Jump to content

Photo

XB Game Developers Package


228 replies to this topic

#226 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Sun May 27, 2018 2:06 PM

Oops, I left out a file. ENCRUZADO_BETA1.ZIP has been posted and is the one to download. Also, when you are setting XBGDP be sure DSK1 uses ENCRUZADO_BETA1.


Edited by senior_falcon, Sun May 27, 2018 2:13 PM.


#227 LASooner OFFLINE  

LASooner

    Moonsweeper

  • 281 posts

Posted Sun May 27, 2018 4:26 PM

 

 
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.
 

 

 

 

woah, awesome new feature Harry!



#228 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Wed May 30, 2018 8:22 PM

It seems that any change, no matter how slight, has unanticipated negative consequences. Here is a bug that got through my testing and it was a real pain in the buttocks to figure out. First the problem:

The compiler uses cpu memory from >FFE8 to >FFFF as a mailbox so the various components can communicate with each other.  Filename, the next position in the menu, where to find the runtime routines, and a few others are kept there. Also, there is a byte that tells the compiler which of the runtime routines (1-7) should be loaded. This used to be in low memory. In making it possible to move the runtime routines to low memory, this had to go someplace else and >FFFF seemed safe enough. Absolutely no problem if you put the runtime routines in high memory as usual. If you have a large program and want to put them in low memory to free up room, you have to leave XB and plug in the MiniMemory cartridge. Doing that zeroes out cpu memory. No problem, the compiler saves the 24 bytes in the mailbox to a disk file. When the TI BASIC compiler loader runs in MiniMemory, it reads the disk file into MB$ to find out the contents of the mailbox. Simple enough, except that BASIC only allows INPUT. It does not allow LINPUT. Most of the time this works fine, but when the last byte is >1F it is not included in MB$ and now MB$ is only 23 bytes long. Why does that matter? Because I got clever with one of the assembly language support routines which reads that string and uses the length to decide what to do. If it's 24 bytes long it does one thing, if less than 24 bytes then it does a different operation. Although it doesn't crash, it gives a garbled prompt for the filename. That only took 2 hours to figure out!

 

Here's the fix:

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) The only time this bug shows up is when you compile a program that uses XB256 and the "Star Wars scroll", no CHSETD and no disk access.

Edited by senior_falcon, Thu May 31, 2018 5:04 AM.


#229 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Tue Jun 5, 2018 8:27 PM

 Here is the newest revision of the XB Game Developer's Package "Encruzado". As noted above, a few bugs were found and squashed and now this should be ready for prime time.
 
COMPILER: The big change is that you now have an option to put the runtime routines into low memory from >2000 to >3FFF.  This is 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.
 
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. 
 
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)-Remember that if you will be compiling a program, then RESTORE must point to a DATA statement, not to a REM before the DATA. The section discussing the COMPRESS utility was not clear about this.

Attached Files


Edited by senior_falcon, Wed Jun 6, 2018 7:09 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users