lgblgblgb
commented
1 year ago The commit above is the supposed fix. Note, that unfortunately it didn't cure the "CRAM utilities" problem (like with configure, but indeed it seems to fix the AnotherWorld problem.
Original issue: #304. During the development of the great AnotherWorld port by Majikeyric, it has been noticed, that Xemu shows a flashing result at only a part of the screen, in every second frame or so. Till now it was very much a mystery what it can be. However recently Majikeyric has informed me, that he has the suspect, glyphs being in the "otherwise colour RAM" 2K area at
$1F800is the problem.Marked as HIGH PRIORITY for now, since it's kind of being part of the foundations of the emulator infrastructure and seems to be kind of dangerous situation.
Original plan for emulation
My original idea was the elimination of checking memory ranges in VIC-IV (and CPU) emulation, so I don't need to handle that memory area in a special way, which would require conditional code at every memory references. So, colour RAM and the "main" RAM (ie, the chip/fast RAM) are both of their own entities with own memory storage. However, on write, both should be update, so then read is OK, not to have specific handing at all.
The problem
The problem, that my original plan seems not be implemented well enough.
It's also very much possible that this problem caused much more trouble, just nobody else (including me) has noticed it yet as the root cause being this bug. I also have a suspect, that maybe
configuredoes not run on Xemu, because of this fact (I'm very much not sure, but configure itself is in the colour-RAM after "power-on").Goal
Fix the issue of handling this memory "shadowing" emulation trick to really work! Hopefully it also fix (at least!) the original AnotherWorld preview, and probably can cure other problems as well.
Again, thanks to Majikeyric for his investigation!
Details
On MEGA65 - confusingly - there are three totally different places when you can access the very same memory:
$D800: 1K or 2K colour RAM (depending on theCRAMbit of VIC-III / VIC-IV)$1F800$FF80000Internally Xemu uses always the "main RAM" (first 384K of memory map, aka "fast" or "chip" RAM) by VIC-IV to fetch anything "non-colour" stuff, and the MEGA65 32K "colour RAM" to fetch colour information. This is a performance hack, so no need to handle special cases based on memory location.
But that also means, that "main" and "colour" RAM must be kept in sync when writing, which was the main issue here. As keeping the sync was bad, any situation when colour RAM area is used by VIC-IV for non-colour information (eg, using glyphs at the
$1F800-$1FFFFarea) to be fetched, resulted in serious problems. Probably other defects could be noticed as well because of this.As we could see above, there are at least three places where this must be fulfilled carefully, plus another Xemu specific one:
configure, can be found in colour RAM after "power on"). So when doing that, it must be also done carefully.