XB Game Developers Package

[+hloberg]

FINALGROM > gem 2.8 + NanoPEB

1 5EE0

2 F5E7

3 A2E3

4 6F6E

5 07C8

6 2721

7 C3D7

8 2D10

9 693B

10 ECC1

11 DF36

12 0A9A

13 7E92

14 899C

15 CF4F

16 4D9F

17 C17E

18 C086

19 0000

20 0000

 

FINALGROM > gem 2.9 + NanoPEB

1 5EE0

2 F5E7

3 3777

4 CBA2

5 07C8

6 B3D9

7 47D7

8 2D10

9 693B

10 ECC1

11 8F68

12 74C6

13 6389

14 6AD5

15 E5AD

16 8642

17 D86D

18 C086

19 0000

20 0000

 

getting info out of the gem 2.9 was difficult as it kept locking up. hopefully correct.

 

 

[senior_falcon]

6 hours ago, hloberg said:

FINALGROM > gem 2.8 + NanoPEB

FINALGROM > gem 2.9 + NanoPEB

getting info out of the gem 2.9 was difficult as it kept locking up. hopefully correct.

You misunderstood. GEM 2.9 works with Classic99, but does not work with FinalGrom and the NanoPEB.

I would like to see the checksums for the same version of GEM 2.9 running both ways. It works one way but not the other, so let's see if we can find out why there is a difference.

You are running in TI BASIC, so you shouldn't have any lockup problems. Even though you are not using GEM, the roms are still there and can be accessed by my checksum program.

(Edit) While you are at it, it might be helpful if you did the same thing for GEM 2.8.

I have a feeling that banks above 16 are corrupted somehow, but why speculate when you can actually find out.

Edited November 6, 2023 by senior_falcon

[+hloberg]

2 hours ago, senior_falcon said:

You misunderstood. GEM 2.9 works with Classic99, but does not work with FinalGrom and the NanoPEB.

I would like to see the checksums for the same version of GEM 2.9 running both ways. It works one way but not the other, so let's see if we can find out why there is a difference.

You are running in TI BASIC, so you shouldn't have any lockup problems. Even though you are not using GEM, the roms are still there and can be accessed by my checksum program.

(Edit) While you are at it, it might be helpful if you did the same thing for GEM 2.8.

I have a feeling that banks above 16 are corrupted somehow, but why speculate when you can actually find out.

the values are the same for classic99 and what I posted for use with the NanoPEB.

classic99 + gem2.9

1 5EE0

2 F5E7

3 3777

4 CBA2

5 07C8

6 B3D9

7 47D7

8 2D10

9 693B

10 ECC1

11 8F68

12 74C6

13 6389

14 6AD5

15 E5AD

16 8642

17 D86D

18 C086

19 0000

20 0000

 

I know this probably throws u a curve ball on ur theories. As for me, my TiPi will be here tomorrow morning so the NanoPEB is going into cold storage before I leave for work in a couple hours. if u have any more test I'll see if I can do them today before I leave.

[senior_falcon]

I will add a grom checksum to the test just to be sure and will try to post that tonight. But if the groms are the same and the roms are the same, then it is a mystery to me why they would behave differently!

[senior_falcon]

12 hours ago, hloberg said:

I know this probably throws u a curve ball on ur theories. As for me, my TiPi will be here tomorrow morning so the NanoPEB is going into cold storage before I leave for work in a couple hours. if u have any more test I'll see if I can do them today before I leave.

Here is the same checksum program with the groms added. If you feel like it, can you try this with XB 2.9 running in Classic99 and with the nanoPEB and the final grom.

Based on what I am seeing so far, I would guess the checksums will be identical.

If so, this brings up the question of why the same exact code runs properly on Classic99, yet crashes with the nanoPEB and FinalGrom?

 

CHECKSUMBX

[+arcadeshopper]

10 hours ago, senior_falcon said:

Here is the same checksum program with the groms added. If you feel like it, can you try this with XB 2.9 running in Classic99 and with the nanoPEB and the final grom.

Based on what I am seeing so far, I would guess the checksums will be identical.

If so, this brings up the question of why the same exact code runs properly on Classic99, yet crashes with the nanoPEB and FinalGrom?

 

CHECKSUMBX 896 B · 1 download

I'd look at VDP ram corruption, nanopeb uses VDP ram for it's stuff and you may be overwriting something

[+hloberg]

23 hours ago, senior_falcon said:

Here is the same checksum program with the groms added. If you feel like it, can you try this with XB 2.9 running in Classic99 and with the nanoPEB and the final grom.

Based on what I am seeing so far, I would guess the checksums will be identical.

If so, this brings up the question of why the same exact code runs properly on Classic99, yet crashes with the nanoPEB and FinalGrom?

 

CHECKSUMBX 896 B · 2 downloads

I probably won't be able to get to this till after Thanksgiving. Anyone else want to help out?

[senior_falcon]

On 11/7/2023 at 9:59 AM, arcadeshopper said:

I'd look at VDP ram corruption, nanopeb uses VDP ram for it's stuff and you may be overwriting something

I suppose that might be a possibility. Does anyone know what areas of the VDP are used by the nanopeb?

[RickyDean]

30 minutes ago, senior_falcon said:

I suppose that might be a possibility. Does anyone know what areas of the VDP are used by the nanopeb?

I looked in the manual: https://web.archive.org/web/20220310014026/https://nanopeb.com/downloads/nanoPEB/docs/nanoPEB-SIO_V1.pdf

But don't see any programming or any VDP related info.

[RickyDean]

1 hour ago, senior_falcon said:

I suppose that might be a possibility. Does anyone know what areas of the VDP are used by the nanopeb?

There is some vdp access in this assembly code for the CF7 probably used in the Nano too.

cfmgr.txt

[+Lee Stewart]

6 hours ago, senior_falcon said:

I suppose that might be a possibility. Does anyone know what areas of the VDP are used by the nanopeb?

 

The nanoPEB uses the 8 bytes at the top of VRAM for its validation code and what volumes are associated with DSK1, DSK2, and DSK3, pushing the buffer space down by that much, such that CALL FILES(3) will put >37CF at >8370 as the highest available VRAM address instead of the TI DSR’s >37D7. Otherwise, I think the nanoPEB uses the VRAM buffer area in the same manner as the TI DSR. Fred ( @F.G. Kaal ) knows much more about this, I am sure.

 

...lee

[F.G. Kaal]

14 hours ago, Lee Stewart said:

 

The nanoPEB uses the 8 bytes at the top of VRAM for its validation code and what volumes are associated with DSK1, DSK2, and DSK3, pushing the buffer space down by that much, such that CALL FILES(3) will put >37CF at >8370 as the highest available VRAM address instead of the TI DSR’s >37D7. Otherwise, I think the nanoPEB uses the VRAM buffer area in the same manner as the TI DSR. Fred ( @F.G. Kaal ) knows much more about this, I am sure.

 

...lee

The bytes in VDP RAM are set as follows:

 

 * >3FF8 = >AA03
 * >3FFA = Vol# DSK1 (1-x)
 * >3FFC = Vol# DSK2 (1-x)
 * >3FFE = Vol# DSK3 (1-x)
 

and as far as I know the nanoPEB and CF7A+ sidecar are using the VRAM buffer area in the same manner as the TI DSR.

 

Edited November 9, 2023 by F.G. Kaal

[senior_falcon]

That's about what I figured. XB 2.9 G.E.M. does nothing to that area of the VDP.

One possibility is that Classic99 handles errors differently than a real TI. Perhaps there is an invalid opcode that Classic99 ignores that is causing these crashes.

That seems unlikely because most people report that GEM runs fine on a real TI.

Just to be sure, tonight I will set Classic99 to break on invalid opcode and see what happens.

[Asmusr]

It seems to work fine on my nanoPEB running from the FinalGROM. I was able to choose the different options from the module menu, and save XB 2.9 programs on the nanoPEB. I couldn't remember how to enter the 80 column mode.

Edited November 10, 2023 by Asmusr

[Tursi]

6 hours ago, senior_falcon said:

One possibility is that Classic99 handles errors differently than a real TI. Perhaps there is an invalid opcode that Classic99 ignores that is causing these crashes.

The real CPU ignores invalid opcodes too  6 cycles, no effect.

 

I haven't followed the whole thread, but if you're using the Nanopeb under Classic99 I consider that more of a curiosity than a feature. There's no documentation available so it is "appears to work" as a status... 

 

But definitely remember to check the Classic99 debug log ANY time you have a disk access that works in Classic99 and not on hardware. 9 times out of 10 it has warned you that is the case.

 

 

[Asmusr]

58 minutes ago, Asmusr said:

It seems to work fine on my nanoPEB running from the FinalGROM. I was able to choose the different options from the module menu, and save XB 2.9 programs on the nanoPEB. I couldn't remember how to enter the 80 column mode.

Got it to work in 80 column mode also (on real hardware, with a NanoPEB, FinalGROM and F18A). NanoPEBs and FinalGROMs can be a bit flaky IMO, so maybe that's why it doesn't always seems to work?

[senior_falcon]

2 hours ago, Asmusr said:

Got it to work in 80 column mode also (on real hardware, with a NanoPEB, FinalGROM and F18A). NanoPEBs and FinalGROMs can be a bit flaky IMO, so maybe that's why it doesn't always seems to work?

I did some quick tests for invalid opcodes, but none were found, and Tursi says that shouldn't matter anyway.

Since it seems to work for most people using real iron, and works for Rasmus using the NanoPEB and FinalGROM combination, I guess this will have to remain a mystery.

[senior_falcon]

AlexJ seems to have a real knack for finding errors in my code. Here are 2 anomalies that he found in the compiler, along with one request and its solution.

 

1 - If the compiled code uses CALL LINK then the name of the subroutine must be in the call link statement.

     i.e. 10 CALL LINK("CLS") but not 10 A$="CLS"::CALL LINK(A$)

     Here is the code that led to the discovery:

       35 FOR W=1 TO WN :: _PR$="PRINT" :: IF WC(W)=P THEN _PR$=_PR$&"I"
       40 CALL LINK(_PR$,WY(W)+1,WX(W)*2-1,SEG$(SN$,W,1),1):: NEXT W

    This code is clever in that it lets one CALL LINK do either PRINT or PRINTI. 

    Unfortunately the compiler balks at this and so you must make 2 lines, one with CALL LINK("PRINT",..) and one with CALL LINK("PRINTI",..)

 

2 - This is a really weird line of code that works in XB, but fails in the compiler.

      570 IF V=-10 THEN GOSUB 1420 :: ON FL+1 GOTO 500,730       here the sub at 1420 sets FL to 0 or 1, then the ON FL+1 sends it to the right program line

     It seems really strange to put ON GOTO or ON GOSUB in an IF/THEN/ELSE statement, but it does work in XB. The solution here is simple: IF FL=0 THEN 500 ELSE 730 or else put the ON GOTO in a separate line.

 

3 - He found an error in T40XB that will also be in T80XB:

      5010 CALL LINK("T40")

      5150 CALL LINK("PRINT",25,1,"",0)       this just scrolls the screen by printing a null string on line 25

      5170 RETURN

    This causes "RETURN WITHOUT GOSUB IN 5170"

    If you make the length a 1 then the problem goes away. CALL LINK("PRINT",25,1,"",1)

 

Rather than spend hours trying to fix the code, I will amend the docs to describe the errors and how to avoid them.

 

4 - Is there a way to set the random number seed and store it so you can reset it to give the same "random" numbers if you replay the game.

 The answer is "yes." Here is my revised paragraph in the manual that describes RANDOMIZE:

 

RANDOMIZE can be used, but has no effect; it is done automatically. The random number seed is the 2 bytes at >83C0  or -31808. The TI is constantly scrambling this value until the program starts up. You can CALL LOAD(-31808,N1,N2) to get the same random number sequence, or CALL PEEK(-31808,N1,N2) to store the seed so it can be restored later.

 

(-31808 is the random number seed for TI BASIC, compiled XB, XB2.9 G.E.M. and probably RXB. It is not the random number seed for normal XB)

 

[SteveB]

17 hours ago, senior_falcon said:

4 - Is there a way to set the random number seed and store it so you can reset it to give the same "random" numbers if you replay the game.

 The answer is "yes." Here is my revised paragraph in the manual that describes RANDOMIZE:

 

RANDOMIZE can be used, but has no effect; it is done automatically. The random number seed is the 2 bytes at >83C0  or -31808. The TI is constantly scrambling this value until the program starts up. You can CALL LOAD(-31808,N1,N2) to get the same random number sequence, or CALL PEEK(-31808,N1,N2) to store the seed so it can be restored later.

This is great! I always missed the RANDOMIZE X function in the compiler and had to build my own randam number generator in the past. It is a great trick to save lots of space to make things repeatable by storing just a seed and create the values for a level background or attack-pattern in a game.

[senior_falcon]

Although TI BASIC and XB 2.9 G.E.M. give the same results with the same random number seed, the random numbers created by the compiler are different. So if you intend to use this in a compiled program, you must use a compiled program to determine what seed gives the desired results. If you run this program in basic and compiled, you will see the results are different.

10 CALL LOAD(-31808,12,34)
20 FOR I=1 TO 20
30 PRINT INT(RND*99);
40 NEXT I

 

Here is something interesting. Run this program in E/A Basic or XB 2.9. It sets the random number seed, then peeks the value that RANDOMIZE actually loaded A seed from 100 to 199 will actually give the same seed, as the PEEK shows. Likewise 200 to 299, etc. The BASIC manual explains why, but it is still surprising to me. The seed can even be something like 1.234e+126

10 RANDOMIZE (I)
20 CALL PEEK(-31808,A,B)
30 PRINT I;A;B
40 I=I+1
50 GOTO 10

 

 

Edited February 26 by senior_falcon

[1980gamer]

On 2/24/2024 at 11:26 PM, senior_falcon said:

1 - If the compiled code uses CALL LINK then the name of the subroutine must be in the call link statement.

     i.e. 10 CALL LINK("CLS") but not 10 A$="CLS"::CALL LINK(A$)

     Here is the code that led to the discovery:

       35 FOR W=1 TO WN :: _PR$="PRINT" :: IF WC(W)=P THEN _PR$=_PR$&"I"
       40 CALL LINK(_PR$,WY(W)+1,WX(W)*2-1,SEG$(SN$,W,1),1):: NEXT W

    This code is clever in that it lets one CALL LINK do either PRINT or PRINTI. 

    Unfortunately the compiler balks at this and so you must make 2 lines, one with CALL LINK("PRINT",..) and one with CALL LINK("PRINTI",..)

LOL, I tried to do this a few years ago.

 

I also tried to compile an older game that works in Vanilla XB and old GEM.  I tried to compile using XB 2.9 and latest GEM and it fails.

That is, it will either lock during OBJ stage or if I use 2.9 and an older GEM, it compiles, but when I run it, it does not behave as expected.

 

This is minimal info. Sorry, I will try to get some time to document my findings in detail.   But it looks like an XB 2.9 issue mostly.

[senior_falcon]

14 hours ago, 1980gamer said:

I also tried to compile an older game that works in Vanilla XB and old GEM.  I tried to compile using XB 2.9 and latest GEM and it fails.

That is, it will either lock during OBJ stage or if I use 2.9 and an older GEM, it compiles, but when I run it, it does not behave as expected.

This is minimal info. Sorry, I will try to get some time to document my findings in detail.   But it looks like an XB 2.9 issue mostly.

Can you either post or PM me the game so I can try to track down the problem?

 

 

 

[1980gamer]

15 hours ago, senior_falcon said:

Can you either post or PM me the game so I can try to track down the problem?

 

 

 

Sending PM now.   Thanks!

 

[senior_falcon]

I tried to compile 1980gamer's program, and just as he described, the compiler crashed. Here is what I saw:

Since the compiler crashes while analyzing line 1170, there is something in that line that the compiler doesn't like. Let's take a look:

1170 IF YEL+BLU+RED=0 THEN 690 :: REM CLEARED

Nothing at all exotic in that line, except the double colon is immediately followed by a REM. Since that is the only thing at all unusual, let's take out the double colon and try again.

1170 IF YEL+BLU+RED=0 THEN 690 ! CLEARED

 

Using a text editor, I quickly found there were 3 lines with a double colon followed by a REM or a !

1170 IF YEL+BLU+RED=0 THEN 690 :: REM CLEARED
3598 IF MDL=32 AND MDL2=32 THEN 3594 :: ! mdr 3530
3960 MOV=MOV+1 :: REM MOV2=MOV2+1

Once the double colons are removed the program compiles, assembles, and runs properly.

 

(edit) the statement separator :: cannot be used at the end of a line, whether followed by a comment or not.

XB is happy to end a line with :: REM comment, but that cannot be compiled.

 

Any time the compiler crashes, you can see where it happened by watching the line numbers as they are analyzed.

 

Finding and fixing this would take way too much time, so I have updated the docs to describe this "feature" and how to avoid it.

I should be able to post the latest version soon.

 

 

 

Edited March 1 by senior_falcon

[Cheung]

14 hours ago, senior_falcon said:

I tried to compile 1980gamer's program, and just as he described, the compiler crashed. Here is what I saw:

Since the compiler crashes while analyzing line 1170, there is something in that line that the compiler doesn't like. Let's take a look:

1170 IF YEL+BLU+RED=0 THEN 690 :: REM CLEARED

Nothing at all exotic in that line, except the double colon is immediately followed by a REM. Since that is the only thing at all unusual, let's take out the double colon and try again.

1170 IF YEL+BLU+RED=0 THEN 690 ! CLEARED

 

Using a text editor, I quickly found there were 3 lines with a double colon followed by a REM or a !

1170 IF YEL+BLU+RED=0 THEN 690 :: REM CLEARED
3598 IF MDL=32 AND MDL2=32 THEN 3594 :: ! mdr 3530
3960 MOV=MOV+1 :: REM MOV2=MOV2+1

Once the double colons are removed the program compiles, assembles, and runs properly.

 

Any time the compiler crashes, you can see where it happened by watching the line numbers as they are analyzed.

 

Finding and fixing this would take way too much time, so I have updated the docs to describe this "feature" and how to avoid it.

I should be able to post the latest version soon.

 

 

 

I don't think it allows an empty line after the :: . I've had problems with inadvertently adding a :: at the end of a line and trying to compile.

If you want a comment at the end of a line, you'll probably want to use the exclamation point (!) instead of  :: REM

 

So something like this:

 

10 A=B+C   ! Simple summation of our variables

 

Edited March 1 by Cheung