"Ghost Ship/Yuureisen" by Yasuhiro Kume (1982)

With some help from Jason Dyer and Gunther Schmidl I was able to get hold of the source code of an early Japanese basic text adventure game called "Yuureisen" (https://github.com/jasonbdyer/classic-basic/blob/master/Yuureisen.txt).  Jason calls it Phantom Ship, but many of the sites online list its English translation as "Ghost Ship."

I have been looking for an example of a classic Japanese text adventure for some time, and Jason's blog post about the game provided the opportunity. I have examples of the early text adventure of many countries on my text adventure page (https://jggames.github.io/Type-in-Mania-Text-Adventures.html):

• Agent 999 by Kajsa Söderström 1984 (English translation from Swedish)
• Spaceship Farmer/Astronave Farmer by Mario Pettenghi 1985 (English translation from Italian)
• Caverns in the Pocket/Des Cavernes dans le poquette by Charles Feydy 1982 (English translation from French)
• Drakulas Diamanten/Dracula's Diamonds by C. Seibt 1983 (English translation from German)
• A Hös Lovag (Hero Knight) by Miklós Tihor 1985 (English translation from Hungarian)
• The Time Machine/De Tijdmachine by Gerton A. Lunter 1988 (Netherlands)
• P.R.E.S.T.A.V.B.A. by Miroslav Fídler 1988 (English translation from Czech)

But none from Japan.

I’ve now completed my translation to English and port of the game to TRS-80 MC-10. I’ve also completed playing the game. But of course I cheated by playing it from the inside (code side) out, and not as it really should be played. I look forward to Jason's account of slogging it through in a proper player's way. It’s a complex adventures with lots of subtleties and has been and will be challenging for him. Here’s a video with me demonstrating a bit of the start of the game (an early version of my port with some of the translation still rough):

I really appreciate Jason's detailed discussions of this and other games. They really help when trying to unpack the code and do a translation. Or I should really say "to tweak" a translation provided me by Copilot. It did most of the heavy lifting, but I used Jason's analysis and the contributions of others posting on his blog to help when things were unclear. I also, as usual, called in my son Charlie in to help with a few conundrums I had with certain words. For example, he helped confirm that the original used LEFT and RIGHT directions in addition to North, South, East West. For a time I had even wondered if it was using PORT/STARBOARD. One mystery I still have is the last word in the Verb list, which CoPilot and Charlie rendered as SPIT (Haku). It was clear from the code that it needed to be something like CLEAN or SWEEP, as it involved having to carry a broom and do something with a pile of trash.

Jason Dyer was stuck for a while on the main decks of the ship. I had figured out from the code that the main puzzle there was to hear a message from a pile of skeletons, which indicated that the player must PRAY or say AMEN over all the skeletons on the ship. Then the player would be allowed to interact with those skeletons without being chucked off the ship by the disturbed spirits of the dead sailors (its a neat narrative idea).

If you just looked at those skeletons you would get a message telling you they were, as Jason nicely put it "seething with angry spirits". But if you looked at them after saying AMEN" over their remains they would be described as "sleeping peacefully". Then you could SEARCH or MOVE them. These are actually different VERBS in terms of their effects, although they both accomplish the same end of revealing hidden items.  You need to do this to find needed keys that allow you to proceed to the lower levels of the ship.

The game is designed so that you always have to go and visit the pile of skeletons and “LISTEN” for the message before praying over the other skeletons (Or you can just break out of the program and type in AH=1 and then enter CONT). I think in the original Japanese you might have to use a more specific formula for praying, but I changed it in my English version to be more flexible. The original might be something like “PRAY AMEN” or maybe “SAY AMEN”. I made my version work if you said either “PRAY”, “SAY AMEN”, “PRAY AMEN” or “SAY PRAYER”. These seemed a more natural English set of options. The phrase “PRAY AMEN” seemed a little unusual in English.

The game also requires that you “LOOK" at rooms after entering them before you can interact with any items. You can also and sometimes must look at individual items before you can have further interactions with them. And there is, as I mentioned, a difference between examine and move in terms of effects. I actually enjoyed these complications/subtleties, but it can get a wee bit tedious having to do all 3 actions on every item to make sure you have discovered all hidden items in the game.

I also had trouble figuring out how the doors worked in the original. Something to do with how the word "KEY" is used in Japanese so that it covers the concept of "UNLOCK" in English. Because I didn't understand this subtlety, all the doors were originally “closed” and locked for me. In my initial fix of the problem the doors to the Amory, Storage, Cook’s room, Galley, Officer 1 and Officer 2 were just open and unlocked (didn't need a key). But I noted from Jason's descriptions that they seemed to be at least closed in the original. Then I was able to figure out that doors had to be both UNLOCKed and OPENened and so discovered that my kludged solution was in error.

In porting the game I noticed a place where there might end being a bug in the code for anyone trying to translate the code to any variation of Microsoft BASIC. In the prayer routine there is the following line:

4040 IF LEFT$(A$,4)=LEFT$(V$(5),4)=0 THEN 4090

My Microsoft BASIC chokes on this. By MS BASIC standards it should be expressed with brackets around the LEFT and RIGHT logical equality comparison to separate that logic check from the = 0 check, which is just a way of checking whether that comparison is false.  In the original BASIC the order of operations must be handled slightly differently so that brackets are unnecessary to distinguish  logical comparisons from other logical comparisons. For MS BASIC the line must be something like this:

4040 IF (LEFT$(A$,4)=LEFT$(V$(5),4))=0 THEN 4090

OR even more simply for a Microsoft variations of BASIC, like this:

4040 IF LEFT$(A$,4)<>LEFT$(V$(5),4) THEN 4090

There is another possible bug like the above one:

1450 IF LEFT$(A1$,3)=LEFT$(N$(NN),3)=0 THEN 1490

Should for MS BASICs read:

1450 IF (LEFT$(A1$,3)=LEFT$(N$(NN),3))=0 THEN 1490

OR

1450 IF LEFT$(A1$,3)<>LEFT$(N$(NN),3) THEN 1490

Other than that there wasn't much challenge in converting the code.  It was otherwise pretty MS BASIC compliant.  I had to do a little condensing of the code to make sure it all fit in 20K. I comes out with only just over 300 bytes left after you play the game to the finish, so its a tight fit. 

I also had to reverse the NOUN VERB order of Japanese of the parser to the VERB NOUN order of English.  This required that I alter the parser a little, since it was designed to only look for the first and last space-separated words and therefore ignore possibly multiple word NOUN phrases.  Instead, I had to have it check for only the first two distinct words (VERB and NOUN) and ignore any additional space-separated words of the noun phrase. This way it could handle complex nouns like GOLD COIN and MIZZEN MAST properly. I also had to check, and in a few cases, look for longer numbers of characters than the first 3 of words, so as to distinguish them from other words.  In one case, CANNON versus CANNONBALL I had to change cannonball to "32LB BALL" to allow it to be distinguished properly.

** SPOILERS ** (Don't proceed if you want to be surprised while playing the game)

Finally, I came across what might be an error or minor quirk, depending on how you look at in the original.  In the final boss battle, you are attacked by the skeleton of the Captain.  Saying a prayer wont work.  Nor will any other action.  The solution is to have found the cross in the Command Room, and then when attacked, to "use" it.  The verbs available for "using" the cross are those from the 29-32 as outlined in this IF statement: 

4480 GG=1:IF NN=43 AND VV>28 AND VV<33 THEN PRINT " THE SKELETON DISAPPEARS!":GOTO 1120

Unfortunately, those verbs correspond to the following:

                     

          26  27   28   29  30   31    32      33   36    37     38 

180 DATA TAKE,GRAB,GET,HOLD,DROP,THROW,FLING,BREAK,CRUSH,DESTROY,HIT...

I'm not sure why TAKE, GRAB and GET were left off the options.  HOLD is not a particularly common verb for text adventures.  And I'm not sure why DROP is included.  Perhaps simply because it is a synonym for THROW CROSS and FLING CROSS, which are perhaps somewhat appropriate exorcism techniques.  But I didn't want the final big puzzle to just be an exercise in guess the quirky VERB and to give the player a more sporting chance of not having to play the game all over again, especially with all the UNLOCKing, OPENing, MOVEin, SEARCHin and LOOKing that you have to do (there are no short cuts).  So I changed it to also allow TAKE, GRAB or GET CROSS.

I wish Jason and all the others who try to beat this game the best of luck.  Its a tough game, but ultimately a relatively fair one, except perhaps for this last quirk with the cross.

The game can be played online here:

https://archive.org/details/GSTSHIP

Below are my notes on how to resolve each room's puzzles:

First Level (Using Jason's Map)

Second Level

In Search of "Dojin" by Hiroshi Suzuki (1980) Update 3

My son Charlie did a little play testing and he wondered about the ability of the enemies to "jump off" the obstacle.  I had added a feature to the being-pushed-along-by-the-obstacle routine that randomly (1 in 12) let the enemy stop being pushed (i.e. to "jump off").  Obviously this manifested more in the middle of the screen because the enemies ride longer in that zone. That was my hope. This was meant as a way to cut down on the random killing of enemies as they moved about (something Charlie and I had talked about at great length). This randomness was also meant to encourage the player to try lure the enemies into the upper and lower regions where they could be more assured of being crushed.

Also, the points of intersections of "the road" and "forest paths" also have checks for tracking, so the enemies can jump off when the log goes by pathways and the enemy is near the end of the obstacle.  Again, I wanted to diminish the likelihood of the enemies simply being crushed by chance as they moved around.  I wanted the player to have to understand and manipulate the tracking behaviour of the enemies to lure them to their doom.  But the game with the long obstacle still tended to kill enemies quite frequently without the player's efforts even with these tweaks. So the player would often only be facing one or two, which seemed not to be in the original spirit of the game as described.  So I went back and looked at the diagrams and noticed that the "car" (obstacle) wasn't depicted as being as wide as the central "road". So I shortened it by two blocks and I have taken out the randomness of the enemies being able to occasionally "jump off."

My latest version really creates some interesting dynamics for the enemies.  Now they don't get killed so easily crossing the road.  You really have to work at luring them across near the top or bottom, which is quite different from the prior version.  Because more of them survive for longer they also really pose a challenge for the survival of the player, as they can scrum you en masse and trap you in corners more easily.  Is it too much?  I need to figure out if I need to slow the game down some more (I've already slowed it a little from the last version).  I find it a real challenge, but I'm old, so not a good play tester.  I'll have to try to convince Charlie to do some more testing.  I''ve put the new version up on the Internet Archive and my other locations, such as Game Jolt.  So if anyone else wants to try it, suggestions are welcome.

The game uses the WASD keys for movement.

It can be downloaded (along with the VMC10 emulator) from the Internet Archive: https://archive.org/details/DOJIN

And played online at GameJolt. Select the big green bordered "Play" button. Then select "DOJIN" under the "Recodings of Classic BASIC Programs" menu item: https://gamejolt.com/games/jgmc-10games/339292

Source code can be found on Github: https://github.com/jggames/trs80mc10/tree/master/quicktype/Arcade/Dojin

In Search of "Dojin" by Hiroshi Suzuki (1980) Update 2

Well I simply answered some of my own questions from the prior post and continued developing my attempted recode of "Dojin" based on Mr. Suzuki's sketch and the descriptions provided by John Szczepaniak who interviewed a bunch of Japanese programmers for his book "The Untold History of Japanese Game Developers." Vol 1.  First I got a BASIC only version running, but it was a little pokey, so I compiled it using Greg Dionne's MCBASIC compiler.  Here's the BASIC version:

Here is the compiled version:

If you are seeing this post without reading the prior ones, Mr. Suzuki's "Dojin" is a lost program. It was inspired by one his earlier groundbreaking game programs "Shoplifting Boy" aka "Manbiki Shounen." Dojin then helped inspire the groundbreaking game "Uchuu Yusousen Nostromo," by Akira Takiguchi (Masakuni Mitsuhashi did a NEC PC-6001 port that I used for my port), which is considered a very early example of the survival horror game genre. This project was suggested to me by John Szczepaniak. His book provides the only substantive information that I am aware of about this missing game.

Shoplifting Boy (My port can be played here: https://archive.org/details/MANBIKI)

       ↓

Dojin (missing game)

       ↓

Nostromo (My port can be played here: https://archive.org/details/NOSTRO)

I plan to have my son Charlie to play test Dojin and make final suggestions for refining the speed and timing, and possibly code some slightly more musical elements than the bleeps and bloops I'm only capable of.  So there will be further updates.  Until then the current version can be downloaded from the Internet Archive (but not played.  The Archive emulator doesn't like compiled games):

https://archive.org/details/DOJIN

Dodging?

But I have played the game a little (as you can see in the above video) and the player really has to work hard to avoid the enemies, so much that I wonder if "Dojin" is a Japanese play on words for the English word "dodging" (the title I will give it if I get word that it is not a good representation of the original).  But according to Szczepaniak it means something like "native" or "aboriginal" in Japanese. The light green objects are meant to be trees of the forest.  So the vibe is that you are some kind of colonialist (probably wearing a pith helmet) being chased by locals around their pastoral home. Not sure what the obstacle is. Either a rolling log, which is how my son and I thought of it, or a "car" of some kind (or possibly a bulldozer bringing "progress" to the local population and landscape.

In Search of "Dojin" by Hiroshi Suzuki (1980) Update 1

I have been working on my implementation of the first variation of the rough sketch of the game provided by Mr. Suzuki.  I now have a working group of four enemies ("Y"s) and a player ("X") moving in the maze.  The enemies track whenever they reach a corner junction.  They can get pushed along by the orange obstacle.  If conditions are right they get crushed at the ends.  I haven't put in detection of whether they hit the player or the player gets hit by the obstacle or new screens if you kill all 4 enemies.  Using pure BASIC it is a little bit slow. Adding more refinements will probably make it a little slower again, although I can probably make the code a little faster with the application of speedup techniques, but I think I'm just going to have to compile it using Greg Dionne's MCBASIC compiler.  Then I'll probably have to add delay loops to keep it playable.  So I can't tell yet whether it will be a  playable/enjoyable game.  So many questions remain unanswered:

1. How many enemies?  [I've chosen 4]
2. Do their numbers increase with each screen cleared? Their speed? [Mine: speed increases every screen cleared]
3. Levels of play? [none]
4. Does the player have lives?  How many? [4] Can they earn new ones? [no] Where do they respawn? [bottom left]
5. Splash screen? 
6. Points awarded for enemies eliminated? [1]
7. Scored displayed? Lives? Where? [bottom left and right]
8. Instruction screen? [none: Use WASD keys]
9. High Score displayed? Where? [bottom centre]

Thanks to John Szczepaniak for the project idea and doing the interview with Suzuki, which is the only real source of detailed information about this lost game, and my son Charlie for his coding suggestions and discussion.

I have added a "Japan" subject metadata tag to my program ports from Japanese computers, so I can search on for them by country: https://archive.org/details/@james_gerrie?query=Japan

In Search of "Dojin" by Hiroshi Suzuki (1980)

John Szczepaniak emailed me with a suggestion for a possible "recoding" project (He'd noticed I do such projects) regarding a lost game from the early period of Japanese Game development.  The game "Dojin" was inspired by Manbiki Shounen.  It then helped inspire the game Nostromo. Here are some notes of my discussion of the program with my son Charlie, who watched the video transcript of Szczpaniak's interview and was able to use his knowledge of Japanese to provide some further context about the conversation going on.

From the descriptions Charlie heard in the interview and from the transcript and from the two diagrams, one by the Hiroshi Suzuki on the top left and another by a fellow programmer, Masakuni Mitsuhashi.  Both were youthful programmers and game enthusiasts who had been contracted by Taito to create games and show them to the company as a kind of game idea incubator/computing club.  Mitsuhashi had also played the game. I was able to rough together two MC-10 variations of the game screens based on their different sketches and descriptions:

Mr. Suzuki's Sketch

Mr. Masakuni Mitsuhashi's sketch (Thanks Charlie for helping create this one):

As John Szczepaniak pointed out in his email the two sketches and two descriptions suggest quite different games. The first one would involve what I felt was a fairly straightforward 8-bit BASIC text game using standard tracking algorithm for the enemies moving along the cyan colored hallways. The orange item/obstacle moves from top to bottom (or bottom to top, or both) and the player must lure the enemies via manipulation of their tracking behaviour to "cross the road" and be crushed by the orange moving obstacle (like a "car" on a road is mentioned, or a "piston" or "pendulum"). There is also an objstacle in Masakuni's version but it is not shown in the screenshot above.  In Masakuni's description the player navigates between closed rooms or cells (both descriptions mention a "forest" or "trees") by breaking the walls between them. Masakuni suggests that the enemies have a harder time breaking the walls and so move slower than the player.  But the overall goal is the same: Lure the enemies onto the "road" and time it so that they are crushed by the orange object as it moves up and down.  

According Szcepaniak, Dojin was a forerunner (inspiration of) Nostromo: 

JS: Nostromo was also inspired by Mr Suzuki's unreleased game, called Dojin?

AT: Yes, certainly. I created Nostromo on a PET CBM. Later Mitsuhashi-san ported it to PC-6001. My idea was different from Dojin - actually, Dojin was a very interesting and playable game. But the enemy was always viewable by the player. So because I loved [the film] Alien, as well as Star Wars, I wanted the enemy invisible to the player. Visible only when it is viewable by your character. So that's the idea of Nostromo.

MC-10 Nostromo based on NEC PC-6001 version

In terms of game dynamic Nostromo has a large red "niche" in which the player can shelter from the Alien (the Alien will often pace back and forth in front of it before randomly veering off down another hallway).  That niche reminds me of the little "randomly distributed" niches in Mr. Suzuki's diagram.  But Nostromo also has a dynamic of breaking the walls of the 8 "lockers" that the player must access to retrieve the randomly distributed items needed to clear screens.  So I'm in a real quandary about what the game was actually like.  I am pretty sure I can make a game similar to another Japanese game called Heiankyo Alien, which also has enemies that track you through a linear grid (the programmers actually mention this game on page on p. 400).  That game inspired the game Space Panic (mother of all platform games) and involves digging holes and luring the aliens into them, then quickly refilling the holes before they can escape.  I could see using Suzuki's map to do a very similar thing, except you lure the enemies to the central road area to be crushed.  Here is a video of Heiankyo Alien:

The main problem I can see would be in how the enemies react when they reach the road.  My thought is that they should always proceed across to the other side.  That way they won't just end up wandering in to the central road zone to be killed.  The player would then have to use careful timing and reading of the enemies' tracking behaviour to lure them onto the road for a sure death.

But that suggests that there might be something to the "walls and wall breaking" of the second sketch.  Perhaps the dynamic that prevents the aliens from simply wandering to their deaths on the road as they track the player is that they are compartmentalized.  If they break walls at at a slower pace, then that might give the player time to create paths to lure specific ones to an exit to the road that the player creates.  That dynamic would have aspects like the wall breaking in Nostromo, which requires 2 or 3 shots before the player can blast through the outside wall of the 8 lockers/rooms.

Szczepaniak seems to agree that the wall breaking dynamic has some advantages.  In his email he says:

"I probably won't attempt [to recode] Suzuki's description, since the way he described the random forest, and hiding in the gaps, sounds difficult to implement."

It might not be that difficult to implement, but it is unclear how the tracking enemies will interact with the road and its continuously moving obstacle and whether the resulting dynamic would provide an interesting game or just a exercise in temporary avoidance until the enemies wander to their deaths.  But the second variation also has unknow dynamics.  If the aliens are randomly placed then they will begin tracking towards to the player.  Perhaps they need several attempts before walls breach for them, but will there really be enough time for the player to create trails and lure specific ones into following to the road?  Should the player move slightly faster?  Once on the road how quick (what rate) should the obstacle move?

As Charlie pointed out the obstacle's movement rate (the ratio of obstacle's movement rate from top to bottom or vice versa and the player's movement rate) can't be so quick that the player can't make it across or up or down and back into the "forest". And for both variations, can the enemies get swept before the obstacle (as it moves either up or down) but still move right and left to possibly escape back into the forest before being "crushed" at top or bottom wall edge as mentioned in the interview transcript?  That would certainly increase the need for timing one's luring.

And for an MC-10 re-code (same screen as the NEC-PC6001) would the reduction from the 40 by 25 screen of the PET to a 32 by 16 screen disrupt the original dynamic regarding these ratios?  So many unknowns...  In the end, I will simply have to code each dynamic, do some tweaking of the relative movement rates and see if some kind of playable game "emerges."  And then perhaps send some video to the original author and players to see if either variation comes close.

Here is an actual page from S's book with part of the transcript:

Any comments or suggestions would be much appreciated.

"Nellan is Thirsty" by Dr. Furman H. Smith (1980)

SPOILER ALERT!  The above is a complete walkthrough of the game.

This program is from the July/August 1980 issue of Recreational Computing Magazine.  I have made a port to the TRS-80 MC-10 using Microsoft Color BASIC.  It is a simple text adventure designed to introduce children to text adventure games.  My version of the game can be played online here: 

https://archive.org/details/NELLAN

I used Commodore 64 source code.  There doesn't seem to be any easily available original TRS-80 Model I/III code out there.

It is a very gentle and forgiving text adventure.  Hints are provided at the beginning to familiarize players with the basics of two-word parser text adventuring.  However, this does not mean it is without its challenges. There are some subtle puzzles that need to be figured out, which will challenge neophyte players.

I have made a few edits to the text messages of the game.  Some are just for clarification (perhaps simply my own).  Others are indulgent. I changed the name of a university mentioned.  I wonder if Dr. Furman taught at that university?  It's in Texas, but the game otherwise has a distinctly British vibe to it.  Perhaps it is simply its "Alice in Wonderland" style, or its the name "Nellan," which seems quintessentially English to me.

Jason Dyer has a nice write up on the game:

https://bluerenga.blog/2019/01/31/nellan-is-thirsty-1980/

But I can't see much about Smith there, but the magazine original article supplies these details:

Furman Smith received a Ph.D. in Probability and Statistics from the Florida State University in 1972, taught three years at the University of Kentucky, and has since been at the University of Houston Victoria Campus. He is currently an Associate Professor of Mathematical Sciences teaching four courses, Chairperson of the UHUC Faculty Council, and a member of numerous committees including an eight faculty member group that is advisory to the President of the University of Houston System. He has a marvelous wife, two marvelous kids, one good home computer, a garden, and backlog of work.

 Nice.  From one academic with a backlog of work (who is doing this project during Winter reading week) to another, thanks for a wonderful game Dr. Smith!

"Checkers" by John Collins (1979)

I ran across a neat post on the Atari Archives Site that discusses very early computer versions of Checkers. Kevin Bunch mentioned a version of the game on the Bally Astrocade system that was by John Collins. I've converted other programs by Collins and other programs for the Astrocade system. 

The system had limited memory, about 4K. It was one of the first early video game systems to also include a version of BASIC (a reasonably good one for a machine without a keyboard). Those limits seem to have inspired high levels of programming cleverness among coders. In the late 70s these pioneers created very memory efficient games with AI features within the extreme limits of 4K. Their skill can be easily leveraged to obtain programs that can run on the 4K MC-10 as well. I converted a very powerful Othello game with a strong AI by Clyde Perkins called O-Jello, which works in only 4K. And Collins made a very clever but fairly extensive text adventure Bally's Alley in only 4K.

Collins' Checkers source code is preserved on the Archive as a printout listing from the Arcadian newsletter:

https://archive.org/details/ballyalley_Source_Code_Checkers_by_John_Collins

Bally BASIC is not that hard to work with.  It has a few differences from the Microsoft variation provided with the MC-10, but they are not hard to adjust to--  Semicolons for separating commands on the same line.  No OR or AND Boolean operators.  It uses # for "not equals" instead of <>.  The biggest challenge is that it uses a cartesian graphic coordinate system which starts at the centre of screen, instead of the upper left corner and therefore uses negative numbers.  I'll put my version up on the Internet Archive, so if people want to play the game, it might be a little easier than using a Bally emulator, since input for that system was only by controllers with numeric keypads and overlays for functions and alpha input (as with the old telephone key pads).

https://archive.org/details/CHECKRBA

I also have been making a few graphic fixes to some of my old programs. I rejigged the splash screen (see just above) and the menu operations of my Micro Color Trek. This version is from some Coco version I acquired back in the day. I think I typed it in from an old BBS.  Since the MC-10 Micro Color Compact didn't have download capabilities, I had to list the file from the screen buffer to my thermal printer and then type it back in by hand while I also converted it to MC-10 BASIC. Then I modified it further. It survived the years on tape and I converted it to a WAV sound file early in the 2000s and then converted it to an emulator C10 file. So I thought I would give it a little bit of a touch up. I discovered some unused musical note data typed in, but not accessed, probably for a Coco PLAY command.  I had obviously simply ignored this data in my original conversion. I was able to convert the data for use with the SOUND command instead, and added back in some musical refrains at key points in the program's operation.

I also finally liberated from another one of my old tapes a "Crap" game demo program from the MC-10 User Manual.  Like Trek, I had added some simple SG4 graphic dice, instead of just displaying numbers for the dice rolls.  Back in the day these kinds of edits felt like monumental "computer hacking" to the teen me.

In the spirit of such hacking, I decided to modify a version of a Santa Claus graphic program from Family Computing magazine.  I never liked the version of the chimney presented in that program, so I decided to make something better.  I used the SG4 graphic editor to come up with something that I felt looked more like a brick chimney.  Here is the original version:

Here is my updated version:

I also updated my port of the classic game "Switchbox" from the March 1986 issue of Compute! Magazine. I used the Atari ST source code for my original port. But inspired by a recent Youtube video discussing the program I changed the animation of the switches and added some more speedups to the code (e.g. converting to single character variables, using periods instead of 0s, combining lines): https://youtu.be/nZTqwJLJo-Y?si=A2of9-eoOkXpfBQI

Finally, I made some edits to Family Computing's New Years Eve program.  It was originally limited to the year it was published (1984, if I recall).  I thought it would be nice to update it so a date for any year (at least up to 9999) could be input.  That way, the program will be functional for many years to come.  Who knows, people might need their MC-10 to function in the year 2100...

Enjoy!

Addendum

I made some updates to Checkers.  I added graphics for king pieces and the ability to hit N for a new game.  I also streamlined the board display.  Turns out, everything in terms of squares get placed by the piece placement routine, so I didn't need a separate graphic routine to display the board.  I tested the game against the AI of a online checkers program on Medium difficulty and Collins' program beat it.  But it lost when I set the level to Difficult.  I just turned my phone upside down and input the computer's moves as my moves in Collin' game.  Then I input the moves played by Collins' AI on the phone.  If you take all the computer's pieces, it will sense the game is over and prompt you for a new game.  Otherwise, if the computer takes all your pieces, you can hit N for a new game (or any other time you want to give up).

You have to set the modern game below to "force jumps" and to let you move first. Here is the site I used to test Collins' game:

https://www.247checkers.com/