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.
Lionel Debroux wrote:
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.
Yes, but the MathPrint and Stats Wizards have been such a boon to my students that I've decided it's worth it.
FloppusMaximus wrote:
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.
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: res appRunning, (iy+APIFlag)
which would look like this (before squishing) as an Asm(-style program: Code: :AsmPrgm
:FDCB28A6C9
KermMartian wrote:
It's as simple as executing the command:
Code: res appRunning, (iy+APIFlag)
which would look like this (before squishing) as an Asm(-style program: Code: :AsmPrgm
:FDCB28A6C9
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: ld hl, Appname
ld de,progToEdit
ld bc,8
ldir
B_CALL ExecuteApp
Appname: db "APPNAMEHERE"
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).
KermMartian wrote:
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
Runer112 wrote:
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).
Wes wrote:
There was a time I knew my way around x86 asm pretty well, but I don't know the first thing about z80 asm.
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).
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum