search

lgblgblgb / xemu

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.
https://github.com/lgblgblgb/xemu/wiki
GNU General Public License v2.0
201 stars 31 forks source link

MEGA65+C65: new findings about how C65 memory management works for real #378

Open lgblgblgb opened 1 year ago

lgblgblgb commented 1 year ago

@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

  1. C65 emulator in Xemu should be modified, as this seems to be the behaviour of a real C65
  2. 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

  1. Has lower priority than MAP as discussed above.
  2. The mapped ares are all based from regions from $2XXXX, never from $3XXXX
  3. Trying to write ROM has similar effect as with the CPU I/O port: writing RAM "behind"
  4. 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.

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:

  1. only $D030 ROM mapping instructs that
  2. only "CPU I/O port" (really done by VIC-III already on C65, AFAIK) instructs that
  3. 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.

lgblgblgb commented 5 months ago

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.