SNES enhancement device - 21fx

SNES enhancement device - 21fx
by byuu on 2009-12-01 (#53323)

Cross-posting this here for those who don't frequent my forum, and since it very much relates to the SNES video thread discussion:

http://board.byuu.org/viewtopic.php?f=3&t=403

Feel free to comment here as well. I'm especially very interested in the opinions of people who have created actual hardware devices like the PowerPak on their opinions of the feasibility of making this device a reality, even in very small, limited numbers.

I believe I can create the software needed to drive demand for the hardware, and I would be willing to invest a good amount of money into prototyping such a design.

by Super-Hampster on 2009-12-01 (#53330)

I'm all for it if it's a good product. Are you leaning more towards simply giving the SuperNES a larger storage space so you can tap the true potential of the existing hardware, or are you leaning towards adding new hardware such as a custom sound chip?

by byuu on 2009-12-01 (#53332)

The former. The audio support is there as a necessity to extend existing games without rewriting half the game code, to reduce the complexity of playing back high quality audio, to lessen the burden on the system in doing so for higher video quality, and because it bypasses the need for ADPCM compression. It's not really any kind of sound processor, it just streams one channel with no effects applied.

This is in my mind what the base unit of the SNESCD was meant for. I see the base unit as a device to obtain large amounts of data and stream high quality music. Only by using flash instead of CD, we bypass loading delays.

It leaves the latter wide open, so if someone ever wants to make a high-end cartridge that acts as a BIOS / bootloader for 21fx, they certainly can. I don't think it's necessary, though. The SA-1 is a very capable, existing chip. It just never received any love from developers. It was only barely utilized, and mostly there for anti-piracy.

by MottZilla on 2009-12-01 (#53336)

This seems like a good concept for Homebrew type development as well as enhancements to existing games. But you mention adding to Der Langrisser and Chrono Trigger and working with existing carts. Wouldn't that still require use of a patched ROM and Copier? So it would only work with an existing PCB with your own EPROM or FlashROM game designed to access this device I guess.

But it seems like it would go great with a sort of System Cartridge like you mentioned but not with anything fancy on it. Just a BIOS to boot a homebrew game on a Flash storage medium. I think if you did make a hardware version it would be a serious waste of hooking up such a mass storage device without planning to have a "System Cartridge" so that homebrew games could basically be like SNES-CD games could have been.

Can't really think of anything else to say right now other than that. Mass storage "base unit" with audio stream playback sounds great, and totally awesome if a System Cartridge is provided for homebrew games to boot off Flash. Oh and I do mean homebrew, not necessarily bootlegs though it would seem a mass storage base unit + the right System Cartridge would make the product capable of that as well. Ofcourse I'm sure such a feature would only entice more people to buy units.

And I see your point now about why you would choose to use Flash like CF Flash cards over CD-ROM.

by byuu on 2009-12-01 (#53340)

For a system cartridge like the BS-X, we'd want it to have 32KB of ROM to map to $00:8000-ffff. It would jump to vectors at $0100-0103 for NMI, 0104-0107 for IRQ, etc. When your code runs, write your own JMLs in there and you have remappable interrupts with very little overhead.

$c0-ff:0000-ffff would be for loading in your own data via BIOS transfer commands. The BIOS would just set the data pointer and DMA the data over. It would all be volatile and writable. This would give you both plenty of ROM data and a ton more high-speed RAM to work with. Page out data as needed and your game can be as big as you want with no real limitations.

On startup the BIOS would load up the first 1MB off the flash device and jump to $c0:0000.

In this instance, it would be best to have the flash card be writable so that you don't have to share saves on the base cart and have a BIOS + memory manager like CD-based consoles.

Lastly, put a very affordable, low power ARM core on there. With today's processing power, it would be easy to totally trump the SA-1. But the reason for doing it would be because you can't exactly purchase SA-1 chips on their own. Add a register switch to control which chip has bus access to each of four 1MB regions of NVRAM and a few communication registers ala the S-CPU <> S-SMP.

Voila, you can develop anything using only Compact Flash cards. A killer dev system that's great for emulator and homebrew development. And you could distribute your games on simple, cheap CF media. Put a fancy little printed sticker on there and call it a day. Even those without the hardware could just use it directly on an emulator.

But this is all wishful thinking. I want the 21fx to be something that really happens, and I'll do what I can in that regard. At the worst case, it will exist in bsnes. It's up to others how much farther we can take this.

Once we have that hardware, we can start considering a special system cart. That's so many times more complex though, that just talking about it now makes this entire discussion seem like a teenager's fantasy daydreaming :/

Let's get 21fx up and going first. Who knows, 21fx + PowerPak may already make a perfect development pair :)

Quote:
I hope your idea for the Base Unit proceeds well and you can manage to produce it.

Thanks, we'd certainly make history if we did.

Quote:
Wouldn't that still require use of a patched ROM and Copier? So it would only work with an existing PCB with your own EPROM or FlashROM game designed to access this device I guess.

Yes, that is correct. You will need a custom EPROM cart, a copier, a flash cart or an emulator to run the patched existing games.

by MottZilla on 2009-12-01 (#53342)

byuu wrote:
For a system cartridge like the BS-X, we'd want it to have 32KB of ROM to map to $00:8000-ffff. It would jump to vectors at $0100-0103 for NMI, 0104-0107 for IRQ, etc. When your code runs, write your own JMLs in there and you have remappable interrupts with very little overhead.

I didn't think about that for some reason but it makes sense and I know the FDS does a similar pass off of vectors from the BIOS to the loaded program. Good idea to avoid making the cartridge more complicated.

Quote:
In this instance, it would be best to have the flash card be writable so that you don't have to share saves on the base cart and have a BIOS + memory manager like CD-based consoles.

Would definitely be useful to be able to save data to the card if homebrew is desired in the future. Sure would beat having passwords or having to use System Cart SRAM.

Quote:
Lastly, put a very affordable, low power ARM core on there. With today's processing power, it would be easy to totally trump the SA-1. But the reason for doing it would be because you can't exactly purchase SA-1 chips on their own. Add a register switch to control which chip has bus access to each of four 1MB regions of NVRAM and a few communication registers ala the S-CPU <> S-SMP.

I suppose if you did that I would have to learn something about ARM or use C to take advantage of that. But I can imagine it would be useful for speeding up processing quite a bit. I don't know a whole lot of details about the SA-1 only read alittle bit about it. I suppose as long as "affordable" is really that it would be a wonderful addition to such a System Cartridge.

Quote:
Voila, you can develop anything using only Compact Flash cards. A killer dev system that's great for emulator and homebrew development.

But this is all wishful thinking. I want the 21fx to be something that really happens, and I'll do what I can in that regard. At the worst case, it will exist in bsnes. It's up to others how much farther we can take this.

I wish I knew something about hardware engineering to help you make it a reality. But hopefully someone who does will have the time to help. It's really a good idea and seems like a better idea than a CD-ROM base unit for these times.

Quote:
Once we have that hardware, we can start considering a special system cart. That's so many times more complex though, that just talking about it now makes this entire discussion seem like a teenager's fantasy daydreaming :/

Let's get 21fx up and going first. Who knows, 21fx + PowerPak may already make a perfect development pair

Well it's a good thing you have priorities. And I suppose serious thinking about a system cartridge would need to wait anyway since you have to build from the ground up, not build the roof and worry about the floors below later. The main reasoning behind a system cart to take advantage of the base unit rather than something like the PowerPAK+base unit would be to stream massive amounts of game data since that isn't possible with the PowerPAK which is just emulating a typical cartridge. That plus your ARM processor idea is quite interesting.

Again I really hope to see this base unit get designed and produced in hardware. I'd certainly buy one as SNES is my favorite console.

by tepples on 2009-12-01 (#53343)

If you're going to incorporate a 21.5 MHz ARM7 CPU and an ATA connector (for the CF or the CD), why not just scrap the Super NES and just make a memory card adapter that takes CF for a system that already has Super NES-class graphics and an ARM7 CPU near that clock speed? That's what the SuperCard team did

by byuu on 2009-12-02 (#53354)

To echo this here, neviksti pointed out what should have been obvious to me from the beginning. Oh well, that's why I started the discussion, to find caveats in advance.

The A-bus can't point to the B-bus, which prevents base unit -> VRAM transfers. That would halve our potential memory bandwidth by requiring a transfer from the base unit to WRAM, and then from WRAM to VRAM. That's unacceptable.

So, unfortunately, the base unit idea falls apart. It will have to be implemented in cartridge form.

But it's not all bad. I was honestly just nostalgic about the idea of a dedicated base unit in lieu of the SNES-CD. Since we already have flash carts, it would be easier to make it as a cartridge-type device anyway.

I do however have to rethink things now. Eg whether this should be a Game Genie style passthru or a chip on existing carts, or if that even matters at all.

EDIT: okay, redesigned as a passthru device. But it can just as easily be implemented in a flash cart.

Best of all, neviksti's flash cart is already capable of all but the audio streaming.

http://www.neviksti.com/images/SNESsd_front.jpg
http://www.neviksti.com/images/SNESsd_back.jpg

by Super-Hampster on 2009-12-02 (#53361)

This isn't all bad. I once asked someone at Nintendo if the CD-ROM would use the expansion port and they said yes, but it may also just attach to the cartridge port. So even in the beginning Nintendo considered making the SNES-CD a device that sits in the cartridge connector just like on the Jaguar.

by byuu on 2009-12-02 (#53363)

Really, the only reason to use the base unit is because it's a much better place to put a CD-ROM drive. Sure you can technically get away with one on the top, but it'd be ridiculous.

You'd absolutely need a cartridge, period, since it is not possible to boot from just a base unit alone.

The designs I've seen used a base unit and cartridge, and connected the two with a gaudy cable. I don't fully understand the purpose of having a cable connection between the base unit and cartridge. I mean you could transfer memory between the two quicker, but ... bleh. To do anything useful you have to send it to the PPU or SMP anyway, and that'll be the bottleneck. It doesn't really matter since the device was never released.

-----

Anyway, I pretty much have the design features mapped out. I'm just shuffing with the register layout and usage, and also on how many audio channels I should provide.

None is the easiest, and would take almost no time at all to implement.

One gives us the ability to override existing game audio with CD-quality sound.

Two gives us the ability to do audio and voice samples.

4-8 gives us the ability to completely bypass the S-SMP, potentially even using it as a CPU instead of an APU.

But how hard will it be to implement channels in a hardware device? It'll be trivial from emulation at least. And anything but background audio will need the ability to start playback virtually instantaneously in order for it to be useful.

by tepples on 2009-12-02 (#53373)

I'm not very familiar with the Super NES: is this an analog wire-pair in the mixer path (like on the Famicom) or something digital? And doesn't one need two channels for stereo? (Some songs, like a couple tracks from Broken by Nine Inch Nails, lose certain parts in mono due to phasing tricks. Compare the drums in Theme from NEDM by Coburn: stereo YouTube to mono YouTube.) It shouldn't be too hard to replicate, say, the audio hardware of the Nintendo DS in an FPGA, but it would need its own audio RAM (like on the PS1 and Dreamcast)

by Super-Hampster on 2009-12-02 (#53375)

http://www.caitsith2.com/snes/flashcart ... nouts.html

looks like it's analog, and stereo.

by byuu on 2009-12-03 (#53379)

Aaaaah, so the way it works is to control the voltage level to the pins to change the "sample value". It's not 1/0 but something like +0V = 0, +2.5V = 32768, +5V = 65535? Interesting.

by Super-Hampster on 2009-12-03 (#53423)

So... this is probably a dumb idea, but with increased storage space perhaps an ethernet port would be a good addition to the device.

by byuu on 2009-12-03 (#53426)

I've decided to bypass the current problem of type of device and type of storage medium.

This new API is designed to work regardless of any of that stuff. It will work as a base unit, a cartridge or a pass-through connector. It will work if you use ethernet, CD-ROM, DVD-ROM, SD, CF, ROM or Flash. It's also extensible in the future to add any number of audio channels, to guarantee lower latencies, to allow write access and to be fully backwards compatible with existing code.

Code:
$21f0 = command port
Write:
00 = set data port address (parameter port[0-5] = offset)
01 = set audio track# (parameter port[0-1] = track#; also serves as a stop command)
02 = play / pause current track
03 = set volume (parameter port[0] = left volume, parameter port[1] = right volume)
Read:
d7 = data port ready (wait before reading data port)
d6 = audio track ready (wait before issuing play command)
d5 = audio playing flag (use this to auto-repeat the song if desired)
d4 = audio paused flag
d3-d0 = version (for capabilities and chip detection)

$21f1 = data port
Write: reserved for now, will still increment address
Read: fetches data, increments address

$21f2-7 = parameter ports 0-5
Read: returns current data port address

Now is definitely the time to specify any potential shortcomings / problems / suggestions / whatever.

With the API ready, I can implement this in emulation now, and will probably start on it this weekend.

by MottZilla on 2009-12-03 (#53431)

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? Obviously write access wouldn't work with certain mediums and audio tracks couldn't be played while accessing data on certain mediums. Would this just have to be something the developer of a program taking advantage of this would have to be aware of?

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.

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?

I'm just curious how it would function from the point of view of the SNES programmer.

by byuu on 2009-12-03 (#53452)

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.

Quote:
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.

Quote:
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.

Quote:
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.

by MottZilla on 2009-12-03 (#53460)

Sounds good to me. And it would seem that if this base unit is created it would be possible if you wanted to make your own little BIOS cartridge that lets you run your own program from within WRAM very easily for fun. I do like the idea of using a CD-ROM personally. Seems like it shouldn't be that hard to do either since Bung managed to do basically what we are talking about already.

by byuu on 2009-12-06 (#53608)

Okay, for those who want to play around, I've added 21fx support to the latest WIP.

http://byuu.org/temp/bsnes_v057_wip05.tar.bz2
(if the link is dead, you took too long to get it, sorry.)

You will need the DLLs from the official version to run it. It also leaves the debugger enabled and lacks profile optimizations so it's even slower than normal.

Here's an example 21fx ROM + source:
http://byuu.org/temp/21fx.tar.bz2

It looks for 21fx.bin in the game path. If it finds it, it enables 21fx support. It won't work with SuperFX, SA-1 or Super Game Boy, at least not yet; because they all need the coprocessor thread to run.

It will read four bytes in from 21fx.bin (skipping the first byte to show seeking capability) and write it to save RAM. This specific "game" also tries to play audio00000.wav. I didn't include it because those files are big. Use Winamp DiskWriter or something and create a 44.1KHz, 16-bit stereo, signed, PCM uncompressed WAV file. Put it in the same folder as the game and it'll play. Save states work on it as well.

Interface:
Code:
$21f0 = command port
Write:
00 = set data port address (parameter port[0-5] = offset)
01 = set audio track# (parameter port[0-1] = track#; also serves as a stop command)
02 = set volume (parameter port[0] = left volume, parameter port[1] = right volume)
03 = play / pause current track
Read:
d7 = data port ready (wait before reading data port)
d6 = audio track ready (wait before issuing play command)
d5 = audio playing flag (use this to auto-repeat the song if desired)
d4 = audio paused flag
d3-d0 = version (for capabilities and chip detection)

$21f1 = data port
Write: reserved for now, will still increment address
Read: fetches data, increments address

$21f2-7 = parameter ports 0-5
Read: returns current data port address

Absolutely none of this is set in stone. I'm leaving the version code at zero to emphasize this. Use it at your own risk, but if you do, please let me know how it goes. I'm very interested to see what we can do with this.

I haven't added any actual delays yet, so be sure to use the wait flags. Once the API is official, I'll probably add a ~1ms seek delay to both.

by MottZilla on 2009-12-06 (#53630)

I've got some ideas I'll have to attempt.

by byuu on 2009-12-06 (#53634)

Cool. smkdan said he was successful already in getting Super Mario World to play back MP3->WAV files instead of BGM. Meaning sound effects would still work.

It may be harder in some games to mute only the background music, but I believe for the most part it won't be that bad.

Also, be careful with the API, as it will change. Write a wrapper if you have to. Otherwise, only use it if you're willing to update whatever you use for v058 official.

by MottZilla on 2009-12-06 (#53639)

That's similar to what I'm doing as a test, attempting to add a full audio soundtrack to a game which requires telling the game not to play the music. I've made progress on the particular game I'm trying this on but still have things to figure out. Also just a minor question, why no ability to play an audio track with a "Repeat" setting? Or is there but I missed it. Otherwise you have to hack games to constantly poll if music has stopped playing.

by byuu on 2009-12-06 (#53641)

That's what I was discussing on my forum. We're going to merge the parameter registers into a shift register, and update play/pause to be more explicit on what you want to do (play with or without repeat, or pause).

For now, it'll just loop the wave file. But eventually I'm thinking we should include a "seek back location" inside the wave file for clean looping without fading.

-----

EDIT: new build, just go to my page to read the new info and spec. Don't feel like copy and pasting. I think this API is 99% final now, and it has a repeat command.

by tomaitheous on 2009-12-14 (#54031)

I just wanted to say, this sound like a great idea. I just hope it makes it into production - even if in small amounts. That way it's not consider "fantasy" emulation

by byuu on 2009-12-14 (#54034)

If you or anyone could help, we'd really appreciate it :)

Current issue: we need a 28-pin (though it can be 56-pin and we ignore every other one) edgeboard connector. It needs to look exactly like this:
http://img410.imageshack.us/img410/4654/dsc00587id.jpg

1.25in or 3.175cm wide, with pin spacing of 1mm pin to 1mm gap = 2mm per.

by caitsith2 on 2009-12-14 (#54064)

byuu wrote:
If you or anyone could help, we'd really appreciate it

Current issue: we need a 28-pin (though it can be 56-pin and we ignore every other one) edgeboard connector. It needs to look exactly like this:
http://img410.imageshack.us/img410/4654/dsc00587id.jpg

1.25in or 3.175cm wide, with pin spacing of 1mm pin to 1mm gap = 2mm per.

That should be 1.25in x 0.32in (or 3.175cm x 0.813cm), due to physical constraints of the snes side of the connection.
Width of 0.32in or 0.813cm

The card edge itself is 1.12in x 0.072in (or 2.831cm x 0.183cm)

by byuu on 2009-12-14 (#54066)

caitsith2 wrote:
The card edge itself is 1.12in x 0.072in (or 2.831cm x 0.183cm)

You mean the inner portion of the card edge from the SNES side?

Thanks for measuring that with the caliper, by the way.