Talk:83Plus:OS:TIOS Alternatives

Nostalgy

Well, I was on the team for that, and as far as I knew it died. I've not touched my parts of the code for about two years now. I'd be willing to take it back up if it's going to go anywhere, but... I just haven't touched it in so long I'd probably want to start over, especially since I've learned some things since I started working on it. Andy Janata 10:31, 27 March 2006 (PST)

Vera = exokernel?

In regards to Vera: this architecture is very similar to that of an exokernel operating system. Having briefly read up on Vera, it doesn't seem to me to be an exokernel. Even in its current form the operating system seems to do more than securely export hardware resources. However, I'm not intimately familiar with the project, so I'm leaving some time for someone to correct me before I change the text. --Dan Englender 12:25, 27 March 2006 (PST)

Vera seems to have died in her cradle... Anyway, the idea is to provide a filesystem (possibly integrated with memory management), a plugin system that would enable user code to extend the assembly interface, user program execution (naturally) and maybe a common link protocol and a customisable ISR at $0038. Everything above that, including the UI and maths capabilities is not an integral part of the system. CoBB 13:09, 27 March 2006 (PST)

Yeah, but providing a file system and memory management is beyond exokernel. Plus it doesn't seem to grant access to and revoke hardware resources. I would say it's more microkernelish than exokernelish, although probably provides more OS support than even a microkernel. --Dan Englender 13:29, 27 March 2006 (PST)

I based my text there on the comment left on the Vera wiki discussion page about their supposed "Core Design Principle". I'm not sure the traditional OS categories work very well for TI-83+ calculators in the first place. I have no particular attachment to that categorization, at any rate, so remove or alter it if you think it's inaccurate. --Premchai21 19:12, 27 March 2006 (PST)

An exokernel's job is to securely multiplex and control access to hardware resources. On a system with no memory protection, it is impossible to secure hardware resources while still allowing the user to run arbitrary code. I think discussing what type of kernel a calc OS uses is rather meaningless, because most of the distinction between kernels is the amount of code in userspace vs. kernel space, and on the calculator there is not any separation of memory spaces between user and kernel. Jib 02:08, 5 November 2006 (PST)

Thoughts on OS viability

Well, I've been thinking myself about creating an OS for the calc. I've been discussing it with friends who are more "in the know" than I as well. In this time, I have come to realize the limitations of the z80 processor. It is now my firm belief that replacing the TI-OS simply isn't viable or worth it.

The z80 processor does NOT have a protected mode. *ANY* piece of software running on it has direct control over the hardware. There is absolutely NO workaround for this. A malicious piece of software, or just a severely glitchy piece of software, could completely fubar the calc and there isn't a damn thing you can do about it. Toksyuryel 12:53, 10 July 2006 (PDT)

Actually, the worst-case scenario is you are left with a calculator with no OS on it, but the boot page will still always be there and you'll be able to load an OS back on it. It would be very hard to permanently damage the calculator from software (blue lines excluded); you can always pre-empt the installed OS with the boot code when you insert a battery while holding DEL. Andy Janata 14:45, 11 July 2006 (PDT)

Since someone told me this might be a bit too technical, I'll rephrase: You can _always_ put TI-OS back on a calculator, no matter what a previous OS or other piece of software may do to the calculator. There is only one real way to break the calculator from software, and that is to overpower the LCD. Andy Janata 20:09, 11 July 2006 (PDT)

Also, the z80 itself may not have protections, but the calculator's hardware implements a few. There are ROM read/write protections, and ROM and RAM execution protections. These can be used to your advantage when writing an OS. It's certainly true that you can crash the calculator from any program, but you could do that from early PCs too, and that didn't stop people from writing operating systems. As for "fubaring" the calculator, without too much trouble you could design an OS to be more secure than TIOS, and fubarity isn't particularly common in TIOS. Obviously designing an operating system which implements all modern systems concepts is out of the question, but there's no reason why you couldn't replace TI-OS with a very functional alternative operating system. --Dan Englender 20:13, 11 July 2006 (PDT)

The fact that there is no way to prevent a program from wiping the Flash is a serious problem, imho. It is no fun at all having to re-send the OS when something like that happens. And the blue lines thing? Totally unacceptable. Access to the hardware on such a level should be restricted and explicitly controlled. Unfortunately on the z80 this is not possible. These are the kinds of protections I look for when I consider an OS, but these things are not possible on the z80. I do understand that old PCs used to have the same problems, but we aren't living in those days anymore. It has been brought to my attention however that the m68k does have something of a protected mode, so I may get myself an 89/92 and fiddle with it. I am sorry that I cannot share your optimisim, but I strive for the highest quality and when such is physically impossible I look elsewhere. Toksyuryel 02:18, 13 July 2006 (PDT)

High-level language based OS

Neither the m68k nor the Z80 has any built-in ability to do memory protection or hardware access control. The only way to prevent the user from writing arbitrary data to the hardware is to prevent the user from running arbitrary code. One possible way this could work is to have the OS only programmable in high-level languages, a bit like what the TI-OS was like before it was hacked to run ASM.

Of course, if you actually implemented something like what I described, you would make it faster, smaller and more powerful than TI-BASIC. If the system had a sufficiently well-designed high-level language, you could do almost anything that ASM can do, but more easily and without the risks to the hardware.

An OS that runs entirely on a high-level language is harder to design, though, because you have to decide what functionality of the hardware will be exposed to the user in what way, so that the user is able to do as much useful stuff as possible without being able to screw up the system.

Jib 02:18, 5 November 2006 (PST)