geneve 9640 Clear for Action ported to Geneve

[+hloberg]

UPDATE: DEBUGGED VERSION C10A AS DOWNLOAD

has version for DSK1 and if you have Geneve MAME package download from my site https://ti99resources.wordpress.com/emulation/

you can just replace the SOFTWARE files with the new SOFTWARE files and execute ABGAMES at the Geneve prompt for the menu to run CFA,

-------------------------------------------------------------

'Clear for Action in the age of Sailing'  is a game of strategy pitting you against the computer in a pitched naval battle in the age of the great sail battleships of the 18th century. Originally ported to the TI-99 by Walid Maalouli from the TRS-80 I have now ported thst 99 version over to the Geneve. This is a really terrific program and I have made some modifications to better run on the Geneve and take advantage of it's features.

The program is now one large program. Malllouli had to break up the program to get it fit on the 99, on the Geneve there is more than enough memory to fir the whole program at once. Also switched some of the menus to 80 column and added more info in the program.

I have the program on the disk to run from a HD. to change to run from disk change the variable on line 100 to the default SAVEFILE area.

enjoy

 

CFA10a-UPDATED.zip

[+Vorticon]

That is awesome! Wish I had a Geneve on hand! 

I'll have to check it out in MESS.

I have to say that the original program is a classic rat's nest which I coded directly in the XB environment. No TICodEd back then sadly. I'm surprised you managed to make sense of it

Thanks for doing this.

[+Vorticon]

Would it be possible to post a short video of the action? 

[+mizapf]

Here is a hard disk image for MAME; the program is located in E:\BASIC\ABASIC4, and the line 100 has been edited accordingly.

 

mame geneve -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -hard1 genhd01.hd

 

After booting, do a CD BASIC\ABASIC4, then enter ABASIC1. When ABASIC has completed loading, enter OLD E:C9, then RUN. Check that you are using uppercase in the game (press the key that is mapped to CapsLock, maybe CapsLock itself will do).

 

I tried it, but I got an error message BAD SUBSCRIPT IN 5540 after some time.

genhd01.hd

Break is F4; leave ABASIC with BYE.

[+hloberg]

1 hour ago, mizapf said:

Here is a hard disk image for MAME; the program is located in E:\BASIC\ABASIC4, and the line 100 has been edited accordingly.

 

mame geneve -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -hard1 genhd01.hd

 

After booting, do a CD BASIC\ABASIC4, then enter ABASIC1. When ABASIC has completed loading, enter OLD E:C9, then RUN. Check that you are using uppercase in the game (press the key that is mapped to CapsLock, maybe CapsLock itself will do).

 

I tried it, but I got an error message BAD SUBSCRIPT IN 5540 after some time.

genhd01.hd 1.11 MB · 3 downloads

Break is F4; leave ABASIC with BYE.

DOH!

I fixed that problem but forgot to post the fixed version.

simple: change line 90 from OPTION  BASE 1 to OPTION BASE 0.

the problem only seems to come up when you create your own ships. if you use the built in scenarios it doesn't happen. for some reason PSAIL(CAL) is being set to 0 when you create your own scenarios. I spent a few hours trying to figure out why and was never able to track it down. but change the option base to 0 and the problem goes away. It also doesn't seem to effect the play, that I was able to see. 

HLO

[+Vorticon]

Just tried it in MESS under Linux and it's quite a faithful recreation. There is however an issue with the calculated distance between ships: It seems to increase instead of decrease as they get closer which obviously affects gun range.

[+hloberg]

1 hour ago, Vorticon said:

Just tried it in MESS under Linux and it's quite a faithful recreation. There is however an issue with the calculated distance between ships: It seems to increase instead of decrease as they get closer which obviously affects gun range.

hum. I guess my unfamiliarity with how the program supposed to work starting to show. I just thought I was a bad shot why I couldn't land a cannon ball. 

well, looks like v10 + is coming up.

by the way, does that happen with the built in scenarios or/and the created ones? 

[+Vorticon]

I just tried one of the built-in scenarios.

[+Vorticon]

Here's the manual by the way.

cfa.zip

[+hloberg]

and another lesson learned, don't post something at 2am when your half asleep. 🙄

looking back at it I shouldn't caught that error.

[+mizapf]

The subscript error also happened when loading the scenario from SAVEFILE, but it is solved by the option base 0 setting.

Stopping the program is done by CTRL-C, not F4, as I said above.

 

@InsaneMultitaskerDid ABASIC always offer international characters (when you go through CTRL-a, ...), or is that a newer GeneveOS feature? By the way, seems as if the ß (eszett) is missing.

[+InsaneMultitasker]

2 hours ago, mizapf said:

@InsaneMultitaskerDid ABASIC always offer international characters (when you go through CTRL-a, ...), or is that a newer GeneveOS feature? By the way, seems as if the ß (eszett) is missing.

This is a side-benefit of the IBM Graphics implementation. I believe that Geneve OS 7.30 enabled the definitions for characters 128-255, by default.  Characters 0-31 may also be defined by default, though I would have to check to be sure. (The OS command line does not allow display of characters 0-31 at this time since many of the codes also have specific formatting functions; with the ANSI XOP, they should technically be available).

 

The eszett and a few other character(s) may or may not be differently defined as a result of the logo that was added to the OS version display.  @9640News see Michael's comment as we may want to consider adjusting the logo characters or forcing a redefinition with a command.  EDIT: I will post in the Geneve OS dev topic, as I have some uncertainty about the character sets.

[+hloberg]

I found the error with needing OPTION 0. I accidentally deleted part of a line. creating scenarios now works. 

BUT, there is something weird going on with the CALL DISTANCE command. It 'looks' like it just keeps increasing the distance no matter what. I'm going to run a few more test.

[+Vorticon]

20 minutes ago, hloberg said:

I found the error with needing OPTION 0. I accidentally deleted part of a line. creating scenarios now works. 

BUT, there is something weird going on with the CALL DISTANCE command. It 'looks' like it just keeps increasing the distance no matter what. I'm going to run a few more test.

Perhaps there is a sign inversion somewhere.

[+hloberg]

it looks as if CALL DISTANCE in Advanced BASIC is defective. sigh. It just keeps increasing the distance value no matter what.

 

[+InsaneMultitasker]

3 hours ago, hloberg said:

it looks as if CALL DISTANCE in Advanced BASIC is defective. sigh. It just keeps increasing the distance value no matter what.

 

Could you write a very short program that demonstrates the increasing distance error in ABASIC but works properly in standard XB?  Does the error occur with the distance between two spites, distance between a sprite and a fixed point, or both? 

 

Update: I had a few minutes before I needed to run some errands. This code shows a definite error in ABASIC or the MDOS XOP.  I will PM you.

 

1 !SAVE DSK8.SPRITE2
5 CALL CLEAR
20 CALL VERSION(A) :: IF A=110 THEN 100
30 CALL GRAPHICS(1,1)
100 CALL SPRITE(#1,65,16,50,50,5,0)
105 CALL SPRITE(#2,67,7,30,30,5,0)
110 CALL DISTANCE(#2,#1,F)
115 CALL DISTANCE(#2,1,1,G)
120 DISPLAY AT(24,5):F;G
130 GOTO 110
 

[+hloberg]

2 hours ago, InsaneMultitasker said:

Could you write a very short program that demonstrates the increasing distance error in ABASIC but works properly in standard XB?  Does the error occur with the distance between two spites, distance between a sprite and a fixed point, or both? 

 

Update: I had a few minutes before I needed to run some errands. This code shows a definite error in ABASIC or the MDOS XOP.  I will PM you.

 

1 !SAVE DSK8.SPRITE2
5 CALL CLEAR
20 CALL VERSION(A) :: IF A=110 THEN 100
30 CALL GRAPHICS(1,1)
100 CALL SPRITE(#1,65,16,50,50,5,0)
105 CALL SPRITE(#2,67,7,30,30,5,0)
110 CALL DISTANCE(#2,#1,F)
115 CALL DISTANCE(#2,1,1,G)
120 DISPLAY AT(24,5):F;G
130 GOTO 110
 

copy that

[+mizapf]

I tried it in ABASIC3, 4, and Extended Basic (on MAME), and both ABASICs behave the same way, Extended Basic is different. It seems as if DISTANCE returns  x²+y² (without sqr), because the rate accelerates towards the bottom. The distance between the sprites (left number) is almost constant in Extended Basic but rising in ABASIC. The distance from (1,1) (right number) is rising with all BASICs, but even here, ABASIC delivers a higher value than Extended Basic.

[+InsaneMultitasker]

2 hours ago, mizapf said:

I tried it in ABASIC3, 4, and Extended Basic (on MAME), and both ABASICs behave the same way, Extended Basic is different. It seems as if DISTANCE returns  x²+y² (without sqr), because the rate accelerates towards the bottom. The distance between the sprites (left number) is almost constant in Extended Basic but rising in ABASIC. The distance from (1,1) (right number) is rising with all BASICs, but even here, ABASIC delivers a higher value than Extended Basic.

I believe that either ABASIC or the OS is incorrectly calculating the sprite number or VRAM address of the sprite table. I can get the distance of sprite #1 by checking sprite #2.

 

100 CALL SPRITE(#1,65,2,50,50,0,5) !create sprite #1 at 50,50 with motion along one axis

110 CALL DISTANCE(#1,50,50,R) !R will not change

120 CALL DISTANCE(#2,50,50,F) !F will change even though there is no sprite #2 defined or in motion

130 DISPLAY AT(24,1):R;F

140 GOTO 110

When F reaches 32,400 the interpreter pauses twice, most likely a vram and/or calculation overflow. 

[+Vorticon]

Is this fixable?

[+mizapf]

18 minutes ago, InsaneMultitasker said:

I believe that either ABASIC or the OS is incorrectly calculating the sprite number or VRAM address of the sprite table.

We could write the test program in TIC to check what is wrong. It's unlikely that the TICLIB has the same problem as ABASIC, unless the issue is deeper.

[+hloberg]

1 hour ago, Vorticon said:

Is this fixable?

I can use a math formula and hold the locations in variables to get the  same results for the DIST without using the CALL DISTANCE, that is, when I figure out what the formula is for getting the distance the same way as CALL DISTANCE .

Also were looking at the ABASIC code to fix CALL DISTANCE but  that could take some time.

But, yes, it is eventually fixable.

 

[+hloberg]

3 hours ago, mizapf said:

We could write the test program in TIC to check what is wrong. It's unlikely that the TICLIB has the same problem as ABASIC, unless the issue is deeper.

ABASIC was somewhat based on MyArc Extended BASIC II. I think I'm going to pull that out and see if get the same error.

you know, it's funny this bug has never revealed it's self before now. I guess CALL DISTANCE isn't used very much.

EDIT: MyXBII works correctly.

[+Vorticon]

13 hours ago, hloberg said:

I can use a math formula and hold the locations in variables to get the  same results for the DIST without using the CALL DISTANCE, that is, when I figure out what the formula is for getting the distance the same way as CALL DISTANCE .

Also were looking at the ABASIC code to fix CALL DISTANCE but  that could take some time.

But, yes, it is eventually fixable.

 

Well one way is to do a CALL POSITION (or equivalent in ABASIC) for each of the ship sprites and simply use the formula DIST=SQR((X1-X2)² + (Y1-Y2)²). This will give you a distance in pixels. Since the game field has a resolution of 1600m in both the X and Y coordinates and spans 22 characters per side, this should give us a conversion factor of 1600/(22*8)=9.1. In other words, 1 pixel is 9.1 meters.

[+hloberg]

2 hours ago, Vorticon said:

Well one way is to do a CALL POSITION (or equivalent in ABASIC) for each of the ship sprites and simply use the formula DIST=SQR((X1-X2)² + (Y1-Y2)²). This will give you a distance in pixels. Since the game field has a resolution of 1600m in both the X and Y coordinates and spans 22 characters per side, this should give us a conversion factor of 1600/(22*8)=9.1. In other words, 1 pixel is 9.1 meters.

thanks. that should work.

I plan to play the heck out this game (and not in the middle of the night ) to check for any other issues before I release v10. so expect the fixed version when you see it.

HLO