You still didn't read, or you didn't understand and did not ask.
First of all, "I converted my map data to {C}" really doesn't mean anything. Not just because we're in Axe, this time. I don't think that could mean something in another language.
Then, "[22]→{127+C}" tries to store a pointer to [22] (which is not the hex value 22 but a 2-byte number) in the one byte located in 127+C. Same with "[22]→{128+C}".
So I think you didn't "convert" anything (because there is no such thing as "conversion" in Axe), then you stored random numbers in two bytes, so I don't see why your picture would not be completely different.

Would you mind sharing the complete code ?

I have another question. Is every two character in the gdb as one byte or is it 2?

I see you didn't read what I wrote.
"In the GDB" doesn't mean anything, the GDB is a number, a pointer, not an object with numbers inside.
And every pointer points to one byte, but you can read 2 bytes at once, or 4 if you want, or interpret a sequel of 11 bytes as a string, etc, they don't have a size, it is just you deciding when putting them in your program what they represent.

Then optimize, there is not much to do for the moment. Or if you don't manage to, you can also get all your data in external appvars and keep only the code in the app.

"GDB" is nothing but a name. You could have put "°TheMap" or "Str12" instead of "GDB1". I just say that because some people confuse pointers with objects and feel like they're declaring some structure when doing →GDB1.

And changing an element is easy. If you want the first byte in the free RAM area starting at L1 to be 1, you do 1→{L1}, right ?
Well if you want your 58th byte in the RAM area that is your map starting at GDB1 to be 18, you do 18→{58+GDB1}.
And if you can change each element, you can change tows, etc.

Just note that, as I said, that works everywhere in RAM (even in places you shouldn't write to) but nowhere else, so if you compiled your code as an app, it will be run from Flash and you "can't" modify anything there, so you'll have to use workarounds like appvars, or to copy data in free RAM areas first. But if you didn't compile as an app, forget that last sentence.

Yeah, I could do that. Even easier to code and even smaller.

Or do you feel that if there were more parts than two in my transition, it would give less headaches ? I mean instead of " first half goes up and last half goes down", something like "first 8 columns go up, next 8 columns go down, next 8 go up, etc". Maybe it would feel less like the earth turning.

Or middle tier goes up and the two others go down. Is this better ?

Did you read my answer to your previous post which was posted in the right section as opposed to your latest post, and which didn't mention that inexistent calculator that the TI-84 is (there is always something behind the "84" and it matters now that the CSE is out) ?

Yeah but Mimas is the most recently updated one.

Lol, see my edit ? It is because my post included your exact sentence before I checked and saw on ticalc that ASMDream was also the most recently updated one. Seems like there are updates without notifications here, while FloppusMaximus made a huge new post for his latest release on Mimas.