12/27/2023 0 Comments Goomba color oracle of ages![]() * Run your emulator for a bit (a couple of seconds while the problem occurs), then check the last few instructions that were running before closing your emulator. With any luck, you'll be able to say "Hey, after the 5th VBLANK, something happens, my registers are different from BGB's!" and go from there. There are only roughly 60 VBLANKs per second on the GB, so that's frequent enough to see where you go wrong without checking it thousands of time just to see when it goes wrong. Watching when the code jumps to the VBLANK interrupt is a great place to start. Be careful not to choose something that gets called thousands of times per second. * Choose a breakpoint you know your emulated CPU will hit frequently. Instead, consider these techniques I use to determine where the problem lies. I know going through the entire game one instruction at a time is tiring, and in fact you shouldn't be doing that. If you find a point where your debug logs differ from another debugger, that's going to be a point of interest. ![]() Once you've got that set up, compare your debugger's output with the output of a known, working debugger (BGB is great for this). Being able to run the emulated CPU instruction by instruction is a must, as are breakpoints. Even if it's something simple, like just printing out text via the CLI, you should do it. What I would do is start working on a debugger. CPU bugs are not fun since they can be incredibly hard to pinpoint. That saved me tons of time when I worked on the GBA, and I wish I had done it when working on the GB/GBC. I can't stress enough how good it is to build a good debugger into your emulator. Those games are edge cases though if you just want to run 99% of commercial games, MBC1, MBC2, MBC3, and MBC5 are what you should focus on. MESS supports MBC6, but if you're looking at its code, just be aware that it's not technically FOSS. ![]() VBA-M's source code is probably the 'best' (and I use that word loosely, there are hardly any comments in the code!) documentation of the MBC7. There are a few MBC types not listed in the link provided, only because they were exotic (MBC6 for multi-carts? and MBC7 for Kirby Tilt 'n' Tumble) and technically came out after Pan Docs was initially released. It may seem a bit confusing, but handling MBCs is much more sane than trying to handle all of the various NES cartridge types Info on how each MBC works can be found here -> You'll need to look at the bytes at 0x147, 0x148, and 0x149. They'll tell you the MBC type, how much ROM there is, and how much (if any) external RAM is present. There are three bytes in the cartridge header that determine all you need to know. In other news, it looks like one of my favorite gameboy emulators goomba color is under development again. It will probably take some weeks before I can work on it again, but I plan to have it running on the arm board at usable speed in the next few months. For the graphics, I'm considering caching the tiles to speed up the rendering, as the tile accesses seem to take a considerable amount of time. It looks like I can't reuse too much of my old code, either due to the different structure of the emulator or because it is too slow. Next up are the callbacks for special registers (timers, interrupts.) and graphics. The CPU passes almost all tests, with the only failures due to missing timers. ![]() Instruction decode/dispatch should also be faster. Your console output looks fine, at least if you call it only after a write to 0xFF01.Īnd a (not so) small update from me: I reimplemented the CPU core in arm assembly, this time avoiding some of the bottlenecks of my old implementation, mainly interrupts and timer handling. Related to your second question, you might also want to treat memory access to 0xFF00-0xFFFF (and maybe some other regions) differently than regular memory, as some of them will trigger special behaviour.įor example, writing to 0xFF0F might trigger an interrupt after the current instruction, or writing to the ROM banks accesses the MBC. This of course means that you can no longer access the whole memory as a single array. That size also fits nicely for the switchable RAM banks in the GBC and some other special regions. I use a lookup table with 16 entries so that each entry maps 4KiB of memory, using the highmost 4 bits of the address. There are different ways to implement this. Yes, while the region from 0x0000 to 0x3FFF always maps to the first 16KiB, the region from 0x4000 to 0x7FFF can be switched to any ROM bank depending on the MBC (memory bank controller) in the game cartridge.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |