Jump to content

XB Game Developers Package


Recommended Posts

EDIT JULY 29, 2023 - The latest version, JUWEL5, is at the end of this post.

At the end of this post is the latest version of the Extended BASIC Game Developer's Package "Juwel5"

The biggest additions are faster and more versatile utilities for making cartridges. MAKECART8, which is used to make a rom cartridge from a compiled program, is much faster than the previous version, plus it has changes that should avoid problems regardless of which rom bank is selected at startup.  There is another utility that can combine multiple cartridges into a much larger multiple cartridge. You can have a compiled program load and run any other program in the cartridge, allowing a large XB program with many program files to run from a single cartridge. Or you can have a cartridge start with a menu program that allows you to select from multiple compiled programs.

The cru access recently added to XB 2.9 G.E.M. can now be compiled. Also CALL MOVE from XB 2.9 can be compiled.

There was a bug that caused problems when adding a comment to a line containing an IF/THEN/ELSE statement. This has been fixed.

The docs received the usual additions and editing. There were probably some other changes to the program, but I have forgotten what they are.


(There is a tutorial showing how to make this multi cartridge)



(EDIT APRIL 10, MAY 2, 2022  May 10, 2022 - The latest version, JUWEL4, is at the end of this post.


At the end of this post is the latest version of the Extended BASIC Game Developer's Package "Juwel2".

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

XB29GEM2      Extended BASIC 2.9 G.E.M.


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


(EDIT JUNE 28, 2021 - The latest version, JUWEL, is at the end of this post)


Attached is a zipped folder that contains two tools that XB programmers can use to create arcade quality games.


The first tool is XB256 which unlocks most of the graphics capabilities of the 9918A video processor. You can can toggle between 2 screens while preserving the graphics on each screen. Screen2 offers a full 256 unique character definitions, compared to 112 in XB. Plus, you can have 28 double sized sprites, each with its own unique character pattern. There are scrolling routines to scroll characters left, right, up and down. Others let you scroll smoothly a single pixel at a time. Yet another lets you do a "Star Wars" style text crawl. Areas of VDP memory can be save in a compressed format so you can save character definitions, sound tables, screen images, etc. in a more compact form that can be loaded much more rapidly. There is a sound list compiler that creates sound lists from music and sound effects that you create in XB. Once these are included in your program you can choose music or sound effects to automatically play in the background while your program runs. Also, the sound list player can play two sound lists at a time so you can have background music playing with sound effects that don't interrupt the music. All this can be easily programmed in XB.


The other tool is my XB compiler, which has been expanded to include all of the XB256 assembly language subroutines. Compiling the program will speed it up by a factor of 10x to 30x. With the ability to run the advanced graphics and sound capabilities of XB256 at near assembly speed you can create arcade quality games without having to learn how to program in assembly language.


(Edit May 18, 2014 - Revised version is attached with CF7 and Myarc controller compatibility, more versatile memory allocation for sound tables, and expanded documentation about sound tables. Replace the old one with this and don't mix and match files as they are not compatible between versions.)

(Edit November 16, 2014 - Added disk catalog utility (CAT) to XB256 and a faster random number generator (IRND). There are now two converter programs that generate sound lists from XB CALL SOUND statements, which have different strengths and weaknesses. The manual was expanded and a few bugs were fixed.)

(Edit November 30, 2014 - Newest version with a few improvements - FREEZE and THAW for automatic sprite motion, IRND expanded to return up to 8 random numbers per call, etc.)

(Edit December 26, 2014) This should be the final update of the XB256/COMPILER256 combination. There is a built in utility that forces a program to be saved in IV254 format. If the XB program segments are in IV254 fomat then large programs running under XB256 can be chained together without overwriting the screen, character definitions and colors used when in screen2. A subroutine has been added that will load a font with true lower case characters with descenders. There is a subprogram CALL LINK("SCREEN",color) that works exactly like CALL SCREEN except the screen color is saved. That way when you change screens the screen background colors are saved/restored. And of course, the usual tweaks to the documents.

(Edit June 12, 2015) Compiler256D now has disk access - DV type only of any length, up to 3 files open at a time plus a few bug fixes. Part of XB Game Developer's Package. Latest version is in this post.

(Edit April 27, 2017) BXLOADER is attached. This lets you use the EA cartridge to load the object code, giving a 20x improvement in speed.

(Edit April 28, 2017) BXLOADER is updated. Now you have the option of using compressed object code which loads twice as fast as uncompressed code.

(Edit January 25, 2018) "Amontillado" Major update to user interface. There is an autoprompt every time a response is asked for and you pretty much just have to press Enter repeatedly to compile a program. A menu program now directs everything and the new loader is incorporated as part of the package. Changes to the original XB/XB256 program can be made and recompiled very quickly now. The agonizingly slow GPL loader from XB is replaced with the fast assembly loader from E/A. Read XBGDPDOCS for set up information.

(Edit February 13, 2018) "Bordeaux" Changed the compiler so it can handle the more versatile XB style IF/THEN/ELSE format

(Edit February 14, 2018) Uploaded "Bordeaux" again with slight revisions to compiler documentation.

(Edit February 25, 2018) Uploaded the "Chardonnay" version. This fixes the IF/THEN/ELSE bug that was in "Bordeaux". As far as my testing shows, the only limitation is that you cannot have nested IF/THEN/ELSE statements.

Somehow an older version of COMPRESS found its way into the package; that has been replaced with the latest version.
Additions to XB256 and the compiler are CALL LINK("SYNC") which lets you tell a loop how long to take. I will post a video showing a digital clock that uses this
Another addition is CALL LINK("RUNL1") which lets you load and run an XB program from another, but without doing a prescan. This means that variables are carried through into the new program and you don't have to store them and then retrieve them.
I have removed the DV80 version that was compatible with a real TI. It is a lot of trouble to maintain two versions and I can't see any benefit in spending time on that. I'm getting 72 errors when compiling Aperture on a real TI - I think there is something wrong with the runtime routines but don't know what. The programs created with Classic99 are compatible with real iron and that's really all that matters. If people complain enough I could revisit this.
(Edit April 6, 2018) Uploaded "Dolcetto" version. The changes were:
COMPILER: A couple of bugs were fixed. If you broke a compiled program running from XB and if CALL LINK("FREEZE") had been used then sprite motion was turned off when you ran the program again. Under certain conditions the sound list processor could leave one or more sound generators turned on
XB256: Both bugs described above could cause the same trouble with XB256 and have been fixed. COMPRESS had a few changes so it provides better prompts when saving data. You can turn off the autocomplete routine in XB and XB256 by pressing F3 when prompted OLD DSK.
All the documentation has been revised with extensive changes to the sound table section of the XB256 manual. SLCONVERT in particular was very poorly described and almost unuseable. Using it should be much easier now.
(Edit April 6, 2018) I goofed. There were some left over files in the folder which was the result of trying to have a TI compatible version and a Classic99 compatible version. and I did not rename one of the files. I have re-uploaded DOLCETTO or you can just edit line 190 in LOAD:
(April 12, 2018) DOLCETTO1 is uploaded which fixes a dumb mistake I made in CALL KEY while saving a few bytes.
(May 27, 218) ENCRUZADO uploaded with these changes:
COMPILER: You now have an option to put the runtime routines into low memory from >2000 to >3FFF. This would be necessary is if your compiled program is too large to run in the 24K of high memory, with both compiled code and the runtime routines all located there. With the runtime routines in low memory it is safe to say that you should have no memory problems when compiling even the largest XB programs. If the program is saved as EA5 the program will be loaded exactly as before. If you save as an XB loader there are two programs. The first loads the low memory portion of the code and then automatically loads and runs the second program. Other than a brief pause while the second program is loaded, you will see no difference in how this functions.
When running from XB there are now three ways to start the compiled program.
CALL LINK("RUN") starts the program with a scan that breaks the program execution when F4 is pressed.
CALL LINK("RUNEA") starts the program exactly as it would be when running as EA5. No F4 scan is performed.
CALL LINK("RUNV") starts the program but without resetting any of the Screen2 patterns or character definitions. This lets you chain compiled programs together while retaining all the graphics created by the first program.
A bug in playing sound lists from EA5 was corrected.
XB256: The big change here is that there is a second version of XB256 called XB256HM.This provides a way to save an XB program and XB256 in the same program; If you don't need the speed of a compiled program, this makes a nice, neat one program package
(edit) I left out a file. I have reposted the package as ENCRUZADO_BETA1.ZIP
(edit) - There is a minor bug that needs to be fixed by editing line 520 in the compiler. See post 228 if you want more details.
Edit line 520 to be:
520 DISPLAY AT(21,1):SF$&" is compiled." :: CALL LOAD(-1,0)::RUN "DSK1.LOAD"
(edit) Attached is the finished version of "Encruzado". Besides the changes noted above, I also added an option to use the runtime routines from the earlier TI BASIC compiler. These are more compact and may run a bit faster because the interrupt routine has less overhead.
(Edit August 17, 2018) The latest version is "Frappato". This does not have any huge changes, but there are some useful improvements:

XB256 and XB have been altered so you can tell whether autosave is active. When it it active there is a light pixel in the center of the cursor. The cursor becomes solid black when autosave is no longer active.

XB256 has been altered so it will try to modify the XB grom starting at >6000. If you have enabled gram at >6000, this can addresses some stability issues that arise when using cpu overdrive.
XB256HM is gone. Instead, XB256 is modified so you can merge an XB program with the XB256 loader, making a nice neat package.
A bug in XB32 that interfered with garbage collection has been found and fixed. This would only cause trouble if you put the runtime routines in low memory and tested in XB.
Plus the usual improvements to the docs.
(Edit January 1, 2019)
Here is GRECHETTO, the latest version of the XBGDP.

Changes include:

The compiler is still an XB/Assembly hybrid program, but it was rewritten so the main loops are all in assembly. This makes it about 5-6x faster.

Nested arrays can now be used

Multiple variables can be assigned with one LET statement. i.e. 10 A,B,C,D=23 or 10 IF Z=12 THEN A$,B$,C$="YOU WIN!"

The compiler looks for decimal points and gives a NON INTEGER message next to the line number. This way when you return to XB you know which lines need attention.

Speech is supported with both SAY and SPGET.

As always, these changes may cause unexpected trouble in other parts of the program, so for now this is a BETA release.

(Edit January 7, 2019) GRECHETTOBETA2 was uploaded this post and #403.

A folder, GRECHETT99 was added with files modified to run on a real TI99. The autoprompts are modified to provide the proper defaults when running on a real TI99. A bug in disk access is fixed.

There are two other changes that hopefully won't cause trouble:

1 - The runtime files have been rearranged to use memory more efficiently - i.e. XB256 routines are not


(edit 2 July) This new package contains a revised version of XB 2.8 G.E.M. that corrects a minor bug when loading EA5 programs.

loaded unless needed.

2 - The runtime files in GRECHETT99 have been stripped of comments to be more compact. Without the comments they are about half the size. Hopefully no code was inadvertently stripped out.


Here is the latest and probably the final version of the XB Game Developers Package. This version is called "Hondarrabi".


The most important addition is that named subprograms are now fully supported. Now almost everything in XB can be compiled, with the exception of DEF and trig functions.

I will leave this in beta for testing for maybe 3 months before making it the final release. Find the bugs now, before I lose interest in this!


(March 15, 2019) Here is the final version of the game developers package. Here are the changes:
COMPILER: The compiler actually does now fully support user defined subprograms, With Hondarrabi it could not pass an array to a subprogram such as:
10 A(2,3)=523::CALL TESTSUB(A(,))
110 PRINT Z(2,3) and 523 will be printed.
The XB loader that uses the full 32K of memory (i.e. put runtime in low memory) can now save in both EA5 and XB format.You no longer have to go to MiniMemory for that (although it is quite a bit faster to do that)
The usual minor tweaks to the code and docs.
(Edit March 17, 2019) I have re-uploaded the package. The only difference is in the documentation which now accurately describes how to use IF-THEN-ELSE with the compiler. Also page 12 of the compiler manual has a list of reserved names that cannot be used as subprogram names.


(Edit April 6, 2019) "ISABELLA2". This has all the bug fixes developed in the course of the past few weeks getting Stratego to work and as far as I know it is complete. A few bugs in how subprograms are handled were ironed out and now IF THEN ELSE works exactly like XB. There was one quirk that I left in. That was found by Vorticon when he tried to display a print list using SIZE and found that the line was cleared all the way to the right side of the screen. I tried to fix this but found that the fix changed the display/print behavior elsewhere. It would take weeks of testing to get this all exactly the same as XB, so I decided to change the docs to describe the limitation.


I made a minor addition to the utility XB32K that allows the programmer to use all 32K of expansion memory for an XB program. It is more thoroughly tested and the docs go into much more detail. This is now part of XBGDP.


(Edit April 23, 2019) "ISABELLA4". A couple of minor tweaks. The main difference is that Asm994a has been added, which simplifies the setup if you want to use that assembler. This version was converted so that it defaults to .TXT files which eliminates one step in the process. The docs have been modified to reflect this change, plus a few other minor changes to the docs.

(edit April 27,2019) If you downloaded ISABELLA4, you should replace it with this version. In the earlier version, I did not include the licensing agreement for Asm994a which Burrsoft says must be included.


(Edit May 29,2019) "ISABELLA5" This addresses a few issues that Wolhes found. The changes include:

Fixed a bug that caused a crash when inputting an array element with ACCEPT AT. Fixed a bug that caused problems passing an array element to a subprogram. When using ACCEPT AT with SIZE, the XB source program will "beep" when reaching the right hand boundary. The compiled version will 'honk". This is a side effect from using the console text editor and is not practical to change. The behavior is noted in the manual. CALL ERR is not supported by the compiler and the docs have been revised to describe this.



(edit 2 July) This new package contains a revised version of XB 2.8 G.E.M. that corrects a minor bug when loading EA5 programs.

(Edit July 4, 2019) ISABELLA6. This adds the ability to delete a file on a disk drive with the XB statement DELETE "DSKn.FILE". N.B. This does not work when using FIAD and Classic99.

Also boot tracking has been added so you can have the XBGDP on DSK1 to DSK9. If it is on DSK3 you would start it up with RUN "DSK3.LOAD". There is one case where boot tracking does not work - if you are using the TI assembler that comes with the package, the return will be to the start of XB which  tries to RUN DSK1.LOAD. There is no practical way to change this. You will have to type RUN "DSK3.LOAD" again or you could have a one line LOAD program on DSK1: 10 RUN "DSK3.LOAD". This does not happen if you use Asm994a.


(Edit May 17, 2021) JUWELbeta. Juwel lets you use assembly routines to support compiled code. Page 17 of XB Compiler.pdf has the details.

The files TMLC, T40XBC, T80XBC, XXBC are TML, T40XB, T80XB, XXB modified to work with the compiler. You can use your own custom routines if desired.

Also included is XB 2.8 G.E.M. which offers many advantages over the usual variants of XB.



(Edit June 28, 2021) Here is XBGDP20210628. the release version of the XB Game Developer's Package "Juwel"

The zipped folder contains two folders. One is JUWEL which contains the latest versions of the compiler and XB256. Compiled programs can now use assembly support routines.

The other folder is XB28GEM,  which contains XB 2.8 G.E.M. and its documentation. This is a major advance for Extended BASIC, offering many improvements over XB 2.7.  and unlocking the graphics potential of the TI-99/4A. XB can now use bit mapped graphics, 40 column text mode, 80 column text mode and XB256, all available from the main menu.

(Edit July 2, 2021) Here is XBGDP20210702. There was a minor bug in XB 2.8 G.E.M. that is now fixed. Other than that this is identical to the previous version.










Edited by senior_falcon
Revision to program
  • Like 25
  • Thanks 2
Link to comment
Share on other sites



Many thanks for your efforts to add some major functionality to XB that's accessible to those of us who never quite grasped assembly. Right now, I'm struggling to recall my own XB programming skills, it's been that long since I've exercised that portion of my brain cells. I never wrote many game/graphic programs and went more towards creating things to solve my own practical needs, like my darkroom timer and associated business-related apps or my bloated do-all disk cataloger program.


When I tried games with sprites, the CALL COINC statements never could quite give me the speed or response I was seeking for good gameplay, so I ended up leaving game creation to more competent programmers than I. Maybe with your new routines, even I could take a stab at creating something worth typing RUN to play it, lol.


Edited by Ed in SoDak
Link to comment
Share on other sites

Thank you Harry for bringing out the full potential of XB. To think that we could have had these capabilities decades ago... But then, with all the included goodies, there would have been little enhancement to learn assembly language at all!

Edited by Vorticon
  • Like 2
Link to comment
Share on other sites

If I was so not good at Assembly, I would try this out.


It really is amazing set of tools. - I will have to see if I can help out this year by sharing some of my 'assembly' stuff, it might help adding new stuff to this package, or get people to jump over to Assembly.


Now we just need a GPL Development Package to get people to write new GROM based games, it really not that bad of lang. once you learn it.. :) And with UberGrom coming out, it would be nice to see some new GPL programs/apps/games to burn into it!

Edited by Gary from OPA
Link to comment
Share on other sites

Yea, well the more I promoted GPL the more flak I got for it.

Some fans but as most are Assembly and C people on this site.

I feel I was flogging a dead horse.

Which is why I do not show up much anymore.

(Not that I am picking a fight, just pointing out the truth of my feelings on this matter.)





Look at GPL Section.

  • Like 1
Link to comment
Share on other sites

Yea, well the more I promoted GPL the more flak I got for it.

Some fans but as most are Assembly and C people on this site.

I feel I was flogging a dead horse.

Which is why I do not show up much anymore.

(Not that I am picking a fight, just pointing out the truth of my feelings on this matter.)





Look at GPL Section.




I have never seen anyone give you flack for GPL. I think maybe you misconstrue the flack.


We would all love to learn more and appreciate the work you have done with GPL and RXB. We just don't all agree with all of your strongly felt and verbosely articulated positions on some topics. And your need to post on unrelated topics about unrelated things..


GPL is something I intend on looking into in the future and I hope you and your documentation is available at that time to show how it's done.



Link to comment
Share on other sites

Many thanks for an excellent development tool, Harry!


Rich, talking GPL is fine--and you have taught us a lot about it. :) It is TI programming after all, which is why we come to this forum in the first place. My only thought for some of the flak you've taken over time is something I also tell my wife: it isn't the intended content of the message that gets to be a problem, it is the way you approach it. There are good ways (and you've often chosen those, and the discussion has been VERY good) and there are not so good ways (and you've hit on those a few times too--and those were the conversations that devolved into unholy messes). I really like your input. My only recommendation would be to look at your message and read it a bit critically before you post. You'll catch a lot of the potential misunderstandings that way, and the conversations will be better overall. I make mistakes too (we all do). And look at another bright side item--Once we've tested Gazoo's ÜberGROM image, I'll be asking him to do one with RXB in it and another with Winfried Winkler's XB3, so that all three of the viable strains of Extended BASIC are readily available in cartridge form. Your strong advocacy of RXB in a cartridge was one of the reasons I didn't give up on the project when it ran into some development issues.


Now we have the wonderful XB Game Developer's Package to compile things into Assembly. Maybe you could develop something that would compile into GPL to give budding GPL programmers a similar programming environment? I would really like that one, Rich! Hoist it into one of the ÜberGROMs and you'd have a huge space for your program files and keep it AMS aware to use the extra space there and you'd have something awesome. . . :) :) :)

Link to comment
Share on other sites

Hello Harry,


Thanks again for sharing these great XB extensions!


I have a 'real' TI with a CF7+ device installed (Plus XB). I loaded the XB Game Developers Package without any issues (RUN "DSKn.XB256"), but when I run the 256DEMO, the TI just froze. I tried a couple of times with the same result. As a matter of fact, after I load XB256, I'm not able to load or run any program. Any ideas on what could be causing this problem...?


Many thanks,



Link to comment
Share on other sites

Both "The Missing Link" and "XB256" do some creative rearranging of the VDP RAM. This works fine when using emulators (Classic99 and Win994a) and real iron using the TI disk controller and the Myarc controller. The CF7 does not like what is done to the VDP and so disk access will not work once TML or XB256 are loaded. On "In praise of the F18A", post 48, I have posted a test program that details what is done to the VDP ram and pointers in the scratchpad. Hopefully someone who has a CF7 and some assembly knowledge can use this information to find a solution to the problem. There are a couple other approaches for XB256 that should make it useable with CF7, but TML has more stringent requirements and this approach is the only one that can work with it.

Link to comment
Share on other sites

I've attached a modified version of XB256. Instead of doctoring the disk file buffers, this one maps the VDP in a different way and changes the bottom of the stack pointer. It should work fine with the CF7. Give it a try and if it works at all, then give it a thorough testing. It runs the demo program properly on Classic99. You should be able to open disk files just like in XB and read/write to them. One caveat is that the supporting software for XB256 hasn't caught up to the changes yet, so you can't make soundlists or use COMPRESS to save areas of VDP. Other than that it should work OK. (I hope!)



  • Like 1
Link to comment
Share on other sites

Thanks for testing this. I will be releasing the modified version soon. I have to go through everything to be sure all the necessary changes get made, plus update the manual. This is a bit of an improvement on the original because you have more control over how the VDP memory is used. and there is a bit more room in the stack. This will make XB256 compatible with the CF7. I still need someone to use post #48 in "In praise of the F18A" to determine if the missing link can be made to work with the CF7.

Link to comment
Share on other sites

Thanks Harry for modifying XB256 to work on the CF7! I tried it on my machine and worked without any issues. Sorry for the delayed response, but I was out for a while. Thanks again for sharing your work with us.

Link to comment
Share on other sites

  • 2 weeks later...

Revised version is available in Post #1. The package has been modified to allow compatibility with CF7, myarc controllers, etc. The vdp memory allocation is different and the various components are not compatible between versions, so delete the older version and use this one. The only real difference that you would see is that sound tables are handled somewhat differently. Allocating memory for sound tables is simplified and there is a bit more stack space available.

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...