It is currently Wed Nov 22, 2017 7:04 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 26 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Program code in WRAM
PostPosted: Sat Sep 16, 2017 7:40 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3951
Aplib has the two cases for small amounts of recently appearing data:

111, xxxx: (7 bits) any recent byte in last 16 bytes
110, B: (11 bits) length 2 or 3, offset 01-80

So single bytes that appeared recently eat up 7 bits of space, and 2-3 byte long sequences that recently appeared eat up 11 bits of space.

Meanwhile, huffman has to include a table before the compressed data can appear. But the compression can be good for bytes that appear frequently throughout the data, regardless of position and surrounding bytes.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject: Re: Program code in WRAM
PostPosted: Sat Sep 16, 2017 11:32 am 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1467
Bregalad wrote:
As a side note, if you're going to have code sit in WRAM anyway, you might as well compress it so you can save PRG-ROM (in this case, if this can make your game fit in 128 KB PRG-ROM instead of 256 KB PRG-ROM).

I don't think the source code will be the thing that decides whether I need 128 or 256 KB. The deciding factor will be the game world data, the music and especially the dialogs.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
 Post subject: Re: Program code in WRAM
PostPosted: Sat Sep 16, 2017 12:11 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1467
By the way, are there speed differences between reading code from WRAM vs. reading it from regular ROM?
I'm asking, so that I know whether I should rather put the time-critical code into RAM (like sprite updates) or the code that is done when rendering is turned off (like CHR RAM updates).

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
 Post subject: Re: Program code in WRAM
PostPosted: Sat Sep 16, 2017 1:18 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6448
Location: UK (temporarily)
NES CPU always operates at the same speed, regardless.

The big speed boost you get for code in RAM is self-modifying code.


Top
 Profile  
 
 Post subject: Re: Program code in WRAM
PostPosted: Sat Sep 16, 2017 6:21 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3951
Yeah, you get lda #xx \ sta $2007 loops when you use self-modifying code in RAM.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject: Re: Program code in WRAM
PostPosted: Sun Sep 17, 2017 12:21 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7272
Location: Chexbres, VD, Switzerland
DRW wrote:
I don't think the source code will be the thing that decides whether I need 128 or 256 KB. The deciding factor will be the game world data, the music and especially the dialogs.

Definitely, but you can also compress those. For instance, you could use the same Huffman compression with a different Huffman table adapted to the type of data to be decompressed.


Top
 Profile  
 
 Post subject: Re: Program code in WRAM
PostPosted: Sun Sep 17, 2017 12:26 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1467
Maybe later. First I'll have to see how much stuff we even have. And counting on 256 KB means that I don't have to worry about space and we can also add some high quality in-game artworks to the unused ROM. A situation that will probably not happen if I aim to fit everything into 128 KB.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
 Post subject: Re: Program code in WRAM
PostPosted: Sun Sep 17, 2017 2:04 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7272
Location: Chexbres, VD, Switzerland
Well, using 256 KB doesn't prevent you from compressing data and code to make even more of it fit.


Top
 Profile  
 
 Post subject: Re: Program code in WRAM
PostPosted: Sun Sep 17, 2017 2:23 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1467
I assume using 256 KB is more than enough, so that I don't need to compress data. Maybe compressing dialogs to six bits per chacter instead of eight, but not much more.

If I don't use bankswitching for code, I can only use up to 8 KB of uncompressed additional code anyway: The space in WRAM.
And since, for data, the 15 switchable banks are probably more than enough for my whole game, what would be the advantage of compressing 8 KB of additional code, so that it takes a bit less space in the switchable bank of which we have more than enough anyway?

There's plenty room for game data (graphics, dialogs, enemy behaviors etc.): 15 x 16 KB.
But there's only 16 KB for code and maybe up to 8 KB if it's really necessary. Unless I want to fiddle with bank switching. Which I only want to do for data, not for code.

So, wasting code space for a compression algorithm, to compress data for which we just got twice as much space as originally intended, is a bad idea in this constellation.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
 Post subject: Re: Program code in WRAM
PostPosted: Sun Sep 17, 2017 4:45 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10117
Location: Rio de Janeiro - Brazil
Prematurely worrying about compression is definitely a bad idea.


Top
 Profile  
 
 Post subject: Re: Program code in WRAM
PostPosted: Mon Sep 18, 2017 2:41 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7272
Location: Chexbres, VD, Switzerland
tokumaru wrote:
Prematurely worrying about compression is definitely a bad idea.

Well I am extremely biased as I love fitting everything in a PRG-ROM as small as possible. In my game engine many things are compressed, code (in the form of interpreted bytecode instead of compressed 6502 code), levels, metasprites. Only small things such as code run every frame, palettes and level metatile definition aren't compressed. I even wrote CompressTools for the sole purpose of studying as much as possible about compression and be able to customize my compressions.

Quote:
If I don't use bankswitching for code, I can only use up to 8 KB of uncompressed additional code anyway: The space in WRAM.

Wrong, WRAM is rewritable so you can put as much code as you want there, just only 8KB at the same time.
To be honest copying only <8kb of code here to never touch it ever again makes few sense, basically it'd be just a small expansion on the fixed bank. However doing that multiple times and treat the WRAM area as an additional bankswitch room (where bank-switching is slow) makes more sense.

In the case of a JRPG, you could have the battle code loaded when starting a battle, the menu code loaded there when you open the menu, the dialogue box code loaded there when opening a dialog box, etc, etc... You could even have more than one bank, say, two 3kb banks and this leaves 2kb for save game data. Decompressing 3kb of code should take about one frame, and when you do it you have it at your disposal in WRAM.

You also get the gain of possibly self-modifying code, which can in some cases be faster (however it can also become a headache). If a RAM variable is only loaded at one place, for instance, you can just use LDA #imm and change the immediate as it is the variable itself. You can also change JMP and JSR adresses on the fly.

Quote:
And since, for data, the 15 switchable banks are probably more than enough for my whole game, what would be the advantage of compressing 8 KB of additional code, so that it takes a bit less space in the switchable bank of which we have more than enough anyway?

There's no point in decompressing code in WRAM only once and never touch it again, that'd be insignificant as you pointed out.

Considering what I stated above, which holds ture when using compression, then it suddenly makes a lot more sense as you can compress a lot more code that way, of course not the whole game's code, as you have constraints that is only <8kb of decompressed code at the same time and it takes time to rewrite it with other code, but you could compress a significant part of the code that way. It makes sense in the general case, but maybe not in your specific case. I don't know, as tokumaru said it's too soon to know but I thought it would just be good for you to know about the possibility (without using it), and resorting to it later if the situation ever calls for it.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 26 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: ReverendSA, tepples and 10 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