Jump to content

Lee Stewart's Photo

Lee Stewart

Member Since 7 May 2011
OFFLINE Last Active Yesterday, 6:57 PM

#4259303 Satellite tracking program for TI-99/4A

Posted by Lee Stewart on Tue Apr 16, 2019 3:17 PM

I use John Walker’s (founder of AutoDesk, Inc. and coauthor of AutoCAD) Home Planet, available from his website, Fourmilab, based in Switzerland.  The Home Planet C source code (Visual C 7.0/Visual Studio .NET) is available on the site, as well.  It might offer some insight for an energetic programmer.

 

...lee




#4257803 CALL FILES/subprogram >16 code

Posted by Lee Stewart on Sun Apr 14, 2019 1:09 PM

Lee, I wrote some code for updating the file buffers at the top of the VDP RAM that I erroneously called PABs.  But now where are these "linked PABs" of BASIC that >833C should point to?  That address contains 0 after entering BASIC.  EDIT: Is the OPEN command in the DSR handling this?

 

I also had another look at the TIFC, and for that device at least >16 and FILES are identical in function.

 

Again, the DSR knows nothing about a linked PAB list.  The PAB that TIB or XB sets up for a given file has all the information the DSR needs for OPEN or any other file-dependent opcode.

 

When TIB or XB start up, there are no PABs, so >833C contains 0, signalling that such is the case.  This (0) is the same value as contained in the list-link-pointer address (first two bytes) of the last PAB in the chain, signalling the end of the chain.  The PAB chain starts after the space allotted to the Value Stack, whose base pointer is >8324 and top-of-stack pointer is >836E.  TIB and XB probably have a hard-coded start address for the start of the PAB list.  On page 302 of the E/A Manual, there is a suggestion that this address for TIB is >0FAB.  Based on the different sizes of the first two PABs, I would guess TIB and XB reserve space for a file’s data buffer immediately following its PAB.

 

...lee




#4257643 CALL FILES/subprogram >16 code

Posted by Lee Stewart on Sun Apr 14, 2019 7:21 AM

Thanks, but the second program won't do, because there is no DSR.  In fact, I'm trying to put together a DSR and CALL FILES should be part of it.  :)

 

I do not mean to strain at gnats here, but the DSR knows nothing about Basic.  Anything done to the PAB chain or pointers needed by Basic are handled by Basic’s CALL FILES() function, not the DSR.  CALL FILES() ultimately calls DSR subprogram >16, but it does other things that the DSR does not.  Perhaps the attached documents will help.  I think I retrieved them from WHTech’s site:

 

Attached File  TI99 TI Software Specs for Disk Peripheral.pdf   754KB   2 downloads Attached File  TI99 TI GPL Interface Specs for Disk Peripheral_+_Functional Specs.pdf   750.22KB   3 downloads

 

...lee




#4257593 CALL FILES/subprogram >16 code

Posted by Lee Stewart on Sun Apr 14, 2019 5:46 AM

Does anybody have an implementation for CALL FILES/subprogram >16?

 

From my understanding of BASIC, I assume that this routine decreases or increases >8370 (by >26x bytes?), updates the PAB links, and possibly sets some additional values.  I've looked at the TI Floppy Disk controller code for CALL FILES, but the code is really spread around and uses general purpose functions that obscure what really needs to be done.

 

Now before I embark on re-creating this on my own, are there already implementations for this?

 

I am not sure what exactly you are trying to do, but subprogram >16 for the TI disk controller (and all others that strictly adhere to its example) reserves >206 (51810) bytes in upper VRAM for space for each additional file you anticipate adding to the maximum number of files that can be open simultaneously.  The DSR (not Basic) updates >8370 as necessary.  This is a DSR function that works the same regardless of the programming language that calls it.  To my knowledge, TI Basic implementations do not do anything with PAB links until a file is actually opened.  Pointers affecting available memory in VRAM for Basic are surely updated, but I do not think additional space is reserved until files are actually opened.

 

...lee




#4255873 Suprisingly good projector for native TI composite

Posted by Lee Stewart on Thu Apr 11, 2019 7:37 AM

Here is the back of a PRJLE33 from Amazon:

 

Attached File  prjle33.gif   231.25KB   2 downloads

 

...lee




#4253759 Classic99 Updates

Posted by Lee Stewart on Mon Apr 8, 2019 6:09 AM

Thanks but I am in XB not Mini Memory.

 

You obviously did not read the referenced posts.  Unfortunately, the code is for TI Basic, so it will not work as written for XB.  However, with the right EQUates, it should work just fine for XB.  I am reasonably sure I did it for XB, too.  I will post the code if I find it.

 

And—Rich, considering that this CALL LINK() problem is not a Classic99 problem, we probably should create another topic to work on its solution to avoid further hijacking Tursi’s “Classic99 Updates”.

 

...lee




#4253620 Classic99 Updates

Posted by Lee Stewart on Sun Apr 7, 2019 7:47 PM

Right... but I don't see any emulation issues. I'm sure you're looking in the wrong place. In regular XB, you read your CALL LINK arguments using the list at >8300. I would expect that's the same in RXB. Have a look at the attached - it's a rough disassembly of the XB utilities. I know I've used STRREF for sure. ;)

 

I don't think I've ever tried to pull LINK arguments without the utilities.

 

attachicon.gifXBDUMP.TXT

 

I am pretty sure I have done it without the utilities.  If I find the thread, I will let you know.

 

...lee


  • RXB likes this


#4252857 Dragon's Lair is sold out!

Posted by Lee Stewart on Sat Apr 6, 2019 11:58 AM

Got mine today.  Woohoo!  :grin:

 

...lee




#4252353 Navarone cartridge expander

Posted by Lee Stewart on Fri Apr 5, 2019 3:22 PM

Thinking of getting a NOS Navarone expander from ebay.

Will it "play nice" with a finalgrom99?

Are any carts known to have issues when used with this device?

 

I do not know about the FG99, but I know that Tony’s XB 2.7 cartridge does not play nice with other cartridges on the expander.  I forgot the reason, but I am sure there are other cartridges, as well.

 

...lee




#4252185 Classic99 Updates

Posted by Lee Stewart on Fri Apr 5, 2019 11:29 AM

Source code of GPL and CALL INIT use this address >83A0 is the Default Data Stack, CALL LINK variables are pushed onto the stack.

What I am doing it trying to find out what is at this address to see what is pushed onto the stack and see why my RXB routine CALL LINK(address,variable) is crashing only if a variables exists?

CALL LINK(address) works exactly as it is supposed to work, but why it crashed with a single or more variables is the issue.
(You see the variables are handled in ASSEMBLY not GPL so I need to find out how....)

 

If I can not see what is going on there then it is virtually impossible to figure out why it fails.

 

As Tursi indicated, CALL LINK() uses the VDP Value Stack in VRAM for parameter passing.  The Value Stack Pointer is at >836E, which contains >0958 at XB startup (>06F8 for TIB).  The Value Stack is 8 bytes wide.

 

The TI Extended Basic Assembly Language Code Programmer’s Guide says this (among other things) about CALL LINK():

 

The arguments are passed to the ALC subprogram through the stack in VDP RAM and the identifier list in CPU RAM.  The identifier list consists of the following:
  1. >8300 – >830F  Argument identifiers (one byte each; maximum of 16).
  2. >8310          Old value stack pointer.
  3. >8312          Number of arguments.
  4. >8314          Temporary storage space for subroutine name.

 

...lee




#4251570 xdt99: New TI 99 cross-development tools available

Posted by Lee Stewart on Thu Apr 4, 2019 1:14 PM

I may need to finally bite the bullet and convert my 4-bank fbForth 2.0 code for assembly by xas99 instead of the asm994a I have been using.  I am pretty proud of the method I use to calculate target addresses for blocks of code that get moved, but I should not need to use it in xas99.  XORG should make it much easier to read and I do like your last enhancement with modifiers.  Of course, as has been said many times before, xas99 has the added benefit of current support.

 

...lee




#4246930 Received TI-99/4A weird thing on screen

Posted by Lee Stewart on Thu Mar 28, 2019 12:41 PM

traindriver69, if you do attempt to replace the relevant VRAM chip, be very careful not to compromise the integrity of those white vertical strips running across the top and bottom of those chips.  They each house one or more bus bars integral to the motherboard’s circuitry!

 

...lee




#4241872 Assembly: Problem calling GPLLNK without 32 KB memory expansion

Posted by Lee Stewart on Wed Mar 20, 2019 5:39 PM

Lee! This thread was all Greek to me.

I was able to translate your post into my-lingo...

 

. . .           

 

Well, then, I guess it was not as arcane as it appeared, initially!  :)

 

...lee




#4241669 Assembly: Problem calling GPLLNK without 32 KB memory expansion

Posted by Lee Stewart on Wed Mar 20, 2019 12:38 PM

Heh, I arrived almost at the same code, but what's the relation of XTABFE and GXMLAD?  AFAIK the original routine uses >200E and >176C, but both >1675 and >176C don't make any sense address-wise.

 

How are those values used?  I might want to move XTABFE somewhere else.

 

The following probably contains a lot of what you already know, but, hopefully, it answers your questions and may help the casual reader with other details:
 
XTABFE contains the address of the 15th vector (16 possible) in the 16th XML vector table (16 possible) referenced by the GPL code: “XML >FE”.  The two-byte, hex code for this is >0FFE.  The XML table:element refrence is >FE, with >Fx referencing the table starting at >8300 and >xE referencing element >1C—hence >831C as the value of XTABFE.
 
GXMLAD contains the address of the GPL XML instruction (>0FFE) we wish the GPL interpreter to execute, which is located at GROM0 address >1675.
 
Regarding the GROM0 addresses >1675 and >176C, GPL instructions are on byte boundaries, not word boundaries as with ALC.  The GPL XML instruction opcode (>0F) appears at both locations.  The XML table:vector byte that follows it in the first reference (>1675) is >FE, which is explained above.  In the Heiner Martin GROM0 dump, the byte following >0F at >176C is >27, which points to the 8th vector (>200E) in the 3rd XML vector table, starting at >2000 in low RAM.  Because the GPL interpreter is byte oriented, it does not matter that the GPL “instructions” at >1675 and >176C are data and never normally executed.  It is sufficient that they happen, fortuitously, to be the actual instructions we need to serve our ends.
 
...lee



#4241027 Camel99 Forth Information goes here

Posted by Lee Stewart on Tue Mar 19, 2019 10:56 AM

...

Camel Forth's DIGIT? (original comments by Dr. Brad Rodriguez)

: DIGIT?     ( char -- n -1)             \ if char is a valid digit
\            (      -- x  0 )            \ if char is not valid
              DUP 39 > 100 AND +         \ silly looking
              DUP 140 > 107 AND -
              [CHAR] 0 -                 \ but it works!
              DUP BASE @ U< ;       

 

Clever code, indeed—but it confused me at first because of a missing HEX ahead of the definition.  I especially like how the ASCII gap is handled.  It insures that any character in the gap is treated as a number higher than any likely radix (314 – 320), which should fail the comparison at the end of the definition.

 

[Edit:  I should add that the two AND operations will not work in TI Forth or fbForth because operations that yield TRUE or FALSE, unfortunately, render TRUE as 1 rather than -1 (FFFFh) as in the above case.]

 

...lee