XB Game Developers Package

[senior_falcon]

20 minutes ago, pixelpedant said:

Ah, indeed, it looks like this data is just structured in a way that isn't compatible with a compiled program, and should be restructured for use with LINPUT.

 

With integers and strings in separate records. 

 

I think the structure is fine. I think if you make this change it will work.

60 INPUT #1:CNUM::LINPUT #1:CPAT$

[Asmusr]

59 minutes ago, senior_falcon said:

Saving as a cartridge requires XB2.9 G.E.M. and Classic99 version QI399.055 or later.

Great feature. Is it only the ?X that makes it dependent on Classic 99?

[senior_falcon]

1 hour ago, Asmusr said:

Great feature. Is it only the ?X that makes it dependent on Classic 99?

The file must be saved without the >80 byte header. If there is a way to do that on a real TI99 then it should work.

[Asmusr]

6 minutes ago, senior_falcon said:

The file must be saved without the >80 byte header. If there is a way to do that on a real TI99 then it should work.

Is the >80 byte header the TIFILES header? As long as you're on a real TI it doesn't exist, so I guess it depends of how you transfer files from your TI to your PC or FinalGROM.

[pixelpedant]

2 hours ago, senior_falcon said:

I think the structure is fine. I think if you make this change it will work.

60 INPUT #1:CNUM::LINPUT #1:CPAT$

 

The result with the following:

 

40 CALL CLEAR
45 OPEN #1:"DSK1.PATS",INPUT
50 FOR X=1 TO 2
60 INPUT #1:CNUM
65 LINPUT #1:CPAT$
70 CALL CHAR(CNUM,CPAT$)
75 PRINT :"Loop "&STR$(X)&": ": :"CNUM: "&STR$(CNUM):"CPAT$: "&CPAT$
80 NEXT X
90 CLOSE #1
100 PRINT :"HERE IS WHAT THESE CHARACTERS LOOK LIKE: "&CHR$(128)&CHR$(129)&CHR$(130)&CHR$(131)&CHR$(132)&CHR$(133)&CHR$(134)&CHR$(135)
110 CALL KEY(0,K,S):: IF S=0 THEN 110

 

i.e., an INPUT (for the integer) followed by LINPUT (for the string) is as follows:

 

 

Which is to say, the INPUT reads only the integer with which the first record starts, followed by the LINPUT reading the entire record, for the second record. 

 

Which is to say INPUT and LINPUT do have distinct behaviours, once compiled, but not in a way that is immediately useful, here. 

 

So I think I do need to just put the values in separate records, which is easy after all. 

 

Also preferable because, for me, it's preferable (when possible - it isn't always) to have code which behaves pretty much the same in XB and after compiled, rather than having different behaviours in each case. 

 

[senior_falcon]

5 hours ago, pixelpedant said:

Which is to say, the INPUT reads only the integer with which the first record starts, followed by the LINPUT reading the entire record, for the second record. 

Which is to say INPUT and LINPUT do have distinct behaviours, once compiled, but not in a way that is immediately useful, here. 

So I think I do need to just put the values in separate records, which is easy after all. 

Also preferable because, for me, it's preferable (when possible - it isn't always) to have code which behaves pretty much the same in XB and after compiled, rather than having different behaviours in each case. 

 

This works the same in both XB and compiled XB. RUN 200 makes the file, then RUN reads the file and prints what was read. (I did not test making the file from compiled code.) 

Maybe this is what you meant by having separate records? At first I though you were saying you need to open two separate files.

It is definitely true that compiled code should run the same as XB. That way you can do your debugging in XB where it is easy.

100 OPEN #1:"DSK1.CHARDATA",INPUT
110 FOR J=1 TO 9
111 INPUT #1:I :: LINPUT #1:I$
112 PRINT I:I$
120 NEXT J
130 CLOSE #1
140 END
200 OPEN #1:"DSK1.CHARDATA",OUTPUT
202 FOR I=1 TO 9
205 I$=RPT$(STR$(I),64)
210 PRINT #1:I:I$
220 NEXT I
230 CLOSE #1

 

[pixelpedant]

53 minutes ago, senior_falcon said:

At first I though you were saying you need to open two separate files.

Oh, no, indeed, I just meant separating the values into individual records so that LINPUT can be used to read all of them gracefully, whether compiled or interpreted.  Which has indeed worked out fine as a solution, of course.  There's no particular reason both values in each pair should need to be in the same record as they were originally.  Just splitting them in this way is fine, so that the file is now:

 128 
00000000000304080000000000BB00AAA02040800000000000AA00BB00000000
 132 
0A080A080A080A080A08040300000000A020A020A020A0200000000000804020
 0 
0000000000000000545454545400FC00282828282800FC004464745444C4C404
 4 
90989C9490B0B080007C1C6C74787C00007C7C0C74787C00007C7C007C7C7C00
 8 
80808080808080FC0010187C181000FC04040404040404FC00704870484800FC
 12 
00784070404000FC00304878484800FC0010387C101000FC80B8A0B4A4A480FC
 16 
000008DC484000FC04344424146404FC00784070404000FC00000000000000FC
 20 
FC000000000000FCFC0000000000000000704870404000FC0010307C301000FC
 24 
00384040403800FC04040404040404FC00704870487000FC0010107C381000FC
 28 
04444444447404FC040404040404040480808080808080800000000000000000
 35 
082C386C3868200000007878FC000000

 

[senior_falcon]

I have uploaded a revised version of JUWEL which fixes a bug that Alessandro found. This happened when you used DISPLAY AT(..)SIZE(..)

The entire line was cleared and not just the characters specified by SIZE. All fixed. Another bug was found that might have caused problems when putting the runtime routines in low memory.

Post #1 and post #918 on page 37 have the revised version.

[tmop69]

5 hours ago, senior_falcon said:

I have uploaded a revised version of JUWEL which fixes a bug that Alessandro found. This happened when you used DISPLAY AT(..)SIZE(..)

The entire line was cleared and not just the characters specified by SIZE. All fixed. Another bug was found that might have caused problems when putting the runtime routines in low memory.

Post #1 and post #918 on page 37 have the revised version.

 

Many thanks Harry for your beautiful software and the support you provide. It's the de facto standard, without any doubt, for anyone still wanting to use BASIC to develop games for the TI.  Apart from my compilation of legacy games, we have the tons of games by @Retrospect, games from @SteveB, @Bleepbit, @Cheung, etc. and the creations from new TI99 users like @whoami999ster and @Sergioz82.

 

 

[senior_falcon]

I have uploaded another revised version of JUWEL which fixes yet another bug in the compiler that Alessandro found. This bug could almost never happen, and I was fortunate in tracking down the place in the code where it occurred. Once found the fix was easy. An earlier fix caused two programs to fail. MAKECARTG and the loader when creating EA5 files with the runtime in low memory. Since they worked before, the fix was easy once I figured out what had happened.

I am thinking of renaming this project the INSECTARIUM, which is a 50 cent word meaning "Bughouse". Sometimes I feel this project will cause me to end up there.

 

Post #1 and post #918 on page 37 have the revised version.

[+Retrospect]

On 5/3/2022 at 9:04 AM, tmop69 said:

we have the tons of games by @Retrospect,

There will be another one before the end of this year   

 

[wolhess]

@senior_falcon 

Hello Harry,

I installed the new XBGEM 2.9 (from the Juwel 4 package) on my F18a TI with the result that the console blocked at the XB 2.9 prompt.

 

If I autoload my Mega Menu program (compiled with your compiler) the program will also work with tipi access and with tipi/internet weather access.

 

When I press FCTN+4 to pause the Program menu, I see the corrupted XB prompt and the console is stuck.

Is this a known behavior that the new version doesn't work with an F18a modded console?

 

On a second XB console with an F18a (console pure without 32K expansion) I see the same behavior.

 

 

In the XBGEM 2.8 version I have no problems with my F18a system.

 

On my normal console (no F18a) XB2.9 works fine.

 

 

 

 

 

 

[wolhess]

@senior_falcon

Hi again,

 

reight now I tested the new XB 2.9 on my console with a EVPC2 80 column card.

 

The running program changed to the normal 32 column mode.

This system shows me the first time a 80 column XB version. I can list and edit the XB programs in 80 column direct at the console. AMAZING!!!!

 

My Mega Menu (compiled) program is autoloading and working fine.

But when I break the program the system hangs at the normal XB prompt.

 

Maybe this is because I compiled the program with the "Put runtime in low memory" option?

 

 

[senior_falcon]

6 hours ago, wolhess said:

@senior_falcon 

Hello Harry,

I installed the new XBGEM 2.9 (from the Juwel 4 package) on my F18a TI with the result that the console blocked at the XB 2.9 prompt.

Hard to say what is happening here. Debugging from a distance and without a debugger is challenging. Do you have the 32K ram expansion? Is this screen shot right after pressing 2 for XB 2.9? There are 3 extra characters before the cursor-I wonder why that is?

 

If I autoload my Mega Menu program (compiled with your compiler) the program will also work with tipi access and with tipi/internet weather access.

 

When I press FCTN+4 to pause the Program menu, I see the corrupted XB prompt and the console is stuck.

A compiled program needs 32K to run, so obviously you have that. It looks like autoload works fine, but somehow the editor cannot be used, either from normal startup (Press 2) or when a program breaks?

Is this a known behavior that the new version doesn't work with an F18a modded console?

I do not know this.

On a second XB console with an F18a (console pure without 32K expansion) I see the same behavior.

I do not know this for a fact, but would be surprised if this worked without 32K.

 

In the XBGEM 2.8 version I have no problems with my F18a system.

 

On my normal console (no F18a) XB2.9 works fine.

 

Compared to XB 2.8 G.E.M., there is an additional bank of 8K memory, which is where the new editors are kept.

Is it possible that your cart is not seeing that bank?

Since you can autoload a program it should be possible to resolve this. I will PM you later today so we can figure this out.

 

 

 

 

 

[senior_falcon]

18 hours ago, wolhess said:

@senior_falcon 

I installed the new XBGEM 2.9 (from the Juwel 4 package) on my F18a TI with the result that the console blocked at the XB 2.9 prompt.

 

Hi Wolfgang:

Take a look at my post #8 in "TI99/4a OS Version"

There is a one line program listed there. Save it to DSK1.LOAD using any XB that works, then put in XB 2.9 G.E.M. and press 2. What number is printed?

[wolhess]

14 hours ago, senior_falcon said:

Hi Wolfgang:

Take a look at my post #8 in "TI99/4a OS Version"

There is a one line program listed there. Save it to DSK1.LOAD using any XB that works, then put in XB 2.9 G.E.M. and press 2. What number is printed?

Hi Harry,

 

Do you have the 32K ram expansion?

--> Yes I have a 1MB SAMS card in the PEB and it defaults to the normal 32K expansion.

 

Is this screen shot right after pressing 2 for XB 2.9?
--> The screen shows the status after pressing BREAK (FCTN+4).

--> The same result comes up If I press 2 from the TI Menu.

 

There are 3 extra characters before the cursor-I wonder why that is?

--> The prompt with the extra character is the same if I autoload and break the program or if I press 2 and the system shows the prompt the first time.
 

It looks like autoload works fine, but somehow the editor cannot be used, either from normal startup (Press 2) or when a program breaks?

--> Both ways reults in the same blocking prompt screen.
 

I do not know this for a fact, but would be surprised if this worked without 32K.

--> In the console with an F18a built in, the system shows the same blocking prompt screen (with the same caharacters befor the very fast blinking cursor).

--> In my console witout an F18a, I can work with the XB 2.9 without an issue! Even without or with 32K expansion.
 

Is it possible that your cart is not seeing that bank?

 --> Maybe it is possible.
 

There is a one line program listed there. Save it to DSK1.LOAD using any XB that works, then put in XB 2.9 G.E.M. and press 2. What number is printed?

--> The number is "8", after BREAK I see again the prompt wit the three character before and the console stucks.

--> With XB 2.8 I see also "8", after BREAK I see the normal prompt and I can edit the program.

 

 

[senior_falcon]

Well now, that's a bit of a mystery. It seems that the F18A is blocking the editor somehow. Even though the editor seems to be frozen, try typing BYE and Enter. Maybe the editor is working, but just not appearing on the screen.

I will look to see if there is something obviously different between 2.8 and 2.9

[Asmusr]

Can it be reproduced in JS99er.net with F18A enabled?

[senior_falcon]

16 minutes ago, Asmusr said:

Can it be reproduced in JS99er.net with F18A enabled?

It seems to work fine. However, JS99er has version 2.920220202. The latest version is 2.920220317. It would be nice if the latest version did not work in JS99er; that way it should be possible to track down the problem.

[Asmusr]

35 minutes ago, senior_falcon said:

It would be nice if the latest version did not work in JS99er; that way it should be possible to track down the problem.

Updated.

[senior_falcon]

I am still seeing 2.920220202

[senior_falcon]

4 hours ago, Asmusr said:

Updated.

OK, now it is version 2.920220317. F18A is enabled and the good news is that everything seems to work normally. I can press 2 and get the command line as expected. I ran a simple program and when it ended the command line came back.

The bad news is that everything seems to work normally, so I have absolutely no idea what might be going on.

(edit) I do notice that the keyboard response is a bit sluggish when using the F18A. You have to type slowly or key presses are missed. With it disabled the response seems normal.

The 80 column hack in Classic99 is not available, so EDIT80 does not work properly unless the F18A is enabled.

Edited June 18, 2022 by senior_falcon

[senior_falcon]

@wolhess

As expected, without the 32K expansion, there are things that do not work and the computer crashes. I think the XB 2.7 core of this works fine, but many of the CALLs and other features I added such as the 40 and 80 column editors, XB256, The Missing Link, etc. all need 32k and will not work.

 

[wolhess]

15 hours ago, senior_falcon said:

Well now, that's a bit of a mystery. It seems that the F18A is blocking the editor somehow. Even though the editor seems to be frozen, try typing BYE and Enter. Maybe the editor is working, but just not appearing on the screen.

I will look to see if there is something obviously different between 2.8 and 2.9

Hi,

I tried to type BYE but nothing happens. Only a reset helps to get the title screen.

 

In the version 2.820210712 I can break the program to the XB prompt and I can edit, list, save and load back the program without an issue.

[wolhess]

11 hours ago, senior_falcon said:

@wolhess

As expected, without the 32K expansion, there are things that do not work and the computer crashes. I think the XB 2.7 core of this works fine, but many of the CALLs and other features I added such as the 40 and 80 column editors, XB256, The Missing Link, etc. all need 32k and will not work.

 

You are right, I only tested the short "100 CALL VERSION(V)::PRINT V" program. 

 

Normaly I always have the 32K RAM expansion active.