Re: SD: Re: DHOS Calls update II


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

Re: SD: Re: DHOS Calls update II




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.

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

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

--Jonathan Kaus
IRC: Jedsmeny
ICQ: 15873088
email: kaus@cybrzn.com