How SuperFX assisted games displayed?

[johannesmutlu]

Wow thanks for mentioning this, now that’s what i call information.
But i got another question.
Since the snes bandwide is limited, it cannot stream 4bit graphics at full resolution at 60fps straight from the cartride.
However i do know that it can stream gameboy resolution at 2Bit graphics at 60fps straight from the cartride to the screen, aka supergameboy.
But i wonder if the snes is capable to also stream 4bit color graphics or 56 color graphics straight from the cartride to the screen.
I ask this because i was wondering if a gameboycolor addon for the snes is possible.
Also i was wondering if it is possible to mod the supergameboy’s rom with a new firmware or imagine a supergameboy 3 to allow sprites to have their own colors from the background to allow 10 colors at the same time on screen at 60fps.
However if the snes can’t even handle more then 2bit color graphics at gameboy resolution at 60fps straight from the cartride, then yes i can forget about such possibility.
Thanks alot

[Kannagi]

If we do a "forced blank" during the display, yes it is possible.
it will reduce the resolution of the SNES (there will be black bars), but there will be enough for 160x144

[tepples]

The Game Boy Color system on chip (SoC) does not produce a 6-bit stream of indices into the palette. It produces 15-bit output, with 5 bits of red, 5 bits of green, and 5 bits of blue, and a few sync signals, intended for the LCD. This means that instead of harvesting the SoC from a donor GBC system, you would need to reimplement everything in the SoC from scratch to emit separate streams of 6-bit palette indices (17280 bytes) and palette data (128 bytes).

Now assuming you are reimplementing the SoC:

At 165.5 bytes per line, it takes 105 lines to send 17280 bytes to video memory using DMA. If you blank all but 144 lines of the screen, you get about (261 - 144) = 117 lines. This fits, though there will need to be some rearrangement of data using less common VMAIN increment modes to skip bit planes 7 and 6 of each tile.

Many GBC games use the "hicolor" technique. This involves CRAMming a bunch of new colors into palette memory during the horizontal blanking period between each scanline and the next. If your reimplemented SoC's video output has only 56 colors, it may not be able to handle hicolor games. There may be some way to stream palette changes to the PPU using HDMA, though I guarantee nothing and can explain nothing about this.

[tokumaru]

This means that instead of harvesting the SoC from a donor GBC system, you would need to reimplement everything in the SoC from scratch to emit separate streams of 6-bit palette indices (17280 bytes) and palette data (128 bytes).

Or maybe you could have a middleman recompress the 15-bit image into indexed format, no?

[93143]

I thought about this a while back.

Basically, I think a Super Game Boy Color with full compatibility should be possible, using a variant of my SNES Fantom Bitmap technique to rewrite the entire CGB palette in one line. Shonumi says palette writes during active line rendering don't do anything, so a simple double buffering scheme with one unchanging palette every scanline should be adequate for all use cases. calima disagrees, but he can't remember any details, so...

[lidnariq]

my SNES Fantom Bitmap technique [...]
Shonumi says palette writes during active line rendering don't do anything,

Those two contradict each other - your Fantombitmap requires that palette writes during active line rendering set the color that's currently being drawn (in ... one of main/sub screen, I forget)

Oh, Shonumi was talking about palette writes on the CGB

[93143]

Oh, Shonumi was talking about palette writes on the CGB

Yeah, sorry about that. I could have worded that more clearly. He wrote a test ROM, and apparently when you try to write to the palette on a real Game Boy Color during Mode 3 (active pixel rendering), nothing happens. Which I take to mean that taking a snapshot of the palette state during Mode 3 for each line should be sufficient to fully reproduce the colour capabilities of the machine. It remains merely to somehow get that palette snapshot into CGRAM, which is where the hidden-layer DMA trick comes in.

Note that I have not actually tried this, and I probably should. The math says it should work...

[johannesmutlu]

So to wrap it all up, rendered gameboycolor graphics can be streamed through the cartride into the snes ppu chip at 60fps on screen.
BUT games wich do use hi-color mode cannot be viewed on the snes, but since only 3 games do make use of it such as alone in the dark, the new addams family and the fish files etc…
But since most gbc games don’t use that mode, we should be fine with such gameboycolor adaptor.
But if we really want to make those games ever work, we might just disable hi-color mode on those games.
But i really want to see it happen.
I can imagine myself to play the 8bit version of donkeykong country etc… on the snes that way just for the sake


And whose not dreaming about a nes,genesis and gba adaptor as well as a ps1 addon for the snes wich uses a costum chip to conver hi-color hi-res graphics down into 256 blended colors at 200x160 pixels at 30 mixed fps while hdmaing it’s streamed audio through the snes soundchip.
Just to be able to play and play and enjoy sll those games in a snes perspective.
Because that would be cool
It’s my wetdream wanna seeing come true.
Even if trade offs had to be made and even if you have to deal with stuttering or smearing frame rates with some input lag, it would be freaking damn cool just for the sake.
But as of now all those adaptors just cheatingly bypasses the snes hardware with their own av cables

[93143]

BUT games wich do use hi-color mode cannot be viewed on the snes

I don't think that's true. I haven't actually tested my proposed method, but the tricky part is the same as in a method that is confirmed working, so it should work. This method should be able to refresh the entire CGB palette every line without any visible artifacts, so "hi-color mode" should be no obstacle.

The only question then is whether calima was right about there being a Fantom Bitmap equivalent (that no games used) on CGB. It doesn't appear so, but I guess it's possible Shonumi overlooked something...

[Señor Ventura]

BUT games wich do use hi-color mode cannot be viewed on the snes

I don't think that's true. I haven't actually tested my proposed method, but the tricky part is the same as in a method that is confirmed working, so it should work. This method should be able to refresh the entire CGB palette every line without any visible artifacts, so "hi-color mode" should be no obstacle.

The only question then is whether calima was right about there being a Fantom Bitmap equivalent (that no games used) on CGB. It doesn't appear so, but I guess it's possible Shonumi overlooked something...

2 Bytes per pixel...

Maybe some things could be done trhough framebuffer, but normal graphic modes with direct color seems another story.

What are the possibilities?.

[93143]

The key is to recognize that my "DMA direct colour" demo isn't actually DMA direct colour. It's DMA nearly direct colour, because the colours make a short stop in CGRAM before being displayed.

The CGRAM address is controlled by the S-PPU during active rendering, so writes go to wherever the S-PPU was fetching a colour from at that moment. I discovered that the main and sub screen colours are always fetched on alternating half-dots regardless of whether they're visible or not. So I used a pickup pattern on an invisible BG layer on one screen to direct DMA writes to desired locations in CGRAM, and then displayed the data with a visible layer on the other screen. (Which layer is on main and which is on sub is actually dependent on CPU/PPU half-dot alignment, which is not consistent between boots on all machines but is easy to detect.) In principle, though, there's no reason why the display pattern needs to just display all the colours in the order they went in...

So what I proposed for the SGBC was a hidden 4bpp pickup layer, with an 8bpp display layer. The display layer would have 6 bitplanes written every frame, and one of the two otherwise-unused bitplanes would alternate between zeros and ones each line, allowing palette double-buffering in CGRAM. (This eliminates the insoluble race condition of trying to update the palette as it's being used when the display layer is full-res and unsorted, so the palette being written during a given line is actually the palette for the next line.) Transferring 6bpp into an 8bpp layer is a bit fiddly, but doable.

Now, 4bpp layers on SNES are not like BG layers on the CGB. The latter do actually use their zero colours. This means that there are no gaps in the bottom half of a CGB palette, so at first glance it looks like a 4bpp layer is inadequate (there are two zero colours that need to be written but can't be accessed via the pickup layer). To avoid the SGBC having to rearrange the palette indices in the source data, my plan was to start the palette DMA near the beginning of HBlank, so it gets in at least 17 colours before the bit depth of the pickup pattern becomes relevant. HBlank is more than wide enough for this, and since the palette DMA trick already requires jitter levels of a few pixels at most to work at all, this shouldn't be a failure point.

...

It should also be possible to make a video mode using this technique. Something similar to Mega Color, but with more colours changed every line.

[mannes]

Cool! I didn't know SNES is able to "blast process".
As far I know that colour trick when you are sending DMA directly to the background colour into CRAM gave the name: blast processing.
Unfortunately neither Sega Genesis/MD nor SNES can use it because of doubled or even quaternary pixels.
Sega could use it for some games or at least video playback but there is a bad thing:
because of the memory refresh you have about 5 (doubled) columns of quaternary pixels (each 64 pixels) and it looks like as the image zooms through a lens.
Even tolerant to double pixels games looks ugly with those zooming columns.
It's acceptable if the image doesn't change. But once image changes you see the zooming columns and it becomes unacceptable for usage.

So, my understanding was you could get 320x240 @ 30fps with a fully selectable 15bpp per pixel on the Mega Drive using this technique, is this not the case? Are the quadrants always there regardless?

The key is to recognize that my "DMA direct colour" demo isn't actually DMA direct colour. It's DMA nearly direct colour, because the colours make a short stop in CGRAM before being displayed.

The CGRAM address is controlled by the S-PPU during active rendering, so writes go to wherever the S-PPU was fetching a colour from at that moment. I discovered that the main and sub screen colours are always fetched on alternating half-dots regardless of whether they're visible or not.

...

It should also be possible to make a video mode using this technique. Something similar to Mega Color, but with more colours changed every line.

Is this possible in mode 5/6 or when pseudo hires is enabled? Is there any difference in pixel display quality using 512x448? Or are the dots just written twice like expected and end up being 8 pixels long instead of 4? I've been looking for a way to do a 16 color 512x448 display on the SNES that has an actual dot resolution of 512x448 instead of a inflated 256x224 resolution that technically outputs as 512x448.

[Señor Ventura]

The key is to recognize that my "DMA direct colour" demo isn't actually DMA direct colour. It's DMA nearly direct colour, because the colours make a short stop in CGRAM before being displayed.

The CGRAM address is controlled by the S-PPU during active rendering, so writes go to wherever the S-PPU was fetching a colour from at that moment. I discovered that the main and sub screen colours are always fetched on alternating half-dots regardless of whether they're visible or not. So I used a pickup pattern on an invisible BG layer on one screen to direct DMA writes to desired locations in CGRAM, and then displayed the data with a visible layer on the other screen. (Which layer is on main and which is on sub is actually dependent on CPU/PPU half-dot alignment, which is not consistent between boots on all machines but is easy to detect.) In principle, though, there's no reason why the display pattern needs to just display all the colours in the order they went in...

So what I proposed for the SGBC was a hidden 4bpp pickup layer, with an 8bpp display layer. The display layer would have 6 bitplanes written every frame, and one of the two otherwise-unused bitplanes would alternate between zeros and ones each line, allowing palette double-buffering in CGRAM. (This eliminates the insoluble race condition of trying to update the palette as it's being used when the display layer is full-res and unsorted, so the palette being written during a given line is actually the palette for the next line.) Transferring 6bpp into an 8bpp layer is a bit fiddly, but doable.

Now, 4bpp layers on SNES are not like BG layers on the CGB. The latter do actually use their zero colours. This means that there are no gaps in the bottom half of a CGB palette, so at first glance it looks like a 4bpp layer is inadequate (there are two zero colours that need to be written but can't be accessed via the pickup layer). To avoid the SGBC having to rearrange the palette indices in the source data, my plan was to start the palette DMA near the beginning of HBlank, so it gets in at least 17 colours before the bit depth of the pickup pattern becomes relevant. HBlank is more than wide enough for this, and since the palette DMA trick already requires jitter levels of a few pixels at most to work at all, this shouldn't be a failure point.

...

It should also be possible to make a video mode using this technique. Something similar to Mega Color, but with more colours changed every line.

I think i see what it is for...

If cgram is still there the oam still exists, so sprites are not eliminated.

And using the cgram as a color data pool you can iterate two or more pixels with the same color information without repeating the necessary 2 Bytes of the direct color mode, or "reserve" colors for a lot of pixels all along the screen saving these transferences too.

It will not be 32768 colors, but maybe 1000 colors could be for real, including sprites not limited to 128... What are your estimations?

[93143]

So, my understanding was you could get 320x240 @ 30fps with a fully selectable 15bpp per pixel on the Mega Drive using this technique, is this not the case?

That is not the case. You can do 60 fps with this technique, but (a) the pixels are always doubled horizontally, except the ones that are quadrupled because of refresh slots interrupting the DMA, and (b) the Mega Drive can only do 9-bit RGB.

Unlike the SNES version, Fantom Bitmap on the Mega Drive uses forced blank, so there's really nothing more you can do.

Is this possible in mode 5/6 or when pseudo hires is enabled? Is there any difference in pixel display quality using 512x448? Or are the dots just written twice like expected and end up being 8 pixels long instead of 4?

The 512-wide modes on SNES use the main and sub screens to display alternating half-dots. This means my invisible-layer trick is incompatible with it.

The DMA unit on the SNES does not speed up in high-resolution mode, so the output pixels would be the same width. On top of that, if you're using hires, you can't use the invisible-layer trick, so you can see the layer the DMA is writing to. And the DMA unit's timing alignment behaviour means you cannot get straight columns - best case, the trigger point is late (or early) by one dot every other scanline, and this pattern oscillates. Also, you have to mess up the data format to prebuffer the DRAM refresh, since those colours now have to be written during HBlank. Basically, hires mode makes DMA direct colour worse for no benefit.

You could use a luminance mask to do lossy full-res (256-wide) video using DMA actually-direct colour (plus DRAM refresh prebuffering) as a slightly jiggly chroma layer. But high-res won't work because the doubled resolution and the subtractive blend both need the same hardware and thus cannot coexist. Interlace would technically work, but that's putting an awful lot of stress on the luminance mask update bandwidth if you want actual video...

I've been looking for a way to do a 16 color 512x448 display on the SNES that has an actual dot resolution of 512x448 instead of a inflated 256x224 resolution that technically outputs as 512x448.

You can easily do true multipalette 4bpp (so, 121-colour) 512x448i (not 448p) on SNES, with either Mode 5/6 or (if you know what you're doing) pseudo-hires. It's called "pseudo-hires" not because it isn't real hires, but because it's not specifically hires; you can do other things like pseudo-transparency with it because the even and odd "half-dots" (really just half-width pixels) are from different layers and are not scroll-locked to one another like they are in Modes 5/6.

Mind you, displaying fullscreen video at that resolution is totally impossible because there's not enough VRAM. But a game (or a carefully constructed fullscreen image) that uses repeated and/or flipped tiles to stay under VRAM limits is no problem. Heavily letterboxed/windowboxed video could work too.

512-wide tends to not be super sharp on real hardware because the signal path between the S-PPU and the screen of a CRT TV causes significant horizontal blur and chroma artifacting. (This is why "pseudo-hires" kinda works as a blend mode.) It's got nothing to do with being 'fake' hires.

If cgram is still there the oam still exists, so sprites are not eliminated.

I'm afraid I can't make out what you're trying to say here.

And using the cgram as a color data pool you can iterate two or more pixels with the same color information without repeating the necessary 2 Bytes of the direct color mode

Yes, that's the idea.

or "reserve" colors for a lot of pixels all along the screen saving these transferences too.

Oddly enough, not really. Schemes based around this idea tend to max out their bandwidth just transferring a 6bpp image, or a larger multipalette 4bpp image, and because of the palette double buffering, even the latter can't really use any extra colours. You can pretty much fill a quarter of CGRAM with one line of DMA, and that's how much you can use with the graphics you've got time to transfer. And there's not much point saving time on the CGRAM DMA transfers, because the timing requirement is so tight that you can't really use the CPU time saved anyway.

It's true that sprites are still available, and their half of CGRAM is totally independent of what's going on with the BG layers, so in that sense... yeah, I guess... There's not much room to update the sprite graphics, though...

In principle you could do 7bpp at 30 fps, so as to reserve half of CGRAM as constant colours instead of sprite colours. But you'd only be able to access half the reserved colours on any given line because of the double buffering scheme, and the window size would not be great by SNES standards. Better than the Game Boy, but at half the frame rate, and if you're not playing a Game Boy game there are better ways to use the SNES...

It will not be 32768 colors, but maybe 1000 colors could be for real, including sprites not limited to 128... What are your estimations?

Again, what are you talking about?

I'm talking about a method of taking a hardware-rendered image with hard limits of 56 colours per line and 40 sprites, and encoding it in a format the SNES can display. This involves all the sprites being rendered down into the single 6bpp layer, so the Super Game Boy Color doesn't use SNES sprites at all.

I mentioned the possibility of a video mode using a similar technique, but that would probably be unsuitable for real-time rendering even on a modern PC because of the colour quantization and attribute optimization necessary. This is not a software rendering technique.

You also can't do palette expansion of hardware sprites this way, because you can't linescroll sprites, so there's no way to double buffer sprite palettes.

...

If you must know, the Super Game Boy Color would max out a little below 3000 colours, because the CGB can only change about 20 colours per scanline. The SGBC display method can do 8064 colours, but I'm pretty sure the CGB itself can't achieve that in practice.

The Mega Color-like video mode I alluded to should max out at 11712 colours for a 192-line display, but I wouldn't expect it to ever really get near that. My original DMA direct colour demo was capable of 14336 colours (one per pixel at 64x224), but the highest I've ever actually seen was 10139 colours; most images at that resolution and RGB depth use a lot less.

1000 colours is not hard. We've done that by just changing up to 8 colours per scanline with HDMA. Again, though, that's not a real-time video codec...


...


Hey, I just thought of something silly. A Super Game Boy 3, or a Super Game Boy Color in DMG mode, could have a mode where it writes the 2bpp framebuffer into an 8bpp layer, cycling through the four bitplane pairs every four frames, while also cycling CGRAM through a four-frame pattern, to emulate the slow LCD the original Game Boy used...

But would that be enough? How slow was the original DMG screen?

[Señor Ventura]

Hey, I just thought of something silly. A Super Game Boy 3, or a Super Game Boy Color in DMG mode, could have a mode where it writes the 2bpp framebuffer into an 8bpp layer, cycling through the four bitplane pairs every four frames, while also cycling CGRAM through a four-frame pattern, to emulate the slow LCD the original Game Boy used...

But would that be enough? How slow was the original DMG screen?

I don't know if i'm understanding well... Do you want to draw a 4 color tile into a 64 color attribute to add/substract colors starting from the original graphic to simulate... ghosting, maybe?...

Lately i've been thinking some ideas too... unafordable, in fact, but always has to be a beginning...

A single 8bpp with 64 different pixels, and update the cram with different color information to draw the graphics without transfering the entire tile every time... always is the same tile repeated, but with different color position within with every one. I have some solutions, and could be so interesting to keep a lot of bandwith achieving large animations

And still thinking about improved scenarios in art of fighting 1 & 2... 256 tiles pool, and from the 32th scanline update about 10 new tiles every scanline updating the tile attribute (not the tile itself, since all the possible variations are already stored in vram). The key is to fill 45KB of tiles in vram, and point to them when needed.


P.D: i will not forget to answer the rest of the post, i'm a littke bit busy right now...