Re: SD: Re: DHOS Calls update II
[Prev][Next][Index][Thread]
Re: SD: Re: DHOS Calls update II
comments to your comments.
(Note: I read this right after I sent Update IV!)
>From: "Kaus" <kaus@cybrzn.com>
>To: <shell-developers@lists.ticalc.org>
>Subject: SD: Re: DHOS Calls update II
>Date: Wed, 19 Aug 1998 23:29:38 -0500
>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
didn't think about this one
>
>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)
well, the program might want to see if a program exists. But I gues
this can be put into LD_PRGM and LD_LIB. But what if it just wants to
search, not load it.
>>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
I'm not quite sure what my reasoning was here.
>>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
>wondering wehre they would be..... :) Where did you learn this? juust
schem
>examination?
yeah, the other 2 pins are power and ground.
>>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
that's what I was thinking. The prgm tells the OS how to set up the
EMP, and when it outputs data it tell the os which port(ie I2C port 2,
ect)
>>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?
over the EMP
>>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
yeah I know
>>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...
alot of them are in the ROM, some have been found.
>>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.
this would slow the program down.
>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
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com