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 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 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 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.