Progress Thread - Wolfling

Moderator: Moderators

tepples
Posts: 21751
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Progress Thread - Wolfling

Post by tepples » Sun Sep 17, 2017 12:55 pm

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?
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.

User avatar
tokumaru
Posts: 11466
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Progress Thread - Wolfling

Post by tokumaru » Sun Sep 17, 2017 1:31 pm

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.

tepples
Posts: 21751
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Progress Thread - Wolfling

Post by tepples » Sun Sep 17, 2017 1:35 pm

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?

User avatar
Lazycow
Posts: 98
Joined: Tue Jun 11, 2013 1:04 pm
Contact:

Re: Progress Thread - Wolfling

Post by Lazycow » Sun Sep 17, 2017 1:55 pm

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

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Progress Thread - Wolfling

Post by thefox » Sun Sep 17, 2017 1:59 pm

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
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

tepples
Posts: 21751
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Progress Thread - Wolfling

Post by tepples » Sun Sep 17, 2017 2:11 pm

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.

User avatar
tokumaru
Posts: 11466
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Progress Thread - Wolfling

Post by tokumaru » Sun Sep 17, 2017 5:29 pm

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
Posts: 1016
Joined: Tue Oct 06, 2015 10:16 am

Re: Progress Thread - Wolfling

Post by calima » Mon Sep 18, 2017 12:32 am

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.

User avatar
Lazycow
Posts: 98
Joined: Tue Jun 11, 2013 1:04 pm
Contact:

Re: Progress Thread - Wolfling

Post by Lazycow » Sun Sep 24, 2017 8:41 am

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

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Progress Thread - Wolfling

Post by thefox » Sun Sep 24, 2017 8:47 am

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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
Lazycow
Posts: 98
Joined: Tue Jun 11, 2013 1:04 pm
Contact:

Re: Progress Thread - Wolfling

Post by Lazycow » Sun Sep 24, 2017 9:03 am

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

tepples
Posts: 21751
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Progress Thread - Wolfling

Post by tepples » Sun Sep 24, 2017 9:16 am

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?

User avatar
dougeff
Posts: 2614
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: Progress Thread - Wolfling

Post by dougeff » Sun Sep 24, 2017 9:50 am

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.
nesdoug.com -- blog/tutorial on programming for the NES

User avatar
pubby
Posts: 545
Joined: Thu Mar 31, 2016 11:15 am

Re: Progress Thread - Wolfling

Post by pubby » Sun Sep 24, 2017 10:08 am

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.

User avatar
Lazycow
Posts: 98
Joined: Tue Jun 11, 2013 1:04 pm
Contact:

Re: Progress Thread - Wolfling

Post by Lazycow » Sun Sep 24, 2017 10:53 am

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:

Post Reply