Jump to content

Photo

Specialized file access from XB


79 replies to this topic

#26 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,279 posts

Posted Sat Oct 13, 2018 2:54 PM

Well after a couple of hours of hair pulling wondering why my test code was locking up the console, it turned out that DSRLNK is not supported by the XB environment! Please tell me that somebody here has written a homebrew DSRLNK routine because I have no clue how to go about doing this myself...

 

I never quite understood why TI excluded DSRLNK from the set of routines.  Maybe there wasn't enough space to include it in the cartridge? 

 

Below is one of the DSRLNK routines I have used with XB since '92 that may work for you.  It does not use the VDP "BLWP" utilities as it reads/writes directly to the video ports. It starts scanning at CRU 0x1100.  You will need to save and restore the VDP memory you use for PABs and buffers, unless you can target memory unused (or unavailable) to XB.  Some of the later fixes made during the Yahoo group days are missing from this implementation but for most cases, that isn't a problem if you follow each opcode's requirement for error testing.  (Edit:  I did not write this routine; I think it is nearly the same as the EA version, though I've never taken the time to compare the two)

 

Spoiler

Edited by InsaneMultitasker, Sat Oct 13, 2018 2:56 PM.

  • RXB likes this

#27 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,909 posts
  • Location:Denmark

Posted Sat Oct 13, 2018 3:12 PM

I never quite understood why TI excluded DSRLNK from the set of routines.  Maybe there wasn't enough space to include it in the cartridge? 

 

I never understood that either. Where is the routine that TI BASIC is using stored?



#28 HOME AUTOMATION OFFLINE  

HOME AUTOMATION

    Chopper Commander

  • 147 posts

Posted Sat Oct 13, 2018 4:09 PM

 

Or perhaps "a custom X-Y plotter table for the TI along with a controller which is driven by the TI."?  :)

Well... Who doesn't already have a custom X-Y plotter table for the TI along with a controller which is driven by the TI?


I'm guessing something more along the lines of:


TX1000;online...

matching;pattern descriptor table...
selecting;weapons mode...
targeting;carbon biounits...



#29 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,395 posts
  • Location:Eagan, MN, USA

Posted Sat Oct 13, 2018 5:08 PM

 

I never quite understood why TI excluded DSRLNK from the set of routines.  Maybe there wasn't enough space to include it in the cartridge? 

 

Below is one of the DSRLNK routines I have used with XB since '92 that may work for you.  It does not use the VDP "BLWP" utilities as it reads/writes directly to the video ports. It starts scanning at CRU 0x1100.  You will need to save and restore the VDP memory you use for PABs and buffers, unless you can target memory unused (or unavailable) to XB.  Some of the later fixes made during the Yahoo group days are missing from this implementation but for most cases, that isn't a problem if you follow each opcode's requirement for error testing.  (Edit:  I did not write this routine; I think it is nearly the same as the EA version, though I've never taken the time to compare the two)

 

Spoiler

 

 

Thanks! Can you give me pointers on how to actually use that routine by any chance? 



#30 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,395 posts
  • Location:Eagan, MN, USA

Posted Sat Oct 13, 2018 5:08 PM

Well... Who doesn't already have a custom X-Y plotter table for the TI along with a controller which is driven by the TI?


I'm guessing something more along the lines of:


TX1000;online...

matching;pattern descriptor table...
selecting;weapons mode...
targeting;carbon biounits...

 

That's next :)



#31 RXB OFFLINE  

RXB

    River Patroller

  • 3,370 posts
  • Location:Vancouver, Washington, USA

Posted Sat Oct 13, 2018 6:30 PM

 

Honestly Rich I think it's time for me to dump XB altogether and stick with RXB! This will simplify things tremendously.

Now here's a newbie question: how may bytes are in a sector using a standard TI controller?

 

Addendum: I just noted from the description of the SECTOR command that it corrupts the lower 8K of memory, so unfortunately I won't be able to use it since I need that area for my assembly routines... Bummer...

LOL well that is a issue.....

 

BUT

Just occurred to me what area of memory is open?

 

Using RXB you could copy that 256 area using CALL MOVES("RR",256,8192,-20480)

This would move 256 bytes from >2000 in lower 8K to >B000 in Upper 24K and which would preserve your program.

From this point you can use CALL SECTOR to move it to lower 8K as you have saved the memory that was there from previous line.

Now use CALL MOVES ("RR",256,8192,-20224) and save that sector to memory from Lower 8K >2000 to Upper 24K at >B100

Finally restore your copy of >2000 with CALL MOVES("RR",256,-20480,8192)

 

Unless you are using a interrupt at >2000 of memory everything should pan out fine, so guess you have a solution.


Edited by RXB, Sat Oct 13, 2018 6:52 PM.


#32 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,279 posts

Posted Sat Oct 13, 2018 8:43 PM

 

 

Thanks! Can you give me pointers on how to actually use that routine by any chance? 

Oh, sorry, the vector for the routine is 'hidden' near the top of the source, 5th line down.  No difference from the other DSRLNK call methods. :)

 

     BLWP @DSRLNK

     DATA 8    (or 10, if using a subprogram routine)



#33 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,395 posts
  • Location:Eagan, MN, USA

Posted Sat Oct 13, 2018 8:48 PM

Oh, sorry, the vector for the routine is 'hidden' near the top of the source, 5th line down.  No difference from the other DSRLNK call methods. :)

 

     BLWP @DSRLNK

     DATA 8    (or 10, if using a subprogram routine)

 

Ah yes I see it. I'll give it a try. Thanks again!



#34 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,395 posts
  • Location:Eagan, MN, USA

Posted Sun Oct 14, 2018 5:06 AM

LOL well that is a issue.....
 
BUT
Just occurred to me what area of memory is open?
 
Using RXB you could copy that 256 area using CALL MOVES("RR",256,8192,-20480)
This would move 256 bytes from >2000 in lower 8K to >B000 in Upper 24K and which would preserve your program.
From this point you can use CALL SECTOR to move it to lower 8K as you have saved the memory that was there from previous line.
Now use CALL MOVES ("RR",256,8192,-20224) and save that sector to memory from Lower 8K >2000 to Upper 24K at >B100
Finally restore your copy of >2000 with CALL MOVES("RR",256,-20480,8192)
 
Unless you are using a interrupt at >2000 of memory everything should pan out fine, so guess you have a solution.


So if I understand correctly SECTOR only needs 256 bytes at the top of the lower 8K. What about the XB program in high memory? You chose >B000, but I assume that's arbitrary. Is there a way to know where the XB program ends so we can pick a safe buffer location?

#35 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,395 posts
  • Location:Eagan, MN, USA

Posted Sun Oct 14, 2018 11:45 AM

Oh, sorry, the vector for the routine is 'hidden' near the top of the source, 5th line down.  No difference from the other DSRLNK call methods. :)

 

     BLWP @DSRLNK

     DATA 8    (or 10, if using a subprogram routine)

 

Update:

I'm afraid it's not working. I did reserve space for DREGS using BSS 32, and I get no errors or lock ups, but nothing gets loaded in the file buffer. The debugger in Classic99 shows no DSR activity on the image file either. Looking at the EA manual it looks like the PAB in the TI Basic environment needs 4 additional bytes at the beginning. Is this needed as well in XB?

 

Frankly, assembly disk file access from the XB environment is a total nightmare... There are solutions with RXB and TML, but not straightforward. I might forgo the XB environment altogether and just stick with pure assembly for this specific application...



#36 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,264 posts
  • Location:Lansing, NY, USA

Posted Sun Oct 14, 2018 3:48 PM

This is easy to do in XB. I am away until tomorrow night. I will post information for you then.

#37 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,395 posts
  • Location:Eagan, MN, USA

Posted Sun Oct 14, 2018 8:52 PM

This is easy to do in XB. I am away until tomorrow night. I will post information for you then.

 

You certainly got my attention here :) To date it has been anything but...



#38 RXB OFFLINE  

RXB

    River Patroller

  • 3,370 posts
  • Location:Vancouver, Washington, USA

Posted Mon Oct 15, 2018 10:02 AM

So if I understand correctly SECTOR only needs 256 bytes at the top of the lower 8K. What about the XB program in high memory? You chose >B000, but I assume that's arbitrary. Is there a way to know where the XB program ends so we can pick a safe buffer location?b

CALL MOVES can move it anywhere you want and yes >B000 and >B100 were just random location ins the example.

You could use CALL MOVES to put it in RAM or VDP or GRAM.

 

>A040 in Upper 24K is the last address available for XB (RXB) so unless you have a XB program that large a save place is >A040 to the top of your XB program.



#39 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,806 posts
  • Location:Silver Run, Maryland

Posted Mon Oct 15, 2018 11:35 AM

 

Update:

I'm afraid it's not working. I did reserve space for DREGS using BSS 32, and I get no errors or lock ups, but nothing gets loaded in the file buffer. The debugger in Classic99 shows no DSR activity on the image file either. Looking at the EA manual it looks like the PAB in the TI Basic environment needs 4 additional bytes at the beginning. Is this needed as well in XB?

 

Frankly, assembly disk file access from the XB environment is a total nightmare... There are solutions with RXB and TML, but not straightforward. I might forgo the XB environment altogether and just stick with pure assembly for this specific application...

 

The extra bytes for TIB PABs are the linked-list way TIB tracks PAB usage.  I would imagine XB does the same.  However, these have nothing at all to do with what your own DSRLNK in an ALC routine would need.  You definitely need VRAM for your PAB (2 bytes) and sector buffer (256 bytes), which are required by the disk DSR.  You can, obviously, copy any of this to RAM that will survive restoration of the XB environment.  I would save any VRAM (PAB and sector buffer) and PAD RAM (>834A – >8357) you and the DSR use and restore it before returning to XB.

 

Edit:  It is probably best to not have any files open in XB when you call your ALC routine.

 

...lee



#40 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,395 posts
  • Location:Eagan, MN, USA

Posted Mon Oct 15, 2018 1:24 PM

 

The extra bytes for TIB PABs are the linked-list way TIB tracks PAB usage.  I would imagine XB does the same.  However, these have nothing at all to do with what your own DSRLNK in an ALC routine would need.  You definitely need VRAM for your PAB (2 bytes) and sector buffer (256 bytes), which are required by the disk DSR.  You can, obviously, copy any of this to RAM that will survive restoration of the XB environment.  I would save any VRAM (PAB and sector buffer) and PAD RAM (>834A – >8357) you and the DSR use and restore it before returning to XB.

 

Edit:  It is probably best to not have any files open in XB when you call your ALC routine.

 

...lee

 

So you are saying that when I return to XB the PAB area and disk buffer in VDP get overwritten? That would certainly explain why I'm not seeing any data in the disk buffer after I return to XB, but still Classic99 should have been able to pick up the DSR activity on the image file, which it does not... At this point I'm not even sure the DSRLNK routine supplied by Tim is even working.



#41 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,806 posts
  • Location:Silver Run, Maryland

Posted Mon Oct 15, 2018 5:44 PM

 

So you are saying that when I return to XB the PAB area and disk buffer in VDP get overwritten? That would certainly explain why I'm not seeing any data in the disk buffer after I return to XB, but still Classic99 should have been able to pick up the DSR activity on the image file, which it does not... At this point I'm not even sure the DSRLNK routine supplied by Tim is even working.

 

They are not necessarily overwritten.  Unless you know otherwise, it is safest to save/restore them.

 

...lee



#42 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,806 posts
  • Location:Silver Run, Maryland

Posted Mon Oct 15, 2018 6:21 PM

Walid...

 

My comments have been assuming you are trying to use level 2, subprogram >14 (Access Direct Input File).  Perhaps that is not the case.  How are you trying to read the file?

 

...lee



#43 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,395 posts
  • Location:Eagan, MN, USA

Posted Mon Oct 15, 2018 8:31 PM

I'm using the routine Tim gave me a few posts back because the standard DSRLNK is not supported in the XB environment. I don't even know what level 2 is ...



#44 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,806 posts
  • Location:Silver Run, Maryland

Posted Mon Oct 15, 2018 9:12 PM

I'm using the routine Tim gave me a few posts back because the standard DSRLNK is not supported in the XB environment. I don't even know what level 2 is ...

 

Levels 1 and 2 are low-level disk and file routines such as Sector Read/Write and Format Disk and, after proper setup with different kinds of PABs and transfer blocks, are called with

BLWP DSRLNK
DATA 10

You are probably more familiar with level 3, the high-level file access routines with the PABs described in the E/A Manual—functions such as Open, Close, Read, Write, etc.—and called with

BLWP DSRLNK
DATA 8

...lee



#45 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,264 posts
  • Location:Lansing, NY, USA

Posted Mon Oct 15, 2018 9:28 PM

Here are two ways you can do this:

 

The first way is to use The Missing Link. You can read a _P file for a picture from a running XB program. When the picture is loaded you can read the character patterns similar to CALL CHARPAT by setting up a loop like this:

10 FOR COL=1 TO 233 STEP 8

20 FOR ROW=1 TO 185 STEP 8

30 CALL LINK("GETPAT",ROW,COL,A$) 

40 NEXT ROW

50 NEXT COL

A$ is a decimal string. If the 8x8 square at row,col is blank then A$="0,0,0,0,0,0,0,0".  If it is all filled in then A$="255,255,255,255,255,255,255,255". 

You can get the patterns for the entire screen this way and then process them as desired.

The slight pain in the butt is that you have to use high memory assembly code for this. Here's how:

Load up TML with RUN "DSK1.TML"  Then OLD DSK1.TMLEXTRAXB will load an XB program with some embedded code that includes GETPAT. Then add lines of XB code as desired, being careful not to overwrite line 3. You can add your own lines of assembly code as desired. Pages 26 to 28 of the TML manual describe how to do this.

 

Method 2 is to write your own custom assembly routines. The first thing you have to do is reserve string space for the >1800 byte buffer that will hold the bit mapped screen patterns., and you might as well reserve another >20 bytes for the PAB. The "Get String Space" routine is how this is done from XB. Below is a quick demo of this routine. The assembly code reserves >1800 bytes and fills it with >99 so you can use the Classic99 debugger to verify that it remains unmodified. After assembling this code, the XB program loads it, reserves the >1800 bytes and then inuts A$. You can find the beginning of the buffer and see how the strings are added to the VDP memory.

	DEF GETSTR
	
WKSP	BSS 32

GETSTR	LWPI WKSP
	LI R4,>1800	allocate >1800 bytes
	MOV R4,@>830C
*addresses >830C and >830D should contain the number of bytes to be allocated

	BLWP @>2018	XMLLNK
	DATA >0002	get string space
*now >831C points to the allocated string space
*and >831A points to the first free address in VDP RAM

	MOV @>831C,R0	first byte of allocated string space into R0
	LI R1,>9900
PRNT99	BLWP @>2020	VSBW
	INC R0
	DEC R4
	JNE PRNT99
*Now all >1800 bytes are set to >99, can use debugger to check this.

	LWPI >83E0	GPL workspace	
	B @>006A	back to XB

 
10 CALL INIT :: CALL LOAD("DSK1.GETSTRSP.OBJ")
20 CALL LINK("GETSTR")
30 INPUT A$
40 GOTO 30
 

Bear in mind that the reserved block of code is put wherever XB thinks is appropriate. You cannot force it to be where you want, and so there is no easy way to display the image on the screen. Your program knows where the buffer starts and so you can go through the patterns and process them as desired. Of course you need a DSR link to be able to do that. Here is one that works.


*******************************************************************************
*GPLLNK AND DSRLINK FROM THE SMART PROGRAMMER
********************************************************************************
 
GPLWS  EQU >83E0
GR4    EQU GPLWS+8
GR6    EQU GPLWS+12
LDGADD EQU >60
XTAB27 EQU >200E
GETSTK EQU >166C
 
GPLLNK DATA GLNKWS
       DATA GLINK1
 
RTNAD  DATA XMLRTN
GXMLAD DATA >176C
       DATA >50
 
GLNKWS EQU $->18
       BSS >08
 

GLINK1	MOV *R11,@GR4
       MOV *R14+,@GR6
       MOV @XTAB27,R12
       MOV R9,@XTAB27
       LWPI GPLWS
       BL *R4
       MOV @GXMLAD,@>8302(R4)
       INCT @>8373
       B @LDGADD
 
XMLRTN MOV @GETSTK,R4
       BL *R4
       LWPI GLNKWS
       MOV R12,@XTAB27

       RTWP
	
*DSRLNK
 
PUTSTK EQU >50
TYPE   EQU >836D
NAMLEN EQU >8356
VWA    EQU >8C02
VRD    EQU >8800
GR4LB  EQU >83E9
GSTAT  EQU >837C
 
DSRLNK DATA DSRWS,DLINK1
 
DSRWS  EQU $
DR3LB  EQU $+7
DLINK1 MOV R12,R12
       JNE DLINK3
       LWPI GPLWS
       MOV @PUTSTK,R4
       BL *R4
       LI R4,>11
       MOVB R4,@>402(R13)
       JMP DLINK2
       DATA 0
       DATA 0,0,0
DLINK2 MOVB @GR4LB,@>402(R13)
       MOV @GETSTK,R5
       MOVB *R13,@DSRAD1
       INCT @DSRADD
       BL *R5
       LWPI DSRWS
       LI R12,>2000
DLINK3 INC R14
       MOVB *R14+,@TYPE
       MOV @NAMLEN,R3
       AI R3,-8
 
       BLWP @GPLLNK
DSRADD BYTE >03
DSRAD1 BYTE >00

       MOVB @DR3LB,@VWA
       MOVB R3,@VWA
       SZCB R12,R15
       MOVB @VRD,R3
       SRL R3,5
       MOVB R3,*R13
       JNE SETEQ
       COC @GSTAT,R12
       JNE DSREND
SETEQ  SOCB R12,R15
DSREND RTWP

To read the _P file you need to set up a PAB in VDP ram like this

>0500,bufferaddress,>0000,>1800,>00 (offset byte),>0E (length byte),DSK1.PICTURE_P  (the buffer address is in >831C after calling get string space)

 

then set >8356  to point to name length (PAB+9) and

       BLWP @DSRLNK

       DATA 8
    
You can get the file name from XB with STRREF


#46 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,395 posts
  • Location:Eagan, MN, USA

Posted Tue Oct 16, 2018 5:09 AM

 

Levels 1 and 2 are low-level disk and file routines such as Sector Read/Write and Format Disk and, after proper setup with different kinds of PABs and transfer blocks, are called with

BLWP DSRLNK
DATA 10

You are probably more familiar with level 3, the high-level file access routines with the PABs described in the E/A Manual—functions such as Open, Close, Read, Write, etc.—and called with

BLWP DSRLNK
DATA 8

...lee

 

Yes indeed. I've never had a need to access disk files from assembly any other way than level 3... 



#47 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,395 posts
  • Location:Eagan, MN, USA

Posted Tue Oct 16, 2018 5:24 AM

 

Here are two ways you can do this:

 

The first way is to use The Missing Link. You can read a _P file for a picture from a running XB program. When the picture is loaded you can read the character patterns similar to CALL CHARPAT by setting up a loop like this:

10 FOR COL=1 TO 233 STEP 8

20 FOR ROW=1 TO 185 STEP 8

30 CALL LINK("GETPAT",ROW,COL,A$) 

40 NEXT ROW

50 NEXT COL

A$ is a decimal string. If the 8x8 square at row,col is blank then A$="0,0,0,0,0,0,0,0".  If it is all filled in then A$="255,255,255,255,255,255,255,255". 

You can get the patterns for the entire screen this way and then process them as desired.

The slight pain in the butt is that you have to use high memory assembly code for this. Here's how:

Load up TML with RUN "DSK1.TML"  Then OLD DSK1.TMLEXTRAXB will load an XB program with some embedded code that includes GETPAT. Then add lines of XB code as desired, being careful not to overwrite line 3. You can add your own lines of assembly code as desired. Pages 26 to 28 of the TML manual describe how to do this.

 

Method 2 is to write your own custom assembly routines. The first thing you have to do is reserve string space for the >1800 byte buffer that will hold the bit mapped screen patterns., and you might as well reserve another >20 bytes for the PAB. The "Get String Space" routine is how this is done from XB. Below is a quick demo of this routine. The assembly code reserves >1800 bytes and fills it with >99 so you can use the Classic99 debugger to verify that it remains unmodified. After assembling this code, the XB program loads it, reserves the >1800 bytes and then inuts A$. You can find the beginning of the buffer and see how the strings are added to the VDP memory.

	DEF GETSTR
	
WKSP	BSS 32

GETSTR	LWPI WKSP
	LI R4,>1800	allocate >1800 bytes
	MOV R4,@>830C
*addresses >830C and >830D should contain the number of bytes to be allocated

	BLWP @>2018	XMLLNK
	DATA >0002	get string space
*now >831C points to the allocated string space
*and >831A points to the first free address in VDP RAM

	MOV @>831C,R0	first byte of allocated string space into R0
	LI R1,>9900
PRNT99	BLWP @>2020	VSBW
	INC R0
	DEC R4
	JNE PRNT99
*Now all >1800 bytes are set to >99, can use debugger to check this.

	LWPI >83E0	GPL workspace	
	B @>006A	back to XB

 
10 CALL INIT :: CALL LOAD("DSK1.GETSTRSP.OBJ")
20 CALL LINK("GETSTR")
30 INPUT A$
40 GOTO 30
 

Bear in mind that the reserved block of code is put wherever XB thinks is appropriate. You cannot force it to be where you want, and so there is no easy way to display the image on the screen. Your program knows where the buffer starts and so you can go through the patterns and process them as desired. Of course you need a DSR link to be able to do that. Here is one that works.


*******************************************************************************
*GPLLNK AND DSRLINK FROM THE SMART PROGRAMMER
********************************************************************************
 
GPLWS  EQU >83E0
GR4    EQU GPLWS+8
GR6    EQU GPLWS+12
LDGADD EQU >60
XTAB27 EQU >200E
GETSTK EQU >166C
 
GPLLNK DATA GLNKWS
       DATA GLINK1
 
RTNAD  DATA XMLRTN
GXMLAD DATA >176C
       DATA >50
 
GLNKWS EQU $->18
       BSS >08
 

GLINK1	MOV *R11,@GR4
       MOV *R14+,@GR6
       MOV @XTAB27,R12
       MOV R9,@XTAB27
       LWPI GPLWS
       BL *R4
       MOV @GXMLAD,@>8302(R4)
       INCT @>8373
       B @LDGADD
 
XMLRTN MOV @GETSTK,R4
       BL *R4
       LWPI GLNKWS
       MOV R12,@XTAB27

       RTWP
	
*DSRLNK
 
PUTSTK EQU >50
TYPE   EQU >836D
NAMLEN EQU >8356
VWA    EQU >8C02
VRD    EQU >8800
GR4LB  EQU >83E9
GSTAT  EQU >837C
 
DSRLNK DATA DSRWS,DLINK1
 
DSRWS  EQU $
DR3LB  EQU $+7
DLINK1 MOV R12,R12
       JNE DLINK3
       LWPI GPLWS
       MOV @PUTSTK,R4
       BL *R4
       LI R4,>11
       MOVB R4,@>402(R13)
       JMP DLINK2
       DATA 0
       DATA 0,0,0
DLINK2 MOVB @GR4LB,@>402(R13)
       MOV @GETSTK,R5
       MOVB *R13,@DSRAD1
       INCT @DSRADD
       BL *R5
       LWPI DSRWS
       LI R12,>2000
DLINK3 INC R14
       MOVB *R14+,@TYPE
       MOV @NAMLEN,R3
       AI R3,-8
 
       BLWP @GPLLNK
DSRADD BYTE >03
DSRAD1 BYTE >00

       MOVB @DR3LB,@VWA
       MOVB R3,@VWA
       SZCB R12,R15
       MOVB @VRD,R3
       SRL R3,5
       MOVB R3,*R13
       JNE SETEQ
       COC @GSTAT,R12
       JNE DSREND
SETEQ  SOCB R12,R15
DSREND RTWP

To read the _P file you need to set up a PAB in VDP ram like this

>0500,bufferaddress,>0000,>1800,>00 (offset byte),>0E (length byte),DSK1.PICTURE_P  (the buffer address is in >831C after calling get string space)

 

then set >8356  to point to name length (PAB+9) and

       BLWP @DSRLNK

       DATA 8
    
You can get the file name from XB with STRREF

 

 

Thank you! I'm not quite clear as to how the DSRLNK routine works, but it's not really important that I do at this stage as long as it works. I get everything else and indeed it sounds pretty straightforward.

I'll post an update later today.



#48 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,264 posts
  • Location:Lansing, NY, USA

Posted Tue Oct 16, 2018 5:31 AM

 

Thank you! I'm not quite clear as to how the DSRLNK routine works, but it's not really important that I do at this stage as long as it works. 

I have no idea how that works. It's in the EA manual. Although I've never had occasion to use it, it seems like a good fit for what you want to do. 

(Edit) I didn't read carefully enough. I thought you meant XMLLNK  and the Get String Space routine. My comments refer to that.

I've used the DSRLNK many times and it works fine.


Edited by senior_falcon, Tue Oct 16, 2018 11:08 AM.


#49 FarmerPotato OFFLINE  

FarmerPotato

    Chopper Commander

  • 144 posts
  • Location:Austin, TX

Posted Tue Oct 16, 2018 9:28 AM

I didn't understand how this DSRLNK from MG Smart Programmer works either, the things it does!

 

For starters, DSRWS = DLINK1. That's seriously weird. However, it ends up saving a chunk of memory.

DSRLNK DATA DSRWS,DLINK1

Registers overlap with the code! There are DATA 0 statements overlapping R12-R15; R12 is the only free register here (R13-R15 store the caller's context.)

 

R3 overlaps the argument to the LWPI GPLWS instruction.

I smell self-modifying code! Indeed, later on  MOV @NAMLEN,R3   modifies the argument of LWPI GPLWS. However, that instruction is never executed again.

It's a good thing, because the argument is set not to a CPU address, but the VDP address of the PAB opcode. That would be meaningless in a LWPI instruction.

 

I found a commented version here, on page 290:  http://ti99ers.org/d...d=13&file_id=19

*<<------------------------------------------------------>>*
* This section of code is only executed once to find the *
* GROM address for the GPL DSRNK, which is placed at DSRADD*
* and R12 is set to >2000 to indicate that the address is *
* found and to be used as a mask for EQ & CND *
*----------------------------------------------------------*
   LWPI GPLWS                        R2,R3                else load GPL workspace

So, instead of allocating 32 bytes of workspace with

DSRWS BSS 32

it fills 24 bytes with code for DSRLNK leaving 8 bytes for  register storage (R12-R15).

 

R3 clobbers part of the DLINK1 code that is only executed once.. actually all of the registers are available at DLINK3, after  DLINK1 has run once, but only one is really needed.

 

 

 

Very smart, Smart Programmer.


Edited by FarmerPotato, Tue Oct 16, 2018 9:29 AM.


#50 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,806 posts
  • Location:Silver Run, Maryland

Posted Tue Oct 16, 2018 10:16 AM

Thank you! I'm not quite clear as to how the DSRLNK routine works, but it's not really important that I do at this stage as long as it works. I get everything else and indeed it sounds pretty straightforward.

I'll post an update later today.

 

I have no idea how that works. It's in the EA manual. Although I've never had occasion to use it, it seems like a good fit for what you want to do. 

 

As implemented by the Editor/Assembler cartridge, TI Forth and Paolo Bagneresi, DSRLNK does the following:
  • Sets up for DSR call
    • pops call type (8 = level 3 device routine; 10 = level 1 or 2 subprogram)
    • processes device/subprogram name ( from pointer at >8356 to name-length in PAB) for DSR
      • checks for 0 < name-length (counted before ‘.’ if present) < 8
      • stores length at >8354 for DSR
      • adjusts >8356 to point after ‘.’ (if found) in device name
  • Switches to GPLWS (GPL workspace = >83E0)
  • Searches peripheral ROMs at CRU addresses >1000 – >1F00 in >100-byte increments for device/subprogram name
    • if found, runs DSR routine for device/subprogram
      • if error return, continues ROM search
      • if normal return, restores WS, processes returned information and returns to caller
    • if no ROM contains device/subprogram name, restores WS and returns to caller with device error
InsaneMultitasker’s DSRLNK probably works the same as the above, but I have not analyzed it, so cannot say for sure.
 
If you use the GPL DSRLNK published in MG’s Smart Programmer mentioned by FarmerPotato, as does fbForth 2.0, GROM and cassette-tape DSRs are searched as well.
 
...lee





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users