Re: SD: Re: DHOS Calls update II
[Prev][Next][Index][Thread]
Re: SD: Re: DHOS Calls update II
and, of course, my comments to your comments to my comments to your
comments!! :)
>From: "Kaus" <kaus@cybrzn.com>
>To: <shell-developers@lists.ticalc.org>
>Subject: Re: SD: Re: DHOS Calls update II
>Date: Thu, 20 Aug 1998 10:51:12 -0500
>Reply-To: shell-developers@lists.ticalc.org
>
>
>And, my comments to your comments on my comments :)
>-----Original Message-----
>From: Matt Butch <mjb25@hotmail.com>
>To: shell-developers@lists.ticalc.org
<shell-developers@lists.ticalc.org>
>Date: Thursday, August 20, 1998 10:45 AM
>Subject: 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.
>
>Ok, i have read through some of the e2 driver code, and we will have
>complete control over every single byte. This is good, but that also
mean
>we will need to completely redevelop the e2's storeage system. I think
we
>willuse a FAT setup (quicker)
>With that, the SRCH for EII progs is a good one.
Well I just deleted that in Update V, but will put it back in VI
>>>>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.
>
>Good good good. I was wondering where the hell.... :)
>
>
>>>>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)
>Alright. The more i thought about the IO MApping, the better i like it
:)
I really like it too.
>
>>>>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
>
>OK. that is what i thought.
>
>>>>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!!!
It's always been so hard to do this, so I thought these would be great
>>>>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.
>>
>No, because it would be done when the program begins. Before the
program's
>execution even starts.
ok, I misread/understood what you wrote. This would be great. But
question. What if the program needs to load more than libs than the
available memory(doubt that it would happen, but we have to make sure we
cover all contingcies)??
I'm fixing up Update VI right now.
>--Jonathan Kaus
>IRC: Jedsmeny
>ICQ: 15873088
>email: kaus@cybrzn.com
>
>
>
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com