It is currently Sat Nov 25, 2017 2:41 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 65 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Sun Sep 17, 2017 12:55 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19259
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sun Sep 17, 2017 1:31 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10120
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sun Sep 17, 2017 1:35 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19259
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Sun Sep 17, 2017 1:55 pm 
Offline
User avatar

Joined: Tue Jun 11, 2013 1:04 pm
Posts: 52
@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.


Top
 Profile  
 
PostPosted: Sun Sep 17, 2017 1:59 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Sun Sep 17, 2017 2:11 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19259
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sun Sep 17, 2017 5:29 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10120
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Mon Sep 18, 2017 12:32 am 
Offline

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


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 8:41 am 
Offline
User avatar

Joined: Tue Jun 11, 2013 1:04 pm
Posts: 52
Ok, I ram out of memory. :(
I wonder how much memory famitone2 uses at FT_BASE_ADR=$0100 ?
Can I check this somehow?


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 8:47 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 9:03 am 
Offline
User avatar

Joined: Tue Jun 11, 2013 1:04 pm
Posts: 52
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-)


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 9:16 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19259
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 9:50 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1835
Location: DIGDUG
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


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 10:08 am 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 211
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.


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 10:53 am 
Offline
User avatar

Joined: Tue Jun 11, 2013 1:04 pm
Posts: 52
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:


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 65 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group