[A86] Re: TCP/IP stack
[Prev][Next][Index][Thread]
[A86] Re: TCP/IP stack
>From: "Ryan M. McConahy" <jfanonymous@yahoo.com>
>Reply-To: assembly-86@lists.ticalc.org
>To: <assembly-86@lists.ticalc.org>
>Subject: [A86] Re: TCP/IP stack
>Date: Sun, 23 Sep 2001 09:15:40 -0400 (EDT)
>
>
>
>
>On Sun, 23 Sep 2001, David West wrote:
>
> > Following are the problems to which I've never been able to come up with
> > satisfactor answers too. As a result, I have yet to be able to obtain a
> > vision clear enough to be able to design/impliment such an alternative
>OS.
> >
> > (1) Process modularity - The new OS should support multi-processing.
>The
> > calc already has an on board 200hz timer for the time sharing, but the
>z80
> > does not directly support virtual memory. Without proper memory
>isolation,
> > multi-processing seems to me to be hardly worth trying for. I find
>myself
> > unmotivated to support an OS that doesn't support multi-processing.
>
> > The best solution I have come up with for this so far is to build a
> > small/light (and hopefully fast) byte-code interpreter to act as a
>virtual
> > CPU that would allow for virtual memory. The the new OS could be
>targeted
> > for this virtual CPU. (www.cybiko.com has supposedy done this for their
> > portable wireless computer. See their development section and read
>about
> > the OS specs and software specs.) The only problem with this is, what
>if
> > you build it and find out it is unacceptly slow. That would be a
>bummer.
>
>So the Z80 would be emulating a CPU that would be running our programs?
>Not the Z80? Wouldn't that be painfully slow? What if all programs had
>relative addressing?
>
That is a completely viable solution. What about process protection though?
With this sort of scheme any process has the ability to crash the entire
system. And if the system crashes, the old TI-OS comes back and they you
have to go to a PC to get the whole system back on the calc. I think
robustness will be inportant because as soon as the OS crashes your stuck
with the old OS. What do you think?
Also the kernel would have to deal with memory fragmentation. Like in the
older MAC OSs when you load program A, B and C. And then close program B,
you have a hole in memory that is the size of program B. Then you get into
situations where you have lots of free ram but not enough in one space to
load another program. Unless you allow the kernel to rearange or (defrag)
the memory space dynamically. This could be made to work, but does feel
very eligant to me. Any thoughts? Is this a trade-off worth making?
> > (2) What relationship should the new OS have with the existing one -
> > Should this new OS totally take over the calc? Or should the OS be
>aware of
> > the existing built in OS and work around it. So that users don't have
>to
> > erase their entire calc to install the new OS. The problem with this is
> > that it severly limits the resources availible to such a new OS. What
>if I
> > have the new OS and want to graph an equation right fast? How do i
>"suspend
> > the existing OS" and then restart the old OS and then when i finish
>doing my
> > calculations go back to the new OS. There a lot of possible ways to
>deal
> > with this problem. The easiest I think is to just accept that usage of
>this
> > new OS will prohit the use of the existing OS. But this could
>potentially
> > limit the usefullness of the new OS. The existing OS has an advantage
> > because it has lots of stuff in ROM. It is doubtfull that a calculator
> > program with all the functionality of the ti-86 could be written for
>this
> > new OS because it would only have on the order of 112K of room to work
>in.
>
>The TI-OS is on a 256k ROM chip. What if you replaced that, and installed
>a new 512k chip with both the TI-OS and the new OS on it? Maybe it could
>be flash. What if you could add in a second RAM chip? Giv the current one
>to the TI-OS, and add a larger one for us? Or maybe you could make the
>flash chip a couple megs, and that could be part of our virtual harddisk
>in the new OS/TIGL86 (TI-GNU/Linux 86)?
>
The only concern I have about this sort of solution is that it would require
significant hardware upgrades. This would limit the number of people who
could make use of the system. Purhaps it would be done in such a way that
if the user had access to the hardware upgrade the new OS would take
advantage, but if they didn't they could still use the new OS, but only in
an exclusive mode. Another solution along the same lines would be to use an
external memory expander (through the serial port) to provide extra off calc
storage so that swapping between operating systems would be possible.
You illuded to one idea that I've thought about, but am unsure if it could
work or not. That is to some how run the calculator OS from the new OS by
making use of the the ROM. This would require extensive knowledge of how
code is laid out in the ROM. This woul dbe furthur complicated by differing
ROM versions. But i invision a "virtual calc" application that knows how to
run the code in the rom in such a way as to simulate the calculator with
limited resources. Maybe apps could be buillt for the new OS that know how
to use the various apps of the origonal OS. For example maybe there could
be a function graphing app that makes use of code in ROM to simply graph
functions. As I said before this would require very indepth knowledge of
the ROM code and would be complicated by differing ROM versions and the
level of modularity within the ROM code itself.
later,
David E. West
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Follow-Ups: