Add dynamic mode change by writing to $d030 #8
Conversation
MCL64/SourceCode/MCL64.ino
Outdated
| @@ -476,6 +477,9 @@ inline void write_byte(uint16_t local_address , uint8_t local_write_data) { | |||
|
|
|||
| wait_for_CLK_rising_edge(); | |||
| digitalWriteFast(PIN_DATAOUT_OE_n, 0x1 ); | |||
| } | |||
| if ( internal_address_check(local_address) == 0xd030) { | |||
There was a problem hiding this comment.
probably here should be a check to see if I/O is enabled with current memory configuration
…t and test those modes before effecuating mode change at d030
|
Hopefully current_p was the item that keeps track of addr 1 mapping changes. Also, found a small nit that would make writes to 0x02 behave different from 0003->ffff. I think only addr 0 and 1 are special, 0x2 is commonly used as the first free zp memory location so it should act like 3,4,5,6 and so on. |
Yes, 0x02 is plain RAM. The address 0x00 is the CPU port direction register and 0x01 the port data register. Interestingly, these two don't really belong to RAM - writing to these two addresses doesn't drive external control lines on 6510 (section 4 of https://www.cebix.net/VIC-Article.txt ), but I don't believe handling this special case would make any difference regarding compatibility. The only way to read/write RAM at 0x00/0x01 is to trick VIC into doing it for you. That's a lot of extra effort not needed in games or demos. |
Only compile tested, I have no teensy4.1 MCL kit yet.
Lots of later improvements possible, like checking where screen ram actually is runtime and so on, but this should be no change from the compile-time SPEEDUP value used before, but allows code to set other values at runtime.