[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: Sat, 22 Sep 2001 19:49:48 -0400 (EDT)
>
>
>I find this to be a fascinating idea! It would make it so you didn't have
>to have access to a dial-up Unix system (the closest one to me is long
>dist., and I could run my own, but I only have one phoneline, so I
>couldn't go online...). I wrote & submitted an article to ticalc about
>GNU/Linux for the TI-86, but didn't hear anything after that. I think you
>should make a Unix-like OS for the calc, 'cuz the TI-OS is math oriented,
>doesn't implement folders, etc. Maybe someone could semi-mass-produce a
>kit to upgrade the TI-86's ROM to either flash-ROM or a new ROM, with both
>the TI-OS and the CalcUnix on it (Dual boot, so you can still do math).
>
>Ryan M. McConahy
>
I've often longed for a different OS for the ti-86. I've never been able to
settle on exactly what features such an OS should have. I'm not sure that a
completely UNIX-like OS would be possible, but I do feel that many features
of a UNIX-like OS would be attainable in some form or another. Such an OS
would be much more condusive to such things as a TCP/IP stack or other
advanced/interesting software. I think the idea of having a C compiler on
the calc itself would be awsome. Instead of the interpreted TI-basic.
I looked for your article but couldn't find it. I'd be curious to see what
kinds of things you thought about in regaurd to an alternative OS for the
ti-86.
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.
(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.
(3) Overall System architecture - Also, should the OS be micro-kernel or
monolithic. Because of the limited space on the calc, probibly monolithic
is the way to go. But also the calc has some pretty raw I/O. I'm not sure
how this should be handled. Should a special abstraction layer be built to
allow for better I/O interfaces. If so should these be built directly into
the kernel, or in some other way. For example the video display is
completely graphical. A video controller layer could be built to allow for
different text modes and graphics modes with various layers of grey. There
are a lot of little descisions like this that I haven't found a way to
settle yet.
These are problems whose solutions i feel pretty good about.
(1) How to devy up the ti-86's memory - The calc has plenty of ram (128K
total). One 16K page is perminately located above 0xbfff. All 8 ram pages
can be placed between 0x4000-0x7fff and 0x8000-0xbfff. The lower 16K z80
memory segment has some TI rom stuck in it.(how rude). So the way I see it,
page 6 and 7 should be placed in the second and third 16k segments and the
upper 48kbytes should be used as "system ram". The kernel should be limited
to the upper 16Kbyte segment somewhere out of the video space's way. The
none kernel space would be used by the kernel for user-program virtual
memory pages. The other pages (1-5) should be abstracted away as a 80Kbyte
"ram disk". This ram disk could be used by the OS to swap user-program
pages to. Perhaps as a "sub partition". Exactly how the File system
abstractions should be layered, I'm not sure. Oh yeah and I think the page
size should be 64bytes (6 bits out of a 16 bit memory space. On pentiums
the page size is 4Kbytes or 12 bits out of a 32 bit memory space. 12/32 is
the same ratio as 6/16)
END.
Well those are some of the things I've thought about in terms of such a new
OS.
later,
David E. West
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Follow-Ups: