[A86] Re: TCP/IP stack

To: assembly-86@lists.ticalc.org
Subject: [A86] Re: TCP/IP stack
From: "David West" <bdaddy_mit@hotmail.com>
Date: Mon, 24 Sep 2001 20:08:48 +0000
Reply-To: assembly-86@lists.ticalc.org




>From: rabidcow@juno.com
>Reply-To: assembly-86@lists.ticalc.org
>To: assembly-86@lists.ticalc.org
>Subject: [A86] Re: TCP/IP stack
>Date: Mon, 24 Sep 2001 11:34:44 -0700
>
>
>If you use  a relocatable program format (either using only relative
>addresses, patching all absolute addresses, or having the program itself
>calculate them), you can execute programs of up to 16k directly in place
>by loading 2 consecutive ram pages to the two swappable banks.  This does
>make ROM calls a little tricky, since the call table can't be loaded at
>the same time:
>   ld hl,VariableName-1
>   rst 20h ; copy name to OP1
>   rst 10h ; get the abs addr
>   ld a,b
>   ex de,hl
>   call _load_ram_ahl
>   in a,(6)
>   out (5),a
>   ; **** You cannot make
>   ; ROM calls starting here
>   inc a
>   out (6),a
>   set 6,h ; switch hl from
>   res 7,h ; bank 2 to bank 1
>   ; execute program
>   ld a,$0d
>   out (5),a
>   ; **** ROM calls are safe
>
I get you now.  I remember this from a long time ago, but never thought 
about using it in conjunction with an alternative OS.  I think the inability 
to make ROM calls is alright.  If anything they might be called through a 
kernel mechanism.  The requirement that the code somehow be relocatable is 
worrysome, but not completely unreasonable.  Or course this mechanism 
doesn't provide any process protection when user programs don't relocate 
correctly, or just misbehave in general.  But the simplicity of this 
approach and the fact that it leverages the existing memory management of 
the calc is very intriguing and possibly makes up for the short commings.  
This is definately the strategy I'm going to use for my initial TCP/IP/PPP 
stack implimentation.

>If programs are interpreted/emulated then they're just like basic
>programs and there's no problem.

What do you mean by this last statement?  (Sorry for being slow, I'm from 
the south[USA])

>
>If you don't wipe out the VAT, you can use Kirk Meyer's memory recovery
>tool  (I can never remember the names of his stuff...), then start the
>new OS again.  Actually, as long as you keep the important stuff in the
>middle of ram, you can restart the new os even without that.

It sounds like your saying that it isn't much trouble to stay out of the 
TI-OS's way.  In the context of the memory management scheme you mentioned 
above, I totally agree with you.  In fact the memory management solution 
gives you the added binifit of being able write a new OS that coexists with 
the existing OS.  Another positive benifit of leveraging the existing memory 
management.

But the whole relocatable code issue is a thorn in the side for this scheme. 
  Does anyone have any comments about personal experience writing and using 
relocatable code for the TI-86 (debugging, code generation strategies, or 
other issues).  I don't have any practical experience with it.  I've seen 
documentation that some C compilers will generate such code.

later,

David E. West

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp