If there was ever a group of people who could figure out this problem, it's you guys.

The Statistics book I teach with comes with a TI-83/84 APP that contains all the data sets that are in the textbook. So instead of having to manually enter the data into their calculators, students can just run the app and load the specified lists into memory. The app ran fine with the older OS's, but when we upgraded to 2.55MP, the app started having a strange issue: after exiting from the app, none of the Stats Wizards work. It's as if Stats Wizards had been turned off, but the MODE screen still shows it's on. Then if I run any other APP and exit, the problem is gone and all the Stats Wizards work again.

Any idea what's happening here? Sounds like the app is not exiting cleanly. Any way to fix this? Would a shell be able to trap the app's error?

The app in question can be found at http://media.pearsoncmg.com/aw/aw_triola_elemstats_10/cw/content/appb/tiapp.zip

Alternatively, I'm exploring other ways to easily move about 120 lists of data between archive and ram memory. I'm thinking of just putting them into GROUPS and using GroupTool (http://www.ticalc.org/archives/files/fileinfo/385/38560.html). Any other ideas?

Thanks,
-wes

OS 2.53MP and 2.55MP introduce a number of bugs and break backwards compatibility for a number of things. A number of users are therefore staying on 2.43.
Not that this solves your problem, but I'm not knowledgeable about programming TI-Z80 native code; others here are, as you know, and that's precisely why you posted here

Lionel's right, but in this case the problem is arguably a bug in the application. To be fair, though, the SDK documentation on this is not very clear, and in fact includes some rather questionable recommendations (all the stuff about monAbandon.)

Applications can install a so-called "putaway" routine, which the OS will call when the application exits. The OS also includes a default putaway routine that cleans up various flags. When you install a custom putaway routine, you're supposed to do whatever cleanup is necessary and then jump to the system's default putaway code (B_CALL ReloadAppEntryVecs / B_JUMP PutAway.)

The application you posted doesn't do that (it just does its own cleanup and then returns), with the effect that the appRunning flag is left set, which confuses the OS.

Yes, but the MathPrint and Stats Wizards have been such a boon to my students that I've decided it's worth it.


Could this appRunning flag be cleared with a small asm( program? Or would this have to be done from within an APP?

-wes

It's as simple as executing the command:
Code:
which would look like this (before squishing) as an Asm(-style program:
Code:

Well that was easy. Works like a charm. I'll put that on my Stats students' calculators first day back from spring break. Thanks.

Now I don't suppose there's any asm magic to call an APP from within a TI-BASIC program? If there were, then I could have a program call the APP immediately followed by the fix. That way, it would all be invisible to the students.

-wes

the un-assembled code to launch an application looks like this (someone who knows assembly better than I can turn it into the hexadecimal machine code representation by hand, or you can trying playing about with an assembler yourself):


Code:


Unfortunately, I'm pretty sure that will dump you back on the homescreen after it finishes (someone else will have to fill you in on the details and possible work-arounds) .

(see WikiTi for reference material)

As elfprince13 says, launching an App from an ASM program is easy. Getting control back after that App ends is extremely non-trivial. A better option would be probably figuring out how to patch the App to make it disable that flag itself while it was terminating (or better yet, make its putaway routine jump to the OS putaway routine instead of just ending).

I think doing such a patch is well beyond my reach. There was a time I knew my way around x86 asm pretty well, but I don't know the first thing about z80 asm.

For my purposes, I think I'll just use your AsmPrgm fix for the remaining few weeks of this school year. Next year I'll give the students the data lists in GROUPS and use GroupTool. I've been playing around with GroupTool the last few days and I think it will suit the need just fine.

Thanks,
-wes

I believe I fixed it: https://dl.dropbox.com/u/34812306/TriolaXe-fixed.8xk

Wow, I believe you have! On behalf of my students, and myself, thank you.

I'm curious how difficult the process was. I'm also curious if the textbook author or publisher would be interested in your patched version.

Once again, a huge thanks,
-wes

The issue was simply that the application never invoked B_CALL(_ReloadAppEntryVecs) in its exit procedure. I just found the exit procedure, cut out the jump back to the OS, and pasted in its place a jump to my own code, which I sneakily hid in the application header because the rest of the application page was full of code or data. My code just makes that call above before jumping back to the OS.

If you would like to contact the textbook author/publisher with the fixed version, feel free to do so. They could either just redistribute my patched version or reassemble the original with B_CALL(_ReloadAppEntryVecs) inserted right before the jump back to the OS, B_JUMP(_JForceCmdNoChar).

They're actually pretty similar. You can actually write programs which are source compatible between z80 and x86 if you're careful (both have a shared heritage through the 8080 - Intel dropped binary compatibility for the 8086, but maintained source compatibility).