Progress Thread - Wolfling

[tepples]

I've discovered the reason why my DPCM-split code failed: It does not like famitone.

It figures, as Some of Shiru's games have DPCM drums. Pently doesn't touch the DPCM regs. Have you considered using it?

By the way, did anyone modify the exomizer decruncher to depack to CHRRAM directly? Currently, I am using RAM as a intermediate buffer and copying the data to CHRRAM in a 2nd step.

Any decompressor for a codec using back-references, such as LZSS or interleaved PB53 or Bagel, will need to use an intermediate buffer. But that means you can also pack things that will be streamed to CHR RAM while the game is running.

[tokumaru]

Any decompressor for a codec using back-references, such as LZSS or interleaved PB53 or Bagel, will need to use an intermediate buffer.

You can use VRAM directly, it's just that you'll be doing a lot of $2006 writes. I think I coded an LZSS decompressor like that.

[tepples]

But why have separate versions of the decompressor for updates during forced blank using $2006 reads and updates during vblank using a temporary buffer? Or do you plan on not having updates during vblank at all?

[Lazycow]

@tokumaru: For exomizer, just using $2006-writes is not enough, I tried... The algorithm would sometimes need to "read" from CHRRAM and sometimes from ROM. I don't understand the algorithm good enough to know when the input has to be switched. But I think it would be possible.

@tepples: Yes, modifying CHRRAM on the fly is a nice-to-have. Anyway, optional direct decompression to CHRRAM would be nice, too. The compression ratio degrades with small intermediate buffers and splitting data into small chunks is complicated...

The drums? Hm... Ok, maybe I will give the DPCM-split a 2nd try when I have some time left before the deadline.

[thefox]

Any decompressor for a codec using back-references, such as LZSS or interleaved PB53 or Bagel, will need to use an intermediate buffer.

You can use VRAM directly, it's just that you'll be doing a lot of $2006 writes. I think I coded an LZSS decompressor like that.

There's one like that for apLib: http://jiggawatt.org/badc0de/decrunch/a ... 2_vram.asm

[tepples]

Anyway, optional direct decompression to CHRRAM would be nice, too. The compression ratio degrades with small intermediate buffers and splitting data into small chunks is complicated...

The overall compression ratio (data plus decompression code) also degrades with multiple versions of the compressor in the ROM. I guess it's a tradeoff of one type of degradation against the other.

[tokumaru]

The reason I was reading from VRAM directly was because the LZSS variant I was using supported very distant references, so the stock 2KB of RAM couldn't possibly cache all the needed data.

If you're working with short packets of data, then I agree it makes sense to use a buffer in RAM, but with only 2KB of total RAM, much of which might not even be available for this purpose, it may be mandatory to work directly in VRAM when decompressing pattern table data, which can be as big as 8KB.

[calima]

But why have separate versions of the decompressor for updates during forced blank using $2006 reads and updates during vblank using a temporary buffer? Or do you plan on not having updates during vblank at all?

For my use (lz4 direct to vram), the runtime updates have different compression, lz4 is only used for entire screens, uploaded during black screens.

[Lazycow]

Ok, I ram out of memory.
I wonder how much memory famitone2 uses at FT_BASE_ADR=$0100 ?
Can I check this somehow?

[thefox]

Ok, I ram out of memory.
I wonder how much memory famitone2 uses at FT_BASE_ADR=$0100 ?
Can I check this somehow?

IIRC the documentation mentions it.

[Lazycow]

Ah, ok. This one?

Code: Select all

               RAM     ZP     ROM
FamiTone2:     186      3    1636

I was hoping for something in the code, but ok... No risk, no fun...

[tepples]

FamiTracker 0.4.2:
245 BSS, 20 zero page, 5547 ROM
FamiTone2:
186 BSS, 3 zero page, 1636 ROM
Pently, all features on:
104 BSS, 41 zero page, 1918 ROM
Pently, subset comparable to FamiTone2:
104 BSS, 41 zero page, 1283 ROM

Pently has a configuration file that disables features at assembly time to save ROM, though it's not yet smart enough to save RAM. Disabling vibrato, arpeggio, portamento, attack track, square pooling, channel volume, and notes higher than D-6 approximates the feature set of FamiTone2.

Would you consider using Pently? Or would I first need to add RAM compaction when features are turned off?

[dougeff]

There are some conditional statements in famitone2, it will use less RAM and ROM space if you reduce the number of sound fx channels.

Plus, you can remove the PAL note table, if you are very short on space.

[pubby]

Dunno if this is helpful or not, but my music engine uses 12 bytes ZP and 86 bytes in the stack. It can play most Famitone2 songs.

[Lazycow]

Thanks for the hints, I wasn't aware that there're so many music players out there.
I wanted to try another player anyway because of my failed attempts to do a DPCM-split.
But I'm not brave enough to select a music player before talking to "the" musician. (there's no musician for Wolfling, yet)
I'm keeping the 186-byte-famitone2 for now: Let's hope the documentation is correct...