Direct link:
https://docs.google.com/file/d/0B4cc2TZ ... dr/previewSomething 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.)
byuu wrote:
Direct link:
https://docs.google.com/file/d/0B4cc2TZ ... dr/previewSomething 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).
byuu wrote:
* 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.
Quote:
* 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.
Quote:
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.
> 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.
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).
I liked that one line, "Many people assumed CD games are slow." Many people are right!
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.
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.
tepples wrote:
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 ; - )
byuu wrote:
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.
nocash wrote:
tepples wrote:
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.
byuu wrote:
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.
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... :|
Well, Nintendo Power did already publish about half of the info in this leak, such as what "HANDS" means.
> 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.
byuu wrote:
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.
Your understanding is correct. A address bus, B address bus, shared data bus.
The problem here is that the expansion port only has the B address bus and data bus on it.
If you are trying to read data out of the expansion port, you are tying up the B bus. Thus, you are reading from it. Thus, you can't write to another B address at the same time.
The cartridge connector has both A and B on it, but that doesn't do you any good: you can't write to VRAM on the A bus, nor can you read from the expansion port on the A bus.
So the only way to do a DMA from something into VRAM directly is for that something to be on the A bus, which means it has to be a cartridge chip and not an expansion port chip.
But there's only one data bus. The only restriction is that the DMA unit drives the /RD and /WR lines for the A and B busses as complements. But if there's nothing to read from, or nothing to write to at that address, a peripheral could inject its own data / read from the bus at the time, regardless of what bus it's on.
And there's only one B address bus.
You cannot have a read address of $FF (from the expansion port) and a write address of $18 (to VRAM) on the same bus at the exact same time.
And a cartridge could decode a block of memory on the A bus and send it to the expansion port using the EXPAND pin, such that a device in the expansion port could know that the DMA unit is trying to read from a specific memory region of the A bus.
Ah, so ... the cartridge would see a read from $50:0000 (fixed DMA from 5000000/A to 2118/B), and set the expand pin. And for each memory clock tick, the expansion port device would write data onto the shared data bus even though it's supposed to be the cartridge doing it.
Neat. Seems like that EXPAND flag would have to be set really, really fast so you don't miss the first byte transferred.
At any rate, the solution still requires a cartridge and expansion port device working together. So it really doesn't buy you much. You may as well put the MSU1 in the cartridge at that point. If some hardware did use this EXPAND trick, it'd certainly be a fun change to support under emulation.
I really wanted this behavior straight out of the expansion port. Then it'd be possible to make an MSU1 base unit that could be used with any flash cart or copier device. Or even newly made cartridges. Downside there being: no support on SNES Jr or clone systems.
Yes, there are two address busses (A and B), and one data bus (shared for both A and B). The data bus is available on both cartridge and expansion port, so both could access it. The only restriction is that expansion port doesn't have have A-bus address lines.
So expansion hardware CAN access data bus on A-bus accesses, the only problem is that it CANNOT know WHEN it should do those accesses - unless one is doing the A-bus address decoding in the cartridge, and notifies the expansion about the decoding result via EXPAND line.
For example, with the existing hardware: The MAD-1 decodes A-bus addresses, and does output chip selects for SRAM, ROM1 and ROM2. So one could simply wire ROM2 to EXPAND pin (that should work, except... maybe one would need to OR it with /RD signal).
Of course, EXPAND is only one bit wide, so the expansion wouldn't know which byte within the ROM2 region is accessed, nor if it's a /RD or /WR access. But it's enough for a simple one-way data transmission from A-bus (expansion) to B-bus registers (VRAM, OAM, WRAM, etc).
Normally one would transfer data between snes and cartridge, or between snes and expansion. Transfer between expansion and cartridge should be working too - but I can't see what that would be good for (unless for very uncommon hardware setups), and of course such transfers would still require the snes to perform them as DMA transfers (so that the SNES CPU gets paused, and that the transferred data wouldn't collide with opcodes or other stuff on the databus).
From expansion to cart gets the data into the coprocessor's local memory.
nocash wrote:
For the 32bit cpu it's still unclear if it was the same as in PSX.
Allegedly it was the same CPU as in the Virtual Boy.