
The Ultimate Game Boy Talk (33c3) [video] - mcp_
https://www.youtube.com/watch?v=HyzD8pNlpwI
======
t0mek
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](https://www.youtube.com/watch?v=fe1-VVXIEh4)

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

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

~~~
ZenoArrow
There's also one for the Amiga 500:

[https://m.youtube.com/watch?v=BbVAvDbzXFk](https://m.youtube.com/watch?v=BbVAvDbzXFk)

~~~
digi_owl
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.

~~~
ZenoArrow
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](http://amiga.resource.cx/exp/gvp530)

------
binji
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](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...](https://www.reddit.com/r/EmuDev/comments/4n71ea/gb_pinball_deluxe_fails_to_run_on_any_emulator/).

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

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

------
pepijndevos
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...](https://drive.google.com/file/d/0BzPtU6SpBQZzVVdZZ0kxNGhqVjg/view?usp=sharing)

Source:
[https://github.com/pepijndevos/gbpaint/blob/presentation/mai...](https://github.com/pepijndevos/gbpaint/blob/presentation/main.asm)

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

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

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

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

~~~
gravypod
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.

~~~
apetresc
Sooo why not just watch a college architecture course?

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

------
Yan_Coutinho
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...](https://www.livecoding.tv/michielha/videos/ZeNNa-a-python-game-boy-
emulator-36)

------
ZenoArrow
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?

~~~
rkachowski
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/](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](http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf)

[2]
[http://cratel.wichita.edu/cratel/ECE238Spr08](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](https://github.com/rkachowski/rubygb)

~~~
ZenoArrow
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.

~~~
rkachowski
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).

------
jupp0r
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.

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

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

------
duiker101
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.

~~~
gumoro
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 :)

~~~
koorogi
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](https://en.wikipedia.org/wiki/Sega_v._Accolade)

------
faragon
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.

------
dom96
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](https://github.com/dom96/gbemulator)

------
planteen
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.

------
pepijndevos
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.

~~~
mmastrac
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.

~~~
pepijndevos
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.

------
deutronium
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.

