nesdev.com
http://forums.nesdev.com/

Progress Thread - Wolfling Zero
http://forums.nesdev.com/viewtopic.php?f=33&t=16143
Page 3 of 6

Author:  tepples [ Sun Sep 17, 2017 12:55 pm ]
Post subject:  Re: Progress Thread - Wolfling

Lazycow wrote:
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?

Quote:
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.

Author:  tokumaru [ Sun Sep 17, 2017 1:31 pm ]
Post subject:  Re: Progress Thread - Wolfling

tepples wrote:
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.

Author:  tepples [ Sun Sep 17, 2017 1:35 pm ]
Post subject:  Re: Progress Thread - Wolfling

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?

Author:  Lazycow [ Sun Sep 17, 2017 1:55 pm ]
Post subject:  Re: Progress Thread - Wolfling

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

Author:  thefox [ Sun Sep 17, 2017 1:59 pm ]
Post subject:  Re: Progress Thread - Wolfling

tokumaru wrote:
tepples wrote:
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

Author:  tepples [ Sun Sep 17, 2017 2:11 pm ]
Post subject:  Re: Progress Thread - Wolfling

Lazycow wrote:
Anyway, optional direct decompression to CHRRAM would be nice, too. 8-) 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.

Author:  tokumaru [ Sun Sep 17, 2017 5:29 pm ]
Post subject:  Re: Progress Thread - Wolfling

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.

Author:  calima [ Mon Sep 18, 2017 12:32 am ]
Post subject:  Re: Progress Thread - Wolfling

tepples wrote:
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.

Author:  Lazycow [ Sun Sep 24, 2017 8:41 am ]
Post subject:  Re: Progress Thread - Wolfling

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

Author:  thefox [ Sun Sep 24, 2017 8:47 am ]
Post subject:  Re: Progress Thread - Wolfling

Lazycow wrote:
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.

Author:  Lazycow [ Sun Sep 24, 2017 9:03 am ]
Post subject:  Re: Progress Thread - Wolfling

Ah, ok. This one?
Code:
               RAM     ZP     ROM
FamiTone2:     186      3    1636

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

Author:  tepples [ Sun Sep 24, 2017 9:16 am ]
Post subject:  Re: Progress Thread - Wolfling

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?

Author:  dougeff [ Sun Sep 24, 2017 9:50 am ]
Post subject:  Re: Progress Thread - Wolfling

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.

Author:  pubby [ Sun Sep 24, 2017 10:08 am ]
Post subject:  Re: Progress Thread - Wolfling

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.

Author:  Lazycow [ Sun Sep 24, 2017 10:53 am ]
Post subject:  Re: Progress Thread - Wolfling

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... :shock:

Page 3 of 6 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/