Boot tracking in XB

[+Vorticon]

Hi. How does one achieve boot tracking from within XB?

[sometimes99er]

Boot tracking ?

 

Power-up Program Execution - When TI Extended BASIC is first chosen, it searches for a program named LOAD on the diskette in disk drive 1. If that program exists, it is placed in memory and run.

[jacquesg]

* TRACK4S - SOURCE CODE FOR CHANGING

* DEVICE NAME IN AN XB PROGRAM

* FINDS DSK1 ANYWHERE IN XB PROGRAM

* AND CHANGES IT TO DSKX, WHERE X IS THE

* DRIVE FROM WHICH XB PROGRAM WAS LOADED

* OCCUPIES 162 BYTES OF MEMORY

* 26 FEB 1992

* HARRISON SOFTWARE (PUBLIC DOMAIN)

* CODE BY BRUCE HARRISON

*

DEF TRACK

TRACK

LWPI WS USE OUR WORKSPACE

MOV @>83D0,R12 GET THE CRU BASE IN R12

MOV @>83D2,R9 GET THE ROM ADDRESS FOR DEVICE

LDCR @ONES,0 ENABLE THE ROM

AI R9,4 ADDING FOUR PUTS US AT THE LENGTH BYTE

MOVB *R9+,R4 PLACE THAT IN R4 AND INCREMENT R9

SRL R4,8 RIGHT JUSTIFY LENGTH IN R4

LI R10,TEXT POINT TO TEXT BUFFER

MOVIT MOVB *R9+,*R10+ MOV ONE BYTE FROM ROM TO TEXT BUFFER

DEC R4 FINISHED?

JNE MOVIT NO, DO ANOTHER BYTE

LDCR R4,0 DISABLE THE ROM (R4 IS ZERO AT THIS POINT)

MOV @>8330,R13 PUT START OF LINE NUMBER TABLE IN R13

NEWLI INCT R13 POINT TO BYTE CONTAINING ADDRESS OF LINE

C R13,@>8332 ARE WE PAST END OF LINE NUMBER TABLE

JGT QUIT IF SO WE ARE FINISHED

MOVB *R13+,R4 GET HIGH ORDER BYTE OF LINE ADDRESS IN R4

SWPB R4 SWAP R4

MOVB *R13+,R4 GET LOW ORDER BYTE OF LINE ADDRESS

SWPB R4 SWAP SO R4 CONTAINS STARTING ADDRESS OF A LINE

*

* AT THIS STAGE R4 POINTS TO THE BEGINNING OF A LINE IN THE XB PROGRAM,

*

NEXT

MOV R4,R10 SET R10 EQUAL TO R4

CHECK

LI R9,DSK1 POINT AT TEXT 'DSK1'

LI R3,4 SET FOR 4 CHARACTER COMPARE

CMPB CB *R10,@ZERO IS THE BYTE WE'RE LOOKING AT A ZERO?

JEQ NEWLI IF SO, IT'S THE END OF A PROGRAM LINE

CB *R9+,*R10+ COMPARE BYTES AND INCREMENT

JNE NOCMP IF NOT EQUAL, GET OUT

DEC R3 ELSE DECREMENT COUNT

JNE CMPB IF NOT ZERO, REPEAT

LI R9,TEXT DSK1 WAS FOUND. POINT TO BOOT TRACKED DEVICE NAME

MOV R4,R10 R10 POINTS TO LOCATION WHERE "DSK1" WAS FOUND

*

* THE LOOP AT MOV2 OVERWRITES "DSK1" IN THE XB PROGRAM LINE

* WITH DEVICE NAME FOUND IN THE BOOT TRACK PROCESS

*

LI R5,4 FOUR BYTES TO MOVE

MOV2

MOVB *R9+,*R10+ MOVE ONE, INCREMENT POINTERS

DEC R5 DECREMENT COUNTER

JNE MOV2 IF NOT ZERO, REPEAT

MOV R10,R4 START OF NEXT GROUP OF BYTES

JMP CHECK JUMP BACK

NOCMP INC R4 GO START AT NEXT BYTE IN XB PGM LINE

JMP NEXT AT LABEL NEXT

QUIT

LWPI >83E0 LOAD GPL WORKSPACE

CLR @>837C CLEAR THE STATUS BYTE

B @>006A RETURN TO GPL INTERPRETER

TEXT BSS 6 BUFFER FOR DEVICE NAME

WS BSS 32 OUR OWN WORKSPACE

ONES DATA >0101 WORD TO TURN ON ROM IN CRU

ZERO DATA 0 ZERO BYTE FOR COMPARISON

DSK1 TEXT 'DSK1' COMPARISON TEXT

END

 

Bruce had a lot of other XB utilities on his two XBUTIL1.DSK and XBUTIL2.DSK files. I think that all of Bruce's programs are on the whterm site.

 

Jacques

 

Is there a way to have AA retain the original spacing in a source listing?

Edited November 16, 2011 by jacquesg

[+Lee Stewart]

Is there a way to have AA retain the original spacing in a source listing?

 

 

Just put code tags around it (click the "<>" button at the top of the "better" editor you get by clicking the "more reply options" button at the bottom of the initial editor you get when you start a reply. Here's your code between code tags---still not perfect, but perhaps a bit more readable:

* TRACK4S  - SOURCE CODE FOR CHANGING
* DEVICE NAME IN AN XB PROGRAM
* FINDS DSK1 ANYWHERE IN XB PROGRAM
* AND CHANGES IT TO DSKX, WHERE X IS THE
* DRIVE FROM WHICH XB PROGRAM WAS LOADED
* OCCUPIES 162 BYTES OF MEMORY
* 26 FEB 1992
* HARRISON SOFTWARE (PUBLIC DOMAIN)
* CODE BY BRUCE HARRISON
*
   DEF  TRACK
TRACK
   LWPI WS		   USE OUR WORKSPACE
   MOV  @>83D0,R12   GET THE CRU BASE IN R12
   MOV  @>83D2,R9	GET THE ROM ADDRESS FOR DEVICE
   LDCR @ONES,0	  ENABLE THE ROM
   AI   R9,4		 ADDING FOUR PUTS US AT THE LENGTH BYTE
   MOVB *R9+,R4	  PLACE THAT IN R4 AND INCREMENT R9
   SRL  R4,8		 RIGHT JUSTIFY LENGTH IN R4
   LI   R10,TEXT	 POINT TO TEXT BUFFER
MOVIT  MOVB *R9+,*R10+   MOV ONE BYTE FROM ROM TO TEXT BUFFER
   DEC  R4		   FINISHED?
   JNE  MOVIT		NO, DO ANOTHER BYTE
   LDCR R4,0		 DISABLE THE ROM (R4 IS ZERO AT THIS POINT)
   MOV  @>8330,R13   PUT START OF LINE NUMBER TABLE IN R13
NEWLI  INCT R13		  POINT TO BYTE CONTAINING ADDRESS OF LINE
   C	R13,@>8332   ARE WE PAST END OF LINE NUMBER TABLE
   JGT  QUIT		 IF SO WE ARE FINISHED
   MOVB *R13+,R4	 GET HIGH ORDER BYTE OF LINE ADDRESS IN R4
   SWPB R4		   SWAP R4
   MOVB *R13+,R4	 GET LOW ORDER BYTE OF LINE ADDRESS
   SWPB R4		   SWAP SO R4 CONTAINS STARTING ADDRESS OF A LINE
*
* AT THIS STAGE R4 POINTS TO THE BEGINNING OF A LINE IN THE XB PROGRAM,
*
NEXT
   MOV  R4,R10	   SET R10 EQUAL TO R4
CHECK
   LI   R9,DSK1	  POINT AT TEXT 'DSK1'
   LI   R3,4		 SET FOR 4 CHARACTER COMPARE
CMPB   CB   *R10,@ZERO   IS THE BYTE WE'RE LOOKING AT A ZERO?
   JEQ  NEWLI		IF SO, IT'S THE END OF A PROGRAM LINE
   CB   *R9+,*R10+   COMPARE BYTES AND INCREMENT
   JNE  NOCMP		IF NOT EQUAL, GET OUT
   DEC  R3		   ELSE DECREMENT COUNT
   JNE  CMPB		 IF NOT ZERO, REPEAT
   LI   R9,TEXT	  DSK1 WAS FOUND. POINT TO BOOT TRACKED DEVICE NAME
   MOV  R4,R10	   R10 POINTS TO LOCATION WHERE "DSK1" WAS FOUND
*
* THE LOOP AT MOV2 OVERWRITES "DSK1" IN THE XB PROGRAM LINE
* WITH DEVICE NAME FOUND IN THE BOOT TRACK PROCESS
*
   LI   R5,4		 FOUR BYTES TO MOVE
MOV2
   MOVB *R9+,*R10+   MOVE ONE, INCREMENT POINTERS
   DEC  R5		   DECREMENT COUNTER
   JNE  MOV2		 IF NOT ZERO, REPEAT
   MOV  R10,R4	   START OF NEXT GROUP OF BYTES
   JMP  CHECK		JUMP BACK
NOCMP  INC  R4		   GO START AT NEXT BYTE IN XB PGM LINE
   JMP  NEXT		 AT LABEL NEXT
QUIT
   LWPI >83E0		LOAD GPL WORKSPACE
   CLR  @>837C	   CLEAR THE STATUS BYTE
   B	@>006A	   RETURN TO GPL INTERPRETER
TEXT   BSS  6			BUFFER FOR DEVICE NAME
WS	 BSS  32		   OUR OWN WORKSPACE
ONES   DATA >0101		WORD TO TURN ON ROM IN CRU
ZERO   DATA 0			ZERO BYTE FOR COMPARISON
DSK1   TEXT 'DSK1'	   COMPARISON TEXT
   END

 

...lee

[+Vorticon]

Ah excellent! Thanks guys I am not familiar with the XB environment from an assembly standpoint, but I understand the gist of this routine. I will need to look up these addresses though.

[RXB]

Here is a RXB Boot tracking with no Assembly and it fetchs the DSR Device name from the ROM of the card.

11 ! BOOT TRACKING IN RXB   MERGE this program frist	so your program knows which drive it loaded from last.  *NOTE: NO ASSEMBLY USED!!
12 CALL PEEK(-31792,R,I,C,H)
:: CRU=128*R+I :: CPU=256*C+H+5
:: CALL IO(3,8,CRU,255)
:: CALL MOVES("R$",4,CPU,D$)
:: CALL IO(3,8,CRU,0)
13 CALL MOVES("V$",20,2086,E$)
:: PRINT "DEVICE:";D$:"PATH:";E$

 

I should explain I need a better access to the last PAB used by XB because if it does a Garbage collection it moves the data.

Edited November 16, 2011 by RXB

[Willsy]

Deleted garbage post.

[Willsy]

There is a map of how the VDP memory is used by the floppy controller here:

 

http://nouspikel.group.shef.ac.uk//ti99/vdpram.htm

 

There's no point using Classic99 to examine the VDP memory after a disk access, as it doesn't use a "TI" disk controller, and thus doesn't use VDP memory. I used TI994W and I saw some stuff in VDP memory but that also didn't make much sense. You'll probably have to use to a real TI to see whats in the VDP. VDP address >3EEB (number of drive last accessed) looks useful, and also >37DB (CRU base of the controller card). I'm assuming that AFTER a disk access, one could look at >37DB to get the CRU address of the card. You then map DSR at that CRU address in (you'll need a bit of assembly code for that) and from there you can walk the DSR header and extract the device name (DSK, RD, HDS etc). You can then combine the value at >3EEB to make a full device name, i.e DSK1 RD3 etc and append the filename that you want to access. So you end up accessing the file that you want to access, on the device that was last accessed.

 

More investigation will be required on real hardware though to ensure my theory is valid - and even if it is, looking at how the emulators use the VDP (which doesn't seem to adhere to the documented behaviour on Theirry's site) there is a good chance this technique won't work on emulators.

[+Vorticon]

There is a map of how the VDP memory is used by the floppy controller here:

 

http://nouspikel.gro...ti99/vdpram.htm

 

There's no point using Classic99 to examine the VDP memory after a disk access, as it doesn't use a "TI" disk controller, and thus doesn't use VDP memory. I used TI994W and I saw some stuff in VDP memory but that also didn't make much sense. You'll probably have to use to a real TI to see whats in the VDP. VDP address >3EEB (number of drive last accessed) looks useful, and also >37DB (CRU base of the controller card). I'm assuming that AFTER a disk access, one could look at >37DB to get the CRU address of the card. You then map DSR at that CRU address in (you'll need a bit of assembly code for that) and from there you can walk the DSR header and extract the device name (DSK, RD, HDS etc). You can then combine the value at >3EEB to make a full device name, i.e DSK1 RD3 etc and append the filename that you want to access. So you end up accessing the file that you want to access, on the device that was last accessed.

 

More investigation will be required on real hardware though to ensure my theory is valid - and even if it is, looking at how the emulators use the VDP (which doesn't seem to adhere to the documented behaviour on Theirry's site) there is a good chance this technique won't work on emulators.

 

I did not think about compatibility with emulators... In this day and age, one can no longer ignore this. Maybe I'll just ask the user to simply input their disk path at the start of the program. It's not seamless or elegant, but at least it will guarantee compatibility with anything outthere.

[Willsy]

What's the address of the scratch pad memory in cb speak ? Anyone know? Xb had this weird address scheme for CPU memory addresses; some addresses are negative (go figure)

[Willsy]

Sorry, that should be Xb not cb - bloody 'phone...

[sometimes99er]

E/A page 276

 

The address is a numerical expression or variable from -32768 through 32767. Addresses from 0 through 32767 represent >0000 through >7FFF. Addresses from -32768 through -1 represent >8000 through >FFFF expressed in two's-complement form. To access an address above 32767, subtract 65536 from it.

Edited November 17, 2011 by sometimes99er

[RXB]

The RXB Boot Tracking I posted does not use Assembly and is very compact and would fit on one line of XB. I use 3 lines in DEMO.

 

Also good point Willsy as to why my Boot Tracking in RXB does not fetch the last PAB used as Classic99 does not access the VDP the same way.

 

The 4 bytes I fetch are the 2 bytes for last CRU used also 2 bytes for VDP PAB last used at >0826.

 

Doing this from Assembly gets way more complicated as you have to use a CALL LINK and push stuff onto the VDP STACK

and if it changes VDP.

 

Thanks again Willsy I wondered why my RXB Boot tracking worked fine on a TI and not correctly in Classic99.

Edited November 17, 2011 by RXB

[+Lee Stewart]

If, by "scratch pad memory", you mean the CPU RAM PAD (8300h to 83FFh), that would be -32000 to -31745 (decimal), which I think is how XB needs it.

 

...lee

[RXB]

Yes, I use CALL HEX in RXB as it will only create string variable HEX >0000 to >FFFF into -32768 to 32767

 

RXB CALL HEX is not a full on HEX converter it is support for CALL LOAD, CALL PEEK, CALL LINK, CALL POKEV

CALL PEEKV, CALL POKEG, CALL PEEKG, CALL MOVES, CALL EXECUTE, and CALL IO.

 

Oh forgot CALL SECTOR, CALL ISRON, CALL ISROFF, and CALL POKER.

 

LOL just figured out you were discussing the same thing with Sometimes99er.

Edited November 17, 2011 by RXB

[+OLD CS1]

Rich,

 

A little off-topic, but is it much more difficult to create actual functions like HEX$() rather than sub-programs? I guess either way is just as convenient (CALL HEX(,) or A$=HEX$()) it just skewers my sensibilities to call a sub-program if a function would work just as well.

[RXB]

Rich,

 

A little off-topic, but is it much more difficult to create actual functions like HEX$() rather than sub-programs? I guess either way is just as convenient (CALL HEX(,) or A$=HEX$()) it just skewers my sensibilities to call a sub-program if a function would work just as well.

 

I used a CALL HEX as the A$=HEX$(number) requires the opposite A=DEC(string) but in CALL HEX I can do something requiring less memory.

CALL HEX(A,A$,B$,B,C,C$) to do this with HEX$(number) and DEC(string) would look like this:

A$=DEC(A) :: B=HEX$(B$) :: C$=DEC©

So put into MERGE format looks like this:

CALL HEX(A,A$,B$,B,C,C$)				 = >00649DC8034858B741B34124B342B342B343B34324B6
A$=DEC(A) :: B=HEX$(B$) :: C$=DEC(C$)  = >006E4124BE444543B741B68242BE48455824B74224B6824324BE444543B743B6

 

So I had two reasons for doing this. CALL HEX is faster and more compact (saves memory).

 

Well also any calculation inside a command is slower then doing that calculation outside the command as it spends so much time fetching values the less time fetching values is better but a little less convenient. So what you prefer would be more convenient but slower overall. I picked speed and saving space.

Edited November 18, 2011 by RXB

[+OLD CS1]

A reasonable explanation, thank you.