The next thing to implement is going to be exceptions, or traps, or faults, I haven’t really decided what to call them yet.

We’ll need them for syscalls, page faults, breakpoints, and probably things I haven’t realized yet. My current thought on implementing them is to treat them as another class of interrupts and give them the same intvect handling that the current ones get, except that we need to jump to the handler on the next microcode step rather than the next fetch. We have 8 interrupts so far, for heartbeat, RTC, serial 0, serial 1, storage, and 3 for the future, if we add another few as “high interrupts” this should do what we need. We’ll need to implement:

• Extra interrupt flipflops and a wider intvect setup to accommodate one extra interrupt for each exception we need.
• Another microcode bit to reset the high interrupts/exceptions. I think resetting them all as a batch should be okay rather than needing individual clears, since we shouldn’t have more than one active at the same time.
• Logic to detect if a high interrupt/exception is active and immediately jump to the handler. I probably need to draw out the current flow of cs_addr as it runs through so many muxes already that I’ve lost track of how it works.
• An instruction to trigger the syscall high interrupt. This will probably be via another microcode bit, though I’m running out at this point so I need to think about this.

Will think on this for a bit before starting to implement it, in case I’m missing something obvious or I think up a cleaner way to do it.