SNES CD-ROM question

This thread should be for hardware-oriented folks (hoping for byuu, nocash, and lidnariq at a minimum). I apologise for the length of this post in advance.

I want to establish something up front: I tend to take articles written by Kotaku with a grain of salt. So while that article outlines mostly the business side of things, and seem plausible, what I feel is overlooked is a more important technical "fact" that I'd like to discuss here. In that article, the following is stated:


The SNES CD-ROM peripheral was intended to be connected to the console via the SNES expansion port. There may have been a related cartridge that could come with something (fine/great, and yes I'm aware that pin 2 on the cart connector is connected to pin 24 on the expansion port), but regardless...

I am not concerned with the audio capability (ex. Redbook, CDXA, etc.), as it's doable since the SNES expansion port has 3 pins for audio "overlay/mixing" (mono, left, and right).

What I take issue with is that the SNES does not really seem capable of full-motion 30fps video as described.

I want to review the facts and specs as I understand them. Some of what I know comes from people who I PERSONALLY know who worked in the industry doing commercial SNES games at the time (1993 onward; and I can name names/companies if validity is needed) told me specifically that the SNES CD-ROM peripheral failed because, and I quote, "the SNES was never designed for full-motion video playback" (they didn't specify framerate, but let's assume 30fps to be fair), and I've always believed these people (read: no reason to believe they'd lie).

Thus, I ask hardware folks to please correct me if I'm wrong in the below (I certainly could be). I'm basing this mostly on the official block diagram from Nintendo (I won't post pictures of it, you all know where to find this) and some other sources:

PPU1 / 5C77 is what handles PPU RAM access and essentially handles all the "tile-based" math/logic. It has access to:

- CPU data bus (CD0-7)
- Main B-bus (addressing PA0-7, control /PARD + /PAWR)
- Two dedicated busses for PPU RAM:
-- VRAM Bus Control (VAA0-13, VAB0-13, VA14) + /VRD + /VAWR + /VBWR
-- VRAM Data Bus (VDA0-VDA7 and VDB0-VDB7)

PPU2 / 5C78 is mainly the "video output" IC. It has access to:

- CPU data bus (CD0-7)
- Main B-bus (addressing PA0-7, control /PARD + /PAWR)
- Capability to reset PPU1
- Several dedicated busses for PPU RAM:
- Access to VRAM Data Bus (VDA0-VDA7 and VDB0-VDB7)
- Mainly outputs to video output circuitry (RGB, S-Video/composite, etc.). (Probably what's responsible for handling things like brightness control via $2100, colour add/sub screen, etc.)

One thing worth noting that does confuse me:

This pinout for PPU2 / 5C78 depicts pins 69-76 as EXT0-EX7 for "External Video Input" from the VRAM Data Bus, stating "High Byte; it is unclear why this is wired up to VRAM in the SNES". This doc gives thanks to nocash too. And yes, I know/recognise jwdonal, as he's a great forum member here responsible for his FPGA-based SNES that is pretty dang cool.

nocash's document states 69-76 SRAM EXT0-EXT7 (sram data upper 8bit) (shortcut with VDB0-VDB7). I'm a bit confused as to why that says "SRAM" and not "VRAM"; PPU1 does have some which say "SRAM" others which say "VRAM". This may be me simply misunderstanding what's being depicted (remember, I'm not a hardware guy).

SNES expansion connector (here's Anomie's version) show the following relevant pins:

- Main B-bus (addressing PA0-7, control /PARD + /PAWR)
- CPU data bus (CD0-7) -- Anomie's doc says "Data bus D0-D"; Nintendo's block diagram confirms it's the CPU data bus
- DOTCK -- for the PPU dot clock (~5.3MHz but with some oddity during HBlank)

So I could see the CPU data bus being used for MMIO register-related purposes. Makes sense. And DOTCK being used for some PPU synchronisation. Also makes sense. But I don't see how having access to the main B-bus would be able to, say, provide full-motion 30fps video considering that the data would have to be tile-based and still work within the existing limits of the SNES's clock speeds, etc...

I will ask a question while here: I've never quite understood mode 7's EXTBG, and nocash's document states "... the 8bit external input is simply shortcut with one half of the PPUs 16bit data bus. ... However, in BG Mode 7, it's receiving the same 8bit value as the current BG1 pixel - but, unlike BG1, with bit7 treated as priority bit (and only lower 7bit used as BG2 pixel color)." Could this be used for some kind of video playback source? I'm thinking not given the description, but I don't quite understand it.

As for the disc format... well, Nintendo implied it would be its own proprietary format "N-Disk". This may be different from the prototype/dev unit which just used standard CDs -- we'll never know. I'm trying to do the math of how much data this thing could pump out, but that math just turns up raw bytes, not including other kinds of overhead.

So... would the SNES CD be capable of doing full-motion (let's say 256x224 (NTSC) to keep it simple, or 512x448 if you want to get fancy) video any more than, say, a standard cartridge could? The B-bus access is 8-bit. I just don't see how it'd be possible.

Same goes for if the expansion unit could handle MPEG-1 itself through something like Video CDs. Worst-case scenario that would be 1150kbit/s (352x240 @ 30fps) + 224kbit/s (audio) = 1374kbit/s =~ 172kBytes/sec. Hence why when I read the Kotaku article, I took issue with the technical statements made there, because to me, it doesn't seem feasible.

It seems more like the SNES CD was intended to be truly an expansion add-on to offer, say, Redbook-like or CDXA-like audio capabilities (think: PCE/TG16 CD / Super CD), along with large graphical expansion capabilities given capacities of CDs (more than carts) at the time.

Thoughts/comments?

And thanks for taking the time to read this.

On the Genesis, Sonic 3D had an impressive 15fps intro, so maybe the SNES CD wouldn't even have needed 30fps to be considered a success.


VRAM is SRAM i.e. static RAM; it uses flip-flops (transistors) instead of capacitors and therefore doesn't require a refresh signal/period like WRAM.

Sonic CD into is just uncompressed data, both sound and video, completely pushing the CD drive's bandwidth. There's also lot of small clicks in sound due to buffer underruns on real hardware.

I don't think 30fps was anything that was a requirement or a sensible target, almost all full screen video was low frame rate stuff on other machines also. On Mega CD games that did full screen video also used compression on the video data to bring the bandwidth requirements down and possibly also VRAM transfer bandwidths.

I took the time to read it but I cannot give any hardware opinion about it ^^;;

I don't know how much it would have brought to the platform with the limitation of the actual hardware. CD audio is nice but the snes sound was good if done properly. I always hated those low framerate videos so I think I would have tried but not buy it.

FMV in Resident Evil 2 for Nintendo 64 is 15 fps. Most traditionally animated cartoons are 12 fps.

Let's try the specs of the Sonic 3D Blast intro: 240x80 pixels, 4bpp, 15 fps, using a blur technique to reduce dither artifacts and somewhat hide vertical stretching by a factor of 2. That's 9600 bytes per frame (small enough to double buffer) or 144 kB/s before compression. You'll need to fit audio into the stream as well, so you'll need some sort of compression for the video.

That connection is specifically why mode 7 EXTBG works, where the 128s bit divides the same plane into FG and BG layers. What's actually happening is the exact same data arrives via two different interfaces, and in mode 7 they just so happen to have the same encoding.

If I understand correctly, you can turn on EXTBG in other modes, too, but you get garbage because the data is not a remotely similar encoding.



In my opinion, your direct question has already been answered adequately by TµEE and tepples.

I think there were some MSU1 threads (here and/or on byuu's forum) about full-motion videos and their restrictions.

You can take it from me, it's more than capable of that.
Else, I wouldn't have been able to port a FMV game to the SNES (using byuu's MSU-1, but it could run from ROM (of considerable size) or the SNES CD aswell).

Ultimately, it's just a question of bandwidth (VRAM/CD) and how much you can compromise on picture quality.
Bad video quality didn't stop the Mega CD from happening.

I think we can assume with a high degree of certainty that the SNES CD was killed for political, not technical reasons.

EXT0-7 are for EXTBG mode. It's a special mode that most associate with mode 7, but actually works with any BG mode (just much less useful on BG0-6.)

The idea is that you'd have an external source feeding video into the SNES, for screen overlays of graphics.

Of course, the pins aren't connected to anything on the cartridge nor expansion ports, and so there would have been no way for the SNES PPU to use EXTBG mode. Only new hardware (Nintendo Super System, Super Famicom Box, Nintendo Gateway System) could have used EXTBG mode ... and yet, none of them did. They devised their own overlay systems instead.



The PPU uses static RAM chips, eg there is no refresh as with DRAM.

VRAM describes the usage, SRAM describes the implementation. It's much like how I call the SNES WRAM (work RAM) as DRAM, because it makes it clear what the CPU DRAM refresh pause each scanline is about.

...

Let's first consider what a stock SNES can do. For full motion video, your only practical option is mode 3, with 8bpp (256 color) images.

There are 1364 clock cycles per scanline. 40 clocks are lost to DRAM refresh. I'll use NTSC limitations here, since video only in Europe would be unlikely. So there are 262 scanlines per frame.

This gives us 1324*262 = 346888 clocks per frame. *60 = 20813280 clocks per second.
DMA is the fastest way to get memory to the SNES VRAM, and it needs 8 clocks per byte transferred.
So you have an absolute maximum of 43361 bytes per frame, or 2601660 bytes per second, that can be sent to the PPU.

However! You can't write to VRAM during active display. You are not required to have all 224 visible NTSC scanlines rendered, however. You can force blank along the top and bottom, creating a vertical letterboxing effect, to eke out more time. Similarly, you don't have to transfer data for the entire width of the screen, although you won't get that time back to write more data to VRAM, it will still reduce the number of pixels you must transfer per frame.

So let's say we choose 224x144 for our video. A far cry from fullscreen. 262-144=118 scanlines of V/force/blank. *1324/8=19529 bytes per frame can be sent via DMA to PPU VRAM. A 224*144 image takes 32256 bytes of data. So we cannot manage 60fps. But if we spend two frames to transfer each output frame, then we can send 39058 bytes per 30fps output frame ... and it fits! Hooray! 224x144x8bpp@30fps is doable.

And with a little extra bandwidth, so you can choose between: sending a unique 256-color palette per frame, or ekeing out a bit more resolution and using Mode 3's direct color option, which will give you RGB332.

You could also lower the framerate to 20fps and get a much larger video window output. You can do those calculations on your own using the above knowledge.

If you want to know the max PAL rate, use my calculations above, only PAL has 312 scanlines per frame and runs at 50hz instead.

Further pedantry: if you're okay with something like Bad Apple, you could do 2bpp (16 color) video, in which case, halve the amount of bytes required per frame. Not very impressive, but you could probably manage 256x224@20-30hz at that point, I think.

...

There is another limitation: the SNES expansion port is on the B-bus, as is VRAM. This means you cannot transfer from the expansion port into VRAM. As such, you need twice the time to transfer from expansion port to WRAM, cart SRAM, or some other location, and then to transfer that to VRAM. You could use the time during active display to do this, if you don't need any other CPU time for anything else.

...

Okay, now I'll dive into your question. The SNES-CD would have been, almost certainly, a 1X CD-ROM drive (150KB/s). But let's be generous and say it was a 2X CD-ROM drive (300KB/s).


150*1024=153600 bytes a second. 300*1024=307200 bytes per second. Divided by 30 for 30fps video, 2X gets you 10240 bytes per frame. It's barely more than half of what we need for even 224x144x8bpp@30fps. So the SNES CD could only muster, at best, 224x144x8bpp@15fps, and that's presuming Nintendo went with a luxurious for the time 2X CD-ROM drive.

However, one wouldn't have to send raw video, right?

The SNES CD could send you MPEG encoded data to the base cartridge, and the base cartridge could contain an MPEG decoder that would let you DMA the MPEG data into decompressed PPU VRAM data.

So if you were willing to sacrifice video quality to heavy compression and constrain the MPEG stream to 150KB/s (1X) or 300KB/s (2X), and include the MPEG decoder inside the cartridge instead of the base unit (remember: you can't transfer from the expansion port to VRAM), then your limitation would once again become ~224x144x8bpp@30fps.

...

I really can't imagine Nintendo packing a VCD card equivalent into the base cartridge, though. They were pricey and bulky, and the power draw from the cartridge port would probably be pushing it as well.

More than likely, most games would use animated sprites to mimic FMV, much like the original Lunar: Silver Star did on the Mega CD, before they had better video codecs for that (much more capable) system.

Just add another power adapter that feeds into the cartridge

But seriously, couldn't the expansion unit have some data decompressing hardware?

I've found a webpage saying that CDROM at single speed was invented in 1984, and double speed in 1992.
Maybe it was a huge step in technology to reach double speed... or maybe it was someway like this:
- So the CDROM drive you've developed is reading data at 150K/s, could it also read data at a faster rate?
- Of course it could do that, and yes, that's really a huge problem. But don't worry, our whole tech staff has spent the past eight years on making sure that it does never spin faster or slower than 150K/s - because that would totally screw up CDDA audio playback!

Anyways, the bios/chipset of the SNES CD prototype supports Double Speed, and the chipset supports MODE2/FORM2 with 914h-byte sectors, that allows 340Kbytes/s.
XA-ADPCM audio needs at least 1 sector per 32 sectors (mono, 18900Hz), so, with audio, that would leave up to 329Kbyte/s for video.
I would assume that the retail version was planned to support that, too.

The SNES PPU is fast enough to DMA a reasonable picture size at reasonable frame rate (going by above posts). The 8bit color depth might be a bit low for videos, easiest workaround would be dithering, and with some more efforts one could try to match the palette to the current movie scene.
Asides, PPU Mode 7 isn't just "256 colors". It's also "rotation/scaling". Eg. one could scale 128-pixel scanlines to full 256-pixel width (or whatever one wants, eg. 200-pixel to 256-pixel). Don't know if such full-width images would look better/worse than unscaled images with smaller width.

VCD hardware was released 1993 (a year after the SNES CD prototype, and a year before PSX, though even PSX did merely support MDEC, not VCD). Something like MDEC in SNES CD BIOS cart (or directly on the SNES CD expansion board) wouldn't be black magic. In fact, SNES games later did do such things with SPC7710 (1995) and S-DD1 (1996), and even a GIF decoder would be more than enough for SNES video streaming. I mean, the compression ratio doesn't matter too much: If the decompressed image is too large then it won't pass through PPU DMA.

I knew I should have mentioned that you could run a power source to the cartridge, because someone would mention it if I didn't. Ah well.

I definitely already explained why the base unit couldn't decompress though ...



Yes, but it limits you to 128x128 resolution, the scaling is affine (point-based, so blocky) and you also lose that force blank time to send more data. Not the best trade-off.

Thank you everyone for your responses! I actually found several posts to be very informative.

I had to exclude the MSU-1 example from the responses because that really wasn't something available at the time when this hardware was available. So while it makes what's described possible, I'm talking about without such expansion chips. It seems with expansion chips that could handle offloading, a lot more things become feasible. I didn't mention this in my initial post because I thought that would be implied from discussing the device in question and what was available at said time.

byuu and nocash's responses were actually the most helpful in me understanding what exactly could be achieved, and that's also working off the assumption that there was no additional hardware involved (ex. MPEG decoder IC, some kind of DSP that would translate from one format to another without the main CPU having to do it, etc.), and with the CD-ROMs limits (we're assuming 1x (150KByte/sec) even though the Kotaku article actually states it's 2x (300KB/s); nocash shed some light on this in his post too).

The 19529 bytes per frame limitation (for DMA to PPU RAM) is important. byuu's note of 224x144, 8-bit (mode 3) @ 15fps seems to be what could be possible given the bandwidth limitations (said phrase used both literally and generally here) of everything involved, without any expansion chips (cartridge-wise). But full-screen (256x224, 8-bit, @ 30fps) doesn't seem like a possibility without additional hardware.

Please note: this isn't something along the lines of "see the SNES sucks!" or other whatnots, it's more along the lines of trying to justify what I was told by actual commercial SNES game programmers *at the time*, re: why the CD expansion device never came to light. I had no reason to believe said people were lying to me given their roles and their pasts, but maybe what I was told was based on their own conclusions or assumptions.

It sounds like the device certainly could have been used for short FMV cutscenes between major events in a game, as well as (certainly) redbook-esque audio overlay (a la TurboCD).

I kept thinking back to Book of Ys 1 & 2, and Ys 3, recalling "didn't these have some FMV sequences?" My brain really thought they did, but I was having to go back nearly 30 years in memories to a system I didn't have and rarely saw (I had only one friend with a TG16/CD -- was just too expensive!). Review of YouTube videos showed me that no, Book of Ys 1 & 2 had no FMV (just Redbook audio (one of the best soundtracks of any video game ever) + ADPCM), while Ys 3 had similar, combined with several scenes that were meant to look like FMV but weren't (just good art/animation; the animation was limited to things like hair/eye/lip movement, so doable on a lot of systems with enough PPU RAM).

That said: there is one TurboCD game that does use what almost looks like FMV (though it looks more like captured motion video turned into lots of frames/tiles for animation, not actual full-screen video): something from NEC called It Came From The Desert. Certainly there were bandwidth limitations (it looks like 15fps or less, static backgrounds, and very limited palette). Seeing this immediately brings to mind all the aforementioned limits. (I was never very impressed with FMV of this sort, BTW; I always felt it worked better for stuff like cartoons or anime where a more "limited" palette was perfectly reasonable).

I guess another system to ponder in comparison would be the Sega CD (Night Trap comes to mind, haha).

Anyway I'm rambling. Thank you all for the insights, I appreciate it very much!

128x128 pixels is derived from 256 tiles limit in BG Mode 7? Yes, okay, that's right, BG Mode 3 would allow more tiles at same color depth.
On the other hand, 128x128 pixels would be 16Kbytes, and horizontal scaling to 256x128 pixels does't affect forced blank time.
With 329K/s from CDROM, that would allow 20fps, without needing any decompression hardware.

Shifting the image left/right one pixel at 60Hz rate could be used to produce less block scaling (though the flimmering might look more annoying than pleasing). 128 scanlines leaves some spare forced blank time, so one could also add vertical scaling (though I guess then it would start to look really ugly). Anyways, scaling is just one idea. A slightly smaller image, or a lower framerate might look much better. And best would be decompression.

There's nothing preventing decompression hardware in the base unit (aside from development time needed for rearranging the whole pcb layout). Bulky doesn't rule out anything, and cdrom data currently being on B-bus doesn't mean that they couldn't instead redirect that data to the decompression hardware.
Also SNES could do a DMA from some open-bus address to PPU, there's nothing preventing the base unit from outputting data upon PPU writes (as long as there's an I/O port for disabling that behaviour, so the CPU could also write to PPU without getting disturbed by the base unit).

Concerning power supply, I guess decompression won't require more power than DSP-1 and the like, or maybe even less power, especially if it's a simple decoder without multipliers (eg. GIF style, or some bloody RLU variant, maybe supporting compression of rows of same pixels, and rows of pixels with increasing/decreasing colors, it can use lossy compression, and the compression ratio doesn't need to be better than 50% for PPU DMA).

You got that wrong. MSU-1 is just a storage device (like CDROM).
Any kind of video decompression for it is plain software running on the SNES CPU without any special coprocessor hardware.
EDIT: Or well, MSU can be faster than CDROM, ie. it can transfer more data, without needing decompression for tnat.

300Kbyte/s is with error correction (eg. for program code).
340Kbyte/s is without error correction (eg. for audio/video streaming).

I mean 256x224x8bpp@30fps is just plainly impossible no matter how much hardware you throw at it. The only way you'll get that is with a 32X style link where the SNES video out goes into the add-on unit, and the add-on unit outputs its own video signal that super imposes one device onto the other.



The only thing that prevented something like the MSU1 existing in 1998 was that the cartridges would be the size and cost of Neo-Geo games. I don't think "marginally better audio quality and four minutes of cutscenes" would justify someone to pay $400 instead of $60 (in 1998 money) for a game ^^;



I mean, tricks like that are truly starting to abuse the hardware. But yeah, the 21fx actually hijacks $fffc,fffd vector reads and redirects it from the expansion port alone, so yes, it's technically possible. But it's really, really, really not supposed to be.

Given how little cpu Cinepak takes, it's conceivable an existing chip like SA-1 could decode that.

Just found this https://m.youtube.com/watch?v=oOowlcsADt4 FMV on a VIC-20. Its monochrome only though..

We were able to get this working on a C64 https://www.youtube.com/watch?v=2yG36ROGdYA its only 1/4 size and 15fps but its FMV

If you give a C64 a DMA engine then https://youtu.be/wNT3E1KGboU?t=105

Give this already exists https://youtu.be/Gm9lgIzjlK8?t=99 without the CD add on.

I would think given limits you could get movie playback. I mean you could even interlace the frames and use HDMA to pull the fields out such that each alternative line was in sequence in VRAM so you can DMA frame updates to a half per frame. You would keep the screen map static so you just have to update 32x14 = 448 tiles, at 16 colour mode is still 14K if my maths is right... which would take about 2 frames to transfer so you could do a field at 30fps, so a frame at 15fps. If you narrow the "fmv" then you might be able to get more, of if you make the alternative frame Scan Lines like C&C did then you can double the frame rate. Something like the 90s Anime style would probably delta compress really well as you would only need to handle the tiles that change in a frame which given the large areas of solid colour, is probably not that much for most frames.

The 2x2 pixel and 4x4 pixel blocks of Cinepak are more convenient to write out in a packed pixel format (like Sega Genesis) than a planar one (like Master System/Game Gear, Game Boy, and Super NES/TG16). How easily would SA1 cover the difference?

What if you used mode 7 to get packed pixels and then used the background scaling to handle the screen resolution / codebooks? You could, for example, scale the background down to use individual tiles as codebook entries, or something like that.

The SA-1 has a bitmap -> tiles conversion for "free" in its DMA controller. So you get the SA-1 to convert the Bitmap into tiles to WRAM then get the SNES DMA to pump it to VRAM.

On the c64/anime front, we already have the Pokemon anime intro for GBC, packed as tiles. The compressor is open source.

Given how the VIC-20's video mode works, I'm certain they could trivially change it to 96x160 4-color mode... they clearly already support changing the background color.

Life finds a way.

https://www.youtube.com/watch?v=19XdGJh6Znc

I'm sure the SNES with a PCE CDROM style attachment could do better.

Isn't the Super CD suppose to have the GSU2? That is able to make bitmap data and have the SNES throw it on screen?

I just want to correct a few things about SNES CD:
There are two of them, there's the Super Disc from Sony, the prototype that we ended up getting, which is just basically a regular double speed CD-ROM drive plugged to the EXT port alongside a BIOS cartridge.

Then there's the Philips one that adds the additional processing unit to it (estimated to be a NEC V810, same CPU as Virtual Boy because of cache size), and also, one detail that has been omitted to be mentioned here and I feel it's important: The drive is connected to the cartridge with a cable. That's in the specs, you can find it. Potentially could use both A-bus and B-bus.