Mille Borne in Applesoft BASIC

[+hloberg]

UPDATE:

 @micahcowanfound a bug at line 26200 where I had dropped a zero from a goto. oddly, the same error was in the CoCo2 version and I never caught it. it's fixed. also he made a good suggestion about add ....... while the game was loading the cards, added that too (thanks). SO the download on the 1st post is now is V2 of the game.  

 

Hello, I'm new to the Apple II scene. In fact I wrote my 1st Applesoft BASIC program (well ported) last night. It's a port of a game I ported from the Atari 8-bit for other systems, Mille Borne. Mille Borne is a card game that also goes by the name 1000 miles, the mile game and other like names. It's origin is in France and is a automobile card game where you play against an opponent putting down cards to make your way to the finish line. You opponent can throw hazards in your way to slow your progress as well as you can to them. 

As I said, the game originally came from the Atari 8-bit (where I got it I don't know). Then a few years back I ported it to the TI-99, then recent to the CoCo2 and then back around to Atari Microsoft BASIC (see my AA project below site here for those translations:) Anyway, here it is with some basic instructions for Mille Bornes. The game is text (It's my 1st Apple II program after all and I just learned Applesoft last night but it plays a good game). Enjoy

 

 

Mille Borne Card Rules.pdf

MilleBornesV2.DSK

[micahcowan]

Hiya! Welcome to the Apple II scene - I'm new here as well, got my //c about a year ago.

 

Mille Bornes is a great game, I have it in a tin at home, and my first exposure to it was on the Mac, in the form of this game.

 

I enjoyed playing your creation very much! There were no surprising or confusing gameplay aspects (at least, for someone who already knows how to play the card game).

 

I did find that the card reading/shuffling portion had me twiddling my thumbs, wondering how long it would take. I added a progress status, and made the shuffle faster as well (by only randomizing one of the swapped cards, incrementing the other, ensuring every card gets swapped at least once but no more than 100 iterations, and half the random calculations).

 

Feel free to incorporate one or both changes. My modifications are:

1950 PRINT "READING CARDS...":I=0
2300 PRINT I;" CARDS. SHUFFLING.";
2310 II=0
2410 FOR Z=1 TO I:B = INT(RND(1)*I) + 1
2420 II = II + 1 : IF II = 10 THEN II = 0 : PRINT ".";
2500 T1$ = CR$(Z):CR$(Z) = CR$(B):CR$(B) = T1$: NEXT Z: REM REM REM@@@ 5 CARDS EACH
2900 PRINT

(BTW, is that REMark on line 2500 actually intended?)

[+hloberg]

I translated it from the CoCo by pulling it into Notepad+ on my laptop then did global replace for things like REM (' on the CoCo) and some of it came out looking a little odd. otherwise the CoCo to Applesoft was the easiest port I have done of the game. Worst was the 1st Atari BASIC to TI99. Atari BASIC is very non-standard in the way it uses strings. The TI99 version was an almost complete rewrite because. All other version been based on the TI99 version since.

[JamesD]

2 hours ago, hloberg said:

I translated it from the CoCo by pulling it into Notepad+ on my laptop then did global replace for things like REM (' on the CoCo) and some of it came out looking a little odd. otherwise the CoCo to Applesoft was the easiest port I have done of the game. Worst was the 1st Atari BASIC to TI99. Atari BASIC is very non-standard in the way it uses strings. The TI99 version was an almost complete rewrite because. All other version been based on the TI99 version since.

RND, PRINT@, and a couple other things need changed, but they are both Microsoft BASICs.
Porting to the Plus/4 can be pretty easy, but the C64 is missing some common commands you have to replace with POKEs and ROM calls.
I posted a link to your site in the news topics suggestions for CoCoTalk on the CoCo Discord server.
You might get a mention Saturday.
*edit*
If it wasn't already mentioned

Edited September 14, 2020 by JamesD

[JamesD]

If you didn't use Extended BASIC commands, that might run on an MC-10

[JamesD]

12 hours ago, micahcowan said:

Hiya! Welcome to the Apple II scene - I'm new here as well, got my //c about a year ago.

 

Mille Bornes is a great game, I have it in a tin at home, and my first exposure to it was on the Mac, in the form of this game.

 

I enjoyed playing your creation very much! There were no surprising or confusing gameplay aspects (at least, for someone who already knows how to play the card game).

 

I did find that the card reading/shuffling portion had me twiddling my thumbs, wondering how long it would take. I added a progress status, and made the shuffle faster as well (by only randomizing one of the swapped cards, incrementing the other, ensuring every card gets swapped at least once but no more than 100 iterations, and half the random calculations).

 

Feel free to incorporate one or both changes. My modifications are:

1950 PRINT "READING CARDS...":I=0
2300 PRINT I;" CARDS. SHUFFLING.";
2310 II=0
2410 FOR Z=1 TO I:B = INT(RND(1)*I) + 1
2420 II = II + 1 : IF II = 10 THEN II = 0 : PRINT ".";
2500 T1$ = CR$(Z):CR$(Z) = CR$(B):CR$(B) = T1$: NEXT Z: REM REM REM@@@ 5 CARDS EACH
2900 PRINT

(BTW, is that REMark on line 2500 actually intended?)

That's the same RND change I had to make on the "Solitaire Solver" I ported to the Apple.

[JamesD]

44 minutes ago, JamesD said:

RND, PRINT@, and a couple other things need changed, but they are both Microsoft BASICs.
Porting to the Plus/4 can be pretty easy, but the C64 is missing some common commands you have to replace with POKEs and ROM calls.
I posted a link to your site in the news topics suggestions for CoCoTalk on the CoCo Discord server.
You might get a mention Saturday.
*edit*
If it wasn't already mentioned

It was mentioned in the August 29th show

 

[+hloberg]

3 hours ago, JamesD said:

It was mentioned in the August 29th show

 

thank you. and thank you for the mention. very kind of you and i'll listen to the episode.

[+hloberg]

 @micahcowanfound a bug at line 26300 where I had dropped a zero from a GOTO. oddly, the same error was in the CoCo2 version and I never caught it. it's fixed. also he made a good suggestion about adding ....... (dots) while the game was loading the cards, added that too (thanks). SO the download on the 1st post is now is V2 of the game.  

if you have the old version the fixed line should read:

26300 NC=NC+1 : IF NC=TD THEN YR$(PR,KP)="" : GOTO 26500

and the added line is:

2420 II = II + 1 : IF II = 10 THEN II = 0 : PRINT ".";

 

[+hloberg]

3 hours ago, JamesD said:

If you didn't use Extended BASIC commands, that might run on an MC-10

I tried to port it to TI console BASIC and ran out of memory. I wonder if I would have the same problem with the MC-10. the program doesn't use that many extended commands  so if it fits would be simple to port.

[+hloberg]

FYI:

I'm giving anyone who wants to port this MIlle Borne to other computer cart blanche. just maintain the spirit of what I wrote, leave in the REMS the list of other ports and who did them and tell me you've elected to do a port and then post it somewhere on Atariage.

[+hloberg]

4 hours ago, JamesD said:

RND, PRINT@, and a couple other things need changed, but they are both Microsoft BASICs.
Porting to the Plus/4 can be pretty easy, but the C64 is missing some common commands you have to replace with POKEs and ROM calls.
I posted a link to your site in the news topics suggestions for CoCoTalk on the CoCo Discord server.
You might get a mention Saturday.
*edit*
If it wasn't already mentioned

you see the Plus4 port that was done on my projects page?

 

[JamesD]

3 hours ago, hloberg said:

I tried to port it to TI console BASIC and ran out of memory. I wonder if I would have the same problem with the MC-10. the program doesn't use that many extended commands  so if it fits would be simple to port.

There are upgrades that will let you have access to 32K from BASIC.

[micahcowan]

I've put up a project for this at github, with the author's permission: https://github.com/micahcowan/a2millebornes/

The direct link to the (HTML-ified) BASIC source code is https://github.com/micahcowan/a2millebornes/blob/master/src/mb.bas
 

If you're wondering at the various instances of REM not being followed by a space, for instance the first line 10 REMMB010 and others like 3670 REMREM REM@@ DISPLAY INTERFACE... that's an interaction between the detokenizer I'm using to generate the BASIC listing, and the way tokenization is done in AppleSoft. In AppleSoft BASIC, if you type a line like 10 REM FOO, AppleSoft tokenizes the REM and then immediately starts copying the content, and includes that first space. When you LIST it back out, AppleSoft will emit a space after the REM... and then it will emit another one because it saved it as part of the content. In order to avoid this problem, the tokenizer I'm using made the choice not to emit an extra space after the REM... that way you can feed the source listing to the tokenizer, and then feed the tokenized version back into the detokenizer, and the contents will be the same. However, it also means that a like that AppleSoft's LIST command would output as 3670 REM REM REM@@ DISPLAY INTERFACE ends up with a REMREM at the start instead.

 

If I should make any updates worth cutting a disk for, I'll put it at https://github.com/micahcowan/a2millebornes/releases/ (and in this thread as well). It's my intention to work over the Coup Fourré mechanic, to bring it more in line with how it works in the original card game, and to restore the value of holding onto a card for the chance to perform a Coup Fourré (currently not worthwhile, since you don't gain the extra turn afterward, and you still have to play a Roll! card again afterward).

 

EDIT: Should you wish to try out the current "in-progress" version, however, you could always copy/paste the contents of https://raw.githubusercontent.com/micahcowan/a2millebornes/master/src/mb.bas into the JavaScript "AppleSoft emulator" at https://www.calormen.com/jsbasic/

Edited September 15, 2020 by micahcowan
How to try out in AppleSoft emulator

[+hloberg]

@micahcowan sent me a personal message that I think all should know about as it has a bearing on how one can program in Applesoft in a virtual environment.

His message:

I found one additional "bug" I figured I'd let you know about. The bug may not have been due to your error, and will not actually affect the way the program runs: but if you do a "LIST 18400-18600" and look closely at the output, you'll find that there's a line 18430 that comes *after* line 18450.

 

It looks like that line 18430 does belong after 18450, though, but the AppleSoft tokenizer I'm using in a Unix environment (I use different ones; today it was Mac OS) refuses to tokenize it back again when line numbers are out of order, so I changed its line number to 18460.

 

my response:

 

OK that's just weird. how I did this, and I do the same with all the ports, I use a program, in this case ciderpress,  to import the text file I modified in Notepad+ as a BASIC file to the .DSK. on all other computers any lines out of sequence rights themselves when loaded the 1st time so I never bother to check. Well, learned with the AppleIIe BASIC looks like it will keep it out of sequence so I need to check that. Lesson learned. More than likely there is no checking for lines out of sequence when loading a BASIC program in Applesoft. Applesoft must just assume they were all saved correctly. Next time I'll take a little more time to check over the program and not assume it's all correct.

 

Anyone else run across where the lines are saved out of sequence in Applesoft?

 

 

 

 

[micahcowan]

2 hours ago, hloberg said:

OK that's just weird. how I did this, and I do the same with all the ports, I use a program, in this case ciderpress,  to import the text file I modified in Notepad+ as a BASIC file to the .DSK. on all other computers any lines out of sequence rights themselves when loaded the 1st time so I never bother to check. Well, learned with the AppleIIe BASIC looks like it will keep it out of sequence so I need to check that.

The only reason I was able to catch the bug in the first place, is because I have the same kind of workflow, except that instead of using ciderpress, I was using deater's dos33fsprogs command-line tools, and they refused to tokenize the file back into an AppleSoft-format file again when it finds an out-of-order line.

 

Similarly I found another error from happy tool strictness last night, when I attempted to copy/paste the code into that JavaScript AppleSoft emulator, which apparently does complete syntax checking before it ever runs (AppleSoft only syntax-checks a line when it's run): line 17540 had one IF statement remaining that tried to use an ELSE (it copy/pastes from the github version fine now though).

 

Quote

Lesson learned. More than likely there is no checking for lines out of sequence when loading a BASIC program in Applesoft. Applesoft must just assume they were all saved correctly.

An AppleSoft-format file seems to be a tokenized BASIC program, laid out in the file exactly as it appears in memory. I think DOS must just copy the stored, tokenized BASIC, byte-for-byte, from memory direct to disk, including pointers to elsewhere in memory (the link entries the start of one line to where the next one is). I'm not sure if it translates in the case that start-of-program isn't set to $800, but anyway yeah - Applesoft/DOS does zero checking of the program after loading.

 

As I understand it, there are programs that will happily take advantage of this behavior: before saving you can set the "end of program" vector at $AFB0 to a higher value, creating some space; then you can stick some machine code in that newly-created space before saving your program, and interface to it via CALL() and the like; and the DOS will happily include it when saving and loading.

[+hloberg]

1 hour ago, micahcowan said:

 

As I understand it, there are programs that will happily take advantage of this behavior: before saving you can set the "end of program" vector at $AFB0 to a higher value, creating some space; then you can stick some machine code in that newly-created space before saving your program, and interface to it via CALL() and the like; and the DOS will happily include it when saving and loading.

you can pull a similar trick on the TI-99 and embed machine code with the BASIC code so both loads at the same time. the machine code is actually invisible to the user.  

[Byte Knight]

Very cool - thanks for porting this!

 

If you really want to go old-school, I've made this available as a download in my Basic Files section on my BBS (telnet://cqbbs.ddns.net:6502).  Download directly to your Apple II hard drive!

[+hloberg]

42 minutes ago, Byte Knight said:

Very cool - thanks for porting this!

 

If you really want to go old-school, I've made this available as a download in my Basic Files section on my BBS (telnet://cqbbs.ddns.net:6502).  Download directly to your Apple II hard drive!

thank you. as soon as I have the hardware I'll try out your BBS. Love the old-school stuff.

[JamesD]

FWIW, putting REM at the end of lines or executing lines that have a REM statement will slow down your program in Microsoft BASIC.
When BASIC encounters GOTO, GOSUB, REM, or has an IF, it has to scan for the end of line marker character by character.
This is one of the things I've changed in the optimized BASIC I've been working on for the MC-10.

[micahcowan]

I made a bunch of modifications (improvements, I hope?), and released the results on github.

 

Download the .dsk image, or try it out online in a JavaScript Apple ][ emulator!

 

The biggest gameplay change is to how Coups Fourrés work, bringing them more in-line with the original card game:

• After a Coup Fourré is performed, that player is left with a Roll! status (the Coup Fourré completely cancels out the action of the played hazard)
• The player performing Coup Fourré draws a card, then immediately plays again
• A Coup Fourré may only be performed immediately after the hazard it counteracts

(Since Coups Fourré are a relatively rare occurrence: comment out line 3510 to begin each round with set cards, chosen to make it much easier to exercise/test how Coups Fourré work!)

 

In addition to the gameplay changes, Coups Fourrés are now accompanied by more "flashy" messaging, and Safety cards that were played as a Coup Fourré are written in inverse text.

Other changes:

• The scoreboard displayed at the end of the round is easier to read and contains the complete information.
• A round counter is displayed, at the start of new rounds, and during gameplay.
• Most prompts wait for any keypress, rather than using INPUT to wait for a Carriage Return.
• Discard prompt no longer assumes "Y" when the keypress was neither "Y" nor "N".
• Changed the shuffle algorithm (faster, and guarantees every card was swapped at some point).
• It is no longer possible to make a card selection "in advance" while the computer is making its play (input is flushed before prompting for a card).

Thanks again to @hloberg for bringing this excellent (and apparently, fun-to-hack) implementation of the game to the Apple ][ !

[+hloberg]

good job! love it when someone can improve on what I do. In fact, I looking to retro some of the improvements in the previous versions for the TI-99, Atari MSBASIC and the CoCo2.

oh, on my AppleIIe enhanced when you do a FLASH it pulls in the alternate character set with icons and the banner looks like gibberish. looks AppleIIe standard work fine though. not sure how that is fixed as I don't know yet enough about the IIe enhanced. I would imagine the IIGS would get the same effect. no big deal, just an interesting note.

[micahcowan]

2 hours ago, hloberg said:

good job! love it when someone can improve on what I do. In fact, I looking to retro some of the improvements in the previous versions for the TI-99, Atari MSBASIC and the CoCo2.

 

Thought that might be a possibility!

 

2 hours ago, hloberg said:

oh, on my AppleIIe enhanced when you do a FLASH it pulls in the alternate character set with icons and the banner looks like gibberish. looks AppleIIe standard work fine though. not sure how that is fixed as I don't know yet enough about the IIe enhanced. I would imagine the IIGS would get the same effect. no big deal, just an interesting note.

 

I believe this shouldn't happen by default, if MB is the first program you've run since last boot/reboot. I didn't run into this problem at all on my //c, whose MouseText behavior is supposed to work the same way as an "enhanced" IIe (nor in emulators emulating an enhanced IIe). By default it's supposed to be the case that flash mode is supported rather than MouseText, but something you ran before MB might conceivably have toggled MouseText on (80-column mode turns it on by default, but is also apparently smart enough to intercept "FLASH"-mode text when written, and transform it into "INVERSE" instead - at least on my //c). If you used ADTPro or the like to transfer the card to your machine, it wouldn't surprise me if that's what did it. Naturally, in this day and age, I shouldn't write code that assumes it was not transferred via some other program first (that may or may not have tweaked some soft switches), so I should probably "POKE 49166, 1" before invoking FLASH to be safe (or avoid it completely in favor of INVERSE instead - which I presume works fine for you in YOU/COMPUTER, and COUP FOURRE-marked cards?).

 

I may still have more changes I want to do. It occurred to me the other day that you could totally play this game entirely with a paddle or joystick. I just got a MiSTer FPGA kit set up recently, and loaded it up to the brim with software and cores for various retro hardware, and I thought it'd be neat to be able to fire up and run the Apple II Mille Bornes on there, and do everything entirely via paddle (I'd need to build in a loop back to start at game end I suppose, as otherwise you need to type "RUN" again after the game ends).

[+hloberg]

6 hours ago, micahcowan said:

Thought that might be a possibility!

 

 

I believe this shouldn't happen by default, if MB is the first program you've run since last boot/reboot. I didn't run into this problem at all on my //c, whose MouseText behavior is supposed to work the same way as an "enhanced" IIe (nor in emulators emulating an enhanced IIe). By default it's supposed to be the case that flash mode is supported rather than MouseText, but something you ran before MB might conceivably have toggled MouseText on (80-column mode turns it on by default, but is also apparently smart enough to intercept "FLASH"-mode text when written, and transform it into "INVERSE" instead - at least on my //c). If you used ADTPro or the like to transfer the card to your machine, it wouldn't surprise me if that's what did it. Naturally, in this day and age, I shouldn't write code that assumes it was not transferred via some other program first (that may or may not have tweaked some soft switches), so I should probably "POKE 49166, 1" before invoking FLASH to be safe (or avoid it completely in favor of INVERSE instead - which I presume works fine for you in YOU/COMPUTER, and COUP FOURRE-marked cards?).

 

I may still have more changes I want to do. It occurred to me the other day that you could totally play this game entirely with a paddle or joystick. I just got a MiSTer FPGA kit set up recently, and loaded it up to the brim with software and cores for various retro hardware, and I thought it'd be neat to be able to fire up and run the Apple II Mille Bornes on there, and do everything entirely via paddle (I'd need to build in a loop back to start at game end I suppose, as otherwise you need to type "RUN" again after the game ends).

Nope, I tested it just running just DOS with FLASH and got the same effect. I'll try that poke and see what I get.

 

I Have a version of the original Atari 8-bit that use only Joystick and it works well. See this project on my projects page. might help you with the work flow.

 

[The Usotsuki]

For the Apple //e:  You might want to POKE 49166,0.