Re: A86: TI-86 VAT

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

Re: A86: TI-86 VAT

BIOSERRORS@aol.com wrote:

> I tried to log into the site 5 or 6 times without success.  Can someone please
> send me the .txt file?  (put it in .zip form please)  Thanks.

Here.

--
Bryan Rabeler <brabeler@ticalc.org>
   File Archives, HTML, and Support
   the ticalc.org project - http://www.ticalc.org/


TI-86 VAT Info... you've got questions, we've got hard
earned psuedo-answers.

Where is the VAT in an 86B?
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The VAT begins (at least in all the backups
we've seen) one word from the end of the
file. The last word is some form of CRC
or checksum and is not from the calculator
memory itself.

Where does the VAT begin on the TI-86?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The VAT begins at BFFF on RAM page 7. Take a look
at 86ports.txt for info on how to swap RAM page 7 into
one of the 16k blocks that the processor can access.
There is actually a ROM call that will do it for you
if you'd rather use TI's code. I believe the ROM was
written in z80 by hand so its probably safe to do so
(on the TI-92 -- whose ROM was written in C -- your own
routines will almost always be faster). Take a look at
ti86abs.inc.

What is the format of each VAT entry?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[name] size	flag	address: 24 bits	type
^	^	^	^			^-- Type of file
|	|	|	|-- 3 bytes of abs mem addr
|	|	|-- Usually 0, probably 1 if the file is "protected"
|	|-- Size of the name in bytes. *** See note
|-- Up to 8 bytes, in reverse: I.E. ooF

All of this is stored backwards... that is, the first entry's type
byte is at BFFF and then works backwards towards 0000 as the VAT
progresses. If it goes back to 0000, we're in trouble. :)

*** Note: This is the size in "human" numbers. I.E. sqrxz is 05,
not 04. Subtract one if you're going to use a loop to copy the
data into a buffer. Think of this number as the number of decreases
to make to put your pointer (most likely, hl) at the last letter of 
the VAT starting with it pointing at the name length. Thus you should
decrease the pointer to the VAT -- probably hl -- (unless you like evil
calculator crashes, DON'T use ldir or lddr, as they both either 
increment or decrement both hl and de), THEN do a ld a,(hl) / 
ld (de),a and THEN increase de. Got Milk?

How do I find the end of the VAT?!??
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Apparently 6C6C comes somewhere after the last letter of the last
entry. But there is a problem with checking for 6Cs to determine
when to stop our "dir" routine, or whatever:

Lets say there are two entries in the VAT:

Entry 1 with a name of hello and Entry 2 with a name of hell. Lets
assume that hello is a string and hell is a program. Well, when we
delete hello, VAT Entry 2 gets shifted to VAT Entry 1 since the
VAT must ALWAYS begin at BFFF. Thats all nice and fine... the type
byte gets changed from 0C (string) to 12 (program) and the memory
address is updated. As well, the name length byte changes from 5 to
4. HOWEVER THE ROM DOES NOT CLEAR THE TEXT MEMORY. In other words,
the five bytes before (or after, if you're thinking the "wrong" way)
are STILL hello. Your dir routine would only copy and print four
of these bytes, so thats not a problem. HOWEVER THE FIRST BYTE AFTER
THE LAST LETTER OF THE LAST ENTRY WILL BE A 'o' and not a $6C.

Thus, there has to be a way to detect the size of the VAT or where
it ends. This is a bad example because the calc seems to use at
least several VAT entries (xStat, yStat, fStat) on reset, along 
with two programs called # and ! and the Ans variable. In any case
we have not verified extensively that the VAT does NOT clear the o,
but in some cases it seems that it does not.

HOWEVER: there is another easy way to find the byte after the last
byte of the name of the last VAT entry. Got Milk?

>From $D297 to $D299 (static RAM - not paged RAM) is the address
to the end of the VAT. The abs addr for the end of the VAT is 
($D297) ($D299) ($D298) I.E. If D297-D299 are 0297BF then the 
VAT ends at 0x02BF97. In other words, its at ($D299)($D298) in 
ram page 5-7. It is unlikely that the VAT will ever overflow ram
page 7 so we will just as well not check for the case in which
it ends in another page. With each page being 16k and each VAT
entry being a max of 13 bytes you would need a huge number of
programs to overflow. If you want to be a purist you could use
a ROM call to flip to the RAM page that this address is on and
verify that its still 7 and if its not, reset the calculator or
something. But that would be wasting 4 bytes of memory and every
z80 programmer is obsessive about doing that... the TI-86 only
has 786,432 bits of memory, after all! :-)

Note: the last letter of the last VAT entry is at 
[($D299)($D298)]-1. You can load this into hl using ld hl,($D298)
The value is "reversed" in memory because of the way the z80
stores words. However it will be copied into hl correctly using
the line above. Boy, what is it with these backwards z80 people?

How do I check to see if my counter is there?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you're using hl to access the VAT area of RAM, you can load the
portion of memory above into de and compare it to hl with the
following code:

or a \ sbc hl,de \ jr z,x-equ-y

Or, the 86 Central site has a ROM call that will do this for you and
set the z flag based on the comparison. I don't know if a call is
smaller than an or and an sbc, but I'll leave that to the 86
nuts on the A86 mailing list to decide. I'd probably chose the ROM
call just because I can be assured that any problems aren't with *ROM*
calls. :)

How do I get the size of a variable?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The size is stored inside the variable itself, as is the case in
most of the TI calcs (including, if I remember correctly, the TI-92).
As such you have to flip to the right ram page based on the 24 bit
address. There is a ROM call to do this. See _load_ram_ahl
in ti86abs.inc (on the TI website).

How do I create a VAT entry?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This will create a 500 byte program called hello:

ld hl,varname
rst 20h
ld hl,500

varname .db 12h,5,"hello"
;12h = type of program - not needed for create calls but never mind
;5 = length of name
call _CREATEPRGM ;or whatever it's called


The rst 20h call basically copies varname into OP1, which is what
the _CREATEPRGM routine uses to read its info.

---
Thats all for now. Hope its been informative.

Bryan Rittmeyer
mailto:bryanr@flash.net
http://www.bridges.edu/horizon/eii/
_bryan_@EFNet

(with a lot of help from terry_P@EFNet)
Follow-Ups: References: