More work on pop16
Worked on pop16.pc microcode and sub8.ab microcode a bunch. Didn’t get to a point where either works yet.
Worked on pop16.pc microcode and sub8.ab microcode a bunch. Didn’t get to a point where either works yet.
Figured out the register flow requirements for pop16.pc, and documented it in a diagram. Next step will be to implement the unit test and microcode for it.
Implemented ‘include’ functionality in the microcode generator so that instructions like call (which is really just push16.pc then jmp) can be written as an include, rather than having to copy/paste the contents of those other instructions and maintain two copies.
Implemented CALL instruction, which is now working. Extended the microcode generator so it will now generate a mapping file to translate from a control store address to an instruction name (and step within that instruction), which can be loaded into […]
Refactored all the microcode instructions and their unit tests so that PC now equals the instruction currently being executed, and not the memory location after that. Implemented push16.pc and its unit test and everything works as intended. Next step will […]
Reworked PUSH into push8.imm and push8.? (for future implementation of other non-immediate push8s). Implemented push16.imm and push16.? including their unit test and register transfer diagram. Started working on push16.pc, but ran into an issue where PC is incremented within FETCH, […]
Finished implementing PUSH, including the unit test for it. All seems to be working now, and I fixed a lot of bugs related to RAM while working on this, as this is the first use of RAM in the system. […]
Started working on the unit test for PUSH, found that I hadn’t ever implemented the SP register despite it being the design. Did so, and then did a bunch of troubleshooting related to the new register. At this point tests […]
Added a first stab at some microcode for PUSH, which is a prerequisite for being able to implement CALL and RETURN. Next step will be to write a useful unit test for it so we can confirm it’s working properly […]
Figured out and diagrammed the initials parts of the logic for handling interrupts. Next step is to implement CALL/RETURN, which will be needed to integrate the design into the system.