2023-09-26 - Update

This commit is contained in:
n loewen 2023-09-27 18:24:53 -07:00
parent 562ba47cb5
commit 75fbd20e52
1 changed files with 23 additions and 1 deletions

View File

@ -16,6 +16,9 @@ pointer will overflow and execution will continue at address $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:
@ -45,4 +48,23 @@ To support ROM, I think this is the best plan:
- 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...)
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