In Grammer, I use only one LCD updating routine and it does 2 level, 3 level, and 4 level grayscale because it is technically a 4-level gray routine, using different saturation levels of buffers. However, I think that if we use 3 level grayscale and monochrome as two options, then switching between them is as easy as turning the gray layer on or off and changing the frequency at which the LCD is updated. (Images look a lot better when going from 3 level to monochrome, in my opinion, as opposed to 4 level to monochrome.)

Again, from a graphics perspective, handling the menus might become a pain, but could be manageable. As well, twice the amount of drawing would have to be done, but that can probably be handled without too much of a slow down, even for 6MHz. My real concern is memory and how much of it will be needed. But all this can probably be figured out

That is one of the many things I used it for, actually. I also used it for a text compression routine, but it was very slow for strings thousands of characters long (I later made an assembly version that does a much better job).

This was one of the first assembly programs I ever made and it was inspired by the HextToBin command of Celtic 3. It basically converts a string of hex digits into the binary data (represented as tokens in BASIC). I realised it might be easier for some programmers to use a tiny program like this versus an app

Also, I needed to link to a download of this

I played Pokémon Gold and occasionally, the time actually went backwards. I found that if I corrupted the file a little (exiting in the middle of a save), the data would be fine, but there would be an option to reset the time (so I set it to 6:01 PM and that is how I figured out that time travels backwards). As well, opening certain menus or doing some other events appears to change the day. For example, opening the Pokégear and using left or right to go to the other options will move the day forward by 2 days (it is actually more like 9 days or more, but the net effect is two days and the week changes so you can do the lotto thing). It feels kind of like cheating to do this, but since there is no other way to actually change the time, it is needed for some parts of the game.

Wow, those are nice ideas!

but I'm stopped on a problem
The calc freezes when I modify a grayscale buffer in my options menu ... and i don't understand why...
I try to do otherwise.

Have you figured out why, yet, or is this still a problem?

Ah, that is true. I have been optimising for speed, so currently, all of the 'duplicated' graphics routines take 979 bytes. It is doubling the graphics speed while keeping it running smoothly, too.

The thing is that then, all Axe graphical commands will be unefficient with that method, and since Axe provides a fair lot of them ... You or anyone else (certainly not me, I can't do that) will have to rewrite from scratch all graphical routines the whole game would use to work with vertical buffers. I think that's an enormous time-eating task

I have line, circle, rectangle, pixel, sprite (clipped), tile, text, menu, LCD updating, grayscale, tilemap. Anything else?

EDIT: Also, the battle engine itself could use horizontal buffers, too, so that pure Axe could be used. I could also make a routine to convert a vertical buffer to a horizontal buffer or vice versa, and I could make an LCD update that works with both types of buffers.