XB Game Developers Package

[Opry99er]

^^sounds delicious^^

 

 

[LASooner]

The other nice aspect of compiling is that it is self contained, you don't have to first run XB256, then run your program. I think that's why there isn't the motivation to release it as a straight XB.

 

it just makes it a cleaner presentation to run an E/A file or ROM bin.

[senior_falcon]

The other nice aspect of compiling is that it is self contained, you don't have to first run XB256, then run your program. I think that's why there isn't the motivation to release it as a straight XB.

 

it just makes it a cleaner presentation to run an E/A file or ROM bin.

Good point! I'm still living in the past, so being able to put it in cartridge form is not something that would occur to me.

[LASooner]

maybe a redistributable loader version of XB256 you could put on a disk image to launch your program.

 

What I imagine it would do is allow you to define which XB file you want to launch and it would create a LOAD file you put on your disk to auto execute when you select Extended Basic, start XB256, show a splash screen to get your due, then launch the defined XB256 program. Then you'd definitely know what programs make use of XB256

 

I really dig what you've done so far, I was planning on writing up a tutorial on how I use the compressed data during development.

 

And one day I hope to actually finish a program.

 

[senior_falcon]

I see the manual is not 100% current. Here's what should be at the top of page 26:

 

You may develop a program where you want to have XB256 load automatically and then

load and run your program or even a chain of programs. The first part is easy. First load XB256:

Select XB256 from the menu or type OLD DSKn.XB256. To automatically run a program, change line 10 to:

5 !XB256 “Amontillado” H. Wilhelm 2017 Free distribution only

10 CALL INIT :: CALL LOAD(8192,255,154):: CALL LINK("X")::

CALL LINK("XB256"):: RUN "DSKn.PROGNAME"

(not XB256A - you don't want to use autoprompt)

Then save as LOAD, but be sure not to overwrite LOAD on the XBGDP disk.

Also read the discussion about IV254 that follows

(I wonder what else I have forgotten?)

[senior_falcon]

Sorry to report that a bug was discovered in the new IF-THEN-ELSE routines.

10 IF X=7 THEN 100 works

10 IF X=7 THEN 100 ELSE 200 works

10 IF X=7 THEN Y=12::GOSUB 100 ELSE Y=16::GOSUB 200 works

10 IF X=7 THEN 100::Y=12::Z=23 does not work - it expects an ELSE

 

And I thought I had tested all the possibilities.................

 

As long as you use ELSE it works fine. Meanwhile, the problem has been identified and a repaired version will be released soon

[LASooner]

 

From the XB manual:

100 IF X>5 THEN GOSUB 300 ELSE X=X+5

100 IF Z THEN C=C+1::GOTO 500::ELSE L=L/C::GOTO 300

All should compile and run properly

Also,

100 IF X=3 THEN IF Y=1 THEN IF Z=4 THEN PRINT "PI"

This too works fine, but you might as well just use AND: 10 IF X=3 AND Y=1 AND Z=4 THEN PRINT "PI" ELSE PRINT "NOT PI"

 

I missed the last half of this the first time,

 

10 IF X=3 AND Y=1 AND Z=4 THEN PRINT "PI" ELSE PRINT "NOT PI"

 

are you saying would compile fine with the new version? So we can use AND in our IF/THEN statements?

[senior_falcon]

Yep, that line works the same in XB and when compiled.

[senior_falcon]

OK, here's one for the experts. I have added a subroutine called SYNC to XB256 and the compiler. The idea is to introduce a delay in a loop so that the loop takes a known amount of time. Here is the XB program to test it:

10 CALL LOAD(-1,60)
20 FOR C=1 TO 32 :: CALL HCHAR(10,C,42):: CALL LINK("SYNC"):: NEXT C

Here's the subroutine:

SYNC	CB @>8379,@-1
	JHE SYNC1
	LIMI 2
	LIMI 0
	JMP SYNC
SYNC1	MOVB @>0038,@>8379	moves a zero byte to >8379
	B @>006A

My understanding is that if you set up a loop with nothing but LIMI 2 and LIMI 0 that the VDP interrupt timer at >8379 will be incremented every 1/60 second. If that is true then the XB program will HCHAR another asterisk once a second.

But it prints an asterisk every half second - i.e. twice as fast as I think it should. What am I missing?

 

 

 

 

 

 

 

 

[+Lee Stewart]

OK, here's one for the experts. I have added a subroutine called SYNC to XB256 and the compiler. The idea is to introduce a delay in a loop so that the loop takes a known amount of time. Here is the XB program to test it:

10 CALL LOAD(-1,60)
20 FOR C=1 TO 32 :: CALL HCHAR(10,C,42):: CALL LINK("SYNC"):: NEXT C

Here's the subroutine:

SYNC	CB @>8379,@-1
	JHE SYNC1
	LIMI 2
	LIMI 0
	JMP SYNC
SYNC1	MOVB @>0038,@>8379	moves a zero byte to >8379
	B @>006A

My understanding is that if you set up a loop with nothing but LIMI 2 and LIMI 0 that the VDP interrupt timer at >8379 will be incremented every 1/60 second. If that is true then the XB program will HCHAR another asterisk once a second.

But it prints an asterisk every half second - i.e. twice as fast as I think it should. What am I missing?

 

What makes you think the value in >8379 is 0 when you start SYNC? Should you not set it to 0 at the beginning of SYNC instead of at the end? Are not interrupts enabled part/most of the time in XB?

 

...lee

[senior_falcon]

 

What makes you think the value in >8379 is 0 when you start SYNC? Should you not set it to 0 at the beginning of SYNC instead of at the end? Are not interrupts enabled part/most of the time in XB?

 

...lee

True, it isn't zero the first time through the loop but after the first time it is set to zero. It is likely to be greater than the value placed at >FFFF by line 10,so the first loop would be fast but after that the timer should work right. Because the interrupts are enabled in XB, the time spend in the XB or compiled program is taken into account. In the above example, if the program spend 1/2 second running the XB code it would then spend another 1/2 second in the SYNC loop. Of course this assumes 60 ticks of the clock per second, which brings me back to the question - why does the clock run twice as fast as I think it should?

[senior_falcon]

Boy do I feel dumb. The value at >0038 is NOT zero. It is >1E which happens to be 30 decimal which naturally make the clock want to run twice as fast. The code should have been >0039 which actually is zero.

[Airshack]

Good point! I'm still living in the past, so being able to put it in cartridge form is not something that would occur to me.

 

Hi Falconator,

 

Last year I asked you about FlashROM which you hadn't used. Just wondering if you've seen/used the FinalGROM?

 

LA Sooner makes a great point here: "The other nice aspect of compiling is that it is self contained, you don't have to first run XB256, then run your program. I think that's why there isn't the motivation to release it as a straight XB.

it just makes it a cleaner presentation to run an E/A file or ROM bin."

Many of us are using FlashROM and.or FinalGrom99 to load our games. Way easier and less cumbersome than the p.26 methodology of first loading XB256, etc....

This makes things much easier for an emulator user/game player as well... my two cents.

[+Lee Stewart]

Boy do I feel dumb. The value at >0038 is NOT zero. It is >1E which happens to be 30 decimal which naturally make the clock want to run twice as fast. The code should have been >0039 which actually is zero.

 

Hey—the hardest errors to correct are the ones you know you didn’t make. Happens to me all the time!

 

...lee

[senior_falcon]

 

Hi Falconator,

 

Last year I asked you about FlashROM which you hadn't used. Just wondering if you've seen/used the FinalGROM?

 

LA Sooner makes a great point here: "The other nice aspect of compiling is that it is self contained, you don't have to first run XB256, then run your program. I think that's why there isn't the motivation to release it as a straight XB.

it just makes it a cleaner presentation to run an E/A file or ROM bin."

Many of us are using FlashROM and.or FinalGrom99 to load our games. Way easier and less cumbersome than the p.26 methodology of first loading XB256, etc....

This makes things much easier for an emulator user/game player as well... my two cents.

Running in XB rather than compiled has some advantages for large games where speed is not an issue. For example, you could have a large adventure game that uses many program segments. Using XB256 you would have no trouble loading the segments and running them from XB. This would make it possible to have a large adventure way more than 24K long and with fancy graphics to boot. Put it all on a disk, put it in disk one and have it autoload and start XB256 and then the initial segment of the program. "Who's behind the Mexican UFO's?" comes to mind, although that used Missing Link and bit mapped graphics.

 

I have not seen or used FinalGrom99 or FlashROM.

Edited February 20, 2018 by senior_falcon

[Airshack]

“Running in XB rather than compiled has some advantages for large games where speed is not an issue.”

 

If speed is not an issue why bother compiling?

Edited February 20, 2018 by Airshack

[Sinphaltimus]

“Running in XB rather than compiled has some advantages for large games where speed is not an issue.”

 

If speed is not an issue why bother compiling?

"Load times" - Speed, is always an issue.

[Bones-69]

Running in XB rather than compiled has some advantages for large games where speed is not an issue. For example, you could have a large adventure game that uses.....

 

I love this idea. Screen 1 could be used for text and Screen 2 could have all the pretty graphics, or maps, or some other graphical interface with all the flexibility/convenience of the extra XB256 character sets. Added to my "future project list"!

[LASooner]

Point to remember is sprite data is the screen 1 character set, so if you have sprites in your game, screen 1 would be affected. You'll need to restore the character definitions before going back to screen 1. The good news is if you use compressed VDP data it doesn't take that long to do that.

[senior_falcon]

 

I love this idea. Screen 1 could be used for text and Screen 2 could have all the pretty graphics, or maps, or some other graphical interface with all the flexibility/convenience of the extra XB256 character sets. Added to my "future project list"!

To XB256 I have added the ability to load and run IV254 programs. There are two ways to do it. CALL LINK ("RUN","DSK1.FILE") will let your XB program run another XB program using a string variable or constant. CALL LINK("RUNL1","DSK1.FILE") will load an IV254 program and run starting at line 1 with a major difference. The program starts immediately after loading; all the variables are preserved and no time is spent on prescan. XB does not know that a new program has been loaded and is tricked into going to line #1. Instead of writing a number of stand alone programs, you can write one very large program and break it into sections small enough for XB to load. The thread "Extra large programs spanning multiple files" has more information about this.

"Chardonnay" should be ready in a few days.

[Bones-69]

I am totally digging this concept even for a typical arcade style game. Comes to mind that one could write a dedicated program where all variables are initialised, characters defined, perhaps with a fancy graphical loading page.... Then without penalty to the available programming space in order to get to this point, the main program could then be seamlessly launched. I know my current project which reads all variables off disk still uses up 1600 bytes of programming space just for the initialisation routines. In my example it would be great to claw back some of this precious space.

[senior_falcon]

I am totally digging this concept even for a typical arcade style game. Comes to mind that one could write a dedicated program where all variables are initialised, characters defined, perhaps with a fancy graphical loading page.... Then without penalty to the available programming space in order to get to this point, the main program could then be seamlessly launched. I know my current project which reads all variables off disk still uses up 1600 bytes of programming space just for the initialisation routines. In my example it would be great to claw back some of this precious space.

Remember that you cannot chain compiled programs; they must run as independent units. You would be using this in XB, which makes a fast action arcade style game challenging to say the least.

Actually you can chain compiled programs but only if running in XB. When a compiled program ends program control returns to XB. If the next line in the loader is 20 RUN "DSK1.CPROG2" then CPROG2 would load and run. But character definitions would get reset and the screen would be cleared.

[Bones-69]

Can't chain compiled programs, Got it!

[LASooner]

That's why slow moving adventure games would be a good candidate for this. Time to find an old "Choose Your Own Adventure" book and turn it into a game.

[senior_falcon]

Here is the XB Game Developers Package "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.

XBGDPchardonnay.zip