February 25th, 2014, 21: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, 22: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, 13: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, 20: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 4th, 2014, 00: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, 19: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 20:21.
March 7th, 2014, 05: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.
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.