+Vorticon Posted March 22, 2023 Share Posted March 22, 2023 Renaming it did not do the trick unfortunately... I just got a corrupted FG main screen. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 23, 2023 Author Share Posted March 23, 2023 Which version of XB 2.9 are you using? Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 23, 2023 Share Posted March 23, 2023 49 minutes ago, senior_falcon said: Which version of XB 2.9 are you using? The last one you posted. XB29GEM20220623 (1).zip Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 23, 2023 Author Share Posted March 23, 2023 I checked, and this version resets >83D5 the way it is supposed to. One other possibility is that the bank switched memory is initiating in an indeterminate state. I think this came up and was addressed, but I will check that. 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 24, 2023 Author Share Posted March 24, 2023 Just to check all the possibilities I can think of: To switch to the second bank of memory, should the GPL instruction be CLR @>6002 DCLR @>6002 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted March 24, 2023 Share Posted March 24, 2023 I'm guessing DCLR, as that should be equivalent to assembly CLR. Even if done in separate steps, should be redundant. Sounds like something that would best be determined through testing. Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 24, 2023 Share Posted March 24, 2023 (edited) Both byte and word accesses do 16-bit accesses to the cartridge port, and since it's the write access (and not the contents of it) that does the bank switch, they are equivalent. You can watch the bank change in the Classic99 debugger if that helps. GPL does DCLR as two separate MOVB instructions, so CLR is going to be a bit faster. GPL CLR: 013E 0702 SETO 2 First >FFFF, then invert GPL INV: 0140 0542 INV 2 Data INV 0142 1075 JMP >022E Execute 022E 020B LI 11,>0070 Trick return GPL interpreter 0230 0070 0232 D104 MOVB 4,4 VPD address?- 17 - 0234 130F JEQ >0254 0254 D145 MOVB 5,5 Word? 0256 1301 JEQ >025A 0258 DCC2 MOVB 2,*3+ Write data 025A 06C2 SWPB 2 025C DCC2 MOVB 2,*3+ 025E 0283 CI 3,>837E Was address screen buffer? 0260 837E 0262 16F7 JNE >0252 No, end 0252 045B B *11 To GPL interpreter Edited March 24, 2023 by Tursi 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 24, 2023 Share Posted March 24, 2023 10 hours ago, senior_falcon said: One other possibility is that the bank switched memory is initiating in an indeterminate state. This should certainly be assumed if you're on hardware. The latches we normally use do not have resets, and even if they did, FCTN-= is a software reset that doesn't reset any hardware, so unless software is really careful about when it's allowed or handles it manually, you can't predict what bank you'll be left in. (And that ignores the possibility of a hardware reset button on the console.) A GPL startup routine is the easiest way to force a startup bank if you have GROM available. Otherwise, same header in all banks with the first instruction being a bank change works well. 1 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 24, 2023 Share Posted March 24, 2023 On 3/22/2023 at 2:37 PM, senior_falcon said: In Classic99 ithe bytes are always set to zero at startup. Last one, then I'll go away. You can use File->Debug Reset to reboot with all RAM set to random values to check for such bugs. Though I guess in this case you wanted it to be uninitialized so that wouldn't have helped. If you can use two bytes, though, you can use one to validate the other - just invert it or duplicate it so you can tell if it is (probably) meant to be like that. 2 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 24, 2023 Share Posted March 24, 2023 I figured out what the issue was: the distribution has the XB29GEM_C file named XB29GEM_8 for some reason, and that was confusing the FG99. Once I renamed the latter then everything worked fine. 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 24, 2023 Share Posted March 24, 2023 1 hour ago, Vorticon said: I figured out what the issue was: the distribution has the XB29GEM_C file named XB29GEM_8 for some reason, and that was confusing the FG99. Once I renamed the latter then everything worked fine. If it's more than 8k, then C is the wrong suffix. C means an 8k ROM at >6000. 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 24, 2023 Share Posted March 24, 2023 2 hours ago, Tursi said: If it's more than 8k, then C is the wrong suffix. C means an 8k ROM at >6000. Then it might be an issue with the FG99... As long as it works it does not really matter I suppose. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 25, 2023 Author Share Posted March 25, 2023 On 3/24/2023 at 12:13 AM, Tursi said: Both byte and word accesses do 16-bit accesses to the cartridge port... Thanks! I knew that and if I had thought a little harder then I wouldn't have had to ask. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 25, 2023 Author Share Posted March 25, 2023 18 hours ago, Vorticon said: I figured out what the issue was: the distribution has the XB29GEM_C file named XB29GEM_8 for some reason, and that was confusing the FG99. Once I renamed the latter then everything worked fine. I would like to add this to the docs. Are the file names that work on the final grom XB29GEM_C and XB29GEM_G ? For sure the suffix _8 works for Classic99. 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 25, 2023 Share Posted March 25, 2023 Yes, the C and G extensions work with FG99, but best to leave the underscore out of the filename as well. And that naming convention also works fine with Classic99, so you might as well just use it in a future release to avoid the issues I had. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 25, 2023 Share Posted March 25, 2023 (edited) 16 hours ago, senior_falcon said: I would like to add this to the docs. Are the file names that work on the final grom XB29GEM_C and XB29GEM_G ? For sure the suffix _8 works for Classic99. You have to use 8 for Classic99, C will not load more than 8k of the ROM and will turn off bank switching. I'm not changing Classic99 again for this case. I already had to change it to make assumptions in the event of no tag at all. Metadata is important. It lets you avoid guessing. If we add guessing to metadata then we have defeated the purpose. People will just have to remember for the FG99. Looks like I already put that workaround in place for Classic99. I'll be honest, the discarding of metadata is one of the things that made me lose interest in working on emulation. Edited March 25, 2023 by Tursi 3 Quote Link to comment Share on other sites More sharing options...
Count9929A Posted March 28, 2023 Share Posted March 28, 2023 On 3/23/2023 at 6:58 PM, senior_falcon said: I checked, and this version resets >83D5 the way it is supposed to. One other possibility is that the bank switched memory is initiating in an indeterminate state. I think this came up and was addressed, but I will check that. Oh Thanks!!! I was about to post an help request here, because I was unable to run XB2.9 on real TI+FG99. Carefully reading solved all my problems! 🙂 I can confirm the filename issue, however please notice that the Docs already provide the correct names! In particular the file "1README.PDF", at the bottom, explicitly says that for FG99 you have to rename the files as indicated by Vorticon Indeed, my problems were due to the other problem you mentioned! I was experiencing that when starting XB29, after half-second delay, the screen got garbled. The strangeness was that XB29 was still running, only the display was not working. I could blindly type commands like LOAD, NEW, BYE and see that they were executed. Using the "20220623" version solved the issue. Please notice that I was previously using the version that I found in the JUWEL4+GEM package, which seems to contain an older version of XB2.9 that is *not* fixed for this issue (see 2 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted March 29, 2023 Share Posted March 29, 2023 (edited) I would like to talk again about a problem mentioned before and on which there was no answer. On 10/25/2022 at 10:21 PM, fabrice montupet said: 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. 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. Edited March 29, 2023 by fabrice montupet 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 29, 2023 Share Posted March 29, 2023 You did not try in MAME, did you? 1 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted March 29, 2023 Share Posted March 29, 2023 (edited) Yes, actually I have not tested with Mame. In fact, it is not installed on my computers because I don't use it (it's really a good emulator, a great job but it doesn't corresponds to my needs, I'm sincerely sorry). As the problem is present on Classic99, ti994w (and also on js99'er), I ended to conclude that the problem was with XB256. To precise: I use ti994w for all my developments. Classic99 comes in one step: the compilation and I use occasionally Js99er for debugging and dump operations: Precious helps! Edited March 29, 2023 by fabrice montupet 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 29, 2023 Share Posted March 29, 2023 I don't want you to switch to MAME, just to check whether this problem also occurs there. 🙂 I may try when I find some time. Quote Link to comment Share on other sites More sharing options...
RXB Posted March 29, 2023 Share Posted March 29, 2023 On 3/23/2023 at 8:03 PM, senior_falcon said: Just to check all the possibilities I can think of: To switch to the second bank of memory, should the GPL instruction be CLR @>6002 DCLR @>6002 RXB I just use CLR @>6002 as there is no need to do a word instruction. DCLR is just wasting a byte for no good reason, now in Assembly it is all WORD instructions as Assembly is WORD based, unlike GPL that is Byte based. Quote Link to comment Share on other sites More sharing options...
RXB Posted March 29, 2023 Share Posted March 29, 2023 On 3/23/2023 at 8:17 PM, HOME AUTOMATION said: I'm guessing DCLR, as that should be equivalent to assembly CLR. Even if done in separate steps, should be redundant. Sounds like something that would best be determined through testing. Tested and CLR @>6002 works fine in RXB for FinalGROM. Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 29, 2023 Share Posted March 29, 2023 3 hours ago, 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. I can't help too much.. XB and GPL programs are very tricky to debug and I have minimal expertise in them. But... the /symptoms/ make me wonder whether VDP interrupts are being enabled after the first string? That would certainly cause the weirdness you see. Is the corruption in a predictable location? If you can identify one VDP address which is /reliably/ corrupted, you can set a write breakpoint in Classic99 to stop execution when that address is written to. The first stop should be your deliberate data, the second stop then should be the unexpected corruption. Investigating the state of the machine at that point should provide a lot of insight. 3 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted March 30, 2023 Share Posted March 30, 2023 Thank you for your answer, I'm not sure that the problem comes from emulators. The problem happens totally random. On a same level (the program is a game), all can work perfectly during numerous minutes or hours, then graphic corruptions can suddenly appear. I stop the program, re-run it and all is OK again...for a time. 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.