cardiograph-computer/2023-09-26.md

2023-09-26 — Dev notes

TODO

• Review yesterday's notes on extended addressing
• Add tape drive to mainframe
• Add notes on re-arranging extended system docs

Start/Reset notes

Idea/observation: if the processor begins execution at $FE (say), and instruction $00 is NOP, then after a few NOPs the instruction pointer will overflow and execution will continue at address $00.

...which means that we can just pretend that it startts at $00, but also have the option to add ROM at the top of memory, and have a JMP at the top that redirects execution to somewhere else in ROM.

(This overflow behaviour is normal; see https://stackoverflow.com/questions/26139662/program-counter-overflow)

6502 Start/Reset

https://www.masswerk.at/6502/6502_instruction_set.html:

Start/Reset Operations

An active-low reset line allows to hold the processor in a known disabled state, while the system is initialized. As the reset line goes high, the processor performs a start sequence of 7 cycles, at the end of which the program counter (PC) is read from the address provided in the 16-bit reset vector at $FFFC (LB-HB). Then, at the eighth cycle, the processor transfers control by performing a JMP to the provided address. Any other initializations are left to the thus executed program. (Notably, instructions exist for the initialization and loading of all registers, but for the program counter, which is provided by the reset vector at $FFFC.)

Simulator memory management

To support ROM, I think this is the best plan:

• Create a new module that provides a "memory manager", that contains the actual memory plus a set of annotations indicating which parts are RAM and which are ROM
• When instantiating the CPU, the simulator provides it with an instance of the memory manager
• The memory manager has a .write(startingAddress, bytes) method — and it just does nothing when the address is in ROM
• (The memory manager might also need to provide some way of attaching memory-mapped peripherals...)

Changes to Microprocessor Trainer keypad IO ?

I think the DMA plan for the display is fine, because probably the display controller can just tap into the same address and read-signal lines as the main memory.

...but the keypad input is maybe trickier to do by DMA? It could be done by cycle stealing. (Or it could be done by halting the processor, writing to memory, and then resuming... but that's a bad plan for the keypad.)

It seems like it would be simple enough, though, to use the new IO system I've been planning for the mainframe version-- an INP could just enable the keypad to dump its current state directly onto the bus.

• TODO: think a bit about how the INP/OUT commands would work electrically