Figured out the problem. It is a rare one as it only deals with multi page apps that gain control in ways other than the apps menu.

If you've ever looked at ram page $83, or the extra if you only have 1, you might have seen that it starts out with all the bytes numbered chronologically. At first glance, this seems stupid, but what it actually is, is the app base page table. Each byte corresponds to a flash page and the value of it is the base page of the app.

There's normally no problem because I believe Ti-OS fixes this when an app is run. But when it gets called in a strange way, i.e. hooks calling Catalog Help or a program returning to DCS7, it doesn't get fixed. So if the table is destroyed, any inter-app bcall is going to crash. Which only happen on the rare multi-page apps.

It's a very simple fix, just add bcall(_fillBasePageTable) whenever control returns from somewhere besides the app.

Fascinating, I had no idea. And is this bcall valid on all models, including the 83+BE? Since I've never personally seen this crash happen before, I guess I'll have to assume the only places I need it are the instant I regain control from an ASM program, or the instant I regain control from a BASIC program, in case it called ASM programs. Still awkward, though.

It is not a problem on the 83+ BE/SE because the table is not stored in extra ram.

I was having major problems when using catalog help because one of my apps killed this table every time I turned my calc on. My only option was to install my own help hook and then use a getCSC hook to regain control after it was done.

So, any new updates on this? Any progress or optimizations?

i hope there is

As do I. I also need to remember to test these games out on Doors CS when I'm working on development later, so I can try out thepenguin77's proposed fix and make sure it doesn't break anything else.

*bump* So of course I forgot until shmibs told me about Starfox and Bubble Breaker, well, breaking Doors CS. And _FillBasePageTable does the trick! Huzzah!