Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C65 style memory mapping does not match C65 behaviour #712

Closed
ki-bo opened this issue Jun 21, 2023 · 3 comments
Closed

C65 style memory mapping does not match C65 behaviour #712

ki-bo opened this issue Jun 21, 2023 · 3 comments
Assignees
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.

Comments

@ki-bo
Copy link
Member

ki-bo commented Jun 21, 2023

Test Environment (required)
You can use MEGA65INFO to retrieve this.

  • Platform: all
  • Core Commit: 23b2368
  • ROM Release: 920377

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:

  1. Read/write RAM at $00/$01 in case block 0 mapping (via map instruction) is active with offset 0.
  2. Don't write to RAM if cpu-port is visible at addresses $00/$01
  3. MAP instruction has highest priority with no exceptions. A mapped address will always access the resolved 28bit address. Whether a write to there succeeds depends on whether read-only is active for that address.
  4. $D030 is always mapping address space $28000-$2FFFF. There is no priority over $01 to keep in mind as they will never conflict.
  5. Writing to ROM mapped via $01 or $D030 will write to underlying RAM instead. 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.
@ki-bo ki-bo added the new New report, not classified yet label Jun 21, 2023
@lgblgblgb
Copy link
Contributor

This is very-very interesting, and to be honest, makes sense, especially with the notion of "NOMAP" signal. However $D030 behaviour difference is really strange for me. I mean, how it is possible that basically M65 uses the "wrong" address for any D030-based ROM mapping (other than for ROMC!) and still the original C65 ROM works fine with M65? Does it mean, that the ROM does not use too much this D030-based mapping facility which would show the problem (other than the ROMC @ $C000)?

@ki-bo
Copy link
Member Author

ki-bo commented Jun 21, 2023

Exactly, ROM only used ROMC of $D030. Other ROM is banked in via MAPLO/MAPHI.

@ki-bo ki-bo added enhancement A feature request or other kind of enhancement. architectural decision This is a very important topic that has wide effects. and removed new New report, not classified yet labels Jun 21, 2023
ki-bo added a commit to ki-bo/mega65-core that referenced this issue Jun 21, 2023
@ki-bo
Copy link
Member Author

ki-bo commented Aug 7, 2023

Updated the original text to reflect our decision to always write to underlying RAM when writing to $01/$D030 mapped addresses.

@ki-bo ki-bo self-assigned this Aug 7, 2023
@ki-bo ki-bo added the staged Ready to be merged with stable master branch. label Aug 31, 2023
@ki-bo ki-bo closed this as completed Aug 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

No branches or pull requests

2 participants