RXB Posted March 30, 2023 Share Posted March 30, 2023 Only time I have had issues with EMULATORS is Windows stupid file permissions suddenly without any warning decides to make a file write protected. Does not happen in Linux or Unix or other OS but just Windows that is such a mess they have never fixed this problem. And believe me they know it ticks off everyone every time there is a update or virus update. But Microsoft does not care and has shown it does not care what the customer thinks or how it hurts the consumer. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 9, 2023 Author Share Posted April 9, 2023 (edited) On 3/29/2023 at 3:41 PM, fabrice montupet said: I would like to talk again about a problem mentioned before and on which there was no answer. I had many display problems passing several addresses/string patterns using only one CALL LINK ("VWRITE") routine so, I changed my way of use: During more than 4 months, I ran my XB256 program successfully with no problem using this other method: CALL LINK("VWRITE", memory address1, string1) :: CALL LINK("VWRITE", memory address2, string2) :: CALL LINK("VWRITE", memory address3, string3) :: CALL LINK("VWRITE", memory address4, string4) Today, to earn some memory, I retried the previous method, using this: CALL LINK("VWRITE", memory address1, string1,memory address2, string2,memory address3, string3,memory address4, string4) ...And I quickly had graphic problems again (erratic oblique moving of sprites and garbage in several char patterns). This this very frustrating. Does this happen all the time? i.e. Have you ever been able to write multiple strings using VWRITE? (edit) I tried this and it seems to work fine. 10 FOR I=640 TO 0 STEP -128 20 CALL LINK("VREAD",I,32,A$,I+32,32,B$,I+64,32,C$,I+96,32,D$):: CALL LINK("VWRITE",I+32,A$,I+64,B$,I+96,C$,I+128,D$) 30 NEXT I Edited April 9, 2023 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted April 9, 2023 Share Posted April 9, 2023 It's systematic. Each time I integrate more than two different addresses in the "WRITE" routine, the screen ends up being damaged after a few moments. Maybe your test is not done in the same context as mine. My program consumes more memory (about 1.6Kb remains for stack and 1,8Kb for program when running) and there are many graphics operations between the variable settings and their use in the WRITE routine. Quote Link to comment Share on other sites More sharing options...
Retrospect Posted April 9, 2023 Share Posted April 9, 2023 If one piece of code works fine for @senior_falcon and then doesn't work fine for @fabrice montupet then I would want to ask; Which TI emulator are you using, and which version number? Are you up to date? Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted April 9, 2023 Share Posted April 9, 2023 (edited) For testing, I used Classic99 and ti994w (as I said in my previous messages). And of course I use the latest version of them. Got the same result. Edited April 9, 2023 by fabrice montupet typo error Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted April 9, 2023 Share Posted April 9, 2023 (edited) A precision: There is a difference between the two codes, mine uses array variables. Like this: CALL LINK("VWRITE",1408,F$(16+R2)&F$(32+R2)) :: CALL LINK("VWRITE",1104,F$(20+R2),1016,F$(24+R2)) --> That works fine CALL LINK("VWRITE",1408,F$(16+R2)&F$(32+R2),1104,F$(20+R2),1016,F$(24+R2)) --> Ends to make some garbage on the screen after some time. Edited April 9, 2023 by fabrice montupet Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 10, 2023 Author Share Posted April 10, 2023 (edited) 3 hours ago, fabrice montupet said: Ends to make some garbage on the screen after some time. It sounds like it takes a while for the garbage to appear on the screen. Does this happen in seconds, minutes, or longer than that? Any chance of a screen shot of the garbage? Two more questions: Is this happening in XB or is it in the compiled code? Does it happen every time or is it intermittent? Edited April 10, 2023 by senior_falcon Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted April 10, 2023 Share Posted April 10, 2023 It happen's both in XB256 and compiled, after a moment that can be one minute or more, but sometimes I can use the program during 15mn without any problem (I don't play during a long time because the game is in development) I think remembering that one time it appeared under the minute. I"ll take a screenshot. Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted April 10, 2023 Share Posted April 10, 2023 Continuing to investigate ... 🙂 As the game is very big, I have isolated a part of it that contains VWRITE routines and I ensured that this little part runs in loops to force the problem appears. In this part of the program, I made some modification in the way to call the VWRITE routine and I have found an interesting thing: Step1 : If the line containing the routine is written like this: CALL LINK("VWRITE",1104,F$(19+R1),1408,F$(15+R1)&F$(31+R1)) , I quickly get garbage on some characters in the screen. Step 2: If the line containing the routine is written like this: CALL LINK("VWRITE",1104,F$(19+R1)) :: CALL LINK("VWRITE",1408,F$(15+R1)&F$(31+R1)) No problem appears, even after very long minutes running. But no surprise for me because it is the way that I have found to correct the problem. Step 3: I tried something else:CALL LINK("VWRITE",1408,F$(15+R1)&F$(31+R1),1104,F$(19+R1)) I was surprised to see that no garbage appeared too, even after very long minutes running. As the program worked fine, I stopped it and modified the line as in the step 1: the problem immediately re-appeared. Then I stopped the program, modified the line as in the step 3 and all worked fine again. So, it seems that the appeal address order play a role in the problem manifestation. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 10, 2023 Author Share Posted April 10, 2023 Are you in Screen1 or Screen2? Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted April 10, 2023 Share Posted April 10, 2023 In this program I only use SCREEN1. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 11, 2023 Author Share Posted April 11, 2023 It is hard to know what is going on without actually seeing it. Since VWRITE seems to work at first and the screen problems only develop later, and since strings are involved, I get the feeling that it has something to do with garbage collection. XB256 uses an interrupt routine to keep the stack from using addresses below >1820. Using CPU overdrive, I have seen times when that does now work which leads to screen2 being corrupted. As an experiment, use the Classic99 debugger to look at address >831A. As strings are used by your program, that value will get lower and lower until it reaches around >1820, then a garbage collection happens to clear the unused strings, then the value is reset to the highest possible value. Monitor this value while the program runs and see if it goes any lower than >1800. You can use F1 to halt the program, then F1 again to resume. 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted April 11, 2023 Share Posted April 11, 2023 >831A is a temporary value pointer that gets used by other routines. >8340 is the VDP free space pointer address >836E is the value stack pointer address >8370 is the highest available VDP address These locations and values are from the XB GPL source code and ROM Assembly Source code. Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted April 11, 2023 Share Posted April 11, 2023 16 hours ago, senior_falcon said: As an experiment, use the Classic99 debugger to look at address >831A. I'll do that to understand the problem. That said, my alternative solution by changing the order of the addresses written completely suites me 🙂 Quote Link to comment Share on other sites More sharing options...
RXB Posted April 11, 2023 Share Posted April 11, 2023 This might help you as this is the address used by XB from the GPL Source of XB: <0091> 8300 VAR0 EQU >8300 TEMPORARY <0092> 8301 VARV EQU >8301 TEMPORARY <0093> 8302 ACCUM EQU >8302 # OF BYTES ACCUMULATOR (4 BYTE <0094> 8302 STPT EQU >8302 TWO BYTES <0095> 8304 VARY EQU >8304 <0096> 8306 VARY2 EQU >8306 <0097> 8304 PABPTR EQU >8304 <0098> 8306 DFLTLM EQU >8306 Default array limit (10) <0099> 8306 CCPPTR EQU >8306 OFFSET WITHIN RECORED (1) <0100> 8307 RECLEN EQU >8307 LENGTH OF CURRENT RECORD (1) <0101> 8308 CCPADR EQU >8308 RAM address of current refs <0102> 8308 VARC EQU >8308 <0103> 8308 CCPADD EQU >8308 RAM address of current color <0104> 830A CALIST EQU >830A Call list for resolving refs <0105> 830A RAMPTR EQU >830A Pointer for crunching <0106> 830C BYTES EQU >830C BYTE COUNTER <0107> 830C NMPTR EQU >830C Pointer save for pscan <0108> 830E CHSAV EQU >830E <0109> 830E CURINC EQU >830E Increment for auto-num mode <0110> 8310 TOPSTK EQU >8310 Top of data stack pointer <0111> 8312 LINUM EQU >8312 Used to determine end of scan <0112> 8314 NMLEN EQU >8314 Current line for auto-num <0113> 8314 CURLIN EQU >8314 Current line for auto-num <0114> 8316 VAR9 EQU >8316 <0115> 8316 XFLAG EQU >8316 SCAN FLAG-BITS USED AS BELOW <0116> 8317 DSRFLG EQU >8317 INTERNAL =60, EXTERNAL =0 (1) <0117> 8317 FORNET EQU >8317 Nesting level of for/next <0118> <0119> 8302 AAA1 EQU >8302 <0120> 830C BBB1 EQU >830C <0121> 8308 CCC1 EQU >8308 <0122> *********************************************************** <0123> * Permanent workspace variables <0124> 8318 STRSP EQU >8318 String space begining <0125> 831A STREND EQU >831A String space ending <0126> 831C SREF EQU >831C Temporary string pointer 99/4 GPL-ASSEMBLER (Pass 3) correct PAGE 0003 EQUATES EDIT-359 <0127> 831E SMTSRT EQU >831E Start of current statement <0128> 8320 VARW EQU >8320 Screen address <0129> 8322 ERRCOD EQU >8322 Return error code from ALC <0130> 8324 STVSPT EQU >8324 Value-stack base <0131> 832A VARA EQU >832A Ending display location <0132> 832C PGMPTR EQU >832C Program text pointer <0133> 832E EXTRAM EQU >832E Line number table pointer <0134> 8330 STLN EQU >8330 Start of line number table <0135> 8332 ENLN EQU >8332 End of line number table <0136> 8334 DATA EQU >8334 Data pointer for READ <0137> 8336 LNBUF EQU >8336 Line table pointer for READ <0138> 8338 INTRIN EQU >8338 Add of intrinsic poly constant <0139> 833A SUBTAB EQU >833A Subprogram symbol table <0140> 833C IOSTRT EQU >833C PAB list/Start of I/O chain <0141> 833E SYMTAB EQU >833E Symbol table pointer <0142> 8340 FREPTR EQU >8340 Free space pointer <0143> 8342 CHAT EQU >8342 Current charater/token <0144> 8343 BASE EQU >8343 OPTION BASE value <0145> 8344 PRGFLG EQU >8344 Program/imperative flag <0146> 8345 FLAG EQU >8345 General 8-bit flag <0147> 8346 BUFLEV EQU >8346 Crunch-buffer destruction leve <0148> 8348 LSUBP EQU >8348 Last subprogram block on stack <0149> * FAC EQU >834A Floating-point ACcurmulator <0150> 834B FAC1 EQU FAC+1 <0151> 834C FAC2 EQU FAC+2 <0152> 834D FAC3 EQU FAC+3 <0153> 834E FAC4 EQU FAC+4 <0154> 834F FAC5 EQU FAC+5 <0155> 8350 FAC6 EQU FAC+6 <0156> 8351 FAC7 EQU FAC+7 <0157> 8352 FAC8 EQU FAC+8 <0158> 8353 FAC9 EQU FAC+9 <0159> 8354 FAC10 EQU FAC+10 <0160> 8356 FAC12 EQU FAC+12 <0161> 8357 FAC13 EQU FAC+13 <0162> 8358 FAC14 EQU FAC+14 <0163> 8359 FAC15 EQU FAC+15 <0164> 835A FAC16 EQU FAC+16 <0165> 835B FAC17 EQU FAC+17 <0166> 834C AAA EQU FAC+2 <0167> 834E CCC EQU FAC+4 <0168> 8350 BBB EQU FAC+6 <0169> 834C DDD EQU FAC+2 <0170> 834E FFF EQU FAC+4 <0171> 8350 EEE EQU FAC+6 <0172> 8354 DDD1 EQU FAC+10 <0173> 8356 FFF1 EQU FAC+12 <0174> 8358 EEE1 EQU FAC+14 <0175> * ARG EQU >835C Floating-point ARGument <0176> 835D ARG1 EQU ARG+1 <0177> 835E ARG2 EQU ARG+2 <0178> 835F ARG3 EQU ARG+3 <0179> 8360 ARG4 EQU ARG+4 <0180> 8361 ARG5 EQU ARG+5 <0181> 8362 ARG6 EQU ARG+6 <0182> 8363 ARG7 EQU ARG+7 <0183> 8364 ARG8 EQU ARG+8 <0184> 8364 XSTLN EQU >8364 GKXB variable <0185> 8366 XENLN EQU >8366 GKXB variable <0186> 8367 ARG11 EQU ARG+11 <0187> 8368 XCURLI EQU >8368 GKXB variable <0188> 836A XCURIN EQU >836A GKXB variable <0189> 836B ARG15 EQU ARG+15 <0190> 836C ARG16 EQU ARG+16 99/4 GPL-ASSEMBLER (Pass 3) correct PAGE 0004 EQUATES EDIT-359 <0191> * VSPTR EQU >836E Value stack pointer <0192> 8376 EXPZ EQU >8376 Exponent in floating-point <0193> 8384 RAMTOP EQU >8384 Highest address in ERAM <0194> 8386 RAMFRE EQU >8386 Free pointer in the ERAM <0195> 8388 RSTK EQU >8388 Subroutine stack base <0196> 8389 RAMFLG EQU >8389 ERAM flag <0197> 83AF STKMIN EQU >83AF Base of data stack <0198> 83BD STKMAX EQU >83BD Top of data stack <0199> 83CE PRTNFN EQU >83CE <0200> *********************************************************** <0201> * VDP addresses <0202> 02E2 NLNADD EQU >02E2 New LiNe ADDress <0203> 02FE ENDSCR EQU >02FE END of SCReen address <0204> 0371 LODFLG EQU >0371 Auto-boot needed flag <0205> 0372 START EQU >0372 Line to start execution at <0206> 0376 SYMBOL EQU >0376 Saved symbol table pointer <0207> 0382 SPGMPT EQU >0382 Saved PGMPTR for continue <0208> 0384 SBUFLV EQU >0384 Saved BUFLEV for contiue <0209> 0386 SEXTRM EQU >0386 Saved EXTRAM for continue <0210> * SAVEVP EQU >0388 Saved VSPRT for continue <0211> * ERRLN EQU >038A On-error line pointer <0212> 038C BUFSRT EQU >038C Edit recall start addr (VARW) <0213> 038E BUFEND EQU >038E Edit recall end addr (VARA) <0214> 0392 TABSAV EQU >0392 Saved main symbol table ponte <0215> 0396 SLSUBP EQU >0396 Saved LSUBP for continue <0216> 0398 SFLAG EQU >0398 Saved on-warning/break bits <0217> 039A SSTEMP EQU >039A To save subprogram program ta <0218> 039C SSTMP2 EQU >039C Same as above. Used in SUBPRO <0219> 039E MRGPAB EQU >039E MERGEd temporary for pab ptr <0220> *---------------------------------------------------------- <0221> * Added 6/8/81 for NOPSCAN feature <0222> 03B7 PSCFG EQU >03B7 <0223> *---------------------------------------------------------- <0224> * Flag 0: 99/4 console, 5/29/81 <0225> * 1: 99/4A console <0226> 03BB CONFLG EQU >03BB <0227> *---------------------------------------------------------- <0228> * Temporary <0229> 0374 NOTONE EQU >0374 NO-TONE for SIZE in ACCEPT us <0230> * in FLMGRS (4 bytes used) <0231> 0388 SAVEVP EQU >0388 <0232> 038A ERRLN EQU >038A <0233> 03AC ACCVRW EQU >03AC Temoporary used in ERRZZ, als <0234> * used in FLMGRS <0235> 03B0 VALIDP EQU >03B0 Use as two values passing fro <0236> 03B2 VALIDL EQU >03B2 VALIDATE code to READL1 <0237> 03BC OLDTOP EQU >03BC Temporary used in ERRZZ, also <0238> <0239> 0820 CRNBUF EQU >0820 CRuNch BUFfer address <0240> 08BE CRNEND EQU >08BE CRuNch buffer END <0241> 08C0 RECBUF EQU >08C0 Edit RECall BUFfer <0242> 0958 VRAMVS EQU >0958 Default base of value stack <0243> 0390 CNSTMP EQU >0390 Use as temporary stored place Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 12, 2023 Author Share Posted April 12, 2023 8 hours ago, fabrice montupet said: I'll do that to understand the problem. That said, my alternative solution by changing the order of the addresses written completely suites me 🙂 Your alternative solution is not a good way to fix this. This problem needs to be fixed properly and since I cannot make it happen, I do not know what to do to fix it. The easiest way for everyone would be to send me the program that does not work properly with an explanation of how I can make it fail. Then I could study it and (hopefully) figure out what is happening. 5 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted April 12, 2023 Share Posted April 12, 2023 Of course, I well know that my alternative solution isn't the best one, it just permitted me to go forward in my development and may help some others that will encounter the same issue, in a waiting of a definitive solution. I will extract a part of my code with the VWRITE routines in use and that cause some trouble for being studied. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 17, 2023 Author Share Posted April 17, 2023 Still waiting for you to send the program that does not work properly... Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 17, 2023 Author Share Posted April 17, 2023 On 4/12/2023 at 2:09 PM, fabrice montupet said: Of course, I well know that my alternative solution isn't the best one, it just permitted me to go forward in my development and may help some others that will encounter the same issue, in a waiting of a definitive solution. I will extract a part of my code with the VWRITE routines in use and that cause some trouble for being studied. Still waiting for you to send a program that does not work properly... 1 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted April 23, 2023 Share Posted April 23, 2023 I haven't forgotten you. I am sorry for the delay but I have first to resolve a problem in my game before giving its code. Thank you for the interest about my question. 2 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted May 20, 2023 Share Posted May 20, 2023 I have found a problem in my XB256 compiled program, it concerns CALL PEEK. If I write: CALL PEEK(W,P) :: CALL PEEK (W+64, Q) , when compiled the program gives the good values to P and Q. But if I write: CALL PEEK(W,P,"",W+64, Q) , the compiled program gives good values to P but not to Q, so I wonder if the empty string "" between two variables and permitting to read values starting at more than one address works with the compiler. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted May 21, 2023 Share Posted May 21, 2023 8 hours ago, fabrice montupet said: I have found a problem in my XB256 compiled program, it concerns CALL PEEK. If I write: CALL PEEK(W,P) :: CALL PEEK (W+64, Q) , when compiled the program gives the good values to P and Q. But if I write: CALL PEEK(W,P,"",W+64, Q) , the compiled program gives good values to P but not to Q, so I wonder if the empty string "" between two variables and permitting to read values starting at more than one address works with the compiler. It looks like you expect CALL PEEK to work like CALL LOAD—it doesn’t. CALL PEEK only takes one address as its first argument. It can take multiple variables after the address to get a string of bytes that start at that address. ...lee Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted May 21, 2023 Share Posted May 21, 2023 3 hours ago, Lee Stewart said: It looks like you expect CALL PEEK to work like CALL LOAD—it doesn’t. CALL PEEK only takes one address as its first argument. It can take multiple variables after the address to get a string of bytes that start at that address. ...lee Thank you for your help. In fact, I have read the Editor/Assembler manual, page 281, and seen this: "The PEEK subprogram reads bytes from CPU RAM and, starting at the address, assigns those values to the numeric variables in the variable-list. You can read values starting at more than one address by separating the last value in the variable-list from the next address with an empty string ""). For example, the statement CALL PEEK(8192,A,B,C(8),"",-24576,X) places the value from address 8192 (>2000) in A, the value from address 8193 (>2001) in B, the value from address 8194 (>2002) in C(8), and the value from address -24576 (>AOOO) in X." So, Have I missed or misunderstood something? Quote Link to comment Share on other sites More sharing options...
+mizapf Posted May 21, 2023 Share Posted May 21, 2023 Easy to clarify: The PEEK subprogram from Editor/Assembler supports it, the one from Extended Basic does not. Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted May 21, 2023 Share Posted May 21, 2023 (edited) Thank you Michael. So the problem is EXB. I should have verify in EXB. In fact, I never use it anymore since I discovered the excellent XB256 .I wonder what things had in EXB TI developers minds... May be some missing memory space in EXB ROM to do the same as in E/A. In any case, making the same subprogram with different function/behavior is really frustrating. But i will find another way to speed up my program 🙂 Edited May 21, 2023 by fabrice montupet 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.