I've already mailed to Xavier Vassor about this and I'm now waiting for an answer: why aren't archived programs using highscores and archived libraries supported anymore? I didn't have any problems with my TI-89 (Hardware 1, AMS 1.05, DoorsOS Final Beta 2) when using this feature. Now I use AMS 2.03, first with Kernel 0.6, now with DoorsOS II and I miss this auto-unarchive feature.
Am I the only one who misses it? Why was it removed?

These features have been removed because in the old system, files were unarchived and so they couldn't be recovered by the archive recovery system of AMS 2.0x in the case the program crashes.

all you have to do is have a backup folder, say "zarchive" and put in a copy of all your games and libraries and archive them, and leave the rest in the main folder unarchived and if it crashes then you can copy your backups, which would be saved by the memory recovery system, back into the main folder. :)

Or how about rather than unarchiving it, just making a copy of it in ram somewhere, and then if the program ends correctly, unarchive the original version and then archive the "run" version.

Hrmm...think about that one. Games like SF2 would require about 120k or more free ram :P Hrmm...the game is 40k, the people are like 40k each uncompressed. That just might causes some problems :)

I agree!
And the memory recover doesn't work anyway, it never recovers ALL the archive, only random parts. (I have Hardware 1, but I have read about people with Hardware 2 complaining about the same thing.)
So we want the automatic unarchive again, maybe the Doors Team could release 2 versions of DoorsOS: one with the automatic unarchive and one without.

But if we have to keep them unarchived, the archive memory recovery won't recover them either.

I think this is a good thing :)

Before I would have a garbage collection every other time I played SMQ or SFT2. And then the calc would usually crash :( I am glad that Xavier took this out! If you want to keep your highscore (useless feature, IMO) just keep the game(s) unarchived!

My calc has never crashed during the garbage collection, even if it was performed by the TIOS function call from DoorsOS (after playing SMQ 10 times from archive).
And the highscores are not the most important thing for me, the archived libraries are.

Nevermind, sorry for the whole controverse, I will just keep my libraries unarchived and be quiet.

Good job, Xavier and Cédric et continuez comme ça! DoorsOS is and will remain the best kernel for the TI-89/92+ out there.

Hey, i downloaded the new doorsos and unzipped it, I could not find the included run() program is it supposed to be there. SOMEONE PLEASE RESPOND?

Its included in the one I downloaded.

I still have my 89 on hw1.00 and AMS 1.00, I think its easier that way.. it hasn't crashed in along time. I just got a 92+ for Christmas, and it has HW2 and AMS1.05 on it.. I haven't really done anything with it.. except put doorsos on it (the older version), and its running fine.. I'm kinda ansy to put AMS2.03 or the new doors version on it.. I just hope we can get back to a safe calculator environment instead of everything being so unstable.

Ya i finally found it. Do not put rom version 2.03 on HW2 because I'm pretty sure it won't work. I have 89 HW2 and Doors (yes the new version that is supposed to work on all rom versions) does not work at all. So i would not recommend you trying it on the 92, though it maaaaay just work.

I think DoorsOs rocks , but it didn't work on my TI 89.
Not this time... , I have HW1 , and AMS 2.03 . Maybe the libs.... I sent everything that came with
doorsos.zip , run() it's avaible . Anyway we're everyday near and near . To have a TI-89 it's like "to have a god in your hands" -besides the ti92plus
TI ROCKSSSSS!!!!!!!!!!!!!!!!
HP49G SUCKS SO MUCH ......

Yes, the TI 68k series do have quite a nice hardware. But does saying "HP sux" make it any better ? Did you even get to use a HP-49 ? Although the hardware hasn't evolved much since the good'ol 48G, I feel those software guys have done a very nice job indeed !

with this 8k thing being bypassed, you think TI is going to get paranoid that people WILL start "running applications from the RAM"? :P

I don't think that they really believed that nobody was gonna bypass that limit within the first few days. Nobody is that stupid.

For a Ti-89 HW 2 AMS 2.03
1) What do I need as a shell?
2) What Libraries does the shell need?

For a Ti-89 HW 2 AMS 2.03
1) What do I need as a shell?
2) What Libraries does the shell need?
3) What problems arise from having the shell
installed?
4) What games and programs will work for this shell?
5) What bugs are known and have been found?
6) What's the optimum configuration for my calculator, trade off between memory, functionality, and GAMES?
(Say a HW 2 AMS 1.05, AMS 1.00)

If you are interested in games, your best bet is to stick with OS 1.00. The shells for 1.05 and 2.xx are screwed up, as you can tell from reading all of the comments on this page. The best Shell I have found so far is Doors, because you can run programs directly from the home screen.

However, if you upgrade to version 2.03 from Ti's web site (www.ti.com/calc), you will temporarily lose the ability to run assembly programs, meaning, all good games for the time being. The shell, Doors, is currently running into a lot of problems, because it was just released on the 24th. On the brighter side, you will be able to download certain flash programs from TI's side including Cabri Geometry (which you should only get if you need it for school- it's not much fun to play around with unless you are REALLY bored).

Other than the ASM program problem, there really is no differnce between the ROM versions, other than the menus and file management being easier in the newer versions. Good luck.

Except one great thing (that should be implemented from the beginning), reset (2nd-Left-Right-On) does not erase archive memory. So, AMS 2.03 is ideal for on calc programming.

By the way, I am not fan of shells for TI89 and TI92+. Yes, they support libraries, but the most of libraries duplicate functions that already exist in ROM, programs use libraries non efficiently (only one or two functions), and instalation of programs is generally hard (install kernel, eventually erase installer, read from manual of program which libraries it require, download all libraries from Internet, transfer libraries to TI89, transfer the program).

The idea of shells was to avoid modification of program after releasing new version of TI OS. However, when new versions were released, we again had to recompile everything.

Shells are recidive from old FARGO days. ROM functions are more and more discovered, and I thing it is time to convert programs to standalone applications if possible.

When I see messages like this, I laugh:P People who write these things are like those silly traditionalists. They want to use the simpler ways when the newer ways are better.

Please, feel free to make Street Fighter 2 for me working with HW 2 in AMS v2.03 with grayscale no flicker without DoorsOS or some shell to help you get around the 8k limit. When you do... I'll be eating my hat:P

-Trailblazer

Breaking 8K limit is not issue of DoorsOS. I Broke 8K limit in Tezxas 2.0, using my own launcher. And Tezxas use more memory than any other TI89 program (except maybe Street Fighter), about 155K.

Additionally, if flickerless grayscale on AMS 2.03 HW 2 is impossible without DoorsOS, it is impossible with DoorsOS too. It is hardware problem, not software.

One great example happened after AMS 2.01 released. DoorsOS failed and failed almost all TI89 assembly programs. The only program that survived was CReversi, because it was standalone, less than 8K, application.

And DoorsOS II still rely on fixed handles for VAT tables and it will fail again after new Flash ROM update.

Have you ever heard about Microsoft Windows? Their constructors told: DLL-s are great, many applications will share it, less disc space etc. Result: even smallest application loads tons of complete DLLs and no Windows application takes less than 1 M of RAM. Look for example Notepad. Simple stupid editor on disc 45 K, which takes in ram about 1.5 M just because it uses some functions from several DLLs.

>And DoorsOS II still rely on fixed handles for VAT >tables and it will fail again after new Flash ROM >update.

It doesn't rely on fixed handles. It relies on a list of addresses for each ROM version. When a new AMS is released, DoorsOS will probably fail until I update this list of addresses, which may take 5 or maybe 10 minutes :)

You are very correct!! Phoenix is the best example with no dependent libraries or anything! Programs should not rely on shells. Libraries, much less shells complicate things to no end. I hope someone reads this and takes notice!

amicek

Heh, and when you archive things in var-link without a shell, do you like having to go back to the beginning of the list and scroll down again to get to the next item. Do you like having zip/unzip features in doorsos (I sure do, I saved about 20% space, enough to shove in 2 more chars for sf2) plus lots of other features

-Trailblazer

I don't mind spending a little time scrolling and the zipping program could come separately - don't get me wrong these guys are doing a great job, I just wish I were possible to simplify (yes I know it is fairly simple already)

amicek

While I loved ZIPlib (esp. for text files!), I just select (F4) all the variables I need to archive, unarchive, or delete, and then perform the function. :)

I'd install DoorsOS II for the Explorer, which I like a lot, but I use the List Editor a lot and won't lose it just for the Explorer (I think the list Editor should have been in there from the start!).

I agree libraries are a bad idea; just look at the 86. I don't need anything other than the program and the Asm( command to use assembly programs. It's much less troublesome. I also don't need some certain shell to run the programs on my 86, which is why I use it more for games than my 89

I also think libraries should be eliminated. It would make everything a lot simpler on the 89/92+ a lot easier. Half the games I put on my calc when I run them say wrong version of this library so I put the newest version I can find on then some other program won't run cause it'll say wrong version of that same library. I know that eliminating libraries would make games bigger but I only ever have about 200 k of working games because the libraries are always wrong.

Your darn right I'm upset. Bart Simpson
Hey watch your mouth, oh you did. Marge Simpson
Now I will return to my store where I dispense the insults rather than absorb them. Comic Book Guy

I AM WRITING IN CAPS TO ATTRACT THE ATTENTION OF ANYONE WHO IS SCROLLING ALONG THE COMMENTS! WE SHOULD START SOMETHING TO ELIMINATE LIBARIES FROM THE 89 AND 92+! - PERHAPS TICALC.ORG SHOULD REQUIRE ALL PROGRAMMERS TO INCLUDE THE CORRECT VERSIONS OF THEIR LIBRARIES IN THE RELEASES OF GAMES! LOOK TO PHOENIX AS A GREAT NO-LIBRARY EXAMPLE

amicek

I totally agree. The 89 has so much memory that using libraries to eliminate shared code is pointless. Staticly linking in code from libraries would make much more sense. It would eliminate all library version conflicts (which annoy me, and others, to no end), and make programs more robust because they wouldn't need a kernel mucking around with the os. It wouldn't take up that much more memory, but th 89 has ample memory anyway.

Possible objections:
Programs > 8k - If you're writing a program this big, you easily write your own loader. It can't be that hard.
Grayscale - The only possible advantage I can see for shared libs is that you can upgrade your grayscale lib when a new version comes out so all your grayscale games will work. But we've seen that a new version requires more than tweaks to a single lib. Besides, with static linking of publicly shared libs, all it would take is a recompile and update on ticalc to get it working. Not a big deal.
Easy file management - This can be written as a separate program. To the person who mentioned something about managing variables with the link menu before, please learn the difference between the kernel and the file manager, doorsos != doors explorer.
Compatability with other rom versions - We've seen that a new rom version requires more than just new libs. If people would just limit themselves to the calls that ti has given us and use static linking for the rest, programs could be recompiled for different rom versions easily, and without shells. Hell, someone could probably write a static lib that would detect rom and hw versions and adapt itself. That way, one binary could be used on all versions. All without shells.
Wasting memory - Come on, you've got so much of it... way more than all the other calcs. You can spare a little.

I love my ti-86 because shells are 100% interchangable; no program is shell dependant in any way, and all programs can be run with no shells at all. AFAIK, it is the only calc with this distinction. The only possible exception is the original AShell and programs that wanted to be written back by the shell. But that was years ago and no program works with AShell anymore. It actually breaks many of them. Also, 85 and 82 emulation require specific shells, but that's not really an exception.

I mention all this about my 86 because it's a good example of how the 89 world should look. All code statically linked, no version conflicts, no mess.

I don't mean to take away from the achievements of the doors team, creating a dynamic linking system on a calculator is quite an achievement. All I'm saying is that it's not necessary, and is probably a bad idea.

I agree that 89 programs should be shell-independant. The 86 is the easiest calc to use because I don't need a certain shell to play a certain game that I like (look at the 83 section...some games are only available for one calc while others are only available for others). Shells should only be used for letting you view your programs in an organized manner, and maybe add one special or two (like easy deletion, customizable folders, etc).

replace that "some games are only available for one calc..." to "some games are only available for one shell..." :P