Does anyone know if any documentation and tools for microprogramming the 10 survived?
Note that KS and KL microarchitecture (and microcode) are VERY different. About the only thing they have in common (besides implementing the PDP-10 ISP) is that they use the MICRO assembler. (Which was the progenitor of MICRO2 (used for VAX & beyond), though MICRO2 isn't upward-compatible.) The KL's ucode is entirely in RAM (D for instruction dispatch, C for control); the KS's DCODE is in ROM (Because it would "never" change, and naturally, as I have come to understand, Mr. PDP-10 found the only known bug in it...).
Be careful with terminology. The "Front End" processor for the KS10 is an 8080 (unlike PDP-10's in the KL series), but the documentation also labels them as '8080 microcode '.
The directory: https://pdp-10.trailing-edge.com/ has SIMH tap format tapes, of number of sources, binaries and tools for the KL and KS systems. Look for the headings labeled "KS10 specific stuff" and "KL10 specific stuff." The binaries and documentation source for the microcode for each are in the files labebled: TOPS-10 KS Microcode Sources 1.13 and KL10 Microcode Sources V2A (442)
The program called MICRO can be found in each.
--
You received this message because you are subscribed to the Google Groups "PiDP-10" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-10+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-10/d67940ea-95a9-4768-bac4-ac482708ee1cn%40googlegroups.com.
the KS's DCODE is in ROM
Be careful with terminology. The "Front End" processor for the KS10 is an 8080 (unlike PDP-10's in the KL series)
the documentation also labels them as '8080 microcode '.
Clem Cole wrote:the KS's DCODE is in ROM
No, it's also in RAM. It sits in a special location on disk where the 8080 retrieves it and puts in in the KS10 control memory. The 8080 has operator commands to write individual microcode words.
Yes, it reads the KS ucode. [.. my email had mentioned from RP/RM disk or TU tape...] Specifically, the CCODE, since the DCODE is in ROM. There are several variants. Originally, one UCode that supported both KI and KL paging, as selected by the OS. (KL is KL pointers and page tables, but only section 0 and some KL paging/extended instructions. To support TOPS-10/KL paging, I also suppress updating the CST if the CSB is 0 - so unlike the KL, the KL paging ucode is the same for both OSs.)
That last line is more than assuming. He's one of the smartest people I know, and has an extremely deep understanding of how computers should work in theory, how they work in practice, and most importantly, why those are often different. [He is also one of the unsung heroes of Alpha's BTW. I think the only thing WRT Alpha I and a few other folks from UNIX-land disagreed with him on — and was later (sadly) proven right about — was the lack of byte support — EV5 finally added those instructions, as in practice, leaving everything as words had proved too painful].When I added the byte-swapping BLTs, I split it into a KI-only (needed for diagnostics) and KL-only (TOPS20, and later TOPS-10 when I switched TOPS10 to KL paging). Necessary for space. But if you expanded the CCODE store, you could compile for both, and one FPGA implementation apparently did.
MIT has a variant that supports (only) ITS paging. (And calls me an idiot in the comments...)
the CCODE is RAM (and is loaded by the 8080 front-end from storage); but the DCODE is in ROM.
MIT has a variant that supports (only) ITS paging. (And calls me an idiot in the comments...)