A lot of old games save space by using the same data for multiple purposes. I’ve seen code used as graphics, code inside graphics, graphics containing map data, and was daydreaming what parts of pico8 could be interesting to use as double purpose.
The game thumbnail seems very promising : 128x128 32 Colors is 10Kb worth which is pretty big for pico8.
There ´s nohing in the api related to it, just a keyboard shortcut to save the current screen to it. It’s hidden when using the built in editor, but you can see it when viewing a .p8 file.

I’m a newbie in lua, and don’t know if it’s a valid lua section, or maybe a type of multi line named comment designed for documentation for example.
Or maybe it’s just part of the .p8 format and never passed to the interpreter ?
If there’s a way in code to interact with it, I’d love to know.
Or maybe the source code is somehow in the scope of the program and can be opened and parsed ?

the cart label is not officially part of the ROM format
(it’s saved in P8 carts because that’s more convenient that a separate image file for example, but it’s nort part of the data hidden in P8PNG carts or the 32k tiny ROM format)

it doesn’t fit the console fantasy that we would be able to access it. but the code section can encode lots of bytes as strings (see https://www.lexaloffle.com/bbs/?tid=38692) and the data sections can be used freely outside of their default role of sprites/map/sfx/music!

Thanks for the answer, it makes sense for a cart game to not have a way read its own pseudo paper label... Bummer.
Using strings to encode data makes too much sense, I'm after the madness more than I'm after the data space, but will remember it, should the need ever arise.
I think I know what I'll try : pure vanilla "just use the map and the sprites" cart, except I'll use full map and full sprites at the same time, so the overlap section will have to make sense at the same time as graphics and as map. I'll start with the overlap section and discover what the game is about along the way :)

I think lget() and lset() would make great additions, allowing for retrieving and setting data in the label image. L standing for "label", of course.

lget is what I was after, lset would be pretty wild : imaging playing zelda on the nes, and find out that the number of hearts and the inventory of your save is visible on the label of the ejected cart :p
Having e-ink labels on carts might actually be an interesting idea, especially for consoles where the inserted cart remains visible...
Think mini auto-maps, secrets, save file summuary, achievements that would remain visible when the cart is powered down...

I disagree that they would be good additions, as the label data is not part of the ROM, but a representation of the physical printed sticker label

note that there’s already a trick to get extra spritesheets: https://www.lexaloffle.com/bbs/?pid=103168

e-ink labels would be fun, although evoking memories of a wholly different generation: dreamcast vmu! :D
this could be done with the gpio interface on raspberry pi and a microcontroller

Wow, the vmu is so cute.
A dpad, buttons A and B, Pause and Reset, but only 48x32 pixels, it's clearly a knock-off of the superior Pico 8 :p
On the other hand, it scores very high on the buttons per pixel video game console rating.
I can think of a few with better scores, but there's usually a catch :

• The light switch, with a score of 1, that has a screen life of a few seconds when you start to play seriously.
• The car keycard, that has a good score, but significant input lag and horrendous display price.
• The micro-wave, with and enormous score of 2, but that tends to overheat or even explode when played without proper input.

Finally, the best no drawbacks is the Merlin with its slightly more than 1 score (15/11), its touchscreen where every pixel has a dedicated button, several build-in games and a digital sequencer !

Hey @ooooggll , @merwok
Turns out we already have lset :
extcmd("label") that does the same thing as pressing F7 : saving what's currently on screen as the current label.
This is useful to programmatically choose the perfect frame for your label during development, But the label is only really added to the cart once you manually save your project, so using the command in a BBS cart would do absolutely nothing, since you can't save the modified label programmatically... Unless cstore that allows to modify the local copy of the memory mapped part of a cartridge also commits the label change ? Probably not but you never know, I'll try.

I believe that extcmd is meant as a helper for development
it has no incidence on label data not being accessible at runtime