February 25th, 2014, 20:31
Hi just to let you know, I'm working on a opensource gameboy emulator in C#. It's just for the process of learning.
Currently I have a cpu core (which might have bugs, but not for sure), MBC3 support. I'm working on the video driver, but it's not finished yet so you'll have to wait, until you can see some screen of my emulator running games.
(Well I could post screens of my debug console xD). Although it's coded in C#, the cpu core is running at a good speed. Without limiting it, I had a clock rate between 40-200Mhz.
You can view the sourcecode on Github. Just follow this link https://github.com/hackiosa/geekboy/
If I have any questions, I'll ask you.
February 27th, 2014, 21:28
So now I got my first question. I'm currently actively developing on my emulator, and I'm working on video emulation.
Well I'm testing my emulator with pokemon red
And when running the game I almost instantly get some kind of error screen ( I believe ).
This is a screenshot ( and yea', the tilemap handling is propably wrong )
Please replace the hxxp with http, I somehow can't post links ō0
You can read it saying "POCKETMONSTER" and there are some tiles of a pokemon I think. That is why I believe it's a error screen, because normally that wouldn't occur..
March 1st, 2014, 12:38
It's nice to see that someone else is working on an emulator.
The screenshot looks like it shows some tiles from the beginning as they are stored in memory.
It says "POCKETMNSR...red" and each character appears only once, while displaying the text should use them multiple times.
Are you using the right background map? (Bit 3 in LCDC)
The other tiles look like Gengar and Jigglypuff so you seem to be on the right track.
I suspect an error in your display code. The only error screen at startup I can think of is the GBC-only screen, and that's obviously not the case...
Depending on how complete your emulated hardware is, some PD games are good for testing as some of them don't require interrupts or timers.
Blargg's test ROMs are also always a good idea.
March 3rd, 2014, 19:52
I could almost finish the video emulation the last days (expect from oam emulation). It's working and I can play only a few games (such as Zelda - Links Awakening), but most of my games (also Pokemon Red) do not work, so it's the case that I'm suspecting the cpu core, because of the video emulation working. I tried to wipe out all errors I could find, but it still does not work with those games. I tried a lot to find mistakes in my cpu core, but recently I couldn't find any more. Well I think I'll rewrite the cpu core the next days. Blargg's test ROMs sadly do not work, too..
Greets from Germany.
March 3rd, 2014, 23:40
It took me a lot of time to find enough bugs in my CPU core to get the tests and some games running...
I found quite some bugs by taking a working emulator, dumping the registers for each instruction and comparing it with the output of my emulator.
Not all differences indicate errors in the CPU core and some can be caused by interrupts or unemulated hardware registers, but others are hopefully very obvious.
I have extended my instruction decoder to a disassembler and am now working on more sophisticated debugging mechanisms to find hopefully some of the remaining pesky bugs...
March 4th, 2014, 18:22
I used the first method, too and I could find the most obvious bugs using this method. Well I'll try some more methods.
I hope to get it fully working some day Maybe I'll rewrite the core later, using my new method
EDIT: Found 2 bugs, but they did not change a lot. But they could have caused big problems. The first was the SRA opcode that was emulated incorrect and the second bug was that the booleans FlagZ, FlagN, FlagHc and FlagC weren't updated after POP AF. Pokemon Red and a lot of others games still don't work..
Last edited by Flerovium; March 4th, 2014 at 19:21.
March 7th, 2014, 04:26
Flerovium - While it's always good to get CPU bugs fixed, it might not be the issue in regards to games that won't work on your emulator (Pokemon and Legend of Zelda, as you mentioned). It could be any number of other areas (MMU, LCD, input). Depending on your understanding of the Game Boy, you might be able to pinpoint or guess where the problem is; it (sometimes) gets easier the more you deal with the Game Boy and your emulator.
If I were to take a guess, your LCD emulation probably isn't perfect, though I haven't thoroughly looked over your C# code. My advice is to make sure everything works, piece by piece, rather than trying to emulate everything the LCD does at once and scratching your head when you get bugs like this. For example, make sure you can do something basic, like properly render a simple background using Tile Set 1 using Tile Map 1 and 0. Then make sure you can properly render Tile Set 0 using Tile Map 1 and 0. Then move onto Window emulation, then sprites. It's a good idea to do one thing at a time, and make sure it's perfect before moving on.
Off the top of my head, I know of a few good Public Domain ROMs that are good for testing. You can find an old Tic-Tac-Toe demo (good for testing sprites) and a small space shooter (good for testing X/Y background scrolling and sprites) here: hxxps://github.com/Two9A/jsGB/tree/master/tests. Naturally both are good for testing your rendering of backgrounds (can't recall which Tile Sets and Maps they use though). For Window emulation, Balloon Man is really good.
March 9th, 2014, 01:29
I used my disassembler to implement a simple profiler. While the output is very messy and not very useful for most games,
I actually managed to find a regression in one of the first games I got running: http://i.imgur.com/43yRmUj.png
it now waits in an infinite loop for mode 0 or 1 while the display is disabled.
I'm not yet sure why the mode isn't right, but it's the first new bug I found in a long time.
March 16th, 2014, 21:26
Shonumi - Background rendering and window rendering is correct (according to Legend of Zelda). This should not be the problem.
Rüdiger - This looks very nice! I had no time and motivation to work on my emulator the past week. School is eating a lot of time
March 16th, 2014, 23:08
Flerovium - Simply because BG and Window rendering is correct in LoZ doesn't necessarily mean it will be so in something like Pokemon. A lot of games do different things in different ways. As I recall, Kirby's Dream Land seems to reserve Tile Set 1 exclusively for sprites, while Tile Set 0 is reserved exclusively for BG tiles. That's why I encouraged you to check a wider range of situations, to see if you can render Tile Set 1 and 0 correctly using either Tile Map 1 or 0. The best thing you can do is always test more games and scenarios. Aside from that, go over the documentation again and make sure you're doing everything to the Game Boy's specifications.
One of these days I'll get around to making a test ROM dedicated to things like graphical accuracy, but I'm currently gearing up for a 1.0 release of my own GB emulator. It's going to be a busy for me until then.
EDIT: Looking over your code on GitHub, I'm curious as to how you handle the MBC5. Just glancing over it, I don't see anything specifically pertaining to the MBC5. The LoZ uses an MBC5 cartridge, unlike the Pokemon games (Red through Crystal) which use the MBC3 cartridge. You should probably look into your MMU as well, as the way you manage MBC read/writes can be just as big a headache as CPU related issues.
Last edited by Shonumi; March 16th, 2014 at 23:21.