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.

Sign up for GitHub

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

Jump to bottom

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

Open
lgblgblgb opened this issue Jun 21, 2023 · 1 comment
Open

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

lgblgblgb opened this issue Jun 21, 2023 · 1 comment
Assignees
@lgblgblgb
Labels
target:C65 target:MEGA65 UPSTREAM CHANGE WIP
Projects
C65 emulator project MEGA65 emulator project

Comments

@lgblgblgb
Copy link
Owner

lgblgblgb commented Jun 21, 2023 •
edited

@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: MEGA65/mega65-core#712

And commit: MEGA65/mega65-core#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:

MEGA65/mega65-core#712 (comment)

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 lgblgblgb self-assigned this Jun 21, 2023
@lgblgblgb lgblgblgb mentioned this issue Jun 23, 2023
Closed
@lgblgblgb lgblgblgb moved this from TODO to In Progress in MEGA65 emulator project Sep 15, 2023
@lgblgblgb lgblgblgb added the WIP label Sep 15, 2023
lgblgblgb added a commit that referenced this issue Mar 15, 2024
@lgblgblgb
MEGA65: first try of new mem decoder #209
2f38036 
It seems to work without too much testing yet. The bad news though: it's
seems to a be a bit slower than the old one :( I expected to opposite.

This also uses the baking/mapping behaviour as mentioned in #378
lgblgblgb added a commit that referenced this issue Mar 19, 2024
@lgblgblgb
MEGA65: further new memory works #209 #378
481b177 
More optimizations and modifications:

* It seems the old method is superior: using linear addresses to the
  actual slot backend readers/writers
* Introducing optional data-pointer driven mechanism for further
  emulation performance
* Unfinished "memory-watch" mode
* Various minor modifications and/or optimizations
@lgblgblgb lgblgblgb moved this from In Progress to DONE in MEGA65 emulator project Mar 19, 2024
@lgblgblgb
Copy link
Owner Author

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.

lgblgblgb added a commit that referenced this issue May 12, 2024
@lgblgblgb
MEGA65: new memory decoder #209 #378
45f9ebf 
This quite big change rewrites the MEGA65 emulation memory decoder
subsystem. Some of the reasons:

* Create a new, not overcomplicated decoder which can be understood at
  all without major headache, and can be also faster as per #209
* Taking account some new findings about how C65 worked (both Xemu and
  MEGA65 was wrong here) and adopted since then by MEGA65 as per #378
* More about the future (not ready in this commit): allow functionality
  for debugger implementation "watchmem" which can monitor about every
  memory r/w events debugger want to check as per #11

This commit is quite big as was mentioned, and may introduce some
regressions. So it's important to have feedback in those cases. Also it
changes the behaviour of memory decoding (#378). The new decoder seems
to be already faster than the old one and more easy to understand and
maintain. Also there is some room for future improvements still in every
areas, including optimizations. The "memwatch" part currently is not
usable though, but the basis are there to be able to implement that at
all (wouldn't be possible with the older scheme).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lgblgblgb lgblgblgb

Labels
target:C65 target:MEGA65 UPSTREAM CHANGE WIP
Projects
C65 emulator project
TODO
MEGA65 emulator project
DONE
Milestone
No milestone
Development

No branches or pull requests
1 participant
@lgblgblgb