Emulations (running on Linux/Unix/Windows/macOS, utilizing SDL2) of some - mainly - 8 bit machines, including the Commodore LCD, Commodore 65, and the MEGA65 as well.
@ki-bo studying C65's memory management (running test programs on real C65) found several interesting facts and difference from the implementation done by MEGA65-core (also Xemu, in both of its C65 and MEGA65 emulator targets!).
C65 emulator in Xemu should be modified, as this seems to be the behaviour of a real C65
MEGA65 emulator in Xemu should be modified if there is a "for sure" decision that this change will be used in MEGA65-core
Note: implementation in the MEGA65 emulator should be done with some "renovation" (rewrite ...) of the memory decoding (the current one is very messy, hard to maintain, slow, and very error-prone). See: #209
This issue is here for me, to make myself sure, won't forget this :)
The scheme
Loosely based on ki-bo's description.
MAP
MAP has the higher priority. If a memory block is MAPed, not even the $D030-based ROM mapping can override. Current (bad) behaviour: $D030 ROM mapping can override MAP.
CPU I/O port (addr 0/1)
Only there, if the 0th block is not MAPed. Current (bad) behaviour: 0/1 is always there, even if 0th block is MAPed. Also, RAM is never written "behind" the CPU I/O port if CPU I/O port is visible.
D030 (VIC-III) ROM mapping
Has lower priority than MAP as discussed above.
The mapped ares are all based from regions from $2XXXX, never from $3XXXX
Trying to write ROM has similar effect as with the CPU I/O port: writing RAM "behind"
CPU I/O port and $D030 based ROM mapping are similar, and never conflict
MEGA65 ROM protection question
MEGA65 only: what would happen if ROM is not write protected, this is a question we (MEGA65 team) can decided, as it's not limited by C65-correctness (on C65, ROM is always ROM, thus "write protected", we can say).
So, what's the behaviour in case of removed ROM protection with D030 ROM mapping?
Nothing changes it seems, the decision with MEGA65 to still write the underlying RAM in that case.
$D030 based ROM banking and the "C64-way" banking never conflicts, however a question arises. Is there an "OR" condition between them? Ie, if C64 KERNAL is banked-in, it can be achieved with all the three combinations of:
only $D030 ROM mapping instructs that
only "CPU I/O port" (really done by VIC-III already on C65, AFAIK) instructs that
both of them instructs that
I suppose it's true, and all of three would yield in banking KERNAL in (unless the last 8K is not MAP'ed of course, since then it has the priority over banking). However - I assume - there is no cross-cause effect, ie, if CPU I/O port instructs banking KERNAL, the $D030's $E000 banking won't change, but the overall effect of those bits is "KERNAL is BANKed" if any (or both) source is set alone.
Closed for the MEGA65 side of the story, as the in-development new memory decoder (#209) already uses it. Still this issue is remain open for the C65 emulator for now.
@ki-bo studying C65's memory management (running test programs on real C65) found several interesting facts and difference from the implementation done by MEGA65-core (also Xemu, in both of its C65 and MEGA65 emulator targets!).
See: https://github.com/MEGA65/mega65-core/issues/712
And commit: https://github.com/MEGA65/mega65-core/pull/718
Note: implementation in the MEGA65 emulator should be done with some "renovation" (rewrite ...) of the memory decoding (the current one is very messy, hard to maintain, slow, and very error-prone). See: #209
This issue is here for me, to make myself sure, won't forget this :)
The scheme
Loosely based on ki-bo's description.
MAP
MAP
has the higher priority. If a memory block isMAP
ed, not even the$D030
-based ROM mapping can override. Current (bad) behaviour:$D030
ROM mapping can overrideMAP
.CPU I/O port (addr 0/1)
Only there, if the 0th block is not
MAP
ed. Current (bad) behaviour: 0/1 is always there, even if 0th block isMAP
ed. Also, RAM is never written "behind" the CPU I/O port if CPU I/O port is visible.D030 (VIC-III) ROM mapping
MAP
as discussed above.$2XXXX
, never from$3XXXX
$D030
based ROM mapping are similar, and never conflictMEGA65 ROM protection question
MEGA65 only: what would happen if ROM is not write protected, this is a question we (MEGA65 team) can decided, as it's not limited by C65-correctness (on C65, ROM is always ROM, thus "write protected", we can say).
So, what's the behaviour in case of removed ROM protection with D030 ROM mapping?
Nothing changes it seems, the decision with MEGA65 to still write the underlying RAM in that case.
Original info:
https://github.com/MEGA65/mega65-core/issues/712#issue-1767742773
Banking behaviour question
$D030
based ROM banking and the "C64-way" banking never conflicts, however a question arises. Is there an "OR" condition between them? Ie, if C64 KERNAL is banked-in, it can be achieved with all the three combinations of:I suppose it's true, and all of three would yield in banking KERNAL in (unless the last 8K is not MAP'ed of course, since then it has the priority over banking). However - I assume - there is no cross-cause effect, ie, if CPU I/O port instructs banking KERNAL, the $D030's $E000 banking won't change, but the overall effect of those bits is "KERNAL is BANKed" if any (or both) source is set alone.