17 replies to this topic

[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 by jacquesg, Wed Nov 16, 2011 11:32 AM.

[Lee Stewart]

jacquesg, on Wed Nov 16, 2011 11:29 AM, said:

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 by RXB, Wed Nov 16, 2011 5:29 PM.

[Willsy]

Deleted garbage post.

[Willsy]

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.

[Vorticon]

Willsy, on Thu Nov 17, 2011 9:17 AM, said:

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 by sometimes99er, Thu Nov 17, 2011 2:10 PM.

[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 by RXB, Thu Nov 17, 2011 3:25 PM.

[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 by RXB, Thu Nov 17, 2011 3:33 PM.

[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]

OLD CS1, on Thu Nov 17, 2011 5:20 PM, said:

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 by RXB, Thu Nov 17, 2011 6:39 PM.

[OLD CS1]

A reasonable explanation, thank you.