CDC 6000/7000 operation, was: Virtual memory

On 9 Nov 2010 at 12:02, Rich Alderson wrote: Let me be a bit clearer. The assembler supported PPU assemblies of course, but where to go if you were Joe User after your program was assembled? PP programs had to be incorporated into a deadstart tape or could be added via EDITLIB (the system library editor). But this was a privileged operation, requiring a "GO" from the operator, which, unless *you* were the operator, was not very likely. Many installations simply omitted EDITLIB from their deadstart tapes to avoid the possibility of error. If you wanted to goof around with system code, you deadstarted a tape that would allow you to do so. PPU development and debugging required a dedicated system. Once a PPU was hung (via program error or hardware malfunction), it was gone the CPU program talking to it permanently hung as well. One typical development technique was to debug your PP code, successively hanging PPUs until you ran out of them or CM to hold your test program, then you pushed the button. In a university environment, I don't doubt that advanced students were given access to PP code writing in sort of an open lab. But that's hardly a production environment and such testing would be done outside of the time, say, that the University was doing their weekly payroll runs. One of the more irritating problems of working with PPU code was that there were few debug tools. If you had a scope you could read the contents of a PPU's P-counter. And there were deadstart dumps, but the picture they gave was incomplete. I wrote an emulator for debugging PPU code that loaded a small resident into a PP to be debugged, that passed data to a second PP over the same channel used for the console display which then displayed and executed the code. The advantage being that you could see everything and set breakpoints. The slowdown was dramatic--the 512 line printer driver would print about 2 lines per minute... --Chuck