Kotaku unveils snes cd-rom tech specs from Nintendo docs

[lint]

http://kotaku.com/the-specs-of-a-ninten ... 1522494626

Enjoy the reading ...

[Near]

Direct link:
https://docs.google.com/file/d/0B4cc2TZ ... dr/preview

Something I've never seen before. Unfortunately very little technical info. We get the RAM sizes, a note that the CD-decoder is a 6502 @ 4MHz with some bitmap conversion and sound table functions. And unfortunately no word on what the 32-bit RISC ISA would be.

Thoughts:
* only 1MB of RAM for the actual game to have available in the base cart. Would have enforced a lot more load screens.
* the CD case was going to contain SRAM ... no memory cards or internal memory management. If only Sony had done this.
* latency of ~1s to start an audio track. Can't read data during audio playback (no surprise.)

[magno]

Direct link:
https://docs.google.com/file/d/0B4cc2TZ ... dr/preview

Something I've never seen before. Unfortunately very little technical info. We get the RAM sizes, a note that the CD-decoder is a 6502 @ 4MHz with some bitmap conversion and sound table functions. And unfortunately no word on what the 32-bit RISC ISA would be.

Thoughts:
* only 1MB of RAM for the actual game to have available in the base cart. Would have enforced a lot more load screens.
* the CD case was going to contain SRAM ... no memory cards or internal memory management. If only Sony had done this.
* latency of ~1s to start an audio track. Can't read data during audio playback (no surprise.)

I was about to post those specs right now

What do you think about no direct connection from SNES CD-ROM unit and B-BUS, byuu? I guess it would be the SNES 65C816 CPU which had to read from PSRAM to send data to VRAM, right? It seems the 32-bit RISC CPU couldn't stream data to VRAM nor APU-RAM, so it would run as a "simple" co-processor (9basicly, the same functions that SA-1, S-DD1, DSP-x all together).

[tepples]

* only 1MB of RAM for the actual game to have available in the base cart. Would have enforced a lot more load screens.

It's more than the TGCD Super System Card and almost as much as the Sega CD. Nintendo has always been fast about loading, and 1 MB with a single-speed drive would have limited load times to about seven seconds. I can think of some cart games that took longer than that to load, such as anything by Micronics for NES or The Lord of the Rings for Super NES. Even Super Mario Bros. for NES takes a few seconds to show what might nowadays be confused with a loading screen before each level. Besides, the "real-time file read" allows loading sequences to be interleaved with XA music, which could be used well for animating each level's intro sequence.

* the CD case was going to contain SRAM ... no memory cards or internal memory management. If only Sony had done this.

That would have meant no ability to bring saves from your rental copy of a game to the copy you end up buying.

latency of ~1s to start an audio track. Can't read data during audio playback (no surprise.)

I guess that's why PlayStation implements XA music streaming based on some sort of ADPCM flavor, which could switch back and forth between filling the audio buffer and reading files. But the PS1's double-speed CD drive helps with that.

[Near]

> What do you think about no direct connection from SNES CD-ROM unit and B-BUS, byuu?

I think it's weird that they'd have a base unit sitting there and *not* connect it to the B-bus. Running a cable between cart and base unit is certainly more flexible, but just very clumsy looking and unprofessional. Perhaps they already had the long-term goal of eliminating that connector (as they ultimately did with the SNES Jr.)

Initially, they probably envisioned an add-on that would just have CD audio playback and data reading. With a game distributed as cart+music/FMV-CD, you could even optionally sell SNES-CD games with fallback support for people without the CD attachment (degraded audio, cutscenes, like Pier Solar.) Self-booting and ROM size wouldn't be issues here. But the costs for the carts would still be very high. Although they'd save money on having simple CDs instead of fancy CD-cases with CICs and SRAM.

The B-bus however makes absolutely no sense for a system meant to run a game from an entirely different, non-cartridge medium. With the CD design they ended up on, I'm betting they wished the B-bus was a base unit<>cartridge bus completely separate from the SNES CPU.

From my own MSU1 perspective ... the major problem with the B-bus is that the PPU sits there, too. This is essential for the SNES to DMA to VRAM. But it means you can't DMA between the expansion port device and the PPU. A dumb copy has to be made to SNES WRAM first. That means having lots of free buffer WRAM on a constrained system, and cutting your throughput in half, again on a constrained system.

Given the only designs they ever ended up actually producing (Satellaview) and designing (SNES-CD), they should have put the entire cartridge connector on the bottom (or side) instead, with a male connector instead of card-edge. If a cartridge is inserted, that runs. Otherwise, the base unit runs. That would have worked for both the SNES-CD and Satellaview, and would not have required the BIOS cartridge. The full-pin male connector probably would have cost the same as the reduced-pin card-edge connector.

> It seems the 32-bit RISC CPU couldn't stream data to VRAM nor APU-RAM, so it would run as a "simple" co-processor (9basicly, the same functions that SA-1, S-DD1, DSP-x all together)

That is correct. It'd just be another coprocessor design. But with so much hardware, and such a limited base system ... that at that point, it really was smarter to just throw in a video chip, remove the cartridge, and make the SNES-CD its own system entirely.

> Nintendo has always been fast about loading, and 1 MB with a single-speed drive would have limited load times to about seven seconds.

Think of the 6MB Tales of Phantasia. And how much it'd suck waiting seven seconds to leave the town, to enter and exit random encounters, etc.

> That would have meant no ability to bring saves from your rental copy of a game to the copy you end up buying.

That would have been good news for Sony and Nintendo, who fought violently against the rental industry. They even had some success in Japan.

Also welcome to me personally, as I don't rent games. But yes, detrimental to those who did and then decided to buy the games later.

[tepples]

The alternative to rental was arcades, and I seem to remember some arcade games supporting PlayStation arcade memory cards to share data between an arcade game and its console tie-in (e.g. F-Zero AX vs. GX or the "link data" support in Dance Dance Revolution).

[mikejmoffitt]

I liked that one line, "Many people assumed CD games are slow." Many people are right!

[tepples]

CD games wouldn't be so slow if some publisher had had the 42'd to take Namco to court to get its Galaga-during-loading patent struck down with the prior art known as Invade-a-Load.

[nocash]

Interesting to see those specs in english. Before that, I've only seen some brief summary of the snes cdrom features yet (released in german for some strange reason). The new docs don't reveal much more info. Half of the doc is about snes-unrelated details like explaining that cdroms are round discs ; - )

For the 32bit cpu it's still unclear if it was the same as in PSX. And pretty much nothing about video. There should have been at least some bitmap to bitplane conversion stuff as in other SNES coprocessors. Ideally it could have had the same GPU/GTE polygon rendering hardware as used in PSX.

CD games wouldn't be so slow if some publisher had had the 42'd to take Namco to court to get its Galaga-during-loading patent struck down with the prior art known as Invade-a-Load.

There's a patent for doing something during loading? Tomb Raider games are using a progress-bar-during-loading, maybe Namco charged patent fees for that ; - )

you can't DMA between the expansion port device and the PPU.

Actually, the SNES could do that. One would only need a tiny A-bus address decoding circuit in the cartridge, and forward a data request signal to expansion hardware via EXPAND pin.

[tepples]

CD games wouldn't be so slow if some publisher had had the 42'd to take Namco to court to get its Galaga-during-loading patent struck down with the prior art known as Invade-a-Load.

There's a patent for doing something during loading?

Compare Invade-a-Load for C64 to Namco's US Patent 5,718,632.

[MottZilla]

Thoughts:
* only 1MB of RAM for the actual game to have available in the base cart. Would have enforced a lot more load screens.
* the CD case was going to contain SRAM ... no memory cards or internal memory management. If only Sony had done this.
* latency of ~1s to start an audio track. Can't read data during audio playback (no surprise.)

The PC-Engine did alot with just 256KB of RAM, and had some quite impressive games with the 2MB Arcade Card. I think 1MB would have been enough. Personally I think PC-Engine was the only one to the the CD-ROM add-on right. Pretty much just adding CD as a storage medium and being able to play CD audio. It did add I think an ADPCM sound channel too. But that sounds simpler and cheaper compared to the Mega CD or what the SNES CD was envisioned as.

[koitsu]

Where is Steve Lin getting all this shit and why hasn't Nintendo's legal dept. hauled his ass into court by now? Consider me pissed off based on what I went through with Nintendo back in the mid-90s over my snestech docs... :|

[tepples]

Well, Nintendo Power did already publish about half of the info in this leak, such as what "HANDS" means.

[Near]

> Actually, the SNES could do that. One would only need a tiny A-bus address decoding circuit in the cartridge, and forward a data request signal to expansion hardware via EXPAND pin.

I'm not a hardware guy ... my understanding was that EXPAND was just a pin connection between the expansion port and the cartridge connector with nothing else on it and no magic to it.

So to me, the expansion port would send a byte over the B-bus, and the cartridge could read it. But now how would the cartridge write that byte back to the B-bus VRAM address? Especially during a DMA transfer that is constantly asserting the B-bus address lines to send the data?

The best you can do, in my opinion, is send all of the data from B-bus to something on the A-bus via DMA. And then DMA all of that data back to the B-bus. I don't see any way you can read from and write to the B-bus (from $21ff, let's say, to $2118) in the same cycle.

> Where is Steve Lin getting all this shit and why hasn't Nintendo's legal dept. hauled his ass into court by now? Consider me pissed off based on what I went through with Nintendo back in the mid-90s over my snestech docs... :|

Would you mind elaborating on your interactions with Nintendo? Perhaps in PM (I won't repeat it) if needed? I'm very interested in this.

[lidnariq]

The best you can do, in my opinion, is send all of the data from B-bus to something on the A-bus via DMA. And then DMA all of that data back to the B-bus. I don't see any way you can read from and write to the B-bus (from $21ff, let's say, to $2118) in the same cycle.

If I understand correctly: in the SNES, there's one address bus and control lines for A, one address bus and control lines for B, and one data bus shared between the two of them. That one can only transfer from the A bus to the B bus or vice versa is because the DMA unit drives an address on each bus and then tells one to read and the other to write.

Am I right?

If so, then you can inject an arbitrary device onto either bus as long as there's a section of memory into which it could be mapped; e.g. if the cartridge explicitly left a gap of open bus in the memory map, it could use the EXPAND pin to tell the peripheral to write data to the data bus when the DMA unit was trying to read from the A bus at that address.