I wonder - did anyone successfully decode the storage order within the sfx section of a cartridge? I managed to do this with the music section, but the values under sfx seem to behave very strange there, I can't find a practical pattern how the bits are distributed there.
I need to write binary data from within my python script and now I exceeded 0x3200, so this is a real show stopper for me at the moment, any help is appreciated!

Yet I know:

• each line stores 68 bytes of data
• each byte is distribute with some of its bits to several locations in this line. Filling all bytes with 255 results in a sequence of 3f77f
• there is a special "header" to each line, consisting of five bytes, which are the last ones in memory and which are not distributed otherwise

What is yet missing:

• The distribution pattern of the "regular" bytes

I documented the file format in the source of my picotool library (which you may find useful if you're using Python to generate carts):

https://github.com/dansanderson/picotool

sfx specifically:

https://github.com/dansanderson/picotool/blob/master/pico8/sfx/sfx.py

Great, you're a life and time saver :) Thank you!

Edith: Ehm... Does that mean, not all bits from the RAM are accessable in the P8-file...? I refer to:

The highest bit appears to be unused. In RAM, Pico-8 sets it for the 2nd note in the pattern for some reason, but this is not written to the PNG.

Correct, at least as of when I wrote that. (IIRC that was Pico-8 v1.4. I have not re-verified some of these assertions in 1.5.) That bit is always written out as 0. I recall testing this by poking values into RAM and saving, but I don't recall if I tested going the other way (writing arbitrary values to the file and loading into RAM).

And this is based on black box testing, so maybe there's a use for that bit that I just haven't discovered. I only know it doesn't get written, as of 1.4.

Currently, I get some really strange effects. Although the bit seems to be stored now (Filling 68 bytes with 255 results in a line

ffffffff3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f3f77f

), the memory is only valid filled after restarting and reloading, if the cart is saved again. Before that, all bytes from 12800 are zero. I press ctrl+s and I get 255 from that very same address.
Edith: The memory is not valid after resaving, but by pressing esc, entering the editor and switching back.

Hi,

I dont know if it can be of any help but I tried to store data in sfx sections before (as I wanted to cache an entire screen frame contiguously in ram) but I had trouble with memory there.

Basically there was an issue when peeking from sfx memory, some bits were masked out / overwritten. Zep has fixed that in 0.1.3 normally (so quite long ago) but maybe there is still a problem there

So, for the sake of documentation, this is the bit pattern in detail:

0000000000000001 = 00400
0000000000000010 = 00010
0000000000000100 = 00020
0000000000001000 = 00040
0000000000010000 = 00001
0000000000100000 = 00002
0000000001000000 = 00004
0000000010000000 = 00008
0000000100000000 = 01000
0000001000000000 = 02000
0000010000000000 = 04000
0000100000000000 = 08000
0001000000000000 = 10000
0010000000000000 = 20000
0100000000000000 = 00100
1000000000000000 = 00200

Now I only need to encode the data this way and I should be fine. But not today, my bed is calling ;)

So, finally I was able to finish the writer code with the given bit pattern. For the records, ALL bits are read from the cartridge, so there is no problem to store binary data there. This gives each cartridge 17kb memory to store data in, nice.