Jump to content

Photo

Specialized file access from XB


79 replies to this topic

#51 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,269 posts

Posted Tue Oct 16, 2018 11:48 AM

The version I posted is a fairly standard routine and should match up with most if not all of what Lee outlined.

 

I have steered clear of the MG DSRLNK for Geneve-specific compatibility reasons, and I have had no reason to provide for GROM or cassette within any of my assembly language programs. It is certainly a nice bit of coding.

 

Fortunately, understanding the DSRLNK routine's inner workings is usually not a per-requisite to using it.



#52 Vorticon OFFLINE  

Vorticon

    River Patroller

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

Posted Tue Oct 16, 2018 9:25 PM

Success! The key to this whole affair, besides the need for a DSRLNK routine, was properly setting up the string buffer space in VDP.

Thank you for all the help guys!

That said, fetching the loaded image byte by byte is slow, and will be even slower as the bytes are processed and sent to the plotter. I wish there was a POKEV for the XB environment, and I'm not sure why TI would leave such an important routine out, just like DSRLNK and GPLLNK...

Interestingly, the XB screen got corrupted during the byte transfers as I was printing every received byte for testing purposes, and I'm not clear as to why.

 

Here's the assembly test code. It's not pretty but it works. I shamelessly incorporated Senior Falcon's code snippet into it. 

Spoiler

 

And here's the test XB code

10 CALL CLEAR
20 CALL INIT
30 CALL LOAD("DSK1.IMGLOAD")
35 CALL LINK("GETSTR")
40 INPUT "ENTER FILE PATH.NAME: ":N$
50 CALL LINK("RDFIL",N$)
55 PRINT "FILE OPENED!"
60 FOR I=1 TO 6400
70 CALL LINK("RDBYTE",BYTE)
80 PRINT BYTE;
90 NEXT I


#53 HOME AUTOMATION OFFLINE  

HOME AUTOMATION

    Chopper Commander

  • 128 posts

Posted Tue Oct 16, 2018 11:44 PM

Hi Vorticon,

I noticed you have bytes 2 and 3(data buffer address) of the PAB set to 0000, this is the starting address of the screen definition table in XB and most or all other TI software... this address is the upper left hand corner character position of the screen. So buffered data appears and disappears from the display as the buffer is poulated. Because Basic uses a >60 character table offset your data appears on the screen scrambled. I've used this technique to help recover data from damaged unreadable tapes. And to peek into adventure tapes before adventure editor was available.
 



#54 Vorticon OFFLINE  

Vorticon

    River Patroller

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

Posted Wed Oct 17, 2018 5:56 AM

Hi Vorticon,

I noticed you have bytes 2 and 3(data buffer address) of the PAB set to 0000, this is the starting address of the screen definition table in XB and most or all other TI software... this address is the upper left hand corner character position of the screen. So buffered data appears and disappears from the display as the buffer is poulated. Because Basic uses a >60 character table offset your data appears on the screen scrambled. I've used this technique to help recover data from damaged unreadable tapes. And to peek into adventure tapes before adventure editor was available.
 

 

Yes I'm aware of that. The >0000 buffer address in the PAB is just a placeholder and gets replaced by the actual string space address once the GETSTR routine is run by XB because I don't know initially where XB is going to store the data :) I don't think that's the issue...

* LOAD FILE
       MOVB @SBUFF,@PAB+9     * UPDATE THE PAB WITH FILE NAME LENGTH
--->   MOV  @BUFADR,@PAB+2     * UPDATE PAB
       CLR  R3


#55 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Wed Oct 17, 2018 6:05 AM

 

Interestingly, the XB screen got corrupted during the byte transfers as I was printing every received byte for testing purposes, and I'm not clear as to why.

This might be a problem with the get string space routine. I noticed it when testing with this code, which forces a garbage collection:

10 A$="Hello World"::GOTO 10

 

Here is another way to reserve VDP:

CALL LOAD(-31888,30,255) This reserves VDP from V1F00 on. But it might mess up disk access. I haven't tested that yet.

 

(Edit) I think this will work for you. I think disk access uses the same memory locations as usual. With CALL FILES(3) that is from V37D8 to V3FFF. With the numbers I give above  V1F00 to V37D7 are available for your use. This doesn't have to be in the immediate mode. To include it in a program do this:

10 CALL INIT::CALL LOAD(-31888,30,255)::RUN 20

20 program continues...


Edited by senior_falcon, Wed Oct 17, 2018 6:21 AM.


#56 Vorticon OFFLINE  

Vorticon

    River Patroller

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

Posted Wed Oct 17, 2018 6:23 AM

The screen corruption is not a huge deal as it does not interfere with the functionality I need from the program.
That said, using XB as the base environment might end up being too slow (will be testing as soon as I receive a part) and I might have to do the whole thing in pure assembly... Regardless this was a great educational experience in XB usage with assembly disk access!

#57 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Wed Oct 17, 2018 8:22 AM

The screen corruption is not a huge deal

Hard to say. Other things might be corrupted as well and lurking iin the shadows waiting to bite. I believe the technique with CALL LOAD(-31888) has no side effects other than smaller stack space, assuming disk access works properly. (Which my quick test this morning seems to validate.)



#58 Vorticon OFFLINE  

Vorticon

    River Patroller

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

Posted Wed Oct 17, 2018 9:18 AM

Hard to say. Other things might be corrupted as well and lurking iin the shadows waiting to bite. I believe the technique with CALL LOAD(-31888) has no side effects other than smaller stack space, assuming disk access works properly. (Which my quick test this morning seems to validate.)


Ok I'll give it a try. For my own edification however, what exactly is going wrong with the string allocation routine?

#59 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Wed Oct 17, 2018 10:47 AM

For my own edification however, what exactly is going wrong with the string allocation routine?

I have no idea. I have never had occasion to use this routine. Either I have not set it up correctly or it has a bug. (The first is the more likely of the two.) Perhaps Rich can shed some light on this.



#60 RXB OFFLINE  

RXB

    River Patroller

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

Posted Wed Oct 17, 2018 2:31 PM

String space allocation XB Assembly ROM:

 0708            ************************************************************
  0709            * ASSGNV, callable from GPL or 9900 code, to assign a value 
  0710            * to a symbol (strings and numerics) . If numeric, the  
  0711            * 8 byte descriptor is in the FAC. The descriptor block   
  0712            * (8 bytes) for the destination variable is on the stack.   
  0713            * There are two types of descriptor entries which are   
  0714            * created by SMB in preparation for ASSGNV, one for   
  0715            * numerics and one for strings.   
  0716            *                     NUMERIC   
  0717            * +-------------------------------------------------------+ 
  0718            * |S.T. ptr | 00 |       |Value ptr |                     | 
  0719            * +-------------------------------------------------------+ 
  0720            *                     STRING  
  0721            * +-------------------------------------------------------+ 
  0722            * |Value ptr| 65 |       |String ptr|String length        | 
  0723            * +-------------------------------------------------------+ 
  0724            *   
  0725            * CRITICAL NOTE: Because of the BL @POPSTK below, if a  
  0726            * string entry is popped and a garbage collection has taken 
  0727            * place while the entry was pushed on the stack, and the  
  0728            * entry was a permanent string the pointer in FAC4 and FAC5 
  0729            * will be messed up. A BL @VPOP would have taken care of  
  0730            * the problem but would have taken a lot of extra code.   
  0731            * Therefore, at ASSG50-ASSG54 it is assumed that the  
  0732            * previous value assigned to the destination variable has   
  0733            * been moved and the pointer must be reset by going back to 
  0734            * the symbol table and getting the correct value pointer.   
  0735            ************************************************************
  0736 6334 C28B  ASSG   MOV  R11,R10           Save the retun address  
  0737 6336 06A0         BL   @ARGTST           Check arg and variable type   
       6338 6B6E  
  0738 633A 02CC         STST R12               Save status of type   
  0739 633C 06A0         BL   @POPSTK           Pop destination descriptor  
       633E 60D4  
  0740            *                              into ARG   
  0741 6340 0A3C         SLA  R12,3             Variable type numeric?  
  0742 6342 1745         JNC  ASSG70            Yes, handle it as such  
  0743            * Assign a string to a string variable  
  0744 6344 C060         MOV  @ARG4,R1          Get destination pointer   
       6346 8360  
  0745            *                             Dest have non-null  value?  
  0746 6348 130B         JEQ  ASSG54            No, null->never assigned  
  0747            * Previously assigned - Must first free the old value   
  0748 634A 06A0         BL   @GET              Correct for POPSTK above  

 99/4 ASSEMBLER
BASSUP                                                       PAGE 0016
       634C 6C9A  
  0749 634E 835C         DATA ARG               Pointer is in ARG   
  0750            *   
  0751 6350 C801         MOV  R1,@ARG4          Correct ARG+4,5 too   
       6352 8360  
  0752            *-----------------------------------------------------------
  0753            * Fix "Assigning a string to itself when memory is full can 
  0754            *      destroy the string" bug, 5/22/81   
  0755            * Add the following 2 lines and the label ASSG80  
  0756 6354 8801         C    R1,@FAC4          Do not do anything in assign- 
       6356 834E  
  0757            *                              ing a string to itself case  
  0758 6358 1317         JEQ  ASSG80            Detect A$=A$ case, exit   
  0759            *-----------------------------------------------------------
  0760 635A 04C6         CLR  R6                Clear for zeroing backpointer 
  0761 635C 06A0         BL   @STVDP3           Free the string   
       635E 18AA  
  0762 6360 C120  ASSG54 MOV  @FAC6,R4          Is source string a null?  
       6362 8350  
  0763 6364 130C         JEQ  ASSG57            Yes, handle specially   
  0764 6366 C0E0         MOV  @FAC,R3           Get address of source pointer 
       6368 834A  
  0765 636A 0283         CI   R3,>001C          Got a temporay string?  
       636C 001C  
  0766 636E 160D         JNE  ASSG56            No, more complicated  
  0767 6370 C120         MOV  @FAC4,R4          Pick up direct ptr to string  
       6372 834E  
  0768            * Common string code to set forward and back pointers   
  0769 6374 C1A0  ASSG55 MOV  @ARG,R6           Ptr to symbol table pointer   
       6376 835C  
  0770 6378 C044         MOV  R4,R1             Pointer to source string  
  0771 637A 06A0         BL   @STVDP3           Set the backpointer   
       637C 18AA  
  0772 637E C060  ASSG57 MOV  @ARG,R1           Address of symbol table ptr   
       6380 835C  
  0773 6382 C184         MOV  R4,R6             Pointer to string   
  0774 6384 06A0         BL   @STVDP            Set the forward pointer   
       6386 18AE  
  0775 6388 045A  ASSG80 B    *R10              Done, return  
  0776            * Symbol-to-symbol assigments of strings  
  0777            * Must create copy of string  
  0778 638A C820  ASSG56 MOV  @FAC6,@BYTE       Fetch length for GETSTR   
       638C 8350  
       638E 830C  
  0779            * NOTE: FAC through FAC+7 cannot be destroyed   
  0780            *       address^of string length^of string  
  0781 6390 06A0         BL   @VPUSH            So save it on the stack   
       6392 6BAA  
  0782 6394 C80A         MOV  R10,@FAC          Save return link in FAC since 
       6396 834A  
  0783            *                              GETSTR does not destroy FAC  
  0784 6398 06A0         BL   @GETSTR           Call GPL to do the GETSTR   
       639A 736C  
  0785 639C C2A0         MOV  @FAC,R10          Restore return link   
       639E 834A  
  0786 63A0 06A0         BL   @VPOP             Pop the source info back  
       63A2 6C2A  
  0787            * Set up to copy the source string into destination   
  0788 63A4 C0E0         MOV  @FAC4,R3          R3 is now copy-from   

 99/4 ASSEMBLER
BASSUP                                                       PAGE 0017
       63A6 834E  
  0789 63A8 C160         MOV  @SREF,R5          R5 is now copy-to   
       63AA 831C  
  0790 63AC C105         MOV  R5,R4             Save for pointer setting  
  0791            * Registers to be used in the copy  
  0792            * R1 - Used for a buffer  
  0793            * R3 - Copy-from address  
  0794            * R2 - # of bytes to be moved   
  0795            * R5 - copy-to address  
  0796 63AE C0A0         MOV  @FAC6,R2          Fetch the length of the string
       63B0 8350  
  0797 63B2 0265         ORI  R5,WRVDP          Enable the VDP write  
       63B4 4000  
  0798 63B6 06A0  ASSG59 BL   @GETV1            Get the character   
       63B8 1880  
  0799 63BA D7E0         MOVB @R5LB,*R15        Load out destination address  
       63BC 83EB  
  0800 63BE 0583         INC  R3                Increment the copy-from   
  0801 63C0 D7C5         MOVB R5,*R15           1st byte of address to  
  0802 63C2 0585         INC  R5                Increment for next character  
  0803 63C4 D801         MOVB R1,@XVDPWD        Put the character out   
       63C6 8C00  
  0804 63C8 0602         DEC  R2                Decrement count, finished?  
  0805 63CA 15F5         JGT  ASSG59            No, loop for more   
  0806 63CC 10D3         JMP  ASSG55            Yes, now set pointers   
  0807            * Code to copy a numeric value into the symbol table  
  0808 63CE 0202  ASSG70 LI   R2,8              Need to assign 8 bytes  
       63D0 0008  
  0809 63D2 C160         MOV  @ARG4,R5          Destination pointer(R5)   
       63D4 8360  
  0810            *                              from buffer(R4), (R2)bytes   
  0811 63D6 C0E0         MOV  @RAMTOP,R3        Does ERAM exist?  
       63D8 8384  
  0812 63DA 160C         JNE  ASSG77            Yes, write to ERAM  
  0813            *                             No, write to VDP  
  0814 63DC D7E0         MOVB @R5LB,*R15        Load out 2nd byte of address  
       63DE 83EB  
  0815 63E0 0265         ORI  R5,WRVDP          Enable the write to the VDP   
       63E2 4000  
  0816 63E4 D7C5         MOVB R5,*R15           Load out 1st byte of address  
  0817 63E6 0204         LI   R4,FAC            Source is FAC   
       63E8 834A  
  0818 63EA D834  ASSG75 MOVB *R4+,@XVDPWD      Move a byte   
       63EC 8C00  
  0819 63EE 0602         DEC  R2                Decrement the counter, done?  
  0820 63F0 15FC         JGT  ASSG75            No, loop for more   
  0821 63F2 045A         B    *R10              Yes, return to the caller   
  0822 63F4 0204  ASSG77 LI   R4,FAC            Source is in FAC  
       63F6 834A  
  0823 63F8 DD74  ASSG79 MOVB *R4+,*R5+         Move a byte   
  0824 63FA 0602         DEC  R2                Decrement the counter, done?  
  0825 63FC 15FD         JGT  ASSG79            No, loop for more   
  0826 63FE 045A         B    *R10              Yes, return to caller   
  0827            * Check for required token  
  0828 6400 D01D  SYNCHK MOVB *R13,R0           Read required token   
  0829            *   
  0830 6402 9800         CB   R0,@CHAT          Have the required token?  
       6404 8342  
  0831 6406 1304         JEQ  PGMCH             Yes, read next character  

 99/4 ASSEMBLER
BASSUP                                                       PAGE 0018
  0832 6408 06A0         BL   @SETREG           Error return requires R8/R9 se
       640A 1E7A  
  0833 640C 0460         B    @ERRSYN           * SYNTAX ERROR  
       640E 664E  
  0834            *      PGMCH - GPL entry point for PGMCHR to set up register
  0835 6410 C30B  PGMCH  MOV  R11,R12           Save return address   
  0836 6412 06A0         BL   @PGMCHR           Get the next character  
       6414 6C74  
  0837 6416 D808         MOVB R8,@CHAT          Put it in for GPL   
       6418 8342  
  0838 641A 045C         B    *R12              Return to GPL   
  0839 641C 045B         RT                     And return to the caller  
  0840 641E C13B  PUTV   MOV  *R11+,R4  
  0841 6420 C114         MOV  *R4,R4  
  0842 6422 D7E0  PUTV1  MOVB @R4LB,*R15  
       6424 83E9  
  0843 6426 0264         ORI  R4,WRVDP  
       6428 4000  
  0844 642A D7C4         MOVB R4,*R15   
  0845 642C 1000         NOP  
  0846 642E D801         MOVB R1,@XVDPWD  
       6430 8C00  
  0847 6432 045B         RT   
  0848            * MOVFAC - copies 8 bytes from VDP(@FAC4) or ERAM(@FAC4)  
  0849            *          to FAC   
  0850 6434 C060  MOVFAC MOV @FAC4,R1           Get pointer to source   
       6436 834E  
  0851 6438 0202         LI  R2,8               8 byte values   
       643A 0008  
  0852 643C 0203         LI  R3,FAC             Destination is FAC  
       643E 834A  
  0853 6440 C020         MOV @RAMTOP,R0         Does ERAM exist?  
       6442 8384  
  0854 6444 160A         JNE MOVFA2             Yes, from ERAM  
  0855            *                             No, from VDP RAM  
  0856 6446 06C1         SWPB R1  
  0857 6448 D7C1         MOVB R1,*R15           Load 2nd byte of address  
  0858 644A 06C1         SWPB R1  
  0859 644C D7C1         MOVB R1,*R15           Load 1st byte of address  
  0860 644E 0205         LI   R5,XVDPRD   
       6450 8800  
  0861 6452 DCD5  MOVF1  MOVB *R5,*R3+          Move a byte   
  0862 6454 0602         DEC  R2                Decrement counter, done?  
  0863 6456 15FD         JGT  MOVF1             No, loop for more   
  0864 6458 045B         RT                     Yes, return to caller   
  0865 645A DCF1  MOVFA2 MOVB *R1+,*R3+   
  0866 645C 0602         DEC  R2  
  0867 645E 16FD         JNE  MOVFA2  
  0868 6460 045B         RT   
  0869 6462 045B         RT                     And return to caller  
  0870            ************************************************************

VDP Garbage Collection is called COMPCT:

  2629            ************************************************************
  2630            * COMPCT - Is the string garbage collection routine. It can 
  2631            *          be invoked by GETSTR or MEMCHK. It copies all  
  2632            *          used strings to the top of the string space  
  2633            *          suppressing out all of the unused strings  
  2634            *    INPUT : None   
  2635            *    OUTPUT: UPDATED @STRSP AND @STREND   
  2636            *    USES  : R0-R6 AS TEMPORARIES   
  2637            ************************************************************
  2638 73D8 C1CB  COMPCT MOV  R11,R7            Save rtn address  
  2639 73DA C020         MOV  @FREPTR,R0        Get pointer to free space   
       73DC 8340  
  2640 73DE C160         MOV  @STRSP,R5         Get pointer to string space   
       73E0 8318  
  2641 73E2 C800         MOV  R0,@STRSP         Set new string space pointer  
       73E4 8318  
  2642 73E6 0585         INC  R5                Compensate for decrement  
  2643 73E8 0605  COMP03 DEC  R5                Point at length of string   
  2644 73EA 8160         C    @STREND,R5        At end of string space?   
       73EC 831A  
  2645 73EE 1A03         JL   COMP05            No, check this string for copy
  2646 73F0 C800         MOV  R0,@STREND        Yes, set end of free space  
       73F2 831A  
  2647 73F4 0457         B    *R7               Return to caller  
  2648 73F6 C085  COMP05 MOV  R5,R2             Copy ptr to end in case moved 
  2649 73F8 C0C5         MOV  R5,R3             Copy ptr to end in read length
  2650 73FA 06A0         BL   @GETV1            Read the length byte  
       73FC 1880  
  2651 73FE D181         MOVB R1,R6             Put it in R6 for address  
  2652 7400 0986         SRL  R6,8              Need in LSB for word  

 99/4 ASSEMBLER
STRINGS                                                      PAGE 0061
  2653 7402 6146         S    R6,R5             Point at the string start   
  2654 7404 0225         AI   R5,-3             Point at the back pointer   
       7406 FFFD  
  2655 7408 C0C5         MOV  R5,R3             Set up for GETV   
  2656 740A 06A0         BL   @GET1             Get the backpointer   
       740C 6C9E  
  2657 740E C041         MOV  R1,R1             Is this string garbage?   
  2658 7410 13EB         JEQ  COMP03            Yes, just ignore it   
  2659            * PERTINENT REGISTERS AT THIS POINT   
  2660            *        R0 - is where the sting will end   
  2661            *        R6 - # of bytes to be moved(does not)  
  2662            *             include lengths and backpointer   
  2663            *        R2 - points at trailing length byte of string  
  2664            *             to be moved   
  2665            * IN GENERAL : MOVE (R6) BYTES FROM VDP(R2-R6) TO VDP(R0-R6)
  2666            *              VDP(R0-R6) moving backwards i.e. the last  
  2667            *              byte of the entry is moved first, then the   
  2668            *              next to the last byte...   
  2669 7412 8DB6         C    *R6+,*R6+         INCR by 4 to include overhead 
  2670 7414 C0C2         MOV  R2,R3             Restore ptr to end of string  
  2671 7416 C100         MOV  R0,R4             Get ptr to end of string space
  2672 7418 06A0  COMP10 BL   @GETV1            Read a byte   
       741A 1880  
  2673 741C 06A0         BL   @PUTV1            Write a byte  
       741E 6422  
  2674 7420 0603         DEC  R3                Decrement source pointer  
  2675 7422 0604         DEC  R4                Decrement destination pointer 
  2676 7424 0606         DEC  R6                Decrement the counter   
  2677 7426 15F8         JGT  COMP10            Loop if not finished  
  2678 7428 0244         ANDI R4,>3FFF          Delete VDP write-enable & reg 
       742A 3FFF  
  2679 742C C004         MOV  R4,R0             Set new free space pointer  
  2680 742E 0584         INC  R4                Point at backpointer just move
  2681 7430 C0C4         MOV  R4,R3             Copy pointer to read it   
  2682 7432 06A0         BL   @GET1             Get the backpointer   
       7434 6C9E  
  2683            * R1 now contains the address of the forward pointer  
  2684 7436 C183         MOV  R3,R6             Address of the string entry   
  2685 7438 0226         AI   R6,3              Point at the string itself  
       743A 0003  
  2686            * R6 now contains the address of the string   
  2687 743C 06A0         BL   @STVDP            Reset the forward pointer   
       743E 18AE  
  2688 7440 10D3         JMP  COMP03            Loop for next string  

Both ASSIGN and COMPCT are in ROM 1 not ROM 2.

 

I could have posted the GPL sections too but doubt you could follow what is going on with GPL  as you have worked with Assembly more.

 

If I were you I would use ASSIGN to set up my space I wanted to use that way not be affected as it does a Garbage collection first (COMPCT) for you.


Edited by RXB, Wed Oct 17, 2018 2:33 PM.


#61 Vorticon OFFLINE  

Vorticon

    River Patroller

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

Posted Wed Oct 17, 2018 4:51 PM

Sorry Rich but I'm still totally in the dark here as to why Harry's routine is corrupting the screen...



#62 Vorticon OFFLINE  

Vorticon

    River Patroller

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

Posted Wed Oct 17, 2018 5:00 PM

This might be a problem with the get string space routine. I noticed it when testing with this code, which forces a garbage collection:

10 A$="Hello World"::GOTO 10

 

Here is another way to reserve VDP:

CALL LOAD(-31888,30,255) This reserves VDP from V1F00 on. But it might mess up disk access. I haven't tested that yet.

 

(Edit) I think this will work for you. I think disk access uses the same memory locations as usual. With CALL FILES(3) that is from V37D8 to V3FFF. With the numbers I give above  V1F00 to V37D7 are available for your use. This doesn't have to be in the immediate mode. To include it in a program do this:

10 CALL INIT::CALL LOAD(-31888,30,255)::RUN 20

20 program continues...

 

 

OK so it works just fine with the CALL LOAD.  Thanks!



#63 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,269 posts

Posted Wed Oct 17, 2018 5:05 PM

recommend that you move your PAB from 0x3A00 to a known, open memory location if you plan to use the program with a standard disk controller/nano device. 



#64 Vorticon OFFLINE  

Vorticon

    River Patroller

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

Posted Wed Oct 17, 2018 5:11 PM

recommend that you move your PAB from 0x3A00 to a known, open memory location if you plan to use the program with a standard disk controller/nano device. 

 

This was a known open location. I had it initially at >1000 but it was getting overwritten...



#65 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,269 posts

Posted Wed Oct 17, 2018 5:55 PM

 

This was a known open location. I had it initially at >1000 but it was getting overwritten...

3A00 won't be overwritten immediately but i is in the disk buffer area, and will be corrupted (or you'll corrupt the disk buffer) unless you performed a CALL FILES to reduce the total files, or some other method.  I didn't see anything like that in your code. 



#66 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Wed Oct 17, 2018 6:27 PM

Insane Multitasker is right - you need to put the PAB into a safe memory location. When I saw that your code reserved >1900 bytes I just figured you would put the PAB in that block of reserved memory along with the buffer, and didn't study your code any more. 

 CALL LOAD(-31888,30,255) reserves V1F00 to V37D7 with the default CALL FILES(3). You can put the >1800 byte long buffer at >1F00 and the PAB at >3700.



#67 RXB OFFLINE  

RXB

    River Patroller

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

Posted Wed Oct 17, 2018 10:35 PM

 

This was a known open location. I had it initially at >1000 but it was getting overwritten...

As XB uses Strings (for both string$ or for Numbers it allocates VDP up to Program space if only running from VDP, 

but if running with 32K is only goes up to file buffers space. 

As per what I posted String starts from >09B0 up to >37DA thus your using >1000 was going to crash EZ unless you only used a few variables and none ever again.



#68 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

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

Posted Thu Oct 18, 2018 7:06 AM

You might try changing the value in >8370 by subtracting >1900 from it to preserve the area starting 1 byte above it.  This would certainly tell XB not to interfere with your buffer, but, with “CALL FILES(3)” and a TI disk controller, it would limit XB to 5415 bytes for strings, etc. (from >09B0 – >1ED7) when it normally would have 11815 bytes (from >09B0 – >37D7).  Though XB should leave your buffer alone, changing >8370 to >1ED7 is almost equivalent to “CALL FILES(16)”, which XB will not allow—“CALL FILES(9)” is XB’s limit (>2BB3 in >8370 or 8707 bytes for strings, etc).
 
Also, once you change the value in >8370, you probably should not change the number of the 4A’s file buffers with “CALL FILES()”.
 
...lee


#69 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Oct 18, 2018 4:34 PM

 

You might try changing the value in >8370 by subtracting >1900 from it to preserve the area starting 1 byte above it.  This would certainly tell XB not to interfere with your buffer, but, with “CALL FILES(3)” and a TI disk controller, it would limit XB to 5415 bytes for strings, etc. (from >09B0 – >1ED7) when it normally would have 11815 bytes (from >09B0 – >37D7).  Though XB should leave your buffer alone, changing >8370 to >1ED7 is almost equivalent to “CALL FILES(16)”, which XB will not allow—“CALL FILES(9)” is XB’s limit (>2BB3 in >8370 or 8707 bytes for strings, etc).
 
Also, once you change the value in >8370, you probably should not change the number of the 4A’s file buffers with “CALL FILES()”.
 
...lee

 

TRUE!

CALL FILES does a Garbage collection (COMPCT in XB ROM) to dump any temporary variables or strings and temp used pointers.

Also empties VDP Stack of temporary stack entries.

 

Which is why after CALL FILES is used, you have to do a NEW



#70 Vorticon OFFLINE  

Vorticon

    River Patroller

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

Posted Fri Oct 19, 2018 9:01 AM

Insane Multitasker is right - you need to put the PAB into a safe memory location. When I saw that your code reserved >1900 bytes I just figured you would put the PAB in that block of reserved memory along with the buffer, and didn't study your code any more. 

 CALL LOAD(-31888,30,255) reserves V1F00 to V37D7 with the default CALL FILES(3). You can put the >1800 byte long buffer at >1F00 and the PAB at >3700.

 

The >1900 was a typo. It's supposed to be >1800 :) I'll keep it though and follow Tim's advice and store the PAB in the extra bytes.

Incidentally, with the full-blown XB control program, file access is not working again and the computer is locking up. I'm going to try Lee's suggestion of updating >8370 (highest available VDP RAM) and see if that solves the issue. Since I am now on real hardware, I do miss the wonderful Classic99 debugger!



#71 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 778 posts
  • Location:The Great White North

Posted Fri Oct 19, 2018 10:32 AM

 

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

 

Hi InsaneMultitasker,

 

Can you tell me what you use SAVE1...SAVE5 for.  I notice the code runs without using them.

 

B



#72 HOME AUTOMATION OFFLINE  

HOME AUTOMATION

    Chopper Commander

  • 128 posts

Posted Fri Oct 19, 2018 2:53 PM

While looking into something unrelated. I stumbled upon somethings regarding DSRs and XB parameter passing... was reminded of your thread. Sorry, If I haven't been much help... maybe I'm on to something useful this time. :)

DSRs
Introduction
Calling
Returning
Parameter passing: PABs

 

http://www.unige.ch/...i99/headers.htm



#73 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

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

Posted Fri Oct 19, 2018 3:30 PM

While looking into something unrelated. I stumbled upon somethings regarding DSRs and XB parameter passing... was reminded of your thread. Sorry, If I haven't been much help... maybe I'm on to something useful this time. :)

DSRs
Introduction
Calling
Returning
Parameter passing: PABs

 

http://www.unige.ch/...i99/headers.htm

 

Thierry Nouspikel’s site is always a first-rate reference for things TI-99/4A!

 

...lee



#74 HOME AUTOMATION OFFLINE  

HOME AUTOMATION

    Chopper Commander

  • 128 posts

Posted Fri Oct 19, 2018 7:04 PM

Agreed... sometimes the real gems are hidden a little bit.



#75 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,269 posts

Posted Fri Oct 19, 2018 7:20 PM

 

Hi InsaneMultitasker,

 

Can you tell me what you use SAVE1...SAVE5 for.  I notice the code runs without using them.

 

B

To the best of my recollection, I've not used SAVE1-5 in my programs.  Maybe the words are used for re-entrant DSR calls. I believe Bruce Harrison wrote a few articles on this topic in Micropendium.   Ss noted in my post, I didn't write this version but it is pretty much standard.  In fact, Paul C.'s Fastterm source code contains a very similar DSRLNK that he labels "ultra standard".

 

I thought the Editor Assembler manual contained a listing of the DSRLNK routine.  I took a quick look at my manual and could not find it.  Maybe I'm thinking of some other documentation.... anyone know where to find the published version? 






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users