XB Game Developers Package

[1980gamer]

As always, you find the solution!

I need to STOP using call sound to slow execution.

1648 IF JY<>0 OR JX<>0 OR K=0 OR K=5 OR K=2 OR K=3 THEN CALL LINK("DELAY",100+DEL) 

 

I remember why I used sound, it was debugging when the line executed.  Then I simply lowered the volume.  But should have changed the command!

 

Edited September 16, 2023 by 1980gamer

[senior_falcon]

jschultzpedersen was having trouble creating a chained cartridge. The problem was caused by a bug in my code, but the strange thing is that when I was writing my code I found it and fixed it. The problem is that i fixed it with a hex editor (had to change 1 byte) and forgot to change the source code. So when I made another addition to the compiler that bug came back. Since it was already thoroughly tested, I did not test that any further and so did not find it.

That led to me finding another bug in something that has worked perfectly for 5 or 8 years.

 

When I looked at my code, I remembered that, besides chaining cartridges, I added the ability to RUN "DSKn.PROGRAM" just like in XB. I guess I was so excited about chaining cartridges that I forgot about this!

 

I hope to wrap this up in the next couple of days.

[senior_falcon]

Here is JUWEL6.

There were a couple of bug fixes to deal with problems that crept in as described in the above post.

 

My understanding is that a cart should be 32K, 64K, 128K, 256K, 512K etc. I changed the cartridge combining utility to add (if necessary) the last cartridge repeatedly so that now happens.

 

JUWEL6.zip

Edited October 9, 2023 by senior_falcon

[MikeV]

I could not believe that there were 60 fonts to select from! Nice work.

[jschultzpedersen]

Hi

 

With JUWEL6'a cool ability to store multiple cartridge images in one large cartridge and then start up each cartridge with the RUN command from another cartridge on the fly, the next question is... Can I maintain the value of variables between the cartridges, or will it do a complete reset of all memory each time?

It is possible to keep data by encoding the data as data for a character definition. If I then start another cartridge with the RUN command, and it is set up to not initialize VRAM, the old values remain and may be decoded and read into similar variables in the new cartridge, as long as I can agree with myself on how it is stored. This is fine for retaining flags and simple numeric values, but it is rather impractical for strings even if it can be done. But is there a way to maintain strings between cartridges? Perhaps an area of RAM, that is unaffected by the cartridge switch, and that may be accessed with peek and load?

The backup plan is to write the stuff to disk and reload it in the next cartridge. So it is not a big deal. I am just curious.

Edited October 19, 2023 by jschultzpedersen
spellig mistake

[RXB]

There is a device already that can do that  instead of VDP use the SAMS it is 1Meg or in Classic99 32Meg.

As long as you do not reset it by turning off the P-Box or power to the SAMS it will retain the data.

Same thing with Classic99 I think, at least I demoed this in Classic99 back  in 2014 that it works using RXB and Editor Assembler.

A demo also switched Cartridges from another GROM base and back again.

[senior_falcon]

6 hours ago, jschultzpedersen said:

Hi

 

With JUWEL6'a cool ability to store multiple cartridge images in one large cartridge and then start up each cartridge with the RUN command from another cartridge on the fly, the next question is... Can I maintain the value of variables between the cartridges, or will it do a complete reset of all memory each time?

It is possible to keep data by encoding the data as data for a character definition. If I then start another cartridge with the RUN command, and it is set up to not initialize VRAM, the old values remain and may be decoded and read into similar variables in the new cartridge, as long as I can agree with myself on how it is stored. This is fine for retaining flags and simple numeric values, but it is rather impractical for strings even if it can be done. But is there a way to maintain strings between cartridges? Perhaps an area of RAM, that is unaffected by the cartridge switch, and that may be accessed with peek and load?

The backup plan is to write the stuff to disk and reload it in the next cartridge. So it is not a big deal. I am just curious.

When a cartridge is loaded, all of the 32K ram is replaced with the new cartridge. So ram is not an option. However VDP ram is unchanged, so you can store values and strings there for retrieval later.

The easiest way to deal with strings is to use XB256, which has two subroutines, VREAD and VWRITE. From the manual:

CALL LINK(“VREAD”, memory address, # bytes, string[ , . . .])
VREAD reads the specified number of bytes from the VDP ram into a string variable of up to 255 bytes. Up to 5 strings can read with one call to VREAD.
CALL LINK (“VWRITE”,memory address, string[ , . . .])
VWRITE writes a string to the VDP ram starting at the specified memory address. Up to 8 strings can be written with one call to VWRITE.

 

One thing you need to deal with is that there is no length byte in the string. You will have to provide that. The program below shows one way to do this.

Line 20 adds the length byte to "HELLO WORLD" and then uses VWRITE to write the length byte and string to 12288 or >3000

Line 40 peeks the length byte and then uses VREAD to read the string into A$.

If lines 10-20 were in the first cartridge and 40-50 were in the second, then "HELLO WORLD" would be saved to vdp and read by the second cartridge.

10 A$="HELLO WORLD"
20 CALL LINK("VWRITE",12288,CHR$(LEN(A$))&A$)
30 A$=""
40 CALL PEEKV(12288,L):: CALL LINK("VREAD",12289,L,A$)
50 PRINT A$

 

In a compiled program or cartridge, all the vdp memory is available except for what is used for the graphics and screen data and the memory used for the disk system.

For XB256, >1820 to >37D7 is available (6176 to 14295)

For T40XB, >13C0 to >37D7 is available (5056 to 14295)

For T80XB, >1780 to >37D7 is available (6016 to 14295)

However, you will probably have trouble testing this from XB, because all the VDP memory can be used by the XB interpreter.

[jschultzpedersen]

Hi

 

Thanks for the detailed answer! VRAM it is then.

[senior_falcon]

On 10/19/2023 at 3:12 PM, jschultzpedersen said:

Can I maintain the value of variables between the cartridges, or will it do a complete reset of all memory each time?

I didn't say anything about storing numeric values. Like the strings, these too must be placed in vdp memory.

It is easy if the value is from 0 to 255. Just POKEV the value, then PEEKV the value when you want to retrieve it.

If the value is negative or greater than 255, then a few extra steps are needed. Remember that for compiled code, values must be from -32768 to +32767.

You must separate the most significant byte from the least significant byte

The XB program below shows how to do this. This works properly when compiled, but if you are running from XB then some more steps are needed.

 

100 INPUT N
120 LSB=N AND 255
130 MSB=(N-LSB))/256
140 CALL POKEV(10000,MSB,LSB)
150 REM **************
180 MSB=0 :: LSB=0
190 CALL PEEKV(10000,MSB,LSB)
200 X=MSB*256+LSB
202 PRINT X
210 GOTO 100

 

Here is this program compiled. You can input any value. A value that is less than -32768 or greater than 32767 will have 65536 will have 65536 added or subtracted until it is in the proper range. So 65537 becomes 1, etc.

 

NUMBRS-X

[jschultzpedersen]

Hi

 

Yes, I was going to store 16 bit numbers as character codes in a CHAR definition and extract numbers from that. The same goes for bit flags. Using the 8 bytes of a single character definitions would allow multiple values and flags. But using POKEV and PEEKV is obviously a simpler solution. So it looks as if the best way to exploit the multicart capability, is to define all CHAR definitions and other potentially useful stuff in VRAM, and then switch to another cartridge without resetting VRAM. This other cartridge would be the main cartridge, and other cartridges could, in turn, feed VRAM data representing a new level, or whatever, to it, by RUN'ning them from the main cartridge, and then RUN the main cartridge again from them - still without resetting VRAM.

[+hloberg]

is GEM finalgrom compatible? I can't seem to get the .bin versions posted here on in classic99 to work.

 

[senior_falcon]

50 minutes ago, hloberg said:

is GEM finalgrom compatible? I can't seem to get the .bin versions posted here on in classic99 to work.

In the README file is the following:

 

Final Grom
To use XB 2.9 G.E.M. with the Final Grom you need to rename the two files:
XB29GEM_G.BIN should be XB29GEMG.BIN
XB29GEM_8.BIN should be XB29GEMC.BIN

 

I understand this works, but I do not have a FinalGrom for testing.

[+hloberg]

1 hour ago, senior_falcon said:

In the README file is the following:

 

Final Grom
To use XB 2.9 G.E.M. with the Final Grom you need to rename the two files:
XB29GEM_G.BIN should be XB29GEMG.BIN
XB29GEM_8.BIN should be XB29GEMC.BIN

 

I understand this works, but I do not have a FinalGrom for testing.

did that and if u run anything u get a red block,underline,blue block at the cursor after it runs then lock up. did in all the GEM programs. probably something I'm doing or not doing.

no big deal, I been using the disk version anyway just thought I try it.

[senior_falcon]

I don't know what to say. Walid had some problems that he was able to solve. This is described in the Extended BASIC G.E.M. thread starting around March 22.

But it looks like you are doing everything right.

You say "if u run anything u get a red block, etc."

Does the menu screen come up properly? Can you select TI BASIC?

[+hloberg]

2 hours ago, senior_falcon said:

I don't know what to say. Walid had some problems that he was able to solve. This is described in the Extended BASIC G.E.M. thread starting around March 22.

But it looks like you are doing everything right.

You say "if u run anything u get a red block, etc."

Does the menu screen come up properly? Can you select TI BASIC?

I'LL check out those post.

...

oh and I forgot to mention I have a nanoPEB.

[+hloberg]

ok when I use your old stuff version 2.8 from this post:

works fine. but try using version 2.9 from any source I get those weird errors.

 

[senior_falcon]

Anyone have any insights about what is happening?

[JasonACT]

It works for me (X=2.91230611) on my Pi Pico GRAM/RAM device on real hardware.  I.E. A simple "Hello, World" print loop works fine.

[jschultzpedersen]

Hi

This works on actual TI99 hardware (TI99, PEB with 32K and RS232, Speech Synth.) for me. Version number is...  2.920230707. I have tested some simple programs and speech.

[senior_falcon]

Thank you for checking that out.

 

Turns out this problem has existed for a while. In the Extended BASIC G.E.M. thread, on page 22, on July 10,2022, electricfling posted this:

The current Extended Basic G.E.M is not executable on a real TI-99/4A with NANOPEB.
Either the TI emits a whistling sound and crashes or after selecting options 1-9 in the main menu only black blocks are displayed and the TI crashes as well.

I assume that the XB G.E.M. is similarly extensive as the XB 2.7 Suite. The latter version definitely does not run on the FINAL GROM 99 with the original TI-99/4A.

In the emulators the whole package works.
Maybe the XB G.E.M. - version is too big for the FINAL GROM 99.

Greetings
Gernot

 

This problem was not resolved at that time either. As I remember, G.E.M. 2.9 is up to 17 banks of memory, while 2.8 (which works with the nanopeb) was 16. Is there something about the nanopeb that interferes with loading so many pages into the rom? Since I do not have one, I do not have any way to test this to find out what could be happening.

I am guessing that some or all of the memory banks are either getting corrupted or are not loading. With GEM loaded, I think TI BASIC should be able to load and run program. If so, I could come up with a TI BASIC program to switch the memory banks and display what is in every bank of cartridge rom. That way we could check to see if the banks are what they should be.

Edited October 30, 2023 by senior_falcon

[+hloberg]

don't worry about it. My NanoPEB has started to act up anyway. I going to replace it soon with a TiPi; that is after I, replace the laptop that just broke, the desktop that's started to give me trouble and the car that just hit 275000 miles.

[senior_falcon]

On 10/30/2023 at 10:46 PM, hloberg said:

don't worry about it. My NanoPEB has started to act up anyway. I going to replace it soon with a TiPi; that is after I, replace the laptop that just broke, the desktop that's started to give me trouble and the car that just hit 275000 miles.

It looks like the NanoPEB is going the way of the rumble seat and the running board.
Still, I am curious about the compatibility issue with GEM. I suspect that some of the rom banks are being corrupted.

Below is a BASIC program that does a checksum by adding up the words in every bank bank and then printing  them on the screen.

First load XB 2.9 G.E.M. Then select 1 for BASIC, then OLD DSK1.CHECKSUMBX and RUN. Press quit to exit.

Can you run this in both Classic99 and with the nano peb and then post the results of both tests?

 

CHECKSUMBX

 

Edited November 3, 2023 by senior_falcon

[+hloberg]

23 minutes ago, senior_falcon said:

It looks like the NanoPEB is going the way of the rumble seat and the running board.
Still, I am curious about the compatibility issue with GEM. I suspect that some of the rom banks are being corrupted.

Below is a BASIC program that does a checksum by adding up the words in every bank bank and then printing  them on the screen.

First load XB 2.9 G.E.M. Then select 1 for BASIC, then OLD DSK1.CHECKSUMBX and RUN. Press quit to exit.

Can you run this in both Classic99 and with the nano peb and then post the results of both tests?

 

CHECKSUMBX 896 B · 0 downloads

 

i'll run it sometime this weekend and let u know the results.

[senior_falcon]

15 minutes ago, hloberg said:

i'll run it sometime this weekend and let u know the results.

Thanks! Needless to say, be sure to use the same version of XB 2.9 for both tests. Anyone else who is having problems running XB 2.9 with the nano peb is welcome to try this as well.

[senior_falcon]

The first program I posted was a hybrid of BASIC and assembly. This new one is all assembly. (It works the same, but is more satisfying to me.)

I included a short video so you can see what to expect.

 

CHECKSUMBX