In this episode I explain Game Boy graphics and fly through some of the code behind those graphics... Support the channel: / neshacker Game Boy Graphics Project - github.com/Nes...
For those who don’t know, the concept of VBLANK stems from consoles connected to CRT TVs where the beam draws the picture from the top down, but the beam needs time to be brought back to the top and is turned off for this period. This happens 60x/sec (USA) and is even designed for in the NTSC/PAL standards. It conveniently gives time for the CPU to do some extra offscreen tasks such as screen movement tile refreshes etc. they carried this over to the Gameboy not because an LCD would need time to go from bottom to top, but it defines a target frame rate and also gives some off-screen CPU time.
I'm not a programmer, just someone who loves video games, and your videos have been great at explaining to a layman how the code is working under the covers.
You are an online rarity my friend. If Nintendo has any vision they should support you in teaching these things to people. You are effectively preserving a chunk of history through technical knowledge. Your videos will be a key asset when people decide it's time to make retro graphics again. And I'm pretty sure when people are through with the new systems and their eternal quest for realism, people will notice true art and design lies in doing more with very little.
This is a great overview for gameboy graphics. I suppose the only thing missing is that you can use interrupts to wait for VBlank instead, which lets you save some battery by halting the CPU in the interrim. It's so cool to see you working on Game Boy stuff at the same time that it's been on my mind. I'm creating a programming language specifically targetted for GB and NES so its nice to have the additional resources to enjoy. I hope you do a video on GB audio in the future :)
I really want to do a dedicated video on interrupt techniques for things like V/HBLANKS in the future. It was hard to fit into the script because I feel the need to explain interrupts in general at that point and it would have felt somewhat off topic for how focused I was keeping things. Good luck on your language, that sounds like a really fun project 🙂. And I'm hoping to do an NES Audio video/project in the new year... one on GB audio is definitely a good idea too!
@@NesHacker ah true, it definitely qualifies for its own topic. The language-work is fun, although a lot of effort, will have to keep you posted, if you're interested!
After seeing Roger Copetti's updated article on the GB's architecture I decided to revisit the bus conflict mystery and I think I've solved it. It seems to be down to two things: 1 - OAM corruption without bus conflict The GB's PPU is kinda buggy, and even if you avoid a bus conflict you can still get OAM corruption if OAM is written to at the wrong time, generally when the PPU is in mode 2 or 3 (these are internal modes, not programmer accessible ala Mode 7). Most emulators won't care and a write to OAM is a write to OAM, but hardware and cycle accurate emulators do care. Since both of these are "live" rendering modes you can avoid this by only ever doing OAM DMA during VBlank. 2 - Actual cause of the bus conflict While most consoles will pause the CPU during a DMA transfer (PS3/Xbox One family are exceptions, though they have multiple HW threads and more advanced bus arbitration so they are a bit out of scope), that doesn't seem to be the case with the GB. Rather, CPU memory access is _invalidated_ which can result in a lot of strange behavior if you're not prepared for it. By making sure CPU access always succeeds by starting DMA while the CPU is running in HRAM this is avoided. I think that makes sense. I could still be wrong (not an electrical engineer) but this does seem to explain everything I had questions with
This video gave me the motivation to learn coding and do a custom gameboy Zelda game as a first project. Mostly because i would be bored to create entirely new tilesets but also because we didn't have an original 2D Zelda in past a decade and i can't wait any longer 🤣 Question : i imagine the logic of the game code on gameboy color is identical but instead of 1,2,3 for color value there's a lot more, or is it more complex than that?
It's possible to update the tiles during the horizontal interrupts (a few pixels each time, since there is many HBLANK in a single frame). A lot of games does that to animate the overworld map.
Indeed, wanted to cover it but didn't want to get into the complexity of HBLANK in this video (especially since I haven't really covered interrupts or timing on the channel).
@@NesHacker I know how to run demo "No Game" but that's where my adventure ends. Currently learning bevy but agb really took my attention. I'm using mGBA and it works great, i have successfully output some logs from my app. now i need to understand gba completely in order to make any progress.
I always wondered how sprite maps worked. Do you have small examples showing the map, code, and expected output for just learning rather than the expectation of implementing it?
That's freaking incredible! ....... i didnt get anything!! .. but i'm sure it's freaking incredible! nah seriously that captivates me to see how everything worked back then... I have so much respect for these programmers.. all these precise manip of assembly with the limitations etc...... now all they have to do is click click click click..
It's super weird too, and hard to find concrete information on exactly how it happens. But it's in the pandocs, so I decided it was probably best to point it out to anyone making and playing their own home brew games.
How does writing graphics data during retrace physically damage the screen? That's got to be one heck of a flimsy LCDC design to make that possible. I'm also not finding anything online about this phenomenon.
It’s more changing the display enabled state outside a VBLANK. Pandocs warns against this explicitly, but afaik it’s not been definitively confined that this does happen (see the very long thread in the comments to this video).
I was wondering the same thing. I'm having a real hard time believing this and in my (albeit short) round around the web I haven't found any evidence to support this claim (yet). I'm not sure if what is shown @1:35 is actually a (permanently) damaged LCD from software or just a hardware failure.
Quoting the pan docs: “Stopping LCD operation (Bit 7 from 1 to 0) may be performed during VBlank ONLY, disabling the display outside of the VBlank period may damage the hardware by burning in a black horizontal line similar to that which appears when the GB is turned off. This appears to be a serious issue. Nintendo is reported to reject any games not following this rule.”
@@regular_spaceYes, but from NESDev: "However, in leaked official Nintendo Game Boy Programming Manual (version 1.0, released 11/09/1999) it's not mentioned that it can cause any hardware damage, only that "a black horizontal line appears on the screen" if LCD turned off outside of VBlank interval (except on Game Boy Color, where it's safe). Also it says that it's 'recommended', not 'required'." From what I've been able to find so far, you'd have to keep doing it pretty extremely and for long periods to have any real lasting effect (if at all). Edit: The actual text from the manual: "Setting the LCDC to OFF (Recommended) Covers: DMG and CGB In early DMGs, a black horizontal line appears on the screen if the LCDC is stopped (LCDC register bit 7 ← 0) at any time other than during vertical blanking. Therefore, the LCDC should be set to OFF during V-blanking. If the occurrence of V-blanking cannot be confirmed, the LCDC should be set to OFF when the value of the LY register is 145 (91h) or greater. These restrictions do not apply in CGB. Thus, when creating software for use on CGB only, the timing of setting the LCDC to OFF need not be considered."
I too am confused by why this might happen. I debated leaving it out, but having seen the line on one of my Game Boys and seeing the GIANT SCARY RED section about it on pandocs made me reconsider. 🤔
I imagine it's a similar case to how the Commodore Pet has the killer poke. The LCD isn't a CRT (even if it behaves like one for the PPU), I don't think you can burn it in. There might be some temporary odd behavior, but no serious permanent damage.
The bus conflict issue is interesting. HRAM ($FF80-$FFFE) and OAM are on their own internal busses to the SoC while WRAM/VRAM are external, so the CPU can safely access HRAM during the transfer. The thing is, the GB's DMA unit is supposed to block CPU access while it is working, so I'm not sure how you could have the conflict appear in the first place. But reading up on a number of high-end GB documentations and they all warn against bus conflicts, though none go into detail about why it happens when on paper the DMA unit should prevent it.
Kirby, you never disappoint. If you’re interested in doing technical editing on scripts, let’s talk. E-mail my NesHacker account. I’d be very happy to hear from you!
More or less the same as the NES/SNES strategy, except that those had more resources (more palette colors, larger tables, more sprites per scanline, etc).
Im loving the gameboy development videos, you actually got me to start a project i've always wanted to do! Keep em coming.. I would love to learn common gb coding practices.
I feel like you look a lot like the Honest Guide here on youtube, who does informative videos for people visiting the Czech Republic. Is that a weird thing to say?
How did they update & store multiple instances of the same entities(les say goomba)? How was additional entity data (like speed and other 'unique' attributes) other than the ones in the sprite attribute tables were stored for these entities (goomba)?
I think this channel is very neat and you're certainly a clever chap. Now I do have a question as since I found your videos I looked on ebay for a game boy. I have to admit I know nothing about the hw but there were lots of choices - are you referring specifically to the first large grey game boy or will one of those pocket versions work?
The Game Boy Pocket is functionally the same as the original "gray brick" Game Boy. So it will work for all the stuff I cover in the video just fine, and it's probably a better choice unless you want the original as a collectors item. Thanks for watching!
This is certainly a great and very explanatory video for whoever wanna start messing with Game Boy graphics, but it doesn't mean it won't catch the interest of "simple" video games fans! That's a lot to say about such a technical topic ! thank you very much for both the information and presentation featured in your video!
Oh this video is great, I already knew a little bit about this stuff from SNES hacking but i never realized what PPU or OAM actually stood for until this video It was also neat to see the similarities and differences between SNES and GB
Love it - I wrote a Game Boy emulator this year (Emu Boy on github). Can truely say I know what makes it 'tick' now :) per scanline sprite limits are due to secondary OAM. This is a fixed sized hardware register which loads and queues up sprite data per scanline, hence the limit. Also, spirite prioirty weirdness got significantly tidied up on Game Boy Color
That was a really exciting look at the Game Boy. As I am currently working on my own homebrew project for the NES, a lot of the mentioned concepts sound pleasantly familiar.
HBLANK stuff is pretty fun, and I tried to fit it in, but the script seemed to balloon up too much when I did, so I decided to set it aside and handle it in a future video :)
