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.
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!
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.
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!
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.
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).
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
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).
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!
@@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.
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.
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..
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?
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 :)
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 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 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).
So professionally scripted and edited. All killer no filler!
That's the idea: no fluff just the good stuff :)
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.
I'm glad you've been enjoying them, and please look forward to more in the new year 🎉
More please. It's so hard to find good videos on Gameboy Assembly and I am working on my own game currently. Great video, I learned a lot.
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.
Your best video yet, and maybe the best homebrew primer ive ever seen! I cant imagine how long this took to capture and edit! 😮
Thanks Matt! Yeah it took me about two months from concept, through script, to finished 😅
Good old H-ram. The reason it doesn't cause any bus conflicts is because those 256 bytes are in the cpu die itself, the bus isn't used at all.
Oh interesting, that would make sense given the DMG-CPU is a system on a chip. Now I'm interested and will have to look into it more deeply 🤔
I love your GameBoy videos. Keep them coming! 👏🏻
Thanks! I definitely have more planned for the new year!
I don't understand, how can the display get physically broken by burning a line? You either set it or not to the tiles you want. How can that harm it?
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!
@@NesHacker Thanks! I'll email you when I have a spare minute tonight!
Another good video. Your vids are always worth the wait. Great job!
Thanks so much!
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.
Wow. A lot of work must have been put into this video and the result is awesome. Keep up the good work!
This is the best and most understandable coverage on the topic I've seen so far, really great video!
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!
wow the editing and motion graphics on this video were so good, this was awesome
This is a splendid video! You explained everything very well. It also got me a bit interested in looking into Game Boy homebrew...
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.
Love the animations!
Thank 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).
Very similar, I think the register interface is better on the GB and I like having the fixed window.
@@NesHackerYeah, the window seems cool. I'd like to play with that.
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
Excellent video. Informative and straight to the point!
this video is underrated, it should have a million views by now. amazing!
Maybe someday :)
This is fascinating! So glad I found this channel!
Awesome.
Very well made. Here's a sub.
This channel is so underrated
I aspire to be "rated" someday, and hopefully never "overrated" 😆
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
Hi, I couldn't find your project when searching Emu Boy.
Oh wait NVM, I found it using emuboy and your handle. How can I get in touch with you?
Oh interesting, that makes more sense. Thanks for sharing! 😊
Can a modified emulator remove the flickering by modifying the second OAM register to be larger?
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
Very High-Quality Video. Good stuff.
Thanks 😊
Great video! I learned a lot of cool stuff. Still need help with snes though... Still excited to learn how to do that. Thanks!
I love these videos!
😊
Ok, now it's clear, thanks.
awesome awesome. i found your 6502 crash course a few days ago. glad you're still making videos
Fantastic content, bravo mate
Cheers 🍻
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?
another amazing vid!
😊
Simple and informative.
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).
Awesome. Thank you
You're welcome!
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!
I love this so much. Could you do some content on Rust AGB and how to work with it? that would be awesome! great video!
I’d have to learn Rust first 😂
@@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.
This is very deep game boy knowledge 🙏
Phenomenal
I’m glad you like it!
still fascinating
The fact you can damage your LCD is super scary!
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.
Does this only happen on the original Gameboy screens or on modern panels as well?@@NesHacker
Seems to only happen on the monochrome versions, unclear if it’s an issue on the GBC
love this video!!!
The Game Boy Color is basically the same but with 8 tile and sprite palettes and maybe more tiles
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..
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?
0:02 Seeing an extra sprite that's mostly empty makes me cringe
Haha, it's how they did it...
There is a video called the ultimate game boy talk, they have some word about compute done in hblank necessary for racing game road curves
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 :)
ゲームボーイの進化の おかげで 携帯電話、電子手帳、ポケットパソコンの進化ですからね 容量の解決 文字とグラフィックの鮮明さですから
Thanks ขอบคุณมาก อยากรู้มานานแล้ว
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 love these videos. I keep mistaking you for displaced gamers. Doesn't help that you both talk a lot about the nes and 6502 assembly.
What is the gameboy game with the most sophisticated mapper? Could it be the Game de Heklen Tamagochi ; that unique lookin skyblue cart 🤔
I wonder what the logic was behind building a display that can be damaged by software.
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 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).
Ohhhhh... I get it now.
the programmers must of had fun with making these games....
do you know why a gameboy can normally handle 40 actors, but GB studio can only handle 10 at a time?
Why is it burning that line in?
Gawd dayum good video
-Gawd dayum-
This took a month, wow
Damage the screen?????
1:47 From what game is this?
What game does the map with the castle and islands come from?
That was just a demo I made, you can play with it in the screen scroll demo in the GitHub repo.
@@NesHacker OK nice. Good job!
Thanks :)
Toppppp
My curiosity is how hackers can turn GB games into color game!
Yeah, I'm just gonna visual script, thank you.
Too much hall effect on your audio 😅
Pls dont do that 😬
Yeah it was a mistake. I didn’t test the Final Cut on headphones and I didn’t hear it on my monitors or my mobile devices :(
So what you’re telling me is... thank god I don’t have to code for this thing
Nah, it’s fun 🤩