SD: Re: DHOS Calls update II

To: <shell-developers@lists.ticalc.org>
Subject: SD: Re: DHOS Calls update II
From: "Kaus" <kaus@cybrzn.com>
Date: Wed, 19 Aug 1998 23:29:38 -0500
Delivered-To: shell-developers-outgoing@towerguard.unix.edu.sollentuna.se
Reply-To: shell-developers@lists.ticalc.org

I have some comments, read throught the list.
-----Original Message-----
From: Matt Butch <mjb25@hotmail.com>
To: assembly-85@lists.ticalc.org <assembly-85@lists.ticalc.org>;
shell-developers@lists.ticalc.org <shell-developers@lists.ticalc.org>
Date: Wednesday, August 19, 1998 11:21 AM
Subject: SD: DHOS Calls update II


>
>Here are the list of ROM calls I suggest that DHOS supports:
>
>ZShell's
>Usgards


We wont use TI-OS vars except in emulation, and once a file is loaded, we
shouldnt need to find it, we should know wher it is.
>SRCH_RAM-search the 85's RAM for a var

We shouldnt need this, since the e2 should be able to do it for us, or if
not, then
our File I/O system driver can do it for us. The users should need to use
this if present.  (ther programmers that is)
>SRCH_EII-same as above but in EII


>DEL_VAR_EII-delete a var from EII


Are you talking a total Eii wipeout?  a complete Reset?  This would mean all
the OS stuff would be completly lost.  WE would have no way to get back into
the OS
>ERASE_EII-erase the EII


>SENDB_EII-send a byte to the EII
>SENDV_EII-send a var to the EII
>RECVB_EII-receive a byte from the EII
>RECVV_EII-receive a var from the EII


Why 6 bit?  are the other two bits on the Module port the GND/+5V?  I was
sondering wehre they would be..... :)  Where  did you learn this? Jsut schem
examination?
>EIIMPB_OUT-ouput a 6bit byte the the EII's module port(EMP)
>EIIMPB_IN-get a 6 bit byte from the EMP
>EIIMPx_HI-x is 1-6;Make EMP pin x high(a 1)
>EIIMPx_LO-" "    "     "        "       "  "  low (a 0)
>EIIMPx_IN-" "     ";get the logic level of pin x


Do we need to setup the module port before we use it?  or maybe we need to
map it to tell the OS wehre our extra linport/i2c networks, etc. are hooked
up on the module port pins.........:) good idea
>CONFIG_EIIMP-set up EMP


See the above comments about SRCH_EII and RAM
>SRCHR_LIB-search for a library in RAM
>SRCHE_LIB-     "       "  "     "      "   EII


>LD_LIB-copy a lib to the 85
>RMV_LIB-delete a lib from the RAM
>LD_PRGM-copy a program to RAM
>RMV_PRGM-delete a program from RAM, copy back if changed

>LCD_ON-self explanatory
>LCD_OFF-ditto
>CONTRAST_RD-get contrast value
>CONTRAST_WR-change contrast value
>INC_CON-increase the contrast by value in A
>DEC_CON-decrease the conrast by value in A
>SEND_I2CR-send a byte in I2C(on EMP) in raw format
>RECV_I2CR-receive a byte
>SEND_I2CM-send data or a var in MBUS format
>RECV_I2CM-receive "  "   "   "   "      "           "


Is this over the calc's linkport, or over the module port on the e2 extended
to emulate a link port, or both?
>SEND_TIP-send data or a var in TI-protocal format
>RECV_TIP-same as above but receive


>EXIT_TIOS-exit back to TI-OS


Alot of these will be easy, since they are all in ROM
>SQRT-square root
>FP_ADD-floating point add
>FP_AUB-floating point subtract
>FP_MUL-floating point multiply
>FP_DIV-floating point divide
>INT_MUL-integer multiply
>INT_DIV-integer divide



These are good ones!!!  Good idea!!!
>KEY_TO_NUMBER-get key and change to number(if possible), if not return
>              key
>KEY_TO_LETTERU-same as above but change to uppercase letter
>KEY_TO-LETTERL-ditto but lowercase


These conversion ones might not be used all the time, so maybe they would be
better in a lib?  or maybe we can find there equivalents in ROM...
>FP_TO_BIN-convert floating poing(FP) # to binary #
>FP_TO_BCD-same as above but to Binary Coded Decimal(BCD)
>INT_TO_FP-integer to FP
>BIN_TO_BCD-binary # to BCD(ie %10000011(130d) to 130h(%0001 0011 0000)
>BCD_TO_BIN-vice versa
>ASCII_TO_BIN-covert an ASCII # to binary(ie '02' to %00000010)
>BIN_TO_ASCII-vice cersa
>BCD_TO_ASCII-convert an ASCII # to BCD(ie 'F0' to %11110000($F0)
>ASCII_TO_BCD



Also, I was thinking about an idea for libs.  If we have a lib, it could go
in the OS's registry. Then, when a program needs a function, the OS, when
going through the program to relocate it, could see that it calls a lib
function, and automatically load the library into ram.  This would be the
'true' Dynamic Link Library Theory Applied.

That way, the programs dont have to worry about loading it themselves, or
updating the prog if the lib is updated.
--Jonathan Kaus
IRC: Jedsmeny
ICQ: 15873088
email: kaus@cybrzn.com




>
>any more?
>
>what do you think?
>
>Matt Butch
>mjb25@hotmail.com
>Member of the Doomsday Horizons Adminstrative Commitee(DHAC)
>
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com