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.