2023-09-26 - Update
This commit is contained in:
parent
562ba47cb5
commit
75fbd20e52
|
|
@ -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
|
||||
Loading…
Reference in New Issue