Reading from archive isn't really that tricky, but it would certainly make the code a lot bigger and require new commands.  You can't just use a pointer; you have to switch pages, store data from that page to a register (temporary variable), switch pages back to the normal RAM, and then save the register into the RAM page at the desired location.  You have to do this for EACH byte or two byte combination you read which means its a lot slower than reading directly from ram.

I think it would really complicate things a lot and it would be about the same speed to unarchive it anyway as it would be to read all of the bytes from archive, although it would definitely be faster for individual bytes.  Putting the calculator in 15MHz mode during archive/unarchives is generally fast enough.  Reading a 6000 byte map by unarchiving would take less than a second to unarchive and especially for RPGs, a little loading bar once in a while isn't that big of a deal since it would never be in the middle of game play.  Just keep the data in ram until its no longer needed.

By the way, another trick I don't think many are aware of is that you can make the program archive ITSELF while its running so you effectively can use the entire free RAM if you need more.  Then unarchive it before you quit.

What the...

It probably won't last though.  I remember Pyoro was ranked #1 for a little bit too.

Exactly.  That's what I was thinking of.

But don't get too used to it, there will be much easier and faster ways to do grayscale in the future.

Trust me, its getting downloads.  This happened to a few of my other programs as well, so I'm not too surprised.  I don't think missing stats imply that it lacks downloads, I think its something else or a fluke in the system.  Every program gets downloads on the front page no matter how dull or boring it is.  And when it has animated screen shots, its likely to get many.  At a bare minimum, I did download it to double check the file after it got approved there.

Reminds me of when I was making Pyoro.  I fit the entire data structure for each fruit crammed into just 4 bytes, not a single bit was wasted.  Not only that, I actually reused different parts of the bytes to represent different types of data depending on the state of the object.

Question:
If you have fastCopy impemented, then why does CopyBuffer use GrBufCpy?

What is called "Fastcopy" in the routines is actually safe copy.  Copybuffer was what I used to use but I don't use it anymore.  I'm just keeping it there becasue in the future there will be more settings on how to optimize the code for efficiency on the size-speed spectrum.  Not all the routines in the list are actually used.

I think you're mistaken.  The 83+/84+ calculators all have 64KB of RAM.  In fact some of them even have extra ram pages that extend the ram up to 128KB.  By default, 64KB is available for reading and 32KB can be used for writing, but there are ways in assembly to extend read and write to the entire ram as well as most of the rom.

Edit: I think some people might consider the being able to read and write continuously to be what separates what is called "ram" and "rom" but I consider it ram since its partially accessible without needing to switch pages.