"This is the mostly recently updated kernel available for the 68k calcs."

Mostly recently?

By the way, it should be time to change the name of asm\games\doorsos to asm\games\kernel , since there is no reason other than historical for this folder to have that name ...

See the update.

Grrr... :-(
I object. The folders for the other calculators aren't named "kernel" either. If you start renaming the "89/doorsos" folder to "89/kernel", then rename the "85/zshell" folder to "85/kernel" as well, and so on (for all other calculator models), and then look at the confusion it causes... The folder is called "doorsos" for a reason: DoorsOS was the first kernel to support that format. That's why the 85/zshell folder is called "zshell" as well. That does in no way mean DoorsOS is the "recommended" kernel for the TI-89/92+/V200; ZShell is not really the "recommended" shell for the TI-85 either, nearly any other shell can run ZShell programs as well as offering additional features. But the folder is still called ZShell, because that's the name of the format. The same goes for DoorsOS.

I've told you a hundred times that Mr. Common doesn't care about History when he comes to download something in the archives!
"-Hu, dooros folder? Let's download it huhuhu..."
And it is to late to save him from the DoorsOs syndrom :'(
And it is not wrong to call the format 'kernel' instead of 'doorsos'. That's what we use to do when we talk about it every day isn't it?
That's not confusion, that is just the logical way it should be.

TIGCC still calls it the "Doors" format in quite a few places. The header for programs based on DoorsOS or compatible kernels is called "doors.h".

I would hope that someone programming in TI-GCC would know enough to realize that DoorsOS isn't the best choice of kernel. The same can't be assumed for regular users.

#include kernel.h

We can't name our header that way because Patrick Pélissier is squatting that name for his unofficial and unapproved header. :p

That header does some very dirty hacks which are neither needed nor future-safe. For example, it toys around with the definition of _main for no reason whatsoever (and in fact, I think that hack is going to break as early as TIGCC 0.95 Beta 1). There is no need whatsoever for those hacks. It also defines/undefines TIGCCLIB #define options which it has no business to define or undefine. I do NOT recommend using that header. Use only tigcclib.h, with #define USE_KERNEL if you really want to write kernel-based programs (including doors.h directly is possible, but deprecated).

And Patrick Pélissier's kernel.h also declares a few RAM_CALLs which will work ONLY with PreOs, and might even crash other kernels such as TeOs. There is no check whatsoever to prevent such crashes. With the new kernel format revision, there will at least be a check in the stub to make sure the kernel is compatible.

>"-Hu, dooros folder? Let's download it huhuhu..."
>And it is to late to save him from the DoorsOs syndrom :'(

But is it really needed to rename those directories to do this? Moving DoorsOS to "TI-89 Assembly Shells (Out-of-date)" should be enough...

Seems like about 59207489 people don't agree with you, sorry :D

Moving DoorsOS to the out-of-date directory certainly couldn't hurt, but why stop there? Some users would pick up on that clue, but not all.

I still haven't stopped laughing about that quote... thanx Christophe. :-)

I could not disagree more.

On the TI-85, one of the assembly program directories is called 'zshell' and those programs *will work* under ZShell, even if you have the newest ROM version. So if a user downloads ZShell because the directory name is zshell, the program will end up working. So the suggestion implied by the directory name 'zshell' is a *good* one.

Now lets move on to the TI-89. Here the only subdirectory is 'doorsos' and those programs *will not work* under DoorsOS for many users, and will work poorly for others. So if a user downloads DoorsOS because the directoy name is doorsos, there is a high chance of failure. Thus the suggestion implied by the directory name 'doorsos' is a *bad* one.

I hope people can see that removing a bad suggestion is not at all analogous to removing a good one. Removing a bad one (by changing 'doorsos' to 'kernel') clearly decreases confusion, while removing a good one (by changing 'zshell' to 'kernel') could increase it, which is the opposite result!

Of course if no users ever take the directory name as a recommendation (or suggestion) then changing changing doorsos to kernel wouldn't help them, but then changing the others wouldn't confuse them either. However I don't think that is the case; like it or not people will think they can use DoorsOS to run 'doorsos' programs.

But calling everything "kernel" is not future-safe. PreOs is going to introduce a new revision to the "kernel format" which is going to use compressed relocation tables instead of the current format. Such programs will therefore work ONLY with PreOs.

Do you want to throw them all in one "kernel" pot, together with DoorsOS-compatible programs? I really don't think this is a good idea. It is as if you threw Usgard and ZShell programs all in one "kernel" (or "shell") folder. Possibly even together with Rigel programs, OS-85 programs etc. They are all "shell-based" programs after all.

Or do you want to create a "preos" folder for the new revision? Don't you think having separate "kernel" and "preos" folders will let people think "kernel" programs aren't going to run with PreOs? It won't be any better than having "doorsos" and "preos".

By the way, I think there should be separate folders for DoorsOS I (most of the time AMS 1 only programs) and DoorsOS II (AMS 2 compatible programs using the new RAM_CALLs introduced for AMS 2 compatibility), the same way there are separate folders for Fargo I and Fargo II. Call them "olddoorsos" and "doorsos", just like "oldfargo" and "fargo".

Using 'doorsos' as a directory name isn't even *present-safe*, because the programs there don't work on DoorsOS even now! The new format may or may not ever be used by a significant number of programs. There are already many programs, including highly popular ones like 'Super Mario Quest', that are not 'safe' in the sense you seem to use it now because their directory doesn't tell what kernel to use. Not only that, it specifically names the *wrong* one, which is even worse than what might happen with PreOS-only programs!

There are other ways to arrange things that you didn't mention. Since most users would be best advised to just get PreOS for everything, one directory called 'preos' for all wouldn't be too troublesome. To have more detail you could also name them /kernel, /kernel/old, and /kernel/preos-specific (or some variation for the last one). However, I think both of the methods you criticized are better than having 'doorsos' only now, or having 'doorsos' and 'preos' in the future, as neither of them gives has the *wrong* shell named.

'kernel': This would certainly be less trouble than on the TI-85. For the TI-85, all the new shells run the ZShell 4.0 format, but don't run those of the other new shells, so switching would be needed. A comparable problem doesn't occur on the TI-89 since PreOS would run all of them.

'kernel' and 'preos': Certainly better than 'doorsos' and 'preos'! People might think 'preos' is not included in 'kernel' but at least that still leaves Universal OS, which is better than DoorsOS! And since 'kernel' doesn't look like the name of a specific OS, people at least might realize it's a general term that could include PreOS. But it looks much more obvious that 'doorsos' does not include PreOS!

Ok, Patrick wins. And I agree with all the points he made. The mention of moving DoorsOS, the latest version, to the (OUT-OF-DATE) folder is not really what that folder is mant for. The OUT-OF-DATE folder is meant to keep a "history" of all the shells before the final version is complete. Thus if you have some programs that are made along the development for a specofic shell, the users can find the old version of that shell to run the program with. So, the latest version of any shell will always be in the /shells/ directory.

Thanks you Pat for explaining everything!! It is complicated, but I just say we blame it all on TI for making upgradeable roms, it's just their way of covering there own butt for when tey find errors in their calcs.

>The mention of moving DoorsOS, the latest version, to the (OUT-OF-DATE) folder is not really what that folder is mant for.

Hmmm... If so, then what is PlusShell 1.00 Alpha doing in that folder? It is the last released version. (And I am intentionally saying "last" and not "latest". I really don't expect there to be any updates. There have been none since 1998.)

It appears as though PlusShell 1.0 Alpha was actually replaced by PlusShell 1.0 Beta, which came out in June 2000. Thus, the alpha is indeed an old version.

This leaves me to wonder why I can't find 1.00 Beta anywhere in the archives, neither under 89 nor under 92plus. Not that it would really matter (PlusShell won't run on any current AMS version), but I am curious. :-)

If you mean this:
"psbrowser.zip 9K 00-06-27 PlusShell Browser v1.0 Beta"
it is just a port of the file browser which once came with PlusShell. The kernel itself is not part of that port.

Yep, that's the one!

It's too bad 2.0 was never fully finished up.

The multi-process feature was cool.

Multi-process feature? Something like the task switcher I wrote a few days ago? (Look at "Alpha/Beta Stuff" at my web page link.)

Well, the PreOs documentation explicitly says "This version of PreOS is compatible with DoorsOs, UniOs and TeOs."...

I think that, as the one who uploaded it here, you should also have put something to that extent into the file description though. :-)

I think you guys are looking more towards a solution without first looking at the problem. The problem is that there are mutiple kernel file formats and multiple kernel file format readers out there. I think the best solution (if not time consuming) would be to seperate the archives into folders such as Kernel2, Kernel3, and Kernel4 for the different kernel file format versions 2, 3, and 4 respectively (for example). Then also include a readme file in that directory that explains which kernel file formats can be read by which kernel file format readers. Then just include another directory, kernels, for all of the kernel file format readers.


(Unrelated) Kernels are TSRs or start up programs which allow external libraries to be used, so I think a new directory for browsers should be created, for browsers such as TiCTex and such.

That's a *really* good idea. We shall take it under consideration.

Good idea. But there are 5 formats of Kernel Programs, not 4.

Well, he listed 3 (2,3, and 4), but that's ok lol.

It may be cool to have folders according to the version of the kernel (They are many different version of the format of the kernel). Here is an extract from Preos doc:
The first kernel for Ti calcs was Zshell (See http://www.ticalc.org) for Ti-85 (I think. Fix me if I am wrong). The first kernel for 68k calc was Fargo for Ti-92 by David Ellsworth (Fargo I and Fargo II) - http://www.ticalc.org.
When the Ti-92+ arrived, Rusty Wagner created the first kernel for 92+ : PlusShell (version <0.9 - Kernel version 1). In fact, there wasn't any kernel program. The kernel core was inside the program itself :
if you have 10 programs, you'll have 10 kernel cores. And you can't update it. As a consequence, Rusty and Xavier (Vassor) decided a new format for Kernel programs with external Kernel core : PlusShell v1.0 alpha, DoorsOs v1.xx and LexOs (Kernel version 2).
They were designed specificely for AMS 1.01... When AMS 2.0x arrived, a new format was decided because the old format supports only AMS 1.01 : DoorsOs II, Universal Os and TeOs (Kernel version 3).
This format is quite good since it works fine today, but it has some gaps. To fix them, 2 new formats arrived : Preos (Kernel version 4) and Pack Archives (Kernel version 5).

Kernel version 6 is being under developpement. It will use compressed relocation table.


So it may be good to have such folders:
(Outdated) Kernel v1 (PlusShell < 0.9)
(Outdated) Kernel v2 (DoorsOs 1.0x / PlusShell 1.0x).
Kernel v3 (DoorsOs 2.0x / Universal Os / TeOS).
Kernel v4 (PreOS > v0.64).
Kernel v5 (PreOS > v0.66).

I think it is the best way, no ?

I forget this:
Preos can run Kernel v3 to 5 on all AMS.
Preos can run Kernel v2 on AMS 1.0x.

And you can convert Kernel v1 to Kernel v2 thanks to the tool provided in the zip.