[demo] SNES Sonic
Moderator: Moderators
- LucianoTheWindowsFan
- Posts: 62
- Joined: Mon Jun 22, 2020 9:39 am
Re: [demo] SNES Sonic
Never knew the SNES had blast processing.
The SNES is my favorite console, not only because it is an upgrade to the NES, but because it had some quality games as well (e.g. EarthBound and Kirby's Dream Land 3).
Re: [demo] SNES Sonic
It doesn't need any. Sonic never used this actual feature, and neither did most Mega Drive games.
Last edited by Nikku4211 on Thu Oct 22, 2020 7:59 am, edited 1 time in total.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
Re: [demo] SNES Sonic
Yes it does. It just goes at half the speed of the MD version (or less if the MD is using H40 mode).
I'm assuming you're talking about "blasting" colours into CRAM via DMA. You can do that on SNES too. It's tricky, but you can actually display a fullscreen uncompressed 15-bit RGB image on SNES using DMA to CGRAM. The trouble is that while the MD's Fantom Bitmap mode looks just barely serviceable with doubled pixels (with a few extra-wide columns due to memory refresh), the SNES version's quadrupled pixels are just too wide. This is because the SNES uses an 8-bit data bus, so it isn't just VRAM DMA that's two pixels per byte, like on MD - it's everything. Fortunately, the SNES already has enough colour capability when used normally that a true-colour mode is less necessary.
Ironically enough, the SNES does have a CPU mode that runs faster than normal (FastROM), while the MD doesn't... although it's not really "blast processing" in any real sense because it's just setting a flag that says "don't bother waiting extra long for the ROM, because it's the expensive kind and can handle normal speed". The OP's Sonic prototype is using FastROM, if anyone's wondering...
I'm assuming you're talking about "blasting" colours into CRAM via DMA. You can do that on SNES too. It's tricky, but you can actually display a fullscreen uncompressed 15-bit RGB image on SNES using DMA to CGRAM. The trouble is that while the MD's Fantom Bitmap mode looks just barely serviceable with doubled pixels (with a few extra-wide columns due to memory refresh), the SNES version's quadrupled pixels are just too wide. This is because the SNES uses an 8-bit data bus, so it isn't just VRAM DMA that's two pixels per byte, like on MD - it's everything. Fortunately, the SNES already has enough colour capability when used normally that a true-colour mode is less necessary.
Ironically enough, the SNES does have a CPU mode that runs faster than normal (FastROM), while the MD doesn't... although it's not really "blast processing" in any real sense because it's just setting a flag that says "don't bother waiting extra long for the ROM, because it's the expensive kind and can handle normal speed". The OP's Sonic prototype is using FastROM, if anyone's wondering...
Re: [demo] SNES Sonic
I think by mentioning Blast Processing people are just being sarcastic and are not really serious about it, as that term can mean anything (or... nothing at all other than advertising jargon), so by saying Sonic MD didn't use Blast Processing is just something like "Sonic on MD is great achievement! And it didn't even need Blast Processing! Hehe!" (The 'Hehe' part is VERY important here.)
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: [demo] SNES Sonic
the SNES actually has a bitmap mode, its only 11bits but that is still better than an MD.
Re: [demo] SNES Sonic
True. But there are only a couple of ways someone knowledgeable could seriously claim the Mega Drive has "blast processing". The most common is the reference to "blasting" colours into CRAM, which is what Fantom Bitmap is based on.
Unfortunately three of those bits are per-tile, not per-pixel. They're taken from the palette selector bits in the tilemap. Per-pixel is 8-bit...Oziphantom wrote: ↑Wed Oct 21, 2020 10:48 pmthe SNES actually has a bitmap mode, its only 11bits but that is still better than an MD.
Re: [demo] SNES Sonic
I think that colour thing is a more recent interpretation though, considering probably near to no one would use these hacky tricks during the lifetime of the system (and every one knows that, without using tricks the MD plain sucksksks in its colour department).
Back in the days of the wars between company S and company N, I think the term usually meant the MD had "blast" processing speed (in more understandable wording, "faster"
Re: [demo] SNES Sonic
If you're talking about direct-colour mode, that's not a bitmap mode. You still have to use tiles there, and the tiles' graphics are actually 8-bit, the extra 3-bits only being set for each entire tile boundary.Oziphantom wrote: ↑Wed Oct 21, 2020 10:48 pm the SNES actually has a bitmap mode, its only 11bits but that is still better than an MD.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
Re: [demo] SNES Sonic
12-bit color is possible on the Super NES. Set up mode 3 with 8bpp RGB332 ("direct color") on 8bpp BG1 and the least significant 1 red, 1 green, and 2 blue bits on 4bpp BG2. Add them with color math. With 60 KiB of VRAM available for tiles at 96 bytes each, you'll be able to put 640 unique tiles on the screen, or 256x160 pixels if no tiles are repeated. This leaves no room for sprites, I'll admit.
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: [demo] SNES Sonic
Like this, I presume:
This would require the first 16 colors of CGRAM to be filled with all variations of 00xx0_000x0_000x0.
The lowest bits (0000y_0000y_0000y) could also be set for a tile-by-tile region, by filling half of CGRAM with a 00xxy_000xy_000xy pattern and using the tile palette index for the y bits...
Code: Select all
blue green red
--------------------------------
BG1 xx000 xxx00 xxx00 (all tile palette indices set to zero)
BG2 00xx0 000x0 000x0
The lowest bits (0000y_0000y_0000y) could also be set for a tile-by-tile region, by filling half of CGRAM with a 00xxy_000xy_000xy pattern and using the tile palette index for the y bits...
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
- Señor Ventura
- Posts: 233
- Joined: Sat Aug 20, 2016 3:58 am
Re: [demo] SNES Sonic
tepples wrote: ↑Thu Oct 22, 2020 6:28 pm 12-bit color is possible on the Super NES. Set up mode 3 with 8bpp RGB332 ("direct color") on 8bpp BG1 and the least significant 1 red, 1 green, and 2 blue bits on 4bpp BG2. Add them with color math. With 60 KiB of VRAM available for tiles at 96 bytes each, you'll be able to put 640 unique tiles on the screen, or 256x160 pixels if no tiles are repeated. This leaves no room for sprites, I'll admit.
So, if you repeat enough the pattern, Could it be possible with 45KB, and have space for sprites?.
4096 colors in one plane, and sprites?.
Re: [demo] SNES Sonic
45 KiB at 96 bytes per tile would mean 480 distinct tiles. This is still more than you get on NES, plus you can flip them (if the art style allows).
Re: [demo] SNES Sonic
Yeah, especially if your shading looks convincing even when symmetric, successfully avoiding pillow shading.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
- Señor Ventura
- Posts: 233
- Joined: Sat Aug 20, 2016 3:58 am
Re: [demo] SNES Sonic
I still don't get how could show off 4096 colors. One background for rpg's or vertical shoot em ups must be seen like a playstation title.
One question about the initial design of the vram, May 128KB double the bandwidth in this architecture?.
Re: [demo] SNES Sonic
On SNES? No. The SNES uses two VRAM chips, but can only write to one of them at a time. The MD, by contrast, uses one VRAM chip, and can write to both of them at the same time. This is why the SNES and MD both had the potential to double VRAM DMA throughput with a design tweak.Señor Ventura wrote: ↑Sat Oct 24, 2020 11:37 amOne question about the initial design of the vram, May 128KB double the bandwidth in this architecture?.
To upgrade the MD to 16-bit VRAM DMA (doubling the bandwidth), you would have to add another VRAM chip, so the full width of the bus could be utilized. So the 128 KB upgrade on MD does double the bandwidth.
To upgrade the SNES to 16-bit VRAM DMA (doubling the bandwidth), you would have to widen the CPU's external data bus to 16-bit (a tad fiddly with a 65816-based chip, but possible), so that VMDATAL and VMDATAH could be written simultaneously by the DMA unit. Doubling the size of each VRAM chip to 64 KB (for 128 KB total) would increase the available VRAM, but would not change how fast data could be written to it.
...
If you're talking about PPU rendering bandwidth, also no, but more emphatically. That would require a complete redesign of the PPU, and perhaps the use of four VRAM chips instead of two.