Super gameboy color?

Discussion of programming and development for the original Game Boy and Game Boy Color.
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Super gameboy color?

Post by 93143 »

Quick question: how much of its palette can the CGB overwrite between one scanline and the next? It looks like GDMA can write two bytes per cycle, which would allow the whole palette to be rewritten in some cases. Is that true?

game-boy-lcd-refresh-diagram.png

Also, my understanding of the above is that the palette cannot be changed during active display, so the whole line is drawn with the same 56-colour palette, with no colour math or other complex on-the-fly adjustments. Is that correct?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Super gameboy color?

Post by lidnariq »

I've found mention of a "2560 colors demo" which appears to be just uploading 20 palette entries on each of 128 scanlines, for whatever that's worth.
Shonumi
Posts: 342
Joined: Sun Jan 26, 2014 9:31 am

Re: Super gameboy color?

Post by Shonumi »

93143 wrote: Wed Nov 04, 2020 8:40 pm Quick question: how much of its palette can the CGB overwrite between one scanline and the next? It looks like GDMA can write two bytes per cycle, which would allow the whole palette to be rewritten in some cases. Is that true?
Two things to keep in mind when talking about DMAs and palette changes on the GBC:

1) Both HDMA and GDMA do not allow you to specify a destination address outside of VRAM. You could technically change the palette used by individual BG or OBJ tiles, but not the colors for the palettes themselves. A pair of registers are used on the GBC to set palette index ($FF68 - BCPS) and the palette color data ($FF69 - BCPD). So those addresses are out of range.

2) You can't DMA palette data quite nicely on the GBC in comparison to other systems. Some consoles reserve specific areas of VRAM for palette data in sequential bytes of memory. Game Boys didn't start doing this until the GBA. This goes back to the two registers I mentioned above. Even if you just wanted change 1 palette every scanline via DMA, the 8-bit register BCPD requires 2 writes to the same location to set the 16-bit palette data.

So, what I'm getting at is that you'll have to manually write some sort of copy routine that executes every scanline (or whatever frequency you need). From what I understand, the simplest route is to use an LCDC Status interrupt triggered by HBlank, and then run your code at that time.
93143 wrote: Wed Nov 04, 2020 8:40 pm Also, my understanding of the above is that the palette cannot be changed during active display, so the whole line is drawn with the same 56-colour palette, with no colour math or other complex on-the-fly adjustments. Is that correct?
Actually, you can change the palette during active display. It just has to be during a time when VRAM is accessible via the CPU. Again, the easiest thing to do is wait for HBlank. I think a few commercial games do this, but it's only practical in limited situations. I believe Tomb Raider does it for "cutscenes" that are detailed still images, and I think Alone in the Dark is known to do this as well. That's how both seemingly exceed the number of displayable colors. And I'm sure there are countless demoscene pieces that do it too. Additionally, see LIJI's GBVideoPlayer2. I'm sure that thing makes all kinds of palette changes.

EDIT - Or maybe I misunderstood what you meant by "active display". For some reason I thought you meant the entire display (until VBlank presumably). Just realized that you might also be talking about mid-scanline stuff. Sorry, it's late over here... Anyway per-scanline, it should be possible during OAM search as well, but this happens before rendering. I'm not sure you could start changing stuff during Mode 3. I think only Prehistorik Man tried that on the DMG.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Super gameboy color?

Post by calima »

There was also some "direct color" mode that would let you display pretty static pics.
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Super gameboy color?

Post by 93143 »

lidnariq wrote: Wed Nov 04, 2020 10:46 pm I've found mention of a "2560 colors demo" which appears to be just uploading 20 palette entries on each of 128 scanlines, for whatever that's worth.
Shonumi wrote: Wed Nov 04, 2020 11:51 pmYou can't DMA palette data quite nicely on the GBC in comparison to other systems.
Okay, so apparently you can't just bulk-DMA RGB values into palette memory, and 20 colours changed per scanline is probably about the limit.

...but Wikipedia says that you can do over 8000 colours by changing the palette between lines. That's 56 colours per line, which is quite close to the theoretical GDMA upper limit. I recall a while back there was some interest on this forum in improving that page; did this slip through the cracks? The NES section looks great...
it should be possible during OAM search as well, but this happens before rendering. I'm not sure you could start changing stuff during Mode 3. I think only Prehistorik Man tried that on the DMG.
Yes, that's what I meant - Mode 3. My interest is primarily in determining whether it's possible for a scanline to have more than 56 colours on it.

The graphic I posted seems to say no. ...except that apparently if palette access is blocked, the result is black whether or not any of the palette entries are black. That would bump it up to 57.

Is "CGB mode" determined at boot, or can it be changed in software? Is it possible to toggle CGB mode during a line, so part of it is in monochrome? That would bring it up to 61. Screen blanking for DMG is whiter than white, making it 62...

Are there any possible circumstances at all in which a single scanline could have more than 62 colours on it? I've got an idea, and I want to be sure I'm not missing something important.
calima wrote: Thu Nov 05, 2020 1:07 amThere was also some "direct color" mode that would let you display pretty static pics.
That's not what I want to hear... I also see no sign of it in the Pan docs, but it's not like I've read them exhaustively... could you be referring to the parrot on Wikipedia, or the "2560 colors demo" lidnariq mentioned?
Shonumi
Posts: 342
Joined: Sun Jan 26, 2014 9:31 am

Re: Super gameboy color?

Post by Shonumi »

93143 wrote: Thu Nov 05, 2020 2:03 am Yes, that's what I meant - Mode 3. My interest is primarily in determining whether it's possible for a scanline to have more than 56 colours on it.
If I have time, I can try to write a brief test ROM later today to see if any GBC palette writes during Mode 3 have any effect. I think LIJI or gekkio might have a more authoritative answer in the meantime.
93143 wrote: Thu Nov 05, 2020 2:03 am Is "CGB mode" determined at boot, or can it be changed in software? Is it possible to toggle CGB mode during a line, so part of it is in monochrome? That would bring it up to 61. Screen blanking for DMG is whiter than white, making it 62...
It's determined at boot. The boot ROM writes to some special MMIO registers, and most of that stuff get locked down as read-only after that. Some bits are writable still, but you can't toggle in between DMG and GBC mode like that.
93143 wrote: Thu Nov 05, 2020 2:03 am That's not what I want to hear... I also see no sign of it in the Pan docs, but it's not like I've read them exhaustively... could you be referring to the parrot on Wikipedia, or the "2560 colors demo" lidnariq mentioned?
They may probably be referring to graphics like this or this. That's from Tomb Raider: Curse of the Sword. Not sure how many palettes it's changing per-scanline though.
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Super gameboy color?

Post by 93143 »

Shonumi wrote: Thu Nov 05, 2020 2:54 amIf I have time, I can try to write a brief test ROM later today to see if any GBC palette writes during Mode 3 have any effect.
I mean, if you're curious... I'm not that desperate. It's just an idea, and if it'll probably work that's good enough for me at the moment.
They may probably be referring to graphics like this or this. That's from Tomb Raider: Curse of the Sword. Not sure how many palettes it's changing per-scanline though.
Taking a quick look in the GIMP, it looks like it may be just the BG layer (32 colours) with perhaps up to half of the colours changed per line.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Super gameboy color?

Post by calima »

No, I seem to remember it wasn't the "update palettes during hblank" technique that games used. It was similar to Genesis and SNES direct color modes, a DMA hack, and no game used it. I don't remember where I saw it though, and couldn't find anything in google...
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Super gameboy color?

Post by 93143 »

Okay, f*** modern computing in general.

I just went on GitHub and found a repository of Game Boy documentation. I clicked on one, which was a PDF less than half a megabyte in size.

I had to MANUALLY POWER-CYCLE MY COMPUTER because I ran out of RAM and the browser stalled. This on a 2 GB machine (used to be 4 GB, but never mind that now) with something like 800 MB free at time of click.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Super gameboy color?

Post by lidnariq »

Yeah, pdf.js is a pig.

I know why they did it - existing PDF readers just had too abominable of a security record - but still.
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Super gameboy color?

Post by 93143 »

Anyway, my idea was that if you're willing to accept black top and bottom borders, a Super Game Boy Color should be possible.

...

If the maximum colour count is 64 or lower, the image can be represented in 6bpp. A 6bpp 160x144 display is 17280 bytes. One NTSC frame affords (262-144)x165.5 = 19529 bytes worth of DMA time to VRAM. This leaves plenty of room for overhead and miscellaneous tasks such as controller state reading/forwarding. The SNES-side driver can't be especially heavy, though, because as we will see later, the rest of the frame is pretty much booked solid.

The SNES doesn't natively support 6bpp, of course. But if I'm not mistaken, the VRAM port is flexible enough that it's possible to efficiently fill 3/4 of an 8bpp tileset with 6bpp graphics, as long as you have full control over the source data format:

Take bitplanes 0, 2, 4, and 5 (NES-style, but with 4 bitplanes instead of two) and transfer them to VMDATAL. Then change VMAIN to increment by 32 words and do 16 DMA transfers to VMDATAH, one for each sliver of bitplanes 1 and 3 (32 words is one 8bpp tile, so a single 8-bit transfer can fill in one byte in every tile). It's slightly more involved than full 8bpp, but nowhere near the overhead of transferring 360 6bpp tiles individually...

Alternately, if a fully contiguous palette is desired, 24 16-bit DMA transfers to VMDATAL/H with 32-word incrementing should do the job, at the cost of some additional overhead.

...

Changing the full palette every scanline is a bit tricky, but I think it can be done by using a variant of the technique I used for DMA direct colour with stable columns. This should allow a full CGB palette to be uploaded to CGRAM every scanline without disturbing the image. However, it does take most of the scanline, and needs either timed code (using the rest of the scanline) or an H-IRQ (requiring the CPU to be idle to prevent excessive jitter) so CPU time is very limited when using this method.

To avoid artifacting due to the palette update overlapping active display, a double-buffering technique would be used in CGRAM, whereby one scanline would be displayed using one 64-colour palette while the DMA updated a second 64-colour palette. The scanlines could easily be made to alternate between palettes by alternating rows of zeros and ones in one of the unused bitplanes in the 8bpp tileset we're writing 6bpp to.

I believe it may be feasible to include 128-colour border graphics on either side of the main display as well. The lack of a second 8bpp layer on SNES may complicate the palette DMA slightly due to colour #0 behaviour with 4bpp layers, but as long as HBlank is wide enough for at least 17 colours (and in principle it should be), everything should fit without pillarboxing. There may be room for a vertical border too, but any more than about a tile's worth of height (4 scanlines on top and 4 on the bottom?) risks stepping on the main VRAM DMA...

...

Thoughts?
Shonumi
Posts: 342
Joined: Sun Jan 26, 2014 9:31 am

Re: Super gameboy color?

Post by Shonumi »

93143 wrote: Thu Nov 05, 2020 5:03 am I mean, if you're curious... I'm not that desperate. It's just an idea, and if it'll probably work that's good enough for me at the moment.
I'm actually on vacation this week, so I don't have much else to do at the moment. Besides, feels good to do some Game Boy assembly coding once in a while :wink:

At any rate, it didn't take long to whip up a simple test. I can confirm that you cannot write to GBC palettes during Mode 3. Furthermore, writes are essentially ignored. They don't seem to cause garbage values to overwrite the palettes, no black palettes either. Tested on a GBC and GBA. I've attached the test ROM and what probably counts for source code (I use my own handmade assembler).

If you press A, the code will try to write palette data when it detects Mode 3 for each scanline. The idea is to change it from blue to red. On certain emulators (notably my own and others like Mednafen) you'll see this change because they don't care about when the palette changes occur. On real hardware, the screen never turns red.
Attachments
gbc_mid.txt
(7.7 KiB) Downloaded 173 times
gbc_mid.gb
(32 KiB) Downloaded 179 times
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Super gameboy color?

Post by 93143 »

Excellent (for my purposes). Good to know.

I tried it in higan v110 and the screen is blue. (EDIT: That was me not paying attention. If I map a controller and press A, I see the change. Apparently higan doesn't accurately emulate this.) Since I don't own a GBC, and I don't have a flash cart for my GBA, I can't test on real hardware, but since you did already that's not especially important.

It seems my fundamental assumption above holds, and 6bpp should be sufficient for all use cases. I wonder what calima was thinking of - a GBA demo, perhaps?
Last edited by 93143 on Mon May 03, 2021 7:13 pm, edited 1 time in total.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Super gameboy color?

Post by Bregalad »

93143 wrote: Sat Nov 07, 2020 2:10 am Since I don't own a GBC, and I don't have a flash cart for my GBA, I can't test on real hardware, but since you did already that's not especially important.
Just saying, a GBA flash card can only test GBA programs, it is useless when it comes to using the GB/C mode of the GBA hardware as far as I know.
Useless, lumbering half-wits don't scare us.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Super gameboy color?

Post by calima »

No, I'm sure it wasn't GBA. And yeah, you need a GB(C) flashcart to run those programs, there is a physical switch and different voltage. GBA everdrive uses a GBC emulator to launch those roms.
Post Reply