XB Game Developers Package

[pixelpedant]

I just noticed that using XBGDP Juwel, upon pressing Enter at the "Press ENTER or QUIT" prompt after the assembler is finished assembling whatever program, the following appears briefly at the bottom of the screen:

 

 

Funny little off-brand leftover, there. 

[SteveB]

On 12/14/2021 at 10:47 PM, Vorticon said:

Well bummer. I have no idea then why the values are not passing through.

Glad to hear though that array parameters work with SUB under compilation.

I'll dig further.

I don't know if this is still relevant: When passing a complete array and not just one element the SUB needs to be

 

SUB Test( SingleDim() , TwoDim(,) )

 

For a single dimension array include empty parenthesis, for more dimensions include one or more comma

[pixelpedant]

Finished my overview (and collection of demos) of the Game Developer's Package. 

 

In practice, it's more about the features of XB256 and their uses, since compiling a typical BASIC program using the package is, in and of itself and in most cases, as simple as pressing Enter a large number of times:

 

 

 

[+OLD CS1]

15 hours ago, SteveB said:

I don't know if this is still relevant: When passing a complete array and not just one element the SUB needs to be

 

SUB Test( SingleDim() , TwoDim(,) )

 

For a single dimension array include empty parenthesis, for more dimensions include one or more comma

This is also covered on page 184 of the TI Extended BASIC manual, with an example on page 185.

 

Quote

Arrays are indicated by following the parameter name with parentheses. If the array has more than one dimension, a comma must be placed inside the parentheses for each additional dimension.

[+Vorticon]

16 hours ago, SteveB said:

I don't know if this is still relevant: When passing a complete array and not just one element the SUB needs to be

 

SUB Test( SingleDim() , TwoDim(,) )

 

For a single dimension array include empty parenthesis, for more dimensions include one or more comma

Thanks but that wasn't the issue. It was a logic error in the program. All good now.

Still in debugging hell though ?

[TheMole]

11 hours ago, pixelpedant said:

Finished my overview (and collection of demos) of the Game Developer's Package. 

 

In practice, it's more about the features of XB256 and their uses, since compiling a typical BASIC program using the package is, in and of itself and in most cases, as simple as pressing Enter a large number of times:

 

 

 

I've grown quite fond of these little demos and your videos in general recently!

Now go back and make some more of them! 

[senior_falcon]

I have added the ability to save a compiled program as a cartridge. (Thanks to Tursi for an update to Classic99 that makes this possible)

First the program must be loaded. This can be either via the usual loading process in the compiler package, or via OLD DSK1.PROGRAM-X as I do in the video.

CALL LOAD(-31868,0,0,0,0)

RUN "DSK1.MAKECART"

Enter the name for the cartridge menu and the filename to save under.

The cartridge is created.

The new JUWEL package will be released in the next couple of days.

 

 

 

 

[sometimes99er]

11 hours ago, senior_falcon said:

I have added the ability to save a compiled program as a cartridge.

An awesome addition. ?
 

[+OLD CS1]

Stream-lining the process.

[pixelpedant]

I was taking a whirl at compiling a program with assembly support today.  I get this error, on attempting to load:

 

 

This seemingly originates from the following lines in the file L24AL1:

 

240 CALL PEEK(-4,S) :: PRINT :"Assembly routines to load?  DSK"&STR$(S)&".FILENAME" :: ACCEPT AT(23,1)SIZE(-28):D$
241 CALL LINK("RUN242") :: PRINT :"Press Enter:":"CALL LOAD(-31868,0,0,0,0):: RUN ""DSK"&STR$(S)&".L24AL2""";
242 DISPLAY AT(19,19):"loading..." :: CALL LINK("RUN",D$)

 

Inserting a statement to PRINT the value of D$ before CALL LINK("RUN",D$) in 242 indicates that the value of D$ is the desired value at that point ("DSK1.SETUP"). 

 

Any idea what might be going wrong? 

 

 

[senior_falcon]

Very glad to see someone giving this a try.

DSK1.SETUP should be the assembly routines embedded in an XB loader. SYSTEX is one method for doing this. I have written the equivalent called KWIKLOAD.  With nothing else loaded, you should be able to RUN "DSK1.SETUP" and have the assembly routines moved from the XB program into low memory with the pointers at >2002 and >2004 updated.

I will look at the docs tonight to see if there is anything that must be added.

[pixelpedant]

2 hours ago, senior_falcon said:

Very glad to see someone giving this a try.

DSK1.SETUP should be the assembly routines embedded in an XB loader. SYSTEX is one method for doing this. I have written the equivalent called KWIKLOAD.  With nothing else loaded, you should be able to RUN "DSK1.SETUP" and have the assembly routines moved from the XB program into low memory with the pointers at >2002 and >2004 updated.

I will look at the docs tonight to see if there is anything that must be added.

Oh, I see.  Yes, I missed that step (embedding the routines in an XB loader).  Will do that, and try again.  Thanks.

[senior_falcon]

I was too hasty in my response. What I wrote is correct, but it is not the whole truth.

Pages 16-19 of "XB Compiler.pdf" describe how to modify the code and make a loader with embedded code. The docs describe it in much more detail, but in a nutshell, the names of all the CALL LINKs must be converted to lower case in the source XB program. The assembly support routines must be loaded, usually via CALL LOAD. Then CALL LOAD("DSK1.FIXAL") and CALL LINK("X") will modify the assembly routines by changing all the names to lower case and modifying the code such as STRREF, STRASG, etc to be compatible with the compiler.

[pixelpedant]

Yes, I did ultimately find the full directions, in the docs and use FIXAL as needed (I had already been using UC2LC, but not FIXAL). 

 

Directions are, naturally, relatively involved, but as always, laid out in good detail in your documentation. 

 

 

[senior_falcon]

4 hours ago, pixelpedant said:

Yes, I did ultimately find the full directions, in the docs and use FIXAL as needed (I had already been using UC2LC, but not FIXAL). 

 

Directions are, naturally, relatively involved, but as always, laid out in good detail in your documentation. 

 

 

You left out the most important part. Did it work?

[pixelpedant]

4 hours ago, senior_falcon said:

You left out the most important part. Did it work?

Not so far, but I'm still futzing about trying to decide what I want to do with it. 

 

The important thing so far is that, while the result has been a loader which crashes, it crashes in a way that looks really cool

 

[senior_falcon]

Very colorful!

I'm assuming this is an XB program that uses assembly routines? Does it work in XB? If no, then obviously that must happen first. If yes, then can you PM me the XB program and assembly support routines?

 

[senior_falcon]

Here is the latest version of the Extended BASIC Game Developer's Package "Juwel".

When you unzip the folder there is the folder JUWEL+GEM. Inside that folder are:

XB29GEM2      Extended BASIC 2.9 G.E.M.

JUWEL2           XBGDP "JUWEL"

JUWEL992       XBGDP "JUWEL" for use with a real TI99. (The difference is that the comments are stripped out of the untime routines and the autoprompts use -S and -O instead of .TXT and .OBJ

 

TMOP69 had problems with DISPLAY AT and SIZE clearing to the end of the line. That problem should be fixed in this version.

There is one tiny anomaly left in the compiled code shown in the following program.

10 A$="ABCD" :: B$="1234" :: CALL HCHAR(1,1,42,768):: DISPLAY AT(1,1)SIZE(3):A$ !this fills the screen with the asterisk, then displays ABC in XB and compiled XB
20 DISPLAY AT(2,1)SIZE(6):A$;B$ !displays ABCD and 2 spaces in XB; displays ABCD12 in compiled XB
30 GOTO 30

This seems to be a bug in XB - the compiled code behave the way I think it should. I am reluctant to try to fix this for fear of breaking something else in the compiler; also, I do not believe this would ever cause problems in the real world.

 

(edit) Fixed bug with DISPLAY AT(..)SIZE(..) which would clear the entire line instead of just the length specified by SIZE. Also fixed another bug when putting runtime routines in low memory.

(edit) Fixed a bug in the compiler that could cause a crash in certain very rare circumstances. Also fixed two programs, MAKECARTG and the EA5 creater for runtime in low memory. A change to RUNTIME1 broke these. All is thoroughly tested now.

 

JUWEL4+GEM.zip

 

 

Edited May 11, 2022 by senior_falcon

[+OLD CS1]

4 hours ago, senior_falcon said:

20 DISPLAY AT(2,1)SIZE(6):A$;B$ !displays ABCD and 2 spaces in XB; displays ABCD12 in compiled XB

Looks like XB does not know how to handle semicolon-concatenated display items against the SIZE() clause shorter than the display output.

 

Replacing ";" with "&" in the line works as one would expect:

20 DISPLAY AT(2,1)SIZE(6):A$&B$ ! This line displays "ABCD12" in XB

Interestingly, if you set SIZE(8) in (the original) line 20, you get ABCD1234.  Quite an interesting bug.

[senior_falcon]

Here is the program I used to test the DISPLAY AT bug in the compiler.

 

 

[pixelpedant]

Seemingly strange issue I'm encountering here with use of CALL CHAR in a compiled program, when a few character patterns are read from a file. 

 

Given the following demonstration program

40 CALL CLEAR
45 OPEN #1:"DSK1.PATS",INPUT
50 FOR X=1 TO 2
60 INPUT #1:CNUM,CPAT$
70 CALL CHAR(CNUM,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

In Extended BASIC, my result is, as expected:

 

 

Compiling, Assembling and Loading this same program in JUWEL2 with all default options, at the CALL KEY loop, my result is instead the following:

 

 

DSK1.PATS IS A DV80 file, from which the intent is to read the first two sets of patterns here, and this happens successfully in XB:

 

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

 

When I modify the test program to print out the patterns it is reading, I get the following, in XB, as expected:

 

 

But the following, once compiled:

 

Which is to say, it is reading the 2nd and 4th records in the file, in that order. 

 

The garbage, I'm guessing, is a consequence of trying to write a pattern for character 4, which does not exist. 

 

But that doesn't explain (to me, anyway) why it reads the 2nd and 4th records, on opening the file, once compiled. 

 

 

[senior_falcon]

 

60 INPUT #1:CNUM,CPAT$

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

 

Disk and other peripheral access is now supported with some limitations:
DISPLAY, VARIABLE is the only file type recognized, but you can use any length desired from DV1 to DV254.

Up to three files can be open at a time. You must use #1, #2, or #3 – do not use other file numbers.

You can only use colons in a print statement. Commas and semicolons will not save as in XB.
10 PRINT #1:”Now, is, the, time   “ will print the entire string contained in the quotes.
20 PRINT #2:”Hello”:”World” or 20 PRINT #2:”Hello”::PRINT #2:”World” are equivalent.
Use LINPUT for reading strings – INPUT will be treated as LINPUT if used
LINPUT will read the entire entry including any ASCII characters (like in XB)
Use INPUT for reading numbers (like in XB)

[senior_falcon]

The latest version of XBGDP give you the option to save the program in a cartridge format, which many users prefer. (Saving as a cartridge requires XB2.9 G.E.M. and Classic99 version QI399.055 or later.)

You can save either as a grom cartridge or as a rom cartridge. A grom cartridge can be used on all TI-99/4a computers including V2.2. Grom cartridges have four 8K groms, and rom cartridges have four 8K pages of rom. The cartridge created requires the 32K expansion.
First the program must be loaded to memory. Normally you would make the cartridge after the program has been loaded during the compilation process as described above. After the options to Save as EA5, Save as XB, and RUN, the program will still be in memory. Or, if the program has already been saved in a previous session, OLD DSK1.PROGRAM-X will load it to memory. Once there, the following steps will save it in cartridge format
CALL LOAD(-31868,0,0,0,0)
 This turns off the expansion memory. If you forget to do this, the program will stop and print a reminder of what steps to take.
To make a grom cartridge:
RUN “DSK1.MAKECARTG”  or OLD DSK1.MAKECARTG then RUN
To make a rom cartridge:
RUN “DSK1.MAKECART8”  or OLD DSK1.MAKECART8 then RUN (Most of it is written in XB, so MAKECART8 takes more time to run.)

The loader program should be self explanatory. You are asked for two things.
The program name. This will become option 2 in the cartridge menu.
The file name where you want to save. You can change the default device name in line 180
The suggested device is DSK2.?X  The ?X. forces Classic99 to save the file without a header.
The suggested file name is the first 8 characters of the program name.
If you are making a GROM cartridge-G.BIN is appended to identify it as a grom cartridge.
If you are making a ROM cartridge. -8.BIN is appended to identify it as a rom cartridge.
If the save was successful, “Cartridge is saved” is displayed
Type NEW if you intent to do more work in Extended BASIC. This turns on the expansion memory.

 

 

 

[pixelpedant]

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. 

 

It's a bit silly inherently to read just two character patterns from a file, but this is originally from a program which was trying to save on memory by any means necessary, and so given it was using files already, more and more just ended up getting dealt with as file data, rather than string literals. 

[+OLD CS1]

8 minutes ago, pixelpedant said:

With integers and strings in separate records. 

Why not store it all in the same field, then separate it out?

 

For example, CHAR=VAL(SEG$(IN$,1,3)) :: PATTERN$=SEG$(IN$,4,254)

 

or use the first "character" in the field as a byte value for the character to assign,

CHAR=ASC(IN$) :: PATTERN$=SEG$(IN$,2,254)

 

Here I am taking advantage of a couple of function features.  ASC() only returns the ASCII value of the first character of a string, irrespective of its length.  SEG$(,,) with a length longer than the string simply returns the string from the start position.

 

Not sure what the memory savings would be doing it this way versus multiple INPUT/LINPUT statements.