ITS microcode

[larsbrinkhoff]

Hello,

I understand it's still too early now. But if you some time in the future would like to try the ITS microcode hacked by Guy Steele and David Moon, I can provide it. We have it assembled from source code: https://github.com/PDP-10/its/tree/master/src/ucode/

I believe it originates from 1975 DEC microcode, with updates over the years. The major change is to support ITS paging.

[alanmimms]

Cool! Do you believe the ITS microcode would run on the KL10pv ("model B") CPU hardware? Does it run the paging in KI mode in hardware or in KL like mode in microcode?

Yes, it's too early. But it would be interesting to try when I have more of the hardware working. This is going slowly because I have a day job and family, but I hope to get it done eventually. Since I finally found the Xilinx bug that had literally stymied me for months I can make progress again...

[larsbrinkhoff]

The MC KL10 was an early KL10 "model A", and maybe in fact the first delivered outside DEC. I don't know exactly what microcode and hardware differences there are between the model A and B.

Paging is more like KL. Refills are done in microcode from a page table in core, and since ITS pages are 1024 words, two hardware page map slots are used for each page.

[alanmimms]

Model B is like Model A but with 2K microinstructions of CRAM, enhancements to the VMA and PAG (and a few others) to support extended addressing and associated instructions and addressing (especially indexing, indirect, and byte pointers) modes to support 32 sections of 256KW, several boards were redesigned so they were cheaper to manufacture (eliminate blue wires), faster clocks (25MHz -> 30MHz), better clock and skew delay adjustments for long backplanes and cables, 16 element microcode call/return stack (was four in model A), and I think the CRAM became 80 bits wide (was 74 in model A?). Not all bits are used - and, funnily enough - it appears the empty bits were sprinkled around the word to make fields line up on octal boundaries nicely.

If you look in doc/EK-EBOX-UD-006-OCR.pdf Appendix C (PDF p.220 and up) you can see the summary of the changes in more detail.

Several things I want to scream about:

<rant>

1. I hate big-endian bit numbering with a passion. It is half of the root cause of a set of Xilinx bugs that cost me a month in this project wondering what part of SystemVerilog I was clueless about that was causing the bad behavior. It turns out to not be my fault. Requiring that you know the width of a field to calculate the bit mask for field[n] is stupid and wrong.

2. Octal is arse. Powers of 2 are part of computing, yet we have these threes all over the place with octal. The only issue would be for values of halfwords, but that is a problem that's easy to resolve.

3. Despite the fact that the PDP10 instruction set is so charming and is deeply tied up with these two points, I would cheerfully trade them for hexadecimal and bit #n = 1 << n little endian numbering as God intended it.
   </rant>

[larsbrinkhoff]

I think @aap said something like model A microwords are 79 bits, and model B 80. The added bit is for a new subroutine call?

[alanmimms]

There is a new way to do microcode subroutine calls in model B. And I think it does add another CRAM bit. Return is done by executing a microcode "special operation" SPEC/RETURN in both models.