As many of you may be aware, you can indeed load and save 256-bytes of data broken down to a storage of 64-numbers using conventional method commands of CARTDATA(), DSET(), and DGET().
However, if you want more than this, you will have to use unconventional method commands of CSTORE and RELOAD.
What follows is a sample program I wrote to demonstrate writing 8-bytes to an external file and reading it back again. You can actually load and save up to 🔺8192-bytes of storage this way so it is not to be overlooked !
Definition and instructions are below:
this fairly complex program will load data from an external binary file and display the results. after this, with the mode set to zero (0), it will save the select text to the select external file so the next time you run, you will be able to confirm it is loaded correctly. note ! this will not work as a true compiled exe or if you are attempting to run it directly from splore. you must save this .p8 to your local hard-drive and execute it -or- run it from an internet online page. if you have any questions or comments, please let me know! |
Wow, Pretty Neat! I don't have any need of it yet, but I will remember this.
Just know it breaks down and doesn't work properly if you try to compile to EXEs, .JS (run locally), or run from SPLORE.
Hopefully this will be fixed by ZED soon ...
Multicarts don't work on the BBS or SPLORE, but they should work as binaries or HTML export? Make sure you EXPORT all the cartridge files.
Hi Tobiasvl:
- Yes, they work exported to .JS but only =IF= they are run from a true Online site, like Itch.
If you try to run the .JS locally, no, you can't do the multicart saving and loading. Tested with Firefox.
OK. I wonder why that doesn't work, but I also wonder why you're running the JavaScript version locally. Surely the binaries support it locally, though? What's the problem there? I'm pretty sure there are multicart games distributed as binary executables.
Testing to see if I can run the HTML and .JS locally as I have a program to convert HTML to EXE in case ZEP's own EXE balked (which it did).
But no, all three of running the EXE, locally running the HTML & .JS, and running your cart from SPLORE - they all fail. You can test this yourself.
I'll take you on your word, but note that SPLORE is supposed to fail - the BBS (which SPLORE uses) doesn't support multicarts, and likely never will, according to @zep in the post I linked above.
OK, I tested it anyway, and it seems you're right. Doesn't work with binary or HTML export.
However, for me it doesn't work with the HTML export even if I upload it to itch though.
I made two test carts, test1.p8 and test2.p8, where test1.p8 reloads from and cstores to test2.p8, and exported them to web. This is what I see in Chrome and Firefox's developer consoles (both locally and on itch). This is on Windows btw.
Reload() does work, but either cstore() doesn't update the cart, or subsequent reload()s always just re-reads the original cart.
Boot:
Navigated to file:///C:/Users/tvl/AppData/Roaming/pico-8/carts/test1.html test1.js:261 >codo_init test1.js:261 platform: Emscripten test1.js:261 codo_system_init test1.js:261 codo_reset_timer test1.js:261 codo_gui_init test1.js:261 codo_keys_init test1.js:261 codo_text_init test1.js:261 codo_video_init test1.js:261 codo_mouse_init test1.js:261 codo_joystick_init test1.js:261 <ok test1.js:261 codo_fopen data.pod (rb) opened test1.js:261 codo_load_pod: data.pod ok test1.js:261 codo_set_screen 128 128 8 100 test1.js:261 set pixel_perfect 1 test1.js:261 codo_sound_init mix_buffer_size: 1024 test1.js:261 audio_init test1.js:261 Sample Rate: 44100 test1.js:261 mounting /user_data test1.js:261 codo: mounted filesystem. test1.js:261 found directory: /user_data/cdata test1.js:261 found directory: /user_data/cstore test1.js:261 found directory: /user_data/carts test1.js:261 starting download.. test1.js:261 0 test1.js:261 loading embedded cartridge test1.js:261 codo_fopen /user_data/cstore/__f15ee4fa2c340c2d3f83e91138e16724fb766088.p8 (r) failed test1.js:261 @ mount_embedded_cart: test1.p8 f15ee4fa2c340c2d3f83e91138e16724fb766088 test1.js:261 @ mount_embedded_cart: test2.p8 d6fa7b88fa333166a5c47070d2fe1ca54d1e9e6a |
Reload (from test2.p8):
codo_fopen /user_data/cstore/__d6fa7b88fa333166a5c47070d2fe1ca54d1e9e6a.p8 (r) failed test1.js:261 sandboxed_cstore file not found: /user_data/cstore/__d6fa7b88fa333166a5c47070d2fe1ca54d1e9e6a.p8 test1.js:261 --> using internal file: test2.p8 test1.js:261 reload()ing 1 bytes from: test2.p8 test1.js:261 codo_fopen test2.p8 (rb) failed test1.js:261 -> returning vdisk file: test2.p8 (rb) test1.js:261 codo_fopen test2.p8 (r) failed test1.js:261 -> returning vdisk file: test2.p8 (r) |
Cstore:
p8_cstore: storing 1 bytes as: /user_data/cstore/test2.p8 test1.js:261 codo_fopen /user_data/cstore/test2.p8 (r) opened test1.js:261 codo_fopen /user_data/cstore/test2.p8 (wb) opened test1.js:261 warning: 2 FS.syncfs operations in flight at once, probably just doing extra work |
Maybe you should move this thread to "Support" and hope @zep sees it. He did say in his blog post that this was supposed to work with the HTML export, and that binary support would come soon (although I haven't checked if he later wrote that it was released in a later version).
Nice to know I'm not the only one suffering from this lack of total recall - well, there it is.
Yes, I'll forward this to SUPPORT. Good idea, T.
And just for good measure, I reproduced it on Linux, with the Linux executable and in the browser.
I reproduced the error on Linux, meaning it did not work there either.
Wow ... So ... maybe ?? ZEP will get it working.
If he's worried about security, he could always store the files encrypted deep in \users\ data, but still accessible to the program both for reading and writing.
Wow ... So ... maybe ?? ZEP will get it working.
If he's worried about security, he could always store the files encrypted deep in \users\ data, but still accessible to the program both for reading and writing persistent data exceeding 256-bytes.
weird.
here's a related thread: https://www.lexaloffle.com/bbs/?tid=29986
the cart I posted there still works (albeit with a typo that makes it write on "itself", hence the colored pixels)
I just exported it to html and bin, works ok...
[Please log in to post a comment]
