Handle modifiable code stored in RAM

[NTmatter]

@grantgalitz points out that games often execute code stored in RAM. This means code may be modified dynamically. It will be necessary to provide cache invalidation for memory >=0x8000. It may be easier to simply fall back to a basic interpreter loop when executing outside of the cartridge ROM

[ghost]

Yeah, specifically games are supposed to busy-wait inside the high-ram (0xFF80 to 0xFFFE) for the length of the period of an OAM DMA (sprite coordinate and information hardware based fast-copy). This is because the CPU is not stopped during the OAM DMA. The HDMA/GDMA of GameBoy Color does stop the CPU though, the exception being OAM DMA of course.

[ghost]

Also, you'll have to handle ROM and RAM memory banking for the more common cartridge types (MBC1/MBC2/MBC3/MBC5), which most games utilize. Imran's demo was a novel and incomplete demonstration that lacked much compatibility due to this (And due to his interpreter emulating the opcodes wrong under certain instructions (Hint: GB does flagging differently than the Z80 under some cases)).

Also make sure you get good accuracy on the STAT interrupts, as many games require near-perfect to perfect clocking there.

[NTmatter]

That's good to know. I'll shop around for another reference emulator once the LLVM basics have been hammered out.

[ghost]

You know I have https://github.com/grantgalitz/GameBoy-Online/blob/master/js/GameBoyCore.js which is a JS GameBoy Color emulator. :P

[NTmatter]

Yep, I've already started poking through it :)

On Sat, Dec 31, 2011 at 2:31 PM, Grant Galitz < [email protected]

wrote:

You know I have https://github.com/grantgalitz/GameBoy-Online/blob/master/js/GameBoyCore.jswhich is a JS GameBoy Color emulator. :P

---

Reply to this email directly or view it on GitHub: https://github.com/NTmatter/LLBoy/issues/5#issuecomment-3323151