nesdev.org

I'm beyond impressed.

I managed to squeeze the compression routine into the last 256 bytes of Fast ROM.

It'll be nice to see if you can get that frame rate constant and audio working as well. Still impressive progress.

psycopathicteen wrote:I managed to squeeze the compression routine into the last 256 bytes of Fast ROM.

If it'd be better with more tables, I could make the chunk slightly shorter.

Really impressive to see it coming on the SNES Also the latter version of the ROM work on almost emulator so we can test it easily.
Before trying to reduce too much the size of the rom, you should really consider the unpacking time on the CPU.
Some frame can be really heavy to unpack (thinking about the tree or the fire screens) and if you look the MD version you will see 2 or 3 locations where the frame rate drop at ~25 FPS instead of 30 FPS. The MD version it is not optimized at its best (i stopped when i assumed it was "good enough") but still i admit that i am wondering how you will be able to push that much data with the 65816 (if you really want to keep the codec lossless and fit that in 8MB with sound) but i am really looking forward your progresses =) Actually your codec looks already better that what i did ! It did not compress as much but it does compress very well and looks not over complicated

I've been working hard on this today, and there's slowdown in one spot that I can't seem to fix. It's during the part with the 3 musicians. I'm going to use DMA to speed up RLE name table decompression, so I'm requesting a slight change to the compression algorithm.

Instead of the CPU knowing automatically where the name tables end and the pattern tables begin, it would be faster if there's an exit byte 11xxxxxx, at the end of name tables, followed by a word with the number of pattern tiles in the frame.

I've looked at the binary. From what I can see, your RAM consists of variables at 0000xxh, and a bigger buffer at 7E2000h+x.

The variables are sometimes accessed as [xxh], sometimes as [00xxh], and sometimes as [0000xxh]. Always using 8bit addressing [xxh] should be faster. Why didn't you do that? Or is the assembler automatically doing that?

Moving the variables from 00xxh to 43xxh should be also faster (by setting the "zero page" bank to 4300h, and then accessing them via 8bit addresses [xxh]. The internal Work RAM at 00xxh is slow. Mis-using the DMA registers as storage is faster.

And for the big buffer, setting DB=7Eh as bank number, and then accessing it as [2000h+x] should be faster than accessing it as [7E2000h+x]. As long as you don't need "DB" for other purposes.

This is the latest version. It has optimizations all over the place, and I still can't get rid of the slowdown in that one spot.

Tonight I plan to regenerate the compressed data with the following changes:

• Chunk size is $3F0000 = 4128768 bytes (4 MiB minus 64 KiB) to allow code in fast ROM
• End each nametable with a 2-byte command
  110000bb then aaaaaaaa: b*256+a compressed pattern tiles follow

That sounds like a good idea. Does the 110000bb byte comes first, followed by the aaaaaaaa?

psycopathicteen wrote:This is the latest version. It has optimizations all over the place, and I still can't get rid of the slowdown in that one spot.

To be honest i am really impressed Very well done, almost full speed on the whole video ! I guess with some minors adjustments you can get it I wonder how much room you have for the sound... but you can always find solutions =)
Did you tested it on real hardware ? is it possible to have the code source ?

Works great on real hardware.

psycopathicteen wrote:That sounds like a good idea. Does the 110000bb byte comes first, followed by the aaaaaaaa?

Yes, big-endian.

But I'm not sure why you need this length when you already have the length from having built the nametable. How exactly would that make decoding faster?

Can you read from DMA registers, and $2181-$2183? Because if that is the case, I can find the end of the tile map by looking at $2181-$2183, and find the amount of tiles by looking at what address the DMA channel left off.

Looking at http://problemkaputt.de/fullsnes.htm , DMA registers are readable, but not $2181-2183 (which are the WRAM address registers).