Jim Menick's "Draw Poker"

I already posted about Jim Menick's BASIC text adventure game "Space Derelict."  That program was an example program from his book BASIC Adventure and Strategy Game Design (1984). Jason Scott mentions that there was a version of the book for the Apple, but I worked from a scan of an edition for the TRS-80 Model IV computer. I have now cleaned up the scan of his example listing for the "strategy game" component of the book, which is a variation of Draw Poker. The "house rules" for that game are:

• Each player starts with $100
• $1 Ante
• Minimum of (pair of) Jacks for opening
• 3 raise limit
• $5 bet limit

I don't know if these are standard rules, or idiosyncratic to this 5 person (including you) computer version of the game. The most interesting aspect of the game is that the other 4 A.I. players are apparently designed with unique playing strategies/styles.  They each have names:

• Marvin
• Gerry
• Walter
• Betsy

It's a very detailed variation of Poker in BASIC.  It seems to handle betting, passing, dealing around among the players, raising, dropping out, etc.  If you drop out, the other players continue to play without you.  I'm not sure if the players are good players, but they are certainly good enough to beat me and my meagre card skills, including the occasional bluff.  

The program was very large.  I had to engage in another of my monumental "shrinking exercises," which involve the following steps:

1. Remove all spaces between commands and variables.
2. Eliminate single command lines and pack multiple commands on lines as much as possible.
3. Change as many multi-character variables as possible to single letter variables.
4. Scan the code for redundant/duplicated code and then shift that to a subroutine.
5. Shrink and streamline messaging, which had to be done anyway to shrink a 80 X 24 game screen down to a 32 X 16 screen of the TRS-80 MC-10.
6. Omit <>0 references in IF statements.  The variable by itself, if a non zero, can simply trigger the if.

Before any of that could be done, I had to chase down all the typos and bugs from my transfer/typing of the game listing from a digital scan.  There were also some apparent errors in the listing, including a missing line at 28070 with a needed NEXT. This was for the winner determining subroutine. I think it just got dropped from being printed in the book.  There was also a reference to variable S5 at line 2642, which I think should be a reference to S5(X), since there is no other non-array S5 references in the code, and all the other references are to S5(X).  I switched it, hopefully it doesn't break something.

It is strange that there seems to be no preservation of the game on the Net.  Like Frank DaCosta's BASIC programming "How-to" book for the TRS-80, I think the listings were simply too long for many people to have had the fortitude to actually type-in and fully debug the game back in the day.  Perhaps, this coupled with the minor printing errors, simply drove people insane, and so beyond Menick himself (and De Costa), few might have ever obtained working copies of the game.  It would seem that neither author distributed/published working copies of their games by way of other media than in book form for typing-in.

I'll continue to bug test and see if other errors emerge.  I have yet to fully test the routines triggered when players lose all their money and drop out of the game and what happens when the human player runs out of doe.  That will simply take some time of test play.  Of course, if there is anyone out there who wants to contribute to game testing, the 5CARD can be played here (at least for the testing phase):

https://archive.org/details/@james_gerrie

Just select the game from the cassette menu, and then type RUN.

Please let me know if you find any bugs or have any comments on the abilities of the 4 A.I. players.

I got a Full House!

Bug Addendum:

I have been intensively testing the game. In addition to a bunch of problems introduced by me in the process to get the game working and pared down to fit in an MC-10, I've found what I think are some existing bugs in the original program:

1. There was an error in the routine that examines 2 pair hands to find the highest card.  Instead of looking at the cards in the hand and comparing which was higher, Menick compared the pointer array variable values to the positions of the first cards for each pair. Those values needed to be put into another array holding the values of the cards themselves to obtain their actual values as cards.  Pointers within, pointers within pointers!  He only went 2 levels deep when he needed 3-- easy to do in such a massive program with massive lines of these multiply embedded pointers.    This happens in my program around line 2901 which is a little subroutine I carved out so that it could also be used by the "Untranslated Player hand" routine latter in the program.  I also unpacked some of the "pointer within pointer" analysis to a subroutine to make the lines shorter, since those kinds of lookups happen a lot and have the same general format.
   
2. The card replacement routine was really messed up.  If you didn't pick correctly and then simply hit N at the "Replace" prompts, it would realize that you hadn't selected enough cards to replace and take you back to start at the top of your card list again.  But it already had replaced the cards you selected and wouldn't turn them back to what they originally were. It also would not re-wind the cards drawn counter!  This meant that if you repeated hitting "N" and kept "restarting" your selection you could effectively eat through the entire remainder of the deck and blow the lid of the array holding those cards! That would cause a catastrophic "out of bounds" error.  So I revamped and stored your (up to) three selections, and then only change them after you have selected the cards you truly want.  So if you make errors, just hit N until it restarts the process as many times as you need.
3. There are places where INPUT is used, such as for "Bet?" and ""How many Cards? selections.  But a numeric variable is used for input, which means if you happen to enter a letter, you get a new line and the message "Redo" and then a newline with a new prompt, which would cause the screen to scroll. Needless to say this really messed up the screen real-estate. So I switched the input to use a string variable and then assign it using VAL to the original numeric variable. So if you enter anything that is not a number it just assumes it's a zero.
4. Minor issue with the game ending.  If you had exactly $1 left at the end it would let you ante up and enter the game with $0.  Then it would keep telling you you were trying to make an illegal bet in an endless loop.  I added logic to terminate the game if you had 0 after your ante.  I also made it so that if you get the pot up to over 480 it reports your "winnings" and thanks you for playing and ends the game. The other players are made to drop out if they have less than $5 each so if you have $500-16 there could be no players left for you to play with.  I don't know how the game would handle only you entering into the actual game play without other players. Menick doesn't seem to have considered this eventuality happening.  I guess he just thought his A.I. players were that good!  Anyway, the game now has a (hopefully) functioning win routine.
5. This one is not really a bug, but it allowed me to push the memory needs down enough that I had enough space to put back in some of the more elaborate game messages. Menick used three string arrays for presenting the cards: One for holding the card's value, one for the suit and one for these two strings combined for the whole card.  E.g. 7  ,  H  and  7H.  This was done for each of the cards. These arrays were for 40 items each: 5 cards for each of the five players, and then up to 3 cards for each player's replacement cards.  Each time these were changed Menick had to update each of three string arrays: Value, Suit and Combined Value/Suit. The combined Value/Suit would used when a card needed to be printed on screen.  But since they were always changed together it seemed redundant to manage a separate "combined" string.  I just stripped it out and simply printed the Suit and Value strings together in the few places needed. The removal of an entire 40 item string array really freed up space, and broke the back of my memory woes. Menick didn't need to worry about such things since he was programming on a TRS-80 Model 4, which I believe had 128K (and at least 48K for BASIC), and not a measly 20K like the MC-10. Such luxury.
6. At the beginning of the subroutine that checks for a straight flush in lines 2630-2647 a variable IN(X) is set to 0. Then a check is made after a search is made in the initial part of the routine for a straight to see if the value of IN(X)=1.  If it is then the subroutine is exited and the program moves on. If not, then the values for aces in the hands (14) are shifted to 1s and the whole routine is run again. I can only surmise that this is to check for a straight in the order A1234.  If straight is found for either the first search or second a branch is made to elsewhere. But if the second search occurs, no change is made to the value of IN(X) to indicate that the "second check" has occurred but no straight of the A1234 type found. So the routine just keeps being run in an endless loop. So I added IN(X)=1 after the first check for a straight is made, so that the branch out on S(X)=1 occurs after the second check.
7. In testing the winning and losing subroutines of the game it became apparent that Menick must not have ever got to that point in his own play testing (or perhaps only on the Apple version).  I created the win and lose conditions by breaking out of the program during the Ante screen, and then changing the banks of each player stored in R(X) and then entering CONT. I was able to figure our that there was something wrong with the dropping out part of the program for "busted" players.  A variable P(X) had to be set to 1 after the "busted" message gets printed, but wasn't. That variable then triggers the awareness that the player is not able to Ante and is also used to prevent printing the player onscreen and skip them for dealing duties, etc.
8. There was a problem with the routine that reexamines your hand after you make card replacements. Menick didn't re-initialize the variables storing your hand values before re-starting the hand analysis subroutine (starting at line 130). So if you had a hand with 2 pairs, and then selected new cards that left you with no recognized hand type (pair, 2 pairs, 3 of kind etc.) that routine wouldn't find anything to report about those recognized hands, so it wouldn't change the reporting variable, effectively leaving your hand with the type of hand identified from before making your replacements.  So if you started with a pair, and then replaced one of those cards in a way that left you with zilch, it would report that you still had a pair. It's possible that this might be a result of something that I changed, but I tried very early version of my edits of the game (I keep a succession) , and the problem was there, so I think it's original. Menick simply didn't test like I did by entering crazy entries again and again with the emulator cranked to the max speed.  It would be very rare (except for Betsy who seems to be a little rash) for players to smash up their own existing hands and then stay around (bluff) to the brutal end just to lose and see their hand described. They'd normally fold. So it's likely Menick wouldn't have noticed this bug. But by playing many games on high speed I noticed this first in my own hands (I was just replacing cards at random and sticking around to the end to make sure I could see all the hands to check them).  Then I noticed it happen in one of Betsy's hands too.
9. I changed the annotation of how hands are reported. It now takes the form of "Full House 6's",  "Four T's" or "Three A's" etc. The subroutine at 32000 finds the value of the highest card for 4-of-a-kind and full house hands.  At line 3410 and 3440 I added a S$ before the GOSUB32000-- The S$ stores the apostrophe and S characters printed after the card number of the highest card in the hand. This annotation was missing from the determination of four-of-a-kind hands (except for one instance). The 32000 subroutine (now relocated to 85) would not work unless this annotation was present like it was for Full House hands.  I adjusted the 32000 routine to deal with the apostrophe and streamlined its operation. 

Challenge

What are the different "playing styles" of the 4 A.I. players?  I haven't examined those routines in depth or read Menick's book in detail. I might do. If so, I will come back here and add an addendum to my addendum and let you folks know. Otherwise, if you want to examine the code yourself, it can be found here:

https://github.com/jggames/trs80mc10/tree/master/quicktype/Casino/Card%20Games/5Card

Final updates can be seen here:

"Star Command Sigma" by ASCII 1982

I had noticed several screen shots of a game called "Star Command Sigma" for the NEC PC6001. It looked like a BASIC game-- a rendition of the vast family tree of Star Trek games-- But since it was by ASCII, a major software company in Japan from the early days of home computing in the 80s, I expected that it would be especially well done. So when I finally got an emulator working for the NEC PC 6001 and located a huge repository of software, I went looking for it. I was able to list it to a file and get the source code. It was not hard to translate.

I have done other games from the NEC PC-6001 using James the Animal Tamer's Virtual NECTrek PC, which was a short lived North American variation of the PC-6001. The BASICs are similar Microsoft variations and the fact that they both use the Motorola MC6847 video chip makes things fairly straightforward.  The NEC uses LOCATE instead of PRINT@, but I just switch its two X and Y arguments to PRINT@X+32*Y, and get the same results. The NEC has some fancy graphics modes, such as the ability to define a virtual console/window on part of the screen, and some super sound generation. But I was able to translate most of this stuff in a downgraded way. One advantage of the MC-10 is that its screen printing and BASIC generally run faster. There is a speed sacrifice to be paid for all the NECs fancy abilities.

Here are some comparisons screenshots of the game working on the PC-6001 emulator and the Virtual MC-10.  They show some of the differences in how the two computer systems implement the MC6847:

NEC PC-6001

MC-10

The NEC allows all the possible character colour layouts provided by the VDG, whereas the MC-10 can only easily access black on green text. The NEC also has an extended character set with lowercase and special symbols, such the degree symbol (little raised circle), which is used in the game.

You'll notice that the Klingon's are called "KLIMZONs" in the NEC variation. However, ASCII provide a variable for storing the name, so you can easily change it to Klingons. I guess they had to worry about copyright infringement, but they wanted customers to be able to easily switch  to full copyright infringement mode if they desired. You'll notice though that they still use an "E" for your ship (I wonder what that stands for?).

ASCII also embedded some strange characters at the beginning of each of the main menu item titles as they were listed in the DATA statements. These weird characters are processed when the titles are read in and combined in a single variable that reads "by ASCII." I guess they were a little worried about copyright infringement of their own. It's kind of like Bill Gates multiple Easter eggs hidden in Microsoft BASIC, such as in the original Commodore BASIC for the PET, that can print out "Microsoft." If any one tried to pirate the code, Bill could just hit a few keystrokes and reveal the Easter egg message and claim ownership!  I thought of switching it to "JimG2022" or some such, but in the end, it's their program.  If they come gunning for me they can happily sell my version to the massive legions of MC-10 users out there!

The music is a bit of a mess.  First of all I don't read music.  Second, the MC-10 only has a simple SOUND command, and not the fancy PLAY command of the NEC.  Still I have butchered the notes listed in those PLAY commands to get some meagre semblance of the original musical refrains for the intro, win and lose screens. I had to be somewhat creative in the implementation of sound effects, but sometimes the program also used the simpler SOUND command, and in other cases I tried to take clues from the notes listed in PLAY commands.

The scrolling "window" allowed for by the CONSOLE command of the NEC had to be dispensed with.  Instead I went with a system of the top of the bottom half of the screen being used for commands, the middle for messages and help info, and the bottom line for combat messages. No scrolling is allowed.  Instead, as messages roll in, a small left pointing arrow appears in the bottom right corner.  When it does, you can hit a key to skip directly to the next message/event. Otherwise a brief pause will occur to allow the player to read the message before it is replaced or erased.

The game is very feature rich. There are options that I have not seen implemented in any other variation of the classic Super Star Trek game. I wont go into complete detail here, but it is a very well-thought out set of command options that will make for a challenging set of tactical decisions as you try to destroy all the Klingons, Oh, I mean Klimzons. The enemies even occasionally shoot torpedoes back at you, which you can launch a counter measure against using the

QWE

  ASD

   ZXC

direction keys.  The NEC used the STICK command to read a direction from the joystick, but I switched it to this keypad arrangement. Hit one of these keys just after the enemy launches a torpedo (or when the left pointing "continue arrow" message is displayed) and you might get lucky in destroying the incoming torpedo. The enemies even move during combat (and other times) so you will find that occasionally they warp out of the way of danger or new ships can arrive to complicate your life.

Below is a playthrough. I lose. I didn't realize that a feature that allows you to get energy from a star is "paid for" by sucking time off of your countdown timer.  If I hadn't been so greedy (and ignorant of how all the features are interconnected) I might just have won!  See if you can spot the moment of my fateful decision...

While investigating the game I also discovered that ASCII went on to make a fancier graphic character version for the MSX line of computers:

So the MC-10 now has a neat little game recovered from the early 1980s to help it to keep pace with the "big boy" systems of the 8-bit era. I wonder of Mr. Godai (listed in the title screen above) is the same programmer who made the version for the NEC?  If so, thank you Mr. H. Godai for a wonderful game.

Addendum

I modified the title page to make the sigma look more like the original:

I also fixed up some of the more awkward "Engrish" phraseology, such as "Torpedo is breakdown."  I changed this to "torpedo damaged" and modified "Klingon" to plural "Klingons" (etc.) on the status screen.  I still don't know what "Offensive cycle" means and what the number attached to it represents.  It's probably something like "threat level" or possibly, the number of combats you have had with Klingons, or something like that. If anyone has suggestions, I'd appreciate hearing them. Perhaps I'll change it if I figure it out.

I added plurals and gender neutral terms to the status report

Addendum to the Addendum

Curtis Boyle mentioned the program on the Cocotalk web show and commented that it was good to see a nice version of Star Trek on the MC-10.  However, it is actually an addition to a number of other Trek variations that I have ported to the MC-10 as part of my efforts to collect up classic BASIC programs for preservation purposes.  It's not Curtis's fault that he wasn't aware of these wider efforts on my part, although I might have made him feel that way when I made a video to bring these other Trek programs to his attention. I didn't mean to offend (Sorry Curtis).  Just goes to show how much tone is lacking from the quick messaging that forms such a part of digital life today. Much thanks to Curtis for the great job he does presenting the details of the projects and activities of the community. In any case, here's the vid with a run down of some of the other Trek offerings on the MC-10:

For an "all Trek" themed game list for the online MC-10 emulator on the Internet Archive just search on "Star Trek" here: https://archive.org/details/@james_gerrie

Addendum to the Addendum Addendum

Noticed some spelling mistakes in the "Encounter in the Near Tholian Sector" game while reviewing my video. Don't know if those are mine from the porting process or from the original, but in any case I've fixed them up.

"Kagelien" from Micom BASIC Magazine Aug 1985

 Beware the "ShadowAlien!"

The following is what came out of Google translate when I downloaded and translated the Readme file that came with a program called "multi-game" for the NEC PC6001:

5. KAGERIEN (instructions)
Move yourself in 4 directions with the cursor keys so that you do not hit an enemy or a bomb (*).
Please take all the unpleasant. Enemies and bombs are displayed only on the left screen, and diamonds are displayed only on the right screen. It will not be. If you press the space key when the score is 100 points or more, you will lose 100 points and the enemy's movement
You can pause it. When the score reaches 500 points, one person increases, and after that, 1,000 points. One person will be added each time. In addition, there is a time limit for each surface, and even if this becomes 0, the number of people will decrease by one.
I will. When all of you die, the game is over. 

Restart
In any game, if you press the space key, you can play the same game and return.
Press the key to return to the menu screen.

At the end
At first, I intended to make everything original, but in the end, more than half were transplanted.

It has become. Next, I challenged the limits of N60BASIC !? Send the game I would like.

Reference
Micon BASIC Magazine August 1985 issue JR-100 "Four-handed Kannon" God Warriors, MSX
"KAGERIEN" Hiroshi Uwasawa, July 1987 issue Family computer "Rurumoppe"
Scramble Uko, February 1988 issue PC-8001 "Yanmo STONE" Minoru Yamamoto

<< Table 1 >> Main variables
S ..... Score
T ...... Time, number of times
R ...... Number of faces
X, Y .... Coordinates of the main character
V, W .... Move destination, move direction
I, J .... Loop
A$, D$, A, B. General purpose

My attempt to clean up these instructions resulted in this:

Use WASD keys to avoid enemy "@" or bombs "*", which are displayed only on the left side of the screen. Collect "$"s on the right side. When score is 100, pressing space clears bombs. 500 points = bonus man and after that, 1000 points is needed. There is a time limit for each round. You lose a life if you exceed it.

From what I can gather from the information provided in the Readme file, the game was originally made for MSX computers and published in Micom BASIC Magazine August 1985 (p. 83) under the name "Kagelien.  I think this was a combination of some Japanese word with "alien" since you can see the English word "alien" in the text and the MSX version uses a sprite that is clearly meant to represent an alien figure. The game seems to have been translated in 1988 to the NEC PC6001 and combined with 3 other programs to create the "Multi-game" program.  In the course of that translation the program seems to have been renamed "Kagerien" for reasons that escape me (or this might just be a tanslation error from the Japanese text file encoding). I separated the source for "Kagerien" from the other programs and renamed my version back to "Kagelien." I added a title page reference to the original 1985 Micom BASIC article, since I wanted to credit the original author of the game. However, that author's name is not apparent in the article.  Perhaps I will have my son Charlie try to decipher it from the Japanese characters.  He might also be able to provide something of the back story.

The game is very clever in its use of a split screen to provide greater tension and difficulty in what otherwise would be a relatively "slow BASIC game," although I did manage to speed it up to a point that I could add 3 levels of play using a slowdown loop. The necessity of having to split one's attention between two different screens means that despite the relatively slow movement of the enemy, you can easily become distracted and allow yourself to be killed.  The sound is minimal, but there must be something about the Japanese education system that produces a good level of basic musical awareness.  Most Japanese games I have translated don't just use indiscriminately selected sounds to indicate major in-game events, but always melodic tones.

Here is a video of the game before I renamed the program:

Charlie's Note:

I'm gonna guess the author's name is those 3 characters floating as a pair and a single up in the top left grey patterned area, 上沢   裕. According to https://culturetour.net/japanese-last-names/uesawa4557 and https://en.wikipedia.org/wiki/Yutaka that's probably pronounced Uesawa Yutaka.

Uesawa(上沢) Japanese Last Name Meaning and Origins

Then that top left paragraph has the backstory: "in XXXX year, a certain astronomer discovered a star covered in diamonds, XX star (Japanese sci-fi is really big on these blanked out names/dates for its settings). A <something> was sent to the planet (probe, mission, colony?). Doctor D, the man who 'developed' the <something> (this word is used in the sense of software, but also of a nation. It might just mean he just develops i.e. works at a facility on the planet?), even though he had a map that could see anything, somehow there was... a shadowy ('KAGE', this is where the name must come from) gorilla-like alien...!"

I wish I could figure out that <something> character. It's a complex character that comes out blurry in the scan.

Addendum to addendum:

Or yea, that something is you. I see that now in the next paragraph. So whatever you are; a robot?

PLAY

The game can be played here under the "Classic 8-bit BASIC games" menu item:

https://gamejolt.com/games/jgmc-10games/339292