January 9th, 2015, 04:20
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.
Originally Posted by shutterbug2000
There are different ways to implement this. I use a lookup table with 16 entries so that each entry maps 4KiB of memory, using the highmost 4 bits of the address. That size also fits nicely for the switchable RAM banks in the GBC and some other special regions.
This of course means that you can no longer access the whole memory as a single array.
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.
For example, writing to 0xFF0F might trigger an interrupt after the current instruction, or writing to the ROM banks accesses the MBC.
Your console output looks fine, at least if you call it only after a write to 0xFF01.
And 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. Instruction decode/dispatch should also be faster.
The CPU passes almost all tests, with the only failures due to missing timers. Next up are the callbacks for special registers (timers, interrupts...) and graphics. 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. 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 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.
In other news, it looks like one of my favorite gameboy emulators goomba color is under development again.
January 9th, 2015, 15:26
Ok, that helps, but I still need help with one thing. What determines which MBC to use?
January 9th, 2015, 16:07
There are three bytes in the cartridge header that determine all you need to know. They'll tell you the MBC type, how much ROM there is, and how much (if any) external RAM is present. -> http://gbdev.gg8.se/wiki/articles/Th...Cartridge_Type
You'll need to look at the bytes at 0x147, 0x148, and 0x149. 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 -> http://gbdev.gg8.se/wiki/articles/Me...nk_Controllers
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. 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. MESS supports MBC6, but if you're looking at its code, just be aware that it's not technically FOSS. 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.