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:
190 CALL LOAD(-7,4):: RUN "DSK1.COMPILER" - not COMPILERW
(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.
Edited by senior_falcon, Fri Aug 17, 2018 9:52 PM.