nesdev.org

For those of you that haven't seen it already, Ferris of elix recently released a new SNES demo called "nu": http://www.youtube.com/watch?v=wi-NxM1EaXM (there's a link in the video description to where you can download the ROM).

Cool.

Neato!

Is that running on real hardware?

This is fantastic, great work!

If they create an NTSC version, they would have to squash the picture down to 184 lines for both DMA reasons and aspect ratio reasons.

psycopathicteen wrote:If they create an NTSC version, they would have to squash the picture down to 184 lines for both DMA reasons and aspect ratio reasons.

<goes and runs it in no$sns, watches the debugger> Oh, hey, I was wondering why the ROM's contents looked so patterned.

Actually, I think the pixel aspect ratio is currently the NTSC aspect... at least assuming those circles at the beginning are supposed to be "proper" circles.

Now to figure out how to get a SPC out of this...

Very, very cool. Still pondering the methodology, but in the end just chose to enjoy what I witnessed.

As for the SPC: could just ask the dude.

lidnariq wrote:Oh, hey, I was wondering why the ROM's contents looked so patterned.

It's a video?

Well put together nevertheless.

The visuals just being "streamed" from ROM is a bit of a let down, but hey; who's anyone to complain when no one else put out a decent SNES demo in over a decade. (:

Also, the really impressive piece of code here is the custom SPC music system, and it sounds damn good too.

So it is like the Bad Apple demo on the Sega Genesis. I thought it was real-time polygon engine, with updating the entire screen 50 frames per second, making use of the extended vblank time PAL consoles have.

I would like to see someone make a polygon engine for the SNES. With planar format you can blit 8 pixels at a time.

why won't this work on NTSC consoles?

Time. It's running a 224 scanline image on a PAL console, so there are 312-224=88 scanlines to transfer data. On NTSC, there's only 262-224=38 scanlines

DMA goes at 2.7MHz, right? If so, I think that works out to PAL has enough time to transmit 15kB of data, while NTSC only affords 6.5kB.

I dumped the .spc file, being a SPC set ripper at heart. No streaming data, that's for sure. Also, the 65C816 ASM to my knowledge is microscopic.

I suspect the SPC application is self-running. I attempted a music modifier, just for fun, and I have no clue if any commands were implemented. Therefore, I suspect the music program is self-running.

The solution was very simple: just dump the SPC the usual way through emulator (for me, that means pressing the dump button, and when the sound starts playing, that usually means I get the music).

I got around to taking a gander shortly before you posted ... they actually made it really easy.
The first 256 bytes of the SPC's memory aren't touched.
Then memory from SNES 0x018000-0x01FEFF (or ROM 0x8000-0xFEFF) is transferred to SPC 0x100-0x7FFF, and memory from SNES 0x028000-0x02FFFF (or ROM 0x10000-0x17FFF) is transferred to SPC 0x8000-0xFFFF, and then the entry point given by the SPC uploader to the SPC is 0x300.

It does implement at least one command (having played with vspcplay): writing to $2140 with nonzero stops playback, and writing with 0 restarts from the beginning. (Reading back from $2140 returns 1 while playing and 0 otherwise)