I've always wondered- will it be hard to recreate the entire Super FX chip and produce a new working cartridge using a Super FX chip?? I suppose the world IS able to do it now, there are many reprogrammable processors, oscillators etc. that are fast, can emulate everything and can do many things. Of course even if it is possible to recreate it now, how much time and effort will it take to achieve that?? I know that Super FX is a processor that does something that ROM tells it to do, so even today, it still remains a challenge to program another processor to emulate the whole thing, meaning program the entire specific assembler for that, emulate specific commands etc.
Another question is- is Super FX chip fully documented already or are there still questions about it that remain unanswered?? In order to recreate the chip, the 1st step is to know how all the functions work of course
What do you think about all of that??
On an FPGA, I'm sure. The parts cost for that is what I don't know, plus it would have to be made by someone who has the talents for it. On a really fast MCU/DSP.. maybe. I'm totally inexperienced with the SFX and what it does best etc., but I have a feeling you'd get more bang for the buck using a modern DSP and running native code on it. Like now you can get stuff like a 200mhz, 2Mbyte ROM, 512kB RAM, with SIMD instructions, w/ FPU even, for around $10.
So you say that it would be even easier to use a straightforward powerful DSP chip and it will do all the job?? 10$ for the chip is still relatively low in this case in my opinion. Unfortunately I don't have any experience with them
. But either way, if it appears to be that easy, I suggest that someone else would already do that...
An FPGA is what you want for this, not a DSP/uC. An FPGA is 100% capable of this, the problem is that the chip hasn't been reverse engineered fully enough at a low enough level to implement the necessary HDL (ikari_01 has been working on it for the SD2SNES, but so far it's not working yet). So is it possible? Absolutely. Is it simple? Not remotely. As far as cost, if you want single-game repros, you're looking at around the price of an INL board + ~$20 (ignoring R&D costs).
Well, I mean the hardware would be relatively easy, but the software is another matter. There aren't very many people making SNES games. If there was at least one person who was serious about using something like this for a new game, I'd definitely be interested in doing the hardware-side of the thing. Note that I'm talking about new games only, I don't give a half a crap about repros/bootlegs.
This is the $10 chip I had in mind (guess it's more like <$9):
http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC32MZ2048EFG064Price goes down to more like $6.50 with smaller memory versions, like 512kB ROM / 128kB RAM. No changes would be needed on the board, just drop on a different chip.
I'm sure there is a similar chip with an ARM core, but I'm not familiar with it. This PIC32MZ EF is what I've been looking into for some other projects, so that's what I'm most familiar with. But this class of MCU/DSPs haven't been around for long, just in the past few years.
People have made similar carts for other systems, there is the Harmony cart for Atari 2600 with a 70Mhz ARM7. Back in 2004 I made an NES cart with a PIC18F which ended up being used for MIDINES only, not any games unfortunately. But the performance of that was a joke compared to what's available now, it's just crazy.
A microcontroller is not the right tool for the job. The SuperFX is a processor with its own ISA, with very particular timings for its instructions, etc. Trying to implement this on a microcontroller, which is a processor with an existing (and in the case of MIPS, completely incompatible) ISA, is literally real-time emulation, which isn't realistically feasible. An FPGA allows you to implement the hardware at the logic level in HDL, essentially you can actually clone the hardware for real, ISA, pipeline, cache, etc. which would be necessary to make this work properly.
This is the chip the sd2snes uses, but you probably wouldn't need anything quite that large for a single IP core.
Sorry, re-reading my posts I wasn't clear that I'm interested in re-creating the SFX "in spirit", not in emulation. That's what I meant by "running native code" and "for new games only". The game would have to target the new chip, written in C and/or MIPS asm. The chances of anyone wanting that are slim indeed, but I figured I'd put the idea out there. I'm sure it would perform better than the SFX.
I'd say a better bet is writing your own expansion chips in a hardware description language and using the SD2SNES to run it. Is the SD2SNES designed for end-user virtual expansion chips, or is the MSU-1 baked into the firmware? I know there's the MSU-1, a "virtual" enhancement chip used to create things like the CD-quality audio and FMV in the MSU1 Zelda hack.
All interesting ideas. The FPGA on the SD2SNES could be used be used to develop support for the remaining unsupported coprocessors (i.e. SA-1, SuperFX) and could be used to define a new community designed graphics accelerator. A new graphics accelerator wouldn't have to be a complicated CPU with its own ISA (although it can). All it would need to do is provide some capability that would be interesting to leverage in homebrew or rom hack games and/or help alleviate the burden of graphics development. I'm fairly new to snesdev so I wouldn't know what types of transformations are lacking or what types of processing effects would be most popular to the community, but designing the hardware on the SD2SNES platform seems like a neat idea to me.
The programming files for the sd2snes FPGA are stored on the SD card, so you absolutely could develop your own custom coprocessor core, I just don't know how the loading is done (I'm guessing it's handled by the menu, which is an SNES application, so you might have to add support for your new core in there, I don't know... but the code is all
here so even that is almost certainly doable).
> I know there's the MSU-1, a "virtual" enhancement chip used to create things like the CD-quality audio and FMV in the MSU1 Zelda hack.
The funny thing is, there's zero programmability in the MSU1. It's literally just two giant ROM chips. One you read over the B-bus, and one that streams over the audio input pins on the cartridge connector.
I very intentionally stayed away from trying to implement a true processor. I've always thought that would be really cool, but there's no reason at all the two have to be tied together into one unit.
You could certainly create a coprocessor that far exceeds the power of the SFX if you wanted to.
But ... keep in mind, you're always going to be limited on the SNES by the PPU. The absolute best quality you will ever be able to achieve is what you can see in video files played back by the MSU1: 256-color, 20fps, 240x144 video.
No matter how clever you are, that's never going to look even **remotely** impressive with today's hardware and games. You could put enough power in a cart to run Dolphin, and scale the video down to display through the PPU, but ... who in the world would even want such a thing? Especially when everyone else will just accuse you of cheating, anyway.
I think the best thing anyone could make for the SNES would be a processor powerful enough to run programs written in C. The underlying implementation would handle all the SNES<>PPU interactions, and do all audio through the expansion pins only. Kind of like a BIOS that entirely handles the SNES-side hardware. Your program would never actually talk to the SNES itself.
The idea would be to create a cart and an SDK such that ordinary people could make compelling SNES-era games without the monstrous complexity of learning how to work with all the archaic and nightmarish processors inside the SNES.
Instead of mass producing the hardware over and over for each game, put a USB port on the side (not many people have SD card writers for their PCs), and let people share their game programs with each other online.
Even this would be incredibly niche, but done right, if you're really, really lucky, you might get SNES homebrew on par with Genesis homebrew dev. But, probably not. It's much too late now.
It'd be a dumb idea anyway. The only novelty would be inserting a cartridge into your legitimate, real SNES console, and seeing your games playing on it.
The only real work we're going to see on the SNES are enhancements to existing games, and maybe ports. Which is exactly what the MSU1 was for.
I think the next low-hanging fruit would be for someone to make a new gamepad that connects to a real SNES, but has rumble support. I'd be willing to emulate said controller in higan, and people would have the option to craft game patches to add in rumble support. Not very impressive, but there's not much left to do. Video and audio are maxed out, so input's the final piece.
byuu wrote:
I think the best thing anyone could make for the SNES would be a processor powerful enough to run programs written in C.
Like maybe a 16.8 MHz ARM?
Quote:
The idea would be to create a cart and an SDK such that ordinary people could make compelling SNES-era games without the monstrous complexity of learning how to work with all the archaic and nightmarish processors inside the SNES.
I believe that's called a "GBA flash cart" and a "devkitARM".
Quote:
Instead of mass producing the hardware over and over for each game, put a USB port on the side
Something that EFA-Linker does. The first version had a proprietary B receptacle, and the second had standard USB mini-B.
Quote:
(not many people have SD card writers for their PCs)
My last three laptops and last desktop computer all came with built-in SD card writers.
Quote:
The only novelty would be inserting a cartridge into your legitimate, real SNES console
And I can insert a GBA flash cart into my legitimate, real GameCube console with a Game Boy Player accessory. In fact, most of the 240p- and 480p-related moaning I hear about GameCube is directly related to Game Boy Player.
> Like maybe a 16.8 MHz ARM?
Sure, that may be enough power. Feels a bit needlessly spartan, though.
About the only benefit beyond what you can already do, special effects wise, would be to have stronger computational abilities. If the RPi Zero can put a dual-core 900mhz ARM or whatever on a $5 complete system, then surely you can use something like that too.
> I believe that's called a "GBA flash cart" and a "devkitARM".
I believe that's called a GBA, not an SNES. The whole point was "make SNES games." If you can move the goalposts to an entirely different system, then just use a PC.
> My last three laptops and last desktop computer all came with built-in SD card writers.
Whereas the ten computers in my house have zero SD card writers. And every single one has USB ports.
Then perhaps I should have been more explicit about my intent by using the exact snowclone: "
If you want GBA, you know where to find it." It's the closest notable existing product combining a C-friendly CPU with a Super NES-class PPU. The one thing it doesn't have is controller 2, as it's intended for use in a LAN.
I don't get why people often suggest targetting another console/computer because it may suit a particular type of program better than the original intended platform. More often than not, people choose a platform based on their personal experiences with it, and the desire to have their own stuff running on it, not because the hardware is the most appropriate.
When I go to the AtariAge forums to discuss how to do something on the 2600, someone always shows up to say that the concept would work better on the 5200 or the 7800. I don't give two shits about those 2 consoles. I've never even seen those consoles in person, seeing as they didn't have nearly the same international impact as the 2600.
I might understand the Super FX hardware very poorly, but basically it's a RISC CPU which function as the 65c816's slave and is able to do various calculations and transfer a lot of data to VRAM. The SNES CPU basically tells the Super FX "compute this, this this for me, etc..."
If the Super FX is replaced by an ARM or any other RISC CPU that does act exactly the same and obey to the 65c816's order the same way, it will not make any difference for the game, right ?
tepples wrote:
The one thing it doesn't have is controller 2, as it's intended for use in a LAN.
And most homebrew would be played solo anyway =P And the one thing it
does have is a built-in screen, by-passing the issues of finding an analog-friendly TV.
tokumaru wrote:
I don't get why people often suggest targetting another console/computer because it may suit a particular type of program better than the original intended platform. More often than not, people choose a platform based on their personal experiences with it, and the desire to have their own stuff running on it, not because the hardware is the most appropriate.
I think the problem is that when you start talking about adding hardawre in the cartridge, you're already wanting to break the "sticking within the console limitations" rule, because you're adding stuff to get around that instead of designing your stuff to work within the original limitations. People may be OK when the extra hardware sorta resembles the kind of stuff you'd expect from that era, but otherwise they'll call you out on it and wonder why don't you go with something else instead.
Bregalad wrote:
If the Super FX is replaced by an ARM or any other RISC CPU that does act exactly the same and obey to the 65c816's order the same way, it will not make any difference for the game, right ?
It will if it expects it to react with the same timing as the original (which I doubt it will).
Also in hindsight, I can see one good reason for wanting to recreate the SuperFX: this way you can just test with the existing emulators. With your own coprocessor you'd have to use real hardware and nothing else, which becomes a slog during those times where you just update game logic and not hardware stuff (an emulator is much faster and you know you're unlikely to break stuff on real hardware). Emulators won't understand the idea of different timings, so either you make your code very permissive, or you make the recreated coprocessor act exactly the same down to the quirks.
So what I was suggesting wasn't to upgrade native SNES graphics to anything that modern consoles can do today, nor was I suggesting to just attach an ARM to a cart and emulate a whole bunch of graphics co-processors. What I see today is that a fair number of people seem to own SD2SNES (so you have already some adoption). Some people see that as being able to play 90% of SNES roms and rom hacks on their actual system. I look at it as my SNES has reprogrammable silicon that can be used in homebrew development. Right now the FPGA is mainly just to create functional clones of known co-processors. I was just testing the idea of just using it for homebrew co-processor development (no matter how complex or naive).
Bregalad wrote:
I might understand the Super FX hardware very poorly, but basically it's a RISC CPU which function as the 65c816's slave and is able to do various calculations and transfer a lot of data to VRAM. The SNES CPU basically tells the Super FX "compute this, this this for me, etc..."
Not really. What you're describing sounds more like the DSP-1. The Super FX is a separate programmable CPU, and it accesses the main game ROM directly to run code written especially for it. It starts in wait mode on power-on, and the SNES initializes it and turns it on (being careful to jump to a safe location first before cutting itself off from its own program ROM, since unlike the SA-1 the Super FX doesn't have a memory multiplexer). It also doesn't access VRAM; it just renders to a framebuffer in its own RAM (the PLOT opcode with its associated circuitry allows the programmer to treat the framebuffer as a bitmap while actually rendering into bitplane format), and the SNES has to turn it off once it's finished rendering and use the S-CPU's DMA controller to feed the result to the S-PPU. (Or the Super FX can turn itself off via the STOP instruction, which issues an interrupt request to the S-CPU.)
Technically, the S-CPU
can write directly into the Super FX's instruction cache, but I'm not sure that's what you meant...
> I was just testing the idea of just using it for homebrew co-processor development (no matter how complex or naive)
That should be entirely possible. My understanding is the firmware for the ARM CPU is uploaded right from the SD card itself. You could replace the firmware with a high-end chess API, or one that adds SNES registers to allow uploading new ARM code at run-time, if you wanted.
> The Super FX is a separate programmable CPU
Starfox makes most people think of the SuperFX as a 3D graphics processor. But indeed, it's really nothing more than a really fast horizontal line drawer. The games that utilize it to draw polygons are just really, really clever. (and indeed, the CPU was designed to be used in exactly this clever way, initially.)
Then of course you have Yoshi's Island, which managed to be even more clever and use it for 2D sprite scaling/rotation.
A small number of surfaces in Star Fox are texture-mapped, including one tower in the center of the first level. So are walls in Doom. I assume that the sprite transformations in Yoshi's Island are the same deal.
A fast plotter may be a more accurate definition (especially when consecutive pixels are involved, which is the case for all the heavy rendering routines anyway).
SD2SNES sounds like a really cool cart, but it looks like it costs at least $200. So one other advantage of a theoretical PIC32-based cart would be that it would cost a fraction of that (maybe 1/5th?). And certainly much cheaper in a larger quantity as for a game release, but that's not realistic to think about, at this point.
It's true an FPGA absolutely kills all when it comes to specialized cases. But in my experience, the people writing games aren't the same ones who are interested in designing chips. And even if you did have a general-purpose CPU implemented in an FPGA, ignoring the price, it's just not going to be able to run as fast as it could on dedicated silicon, due to physical limitations. Of course a custom CPU could be more specialized towards SNES graphics somehow, but that's just getting more esoteric to develop for, and you can forget about targeting it with GCC.
It looks like that FPGA has over 32kB of block RAM, which should be enough to hold a 256x224 4BPP screen. Now if the FPGA could access external memory fast enough to access tile data, maybe it could render a screen into that. Or one of the leftover memory blocks could hold a small amount of tile data. One thing I thought would be neat to see, even though I don't have an application for it, would be something like line plotting and flood filling, I'm sure control parameters for that would easily fit into the remaining block RAM. Seems like something Star Fox would be doable with more polygons or faster frame rate. I've wondered about that kind of stuff on NES, but NES has the advantage of having all it's PPU memory right on the cartridge, so there's no need to pass data through the CPU. I'm more of an audio guy than a graphics guy though, so I'm pretty much talking out of my ass when it comes to rendering graphics and/or 3D stuff.
Also, unlike the SFX and SA-1, in either of the PIC32 and FPGA case, you wouldn't have to block off the SNES CPU, it should have it's own separate memory from the other processor.
The reason the SD2SNES is so expensive is because it's a flash cart, which requires a lot of things you wouldn't need if you were still talking about the initial idea of essentially a repro cart with an SFX clone. You'd have a standard ROM, instead of the PSRAM, you wouldn't need the SD card or the microcontroller. Also, you'd probably be using a smaller FPGA. Like I said before, the cost of an FPGA cart that wasn't meant to be a general purpose flash cart is going to run about $20 more than an INL board.
qwertymodo wrote:
The reason the SD2SNES is so expensive is because it's a flash cart, which requires a lot of things you wouldn't need if you were still talking about the initial idea of essentially a repro cart with an SFX clone. You'd have a standard ROM, instead of the PSRAM
That or just a much smaller RAM.
Quote:
you wouldn't need the SD card or the microcontroller.
Unless you want to exceed the sizes of widely available parallel flash memories. You might end up needing the MCU to hold the Control Deck in reset while it boots the FPGA and copies the initial program from the SD card.
qwertymodo wrote:
You'd have a standard ROM, instead of the PSRAM
That's significant monetary savings. ($7-8 ish)
Quote:
you wouldn't need the SD card or the microcontroller.
Those aren't particularly important compared to the other costs....
Quote:
Also, you'd probably be using a smaller FPGA.
The current XC3S400 is awfully expensive ($30-50), but even the cheapest FPGAs are still a noticeable chunk of change. ($3 IFF you don't need block RAM; $5 if you do; $10+ for anything better than the iCE40 series)
tepples wrote:
You might end up needing the MCU to hold the Control Deck in reset while it boots the FPGA and copies the initial program from the SD card.
Some FPGAs have a "currently loading program from serial 'PROM" output, which could be used to drive SNES /RESET (possibly via a transistor buffer)
Yeah, the FPGA is most likely the biggest part of the cost. The moment you need it you're screwed in terms of cost.
Interesting note, there are
current-gen processors that are supposedly derived from the original SuperFX. Not sure if they are compatible in any practical sense, but it might be worth a look.
not to BUMP a dated thread but there was a BIG release of rumble pack files exclusive to many major snes titles on the xbox for the emulator zsnesxbox i think there in .xpr format but maybe they can be used in higan? or ported to even work on sd2snes? just a thought guys as rumble using the popular xbox 360 remote would prolly be possible in my guess.
I don't know what rumble support has to do with the Super FX, but ...
The way he did it (RAM monitor watch) was too error prone and hackish.
If I do rumble, it'll be more like the MSU1, and require manual assembler work to do it the right way.
Less games would get patched to support it, but they'd work much better.
i know it was off topic i just saw it mentioned here in the thread if you could implement that i think it would be awsome and i see what you saying on the rumble from zsnesxbox being bleh and thank you for all your work too!!
Heck you could probably use the controller port's IOBit to do rumble on the real thing, provided you put batteries in the controller.
You probably wouldn't even need batteries in the controller, there's no current limiter on the controller's voltage supply, and quite a bit of headroom in terms of available current when using the OEM power supply.
I seem to remember that some games using coprocessors would intentionally halt if a controller other than the standard one is connected, reportedly because of current draw. A cart with a coprocessor draws more than one without, and non-standard controllers such as the Super NES Mouse or the multitap draw more than the standard controller. I'm guessing Nintendo thought a mouse in port 1, multitap in port 2, and Super FX all together might have been too much for the power supply to handle.
Found it:
Prohibited Hardware in CARTRIDGE slot (due to overall power consumption) bans Super FX in games using the multitap.
thats silly if there is not enough amps then we can just use a higher amper supply if im right?
Memblers wrote:
Sorry, re-reading my posts I wasn't clear that I'm interested in re-creating the SFX "in spirit", not in emulation. That's what I meant by "running native code" and "for new games only". The game would have to target the new chip, written in C and/or MIPS asm. The chances of anyone wanting that are slim indeed, but I figured I'd put the idea out there. I'm sure it would perform better than the SFX.
I expect some people want a new game they can say is a new SuperFX game. "No, it's better" is, perhaps, tenable, but would not satisfy that niche.
Also, making incompatible code means that 1. it wouldn't have helped, in the construction phase, with understanding the SuperFX and 2. that it wouldn't be transferable knowledge to/from working with the SuperFX, both of which are appealing bits to aspiring SNES programmers.
mmz16x wrote:
thats silly if there is not enough amps then we can just use a higher amper supply if im right?
No, the external supply won't increase the rating of the internal 5V regulator. As far as games refusing to run, there's a difference between policy rules that devs had to follow in order to pass licensing and the actual hardware limitations. The former was obviously instituted on account of the latter, factoring in manufacturing tolerances in addition to leaving a decent headroom margin. Batteries certainly wouldn't be a bad idea, you'd definitely want to measure peak current draw and factor that into the design. I just meant that strictly speaking, you most likely *could* draw directly from the console.
I guess that's why the PlayStation had a beefier power supply: so that it could provide more power to accessories such as the eventual DualShock controller. The N64 Rumble Pak had to go with batteries.
Or we could allow vibration for only a relatively small fraction of the time the system is powered on. How much power does a vibration motor need, and what kind of capacitor can supply that for one second?
maybe rechargable batteries at that? or build a add-on pcb for controllers or a new controller altogether?
You can buy 40F supercaps for ~$15, might work for rumble (though they're only 3.6V, so you'd need some voltage conversion, and I haven't checked the physical dimensions).
http://www.mouser.com/Search/m_ProductD ... RtYN7ZI%3d
I was able to find 1.3V @ 85mA pager motors = 110mW, which is just a little above the permitted 17mA @ 5V = 85mW.
A clever power supply might let you get away with it without needing batteries.
Oh, pff, I should have just looked:
http://www.vibration-motor.com/products ... rrent.html has 17mA @ 3V motors.