In an ancient thread, @dave mentions the frame buffer is in the data tcm area of the playdate's board. The total amount of data tcm memory dedicated to the screen should be 52 bytes per row * 240 rows = 12480 bytes (~12k) iirc. However looking at the datasheet for rev A and rev B it appears that the total amount of data tcm on both boards is >= 64k. I want to know where the rest of the tcm is being used. If it's free I want to know how to access it? Can I just read past the limits of the frame pointer?
2 Likes
Okay so I was able to read a lot of the dtcm but writing seems to crash things if I write in the wrong spots. @dave is it a security issue that I can poke around the dctm? If not would you be able to give me any hints about which parts you are using and which parts we can use?
The rest of DTCM is used for other system stuff. Writing into that will likely cause crashing and unstability. There are a few chunks of unused non-TCM memory scattered about but those are effectively reserved for future expansion: If someone publishes a game that takes advantage of it we either can't add a new feature later that needs that space or we break the game.
I totally get wanting to use every part of the buffalo, but there's an unfortunate conflict here. 
I would also love a way to store small amounts of data in TCM!
My use-case is a texture mapped triangle rasterizer, where I'm reading values from a 4x4 dither matrix for every pixel on the screen. I have an absolutely minuscule amount of data that's in a blazing-hot path, and from what I can tell using the Sampler, the vast majority of my runtime is spent just fetching the same few bytes from memory over and over again.
Even if it's absolutely tiny, the ability to use something like 256 bytes of TCM would be hugely useful (for me, at least). I recognize the issue with allowing access to something that is otherwise needed by the system, but it might be possible to mitigate the damage through the API. Something like...
void* playdate->system->loadTCM(const void* data, uint8_t size);
This API would be identical between the PlayDate and the Simulator, and could gracefully fall back to a standard memory allocation when TCM isn't available for whatever reason. Games which relied on TCM for performance would likely run very slowly, but wouldn't break completely.
It still doesn't solve the underlying issue of system updates potentially impacting games in a way which can't be mitigated by the developer. That's still an unsolvable problem, but I could do a lot with 256 bytes of very fast memory! 
Hey Andrew. It turns out there is a better answer to this question after all. The entire stack (10kb) is in the dtcm so if you use stack variables everything will be fast. I'd recommend checking out the #dev3d channel on the playdate discord (Discord) where people are using tricks like this and more if you haven't already! I use this trick my game Jump Truck if you're curious about if this holds up in production
2 Likes
Well that's excellent to hear (and makes a lot of sense in hindsight, lol)!
I'll have to experiment with copying data into the stack at the start of my draw loop. 