Hey I've been using Pico-8 for a few weeks and having tons of fun and I just worked out how to download other peoples carts so I can see their code and how they did stuff. On page 2 of the sprites in Celeste and the same with some of the other games is like a map things and I think I'm being really stupid but is it a representation of the sprite placing editor thing? If so why add those last two images to view? Thanks for any information I'm really interested.
Below: screenshot of what i mean from Celeste.

Cheers podfish

You can choose to use that part of memory both for a bigger map or for more sprites. If you figure out, how the map is placed there, you can easily share it for both, that's why you always see the memory in both editors.

Hi Podfish,

The last two pages of the spritesheet are shared with the bottom half of the map data. Basically, you can either choose to have more sprites or a larger map.

The thing to keep in mind is that the system doesn't know whether you meant to have it one way or the other. So if you are using the full map size and look at the last page of sprites, you will see garbage on the screen. This garbage is the editor trying to read data for a map cell as a sprite pixel.

You have made the right conclusion.
The page 2 and 3 of the sprite sheet use the same memory as the bottom half of the map sheet. The idea is that you can choose between using more sprites or using more map. For example, you can use page 3 for more sprites and let page 2 empty so your map data can use the top 3/4 of the map sheet.
Have fun experimenting with pico 8.

This reminds that I'd been wondering if anybody's managed to actually cheekily overload this to work both ways yet.

This is, come up with a mix of sprite and map design decisions for a game such that recognizeable, usable sprite pixel art on pages 2 and 3 is rendered by useable map layouts on the lower end of the map sheet.

@josh - well, if you have enough tokens left, you can always generate the map programmatically. Just make an object/table with tile numbers from the sprite sheet, and fill the screen with them as sprites. That's (basically) how the start of a procedural map generator would work, except in this case you're telling it what to put where instead. This way you can use the full sprite sheet and none of the map (or, to save tokens, you can use the half of the map that isn't shared, then generate the rest of the maps).

Oh, sure. I'm not thinking so much about map-management ideas (which are also interesting and in general a hell of a lot more useful to boot) as about the pure stunt-for-stunt's-sake idea of devising sprite sheet content that doubles as map sheet content in a non-gobbledygook way.

I'm working on a game that has a large title graphic stored in map memory. I have a few lines of code that iterate through the map and call pset to render the image.

The game procedurally generates its maps, so the title graphic gets clobbered. When it's game over and time to go back to the title screen, I call reload to load the title graphic back into map memory from cart rom.

I'm so overwhelmed by the quick and great response! Thank you so much everyone really cleared up my confusion :D
Thank you