The Ultimate Game Boy Talk (33c3) [video] | Hacker News Reader

The Ultimate Game Boy Talk (33c3) [video]

youtube.com

119 pointsmcp_38 comments

Open articleView on HN

Similar talks for C64 [1], Atari 2600 [2] and even exotic "Galaksija" [3] computer (ZX 80 clone) are available as well.

[1] https://www.youtube.com/watch?v=fe1-VVXIEh4

[2] https://www.youtube.com/watch?v=aNyebnxV9R8

[3] https://www.youtube.com/watch?v=DIwC9vdqfqw

There's also one for the Amiga 500:

https://m.youtube.com/watch?v=BbVAvDbzXFk

A real eyeopener.

Too bad Amiga was mismanaged from the word go, and that the less than upgradeable 500 was the face of the platform, as it was really ahead of its time in terms of internal design.

But over time the more upgradeable, and cloned to hell and back, IBM PC won out. In particular once the chipsets gained DMA and new expansion buses.

I agree that Amiga was mismanaged from the word go, that was the main issue IMO (they waited far too long before pushing for an upgraded chipset, and they should never have forced the Amiga team to relocate, causing most/all of the original team to leave).

As for expandability, whilst the A500 wasn't as expandable as the A2000, I'd say it was expandable in the ways most users would care about. For example, this expansion allowed users to add a faster CPU (and an FPU), add more RAM and add a hard drive:

http://amiga.resource.cx/exp/gvp530

As long as we're linking personal GB emulators... :-)

Here's mine, written as one file of less than 5000 lines of C: https://github.com/binji/binjgb. It's very accurate, based on few of the most commonly used GB emulator test suites (Blargg's and Gekkio's).

Interestingly, there are still many questions about the specific timings of the Gameboy PPU and APU. An interesting case pointed about by LIJI128 is that no accurate emulator can run Pinball Deluxe; they all crash in some way: https://www.reddit.com/r/EmuDev/comments/4n71ea/gb_pinball_d....

Nice C code! Took a look and seems very solid.

I was unaware of the GB test suites. Thanks for sharing that tidbit.

Amazing!

More or less relevant: For an university project where we made a Game Boy emulator, I wrote a presentation framework on the Game Boy itself, in which we recorded the design video:

https://drive.google.com/file/d/0BzPtU6SpBQZzVVdZZ0kxNGhqVjg...

Source: https://github.com/pepijndevos/gbpaint/blob/presentation/mai...

That code is very clear. Nice. Did you ever go back and write for the GB?

That's my most recent project, but I wrote a paint program and some Pokemon hacks before that.

I wish someone made something about "The Ultimate x86/x64" talk that covered all of the features of modern (x86/x64) processors.

It'd be a couple days long, though...

That's fine. It's worth it. Hell, make it + set of lectures + a book + homework exercises and sell it as a college architecture corse.

Sooo why not just watch a college architecture course?

They are usually very poor in quality. They are also usually stuck in the 70s of architecture development.

LOL this made me remember of a stream about a guy developing a game boy emulator in Python.

By the way, this is the link: https://www.livecoding.tv/michielha/videos/ZeNNa-a-python-ga...

Great talk, tempted to try some Game Boy development now! Apart from the development tools/resources mentioned at the end of the video, any others to recommend?

I was at this talk in Hamburg and it inspired me to tidy up a gameboy dev project I started in Feb. I wish I'd seen this before I started.

BGB (mentioned at the end) really is the best emulator for development, and it works pretty flawlessly in wine (on both OSX and linux). http://bgb.bircd.org/

Aside from that, there is a gameboy cpu manual / cheat sheet (handily printable as an A5 booklet) [1] and by some incredible stroke of luck, there was a university course in Wichita that taught assembly programming via programming gameboy roms [2].

[1] http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf

[2] http://cratel.wichita.edu/cratel/ECE238Spr08

shameless plug: the project I started is available on github here [3] - i'm working on figuring out how to build native ruby extensions so I can have the assembler be built on install, rather than dirtily bundling pre built binaries for OSX use.

[3] https://github.com/rkachowski/rubygb

Cool project! Thanks for the resources. Hopefully I'll find the time to play around with it ...

Thanks for the links, looks like they're great resources to kick start GB dev.

With your project, I'm not sure I understand it yet, is it a tool for creating and running makefiles that work with a GB assembler? If that's right, I can see it being useful.

That's pretty much it, yeah - as well as collating common tools + providing some basic templates for creating projects (getting to hello world requires a lot of boilerplate initialization).

From what I understand, not only does it work in Wine, but it's a first-class supported platform. Never seen that before in software.

Having attended the talk in person, it was probably one of the best uses of animations and diagrams in a presentation I've ever seen.

Agreed. If you discover how he achieved it, let us know please!

Another well designed recommended video about the same topic: "The Game Boy, a hardware autopsy", https://www.youtube.com/watch?v=RZUDEaLa5Nw .

One of the most interesting parts of the talk was the fact that the boot code checks that the game contains the Nintendo logo @19.15. Very smart way of keeping control of the game releases. They have always been very good at keeping their games and copyrights.

Thanks, I had skipped to random parts and missed this one. Here is a transcript:

"The game has to have a copy of that Nintendo logo inside. If it doesn't match, the game does not boot. This was meant so that Nintendo could control which games are released for the platform, because all games had to contain the logo, which is not just a copyright violation but also a trademark violation if you include that and don't have Nintendo's permission".

Neat :)

It's a legal trick that doesn't actually work. Sega tried the same trick and lost when they took it to court in 1992.

https://en.wikipedia.org/wiki/Sega_v._Accolade

It's brilliant. Though this seems like a very "greedy corporation" move nowadays, this was the secret to Nintendo's success eay on. By keeping a tight control over the platform, it guaranteed high quality games and avoided the shoveware of Atari 2600. One could argue Apple emulated this same model 20 years later with the initial tight control over the App Store, to great effect.

I think it was easier to get away with it, when it was simply a entertainment device. But with smartphones etc being about so much more (like say basic communication with an autistic child) it becomes a much harder sell.

It is an interesting overview of Game Boy development: it includes hardware description (CPU, memory map, etc.), per-line interrupt ("raster effects"), palette, priorities, layers, sprites, sound, etc.

This is a really great talk. I have worked on a gameboy emulator in the past in Nim,[1] sadly I didn't get enough time to finish it.

The amount of features offered by the Gameboy does seem rather overwhelming after watching this video.

1 - https://github.com/dom96/gbemulator

Very cool. When I was in high school, I tried my hand at developing Game Boy games using a C compiler. Lots of good memories.

Really hoping they do that Super Nintendo talk next year.

How was the game boy able to do the OAM scan in 20 cycles? You need to do 2 memory reads per sprite(status and y location), times 40 is 80 reads, means 4 reads per CPU cycle.

Perhaps the OAM is in a different memory..? The NES PPU's OAM is in a DRAM, while rest of the PPU RAM is an external SRAM.

I don't know anything about GB programming other than watching the video, but my understanding is that it's not doing memory reads but rather transistor logic to determine which sprites have priority on that line. This is also why you have that 10 sprite limit, as the 10 active sprites end up getting pushed into hardware comparitors for that line.

Explanation starts around 46 minutes into the video.

Right, so these 10 sprites are definitely not in RAM, but in transistor logic, but at the start it has to scan 40 sprites in OAM, which means checking 80 bytes, and copying 10*4 bytes to the comparators.

OAM is separate from VRAM and is located inside the SOC.

The PPU is clocked at 4mhz and I suspect OAM is also clocked at 4mhz (though it could also be implemented as two banks clocked at 2mhz with status in one bank and y location in the other bank). So 4 reads per CPU cycle sounds correct.

I'm very interested in the Kong Feng GB Boy Colour he mentioned, I'd love to know how they copied the GameBoy CPU etc. through decapping.

Reply on news.ycombinator.com