7 ms·
The Ultimate Game Boy Talk (33c3) [video]
- ZenoArrow 10y agoGreat 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 10y agoI 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
- FlorianRappl 10y agoCool project! Thanks for the resources. Hopefully I'll find the time to play around with it ...
- ZenoArrow 10y agoThanks 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 10y agoThat'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).
- jfktrey 10y agoFrom what I understand, not only does it work in Wine, but it's a first-class supported platform. Never seen that before in software.
- Yan_Coutinho 10y agoLOL 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-game-boy-emulator-36 https://www.livecoding.tv/michielha/videos/ZeNNa-a-python-ga...
- deleted 10y ago[deleted]
- t0mek 10y agoSimilar 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 10y agoThere's also one for the Amiga 500: https://m.youtube.com/watch?v=BbVAvDbzXFk https://m.youtube.com/watch?v=BbVAvDbzXFk
- digi_owl 10y agoA 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 10y agoI 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
- pepijndevos 10y agoAmazing! 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/view?usp=sharing https://drive.google.com/file/d/0BzPtU6SpBQZzVVdZZ0kxNGhqVjg... Source: https://github.com/pepijndevos/gbpaint/blob/presentation/main.asm https://github.com/pepijndevos/gbpaint/blob/presentation/mai...
- pryelluw 10y agoThat code is very clear. Nice. Did you ever go back and write for the GB?
- pepijndevos 10y agoThat's my most recent project, but I wrote a paint program and some Pokemon hacks before that.
- dom96 10y agoThis 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
- gravypod 10y agoI wish someone made something about "The Ultimate x86/x64" talk that covered all of the features of modern (x86/x64) processors.
- pepijndevos 10y agoHow 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.
- q3k 10y agoPerhaps 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.
- mmastrac 10y agoI 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 10y agoRight, 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.
- phire 10y agoOAM 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.
- duiker101 10y agoOne 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.
- deleted 10y ago[deleted]
- gumoro 10y agoThanks, 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 10y agoIt'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
- russellbeattie 10y agoIt'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.
- digi_owl 10y agoI 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.
- deutronium 10y agoI'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.
- Darthy 10y agoAnother 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 .
- faragon 10y agoIt 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.
- binji 10y agoAs 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_deluxe_fails_to_run_on_any_emulator/ https://www.reddit.com/r/EmuDev/comments/4n71ea/gb_pinball_d....
- tbrock 10y agoNice C code! Took a look and seems very solid. I was unaware of the GB test suites. Thanks for sharing that tidbit.
- jupp0r 10y agoHaving 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 10y agoAgreed. If you discover how he achieved it, let us know please!
- planteen 10y agoVery 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.