C65 style memory mapping does not match C65 behaviour #712
Labels
architectural decision
This is a very important topic that has wide effects.
enhancement
A feature request or other kind of enhancement.
staged
Ready to be merged with stable master branch.
Milestone
Test Environment (required)
You can use MEGA65INFO to retrieve this.
Describe the bug
There are differences between memory banking/mapping implemented in C65 and MEGA65. The MEGA65 inherited the memory handling of the C65 with map and registers $01 and $d030. However, the main driver for the MEGA65 design was to get the C65 ROM up and running. Since the ROM is not using all capabilities of the mapping methods, we are now seeing differences between C65 and MEGA65 memory and ROM handling. It turns out the C65 mapping is in fact simpler and easier to understand as it does not impose a three-layer priority system to keep in mind.
These are the differences I observed:
MAP
The map instruction can activate mappings (by applying an offset) for 8 blocks 8kb each.
C65: If a read/write access to a mapped address is done by the CPU, it will always be directly resolved to the 1MB address space, hitting either RAM or ROM (and never hitting I/O if mapped). There is no exception to this - map will always do that no matter how $01 or $D030 are set.
M65: Access to a memory location being mapped will only be resolved if not superseded by a $D030 mapping. But it will in turn have higher priority than $01 mappings or I/O accesses.
$01
C65: $00 and $01 are behaving the same as on C64. But if mapping (via map instruction) block 0 with offset 0, then cpuport is bypassed, access will read/write RAM at addresses 0/1 instead.
M65: $00 and $01 are not bypass-able. Writing to them will set the cpu-port config, and additionally will write to the underlying RAM. Reading will always read the cpu-port only, there is no easy way (except with tricks maybe) to read the RAM at addresses 0/1.
$D030
C65: All ROMx flags are related to the memory in range $28000-$2FFFF. They will never be in conflict with $01 mappings, as they are both accessing $2xxxx ROM areas (holding mostly C64 related ROM and interface ROM).
RAM8: $28000 -> $8000-$9FFF (8kb)
RAMA: $2A000 -> $A000-$BFFF (8kb)
RAMC: $2C000 -> $C000-$CFFF (4kb)
RAME: $2E000 -> $E000-$FFFF (8kb)
M65: Most ROM flags map in ROM from $3xxxx, but there is one exception where ROMC is actually mapping in $2Cxxx. Mapping will always happen no matter if MAP is active for that block or not. One must also understand there is another priority between $D030 and $01 mapping as they can map same CPU address space with different ROM regions ($01 mapping C64 ROMs while $D030 mapping C65 ROMs mainly). $D030 will supersede $01 in that case.
RAM8: $38000 -> $8000-$9FFF (8kb)
RAMA: $3A000 -> $A000-$BFFF (8kb)
RAMC: $2C000 -> $C000-$CFFF (4kb)
RAME: $3E000 -> $E000-$FFFF (8kb)
Writing to ROM
C65: Writing to a location with "MAP"ped ROM will always result in no byte written at all. If writing to ROM mapped either via $01 or $D030, the byte will be written to underlying RAM instead -> similar to C64.
M65: Writing to a location mapped with MAP or $D030 will try to write to ROM. If write protect is on, the write will not succeed. Writing to a memory location mapped via $01 will always write to underlying RAM, even if ROM write protection is off.
Expected behavior
It would be desirable to have C65 and MEGA65 behave the same in terms of memory and ROM mapping.
Following changes are proposed:
If the mapped region was turned into RAM before (ROM write protect off), it will write to there instead.This will always be the case even if the mapped ROM was write-enabled via the related Hypervisor call.The text was updated successfully, but these errors were encountered: