Keeping your eyes on the size

Earlier this week, I decided to see if I could do something interesting with only 256 bytes of ROM ($FF00-FFFF). I managed to make a working implementation of the classic "Kefrens bars" effect (or "Alcatraz bars", if you're a history pedant) that fits entirely into 249 bytes (plus two more for the reset vector) and appears to work perfectly on a real SNES

Here's the ROM, and here's a considerably larger GIF of it in action.

(Bonus Pouet page, also)

I'll probably post slightly cleaned up/annotated source code later.

Has anyone else ever attempted to make anything impractically tiny on the SNES before? It definitely feels like a challenge even by the usual standards of "sizecoding", just because the amount of space it takes just to properly initialize enough of the hardware - especially compared to MS-DOS, the usual target, where it you can make a lot of assumptions and end up with working, interesting programs in 32 bytes or less.

I think there are probably some pretty interesting possibilities for sub-1kb programs on the SNES, though. I may try to experiment more in the future.

Very cool demo! Looks great on my FPGA SNES.

If a large range of addresses needs to be set either to #$00 or #$FF, you could encode the addresses in a bitpattern.

%1001 could mean a 1 (/2/4 however) byte run of #$FF, #$00, #$00, #$FF each written to $21xx.

Wow, this is great! I looked in the sprite, palette, and tilemap debuggers and all seem to be empty so I'm scratching my head at this one. Well done.

A lot of homebrew/demo ROMs I've seen are impractically large so I'm interested in seeing what you can get out of a more realistic ROM size from the 16-bit era. I thought up a compression scheme using RLE and a dictionary, I just need to code it. If it works well I might bundle it with my framework.

256b demos usually have custom code generators build in them, you can't really get generic code packer for that size And making something fractal also helps

4K demos, it starts to get to the point where your encode you opcode stream and param streams separately, as you will typically do a
LDA XXXX
STA XXXX
LDA XXXX
STA XXXX
type code where the XXXXs will be different, but this way you can compress the LDA STA run, and then the hi bytes normally have a run so you get the unique lows and RLE the common His etc.

Well for my purposes it wouldn't be quite *that* small. I was thinking more like being able to fit a full length game in about a megabyte.

It depends on the level of detail. There are plenty of full-length 16-bit games that size, such as Super Mario World, Super Mario Kart, and the first two Sonic the Hedgehog games. But something whose detail is comparable to that of Donkey Kong Country or Super Street Fighter II isn't going to fit in 8 Mbit. On the other hand, because original graphics and audio take time to create, I imagine that a full-length game created by one or two hobbyists will economize effort spent on creating assets to the point that the result fits in 8 Mbit.

What sort of overly large ROMs are you talking about? Tech demos that encode the fan video for "Bad Apple"?

Great stuff! And challenge accepted!

Nice demo!
I wrote a BF Interpreter for SNES using 1kB in total for a contest held some time ago: SNESF1k

https://gist.github.com/devinacker/3178 ... 646fd7d952

Source code for the OP demo, for your enjoyment(?) See if you can figure out the technique before spoiling yourself, though.