Hacker News new | past | comments | ask | show | jobs | submit login

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




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: