Jump to content
IGNORED

Extended BASIC G.E.M.


senior_falcon

Recommended Posts

45 minutes ago, Willsy said:

My guess would be some sort of off-by-one error on the line length somehow.

I have modified XB to add a carriage return when listing to disk. The carriage return makes it so that DV2XB can know where each line ends. The other piece of information is that the extra character is >6D which is carriage return plus the XB offset. It seems that somehow it is adding the carriage return when it shouldn't be. I don't think this will be very hard to track down.

  • Like 1
Link to comment
Share on other sites

This revision should deal with the problems that Victor encountered. My first fix was good, but this revision should be perfect.

In dealing with Victor's problem, another minor issue with LIST "CLIP" was fixed.

By the way, although it is not mentioned in the Classic99 manual, you can LIST "CLIP":100-150 if you only want to list lines from 100-150

Also LIST "CLIP":150- will list from 150 to the end, and LIST "CLIP":-50 will list lines  from the beginning to line 50.

 

XB29GEM20220317.zip

See post #534 below for the latest version, XBGEM20220623

 

Edited by senior_falcon
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

As part of the fix for Victor's problem, I made it so XB 2.9 G.E.M. would load all 15 colors to the 15 unused character sets. The video shows all 256 characters being printed on the screen, with editing being done in 40 columns. These characters can be printed to the screen with HCHAR or VCHAR and would be useful as borders. N.B. This change costs nothing-all the usual XB characters from 30 to 159 can be defined.

UNUSEDCHARS.GIF.b03ae3ff8f5463875e0373c2b40a303e.GIF

  • Like 4
Link to comment
Share on other sites

There is an interesting quirk (feature?) in the latest version. It has to do with how XB places characters on the screen when listing. XB starts by placing the screen offset (>60) on the screen and then adds the character. Normally the color for >60 is set to transparent, so the first step puts an invisible character on the screen. With my changes >60 is a magenta block and you can sometimes see a brief flash of magenta before the character is added and displayed. I wasn't sure if it was an illusion, but I used the debugger and found that it is really happening.

 

Is anyone troubled by this?

  • Like 1
Link to comment
Share on other sites

I have not yet replaced PRINT or DISPLAY AT(row,column) with Assembly yet, but intend to do so in future, this should eliminate that effect.

It is after all created by GPL I believe not anything you have created.

  • Like 1
Link to comment
Share on other sites

After some investigation of XB ERROR PRINT when in editor mode works like this:

[2076]               ***********************************************************
[2077]               * ERPRNT - Print an error or warning message
[2078]               *
[2079]               * ERPRNT - Entry point for ERROR
[2080]               * ERPNT5 - Entry point for WARNING
[2081]               ***********************************************************
[2082] 6E0E 06,60,1C ERPRNT CALL G601C             Load the character table
[2083] 6E11 0F,83           XML  SCROLL            Scroll the screen
[2084] 6E13 BE,A2,E2        ST   >2A+OFFSET,V@NLNADD Put the * in
       6E16 8A
[2085] 6E17 BF,20,02        DST  NLNADD+2,@VARW    Set up for the message
       6E1A E4
[2086] 6E1B 86,74    ERPNT5 CLR  @KEYBD            Enable main console
[2087] 6E1D 33,00,01        MOVE 1,G@0(@FAC10),@ARG1  Get message length
       6E20 5D,00,00
       6E23 54
[2088] 6E24 86,5C           CLR  @ARG
[2089] 6E26 32,5C,B0        MOVE @ARG,G@1(@FAC10),V*VARW   Display
       6E29 20,00,01
       6E2C 54
[2090] 6E2D A1,20,5C        DADD @ARG,@VARW        Start location for " IN "
[2091] 6E30 D7,54,62        DCEQ MSG130,@FAC10     "* I/O ERROR [xx]xy"
       6E33 A6
[2092] 6E34 4E,4D           BR   G6E4D
[2093] 6E36 91,20           DINC @VARW             Update for one space
[2094]               *                              separation
[2095] 6E38 BC,5F,E0        ST   V@>04(@PABPTR),@ARG3   * Create high order resu
       6E3B 04,04
[2096] 6E3D 86,5E           CLR  @ARG2             Only display high order decim
[2097] 6E3F 06,6F,BA        CALL DISO              Display this number
[2098] 6E42 BC,5F,E0        ST   V@>05(@PABPTR),@ARG3  * Get low order result
       6E45 05,04
[2099] 6E47 E6,5F,05        SRL  5,@ARG3           Remove mose identification bi
[2100] 6E4A 06,6F,BA        CALL DISO              Output the number in decimal
[2101] 6E4D D7,54,60 G6E4D  DCEQ MSGFST,@FAC10  * Ready * (* RXB *)
       6E50 40
[2102] 6E51 6E,79           BS   G6E79
[2103] 6E53 06,00,36        CALL TONE2             Wake up the idiot!!!!
[2104] 6E56 8E,44           CZ   @PRGFLG           If program, print line #
[2105] 6E58 6E,79           BS   G6E79
[2106] 6E5A C7,20,02        DCH  >02F6,@VARW       It will pass EOL
       6E5D F6
[2107] 6E5E 4E,66           BR   G6E66
[2108] 6E60 0F,83           XML  SCROLL            Display on next line
[2109] 6E62 BF,20,02        DST  NLNADD+1,@VARW    Indent for the "IN"
       6E65 E3
[2110] 6E66 BF,E0,01 G6E66  DST  >C9CE,V@1(@VARW)   * Put in the "in"
       6E69 20,C9,CE
[2111] 6E6C A3,20,00        DADD 4,@VARW           Display location for line
       6E6F 04
[2112] 6E70 BC,76,42        ST   @CHAT,@EXPZ       ASC destroys CHAT
[2113] 6E73 06,A0,0A        CALL ASC               DISPLAY THE LINE #
[2114] 6E76 BC,42,76        ST   @EXPZ,@CHAT       Restore CHAT

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0040 
RXB 2022
[2115] 6E79 0F,83    G6E79  XML  SCROLL
[2116] 6E7B 00              RTN
[2117]               ***********************************************************

PRINT in PROGRAM or COMMAND mode is in ROM at >7B48 (specifically string display on screen):

3500            ************************************************************
  3501            * Decode which I/O utility is being called  
  3502            * Tag field following the XML IO has the following  
  3503            * meaning:  
  3504            *     0 - Line list - utility to search keyword table to  
  3505            *         restore keyword from token  
  3506            *     1 - Fill space - utility to fill record with space  
  3507            *         when outputting imcomplete records  
  3508            *     2 - Copy string - utility to copy a string, adding  
  3509            *         the screen offset to each character for display   
  3510            *         purposes  
  3511            *     3 - Clear ERAM - utility to clear ERAM at the address 
  3512            *         specified by the data word following the IO tag   
  3513            *         and the # of bytes specified by the length  
  3514            *         following the address word. Note that each data   
  3515            *         word is the address of a CPU memory location.   
  3516            ************************************************************

 99/4 ASSEMBLER
SCROLLS                                                      PAGE 0081
  3517 7B48 D01D  IO     MOVB *R13,R0           Read selector from GROM   
  3518 7B4A 0980         SRL  R0,8              Shift for decoding  
  3519 7B4C 1358         JEQ  LLIST             0 is tag for Line list  
  3520 7B4E 0600         DEC  R0  
  3521 7B50 132C         JEQ  FILSPC            1 is tag for Fill space   
  3522 7B52 0600         DEC  R0  
  3523 7B54 130E         JEQ  CSTRIN            2 is tag for Copy string  
  3524            *                             3 is tag for CLRGRM string  
  3525            *                                fall into it   
  3526            * CALGRM  
  3527            * R1 - address of clearing start  
  3528            * R2 - number of bytes to clear   
  3529 7B56 0201  CLRGRM LI   R1,PAD0           Get CPU RAM offset  
       7B58 8300  
  3530 7B5A C081         MOV  R1,R2             Need for next read too  
  3531 7B5C B81D         AB   *R13,@R1LB        Add address of ERAM pointer   
       7B5E 83E3  
  3532 7B60 C051         MOV  *R1,R1            Read the ERAM address   
  3533 7B62 B81D         AB   *R13,@R2LB        Read address of byte count  
       7B64 83E5  
  3534 7B66 C092         MOV  *R2,R2            Read the byte count   
  3535 7B68 04C0         CLR  R0                Clear of clearing ERAM  
  3536 7B6A DC40  CLRGR1 MOVB R0,*R1+           Clear a byte  
  3537 7B6C 0602         DEC  R2                One less to clear, done?  
  3538 7B6E 16FD         JNE  CLRGR1            No, loop for rest   
  3539 7B70 045B         RT                     Yes, return   
  3540            * CSTRIN  
  3541            * R0 - MNUM   
  3542            * R1 - GETV/PUTV buffer   
  3543            * R3 - FAC4/GETV address  
  3544            * R5 - return address   
  3545 7B72 C14B  CSTRIN MOV  R11,R5            Save return address   
  3546 7B74 D020         MOVB @MNUM,R0          Get MNUM  
       7B76 8302  
  3547 7B78 1317         JEQ  CSTR1O            If no bytes to copy   
  3548 7B7A 0980         SRL  R0,8              Shift to use as counter   
  3549 7B7C C120         MOV  @CCPADR,R4        Get copy-to address   
       7B7E 8308  
  3550 7B80 C0E0         MOV  @FAC4,R3          Get copy-from address   
       7B82 834E  
  3551 7B84 06A0  CSTRO5 BL   @GETV1            Get byte  
       7B86 1880  
  3552 7B88 B060         AB   @DSRFLG,R1        Add screen offset   
       7B8A 8317  
  3553 7B8C 06A0         BL   @PUTV1            Put the offset byte out   
       7B8E 6422  
  3554 7B90 0583         INC  R3                Increment from address  
  3555 7B92 0584         INC  R4                Increment to address  
  3556 7B94 0600         DEC  R0                One less to move  
  3557 7B96 16F6         JNE  CSTRO5            Loop if not done  
  3558 7B98 C803         MOV  R3,@FAC4          Restore for GPL   
       7B9A 834E  
  3559 7B9C D800  CSTR07 MOVB R0,@MNUM          Clear for GPL   
       7B9E 8302  
  3560      7BA3  CCBHFF EQU  $+3   
  3561 7BA0 0244         ANDI R4,>BFFF          Throw away VDP write enable   
       7BA2 BFFF  
  3562 7BA4 C804         MOV  R4,@CCPADR        Restore for GPL   
       7BA6 8308  

 99/4 ASSEMBLER
SCROLLS                                                      PAGE 0082
  3563      7BA8  FILSZ6 EQU  $   
  3564 7BA8 0455  CSTR1O B    *R5               Return  
  3565            * FILSPC  
  3566            * R0 - MNUM   
  3567            * R1 - Buffer for GETV/PUTV   
  3568            * R2 - MNUM1  
  3569            * R3 - Pointer for GETV   
  3570            * R4 - CCPADR, pointer for PUTV   
  3571            * R5 - return address   
  3572 7BAA C14B  FILSPC MOV  R11,R5            Save return address   
  3573 7BAC D0A0         MOVB @MNUM1,R2         Get pointer to end of record  
       7BAE 8303  
  3574 7BB0 1604         JNE  FILSZ1            If space to fill for sure   
  3575 7BB2 9802         CB   R2,@CCPPTR        Any filling to do?  
       7BB4 8306  
  3576 7BB6 1604         JNE  FILSZ2            Yes, do it normalling   
  3577 7BB8 0455         B    *R5               No, 255 record already full   
  3578 7BBA 9802  FILSZ1 CB   R2,@CCPPTR        Any filling to do?  
       7BBC 8306  
  3579 7BBE 12F4         JLE  FILSZ6            No, record is complete  
  3580 7BC0 70A0  FILSZ2 SB   @CCPPTR,R2        Compute # of bytes to change  
       7BC2 8306  
  3581 7BC4 B802         AB   R2,@CCPPTR        Point to end  
       7BC6 8306  
  3582 7BC8 D020         MOVB @DSRFLG,R0        Filling with zeroes?  
       7BCA 8317  
  3583 7BCC 160A         JNE  FILSZ3            No, fill with spaces  
  3584 7BCE C0E0         MOV  @PABPTR,R3        Check if internal files   
       7BD0 8304  
  3585 7BD2 0223         AI   R3,FLG            5 byte offset into PAB  
       7BD4 0005  
  3586 7BD6 04C1         CLR  R1                Initialize to test below  
  3587 7BD8 06A0         BL   @GETV1            Get byte from PAB   
       7BDA 1880  
  3588 7BDC 0241         ANDI R1,>0800          Internal?   
       7BDE 0800  
  3589 7BE0 1602         JNE  FILSZ4            Yes, zero fill  
  3590 7BE2 0220  FILSZ3 AI   R0,>2000          Add space character for filler
       7BE4 2000  
  3591 7BE6 0982  FILSZ4 SRL  R2,8              Shift count for looping   
  3592 7BE8 C120         MOV  @CCPADR,R4        Get start address to fill   
       7BEA 8308  
  3593 7BEC D040         MOVB R0,R1             Put filler in place for PUTV  
  3594 7BEE 06A0  FILSZ5 BL   @PUTV1            Put out a filler  
       7BF0 6422  
  3595 7BF2 0584         INC  R4                Increment filler position   
  3596 7BF4 0602         DEC  R2                One less to fill  
  3597 7BF6 16FB         JNE  FILSZ5            Loop if move  
  3598 7BF8 D802         MOVB R2,@MNUM1         Restore for GPL   
       7BFA 8303  
  3599 7BFC 10CF         JMP  CSTR07  
  3600            * LLIST   
  3601            * R0 - FAC - address of keytab in GROM  
  3602            * R1 - keyword length   
  3603 7BFE C30B  LLIST  MOV  R11,R12           Save return address   
  3604 7C00 06A0         BL   @PUTSTK           Save GROM address   
       7C02 60F2  
  3605 7C04 C020         MOV  @FAC,R0           Get address of keytab   
       7C06 834A  

 99/4 ASSEMBLER
SCROLLS                                                      PAGE 0083
  3606 7C08 D220         MOVB @CHAT,R8          Get token to search for   
       7C0A 8342  
  3607 7C0C 0201         LI   R1,1              Assume one character keyword  
       7C0E 0001  
  3608 7C10 DB40  LLISZ4 MOVB R0,@GRMWAX(R13)   Load GROM address of table  
       7C12 0402  
  3609 7C14 DB60         MOVB @R0LB,@GRMWAX(R13) Both bytes   
       7C16 83E1  
       7C18 0402  
  3610 7C1A D0DD         MOVB *R13,R3           Read address of x-char table  
  3611 7C1C D81D         MOVB *R13,@R3LB        Both bytes  
       7C1E 83E7  
  3612 7C20 A0C1  LLISZ5 A    R1,R3             Add length of keyword to point
  3613            *                              at token   
  3614 7C22 DB43         MOVB R3,@GRMWAX(R13)   Write out new GROM address  
       7C24 0402  
  3615 7C26 DB60         MOVB @R3LB,@GRMWAX(R13) Which points to token  
       7C28 83E7  
       7C2A 0402  
  3616 7C2C D11D         MOVB *R13,R4           Read token value  
  3617 7C2E D15D         MOVB *R13,R5           Read possible end of x-char   
  3618            *                              table  
  3619 7C30 9204         CB   R4,R8             Token value match?  
  3620 7C32 1307         JEQ  LLISZ6            Yes!!! Found the keyword  
  3621 7C34 0583         INC  R3                No, so skip token value   
  3622 7C36 9805         CB   R5,@CCBHFF        Reach end of x-char table?  
       7C38 7BA3  
  3623 7C3A 16F2         JNE  LLISZ5            No, so check more in the table
  3624 7C3C 05C0         INCT R0                Point into x+1 char table   
  3625 7C3E 0581         INC  R1                Try x+1 char table  
  3626 7C40 10E7         JMP  LLISZ4            Loop to check it  
  3627            * Come here when found keyword  
  3628 7C42 60C1  LLISZ6 S    R1,R3             Subtract length to pnt at K.W.
  3629 7C44 C803         MOV  R3,@FAC8          Save ptr to KeyWord for GPL   
       7C46 8352  
  3630 7C48 C801         MOV  R1,@FAC4          Save KeyWord length for GPL   
       7C4A 834E  
  3631 7C4C D808         MOVB R8,@FAC           Save CHAT for GPL   
       7C4E 834A  
  3632 7C50 06A0         BL   @GETSTK           Restore GROM addres   
       7C52 610E  
  3633 7C54 045C         B    *R12              And return to GPL   
  3634            ************************************************************

 

Link to comment
Share on other sites

  • 3 months later...

Here is XB 2.9 G.E.M. version 2.920220623

This fixes the problems with crashing that a few have encountered when using a real TI99. When a TI99 starts up, the memory is in an indeterminate state and there was a byte in the scratchpad that was not being properly initialized. Now GEM tries to start with the normal 32 column editor. However some consoles may power up with a bit set that tells GEM to start up using the 40 column editing mode. You can use CALL EDIT32, CALL EDIT40, or CALL EDIT80 to set the desired editing mode.

If you were in the 32 or 40 column editing mode, after a "quit", GEM starts up in that mode. If you were in the 80 column mode, GEM cancels that and starts in the default 32 column mode. This deals with a potential problem. If you do not have 80 column capabilities and type CALL EDIT80, the screen cannot be used. Now, after a "quit," GEM no longer tries to start in the 80 column mode.

 

XB29GEM20220623.zip

 

  • Like 4
Link to comment
Share on other sites

On 7/5/2022 at 5:30 AM, senior_falcon said:

Here is XB 2.9 G.E.M. version 2.920220623

This fixes the problems with crashing that a few have encountered when using a real TI99. When a TI99 starts up, the memory is in an indeterminate state and there was a byte in the scratchpad that was not being properly initialized. Now GEM tries to start with the normal 32 column editor. However some consoles may power up with a bit set that tells GEM to start up using the 40 column editing mode. You can use CALL EDIT32, CALL EDIT40, or CALL EDIT80 to set the desired editing mode.

If you were in the 32 or 40 column editing mode, after a "quit", GEM starts up in that mode. If you were in the 80 column mode, GEM cancels that and starts in the default 32 column mode. This deals with a potential problem. If you do not have 80 column capabilities and type CALL EDIT80, the screen cannot be used. Now, after a "quit," GEM no longer tries to start in the 80 column mode.

 

XB29GEM20220623.zip 1.74 MB · 12 downloads

 

The current Extended Basic G.E.M is not executable on a real TI-99/4A with NANOPEB.
Either the TI emits a whistling sound and crashes or after selecting options 1-9 in the main menu only black blocks are displayed and the TI crashes as well.

I assume that the XB G.E.M. is similarly extensive as the XB 2.7 Suite. The latter version definitely does not run on the FINAL GROM 99 with the original TI-99/4A.

In the emulators the whole package works.
Maybe the XB G.E.M. - version is too big for the FINAL GROM 99.

Greetings
Gernot

 

Edited by electricfling
Link to comment
Share on other sites

6 hours ago, electricfling said:

I assume that the XB G.E.M. is similarly extensive as the XB 2.7 Suite. The latter version definitely does not run on the FINAL GROM 99 with the original TI-99/4A.

Greetings
Gernot

 

The XB 2.7 Suite uses more than one GROM Base, which presents a problem for the FinalGROM. It was assembled on the expectation of being installed in an UberGROM cartridge, which allow for up to 120K of GROM and 512K of ROM. The 512K of ROM isn't a problem for the FinalGROM99, as it is designed to support that, but GROM is limited to 40K in one GROM base, which can be a problem when trying to use complex UberGROM images with it.

  • Like 2
Link to comment
Share on other sites

4 hours ago, senior_falcon said:

Make sure you are using the latest version. Earlier ones could have problems on a real TI99.

I have the last version in use.

Also I have renamed the two files to XB29GEMC.bin and XB29GEMG.bin.

Unfortunately it does not work.

The normal TI-XB version works fine, so it can't be the hardware.

Link to comment
Share on other sites

On 7/11/2022 at 2:14 PM, electricfling said:

I have the last version in use.

Also I have renamed the two files to XB29GEMC.bin and XB29GEMG.bin.

Unfortunately it does not work.

The normal TI-XB version works fine, so it can't be the hardware.

I do not have this hardware, so I cannot test this, but my understanding was that this works. Is anyone else able to verify that this does/does not work?

Link to comment
Share on other sites

On 7/10/2022 at 8:19 AM, electricfling said:

The current Extended Basic G.E.M is not executable on a real TI-99/4A with NANOPEB.
Either the TI emits a whistling sound and crashes or after selecting options 1-9 in the main menu only black blocks are displayed and the TI crashes as well.

I assume that the XB G.E.M. is similarly extensive as the XB 2.7 Suite. The latter version definitely does not run on the FINAL GROM 99 with the original TI-99/4A.

In the emulators the whole package works.
Maybe the XB G.E.M. - version is too big for the FINAL GROM 99.

Greetings
Gernot

 

I am not sure what would be going on here.  Wolfgang (wolhess) reports that XB 2.9 G.E.M. works as expected using the Final Grom. XB 2.9 G.E.M. uses 18 pages of cartridge rom.  Are there different versions of Final Grom?

Option 1 is for regular TI BASIC and to my knowledge that should not be influenced by anything in the cartridge port.

It sounds like you are using both Final Grom and the NanoPEB. Maybe something about that combination leads to problems.

Edited by senior_falcon
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

I have been working with Wolfgang, trying to determine what is causing the incompatibility when using XB 2.9 G.E.M. on the FinalGrom with the NanoPEB. He has done exhaustive tests but so far I can see no practical way to determine why this is failing. If I could load the failed copy of GEM and get into BASIC, I could dump the contents of ROM and GROM to disk to see if there is some copying error. But with the FinalGrom it doesn't look like you can even get to BASIC if loading GEM crashes the computer
 
In case anyone can make sense of this, here is how XB 2.9 G.E.M. is set up:
There are 5 groms, using 8K per grom, which I understand should be no problem.
There are 18 pages of 8K ROM, selected by writing to >6000, >6002, etc.
The rest of the ram is zeroed out, for a total of 512K.

 

Many years ago, assembly guru Bruce Harrison abandoned the TI99 because of frustration about incompatibilities between his software and the newer 3rd party hardware being developed. More and more, I am beginning to see that as an attractive option.

Link to comment
Share on other sites

@Tursi,

I suppose you meant this in a minimalistic/case-specific way.

 

The Image in question, requests to  be loaded as GROM/ROM(40K/512K), this happens before the image is run. This image's page switching, should operate in basically the same way as Classic 99 is already doing. I suppose there could be a difference in how writes above >607E, are handled(how/do they wrap-around?).

 

Perhaps I failed to gather the entire scope of your question.

---

Part of the FinalGROM99's image loader, runs from PAD, and awaits non-zero values at a range within the >6000->7FFF, bank. If only GROM is to be loaded, I believe FinalGROM99 simulates data availability there, in order to trick out the image loader. Could signals from the NANOPEB cause this area to appear zeroed-out, or not, at the wrong moment? Perhaps causing the image to execute before fully loading? Alternately, perhaps the loader's presence in PAD, is interfering with the NANOPEB's expectations.

 

I don't fully comprehend whether the issue occurs from power-on, or only from menu selection, or from which if not both menus.

Link to comment
Share on other sites

7 hours ago, Reciprocating Bill said:

Although the link above (#534) indicates version XB29GEM20220623, version XB29GEM20220317 is what downloads. 

 

6 hours ago, HOME AUTOMATION said:

I sort of assumed that was just an old folder name...

 

Yes, that is correct. It is an old folder name. The grom file in that folder was modified on June 23

Link to comment
Share on other sites

13 hours ago, HOME AUTOMATION said:

Perhaps I failed to gather the entire scope of your question.

It's pretty open... I guess specifically I was asking whether @senior_falcon is using any features of the FinalGROM, or if it's just loading as an image.

 

Loading just as an image, Classic99 will assume that the physical ROM to emulate is the smallest possible to simulate the file loaded (ie: the next power of two). If FinalGROM doesn't do that, maybe it's as simple as padding the file out to 512k and seeing if that reproduces the hang. As a shot in the dark, I'll try that ;)

 

(edit: pad out to 1MB, rather. And that had no effect, everything still seemed to work fine.)

 

 

Edited by Tursi
  • Like 2
Link to comment
Share on other sites

  • 2 months later...

I noticed a strange behavior of XB256 with CALL LINK("VWRITE",memory address, string,...), using Ti994w or Classic 99 emulators.
In a game program that I am writing, I use this subroutine to permit me to change some sprites pattern faster than can do CALL CHAR and it works fine...As long as I pass two VDP writings by specifying the memory address and a string of 32 characters long for each of them.

In the same subroutine, If I add a third writing with always a 32 characters long string, things became odd: Most of the time it works but sometimes (it is totally random and appears very few times), some characters on the screen (not those that compose the Sprites) have suddenly their pattern been changed (garbage) and, sometimes too, Sprites motions are altered by taking erratic directions. To bypass the problem, I enter a CALL LINK("VWRITE") including two VDP writings then I enter an other CALL LINK("VWRITE") just after the first one for other writings but without never exceed two writings. Using this method, the problem totally disappears. 

 

Edited by fabrice montupet
  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...
On 7/14/2022 at 9:56 PM, senior_falcon said:

I do not have this hardware, so I cannot test this, but my understanding was that this works. Is anyone else able to verify that this does/does not work?

Yes. It does not work on my TI either, FinalGrom99 and 32k expansion, everything else is stock.
I have renamed the files and still getting the blue screen.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...