nesdev.org

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.

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?

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.

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.

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 :)

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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)

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

looks like it's analog, and stereo.

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.

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

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