[A86] Re: TCP/IP stack

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

[A86] Re: TCP/IP stack




On Sun, 23 Sep 2001, David West wrote:

>
>
>
>
> >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?

Yes. I guess it would have advantages to run stuff on the virtual
processor. Maybe the kernel could be Z80, and all other programs would run
on the virtual processor. <shrug> I think it would be nice to have
anti-crash protection.

> 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?

I think you should let it defrag. Otherwise, you end up with a
Micro$oft-like product. Leave a WinDoze computer on for a week, and you'll
start to run out of resources. Not a good idea.

> > > (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.

That's a good idea.

>                      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.

Then you have to buy a $45 Expander II, or make one, and you have
something swinging off your calc. The calc wouldn't be as portable and
tough.

> 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
>
>
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
References: