I have now created the Git repository for tiosmod, at http://github.com/debrouxl/tiosmod . But I haven't tested the shrinking of AMS 2.09 for 89 more thoroughly, and won't have time do so tonight.

[EDIT 20100916: I have now transferred the shrunk AMS 2.09 to my testing calculator, and certain operations in the Graph screen don't yield the appropriate result, or even corrupt memory and destabilize the calculator. Don't use the shrunk AMS 2.09 until it is fixed !]
Awww, sorry to hear it. Sad That's frustrating; do you have any leads as far as tracking down the problems?
Uploaded v0.2.3a, which mainly fixes the bug mentioned in the edit of the previous post. Upgrading is strongly advised Smile
Lionel Debroux wrote:
Uploaded v0.2.3a, which mainly fixes the bug mentioned in the edit of the previous post. Upgrading is strongly advised Smile
Congrats! I was happy to hear of your success on IRC this afternoon.
Uploaded v0.2.3b, which replaces one of AMS' traps (~software interrupts) by something useful, in order to fix a glaring bug in AMS: this trap is wired to a normal function, accessible through other means, which has a calling & returning convention for normal functions - but traps are no normal functions...

Even if the difference in calling convention can be overcome by writing the arguments to an exceedingly strange place (with the default value of the supervisor stack pointer, inside the display memory Very Happy), the difference in returning convention cannot be overcome by normal means (perhaps with the Tracing bit, but I'm not sure that this bit, which I've never used, survives the switch into supervisor mode performed by the trap), and the calculator will crash upon returning from the function... To sum up, the trap #3 in AMS is just plain unusable.

The replacement for TI's buggy trap #3 is the one that has been provided for many years by UniOS and PreOS: a HeapDeref (given a HANDLE, return the absolute address of the corresponding block of memory) with proper calling & returning convention.
Very impressive, Lionel, and also very nice of you to mirror the work of your z80 counterpart and fix TI's bugs for them when they've failed to do so. Sad
Well, our beloved manufacturer has abandoned us users and programmers, so we need to perform (we have the duty of performing, I'd say) the manufacturer's job now Smile

IMO, it would be great if we could, together, make the building blocks (tiosmod.c) generic enough to handle both TI-68k and TI-Z80 OS, and be able to build multiple patchsets on top of it (amspatch.c + other ones).
Or, at least, if making a single program is just too hard for some reason, two separate programs with similar APIs (e.g. reading and writing 8, 16, 32 and *8 bits and seeking should be similar in spirit) Smile
Handling the non-binary (Intel Hex format), paginated TI-Z80 OS is more work than handling the binary, flat TI-68k OS.

Currently, AFAICT, there are multiple independent computer-side patches that fix multiple bugs (e.g. the infamous instability of OS 2.53MP, "ERR: VARIABLE") or kill protections (e.g. PTT). Unifying these patches, to make it easier for users to use them, could be a worthwhile goal.
New version, http://tict.ticalc.org/beta/tiosmod-0.2.4.zip .
* fixed a very old bug, documented in http://www.technicalc.org/buglist/bugs.pdf , in contrast handling: destruction of the value contained in two processor registers, d3 et d4, which shouldn't be destroyed. This is unlikely to change anything for anybody, since the bug has been worked around in TIGCC, and therefore GCC4TI, for years.
* AMS 2.08 for 92+ and V200 are now supported, after testing.
Lionel Debroux wrote:
New version, http://tict.ticalc.org/beta/tiosmod-0.2.4.zip .
* fixed a very old bug, documented in http://www.technicalc.org/buglist/bugs.pdf , in contrast handling: destruction of the value contained in two processor registers, d3 et d4, which shouldn't be destroyed. This is unlikely to change anything for anybody, since the bug has been worked around in TIGCC, and therefore GCC4TI, for years.
* AMS 2.08 for 92+ and V200 are now supported, after testing.
Huzzah! Let me know if and when you want me to start looking at code and confer with BrandonW about what z80 patches would need in order to work with the same sort of system.
Quote:
Let me know if and when you want me to start looking at code and confer with BrandonW about what z80 patches would need in order to work with the same sort of system.

Well, people, especially if they're as knowledgeable about TI-Z80 calcs as e.g. Brandon and you are, are totally invited to look at the code and expand it, any time you want (besides your other activities) Wink
This is why I put it under the GPLv2, and posted it to Github.

For information, you don't necessarily have to re-develop an I/O code for the Intel Hex fomat, although you can obviously: for example, there's already a GPL'ed one in, between others, libtifiles (so it can just be copied & pasted & modified) Smile


BTW:
1) if for some reason, it doesn't make sense to make one single program of building blocks (tiosmod, I mean) for both calculator types (e.g. because there would be about zero common code, I don't know ?), then we can just, IMO, make two programs ("tiz80mod" and "ti68kmod", feel free to suggest better names) and patchsets (? and "amspatch") side by side Smile
2) I'm not demanding that all existing unofficial patches to the TI-Z80 OS (critor listed seven of them http://tibank.forumactif.com/programmation-f5/tiosmod-un-patcher-pour-os-de-ti-68k-pour-le-moment-t5872.htm ) be ported to a generic patcher - because, again, maybe doing so does not make sense (I think it makes sense for simple patchsets, but perhaps it's less obvious for the complex Chameleon patch) Smile
I can see that unlike the patches of the patchset of the TI-68k OS (which apply to nearly all versions supported by the patchset), most of the patches listed by critor are tied to one given TI-Z80 OS version.
Yeah, that's generally true, as the problems/bugs that are present generally apply only to one OS version, or else the part of the OS that is relevant to a problem tends to change significantly between OS versions. OK, I'll hopefully have some time in the not-too-distant future for this. Smile
New version, which hopefully disables the Flash memory execution protection on HW1 as well, and adds back OSVRegister/OSVFreeTimer + supporting code in the reset code and in the interrupt handler, i.e. the vectored timers removed by TI in AMS 2.04. These vectored timers were reimplemented independently of AMS by Zeljko Juric in the TIGCC (and therefore GCC4TI) library.

As usual, and though the OS is successfully running tests of the new functionality on one of my physical calculators, use the patcher+patchset or binary diffs at your own risk Smile
New version, http://tict.ticalc.org/beta/tiosmod-0.2.6.zip and, after the next update, on ticalc.org ( http://www.ticalc.org/archives/files/fileinfo/431/43198.html ) as well.
* fixes bugs in the patcher/patchset;
* adds Windows compatibility: the functions the patcher needs do exist in msvcrt, it's just that they have different names;
* adds the fix for another AMS bug, fixed by HW3Patch, namely the one that can occur when changing batteries.
Very nicely done, Lionel, keep up the good work! I wish I had the free time to help out with the z80 version now. :S
  
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
Page 2 of 2
» All times are UTC - 5 Hours
 
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

 

Advertisement