Extended BASIC G.E.M.

[+Vorticon]

Renaming it did not do the trick unfortunately... I just got a corrupted FG main screen.

[senior_falcon]

Which version of XB 2.9 are you using?

[+Vorticon]

49 minutes ago, senior_falcon said:

Which version of XB 2.9 are you using?

The last one you posted.

XB29GEM20220623 (1).zip

[senior_falcon]

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.

[senior_falcon]

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

[HOME AUTOMATION]

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. 

[Tursi]

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

[Tursi]

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.

[Tursi]

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.

 

[+Vorticon]

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.

[Tursi]

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.

 

[+Vorticon]

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.

[senior_falcon]

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.

[senior_falcon]

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.

[+Vorticon]

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.

[Tursi]

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

[Count9929A]

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

 

 

[fabrice montupet]

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

[+mizapf]

You did not try in MAME, did you?

[fabrice montupet]

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

[+mizapf]

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.

[RXB]

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.

[RXB]

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.

[Tursi]

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.

 

[fabrice montupet]

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.