Plausible period MSU1 specs?

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.
93143
Posts: 1344
Joined: Fri Jul 04, 2014 9:31 pm

Plausible period MSU1 specs?

Post by 93143 » Tue Mar 09, 2021 9:39 pm

We all know the MSU1 was designed to be a simplified modern take on the idea of a CD add-on for SNES. Something there are multiple period examples of, including an extant prototype of the Nintendo PlayStation and a tech sheet for the more powerful Nintendo Disc add-on.

But if we start with the MSU1 and try to get as close as possible to it with mid-'90s consumer technology, what do we end up with?

One thing jumps out immediately: the MSU1 can stream data and audio at the same time. That says two drives. One 1x, for music, and one 2x, for data. Expensive? Yeah... Could the music playback be done the way the Voicer-kun does it, with a universal infrared controller mounted on the unit (not on the second controller port, because MSU1 supports two-player mode)? Or are looping and resume important enough functionality that we need a custom drive with a substantial cache to cover maximal seek times? Half a megabyte should cover both features nicely if my calculations are correct (assuming a 1.4 second max seek time, the same as the Nintendo Disc)...

The MSU1's data side can feed DMA. A CD can't; it's not close - at least, not with the drive speeds that were being used in game consoles in the '90s. So what we need is cache RAM. You can't be having the SNES CPU tied up pulling data at 300 KB/s. It should be able to issue a cache request, have the data loaded into the cache, and then receive the all-clear to blast the result into VRAM, or up to the Super FX, or wherever else. (Unfortunately this requires that the data request include a size; you can't just keep DMAing indefinitely once the seek is done like the existing MSU1 spec says you can.) The Nintendo Disc had about one and a half MB of RAM in it, but it also had a big fancy coprocessor the MSU1 doesn't need - what do we think about 2 MB of cache RAM, the same as the Playstation, Saturn, and PC Engine Arcade Card? Dual-ported, so the CD can dump data while the SNES is copying a different chunk? Or should a SNES access simply interrupt the transfer from the L1 drive cache to the main cache, forcing the disc to stop reading if the main cache is tied up for too long?

Speaking of the Super FX, the MSU1 is fully capable of existing in parallel with a cartridge of pretty much any design. Yet it's accessed through the A bus. This suggests, as I believe its creator has noted, a pass-through device, in the spirit of the 32X. Putting two disc drives on top of a SNES could be bulky, but I suppose you could use an independent drive unit attached to the passthrough cart by a cable. Alternately, you could have a cradle-style unit like the Satellaview, but cabled to a passthrough unit, or simply to a port featured by compatible cartridges, rather than plugged into the B bus. With two CD drives, it might want its own power cable...

If one wished to stretch the era a little, a 10x CD-ROM drive could feed DMA continuously and would have been available in mid-1996 as a premium product for PCs. A 2x DVD-ROM would be capable of the same feat, with the bonus of supporting the full 4 GB address space. But the DVD format didn't even hit Japan until November of 1996, so a 2x DVD-ROM drive during the SNES era is kinda pushing the plausibility envelope.

...

I started thinking about this when considering the possibility of a 3D open-world Super FX game engine. Using sprites for hundreds of unique characters in 3D is prohibitive on a cartridge without heavy compression and major fidelity sacrifices, and for... reasons, I chose to go the opposite direction. And I noted that when I got to a plausible balance of resolution and frame count given all the constraints and desired features, it looked an awful lot like something you'd want a CD for.

The obvious solution was the MSU1. I had been fully prepared to tap it as an ersatz bankswitching chip to handle a few extra megabytes, but a few hundred megabytes of easily-available ROM destroys any pretense of authenticity. So I started thinking about simulating latency and transfer speed to pretend the MSU1 was a CD-ROM drive, and how much cache RAM could support how many unique low-frame background NPCs and how fast 300 KB/s could load the extra frames necessary for an activated NPC, and, well, here we are...

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

Re: Plausible period MSU1 specs?

Post by Gilbert » Tue Mar 09, 2021 11:24 pm

tl;dr
(Actually not that the contents aren't interesting; It is just that I have no knowledge in hardware and probably couldn't understand a thing.)

I think one problem could be power consumption. MSU1 is more like a cartridge mapper right?
Modern electronics could do a lot with very little power compared to 2+ decades ago.
If it's supposed to be on cartridge normal consensus is it can work with only the power supplied by the console's cartridge slot (if it's an add on like CD unit or the FDS or the 32x it's okay to supply it with extra power source), which could limit a lot on what could be done in that period.

lidnariq
Posts: 10463
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Plausible period MSU1 specs?

Post by lidnariq » Wed Mar 10, 2021 12:13 am

93143 wrote:
Tue Mar 09, 2021 9:39 pm
Or are looping and resume important enough functionality that we need a custom drive with a substantial cache to cover maximal seek times?
I don't think caching the gap was seen as realistic at the time; neither the SegaCD nor CD-ROM² could. Apparently the first portable CD players with enough cache to cover multiple seconds of gap only came out in 1995.

Maybe Minidisc is a better model. Minidisc players have always had some amount of Electronic Skip Protection, but ATRAC is compressed. I think they have dramatically better seek times too.
what do we think about 2 MB of cache RAM, the same as the Playstation, Saturn, and PC Engine Arcade Card? Dual-ported, so the CD can dump data while the SNES is copying a different chunk? Or should a SNES access simply interrupt the transfer from the L1 drive cache to the main cache, forcing the disc to stop reading if the main cache is tied up for too long?
Getting RAM fast enough to multiplex fake dual-port access would have been fine in 1992, but I still think a model more like the CX-4 is more probable. (Specifically: the SNES explicitly hands exclusive access to the DMA unit)

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

Re: Plausible period MSU1 specs?

Post by Señor Ventura » Wed Mar 10, 2021 7:07 am

93143 wrote:
Tue Mar 09, 2021 9:39 pm
If one wished to stretch the era a little...
My favourite topic xD

What could have been the best snes possible in 1990 (1989 during its assembly)... What was the best 65816 possible in 1989?, What amount of VRAM could have been have?, What about the super fx as PPU3?...

Really the snes doesn’t need too much changes to gain a lot of processing capability, other thing is the prices, but over all i wonder how it could have been worked, and specifically about two things:

1-DMA
2-super FX


If a 65816 at 3.58mhz work toghether with a WRAM at 3.58mhz, Do the DMA theoretically should work at 3.58mhz too?. If someone overclocks the WRAM at 3.58mhz, Could we see the DMA transferring 8.46KB per frame?, or the DMA is not limited by its pipeline, but it was designed like that in purpose... Where is the DMA physically located? (In the cpu, inside the pipeline?, in the PPU’s, outside the pipeline?, it could answer the question).

And about an hipothetical super FX as PPU3... Would it have been limited to work only with the VRAM, preventing the working with the cpu together? (It could be fix using a buffer from the cartridge... ROM -> VRAM -> super FX -> RAM in cartridge -> WRAM -> and at least WRAM, and then, CPU).

...or maybe an super fx as PPU3 could access VRAM and WRAM, Could the mainboard physically admit it?.

stan423321
Posts: 43
Joined: Wed Sep 09, 2020 3:08 am

Re: Plausible period MSU1 specs?

Post by stan423321 » Wed Mar 10, 2021 7:31 am

I'm thinking fake dual porting the RAM for the very specific purposes of SNES CD could have been feasible if someone had a really good idea on how 65816 core works, though I'm obviously no expert. My very unoriginal, PPU inspired idea is that a lot of memory accesses on SNES are more or less contiguous, so you could guarantee that every so often CPU will access an odd or even byte, so CD reader could access the other. That would be a bit slow if you only based it on two such banks and A-A0, but surely with a bit more sophisticated observations and programming rules one could do better?

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

Re: Plausible period MSU1 specs?

Post by creaothceann » Wed Mar 10, 2021 7:59 am

Señor Ventura wrote:
Wed Mar 10, 2021 7:07 am
Where is the DMA physically located?
In the existing SNES the DMA engine is part of the 5A22 CPU.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

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

Re: Plausible period MSU1 specs?

Post by 93143 » Thu Mar 11, 2021 3:00 am

Gilbert wrote:
Tue Mar 09, 2021 11:24 pm
I think one problem could be power consumption. MSU1 is more like a cartridge mapper right?
Modern electronics could do a lot with very little power compared to 2+ decades ago.
If it's supposed to be on cartridge normal consensus is it can work with only the power supplied by the console's cartridge slot (if it's an add on like CD unit or the FDS or the 32x it's okay to supply it with extra power source), which could limit a lot on what could be done in that period.
I'm proposing a CD-based add-on, and I did mention it might need its own power cable.

I didn't think there was anything especially esoteric about my hardware speculations...

lidnariq wrote:
Wed Mar 10, 2021 12:13 am
I don't think caching the gap was seen as realistic at the time; neither the SegaCD nor CD-ROM² could. Apparently the first portable CD players with enough cache to cover multiple seconds of gap only came out in 1995.
Thanks for the historical perspective.

I know it's a substantial amount of memory, but it's not as much as the data drive has (and there is precedent for giving data drives that much memory). It's more a question of how badly you want it.

Would they have done it? I think it's unlikely they'd use two drives in the first place (history suggests they wouldn't, as none of their proposals did). But it's semi-reasonably possible and gets us closer to the MSU1 spec.
Maybe Minidisc is a better model. Minidisc players have always had some amount of Electronic Skip Protection, but ATRAC is compressed. I think they have dramatically better seek times too.
Interesting! I like that idea.

But isn't the quality noticeably lower? I believe Minidisc tops out at 22.05 kHz. Still, it might be a cheaper way to get looping and resume, and it might improve on the bulkiness of a twin-CD solution...

stan423321 wrote:
Wed Mar 10, 2021 7:31 am
I'm thinking fake dual porting the RAM for the very specific purposes of SNES CD could have been feasible if someone had a really good idea on how 65816 core works
The SA-1 worked that way. It simply slowed down when the SNES was accessing the same memory. For instance, normal BW-RAM read access speed was 5.37 MHz, but when the SNES (in Slow mode) accessed it, the SA-1's collision control circuit would delay its own access by one cycle, resulting in an effective access speed of 2.68 MHz for both processors. I believe this is pretty much exactly the behaviour lidnariq was talking about.

This question is less about duplicating MSU1 functionality (we can't) and more about figuring out how much we can get with this too-slow early '90s solution. Explicit finite-size cache requests are already out of spec...

...

Actually, it occurs to me that the real MSU1 spec includes a hiccup for my game engine design plan. It allows for a finite seek time before any data access. A DVD-ROM has actually been suggested as an implementation option, and such a design could result in multi-frame seek times for random accesses. Even an SD card could take several scanlines to cough up the requested data. It would be fine for FMV (because the data would be sequential), but potentially very flaky for sprite animation. One might have to sacrifice a lot of potential ROM space to install a data cache in the cartridge.

I guess this is why it was called the Media Streaming Unit, and not the Anything You Want Random Access Unit...

If I were designing a modern hardware implementation, I'd probably go with a fully addressable solid-state solution for this reason. And considering how small and cheap multi-GB solid state memory units are nowadays, it might as well be a cartridge enhancement like the DSP-1 or Super FX, rather than a whole separate add-on unit like the 32X or Mega CD. Although since there is no single official MSU1 hardware solution, somebody could easily make a passthrough cart, and things could get weird if you plugged an MSU1-equipped cartridge into it... and a game that relied on essentially zero seek time would break or perform poorly on the FXPak/SD2SNES...

Señor Ventura wrote:
Wed Mar 10, 2021 7:07 am
super fx as PPU3?
In 1991, if that was even possible, it would have meant 10.74 MHz max, and very restricted working memory (or else extending the hamfisted "sharing" of the Super FX's ROM and RAM to the entire cartridge bus, unless Nintendo went back to the NES paradigm of having a whole separate cartridge bus for the PPU). It would also have seriously skewed the expectations for what a SNES game was; the market would have looked very different.

I like the idea of using whatever trick Hudson did to run the HuC6280 at 7.16 MHz. A 65c816 at that speed would have been a beast. Even SlowROM would be good for 5 MHz if it weren't for the half-cycle bus behaviour inherited from the 6502...
Last edited by 93143 on Thu Mar 11, 2021 4:09 am, edited 2 times in total.

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

Re: Plausible period MSU1 specs?

Post by Señor Ventura » Thu Mar 11, 2021 3:31 am

93143 wrote:
Thu Mar 11, 2021 3:00 am
In 1991, if that was even possible, it would have meant 10.74 MHz max, and very restricted working memory (or else extending the hamfisted "sharing" of the Super FX's ROM and RAM to the entire cartridge bus, unless Nintendo went back to the NES paradigm of having a whole separate cartridge bus for the PPU). It would also have seriously skewed the expectations for what a SNES game was; the market would have looked very different.

I like the idea of using whatever trick Hudson did to run the HuC6280 at 7.16 MHz. A 65c816 at that speed would have been a beast. Even SlowROM would be good for 5 MHz if it weren't for the half-cycle bus behaviour inherited from the 6502...
As far as i know, the first super fx in a cartridge was restricted from its capabilities, and not doblued after that in another games. Supossedly it was due a bug during its manufacturation, or something like that.

The super fx 2 is in fact the super fx, and the super fx 1 is in fact the half of that processor.


In what sense would have been skewed to have an super fx as ppu3?.

Having in mind that the DMA engine seems to be inside the 65816, Would an 3.58mhz WRAM change the DMA frequency at 3.58mhz too?.

And about the cpu, When was manufactured the first 65816 at 10mhz?, Which was the higer frequency for an 65816 in 1989/1990?.

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

Re: Plausible period MSU1 specs?

Post by creaothceann » Thu Mar 11, 2021 4:41 am

Señor Ventura wrote:
Thu Mar 11, 2021 3:31 am
the DMA engine seems to be inside the 65816
Nitpick: not inside the 65c816; the 65c816 is inside the 5A22, and the latter controls the timing of the 65c816 and implements all the $4xxx functionality.
Señor Ventura wrote:
Thu Mar 11, 2021 3:31 am
would an 3.58mhz WRAM change the DMA frequency at 3.58mhz too?
The $4000..$41FF address range is also slower (12 master clock cycles per CPU cycle), i.e. the input devices. But using DMA on that wouldn't make sense...
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

stan423321
Posts: 43
Joined: Wed Sep 09, 2020 3:08 am

Re: Plausible period MSU1 specs?

Post by stan423321 » Thu Mar 11, 2021 5:22 am

93143 wrote:
Thu Mar 11, 2021 3:00 am
The SA-1 worked that way. It simply slowed down when the SNES was accessing the same memory. For instance, normal BW-RAM read access speed was 5.37 MHz, but when the SNES (in Slow mode) accessed it, the SA-1's collision control circuit would delay its own access by one cycle, resulting in an effective access speed of 2.68 MHz for both processors. I believe this is pretty much exactly the behaviour lidnariq was talking about.
That does not sound like the same thing as my concept in detail, actually. What you're describing seems like a single bank with SA-1 trying to get out of 5A22's way.

lidnariq
Posts: 10463
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Plausible period MSU1 specs?

Post by lidnariq » Thu Mar 11, 2021 1:38 pm

93143 wrote:
Thu Mar 11, 2021 3:00 am
Interesting! I like that idea.

But isn't the quality noticeably lower? I believe Minidisc tops out at 22.05 kHz. Still, it might be a cheaper way to get looping and resume, and it might improve on the bulkiness of a twin-CD solution...
If I'm reading wikipedia correctly, it contains frequencies up to 22.05kHz, so Nyquist means the sample rate is the same as CDs. ATRAC1 Compression may throw away high frequencies in preference, however.

On the other hand, data rates may have been even more unsatisfactory; at slowest the drive might have been only 36.5kB/sec except that there's no point in having Electronic Skip Protection without a drive that's faster than the needed rate. The first MD player reportedly had 10 seconds of anti-skip buffer, or 365kB ... and the the first MD-Data drive ran at just about 1x CDROM speed.

lidnariq
Posts: 10463
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Plausible period MSU1 specs?

Post by lidnariq » Thu Mar 11, 2021 1:58 pm

stan423321 wrote:
Thu Mar 11, 2021 5:22 am
That does not sound like the same thing as my concept in detail, actually. What you're describing seems like a single bank with SA-1 trying to get out of 5A22's way.
Each S-CPU SlowROM cycle is divided into two halves; the first half is always for the SA-1, the second is either for the SA-1 or the S-CPU as needed.

stan423321
Posts: 43
Joined: Wed Sep 09, 2020 3:08 am

Re: Plausible period MSU1 specs?

Post by stan423321 » Thu Mar 11, 2021 3:56 pm

Right. So it uses time as the sole driver for collision prevention mechanism. The access patterns are completely ignored.

However, let's suppose you want to use slower RAM. It's cheaper or something. Well, if it's still cheaper when you buy twice as many half-sized banks, you can arrange them like SNES PPU did. One bank for odd addresses, one for even ones. This is all you need for the data reader to not disrupt the CPU at all until it gets so fast that it starts influencing your RAM bank choices anyway. DVD x1 is something like 1.3 MiB/s, so it's safe to assume our hypothetical time correct data reader would be way below 1.84 MiB/s.

In that situation, maybe all you need is two bytes of buffer for data reader plus four (3 for address, 1 for value) for CPU read repeats. Based on my basic understanding of 5A22, I'm pretty sure that once you remove repeat reads out of the equation, 5A22 shouldn't spend something like 6 cycles accessing odd addressed bytes only (or even). Long DMA flips, instruction fetches flip, long data reads flip... HDMA is what I'm not too sure about.

lidnariq
Posts: 10463
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Plausible period MSU1 specs?

Post by lidnariq » Thu Mar 11, 2021 4:17 pm

stan423321 wrote:
Thu Mar 11, 2021 3:56 pm
Right. So it uses time as the sole driver for collision prevention mechanism. The access patterns are completely ignored.
I don't think I understand what you mean by "access patterns". Would you say more?

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

Re: Plausible period MSU1 specs?

Post by 93143 » Fri Mar 12, 2021 12:12 am

stan423321 wrote:
Thu Mar 11, 2021 5:22 am
That does not sound like the same thing as my concept in detail, actually. What you're describing seems like a single bank with SA-1 trying to get out of 5A22's way.
Sorry, I must've glazed over before I got to the end. It was late at night. Serves me right for complaining about Gilbert's tl;dr...

Anyway, what I described is at least functionally the same as your idea, except probably more robust, and I believe it matches what lidnariq suggested. Trying to guess when an access is coming is bad news IMO unless you can do it perfectly, because the SNES doesn't do wait states, so any unexpected access is going to happen when the S-CPU decides it's going to happen, whether you want it to or not. But if you simply wait for accesses and get out of the way when they happen, you should be fine no matter what.

Perfect interleaving isn't really possible for any length of time unless you're talking about bulk DMA exclusively. The SNES decides how long to spend on a cycle depending on where it's accessing, so if you blindly assume it's a constant 2.68 MHz (or 3.58 MHz) you'll get out of sync quick. So the interleaved-access scheme probably requires a collision control circuit like the SA-1. Also note that the address range the MSU1 ports are in is considered Fast...

Perhaps one could specify in the programming manual that the SNES is only allowed to access the cache RAM port via DMA, and then have the device snoop writes to the DMA registers to reliably predict SNES accesses (once the DMA starts, at least; there's some tricky-to-predict timing jitter between the $420B write and the actual start of the transfer). If I understand correctly, this should allow perfect interleaving with a 5.4 MHz-capable RAM. The SNES shipped with what appears to be at least a 5.4 MHz-capable WRAM in 1991 as a cost-saving measure, so this shouldn't break the bank.

Might it be possible to use DRAM to save money, and use the REFRESH pin on the cartridge slot to sync the refresh cycle with the SNES (so you aren't trying to refresh at random times while the SNES is trying to read data)?

lidnariq wrote:
Thu Mar 11, 2021 1:38 pm
If I'm reading wikipedia correctly, it contains frequencies up to 22.05kHz, so Nyquist
Right. (Note to self: if it's a choice between making a large post on a technical topic and going to sleep, maybe seriously consider the latter...)

I thought I remembered seeing MiniDisc recordings from my mom that brickwalled at half the expected value for Red Book... oh well...
On the other hand, data rates may have been even more unsatisfactory
Yeah, I don't know about using MiniDisc for the data side. That seems like a job for a CD at minimum. Apparently data MiniDiscs could only hold 140 MB until the high-capacity spec came out in 1997...
lidnariq wrote:
Wed Mar 10, 2021 12:13 am
I still think a model more like the CX-4 is more probable. (Specifically: the SNES explicitly hands exclusive access to the DMA unit)
I've glanced over some CX4 documentation and I can't figure out what you're talking about. Are you suggesting the SNES should agree to be locked out of the cache RAM during the entire disc read operation?

Señor Ventura wrote:
Thu Mar 11, 2021 3:31 am
In what sense would have been skewed to have an super fx as ppu3?.
Developers would have felt a lot of market pressure to make games that used it. In actual practice, games that used the Super FX were almost all polygonal 3D games; the only one that was just a mildly enhanced normal SNES game was Yoshi's Island. I'm not saying developers wouldn't have gotten more creative over time if the chip had been available by default, but it would certainly have affected their design decisions.

And let's be honest here - SNES 2D is great, and Super FX 3D is not so great. It's actually possible that the console's library would have aged more poorly if the Super FX had been built in.

(Considering that it's actually not the easiest thing in the world to combine Mode 7 and a Super FX framebuffer due to limited VRAM, one wonders if Nintendo might have decided to expand the VRAM to 128 KB...)

Post Reply