[demo] SNES Sonic

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
LucianoTheWindowsFan
Posts: 59
Joined: Mon Jun 22, 2020 9:39 am

Re: [demo] SNES Sonic

Post by LucianoTheWindowsFan » Wed Oct 21, 2020 4:51 pm

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).

User avatar
Nikku4211
Posts: 400
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: [demo] SNES Sonic

Post by Nikku4211 » Wed Oct 21, 2020 6:20 pm

LucianoTheWindowsFan wrote:
Wed Oct 21, 2020 4:51 pm
Never knew the SNES had blast processing.
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.

93143
Posts: 1344
Joined: Fri Jul 04, 2014 9:31 pm

Re: [demo] SNES Sonic

Post by 93143 » Wed Oct 21, 2020 8:24 pm

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...

User avatar
Gilbert
Posts: 464
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: [demo] SNES Sonic

Post by Gilbert » Wed Oct 21, 2020 10:21 pm

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.)

Oziphantom
Posts: 1106
Joined: Tue Feb 07, 2017 2:03 am

Re: [demo] SNES Sonic

Post by Oziphantom » 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.

93143
Posts: 1344
Joined: Fri Jul 04, 2014 9:31 pm

Re: [demo] SNES Sonic

Post by 93143 » Thu Oct 22, 2020 1:55 am

Gilbert wrote:
Wed Oct 21, 2020 10:21 pm
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)
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.

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.
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...

User avatar
Gilbert
Posts: 464
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: [demo] SNES Sonic

Post by Gilbert » Thu Oct 22, 2020 2:17 am

93143 wrote:
Thu Oct 22, 2020 1:55 am
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.
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"; in actuality, company S led people to THINK the MD was always faster) so it could do whatever the big N-DON'T.

User avatar
Nikku4211
Posts: 400
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: [demo] SNES Sonic

Post by Nikku4211 » Thu Oct 22, 2020 8:05 am

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.
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.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

tepples
Posts: 22323
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: [demo] SNES Sonic

Post by tepples » 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.

creaothceann
Posts: 306
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: [demo] SNES Sonic

Post by creaothceann » Fri Oct 23, 2020 12:27 am

Like this, I presume:

Code: Select all

	blue	green	red
--------------------------------
BG1	xx000	xxx00	xxx00  (all tile palette indices set to zero)
BG2	00xx0	000x0	000x0
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...
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

User avatar
Señor Ventura
Posts: 183
Joined: Sat Aug 20, 2016 3:58 am

Re: [demo] SNES Sonic

Post by Señor Ventura » Sat Oct 24, 2020 11:04 am

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?.

tepples
Posts: 22323
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: [demo] SNES Sonic

Post by tepples » Sat Oct 24, 2020 11:06 am

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).

User avatar
Nikku4211
Posts: 400
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: [demo] SNES Sonic

Post by Nikku4211 » Sat Oct 24, 2020 11:32 am

tepples wrote:
Sat Oct 24, 2020 11:06 am
[...]plus you can flip them (if the art style allows).
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.

User avatar
Señor Ventura
Posts: 183
Joined: Sat Aug 20, 2016 3:58 am

Re: [demo] SNES Sonic

Post by Señor Ventura » Sat Oct 24, 2020 11:37 am

tepples wrote:
Sat Oct 24, 2020 11:06 am
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).
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?.

93143
Posts: 1344
Joined: Fri Jul 04, 2014 9:31 pm

Re: [demo] SNES Sonic

Post by 93143 » Sun Oct 25, 2020 10:43 pm

Señor Ventura wrote:
Sat Oct 24, 2020 11:37 am
One question about the initial design of the vram, May 128KB double the bandwidth in this architecture?.
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.

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.

Post Reply