Jump to content

Photo

XB Game Developers Package


333 replies to this topic

#1 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,245 posts
  • Location:Lansing, NY, USA

Posted Tue Apr 29, 2014 7:55 PM

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.
OLD DSK1.COMPILER
Edit line 520 to be:
520 DISPLAY AT(21,1):SF$&" is compiled." :: CALL LOAD(-1,0)::RUN "DSK1.LOAD"
SAVE DSK1.COMPILER
(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.
 
 

 

Attached Files


Edited by senior_falcon, Fri Aug 17, 2018 9:52 PM.


#2 Retrospect OFFLINE  

Retrospect

    Stargunner

  • 1,083 posts
  • Location:Wakefield, England

Posted Tue Apr 29, 2014 10:33 PM

Thanks Harry :)

 

I'm going to get practicing some routines through this week and next, bounce some ideas of mine around and have a good play with it.

 

Brilliant stuff!  



#3 Ed in SoDak OFFLINE  

Ed in SoDak

    Moonsweeper

  • 414 posts
  • Location:Black Hills of South Dakota

Posted Tue Apr 29, 2014 11:37 PM

 +1!

 

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.

-Ed


Edited by Ed in SoDak, Tue Apr 29, 2014 11:40 PM.


#4 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,079 posts
  • Location:Uzbekistan (no, really!)

Posted Wed Apr 30, 2014 1:04 AM

Just ran the demo program - awesome stuff! :thumbsup:



#5 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,326 posts
  • Location:Eagan, MN, USA

Posted Wed Apr 30, 2014 5:55 AM

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, Wed Apr 30, 2014 5:55 AM.


#6 unhuman OFFLINE  

unhuman

    Stargunner

  • 1,208 posts
  • Location:Vienna, VA

Posted Wed Apr 30, 2014 11:51 AM

This needs tacking on the Development Resources thread!



#7 Gary from OPA OFFLINE  

Gary from OPA

    Moonsweeper

  • 417 posts
  • Location:The World Wide Web

Posted Wed Apr 30, 2014 12:35 PM

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, Wed Apr 30, 2014 12:36 PM.


#8 RXB OFFLINE  

RXB

    River Patroller

  • 3,320 posts
  • Location:Vancouver, Washington, USA

Posted Wed Apr 30, 2014 6:18 PM

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.)

 

 

http://atariage.com/...ment-resources/

 

Look at GPL Section.



#9 RXB OFFLINE  

RXB

    River Patroller

  • 3,320 posts
  • Location:Vancouver, Washington, USA

Posted Wed Apr 30, 2014 6:25 PM

This is a well written package with tools.



#10 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,726 posts
  • Location:Portland, Oregon USA

Posted Wed Apr 30, 2014 6:33 PM

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.)

 

 

http://atariage.com/...ment-resources/

 

Look at GPL Section.

 

Richard,

 

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.  

 

Greg 



#11 slinkeey OFFLINE  

slinkeey

    Dragonstomper

  • 504 posts
  • Not a Gamer
  • Location:Racine, WI

Posted Wed Apr 30, 2014 8:43 PM

I don't recall this place being Anti-GPL.


Edited by slinkeey, Wed Apr 30, 2014 8:51 PM.


#12 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,079 posts
  • Location:Uzbekistan (no, really!)

Posted Thu May 1, 2014 3:11 AM

GPL kicks ass, and RXB is the GPL ass-kicking ninja guru!



#13 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,784 posts

Posted Thu May 1, 2014 5:07 AM

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. . .  :)  :)  :)



#14 awesp OFFLINE  

awesp

    Space Invader

  • 39 posts
  • Location:Sydney, Australia

Posted Sat May 3, 2014 11:16 PM

Thank you very much, Harry, for these great tools!

#15 awesp OFFLINE  

awesp

    Space Invader

  • 39 posts
  • Location:Sydney, Australia

Posted Sun May 4, 2014 3:35 AM

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,

Adam

#16 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,245 posts
  • Location:Lansing, NY, USA

Posted Sun May 4, 2014 6:29 AM

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.



#17 Bones-69 OFFLINE  

Bones-69

    Chopper Commander

  • 206 posts
  • Location:Australia

Posted Sun May 4, 2014 5:20 PM

Amazing Harry. Thank you so much for this contribution.



#18 awesp OFFLINE  

awesp

    Space Invader

  • 39 posts
  • Location:Sydney, Australia

Posted Sun May 4, 2014 7:23 PM

Thanks for your prompt response, Harry.

Kind regards,

Adam

#19 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,245 posts
  • Location:Lansing, NY, USA

Posted Sun May 4, 2014 10:17 PM

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!)

1

Attached Files



#20 hloberg OFFLINE  

hloberg

    Dragonstomper

  • 731 posts
  • Parsec 2600
  • Location:Austin-ish

Posted Mon May 5, 2014 2:19 PM

Tested OK on my CF7. Run old XB256 and the 256DEMO won't load but locks up the computer.

Run your XB256CF7 and the 256DEMO loads and runs fine. 



#21 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,245 posts
  • Location:Lansing, NY, USA

Posted Tue May 6, 2014 10:18 AM

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.



#22 hloberg OFFLINE  

hloberg

    Dragonstomper

  • 731 posts
  • Parsec 2600
  • Location:Austin-ish

Posted Tue May 6, 2014 11:33 AM

  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.

I'll work on it this evening



#23 awesp OFFLINE  

awesp

    Space Invader

  • 39 posts
  • Location:Sydney, Australia

Posted Thu May 8, 2014 10:51 PM

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.

#24 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,245 posts
  • Location:Lansing, NY, USA

Posted Fri May 9, 2014 6:27 AM

 Thanks again for sharing your work with us.

Now how about you sharing some of your work with us!

 

The revised package is coming along nicely.  I need to do some work on the sound list compiler and on the compiler.



#25 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,245 posts
  • Location:Lansing, NY, USA

Posted Sun May 18, 2014 1:00 PM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users