I'm now looking at the project, and I have several optimization suggestions
* first and foremost: unless you experience issues with optimized compilation, which is very infrequent, you should compile with optimization (-Os compiler flag), which, besides speeding up the program, also saves a fantastic amount of space
* on top of that, the -fomit-frame-pointer -mregparm=5 compiler flags save some more space;
* you really should dynamically allocate 5 huge variables: external_level_buffer (jm_levels.c) and the four LCD_SIZE'd variables from jm_graphics.c. You can allocate a single block and play with pointer arithmetic a bit. Currently, they get stored in BSS, but BSS suck for both size and speed efficiency - both directly, because of inefficient instructions + relocation information, and indirectly, because they can prevent from making other optimizations. Getting rid of BSS for most programs I worked on, not just TICT programs, was a major win.
* for now, using compressed relocations and compressed references for BSS saves some more space. When the above variables are dynamically allocated, the BSS becomes small enough to merge with the main executable, and compressed BSS references are moot.
* you used the old, large version of IsVTI(); the newest version can be found inline in e.g. https://github.com/debrouxl/gcc4ti/blob/next/trunk/tigcc/archive/gray.s or in https://github.com/debrouxl/gcc4ti/blob/next/trunk/tigcc/archive/hw_version.s ;
* in GraySetScreenColor_R(): 1) move.l #0xffffffff,%d0 / %d5 would be much better as moveq #-1,%d0 / % d5, 2) the andi.l instructions would be smaller and faster as moveq to an additional register followed by and.l, 3) the cmpi.b instructions might be redundant because the andi.l (with a single-bit mask) already sets the CCR flags, 4) you should use explicit short branches;
* in GraySingleSprite8_COLOR_R(): 1) cmpi.w #0,%d4 is better written as tst.w %d4 (and you could even avoid the tst.w %d4 if you load d6 before loading d4), 2a) given that you're not using the upper part of d5, you should use moveq # instead of move #, 2b) in fact you could replace everything between __GraySingleSprite8_R__Test_WHITE and __GraySingleSprite8_R__Test_Finish by a single lsr.w #3,%d4 instruction (and thereby avoid using d5 at all), 3) you should use an explicit .l on the adda, 4) you should use explicit short branches.

This computer doesn't have GCC4TI binaries, I'll have to build them... or use the other computer's binaries.

On my side, the current build stats for jumpman are:
  Program Variable Size:                    45249 Bytes
  BSS Size:                                 47878 Bytes
  Absolute Relocs:                          712
  Natively Emitted Relocs:                  2
  Relocs Removed by Branch Optimization:    299
  Relocs Removed by Move Optimization:      211
  Relocs Removed by Test Optimization:      5
  Space Saved by Range-Cutting:             1110 Bytes

Great
TI-68k programs are scarce nowadays, so it could arguably be featured wherever you post it. The ticalc.org POTY time is nearing

That looks pretty smooth, good work

Fantastic job, congratulations
We knew since the beginning that it would be possible, but nobody was sufficiently interested in doing that work - until now.
Good thing to be posting on this board as well.

Mainlining the port is an absolute must for long-term maintenance, and for a 32-bit ARM9 platform, this does indeed require using DT: it already was a requirement when the Nspire Linux port was mainlined years ago, as Arnd Bergmann indicated when replying to https://lkml.org/lkml/2013/4/4/113. The tools associated to Nspire Linux may save you some time with that task: there's a DTB loader in there.
It's alright to make a bit more progress on a non-DT kernel for now, but you'll soon be spending time on code you'll have to redo for using DT, so you shouldn't wait much

You need to open the back of the calculator as if you wanted to, say, change the batteries, which requires moving a piece of plastic on the top (or bottom ?) side to unlock the back. You might then see one of the modules listed at e.g. http://www.datamath.org/Graphing/TI-92_Expansion.htm .

One of the software ways to check whether you have a Plus module should be the availability of "Archive" / "Unarchive" entries in Home -> 2nd -> Var-Link -> F1. If they're missing, then the calculator doesn't seem to provide user-accessible Flash memory.

There's been a bit of low-level Prime development lately
Namely:
* newcomer "gigi1237" and Jean-Baptiste Boric are working on a Prime emulator based on QEMU: https://github.com/Gigi1237/qemu (s3c2416 branch). It can largely run Rip'Em, though it can't run the standard Prime OS yet.
* Jean-Baptiste's internship (end of studies) is over, so he's got some more free time now, and the emulator is bound to ease the task of working on Rip'Em

Source: https://www.omnimaga.org/hp-prime/hp-prime-emulator/ (mostly dead board...)

Nope. All programs which use the same way to redefine interrupt handlers, e.g. for reading the keyboard, are affected.

Like many others, I hope CW stays

It had been a while since I read this topic. That's fantastic work, as usual

Glad to read, belatedly, that you've finished making all levels

Caution: as one of the forms of bundling and duplicating code, self-hosting external libs (the proper way, that is) requires staying on top of external updates, including security fixes, and is therefore a maintenance burden. Unless you give up on the updating part, but that's no good for users

Qt isn't perfect, but over time it's become the way to make cross-platform C/C++ GUI programs
It can be used for non-GUI programs as well, though in this case, special care needs to be taken not to over-use it.

I'm sure the MacOS X & Linux users would love a natively portable world editor, like Oiram's
But I do understand that it's more work in the short term if you're not familiar with Qt.

Using passwords or encryption to protect level contents would buy nothing but complexity, indeed.

That looks quite good, keep going