Page 1 of 2

Program code in WRAM

Posted: Sat Sep 16, 2017 3:46 am
by DRW
I like my code to remain in the fixed bank because I think switching the bank is too risky and too much of a hazzle. That's why I attempt to use the switchable banks only for data.

But now that my game uses MMC1 with battery save, I thought of a way to extend the available room for code should it ever become too small:

Would it be possible to use the otherwise unused space in WRAM for code?
You store the code that doesn't fit into the fixed bank anymore somewhere into another bank. And at program startup, you copy that code from the other bank into WRAM. Now you have up to 8 KB (minus the stuff you need for savestates) as additional always available program code.

Would this be possible?

The only problem that I see is: The WRAM has different addresses than the switchable bank. How do you organize your source code, so that you can still call these functions normally?

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 3:58 am
by tokumaru
Yes, you can do this. You just have to assemble the code with an origin of $6000, even though it will be mapped somewhere else in ROM when you're copying it to RAM.

In ca65 you could probably create a memory section with start = $6000, size = $2000 and one or more segments that use it. Then, at run time, you'd switch to the bank that contains that chunk and copy it to WRAM. From then on you can use the code in WRAM as you would any code in ROM.

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 4:02 am
by DRW
But how do I do this in practice, namely in cc65?

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 4:10 am
by tokumaru
Edited my post. I'm not sure about C code, but what I wrote is what I'd do for assembly.

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 4:23 am
by DRW
I know how to create the stuff in the cfg file and how to prepare the code in the bank, but I don't know how to make the compiler know the function addresses in WRAM, except for the first function:

Code: Select all

.segment "SWITCHABLE_ROM_BANK"

Function1Rom:
    BLA
    RTS

Function2Rom:
    BLA
    BLA
    RTS

.segment "WRAM_CODE"

Function1:
    ; Do nothing.
    ; After the copy process,
    ; the code from Function1Rom
    ; will be here.
But how do I make the compiler/assembler know the RAM address for function 2?

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 4:29 am
by tokumaru
Everything you put in the "WRAM_CODE" segment should use addresses in the $6000-$7FFF area if that segment uses a MEMORY area of start = $6000, size = $2000.

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 4:37 am
by DRW
So, I assume I have to do something like this?

Code: Select all

Function2 = WRAM_CODE_LOAD + Function2Rom - SWITCHABLE_ROM_BANK_LOAD

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 4:44 am
by thefox
Use the LOAD and RUN attributes in your linker configuration file: http://cc65.github.io/doc/ld65.html#ss5.4

Point the LOAD attribute to ROM, and the RUN attribute to WRAM. Then you can use define=yes to get the linker to define symbols which you can use to copy the data from ROM to WRAM.

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 4:48 am
by DRW
I didn't know there was a RUN attribute.

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 5:02 am
by tokumaru
Oh crap, I forgot about LOAD and RUN!

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 5:11 am
by DRW
Looks like this is really the most elegant solution. Thanks for that hint.

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 6:17 am
by Bregalad
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).

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 6:46 am
by tepples
What codec is effective for 6502 machine code?

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 7:01 am
by Dwedit
There is Aplib/pucrunch, or huffman.

Re: Program code in WRAM

Posted: Sat Sep 16, 2017 7:09 am
by Bregalad
I'd bet on Huffman since it could encode frequently used opcodes on few bits. I'm kind of fond of Huffman personally, it compress almost everything well.