senior_falcon Posted March 16, 2022 Author Share Posted March 16, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 17, 2022 Author Share Posted March 17, 2022 All fixed. Will post tomorrow. 4 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 20, 2022 Author Share Posted March 20, 2022 (edited) 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 July 6, 2022 by senior_falcon 3 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 20, 2022 Author Share Posted March 20, 2022 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. 4 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 20, 2022 Author Share Posted March 20, 2022 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? 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 20, 2022 Share Posted March 20, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 20, 2022 Author Share Posted March 20, 2022 Yes, this is done by GPL when LISTing a program. Interestingly, it is not done this way when PRINTing or DISPLAYing. There the byte has the offset added before printing to screen. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 21, 2022 Share Posted March 21, 2022 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 ************************************************************ Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 5, 2022 Author Share Posted July 5, 2022 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 4 Quote Link to comment Share on other sites More sharing options...
electricfling Posted July 10, 2022 Share Posted July 10, 2022 (edited) 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 July 10, 2022 by electricfling Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted July 10, 2022 Share Posted July 10, 2022 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. 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 11, 2022 Author Share Posted July 11, 2022 Make sure you are using the latest version. Earlier ones could have problems on a real TI99. 1 Quote Link to comment Share on other sites More sharing options...
electricfling Posted July 11, 2022 Share Posted July 11, 2022 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. Quote Link to comment Share on other sites More sharing options...
DavidC Posted July 11, 2022 Share Posted July 11, 2022 (edited) ..I was wrong, forget I posted..sorry. Edited July 11, 2022 by DavidC Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 14, 2022 Author Share Posted July 14, 2022 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? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 19, 2022 Author Share Posted July 19, 2022 (edited) 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 July 19, 2022 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted August 2, 2022 Author Share Posted August 2, 2022 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted August 2, 2022 Share Posted August 2, 2022 It sounds like a bad page select... what would I need to implement of FinalGROM in order to make using the Classic99 debugger possible? Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted August 2, 2022 Share Posted August 2, 2022 @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. Quote Link to comment Share on other sites More sharing options...
Reciprocating Bill Posted August 2, 2022 Share Posted August 2, 2022 Although the link above (#534) indicates version XB29GEM20220623, version XB29GEM20220317 is what downloads. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted August 2, 2022 Share Posted August 2, 2022 I sort of assumed that was just an old folder name... Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted August 3, 2022 Author Share Posted August 3, 2022 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted August 3, 2022 Share Posted August 3, 2022 (edited) 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 August 3, 2022 by Tursi 2 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted October 25, 2022 Share Posted October 25, 2022 (edited) 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 October 25, 2022 by fabrice montupet 2 Quote Link to comment Share on other sites More sharing options...
konbert Posted November 7, 2022 Share Posted November 7, 2022 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.