3 ms·
I don't know whether OP is the author of this code, but if they are, or if anyone is keen to use it as a template, there's a small but important quirk of the Ga
by wk_end 9y ago
I don't know whether OP is the author of this code, but if they are, or if anyone is keen to use it as a template, there's a small but important quirk of the Game Boy hardware this doesn't take into account: when the Game Boy's screen is rendering (i.e. almost all the time), the CPU doesn't have access to VRAM.
In this case, I guess this demo works (if it does, I haven't tested it on my flash cart) because the amount of data transferred to VRAM is small and the timing of things happens to line up so that it all gets sent at the right time, but for anything more complicated you can't rely on that.
There's two ways around this: either turn the screen off before copying your tile and map data over (and you can only safely turn the screen off when it's not rendering, too) or set up a system to blast as much data as possible into VRAM as quickly as possible when a frame is finished drawing.
To test if the screen is off, either spin until bits 0 and 1 of $FF41 == 01 or set up a interrupt handler that'll get fired on vblank.
OP, if you did write this code (or if the author reads this, or if anyone else is interested), feel free to hit me up with any questions. My primary side project is a GB game, and I'd love to talk shop.
- feeb 9y ago(author) thanks so much for the comments. i vaguely knew about this but i serendipitously didn't run into it. how does lack of vram access manifest? do vram writes silently fail? this is precisely the sort of quirk i wanted to cover in this template so i appreciate hearing about it.
- wk_end 9y agoYeah, writes are ignored, and reads return garbage (no idea what). I recommend using the BGB emulator - you can configure it to crash into a debugger whenever it detects an invalid VRAM access. Plus the debugger is insanely useful.
- posterboy 9y agoand the screen is blanked i suppose. that would allow pritive pwm. has that been used? i would imagine that allows some nice fade effects or enhanced bit-depth in the brightness, as is done eg. on c64.
- moozilla 9y agoAdding to what wk_end has said - many emulators (VBA included) will just write to the VRAM without complaining, so you won't even catch the bug unless you try it on a flash cart or in BGB (I'll second that recommendation). For your demo checking $FF41 should be sufficient, unless you're writing a lot of data you'll usually have enough time in one vblank period. You could wait for $FF41 == 01 and then copy all the data, or check it each iteration of the loop (less efficient but will never fail). I've seen actual games do it both ways (decent amount of disassembly/ROM hacking experience).