Paging was implemented way back near the beginning of the project, but page faults hadn’t been implemented yet. This seemed like a good next thing to work on, so I started looking into it today.

I last looked at this about 4 years ago, in Thoughts on Exceptions where I had a basic plan put together. I set up some flip-flops to capture page-not-present and page-not-writable faults, then started looking at what implementing faults themselves would involve. The main issue I’m running into is that the control store address currently runs through five(!) separate muxes to get from all the various sources to the control store RAM’s address input, which is already fairly ridiculous and getting impossible to troubleshoot, and adding an extra mux for this is just going to make it worse. I’m going to take a break at this point and think about it, but I think this section needs refactoring before I can add anything else.

Control store addresses can come from:

• The control store initialization counter (used to copy the ROM control store into RAM at reset time, since ROM is too slow to run out of plus we have a writable control store)
• An interrupt control store vector (also used for DMA)
• The IR register (used as part of the fetch process)
• The DP register (used as part of the control store write operation)
• The Next CS Address microcode field
• The repeat counter combined with the Next CS Address field, used for repeating microcode operations like shifts

I could wedge it into the interrupt vector mux like I did with DMA, except this needs to jump the control store address immediately, not wait until the next fetch like interrupts and DMA do. I’ll think about this for a bit and see if any easier way comes to mind, maybe something like the X/Y mux that activates latches for each input would be a cleaner way to handle this now that there’s so many inputs. First step will be to draw out what exists now, so that I can visualize how it needs to change.