(notes) 2023-08-24 - Create note with brainstorming re: a more accurate start-up process (and memory/peripheral setup) + a todo list
This commit is contained in:
parent
f2e43888b5
commit
6fc6e727d0
|
|
@ -0,0 +1,81 @@
|
|||
# Dev notes — 2023-08-24
|
||||
|
||||
## CPU start-up
|
||||
|
||||
Thinking about booting up...
|
||||
how would the "pointer to display memory" etc. get initialized?
|
||||
|
||||
They could be in ROM, but then they're not re-locatable.
|
||||
|
||||
Maybe there's a start-up routine in ROM that sets them up?
|
||||
|
||||
[cf. C64 bank switching](https://www.c64-wiki.com/wiki/Bank_Switching)
|
||||
|
||||
The C64 uses I/O lines on the CPU (+ others) to signal to the PLA that it's time to switch ROM banks in or out.
|
||||
|
||||
Maybe I need something like that?
|
||||
|
||||
~~A simplified approach might be to put the pointer-to-display and ...~~
|
||||
|
||||
Current memory map:
|
||||
|
||||
- `00-19` - display (5x5)
|
||||
- `1A ` - pointer to display memory
|
||||
- `1B ` - keypad: value of latest key pressed
|
||||
- `1C ` - reserved for future use (bank switching flag)
|
||||
- `1D ` - initial IP
|
||||
- `1D-FF` - free
|
||||
|
||||
Thinking about changing it for better bank-switching:
|
||||
|
||||
- `00-19` - display (5x5)
|
||||
- `20 ` - initial IP
|
||||
- ` ` - free
|
||||
- `FC ` - I/O controller - pointer to display memory
|
||||
- `FD ` - I/O controller - reserved for future use (bank switching flag)
|
||||
- `FE ` - I/O controller - keypad: value of latest key pressed
|
||||
- `FF ` - ROM - pointer to initial IP
|
||||
|
||||
Ah so actually the issue is that the CPU needs to be paired with an I/O controller,
|
||||
and that needs to know where to look to find these pointers/where to put the keypad info.
|
||||
|
||||
And I think that can just be hand-waved away for now?
|
||||
|
||||
### Here's the plan
|
||||
|
||||
**But I got started on this because I was trying to work out how FF gets loaded with the initial IP, and I think that's still a question.**
|
||||
|
||||
***(And maybe some way to switch ROM in and out would be good for the secret-advanced-mode, since it would be great to have a ROM pre-loaded with a set of convenient utility routines.)***
|
||||
|
||||
I think maybe we just leave the IP hardcoded for now; say that there's a 1-byte ROM at $FF.
|
||||
|
||||
- `00-19` - display (5x5)
|
||||
- `1A ` - pointer to display memory
|
||||
- `1B ` - keypad: value of latest key pressed
|
||||
- `1C ` - reserved for future use (bank switching flag)
|
||||
- `1D ` - initial IP
|
||||
- `1D-FE` - free
|
||||
- `FF ` - ROM (unwriteable) - pointer to initial IP
|
||||
|
||||
- [ ] store `$1D` at `$FF`
|
||||
- [ ] make CPU execute `JMP $FF` on startup
|
||||
- [ ] make ROM unwriteable
|
||||
|
||||
More step-by-step:
|
||||
|
||||
- Change memory from a Uint8Array to a regular array,
|
||||
and make every entry { number | { type: 'ROM', value: number }}
|
||||
- Store ROM as an object in machine.config.js
|
||||
- Load ROM data into memory at CPU startup (`startCPU(RAM, ROM)`)
|
||||
|
||||
(And continue to handwave away how that RAM already contains data, for now...)
|
||||
|
||||
## TODO
|
||||
|
||||
- [ ] Check that we're starting execution at $1D now
|
||||
- [ ] Programming
|
||||
- [ ] Subroutine stack
|
||||
- [ ] Conway's Life
|
||||
- [ ] ? bank switching
|
||||
- [ ] Keypad handling
|
||||
- [ ] Start-up process described above
|
||||
Loading…
Reference in New Issue