Open NTmatter opened 12 years ago
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.
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.
That's good to know. I'll shop around for another reference emulator once the LLVM basics have been hammered out.
You know I have https://github.com/grantgalitz/GameBoy-Online/blob/master/js/GameBoyCore.js which is a JS GameBoy Color emulator. :P
Yep, I've already started poking through it :)
On Sat, Dec 31, 2011 at 2:31 PM, Grant Galitz < reply@reply.github.com
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
@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