> Thus the full image can only be refreshed once every two frames, effectively limiting the maximum framerate to 30FPS - although the test scene runs at closer to 20FPS (primarily due to some bottlenecks with the logic on the SNES side at present).
Getting around this would make this even more interesting. Like most other console PPUs of it's day, due to bandwidth/etc the normal 'flow' is to have a background and a series of 'character' sprites preloaded into VRAM and then shuffled around (this is why in some 'busy' games you would see clipping or game elements disappear on early consoles; too many sprite objects for the PPU to keep track of.)
To that same end, I'd be curious to see what could be done like this on Genesis/Mega Drive hardware
One of my biggest dream retro projects like this would be taking the cartridge expansion idea and using it to integrate a Wi-Fi radio and full online play connected to a central server. (I originally thought of it for GameBoy, but a Super NES cart would offer a lot more flexibility...)
You can see the bones of such technology in real products:
There is the MegaWiFi (https://github.com/doragasu/mw), an ESP8266-enabled Sega Genesis cart which exists as a open source hardware specification but not a commercial product. You could put one of these together from the spec and then write an online game for the Genesis.
I have had similar ideas. Where I ended up was working on Mario Kart 64 mods and figuring out how to enable online multiplayer. Only got some kart speed/accel/size mods working.
The online game's ROM and cartridge hardware including the Wi-Fi radio would have to be made together.
As the Wi-Fi hardware inside the cartridge would be custom, the ROM would have to contain instructions that would not be emulatable by a flash cart (or any other means.)
Edit- Missed "online play?" in your comment. Yes, that's the idea, new homebrew games with actual working online, made for systems released 25-30 years ago.
Thanks for your reply. The SNES was a seminal game system for me and it holds a special place in my heart. I love this idea! Let me know if I can help you make it happen via encouragement, pre-purchasing, beta testing or some combination thereof!
Maybe render a game on super hardware on a server, like Stadia, and beam it to your cartridge, format the frame buffer in a way that can be passed to the host console, and output to the CRT.
You could do definitely do that and it'd turn a lot of heads for sure, but the example I had in mind was more of a traditional client/server architecture. Like a (new, homebrew) RPG that allows up to 4 players tackling a dungeon together.
Ha, never got the chance to play that one. I've been working on this project since the start of the pandemic almost. It's got a lot going on inside of it but we just don't have any great marketing material (video) of it at the moment. I feel the key feature is that you can see and interact with other players in real time and conquer dungeons cooperatively. Lots of people seem to run randomized seeds and divide and conquer since items and progress are synchronized.
It was not uncommon to have expansion chips: even early games such as Super Mario Kart had a (DSP-1) chip to help with 3d calculations. Later chips such as Super FX 1/2 (Star Fox, Doom, Yoshi's Island), Cx4 (Megaman X2/X3), and SA-1 (Kirby's Super Star, Mario RPG) were used in a significant portion of the library.
The SA-1 was basically an additional 10Mhz SNES CPU (which was a 65c816 at about 4Mhz)
You're right but I agree with the parent that it's still a bit misleading. When I saw the video at the top of the article showing a fluid, high framerate realtime video I knew there had to be a trick.
Of course many games shipped with mappers, but if you're willing to put no limit to the amount of hardware you put on said mapper you might as well interface a full high end PC and play Cyberpunk 2077 on "standard SNES hardware".
Basically once you've figured out how to best use the SNES hardware to output fullscreen, decent FPS video from the cartridge port to the TV you can do whatever you want.
It's still a very cool hack but I was hoping for some ultra-optimized software-only SNES raytracer when I read the title.
> What I wanted to try and do was something akin to the Super FX chip used in titles such as Star Fox, where the SNES runs the game logic and hands off a scene description to a chip in the cartridge to generate the visuals.
Bruh. It's in the third paragraph.
> Of course many games shipped with mappers
No. You're thinking of the NES. The SNES handled memory mapping natively. The SNES chips had specific calculation functions, or ended up being co-processors, or both.
> It's still a very cool hack but I was hoping for some ultra-optimized software-only SNES raytracer when I read the title.
Not even the SNES games in the 90s did 3d without an expansion chip. You can't do any raytracing, or any 3d for that matter (without SEVERE compromises) with 3.5 Mhz.
If you read the article, the guy designed his own 3 core chip at 50Mhz... Yes it's more powerful than any chip that was in an SNES, but, it's not entirely period-incorrect.
>This is not real-time raytracing on standard SNES hardware, as the title implies.
I'm not sure the title implies that. Performant raytracing on SNES hardware would be (to my understanding) pure magic - SNES modes may have been good, but none of them were that good. Just reimplementing raytracing in software on a SNES would also not really be that interesting technically. It can already do any kind of calculation, if slowly.
Expansion cards are established ways to improve the SNES's hardware capabilities, as many cartridges did, especially toward the end of the console's lifetime. It's not dishonest to describe using one as doing something "on the SNES" - especially when part of the writeup is about technical challenges interfacing the expansion chip with the actual console.
It sort of is. The SNES was sold as a specific unit with specific licensed cartridges, and has a well known set of expansion chops shipped in cartridges. I think it's pretty well understood that because of this when someone says "on the SNES" they mean using the existing hardware, possibly plus existing chips shipped at the time. The idea conveyed is that this could have been done at the time if only the expertise and effort were put into it.
Sort of like the Commodore demo scene. What they can accomplish with the original hardware is amazing. If they were relying on additional hardware to do so, it's less interesting (but may still be interesting, and an accomplishment, as this is).
A more accurate title based on how people might think of this might be "SuperRT – Hacking SNES hardware to support realtime raytracing" (and even then you're going to get people assuming it's all original hardware).
The SNES, unlike e.g. the Genesis, had a really heavy history of using add-on chips on carts. In fact, its entire architecture was very specifically designed to permit and encourage this, which is why e.g. the Genesis 32X had to intercept the video out port on the Genesis, but Super Nintendo carts could just bolt-on a SuperFX/Cx3/SA-1/what-have-you and go about their merry way. (Even the the unreleased Nintendo PlayStation would have been able to directly interface with the existing hardware, not do the 32X route of video interception.)
Where you may be making a valid point is that I don't know how many people outside the dev scene know how common cart-based extra CPUs were. But doing this feels entirely in the spirit of how development on the SNES actually worked, even at the time--and as someone who's done some SNES development work, I knew from the headline alone roughly how it would necessarily be implemented. The closest analog I can think of would be like seeing a blog post, "calling native Win32 from pure JavaScript," and then being disappointed that ffi was involved. That's literally the only way it could possibly work in the first place, so of course that's what it is going to have to be about.
I don't think the SNES actually had anything in its design that made extensibility easier on it than the Genesis.
This and the Super FX - not to mention the Sega CD or the Sega SVP used in Virtua Racing - etc. all just uploaded video data via the cartridge port and blitted it to the screen console-side.
The only reason the 32X needed to do the weird video interception kludge was to get around the Genesis' poor colour depth, and exactly the same thing would be needed if you wanted to do that on the SNES (the SNES had less of a need for that, but...)
Somewhat strangely, a single shogi game used a 32bit 21mhz ARM cpu (significantly more powerful than the baseline SNES hardware) to run the AI on. A large enough number of those in parallel could possibly display a low res real time raytraced scene decently.
Sure it does.. it says "Realtime Raytracing on the SNES". To any normal person "SNES" means a super nintendo you would have at home.. not one that has expansion cards etc.
Anyway cool project but the title is indeed a bit misleading.
As I understand it, if the OP put their chips and wires into a SNES cartridge, you could take that cartridge, plug it in, and you would see their ray tracing demo on your stock SNES.
This is just like Nintendo adding their own co-processors over the lifetime of the system, albeit with more advanced technology. If Mario Kart is running on the SNES, so is this.
You couldn't download this demo into a ROM image and run it on an emulator. To make it run, you'd have to beg the author of the emulator to actually support your chip.
This is more than a silly, pedantic distinction; emulators are probably the way that >95% of the current SNES playerbase runs the software, and they're likely to remain that way … forever? I don't see the interest in running SNES games ever really going away, since they're fun in a timeless way (like classic books/film), so emulators that support it are likely to stick around for several centuries, barring civilizational collapse. Actual hardware's pretty close to dying out (the recent "SNES Classic" physical devices, afaik, are just neatly packaged emulators).
So I think it really does matter whether it runs in an emulator or not.
(Not to diminish the fairly awesome technical prowess of this hack)
That's true of probably 90% of ROM images though. To get most SNES ROMs to work you need to not only emulate the SNES console itself but also emulate the individual game's chipset. Most SNES games use one of the following expansion chipsets:
Many SNES games include one-off chipsets that common SNES emulators implement as well; for example just something simple like saving your game can't be done on an SNES and needs an expansion chip.
> So I think it really does matter whether it runs in an emulator or not.
If you were to write a SNES emulator that only emulated the console itself, it would not be able to run the many SNES games that use addon chips. SNES emulators include code that emulate the addon chips originally contained in the cartridges[1].
So, I think your test is a false one. Games run in the emulator because the emulator added emulation for the chips in the game. This game cartridge would also run on a SNES emulator if you emulated its chips.
The title is no more deceptive for using an expansion chip than a game like Mario Kart is deceptive for calling itself an SNES game even though it also used an expansion chip.
Almost any popular SNES game you can think of came with extra technology included in the cartridge and commercials often bragged about it, like the SuperFX chip used by Star Fox.
Heck if it weren't for expansion chips, you wouldn't even be able to play Super Mario World or Zelda, since the SNES had no persistent storage, all save games were stored physically on the cartridge itself.
I'm confused. Did you really think somebody found a way to do real-time raytracing on a stock SNES? I saw the title and the first thing I thought is "It's not possible, so clearly they did some black magic fuckery to subvert the system's limitations". I wasn't disappointed either, because it's impressive what he managed to do. Maybe try not to take every title completely literally? And maybe try a little bit harder to appreciate people's creativity and hard work?
I don't think it's misleading, given the SNES history. For me the SNES was famous for its expansion chips - I immediately assumed one like the super fx chip that gave it 3d graphics.
The title may be skewed towards an audience that knows slightly obscure details of SNES history, rather than misleading the general audience.
I'm guessing the division comes down to generational ignorance. Commenters on both the oldest fringe and the younger half of the age curve aren't going to remember the big deal Nintendo made about these chips.
The expansion chips were in the game cartridges, though. This article is talking about how you could potentially make a game cart that you could plug into an SNES as normal and have it play with real time raytracing.
Well, if you're familiar with SNES stuff, you'll recognize "SuperRT" as a reference to the SuperFX chip, which pretty much did a similar thing for 3D rendering on the SNES in its day. That gave it away to me from the start.
I find this kind of dismissiveness boring to start with.
But even beyond that, this isn't the case - the core logic for scene creation runs on the SNES and then the instruction opcodes are shipped to the expansion chip. So it's a GPU for the SNES, and a perfect analog to the SuperFX chip from which it takes its name.
A far cry from simply "using the SNES as a video adapter" as the full SNES hardware is still running the "game logic" to accept input and set up the scene.
I mean ok but then it should be like "Building an external GPU for the SNES".. people are being "dismissive" because of the title's initial expectation- that it was done on a vanilla SNES that you may have laying around at home.
The SNES is totally unmodified. Apart from the fact that what should be housed in a cartridge is instead exploded across breadboards, nothing here is anything but vanilla by SNES standards.
There is no such thing as a game that runs on a vanilla SNES. Every SNES game comes in a cartridge that includes additional technology built into it. You can take the technology that the author created, package it up into a cartridge and plug it into a vanilla SNES as would be required by any other SNES game.
The inherent limitations of an SNES cartridge are the power consumption (although some cartridges actually included batteries) and the memory bandwidth (it's a 16 bit system so the cartridges have 16 pins).
This isn't like woodcarving, which is fairly intuitive and requires only a lot of practice.
FPGA design, and graphics programming generally, requires higher-order math. I have always struggled mightily with trigonometry; something about it just doesn't click in my brain. Calculus I can handle, but spatial math breaks down in my head.
I could probably figure it out given enough time, but it would take much more time than it would take someone whose brain is aligned for it.
Sure. I wrote the Tecmo and CAVE cores for MiSTer, and it's a long road to a complex core like an arcade game, or in this case, a ray tracer.
If you're just starting out, then you've gotta begin with the basics: blinking a few LEDs, etc. From there you can progress to more and more complex circuits as you learn to code in VHDL or Verilog.
I'd recommend buying a couple of 2nd hand books on VHDL and/or Verilog to get familiar with the syntax. There are some good free books too:
Thanks! I have already read the 8bitworkshop one, but I was on vacation back then so I couldn't get my hands dirty. The samples are also definitely going to help. I do like the approach of using something like Verilator, though. The barrier to entry for actually doing stuff on the board seems too large for me at the moment -- Need to install and learn software (Quartus), and my everyday computer is a Mac so I have to use a slow VM!
In that case, you might like one of tom7's many wonnderful videos [0], "Reverse emulating the NES to give it SUPER POWERS!" where he hacks a real NES cartridge with a raspberry pi with an emulator, then figures out how to map all of the data into NES sprites, etc. As usual for his videos, it's absolutely wonderful.
This is one of my favorite videos on all YouTube. I know in retrospect it seems obvious, but when it showed that it was all running on a NES it blew my mind. This video felt like transforming nerd hackery into an art form.
It's funny that you mention that. I, too, often have this reaction to really interesting, cool projects and accomplishments. But over the years, I've learned to realize that the stuff that seems magical is not beyond my reach.
Look no further than this article itself:
> The idea originated when I was trying to think of an interesting idea for a project to help me learn Verilog and FPGA design, and the notion of building a simple raytracer came to mind (partly inspired by a scarily smart friend of mine who is building his own GPU).
The way this author describes his friend who is working on a challenging design is 'scarily smart.' IMO "that other skill domain" seems intimidating from here but if you start small and are willing to put in the time, you can do it.
The people who work on biochemistry, mechanical engineering, auto repair, digital hardware -- they're all just people, after all.
Very cool indeed. Seems like a good platform to apply the demoscene trick of "adaptive subsampling" to greatly improve performance at the cost of a little image quality.
It takes advantage of the fact that pixels that are close together in screenspace are likely to be similar enough to interpolate from it's neighbours where possible. It focuses the computation time on areas where neighbouring pixels are very different, such as object boundaries, shadow boundaries and large lighting differences.
This is pretty neat. Is anyone familiar with the limitations of expansion cards? Like, would it be possible to put a flash drive + an x86 CPU and have the SNES pull from a frame buffer so you can play Crysis on it?
Decent game? Probably not. Based on the article the demo runs at 20 FPS completely saturating the SNES' CPU with a hard limit of 30 FPS due to bandwidth constraints.
At 20 FPS you're already pretty laggy; dropping the FPS further to manage game logic will likely make playing the game an unpleasant experience.
Saw a comment on YouTube about implementing this expansion chip as an sd2snes firmware. If the expansion chip interface was standardized would be cool to see Homebrew using this. Kind of like byuu’s MSU-1 chip.
Just rub your project in retro vibes and it becomes 'remarkable'. But I am not thaat jaded. It's cool. ;-) In fact, there is an original history on the SNES of using coprocessors in the cartridge to enhance the rather underpowered 65816.
Wow, this is stunning! Now if I forgo sleep for the next 5 years, I might be able to finally finish that hacking/reverse engineer project I've been putting off ...
> Thus the full image can only be refreshed once every two frames, effectively limiting the maximum framerate to 30FPS - although the test scene runs at closer to 20FPS (primarily due to some bottlenecks with the logic on the SNES side at present).
Getting around this would make this even more interesting. Like most other console PPUs of it's day, due to bandwidth/etc the normal 'flow' is to have a background and a series of 'character' sprites preloaded into VRAM and then shuffled around (this is why in some 'busy' games you would see clipping or game elements disappear on early consoles; too many sprite objects for the PPU to keep track of.)
To that same end, I'd be curious to see what could be done like this on Genesis/Mega Drive hardware