The sign of victory ! It's been a good day !
Here is the code I wrote for it:
--[[
------ f i l e - 8 k ------
program to test saving off
more than 256-bytes of
persistent data despite any
version changes.
big props to tyroney and
rytrasmi for having the
patience to teach me this. :)
--]]
function main() -- begin
pic={} -- empty array
-- generate serious nonsense
for i=0,8191 do
pic[i]=flr((i+i*1.77))%256
end
-- how much ram do i have left?
-- :)
-- show a bit of it
cls()
for i=0,8191,255 do
print(pic[i])
end
getkey("ready to convert")
for i=0,8191 do
poke(24576+i,pic[i])
-- save it out
end
getkey()
cstore(0,24576,8192,"_data.p8")
-- save screen at memory loc 0
cls()
getkey("saved")
getkey("ready to load")
reload(24576,0,8192,"_data.p8")
-- load 8k at screen start
getkey()
pic=nil -- erase array !
pic={}
for i=0,8191 do
pic[i]=peek(24576+i)
-- get it all back
end
cls()
for i=0,8191,255 do
print(pic[i])
-- proof is in the pudding !
end
getkey("complete !")
end
-- end of main
-- simple get and wait key [a]
function getkey(t)
if t!=null then
print""
print(t.." - press [a]")
end
repeat
flip()
until btn(4)==false
repeat
flip()
until btn(4)
end--getkey
main() -- nifty put at top
|
Ah, it works now ! Umm ... ??? Something strange somewhere. It's the same code, but pasted as CLIPBOARD instead of CART. Glad it works now ! :D
I am SO going to use this in my PICO notepad program.
Huzzah ! Broke the 256-save-byte barrier and now you guys can save 8k at a time !
Alrightee, let's see if I can load the same data back with this modded cart that only loads. If it works, that means ANY program can load any other data file from any other PICO cart, no matter where it is.
You can confirm this by seeing it is two different carts (compare ID numbers) are loading the same Online data file.
UBetcha ! This is so cool ! I was thinking for a-while there I was gonna be stuck with only 256-bytes to save.
This ? tapping finger This is so much more. I suspect I can write a neat little miniature RPG Maker too. A topic and code I'm always dabbling in.
I don't understand the significance of this...you mean you discovered cstore? A built-in, documented function that everyone already knew about?
Or is there something else I am not noticing? Please correct me and forgive my ignorance if I am missing something here!
Man you made me dig for it ! :)
Read this article and I was led to believe that PICO can only work with 256-bytes of save data.
https://www.lexaloffle.com/bbs/?tid=27657
"64 values of save data ain't enough for you? Try using this! These functions will allow you to save up to 2,048 values in persistent data! If you only accepted ON and OFF as acceptable values."
Add up those bits and you can see it is exactly 256-bytes.
Additionally my method does not cut into any image tiles, the mapper, the sound generator, or the music generator. It leaves those clean and clear even if you've filled them all up with your cart.
It should be at the top, but if it isn't, you can find my Notepad cart which directly makes use of this good knowledge HERE:
Well, those 64 values are indeed marked specifically for saving data, where as cstore/restore is just for editing cartridge data and if you using it as save storage, you're also just sacrificing up another part of your cartridge for more save space.
Gamax, all it is doing is saving 8k to a different cartridge. You use the word sacrifice. Is there some way to SEE with memory numbers how this is and could ever be a problem ?
Also, understand I am not the only one doing this. I got intrigued with this save method when I originally saw this program, written by Blokatt, who is also saving more than 256-bytes of persistent data.
The readme is a wonderful thing:
Each cartidge is able to store 64 numbers (256 bytes) of persistent data on the user's PICO-8 (rather than on the cart itself). This can be used as a lightweight way to store things like high scores or to save player progress. If you need more than 256 bytes, it is also possible to write directly to the cartridge using cstore(). The disadvantage is that the data is tied to that particular version of the cartridge. e.g. if a game is updated, players will lose their savegames. Another alternative is to write directly to a second cartridge by specifying a fourth parameter to cstore(). This requires a cart swap though (so is slightly slower), and leaves data-cart litter when run from a local folder. |
For those who are looking for a demo of saving large amounts of data, be warned: I believe the op doesn't work with a normal _update()/_draw()-using cart, since he's using the screen as scratch space and doing his own flip()s at specific times to ensure the scratch space doesn't get wiped out by his draws. A more robust solution would be to store data into a bit of scratch space in your cart that is unused (eg a section of your sprites, map, music, or sfx -- see the pico8.txt for addresses) and poke/cstore/reload/peek into/out of that. You can also store a lot more than 8k of data.
Like this:
I pulled 16k out of thin air -- I believe you can store up to 32k, though working around the 32k limit on numbers was too much bother for this 20 minute demo.
Fweez, for my notepad program, I am ONLY using the screen space temporarily when saving the notebook pages.
Once I do that, I quickly redraw the screen. All other times the data is kept in a simple basic global MSG[8192] array that doesn't touch screen, tiles, map, sound, or music.
No need to see a problem when there isn't. :)
And your method (which takes a-while) winds up only saving 16384 bytes. I could do it a whole lot faster in 2 8192-byte chunks with my code and still affect no tiles, map, sound, or music.
[Please log in to post a comment]
