We already know how to stream raw 16-bit uncompressed samples at 32KHz [1]; so we have just shy of CD-quality audio already. There's really no way to make things sound better than we have now.
The remaining enhancements are to optimize things: produce better sound while using less ROM space, use less CPU power, and be able to still run as many simultaneous sound effects as possible.
It took a long time to perfect because it's nuanced, but it's not a very complex chip: it's around 20KB of C code to emulate its 32-stage state machine. The only part of the SNES DSP that we don't fully emulate right now is the slight decay rate (in the nanosecond range) involved when the MUTE flag is enabled on a channel. And that's mostly because it's an analog component and we don't have the right people to analyze that sort of thing properly.
I do like these demos for their music and their visual aesthetics, but I'm sorry to say, they aren't in any way technically impressive. The first one [1] is literally an FMV, it's all pre-rendered video. The second has one neat effect, the rotating scanline-aligned box that you've seen on other platforms, but all the hard part for other platforms, rasterizing it in realtime, is trivialized by the "mode 7" affine transformation video mode. Just need to calculate one 2D affine matrix per scanline, or load it from a lookup table, and the graphics hardware handles the rest. Plenty of commercial games had similar effects; it's just barely more impressive than seeing a rotating cube on a PlayStation. And even the (admittedly awesome) music isn't doing anything new, it's just using higher quality samples than most devs could afford to use in their games back in the day, synthesized on a PC with more powerful synthesizers.
I'm sorry, I know I sound like a total dick writing that. Again, I do enjoy the music and the visual aesthetics of this group's demos a lot more than a lot of other unarguably more technically impressive demos. Hell, I've watched Smash It about a dozen times now! I'm sure that we can expect really awesome stuff from them in the future as they get more experience. Just had to point out that "THIS IS JUST THE BEGINNING OF WHAT WE CAN DO ON FUCKING SUPER NINTENDO" is an apt description of the tech on display, which is important, because the demoscene is about the intersection of style and technical achievement, not one or the other.
Far less than you might expect. Most aspects of these things were known by someone. The aspect that makes things special is not the pieces of knowledge individually but when several critical pieces arrive together in the right mind.
Much of what can be achieved now on vintage systems is due to the internet enabling the knowledge to distribute.
A little OT because it's not what they're doing in this case case, but...
The NES and SNES (and I'm guessing other cartridge-based consoles) supported having extra chips (often called "mappers") inside the cartridge that would add extra hardware capabilities beyond what the console could do by itself. Basic mappers could switch between different ROM banks, effectively allowing games to have larger ROMs than the console would normally allow. Later, some cartridges would have co-processors that did some of the computation inside the cartridge itself in order to enhance graphics capabilities. That's how the original StarFox was able to run on Super NES, despite the SNES not supporting 3D polygon rendering.
For a while[1], I've wondered what a NES would be capable of if you used a modern ARM SoC - say, a Raspberry Pi - as a mapper. For one, you could make a NES game with WiFi support (you wouldn't even need an ARM chip for that, just an ESP8266 should be able to do the basics). I'm not sure if this is possible, but in theory you could even do all rendering on the ARM chip and output the image directly to the video buffer, effectively allowing you to do just about any graphics the SoC can do. As for audio, on the Famicom (the Japanese NES), there were actually extra analog audio pins for cartridges that would allow a cartridge to output any audio it could generate. The NES doesn't have these pins, but I think you could still do higher-quality audio than the NES is normally capable of by rapidly changing the DMC channel.
I don't know much about NES programming nor really anything about its video hardware, but this is still an idea I've had in the back of my mind for a while.
I know some people might ask "What's the point? All you're doing is making it harder to use a Raspberry Pi!", but I think it would be pretty cool to say you did all that with something that's technically a valid NES cartridge running on an unmodified NES.
[1] really, I first got this idea when I saw Google Maps' 2012 April Fools joke - I started thinking about how a NES-based Google Maps would technically be possible
Only two 8 bit sprites and smaller objects available per scan line. Sprite sorting and multiplexing gets done on the external CPU, along with feeding the right data at the right times allows one to maximize what the internal 1.x Mhz 6052 can do.
We don't. Well, people have had time to find or reverse engineer the specs for some of these weird chips. But also we have cheap, widely available electronics development hardware. An eeprom programmer can be had for under $100, or built with cheap parts. Programmers used to cost thousands of dollars, and might only support a few platforms.
