I envision the first version to be as cheap as possible:
- CD-ROM unit for playing music, output to 3.5mm and mix via audio splitter. Our device would just be a proxy for sending playback commands to it. Like a remote control.
- SD card or flash chip for streaming ROM data.
- separate power source or leech off the SNES, either way.
- don't include an actual CD drive with the system, just the connector and an empty slot.
- build it with veroboard if we have to.
So you're designing the functionality of this mass storage device and leaving it up to anyone who would design a hardware version to determine what medium to use and make sure it works with your API?
The capabilities will be based on the version number, and the version number will be based on what we can actually do with the hardware itself.
In other words, the first emulator release will be as restrictive as possible: no writing, one audio track only, seek delays and a max 512MB range. Once a hardware device actually exists, we'll see what it can do. If it can write, then we'll still use version 1, but allow it to write and update the emulator to match the hardware. If not, we leave it at that.
If someone comes along in the future who simply must have write capability, then he can add it and produce new hardware using a new medium, and we can call that version 2. That will still be fully compatible with version 1 hardware.
Although ideally I don't want more than one version of hardware, I'll leave it open for the sake of creating an actual device.
It would be neat to see multiple incarnations of mass storage devices using the same API and being able to play the same homebrew creations, even with some differing capabilities.
Indeed that is a possibility. I would be more happy though if the different mediums shared the same capabilities, the only differences being that SD would probably have lower latencies for getting the data and audio streams ready.
So would this design mean that there would be no DMA from mass storage to memory on A-BUS? And with Flash or CD-ROM would you just be writing something like a sector number or block number you want to read or possibly write?
You would have to stream DMA to WRAM. Set a fixed-mode transfer from $21f1 to $7e8000+, and dump your data there. Now you can move it to video or whatever. It's annoying doing it twice to get data to video RAM, but because you're otherwise idle during active display, there's way more than enough time for even smkdan's video example.
Again I don't like it, but avoiding it would rule out the possibility of a base unit device, and subsequently of CD-ROM as a storage medium in a non-hideously-ugly form.
As for how it writes, that's up to the device and if we even support writing. It would probably require the SD controller to look up a file inside an FAT32 file system and then use byte positions inside of it. Or perhaps we can just write to the raw sectors and make a special SD formatting tool to get images on there. Whatever's cheaper.
