Transporting peristent RAM


nousername010 2020-12-09 06:26

Let PS be the program with the persistent RAM, and PD the program you want the persistent ram to be in.

There are two ways I discovered:

1.) Override the code of PS with PD's. This is useful for "updating" programs with later versions.

2.) Put some code in PS that copies all persistent data and saves it in a ROM, then run PS. Copy-paste the resulting ROM file from Disk.nx into PD, and then use another line of code to store it in PD's persistent RAM. Useful if you want to edit the save data yourself in another program (and cheat a bit).

What do you think?

G-9 2020-12-09 11:41

Whoa it's hard

nousername010 2020-12-09 13:00 (Edited)

Hopefully tomorrow, I'll upload a program that can edit the persistent RAM data of any program

Edit: Apparently, tools keep their own persistent memory, so using tools won't be possible. I'll make a sub instead.

nousername010 2020-12-09 15:07

Ok, persistent RAM acts a lot weirder than I expected! If you do a plain COPY $E000,4096 to ADDRESS, then unless you poked the entire RAM, you'll get nothing. You only get results if you use a for loop doing PEEK($E000+I).

Here are my subs:

FOR I=0 TO 4095
POKE $A000+I, PEEK($E000+I)

COPY ROM(ROMF),4096 TO $E000

was8bit 2020-12-09 17:13

This would be good for things like a colony game that saves your progression, then you can share your colony for others to play... as i am interested in making a colony game one day that uses both backgrounds to act as the games database array, and both BG's can be perfectly used with PERSIST, one could use your code to share their colony with others...

This is very much like game saves that were stored on the memory cards.. i have a memory card reader/loader that allowed you share copies of your game saves or even upload/download from the internet... i can't remember which system it was for, i am thinking maybe playstation1 ?

Timo 2020-12-09 17:36

If COPY doesn’t work, it seems to be a bug in LowRes NX. I will check it (eventually).

Timo 2020-12-09 19:41

Hm, COPY uses internally PEEK and POKE, so it should be the same behavior. I'll have to test it.

was8bit 2020-12-09 21:06


I successfully used...

COPY $E000,$1000 TO $9000
SAVE 14,"PERSIST",$E000,$1000

And my DISK file has the proper data saved :)

was8bit 2020-12-09 21:09 (Edited)

Try adding WAIT 30 after the first COPY command...

GAMELEGEND 2020-12-09 23:21

why do you have to wait

nousername010 2020-12-09 23:29

Thanks guys!

After experimenting for a while, turns out it wasn't the copy, but rather using the SAVE command in $E000 directly that returns nothing. The copy works fine, and it was just a mistake on my part :p

After even more experimentation, using SAVE directly on $E000 will only work if you wait a couple of frames, so your solution works a lot better. Thanks!

nousername010 2020-12-09 23:30

@GAMELEGEND Looks like we replied at the same time. Hopefully my reply explains it

nousername010 2020-12-09 23:33

@was8bit Yeah, I think it was the playstation. Though I wasn't there in the time of the NES and SNES, I think they rely on their own cartridges for persistent memory.

was8bit 2020-12-10 00:44

Hey, we help each other.. i am happy i could be helpful :)

was8bit 2020-12-10 01:13 (Edited)


Here is a novel idea...

FIRST, take a look at this picture, as it best describes my idea....


was8bit 2020-12-10 01:22

OK, so lets say i have a program called FARMER, which processes production of resources based on the available buildings and such

THEN you have a program called BUILDER, which builds new buildings and such based on the available resources and such...

NOW, lets say you load BOTH as TOOLS...

SO NOW, when you open up FARMER, you then select the tool BUILDER, and builder reads what resources are available from its rom, and edits the rom in FARMER as to what new buildings it builds..

SO THEN, when you open up BUILDER, you then select the tool FARMER, and farmer read what buildings are available from its rom, and edits the rom in BUILDER as to what new resources it creates..

In a way, you then greatly expand your ability to save massive changes on a map between runs by carefully balancing things out between the two....

was8bit 2020-12-10 01:44 (Edited)

So, to play the game, you run BUILDER with FARMER as its tool, to generate raw resources... when you need to build new buildings, you run FARMER with BUILDER as its tool, and build new buildings and such...

was8bit 2020-12-10 01:46

OR, it may be easier to have a BASE game, and simply open up a FARMER tool to farm, and open up BUILDER tool to build..

was8bit 2020-12-10 02:14

FINALLY, has anyone experimented with a program loaded as a TOOL, calling up itself as a tool to edit itself?

was8bit 2020-12-10 02:43


Try this out... save this program on your device.. while open, add it as a tool, then while the program is still open, select "itself" as a tool, and inside the tool, hit the (A) button, then close the tool..and PRESTO, data has been written in the created rom file ;)

Test Tool.nx | Open in app
2020-12-10 02:44

nousername010 2020-12-10 05:19

Nice! It works as intended.

That seems to be a good game idea, especially on PC since the program has an additional debug menu to quickly change tools

was8bit 2020-12-10 05:20

:D ... this discussion was totally fun :)

GAMELEGEND 2020-12-10 05:32

things like this are always so interesting

Log in to reply.