That would definitely be nice, but be prepared for a vastly different programming style. If you're still not discouraged enough, feel free to throw PMs filled with questions at me.

You could also try to set up an emulator first, HP isn't as aggressive as TI about those. Emu48 is the best one by far, and with Debug4x it could hardly be easier to get started. As I mentioned, it does not run ARM code, so some programs labelled as 49G+/50G-only will refuse to work, unfortunately including the OpenFire grayscale library. For those x49gp is a more suitable emulator, but it needs more processing power (two stacked processor emulators are a big CPU time sink), a Unix OS, for example Linux or OSX, and some experience with a Unix shell.

I have more good news: I decided to be that someone [TM] I mentioned a few posts earlier myself, which means my copy of x49gp now handles grayscale. 1-bit (i.e. the normal monochrome mode) and 4-bit (max depth) are tested, 2-bit should work as well. If I'm using this forum's attachment feature correctly, you should find two source code patches below, one fixing two compilation issues on at least my system and a minor error in flash.c I found a while ago, the other one implementing grayscale.
If anyone has problems using these, just ask, I'll see what I can do. x49gp is an old thing with not-too-good code based on an even older version of QEMU, so it would be pretty normal if something breaks. In fact, when I used x49gp the last time (on the Ubuntu version I replaced with Arch a year ago), one of the compilation fixes wasn't necessary yet.

The 4-bit I mentioned evaluates to 2^4=16 shades, black and white included. Most 50Gs have a pretty clear display, so the quality is rather good. Unfortunately there are not many programs / games using this quality, even 2-bit (i.e. 4 shades) is not as common as I'd like. The only 4-bit grayscale programs installed on my 50G are OpenFire's image viewer and my 3D renderer test.
I have a quaternion-based 3D wireframe renderer lying around, and as an HPGCC3 program it was easy to allow the full 4-bit grayscale. But I like to develop on the go, which means cross-compiling on a PC (like with HPGCC3) is not an option. Another obstacle was the lack of grayscale-capable debugging environments till today (now x49gp can do that, it wasn't as hard to implement as I feared). That's why it's only doing my simple test case, a spinning cube. With a polygon-filling routine and some information about the game (because I only know it as "a simplistic 3D game"), Wolfenstein 3D or something similar is definitely possible.

This is hardware grayscale too. Also, I took another look at the pictures on the page linked in the first post. They are photos of a real 49G+ (I think the 50G didn't exist back then), so they pretty much show the quality on the 50G.

Is the on-calc language available (I believe it's SysRPL, right?) viable for simple games or is it as slow as 68K BASIC?

Just adding my own experience in case anyone's curious. The built-in user-facing language is UserRPL, which I'd say is roughly on par with 68K BASIC speedwise, but often a lot faster, depending on what you're doing. SysRPL tends to work much more efficiently, especially for graphics. RPL in general tends to be “jerky”, though, because of the garbage collection method, which is a problem for games. Forcing a garbage collection each loop or few loops makes it smoother but a little slower.

As mentioned, RPL is a stack-based programming language, so the coding style takes a lot of getting used to (SysRPL, even more so), and especially debugging (though it includes an on-calc step debugger which is really helpful). Really long programs can be extremely hard to follow, but it's well suited for making lots of very small, manageable subprograms, which effectively form new “commands” in the language which you can then use to make higher-level subprograms, which can be used as commands, and so on, until you eventually create an entire large program or game out of them. (The HPs have nested directories, so having lots of separate subprograms isn't really a problem like on the TIs—and it's easy to organize custom commands/programs so they can be used in multiple projects, too.)

SysRPL is sort of a superset of UserRPL, has a number of more powerful commands, and allows you to bypass the error checking that usually happens in UserRPL. This can cause a dramatic speedup if you use it for loops that would call a lot of UserRPL words where you know that the argument types and such are correct and don't need to have every single operation recheck the arguments every time. Unlike UserRPL, though, you'll corrupt memory or crash the calculator if you mess up. It's quite easy to combine User and SysRPL code in the same project (they're both the same language internally); when I first started learning SysRPL, I just used it for the speed-critical parts and used the easier UserRPL for the rest.

There's also “HP Basic” which is UserRPL forced into a syntax of a more “normal” programming language. It's not that well documented, and I haven't messed with it much. It strikes me as being a bit of a kludge and lacking in places, and I hear it can be much slower than UserRPL.

The HP-BASIC/UserRPL compiler is of course built in as part of the OS, and there's a hidden SysRPL/ASM compiler and some hacking commands built-in, too, though you need to install a library to be able to use names for the internal commands (instead of hexadecimal addresses). A large amount of the ROM contains SysRPL code (with Saturn ASM for the low-level parts), and there are programs like Nosy that allow you to browse disassembled code right on the calc.

It can be a lot of fun for those who don't mind the “weird” programming language. The range of on-calc dev-supporting tools is just amazing.