mark@hubcap.clemson.edu (Mark Smotherman) (03/30/90)
I've been collecting information on I/O subsystems of historically important machines (and recently published a paper on this in ACM Computer Architecture News, Sept. 1989). The CDC 6600 is one of the machines I'm interested in, and I'd like to get I/O code examples. Do any of you have old listings and would be willing to share with me? Ideally, I would like to have something like (for some early OS version): example user program (assembly) code to request I/O (preferably, a disk seek and read of a random record) ppu 0 code to recognize request and assign ppu for transfer ppu code to recognize assignment ppu transfer loop (was the ppu read instruction synchronous I/O, or did the ppu have a polling loop for the device?) ppu code to transfer from local memory to global ppu code to post completion example user program code to handle completion This is how I believe the OS and the machine worked; please correct me where I am wrong. Also, what kind of IOCS functions were placed in the ppu's? (I know ppu 0 ran the OS at first, but did the other ppu's do code translation, editing, record searching, etc.?) I'd also appreciate suggestions or help as to how to obtain similar example I/O code from other machines. Thanks! -- Mark Smotherman, Comp. Sci. Dept., Clemson University, Clemson, SC 29634 INTERNET: mark@hubcap.clemson.edu UUCP: gatech!hubcap!mark
kjm@ut-emx.UUCP (03/30/90)
In article <1990Mar29.164944.19446@msuinfo.cl.msu.edu>, riordanmr@clvax1.cl.msu. edu (Mark Riordan) writes: > Whoops--my previous message got garbled. I said: > > The 6600 was a RISC machine in my opinion--but it could easily have > gotten by with fewer instructions--especially some of those fancy > addressing modes. Huh? *What* fancy addressing modes? I'd not label the increment-unit instructions that way. Why do you? > The Cyber 70 series (with byte-oriented string instructions) was > an embarrassment. Right. Obviously somebody thought the gadgetry would sell... -- The above viewpoints are mine. They are unrelated to those of anyone else, including my wife, our cats, and my employer. Kenneth J. Montgomery Senior Operating System Specialist kjm@hermes.chpc.utexas.edu University of Texas System Center for High-Performance Computing
kjm@ut-emx.UUCP (03/30/90)
In article <19272@shamash.cdc.com>, rrr@hare.udev.cdc.com (richard r ragan 234-4 340) writes: > > Some of the PP code was still in octal and some had > already been disassembled (by someone named Bass as I > recall). The other interesting thing was the > existence of 007. Not James Bond but a PP program named 007 > that simulated the execution of the CPU as a diagnostic > aid. On the console you would see S=0xxxxx instead of P=0xxxx > for the P register. We also (at UT Austin) had a 007, but it provided a stable, high-resolution clock for system performance tracing. -- The above viewpoints are mine. They are unrelated to those of anyone else, including my wife, our cats, and my employer. Kenneth J. Montgomery Senior Operating System Specialist kjm@hermes.chpc.utexas.edu University of Texas System Center for High-Performance Computing
andyd@tekgen.BV.TEK.COM (Andy Davidson) (03/30/90)
In article <7496@hydra.gatech.EDU> roy@prism.gatech.EDU (Roy Mongiovi) writes: >I did always kind of think that B1 ought to have been one, though. >(Or for the really old-timers, maybe that should have been B7.) Yeah. More than once I remember searching for bugs in Kronos and later in 7600 Scope 1 because some rogue program had changed B1 (or B7) from being 1. There were pseduo-ops if I recall correctly called B1=1 and B7=1 in COMPASS so that the assembler could use B1 (or B7) instead of having to use a constant 1. This reduced many increment instructions to 15 bits instead of 30. My first CDC machine was the 3600 and later the 6500 at Michigan State between 1965 and 1969. Much later I worked on 6600 serial 2? 4? at LBL. Hi, Steve. andy Andy Davidson Toolsmith-in-residence Tektronix,Inc (503) 685-3033 Internet: andyd@pogo.WV.tek.com uucp: ...!tektronix!pogo!andyd -- Andy Davidson Toolsmith-in-residence (503) 685-3033 Internet: andyd@pogo.WV.tek.com uucp: ...!tektronix!pogo!andyd
allan@prism.gatech.edu (Allan J. Nathanson) (04/05/90)
>My guess would be LEM, the lunar module landing simulator. This didn't >require the twin tube display - I used it on the later 754 consoles. It >and many other nifty PP programs (Pacman even!) ran under NOS 1, but broke >due to significant PP memory layout changes in NOS 2. Don't know if anyone >ever converted them. CDC supported just the cutesy ones - eye, worms, Andy >Capp, Snoopy, etc. The last time I saw (used) LEM it was packaged in with a "field" SMM tape. I would love get a copy of the source, spend a weekend or two and get it running on the current system. With regard to the other nifty PP programs, a few minor modifications were needed between the various levels of NOS. And they still run at L739! >One of the best twin-tube displays I ever saw was a working Mickey Mouse watch; >the round screen made it particularly effective! This was in the refurb area of >the Arden Hills plant around 1980; I'm not sure if it was ever out in the field. Yes, it made it's way into the field... It always brought smiles to the kids when we had tours of the computer room. ----- Why is QAC always so short on space? Everytime I need to make mods I'm always on the lookout for 1 more byte!!! Allan J. Nathanson allan@prism.gatech.edu Office of Computing Services ...!gatech!prism!allan Georgia Insitute of Technology Atlanta, Georgia 30332-0275 (404)894-4831
woolsey@netcom.UUCP (Jeff Woolsey) (04/09/90)
In article <7691@hydra.gatech.EDU> allan@prism.gatech.edu (Allan J. Nathanson) writes: >Why is QAC always so short on space? Everytime I need to make mods I'm >always on the lookout for 1 more byte!!! Looks like it's way past time to overlay it. Have fun! -- -- Jeff Woolsey Microtec Research, Inc +1 408 980-1300 ...!apple!netcom!woolsey ...!amdcad!sun0!woolsey