70 lines
2.7 KiB
Markdown
70 lines
2.7 KiB
Markdown
# 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 |