Re: SD: RE: New operating system...

[Prev][Next][Index][Thread]

Re: SD: RE: New operating system...


What you are siply saying is to ignore the os that is there and rewrite
routines for everything that must be done.  Everything.  This gets very
tedious, let me assure you.

Additionally, let me also alert you to the fact that you are not the first
with this idea, and I bet even someone has done it before.  The thing that
makes it not-so-widespread is the fact that everytime you wanted to use the
real calculaotr functions of the thing, you would have to reset the entire
ram.  all of it would be gone.  Then, to get back to the new os state, you
would have to reload everything from a computer, even an eii wouldnt help
you here becasue you would need a driver to recieve everything

that means that you could play games 1st, 2nd, 3rd hour, but then during
math class, 4th hour, you swicth back to nomrla ti-os, and youd be stuck
like that until you got home, 5 hours later.

This is unacceptable to most ppl, usually high school students in our cass.

All curent shells are made specifiically to deal with this problem: make the
tios present and accessible,while allowing easy switching back to the asm
access shell.

I also beg to differ on your point about the current shells not allowing any
more of the TI-86 system resources than the ti-os does alone.  For instance,
only asm can do grayscale.  the current shells can do anything the
programmers put in them.  tO access more resources, the shell maker would
only need to put in routines to access them. It would not require you to
have an os that ignores the tios.

Just my $45.35 worth.

Jonathan Kaus

----- Original Message -----
From: David West <bdaddy_mit@hotmail.com>
To: <shell-developers@lists.ticalc.org>
Sent: Saturday, February 20, 1999 12:35 PM
Subject: Re: SD: RE: New operating system...


>
>>Well, that is kind of impossible, since the TIOS is stored on the ROM,
>>which means Read Only Memory. That's right. You can't wright to it. And
>>the 86 doesn't have a flash ROM, so it can't be erased and rewritten
>from
>>scratch.
>
>True but you could write a program(OS) so with it's own powerup and
>powerdown routines that would be TOTALLY independant of the TI-OS
>
>
>>Windowing APIs are available on other calcs (well, the 85 at least),
>and
>>if there was a demand for them, they could be ported to the 86 easily.
>
>True
>
>>The TIOS isn't hindering us in any way. It is still "quitting" and your
>>machine code is still taking complete control of the calculator. That
>is
>>why you can't break your assembly programs the way you can a BASIC
>>program.
>
>I beg to differ with you on this point.  It is true that your program
>has complete control.  But any program written for the calc, must take
>great care not to mess up the TI-OS.  The program must stay confined to
>certain area's of memory and it cannot use the ram in any way that will
>interfear with the TI-os, or else things well get messed up.  And there
>is a lot of "stuff" int he TI-OS that can be messed up.  Out of pages 0
>and 1 of the system ram, only 10K is alloted for program space???  This
>is rediculus.  Sure good programs can be made in 10K, but this is not
>using the resources to there full potential.  And sure you could
>probibly get more than 10K out of this ram, but you have to go pooking
>around to make sure youdo'nt mess up ti_system stuff to do it.  There
>has to be a better way.
>
>>Anyway, that is what ASE, Rascall, YAS, etc. are. New OS's for the
>>calculator. When they are running, the TIOS exists only in the ROM.
>
>Once again, I beg to differ....All these programs are, are "SHELL's"
>They must adhear to the TI-os like any other program.  They use the
>built in font, the built in memory access routines, and the built in so
>forth and so on.  All "on top of" the TI-OS.  These Shells cannot
>provide any more the TI86 system resources than the TI-OS already does.
>
>Here, this is a "raw" memory layout of the core OS that I am advocating,
>and working on designing.  Assign pages 1, 0 to be "program ram" and let
>them be loacted right beside each other in memory.  The top 6kbytes of
>ram would be left alone to provide double buffered 3-bit grayscale.  The
>next segment of ram going down the ram, would contain the OS-kernel.
>And as soon as the kernal is brought online, it automaticall boot-loads
>a "default" shell out of ram-disk(pages 2-7).  This default shell would
>be very minimal... analagous to a unix box, or dos shell.  Anyway, I'm
>thinking a good kernel can be made to fit ~6-8kbyes at the most.  And a
>default shell
>should be possible in about 2-3k at the most.  So 6kbytes for video,
>8kybtes for kernel, 3 kbytes for shell (and when a program is run, the
>shell will be replaced, so its size it not really relevent)  But that is
>at most only 14kbytes...  The rest of the 18Kbytes of program ram is
>left to the use of the programer.  Plus a full 96Kbytes of ram-disk
>space.  No shell provieds that kind of flexability.  Of course this
>would require an incompatible platform, but I'm not afraid of that.
>
>>Hope this cleared up some stuff.
>>
>>--James
>
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>
Follow-Ups: