Program code in WRAM

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Program code in WRAM

Post by Dwedit »

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!
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Program code in WRAM

Post by DRW »

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.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Program code in WRAM

Post by DRW »

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).
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Program code in WRAM

Post by lidnariq »

NES CPU always operates at the same speed, regardless.

The big speed boost you get for code in RAM is self-modifying code.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Program code in WRAM

Post by Dwedit »

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!
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Program code in WRAM

Post by Bregalad »

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.
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Program code in WRAM

Post by DRW »

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.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Program code in WRAM

Post by Bregalad »

Well, using 256 KB doesn't prevent you from compressing data and code to make even more of it fit.
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Program code in WRAM

Post by DRW »

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.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Program code in WRAM

Post by tokumaru »

Prematurely worrying about compression is definitely a bad idea.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Program code in WRAM

Post by Bregalad »

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.
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.
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.
Post Reply