TI BASIC/TI EXTENDED BASIC Games that are worth to be compiled...

[tmop69]

19 minutes ago, senior_falcon said:

Probably the sounds in the original BASIC version have a negative duration. If so just take out the minus sign.

Yes, I've forgot to convert a couple of CALL SOUNDS. That is fixed now.

[tmop69]

18 minutes ago, senior_falcon said:

List the BASIC program and give me an idea where the problem lies. I'll take a look.

Ok, I've found the issue. I added a CALL LINK("SYNC") without adding the :: to separate from the following instruction, that is a NEXT. No error messages from the compiler. 

 

So:

4020 FOR A=1 TO 13 :: CALL POSITION(#1,RO,CO) :: CALL LOCATE(#1,RO,CO-8) :: CALL PATTERN(#1,98+AN) :: AN=-(AN=0) ::CALL LINK("SYNC") NEXT A

instead of the correct:

4020 FOR A=1 TO 13 :: CALL POSITION(#1,RO,CO) :: CALL LOCATE(#1,RO,CO-8) :: CALL PATTERN(#1,98+AN) :: AN=-(AN=0) ::CALL LINK("SYNC"):: NEXT A 

 

Do you need the broken code to check or is supposed to be the right behaviour to not signal the syntax error?

 

[senior_falcon]

5 minutes ago, tmop69 said:

Ok, I've found the issue. I added a CALL LINK("SYNC") without adding the :: to separate from the following instruction, that is a NEXT. No error messages from the compiler. 

 

So:

4020 FOR A=1 TO 13 :: CALL POSITION(#1,RO,CO) :: CALL LOCATE(#1,RO,CO-8) :: CALL PATTERN(#1,98+AN) :: AN=-(AN=0) ::CALL LINK("SYNC") NEXT A

instead of the correct:

4020 FOR A=1 TO 13 :: CALL POSITION(#1,RO,CO) :: CALL LOCATE(#1,RO,CO-8) :: CALL PATTERN(#1,98+AN) :: AN=-(AN=0) ::CALL LINK("SYNC"):: NEXT A 

 

Do you need the broken code to check or is supposed to be the right behaviour to not signal the syntax error?

 

No error checking is done in the compiled code. This makes the compiled code faster. You should do your debugging in XB.

in your example: CALL LINK("SYNC")NEXT A should give the error message FOR-NEXT NESTING IN 4020

[tmop69]

14 minutes ago, senior_falcon said:

No error checking is done in the compiled code. This makes the compiled code faster. You should do your debugging in XB.

in your example: CALL LINK("SYNC")NEXT A should give the error message FOR-NEXT NESTING IN 4020

ok, thanks.

 

I've found another issue with the "Walls and Bridges" program. It was modified with the VDPUTIL2 to be compatible with XB and it's running fine in XB. I've removed the VDPUTIL2 code (basically a SUB VDP routine with some CALL LOAD that do the magic and the initial line that is calling it), saved and compiled. The program hangs after the initial title screen with:

 

Illegal opcode (0331) at address >E41C, Bank >0100, DSR >FFFF
Illegal opcode (0012) at address >06A0, Bank >0100, DSR >FFFF

 

I've checked, but not found anything wrong with the code. In attachment the original file (before the removal of the VDPUTIL2 code) if you want to have a look at it.

 

 

WALLS.zip

[tmop69]

5 hours ago, Tursi said:

Thanks... I played all the way through this time. I noticed that the death sound and game over sounds are missing their delays and end up basically being a "boop" instead of a falling sound. And the win routine is full of similar tight loops, but it crashes after the very first one. (The character is supposed to run down the ladder, run left to the baddie, punch him, advance to the control board (it's a control board), be confused, punch that, and run back right and up the ladder to the girl). All those steps would also have delay loops. Can't say why it crashes.

 

It's still a good effort, I wouldn't be too worried. 

 

(Simple cheat code - just turn all the enemy sprites transparent. Will still die if you fall or walk off the screen. In the Classic99 debugger, enter "v62e=0000000000000000000000000000000000000000000000000000" (52 zeros)). Makes it easier to get through it all.)

Now it should be all ok (I hope). Tested with the cheat code. ? 

 

[GAME] Hero V1.2 (1988)(Mike Brent aka Tursi)[Compiled by TMOP].zip

[senior_falcon]

6 hours ago, tmop69 said:

ok, thanks.

 

I've found another issue with the "Walls and Bridges" program. It was modified with the VDPUTIL2 to be compatible with XB and it's running fine in XB. I've removed the VDPUTIL2 code (basically a SUB VDP routine with some CALL LOAD that do the magic and the initial line that is calling it), saved and compiled. The program hangs after the initial title screen with:

.....

I've checked, but not found anything wrong with the code. In attachment the original file (before the removal of the VDPUTIL2 code) if you want to have a look at it.

 

 

WALLS.zip 7.03 kB · 2 downloads

Once you can take out the VDPUTIL2 code, you can test this in XB by using RXB or XB 2.8 G.E.M. Either one can run TI BASIC programs that use character sets 15 and 16.

You have one error in the code. It is a subtle one which doesn't keep the program from running in XB, but crashes it when compiled.

5040 GOTO 5080

.....

5080 DATA 83,67,79,82,69

 

Compiled code cannot GOTO a DATA statement. Change that line to:

5040 GOTO 5090

 

There is another problem which is a timing issue. In setting up the program it asks for several things and reads the keyboard with CALL KEY.

2810 CALL KEY(3,X,S)
2820 IF S=0 THEN 2810

It is not enough to check that a key is pressed. The compiled code inputs keystrokes too fast. You need to check for a new key. IF S<1 THEN 2810 will do the trick.

There are several other places where you need to do this.

 

[Omega-TI]

B-1 Bomber is one game I've always liked that I thought would be cool compiled and turned into a cartridge BIN, but with its current display output, it would be uninspiring to most people.  I've always had plans to update it, be never seemed to find the time, and or course it would look much better in 80 column format, but T80XB does not yet compile.  Maybe in another 10 years when I retire I'll have the time, and the software to do everything I want will be at hand.  We'll see.

[tmop69]

8 hours ago, senior_falcon said:

Once you can take out the VDPUTIL2 code, you can test this in XB by using RXB or XB 2.8 G.E.M. Either one can run TI BASIC programs that use character sets 15 and 16.

You have one error in the code. It is a subtle one which doesn't keep the program from running in XB, but crashes it when compiled.

5040 GOTO 5080

.....

5080 DATA 83,67,79,82,69

 

Compiled code cannot GOTO a DATA statement. Change that line to:

5040 GOTO 5090

 

There is another problem which is a timing issue. In setting up the program it asks for several things and reads the keyboard with CALL KEY.

2810 CALL KEY(3,X,S)
2820 IF S=0 THEN 2810

It is not enough to check that a key is pressed. The compiled code inputs keystrokes too fast. You need to check for a new key. IF S<1 THEN 2810 will do the trick.

There are several other places where you need to do this.

 

Many thanks! I'll try again fixing this. Maybe the GOTO to a DATA statement is the same problem that crashed a couple of other games. I'll check an let you know.

 

 

[tmop69]

Another game compiled. It's "MANIA", an adventure from Intrigue.

 

I'm not a fan of text adventures (expecially in 2020...), but I guess some other guys here will like it. And now it's fast...

 

[GAME] Mania (1983)(Intrigue Software)[Compiled by TMOP].zip

[Tursi]

15 hours ago, tmop69 said:

Now it should be all ok (I hope). Tested with the cheat code. ? 

Haha, looks like it! Thanks

[tmop69]

After "MANIA", it's predecessor "Adventuremania".

[GAME] Adventuremania (1983)(Intrigue Software)[Compiled by TMOP].zip

[tmop69]

"Castello Notte Oscura" is a nice RPG game, published by TI99 NewSoft in 1985, that I've received requests for a compiled version.  It's in Italian only. Any volunteer for the translation in English?

[GAME] Castello Notte Oscura (1985)(TI99 NewSoft)[Compiled by TMOP].zip

[whoami999ster]

Google translate is miracolous

[blackbox]

Sorry for the delay- slowly rebuilding the PC and there are gaps when I try to resolve something.

Here is a reworked Zarquon for pure TIB and a reworked ZARQUON/I instruction file.  Quite a hard one- and it is sensitive to the alpha lock key.  It probably needs quite a bit of timing adjustments in places.

  I also added Tickworld to the disk as that is a game I used to play that could do with a bit more speed.

Interesting the compiling is more sensitive to untidy programming than pure basic - it has always been a complaint of basic that it encouraged poor programming habits!  Many TI games suffered from ad hoc code removal to make them fit and code remnants and orphan lines were often left in place.

zarquon.dsk

Edited September 27, 2020 by blackbox

[senior_falcon]

For what it's worth, you have the ability to use the original runtime routines if you are compiling a TI BASIC program. From page 17 of the manual:

 

USING RUNTIME ROUTINES FROM THE ORIGINAL COMPILER

If your program is written in TI BASIC you can now use the runtime routines that were part of the original TI BASIC compiler. The advantage is that the program created is considerably smaller, plus it may run a bit faster due to less overhead in the interrupt routine. The big disadvantage is that it only supports TI BASIC instructions (with a few additions from XB), and there have been no improvements for many years.

Most users will not want to use this, so it is turned off by default. To enable this option type:
     OLD DSK1.COMPILER
     uncomment line 230
     SAVE DSK1.COMPILER
Now when the compiler runs you can press “Y” when prompted “Use TI BASIC runtime?” Default for this prompt is always “N”.

The procedure for compiling a program is identical to the current version described above and in Using XBGDP. The limitations of this earlier compiler are described below, taken verbatim from the original manual. Do not put the runtime routines in low memory!

[tmop69]

Ok, so now a really nice game from Adam Haase: "Quest".

 

All the 8 levels are loaded at ultra fast speed, no more disk access, all is packed in the SSS. The hero and enemies are moving fast! I like the new action/arcade gameplay gained by the extra speed.

[GAME] Quest (19xx)(Adam Haase)[Compiled by TMOP].zip

[tmop69]

On 9/27/2020 at 11:55 AM, blackbox said:

Sorry for the delay- slowly rebuilding the PC and there are gaps when I try to resolve something.

Here is a reworked Zarquon for pure TIB and a reworked ZARQUON/I instruction file.  Quite a hard one- and it is sensitive to the alpha lock key.  It probably needs quite a bit of timing adjustments in places.

  I also added Tickworld to the disk as that is a game I used to play that could do with a bit more speed.

Interesting the compiling is more sensitive to untidy programming than pure basic - it has always been a complaint of basic that it encouraged poor programming habits!  Many TI games suffered from ad hoc code removal to make them fit and code remnants and orphan lines were often left in place.

zarquon.dsk 90 kB · 11 downloads

 

Here is Tickworld. Unfortunately this game is coded in a way that it hasn't received a great benefit from the compilation. There is the need to add some frames of delay to show the various animations, so it's not fast. Anyway, it's surely better than the BASIC version and the startup phase (char definition, etc.) it's no more slow. Let me know, since you have played it a lot.

 

[GAME] Tick World (19xx)(Not Polyoptics)[Compiled by TMOP].zip

[tmop69]

On 9/27/2020 at 11:55 AM, blackbox said:

Sorry for the delay- slowly rebuilding the PC and there are gaps when I try to resolve something.

Here is a reworked Zarquon for pure TIB and a reworked ZARQUON/I instruction file.  Quite a hard one- and it is sensitive to the alpha lock key.  It probably needs quite a bit of timing adjustments in places.

  I also added Tickworld to the disk as that is a game I used to play that could do with a bit more speed.

Interesting the compiling is more sensitive to untidy programming than pure basic - it has always been a complaint of basic that it encouraged poor programming habits!  Many TI games suffered from ad hoc code removal to make them fit and code remnants and orphan lines were often left in place.

zarquon.dsk 90 kB · 13 downloads

 

And here we have the Walls and Bridges. It should have all the needed delays in the appropriate parts of the code, but please try it and let me know if something needs to be fixed, since I've not read the instructions and so I was not able to complete a full game. 

 

Thanks to senior_falcon for finding the problem with the crash.

 

 

[GAME] Walls and Bridges (1983)(Timagination)[Compiled by TMOP].zip

[blackbox]

Many thanks, Tickworld plays a treat - slightly harder. With one life the games can be quite short and rapid, the random spread of trees means you can think quickly for a different strategy each game.  At least I managed to trap a tick in a net and then before it escaped the net, throw it in a cage.   The instructions within the game are slightly easier to follow than the original printed docs.

You avoid having a tick catch you.  You have nets to throw (key T) and wait for a tick to walk into them. The nets appear above you.  Once a tick is caught go under the net and press T, move to a cage and move over it. Tick in cage.  Ticks left in nets will escape.  Ticks in nets can be carried (T).

This was a very early TI Basic game, written for the original TI99/4.

Many of these games by Not Polyoptics are simple but quite playable even today.  Thanks! 
 

[tmop69]

18 minutes ago, blackbox said:

Many thanks, Tickworld plays a treat - slightly harder. With one life the games can be quite short and rapid, the random spread of trees means you can think quickly for a different strategy each game.  At least I managed to trap a tick in a net and then before it escaped the net, throw it in a cage.   The instructions within the game are slightly easier to follow than the original printed docs.

You avoid having a tick catch you.  You have nets to throw (key T) and wait for a tick to walk into them. The nets appear above you.  Once a tick is caught go under the net and press T, move to a cage and move over it. Tick in cage.  Ticks left in nets will escape.  Ticks in nets can be carried (T).

This was a very early TI Basic game, written for the original TI99/4.

Many of these games by Not Polyoptics are simple but quite playable even today.  Thanks! 
 

In general with additional speed there is an increase of difficulty, but this also increases the longevity of the game. ?  TI BASIC is slow, so there are no choices at the time in which the game was designed. There are some interesting BASIC games that can be definitively better now with the extra speed provided by compilation.

 

 

[ti99iuc]

@senior_falcon maybe could you also have an idea to fix also Robopods (http://www.ti99iuc.it/web/download.php?fn=_archivio/252/download/(Eng)-(Game)-(Robopods)-(1983)-(B)-(by_Malcom_Adams)_-_(from_Virgin_Games).zip) game because once compiled it create a bug during the gameplay?

[senior_falcon]

This program uses DEF which is not supported by the compiler.

30 DEF RN(Y)=INT((Y-2)*RND)+3

RN(Y) is used in 7 lines: 820,830,1320,1330,2200,2260,2270

 

Probably the easiest way around this is:

820 R=RN(17)    can become      820 R=INT(15*RND)+3     
830 C=RN(28)    can become      830 C=INT(26*RND)+3     

and so on for the other 5 lines.       

 

I think you could do it with GOSUB, but I think that's more complex.

 

I can't see any practical way to add DEF to the compiler.

 

I think this will fix your problems, but didn't look any further so perhaps there are other issues.

 

 

Edited October 1, 2020 by senior_falcon

[tmop69]

5 hours ago, senior_falcon said:

This program uses DEF which is not supported by the compiler.

30 DEF RN(Y)=INT((Y-2)*RND)+3

RN(Y) is used in 7 lines: 820,830,1320,1330,2200,2260,2270

 

Probably the easiest way around this is:

820 R=RN(17)    can become      820 R=INT(15*RND)+3     
830 C=RN(28)    can become      830 C=INT(26*RND)+3     

and so on for the other 5 lines.       

 

I think you could do it with GOSUB, but I think that's more complex.

 

I can't see any practical way to add DEF to the compiler.

 

I think this will fix your problems, but didn't look any further so perhaps there are other issues.

 

 

The DEF was remapped correctly, hovewer, that's not the problem.

 

This is the strange behaviour: when you deactivated a Robopod (e.g. the #1), its number is then showed in the next one you have to deactivate (with an anim) instead of the correct one (for the example the #2).

 

The correct sequence is: I deactivate Robopod #1, an anim with the #1 disappearing is showed, I can proceed to deactivate Robopod with #2.

Instead, in compiled version the sequence is: I deactivate Robopod #1, an anim with the #1 disappearing is showed, now ad anim is then showed on Robopod #2 that is changing the #2 with #1. The same with the following Robopods (at any step the # is increased). You can complete the game, although is a little confusing.

 

I've tried to fix the issed, but without success. It seems that there is an uncorrect jump to the fade-our routine. The code was working correctly in BASIC.

 

In attachment the FIAD of the modified source used for the compilation (with appropriate delays).

 

 

Robopods.zip

[senior_falcon]

This is what I see in the BASIC version. The version in the video is the one that uses the DEFs.

This matches your description of the faulty behavior in the compiled version. If so then the compiled code is just duplicating the BASIC code.

!

Edited October 1, 2020 by senior_falcon

[tmop69]

20 minutes ago, senior_falcon said:

This is what I see in the BASIC version. The version in the video is the one that uses the DEFs.

This matches your description of the faulty behavior in the compiled version. If so then the compiled code is just duplicating the BASIC code.

!

 

I need to check again. There a various versions floating around. I've checked them with a file compare tool, but seems identical. Need to try with the original tape version.