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.
stan423321
Posts: 43
Joined: Wed Sep 09, 2020 3:08 am

Re: Plausible period MSU1 specs?

Post by stan423321 » Fri Mar 12, 2021 1:07 am

lidnariq wrote:
Thu Mar 11, 2021 4:17 pm
I don't think I understand what you mean by "access patterns". Would you say more?
Well, if it's worth your time, gladly.
  • Data reader would presumably write to a continuous range of addresses in device RAM. This naturally results in alternating between odd and even addresses.
  • 5A22 has four types of memory access "types": instruction fetches, other 65816 core operations, DMA and HDMA.
  • Instruction fetches mostly alternate between the address types, because similarly to data reader they're accessed contiguously, however there are multiple exceptions, like TAX causing repeat reads, and jumps likely not being "parity-aligned".
  • Other core CPU operations (loads, stores, vector fetches) alternate between address types if they're longer than 8-bit, because, once again, they're contiguous within those tiny blocks. 8-bit operations can go wherever they want though. However, the instruction stream is also getting cycles in between those. The set of opcodes that can make a memory access and also jump seems to be limited to block copy and block initialize.
  • Regular DMA either accesses the main bus continuously or repeats accesses to one address. It also stops instruction fetches and regular accesses.
  • HDMA has channels and interleaves them, which complicates things, but it also seems like it takes breaks.
And yeah, if you had way faster RAM available cheaply enough, that's needlessly complicated. Although if you wanted to throw in another CPU...

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

Re: Plausible period MSU1 specs?

Post by lidnariq » Fri Mar 12, 2021 1:48 am

93143 wrote:
Fri Mar 12, 2021 12:12 am
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)?
Yes... but hidden refresh might be easier enough to make it not worth the extra logic to use it.

For RAMs or access speeds that require explicit refresh cycles (as opposed to just operating in the lower bandwidth and higher power hidden refresh mode), you need to go through each row at least once every X milliseconds. The contemporary KM44C1000 (1Mx4bit) has a refresh period of 16ms and 1024 rows, so an explicit refresh cycle needs to happen at 62kHz. If I remember what I read elsewhere, the REFRESH pin is asserted 5 times every hsync, for a total rate of 78kHz, so ... that would technically work.

No memory of how much a 1M 30-pin SIMM cost at the time, though.
I thought I remembered seeing MiniDisc recordings from my mom that brickwalled at half the expected value for Red Book... oh well...
Could well, the ATRAC1 encoder was quite early. I think I read that it cannibalized from the higher frequencies to encode the lower ones.
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...
Yeah. The only publicly released MD-Data drive ( http://www.minidisc.org/part_Sony_MDH-10.html ) says 150KB/s, 140MB, the same 320KB buffer we saw for anti-skip mechanism... it's really just not that compelling relative to a CD.

And I guess Sony, owners of MiniDisc, chose CDs for the PS1, so maybe it really just wasn't the right choice without battery life or rewritability as a constraint.
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?
Yes, that's what I was suggesting. Mostly I'm thinking this because of how simple it is, not because it's particularly usable. Simple patches include having two RAMs, and the S-CPU swaps them as a pair.

---

Oh, I had another crazy idea. Maybe some kind of videocassette.

Original VHS (1979) is probably not good enough to support the necessary data rate (commonly cited luma resolution of 333 x 480 @ 30Hz = 4.8MSa/sec, but an abominable noise floor of 4-5 bits) but S-VHS is both old enough (1987) relative to the SNES and improves on the bandwidth (but not noise floor) by just enough to mayybe be able to carry the necessary 21.5Mbit/sec.

On the other hand, the Alesis ADAT machine was released in 1992, carried 8 channels of 48kHz 16-bit audio (6Mbit/sec), and ran a S-VHS cassette at 3x real-time (2Mbit/sec normalized), so maybe this really is a stretch.

Much later D-VHS / D-Theater (1998) cassettes and machines carry MPEG-1 streams at 28MBit/sec, so it's not too outlandish.

Maybe the problem is just the FM modulation of the luma signal on the videocassette in the first place, and D-VHS fixes that.

Anyway, the interesting thing about this particular crazy idea is you get both an audio stream and a full-bandwidth DMA channel at the same time, but they're strictly coupled. The control channel on the cassette should make seeking easy ... although still much slower than discs.

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

Re: Plausible period MSU1 specs?

Post by 93143 » Sat Mar 13, 2021 12:35 am

lidnariq wrote:
Fri Mar 12, 2021 1:48 am
[tape]
I hadn't thought of that. A semi-custom tape solution might have actually worked. ADAT doesn't quite sustain the necessary data rate as it stands, but it's closer than a 2x CD-ROM drive.

But the seek time! Legend has it the first man to test this device is still waiting for the Data Busy bit to clear...

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

Re: Plausible period MSU1 specs?

Post by stan423321 » Sat Mar 13, 2021 8:47 am

You cannot loop a tape and also roll it up, can you?

Hojo_Norem
Posts: 131
Joined: Mon Apr 16, 2007 10:07 am
Contact:

Re: Plausible period MSU1 specs?

Post by Hojo_Norem » Sat Mar 13, 2021 10:21 am

stan423321 wrote:
Sat Mar 13, 2021 8:47 am
You cannot loop a tape and also roll it up, can you?
Yep - https://en.wikipedia.org/wiki/Endless_tape_cartridge with one notable example being the Sinclair ZX Microdrive.
Insert witty sig. here...

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 » Sat Mar 13, 2021 1:12 pm

creaothceann wrote:
Thu Mar 11, 2021 4:41 am
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...
So... roughly, yes?.
93143 wrote:
Fri Mar 12, 2021 12:12 am
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...)
Apparently, they did (to think in adding 128KB of vram).

Well, and always it can be added an super fx in a cartidge despite having one as ppu3... the thing is if an super fx as ppu3 can alter the tiles in vram to scale and rotate, or even do some calculations for the cpu (if not directly, at least through a ram in the cartridge, and them directly to the WRAM for be read by the cpu).

...or send tiles compressed, and to use the super fx/ppu3 to decompress right there. It could have been interesting... so sad thar the ppu1 multipliers can be used like that (for obvious reasons).

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

Re: Plausible period MSU1 specs?

Post by creaothceann » Tue Mar 16, 2021 9:18 am

93143 wrote:
Sat Mar 13, 2021 12:35 am
lidnariq wrote:
Fri Mar 12, 2021 1:48 am
[tape]
I hadn't thought of that. A semi-custom tape solution might have actually worked. ADAT doesn't quite sustain the necessary data rate as it stands, but it's closer than a 2x CD-ROM drive.

But the seek time! Legend has it the first man to test this device is still waiting for the Data Busy bit to clear...
recent relevant video
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

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

Re: Plausible period MSU1 specs?

Post by lidnariq » Tue Mar 16, 2021 1:11 pm

LGR's video on the Danmere Backer VHS backup system is a better reference. Unfortunately, that only stores 64 bits per scanline, or roughly 1Mbit/sec. The later ArVid products at least got more than twice that on the same grade of VHS.

That said, I was actually inspired by Techmoan's video on D-Theater.
edit: or, come to think of it, Technics's SV-P100 or Sony's PCM-F1 from 1981, which record stereo 14 or 16bps 44056Hz (NTSC÷81.25) making 1.2-1.4Mbit/sec.

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

Re: Plausible period MSU1 specs?

Post by 93143 » Fri Mar 19, 2021 2:38 pm

Yeah, D-VHS does look like it meets or beats the requirements (since the MSU1 standard doesn't specify a maximum seek time). Came out in 1998. Would Nintendo have been able to make up that gap by themselves in the early '90s if they really wanted to?

Hmm. Surfin' Wikipedia...

DDS2 offered 4 GB of capacity in 1993. But the data rate was not high. It wasn't until DAT-72 in 2003 that a DDS-lineage tape drive offered enough speed to feed SNES DMA. LTO is a bit new (came out in 2000). Travan is too new and couldn't sustain the data rate until 2002. AIT-1 could sustain the data rate in 1996, but that's still too new and the tape capacity was way overkill for MSU1; the same could be said of VXA-1 but more so (1999, even larger capacity). A Data8 Mammoth could meet MSU1 specs in 1996 as well, and on what was essentially an audio cassette - actually, the only thing missing from the 1987 EXB-8200 is the transfer rate... DLT hits the capacity mark in 1991 and the data rate in 1996. The IBM 3490E is a bit of an outlier; it could do far beyond the necessary data rate in 1991 with an 800 MB capacity, and in 1992 was advertised with a 2.4 GB capacity with hardware compression (not sure how well that plays with the random access requirement). IBM's successor line, Magstar, came on the scene in 1995, too late for our purposes.

Those are pro-grade dedicated bulk data tape solutions. It looks like there was nothing off the shelf in 1992-93 that would have met the full MSU1 specs - certainly not for cheap - but it seems that the technology evolution in this space was much less tightly clustered than in more mainstream computing components, so a focused development program might have been able to come up with something.

It's an interesting concept, but I still think the latency would be impractically high. Apparently in 1995, IBM came up with the idea of rewinding the tape to the midpoint to cut peak access time in half. I can't imagine there's much more that could be done beyond that, other than just brute-forcing matters with higher data densities and mechanical seek speeds...

This game engine I've been brainstorming would probably have to be very careful about clustering sprite data and dispatching seek requests up to 16 or even 32 scanlines early, just to deal with the slow access time of the high-speed SD cards used in the FXPak. Might need a large RAM cache on the A bus, which is ugly because it adds another DMA stage to get the data into GPRAM, and you have to dodge HDMA if you want to move data outside VBlank. I'm not sure a tape drive would be able to support Super Road Blaster, let alone my idea...

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

Re: Plausible period MSU1 specs?

Post by lidnariq » Fri Mar 19, 2021 2:55 pm

The DV format is a bit earlier (1995), and also supports a high enough bitrate (28MBit/sec). Looks like it's roughly MJPEG on tape.

Regardless, seek time is still the constraint.

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

Re: Plausible period MSU1 specs?

Post by 93143 » Fri Mar 19, 2021 4:01 pm

I mean, if you want to just go with the actual spec, and ignore hacks and homebrews that use it (they didn't exist in 1993 either, after all), then tape is actually pretty promising. It looks like it might be able to meet both the capacity and the data rate specifications with a basically consumer-grade storage medium, and I'm pretty sure there is no MSU1 seek time spec - just a register you have to read to make sure the seek bit is clear before you try to DMA.

This would restrict MSU1 mainly to streaming applications with no fast branches, such as FMV playback. But "streaming" is in the name, and I'm sure a creative programmer could do a fair bit with it.

Anyway, this isn't intended to lead to an actual attempt to mass-produce a hardware MSU1 with early '90s storage technology. Doing that, especially while also supporting existing MSU1 games, would probably require an unreasonable amount of R&D for what is essentially a fun thought experiment...

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

Re: Plausible period MSU1 specs?

Post by lidnariq » Fri Mar 19, 2021 4:09 pm

I do like the idea of making an emulated version of the MSU1 - maybe call it the MSU0 or something appropriately pithy - that enforces these goofy constraints, like seconds (for some realism) to minutes (for sadistic realism) of seek time and sharing the access pointer between the audio and DMA channels.

Post Reply