Hacker News Reader

Comment by the_spacebyte | Hacker News Reader

I've been developing a Game Boy emulator with a friend as well, and struggling a lot with the poor documentation. There's a very thorough PDF with lots of information online but when it comes to Opcodes (and cpu flags) it's quite inaccurate. Most often than not I have to skim through several github projects to check that the implementations match. (which sometimes don't)

Perhaps we'll start doing a Nintendo64 emulator instead which is more complex but from what I've heard/read has much better documentation.

View on HN

I've been doing the same thing, with the same .pdf, and hitting the same errors :)

http://gbdev.gg8.se/wiki/articles/Main_Page is my current documentation of choice - which seems to be based on the same .pdf but has a bunch of updates and errors corrected

Glad I'm not the only one : ) Thanks I'll go check it

Ditto. My project is in Zig here: https://github.com/isaachier/gbemu.

The table here: [1] is very accurate. I wasn't able to find any bug either in the cycle counts or the affected flags list during the Coffee GB [2] development.

[1] http://pastraiser.com/cpu/gameboy/gameboy_opcodes.html

[2] https://news.ycombinator.com/item?id=17134668

Perfect, thank you. I've been using this image but only to cross-check the opcodes values and what they meant.

The table in [1] has 0 in the carry flag for the SRA instructions, is that correct? I thought they shifted the lowest bit into the carry same as SRL.

I think you're right, see [0].

Furthermore E9 is not "JP (HL)" but rather "JP HL". If I remember correctly a few timings or instruction sizes are off as well.

[0]: http://www.devrs.com/gb/files/opcodes.html

That can easily be part of the fun (and learning aspect), though: The detective work in researching what the real system does, based on analysis of a real system (if you have one) or just derived from what available software titles do and expect.

Some documentation is good to get you started, but at a certain point it’s the actual software that should be the guiding factor. Inaccurate documentation, which is not uncommon for the Game Boy, can be unnecessarily misleading though (on the other hand, there’s some satisfaction in essentially proving a different behavior, especially if you accept a piece of documentation to be likely inaccurate from the get go).

As far as Nintendo64 goes, https://github.com/yupferris/rustendo64/blob/master/README.m... has a bunch of good documentation links to get started with.

Have you looked at the Pan Docs [0] at all? They're pretty complete, though I've never used them for opcodes.

[0]: http://problemkaputt.de/pandocs.htm#cpuinstructionset

You might want to check Joonas Javanainen's work, who's doing great analysis of the CPU

https://gekkio.fi

The mooneye-gb project is the one I've been checking the most to make sure I'm getting things correctly. His work is massive regarding the game boy.

While playing with the result (working emulator) can be exciting, the process of developing itself sounds quite mundane.

It certainly starts off that way, but right about the time you have most of your opcodes written and can start stepping through your code, it becomes very exciting very quickly. "Ooh, now I have Tetris getting far enough that I think it's writing to tile memory; can I display that?" "Neat! I wonder if any other games are getting that far. How hard would it be to get the backgrounds working now?"

Suddenly every game you have in your library becomes puzzle box and either works (yay!) or much more often for a young emulator, breaks in a perplexing way. It creates a really rewarding feedback loop, where tiny changes to timers and status registers can have big sweeping effects on your tests. And all your tests are themselves games, and usually fun to explore anyway.

What makes you say that? Writing a Game Boy emulator is essentially implementing a whole computer system, in the case of the Game Boy one that can quickly give you gratifying results, but allows you to dive almost arbitrarily deep.

I’d state the opposite and claim that it’s actually one of the most fun and interesting things I’ve ever undertaken. In fact, I am more interested in the process than the actual product. There are tons of well working Game Boy emulators already.

But you're not creating a new computer system, you're not designing it. You have to exactly follow the specs, and the things mentioned by parent. Seems more like mundane and housekeeping stuff rather than creative.

So? Just because you find it boring and mundane does not mean everyone else does. For me at least, there’s few things more thrilling than learning (and maybe mastering) a new thing. You think new systems start out in a vacuum?

Besides, part of the challenge is that there is no comprehensive spec for the Game Boy, so discovery through research and implementation is part of the process.

In contrast to the creativity that you can exercise along many dimensions of implementing an emulator, riding a bike or laying at a beach with a cocktail is hardly „creative“ at all, yet many people enjoy doing that as well (I certainly do). You said you might even enjoy playing with the resulting emulator, that seems even less creative to me.

Implementing a well-documented spec is fairly mundane, but figuring out that spec on your own is a fascinating puzzle. Emulators are full of curious little edge cases that can drive people to the point of obsession.

https://mgba.io/2017/05/29/holy-grail-bugs/

Write your own spec. Then just start designing fun virtual machines. Make them do what they are not supposed to do in lieu of the hacker spirit :)

While programming I don't need to be creative all the time. I find it very pleasing to understand how this systems work and emulate them. I do confess though, that after a while and after understanding them some Opcode families can get a bit boring. But in general I do enjoy emulators very much and don't find them boring at all.

Reply on news.ycombinator.com