I ran across an interesting looking game ported to the MZ-80 by Joachim Froholt. He mentioned in the blurb for his YouTube vid that:
I translated Takaya Arita's Sharp MZ-80K classic Cavern 2160 to the Sharp MZ-80A (& english).
When I hear someone describing a Basic game as a "classic" my ears immediately pluck up. What is this classic of which you speak? The original game was published as a program listing in the July 1980 issue of I/O Magazine in Japan. I asked Joachim if he had a copy of the original source. He kindly pointed me towards a place where I might find a scan of the article. In the end I decided to simply look up as many videos of the game being played as I could to recreate what I saw using my own code and coding tricks to get speedy animation out of the MC-10. I did eventually get a scan, which was helpful in resolving a few details of the operation of the game, although I am still not sure if I have fully implemented the game, or implemented it with complete fidelity. For example, in my version there is an ultimate time limit. You get quite a bit of time to build your score, but as you do the game gets slightly harder in regular jumps (signaled by some random beeping). At these points the time it takes for the snakes to come back to life after falling shortens. But also, you can reach a point when the time will simply run out. That being said. I have never been able to play to that time.
The original game is described as a classic because, to quote the retro gamer blog:
Dr Takaya Arita’s game is a milestone release from 1980 – it has been considered “the original sandbox game,” and is a strategic digging game that arrived a good couple of years before the likes of Dig Dug and Mr Do. 36 years on, Mindware is now releasing the game on PC, in three different forms. The original version for the Japanese Sharp MZ-80 computer will be converted, and two remixed versions will be provided – one built to the specs of the Sharp MZ-700, and another built as a classic Eighties arcade game.
The game seems like it would be simple, but it takes a lot of strategy to remove earth in a way that prevents the snakes from overwhelming you or sneaking past and making their way to your "base" and thus, defeating you. I was able to find various version and ports to other system, including one with a pixel text drawn version of the original Japanese name of the game, which I was able to recreate as a title screen for my version. Strangely enough when I sent Joachim a video of the game I had recreated he noticed my port of "The Valley" and sent this message:
BTW, I see your last project was The Valley, that's a fun coincidence,
because I was involved with a version for the Sharp MZ-80A just
recently. I only did playtesting for that one. An interesting little
game, more fun than I originally thought it'd be. Here's a video:
It's a small world when porting projects are being done in such similar succession. Perhaps it's a sign that the pool of "classics" is somewhat limited. Maybe I'm coming to end of it! Let's hope not. Anyway here's the vid of my version:
Nuclear Submarine Adventure was a text adventure published in 1980 by Aardvark Software. Its author was Robert J. Retelle, who also wrote the Star Trek Adventure that I ported recently. Versions exist for the C64/128, OSI/Compukit, TRS-80, TRS-80 and CoCo. It seemed time to make a version for the MC-10. The source code was provided to me after an inquiry to the Coco e-mail list, by Guillaume Major, who oversees the Coco Archive. I found out about the game because Colin Appleby of the Grundy Newbrain Emulator site, asked me on solution archive forum whether I had the source. That sent me to Curtis Boyle's Coco game website. An inquiry to Curtis via the e-mail list (maintained by Dennis of maltedmedia.com) prompted him to respond that he couldn't place his finger on a copy of it, but the posting prompted Guillaume to hunt up a copy from some obscure disk and put it up on the archive. That's a lot of work being done by a lot of different people sharing across the internet to facilitate the retrocomputing hobby!
Anyway, SPOILER ALERT! Below I have included a walkthrough and a map thatI created as I game tested the ported source code. I had to simplify all the fancy music. This included a routine that ran a submarine "ping" noise while you are prompted to enter your command. No great loss... I found the ping a little annoying.
I think I found an error in the save routine. It didn't seem to preserve the variable that recorded that you had used the chair to smash open one of the hatches. So every time you saved you had to get the chair again and re-smash the hatch. I added that variable to the save routine. I also added the synonym "GET" for the "TAKE" command, and the options to use U,D,F,A as shorthand for GO UP,GO DOWN,GO FORWARD and GO AFT.
Found out "The Valley" actually started out as a very popular type-in for the Commodore Pet, which was then ported to a variety of systems including the original TRS-80 Sharp MZ-80, BBC and Apple. Here are some links discussing it:
I think, from what I have read that this classic RPG was first published in Computing Today April 1982. I was able to get a listing and based on that and the viewing of many pictures of various versions, I realized that the Newbrain version had departed from the original in some ways. The most obvious was that instead of having two castles at each end of the central "path," the Castles were simply placed randomly. Also, the map was redrawn every time you entered the valley scene from one of the other scenes (Swamp, Forest, Tower). By pouring over the original listing I was able to restore the game's function to be more like the original Pet version. I was also able to clean up the graphics quite a bit, such as making the castles look a little more like castles and the tower more like a tower. Adding better collision detection also prevents attribute clash between these elements. Now the save game feature actually saves the map info so the valley remains steady from saved game to saved game. Lots of other minor fixes too. Here's how it looks now:
Now forests and swamps, like in the Pet version, are two characters wide. The tower is two characters high. Also revamped the beginning instruction screen to provide more detail about the keys used in the program and revamped and sped up the key input to allow for the option to use all eight directions, instead of just up down left and right, as I think it was in the Newbrain version (which made moving very tedious). Now you can use either:
QWE
A D
ZXC
or
TYU
GH
VBN.
The original used the numeric keypad for movement. Since mine uses the left letters of the keyboard you must press R instead of E to get a report of your rating level and what items you have recovered. I also changed the map routine for the Tower, Lair and Temple so that it used the original Pet routine:
Now the maps are much smaller (and less tedious to explore) and more interesting than the ones generated by the Newbrain code:
I also changed the lake and island drawing routine for the Swamp and Forest to use the Pet code. On the whole it has been a very satisfying project. I've learned about a classic RPG and done some intensive code fixing with the help of a very nice article published in Computing Today back in 1982...
Here's my final project of the October Retrochallenge. I finished just a little too late to make the 31st deadline, but in the spirit of better late than never, I'll post about a porting project I embarked on over the last week to help cheer myself during one of the most challenging times I have at work every year, midterms! Lot's of marking of exams and papers makes this a time, along with mid-winter, that I really need some pleasant distraction.
Grundy Newbrain 8-bit computer
I am a member of the CASA website "Solution Archive" dedicated to Interactive Fiction, including classic adventure games. Colin Appleby joined the group and asked a lot of questions in the "classic forum," about adventures with versions for the Grundy Newbrain 8-bit computer of the UK. He was looking for games for this quirky little 8-bit machine, which was a little like the MC-10, in that it never really gained a big enough market share to be considered one of the mainstream home computers. Like the MC-10, it was bit of an outlier, which is just one of the features that can make a machine so endearing as an object of retrocomputing interest.
One of the games Colin mentioned in his posting was a Basic RPG called "The Valley." This, of course. elicited some complaints from the IF purists in the group that it wasn't really an example of interactive fiction or text adventuring. I think such distinctions are rather arbitrary and was quite happy to hear that Colin had made the file available on the Newbrain emulator site. I am always on the lookout for basic source code!
Kayde Manual
The game is from the Kayde company and was originally distributed on tape. Colin's distro not only included a file for loading into the emulator but also the text source code. Oh how I wish everyone who distributed Basic games for emulators did this! It means you don't have to figure out a new system, its emulator and all the tricks about how to get a Basic file in text format out of the system. The source also lists Chris Despinidis as contributing some debugging. I think Chris is the maker of the Newbrain emulator. See: http://www.newbrainemu.eu/ for more info about the Newbrain.
The Newbrain has a 40X24 screen and the game uses simple "text graphics." Since the MC-10 doesn't have 24 lines, it was useful to be able to use the 64X32 8 color low-res graphics to recreate the text maps. Instead of using various characters to represent the objects on the map (forests, lakes, castles, dark tower, woods, safe path, swamp) I was able to use colours. I also had space left over on the right hand side to put a colour key to explain what each colour represented, since 64-40=24 dots or 12 characters. Luckily there weren't too many items, so 8 colors and black were basically enough to represent everything needed for the maps, with only a little careful doubling up of some colours for slightly different uses on the 3 basic types: terrain, forest/swamp, and castle/tower. The result is a little speedier than the original (I was able to get the game up and running on the Newbrain emulator to help with the porting project), which I think is simply because the MC-10 was developed about 3 years later. As usual, I never know if I have fully debugged, but I will continue to play the game for a while and hope to weed out any that may be left.
In fact, I think I might have spotted some bugs in the original source. I shared this info with Colin on the MC-10 Facebook page. I found an error in line 3820 of the original source that I had downloaded (back in September) that involved a missing colon before a PUT command (how the Newbrain outputs special characters to the screen). Having had my source for some time it's possible Colin or Chris has debugged it in the meantime. I also noticed that line 9000 should probably have had a GOSUB20000 in it instead of GOSUB2000, since the former was a commonly called subroutine, whereas the later was definitely not. However, this GOSUB would possibly never have been triggered in the original because it was in an IF statement looking for a character 230, which I could not find "PUTed" anywhere in the source. My best guess was that a code 254 was what was really needed and adjusted my MC-10 version accordingly to use the right POINT check (to sense the color of the screen locations and return a number from 0-8 for the color found). The command now randomly triggers a message that there is no entry to the buildings on the islands (in the middle of swamps and forests) from the direction one is coming and to seek another route in. So perhaps, the MC-10 version has a feature that even the Kayde original lacked?!
Thanks to John and the other participants in the Retrochallenge, and to Colin and Chris over on the Newbrain site for sharing their retrocomputing enthusiasm!
I have a colleague at my university, who when I mentioned my interest in old Basic programs recalled playing a game called "Fur Trader." I told her that I had done a port of a classic simulation called "Oregon Trail" and I think she said that she had played that one too, but had really liked Fur Trader because of its connection to Canadian history.
Since I had so much fun porting and playing Oregon Trail, and I'm also a big Canadian history buff, I thought I would try to look for Fur Trader. I can almost always find a TRS-80 version of any classic Basic text oriented program so I went to one of the major archives for that system that I've stumbled across over the years and looked under the "F" filename section. Sure enough, there was Fur Trader. I then used a handy little utility called TRSTools by Mathew Reed to view the Basic source on any TRS-80 disk or cassette file (for a cassette files you must first drag and drop the file onto a virtual disk). Here is a link to an Atari site with a page scan from the a David Ahl book of games that includes the game.
Then it was just a question of cleaning out the commands distinct to the elder TRS-80. Micro Color Basic doesn't have the DEFINT command, for example, to allow designating variables as integers. Everything must be floating point for the MC-10 so sometimes some strategic INT functions must be added to a program if there are operations that really need only an integer. In the case of Fur Trader, the program used a number of PRINT USING commands to format trading values and costs to two decimal places and with a leading dollar sign. Over the years I've built up a collection of special Basic routines to recreate the functionality of commands like this. I had one in my collection for printing values with just two decimals and no leading space (so the dollar sign can be right next to the first digit). Here's what it looks like:
You assign the number to variable CC and then GOSUB 8. The subroutine returns string I$ formatted to two decimal places and no leading space. You can then print it directly or add it to another string for printing or further string formatting, such as my word wrap or reverse video printing routines, which generally take M$ as their input.
As with my conversion of Oregon Trail, I added some simple graphics to try to help spice up the program a little. In this case I used my SKETCH program to draw some simple fort diagrams. Here is Fort Hochelga (Montreal):
The original title screen describes the program as follows:
You are the leader of a French fur trading expedition in 1776 leaving the Ontario area to sell furs and get supplies for the next year. You have a choice of three forts at which you may trade. The cost of supplies and the amount you receive for your furs will depend upon the fort you choose. You also specify what types of furs that you want to trade.
It's a very simple simulation. Basically you choose the fort you want to choose to trade at from a selection of 3 possibilities and the numbers of different types of pelts. The game randomly selects some hazards and trading prices depending on the fort. I'm not really there is much skill or planning involved. I haven't examined the code in enough detail to figure out whether there is anything more systematic than random numbers that determine the prices, but I think the hazards you run across on the way to the chosen fort are pretty much completely random.
An interesting bit of historical detail is that the Iroquois were traditionally the implacable enemies of the French since they had sided with their arch-enemy, the Huron, which is why your French trading party is in peril crossing Iroquois country on the way to one of the forts.
My hope is that when my son Charlie gets back from his first term at university that he might be able to help program in a brief snippet from a coureur de bois paddling song to add to the intro, or as part of a "travelling" interlude routine. He's my MC-10 sound programming expert. We generally use my MUSIC program to type in notes and then print a list of them as SOUND #,# statements to a text file using the MC-10 emulator's print to file function.
Here's a video of the program as it currently stands:
Another little program I made this month was a simple graphic demo. I subscribe to a number of Sinclair ZX81 Youtube channels. The ZX is the spiritual predecessor of the MC-10. It was obviously the inspiration for the kind of computer the MC-10 is-- an ultra-low-end entry level 8-bit. However, that market had largely disappeared by the time the MC-10 was released in 1983. The classic 8-bit home computers (Atari 800, Commodore 64, Coco) had simply come down enough in price to make ultra low budget machines unnecessary (except for poor flinty losers like me). But I digress. Unlike the MC-10, the ZX thrived in the brief heyday of ultra-low-budget-computing that it helped create. It has lots of fans and lots of Basic programs written for it. It also has a standard graphic resolution of 64 X 48 block graphics, which is a resolution the MC-10 also has in the form of its SG6 screen mode.
Youtuber ZX81 Programs ZX81 has put up a bunch of videos of simple, but interesting Basic programs written for the ZX81. One of these was called "ZX Type-in Program Pattern 2:"
Since the MC-10 and ZX81 share a 64X48 graphics resolution it was pretty easy to port the code I could see briefly listed in the video. The MC-10 lacks a PLOT command, but it can still do SG6 graphics with a few tricks using POKEs. My port uses a special Basic SG6 plotting routine I developed HIRES_SET&RESET2.TXT and not Greg Dionne's M/L plotting routine that I normally use in most of my SG6 programs. However, the MC-10 version is still faster than the venerable ZX81, but the ZX came first and blazed the trail!
Anyway, thanks to ZX81 Programs ZX81 for posting his videos and thanks to the archivists who have contributed all the wonderful free Basic software for the TRS-80 available on the Net. And thanks to Creative computing for it interesting simulation and my colleague Janice Tulk for the suggestion for another fun porting project!
As with many of my programming projects I got my inspiration for Deep Scan via some retro video watching on Youtube. I was browsing game videos from the NEC PC6001. I like keeping track of stuff about the NEC PC because it uses the same neon green wonder of a video chip, the Motorola MC6847, as the MC-10 (and Coco, Dragon, VZ200, etc.). Retro Gamer Z posts a lot of play-through videos for the NEC PC. I've subscribed to his channel, so I see when he posts new things. He posted a video for a game called "Deep Scan."
It was in hires and has lots of wonderful sound (the NEC has a fancy sound chip). Most certainly it was written in machine language. However, I thought the concept would work quite well in Basic. I also felt that I could probably bring all my best tricks to bear on making the animation fast. The resulting game, also called Deep Scan in honour of its inspiration, is pretty fast, although I am under no illusions that it is M/L fast. I'm just happy to make it as fast as possible within the restrictions of Micro Color Basic.
The main action of the program takes place in a tight FOR/NEXT loop starting at line 20--the number I commonly use for the main loop in most of my programs. The most commonly called subroutines usually start at line 1. Line 0 usually dimensions all the variables and then jumps to the startup routines, such as displaying the instructions, which are all located at the end of the program. I use only single letter variables and as few of them as possible, which includes recycling variables for multiple functions if possible. I declare the most commonly used variables in the DIM statement first, since I have been told they are looked up by the basic interpreter from a list in order of declaration or first use (i.e. further down the list takes longer to look up). I use pre-calculated arrays to store the correlated set-reset x/y locations for all the possible screen locations that a sub might be at. That way I can use an array to store each sub's location and the x/y locations for its continuously firing torpedoes, but when I need to re-fire from its current location, I don't have to calculate the new x/y location for its specific screen position. The program just consults the pre-calculated x/y array locations for the current position.
When it comes to checking for the characters hit by the depth charge I use a 255 element array for all possible characters with numbers stored in them usable by ON/GOTO or ON/GOSUB commands. The commands can then act as a single check for multiple possible actions depending on an character occupying the location to which the depth charge will move next. The next location is searched simply by PEEKING the screen memory location of that position and then consulting the array using the number returned. So, the blue water character of 175 is left as zero, whereas the characters for the subs have 1s put in their array locations, and torpedo character has a 2. This way, an ON/GOSUB line#1,line#2 routine can be used to either simply allow the depth charge to continue falling (the 0 value defaults to jumping past the ON/GOSUB options) or the sub hit or torpedo hit routines (line#1,line#2).
I use the same array to store numbers for the various actions of key inputs. Since the program only uses A for left and S for right and the Space key for depth charge, I just need to store a 1, 2 or 3 in each of the array locations corresponding to the ASCII values of each of these keys. Then, one ON/GOSUBline#1,line#2,line#3 will handle what to do when any of these keys is pressed. One ON/GOSUB therefore can do the work of three IF statements, which speeds the program's execution and provides Basic with something like the functionality of a SWITCH statement used in higher level languages.
Other speed measures include having torpedoes only check for hits once they move above the dark blue water. Otherwise they just keep moving up. In other words they don't interact with other subs, other torpedoes, or the player's depth charge. They just keep moving up to the level of the Cyan sky. Once there, a check is made if they hit clear sky (Cyan) or the ship (Black). Sky=have the sub fire another shot. Black=ship hit. I think in the original NEC game shots can be blocked by other subs, torpedoes or the depth charge. By simplifying the complexity of the interactions between virtual objects, limiting the objects to single SET/RESET pixels or characters (the torpedoes), or single line PRINT@ strings (the subs and ship), some reasonably speedy animation in Basic can be achieved. In other words compromises must be made between speed and complexity, but I think virtual worlds can be created in Basic that are complex enough for reasonably good game play.
That being said, I know my games will have a limited possible interest for people attuned to modern computer gaming. Perhaps they might appeal to a very small number who remember the simple Basic type- games of the early 1980s with great affection. Perhaps they might only appeal to me. Yet, when it comes to a hobby it doesn't matter how many other people share one's interest. It was certainly fun in and of itself, to spend a number of hours crafting a "type-in" style game. And it certainly took a few hours, and multiple false starts at thinking I had finished. First I had to refine the startup screen a little to make it a little more interesting than the rudimentary one I started with:
This version also had a few fixes. I had to play enough games to notice that sometimes the bonuses could be randomly plotted in locations to the extreme right that the sub couldn't reach it with its depth charge. I also tweaked the number of lives awarded from a random number of 1 or 2, to just being 2. The game was tough enough that giving 2 lives if you survived 3 screens (when the bonuses appear) seemed reasonable, and more fair than a random number. Such fine-tuning can only come from playing the game a lot. I also eliminated a fourth size of ship, which I found too hard to play. You want to avoid unfairness and arbitrary death as much as possible, which can be tough to achieve in Basic games (or impossible, at least according to my Xbox jaded son).
My last major fix was that I noticed that I had a completely unnecessary array. I had a whole array for all the possible screen locations for the subs. Then I had an array which held a number that I incremented or decremented to point to that array. Stupid. I don't remember the rationale, but I just needed to store the actual screen locations for each sub and increment or decrement that, not a pointer to an array with screen locations. It just goes to show that you never know whether you have fully streamlined a program. Continuous play and reexamination of the code can turn up efficiency improvements even after you think you've done everything possible. Most people will probably find it difficult to discern any substantial difference in speed between the various versions, But such subtle and obscure perfections are what hobbyists live for....
If you try the game try please let me know what you think (unless you are my son Charlie--XBox has ruined you boy, at least for the purposes of Basic Beta testing:). And any suggestions for game improvements or new features would certainly be welcome. My next Retrochallenge post will be about two other programs I worked on earlier in October, Fur Trader and a graphics demo from the Sinclair ZX81.
Thanks to the help of Darren and jdiffendaffer on the MC-10 Yahoo group I was able to figure out the esoteric features of SG6 graphics mode to port a miniature golf game by Mitch Voth(Softside Magazine, Vol 6, no. 7) for the 16K TRS-80. I used Greg Dionne's M/L USR utility (a BASIC subroutine that pokes a USR "SET" function into memory for setting SG6 64X48 graphic points on the screen). I had to figure out a way to do without a point function by simply looking if the byte location of the screen map changed after plotting (i.e. no change means the point is already lit in that byte region). My conversation with Darren and J.D. did help me figure out how to reset a point, which allowed me to get a nice cursor flash function built into my port. Darren figured out a M/L USR "POINT" function (which can also be poked into memory), which I hope to use in future projects or possibly to improve some existing games. I've added that routine (HIRES_SET&RESET2.TXT) to the UTILS directory of my Github site. Thanks again to all these folks for their help in my programming projects. As can be seen in the pictures above I used my SG6 Basic text plotting routine to print the 3 message lines at the top of the TRS-80 original. Of course I had to condense the information to just the course #, par # and player's name (limited to 5 characters). Luckily the original game already doubled the pixels to draw the maps and ball on the 128X48 screen of the TRS-80, so representing it on 64X48 screen was no problem. I just had to half the pixel plot values and remove the second pixel plot done for all the SET commands in the original program. The original also used a period character for target for each hole. I used a red dot instead, and therefore had to re-program a different piece of code to judge when a ball enters the hole. I have also made a couple of little fixes to my programs lately. My son Charlie left for Dalhousie University so his bedroom in the basement has been reverting (somewhat) back to my MC-10 "man cave." I also made a number of Retrocomputing presentations at our local Cape Breton CaperCon gamer and sci-fi convention. As part of that project, I got an old android tablet to work as a WAV file player for my real MC-10s to replace my tape cassette player. So I have been playing a lot of my games on the real hardware lately. I noticed that I hadn't properly entered the map data for the last map of my port of Robot R-29. I also noted a misspelling in my port of Lance Micklus' version of the classic Star Trek III game. His version is very rich and complex. Here's a link to a video of my port from the TRS-80 of TREKIII:
And here's a video of my version of Miniature Golf (Note: I have added a few speedups since this video was made):
Thanks to John and Neil for mentioning my Robot R-29 project in their last Coco crew retro podcast. They gave me a little good-natured ribbing about being a Basic programmer but I still highly recommend their podcast for people interested in all things TRS-80. We Basic programmers are used to hearing such sentiments from the M/L and higher level language master race;)
Next post (hopefully) a Retrochallenge project of some sort.
I have been very busy lately porting programs from various sources. Mostly I have been using the large number of PDFs available from various archives of classic 8-bit computer magazines you can find on the net. Often I simply stumble across someone's post in some forum about a classic Basic game they remember playing. They might mention a magazine and sometimes even an issue and other details that allow me to track down a version of it.
This is how I stumbled across the source code for my very latest porting project. I think I probably did a search on Google like "GOTO GOSUB robot." Maybe I also added the term like "Atari" and tweaked Google to show only sites added in the last year, to see if anything fresh had shown up (i.e. I know I've already searched on "GOTO GOSUB robot" before). Somehow I ended up running across Computer Science by Rafal Bujakowski in which he talks about his programming exploits porting an old Basic type-in game to the Commodore Amiga dialect of the language. It was called "Robot R-29" from a Polish computer magazine from his youth called "Moje Atari" or "Your Atari." Maybe what drew me to his site was a graphic image. I often switch Google to display images rather than sites and then quickly browse for obvious 8-bit computer "screen shots" (i.e. employing simple text graphics).
After finding his site and reading about his interest in the game and where he found it (he had included the graphic image of the actual page you see above) I was able to find the entire magazine on the net. Then I could get a proper printout of the page and begin the process of typing in the program and converting it to MC-10 Basic. Luckily, I didn't have to type in all the maze info because Rafal had helpfully supplied the source code of his update of the program to Commodore Amiga Basic. His listing included DATA statements with strings containing the 5 maps of the original program. It was a very elegantly written program and the elements unique to Atari Basic were not too difficult to figure out.
Still, I also found it helpful to download the Altirra Atari 8-bit computer emulator and search for a program rom/cassette file for the game. It was a bit of learning curve getting the emulator up-and-running, loading the image figuring out how to connect a joystick to my PC and to get the emulator to use it (the game only used joystick for input). But once I got it working I was able to see how the game played, which was helpful in figuring out the program logic of the original listing. I have emulators now for all the major 8-bit machines that used the Motorola MC6847 video chip that the MC-10 used (Coco, Dragon, NEC PC6001, Dick Smith VZ-200, etc) and also for Atari, Commodore and TI. This really helps with my porting activities and is a fun way to learn about other machines and their quirks. For instance, I learned (after a little frustration) that Atari Basic doesn't like "LIST 100-200" to list a range of program lines, but rather requires "LIST 100,200." So "un-microsoft!"
After overcoming all these little hurtles I was able to get a neat little puzzle game going for the MC-10, which should also be easily portable to Coco and Dragon with a few edits. Here's a vid:
I have also done a lot of other porting exercises since my last post, each with its own quirky adventures of hunting down the code, figuring out the quirks and differences between types of Basic and tweaking the code to Micro Color Basic. Here's a brief rundown:
A classic text adventure found on some virtual Coco disk and transferred to PC using the utility decb.exe. Here's the command I use: decb copy -a blank.dsk,WILLBURG.BAS WILLBURG.TXT Of course I have already saved WILLBURG.BAS onto the blank.dsk using the VCC Coco emulator. It can be saved as an text file using the standard disk Basic command SAVE "WILLBURG",A
The comma followed by A means the program is saved as ASCII text.
Back from the Klondike is an original program that implements one of Sam Loyd's most famous puzzles, first printed in the New York Journal and Advertiser in 1898.
Sea Battle, is, I think, a classic Basic game from one of David Ahl's collections. You command a sub which must maneuver around a grid map destroying enemies and sea monsters while avoiding being hit or eaten.
Atlantic Balloon crossing simulator. Ported from TRS-80 Model 1/3. Inspired by a talk on TRS-80 games presented at the Games Developers Conference (GDC) by Jim McGinley. Thanks for the inspiration Jim!
Update to the drawing program I use to create images for use in games. Now with large text entry and circle draw routine added. Also took out some bugs. You can print the screen to text file in the emulator and then edit the result in Notepad for easy inclusion in programs.
Another Star Trek text adventure with the original cast member names restored (which had been altered to protect the guilty in the past when copyright still applied).
Captain Chemistry. Quiz program for chemical elements. ported from Coco. Son tried it. Got perfect (or almost perfect), but he was studying for his Grade 12 IB Chem exams at the time. Way to go Charlie!
Simple navigation of a moving pixel through a maze game. From Compute! magazine when they were still covering the Coco. Compute's coverage of the Coco didn't last long but it provides a rich ground for finding programs to convert to the MC-10. Compute typically made programs that had versions for many 8-bit platforms, so concepts had to be simple and usually stick to simple screen graphics.
Original game program with a panning star field as you move in any of 8 directions and two Romulan Warbirds who dart forwards and backwards towards you. You must try to move your ship using the 8 direction keys:
T Y U
G J
V B N
until a warbird is in the centre and then zap it using SPACE. You must be quick or they will get too close and zap you! Five different sized images simulate the warbird's distance from you. You only have 3 lives.
Success Mansion. A text adventure for the Coco from Rainbow's Book of Adventures. Original version supported Speech Synthesizer Cart. had to remove all that stuff and perform my regular pare-down techniques to fit it into 20K. Load in two parts. First part is the program. Second part is the DATA for the main array of locations. This saves having to have DATA statements and memory for the array. By loading array directly from tape you, only need the memory for the array. I don't think I have ever seen a walk-through published so here's a map:
Instructions:
You start on the porch. MOVE or PUSH the MAT to GET KEY1. Don’t GO SOUTH or you will be forced to exit the game. Basically GET every object mentioned, MOVE every object, LOOK every object and OPEN if possible. Once you have the keys you can UNLOCK all the doors (--[]--). The PAPER and the CARD reveal codes to type into the PANELs. Type OPEN PANEL and then the prompt will switch to one to allow you to type the codes. Once you have all 13 scrolls go to the exit. Use INVENTORY for list of items (No max, but will not list all if you have too many). You really only need to keep KEYS and SCROLLS.
Game ported from magazine found on-line, probably just while browsing through an archive. I believe it is from Your Computer magazine, which was a general home computer magazine in Britain in the 80s. Because it covered all 8-bit computers, it sometimes had games for the Dragon 32 (i.e. British Coco), especially in the 1982-1984 period. Just stumbled across "Time Slider" (the article title) which had a listing of "Time Switch" (the title used in the program itself). Called the version I created for the MC-10 "Slider" because I already had program called switch. Probably should have used the filename "TSWITCH" but I prefer complete names. It's a thinly veiled Dr. Who text adventure, which again tries to avoid copyright infringement. I added a little graphic of a blue box at the end to overcome any such confusion.
Got a message one day from someone from Brazil. Érico had run across some of my videos and mentioned them to some of his mates on a forum for a modern variation of Basic known as GLBASIC. Here's what he said
On
a different note, as curiosity, I currently do my games with a variation of
basic called GLBasic.Back
in our forum, we have a couple tandy color computer users and the subject comes
up every now and then. Once we were talking about this mode and how I would
like to do a game on this mode on modern computers and we then thought to try
it out on a real coco.Matchy
did a wonderful semigraphics paint tool in glbasic that would spit coco code
and it would work fine on a PC, let me point you towards this:http://www.glbasic.com/forum/index.php?topic=9675.90On
page 8, you have Matchy´s code for that.I´m
not sure you have to be logged to see code or images though.Cheers! -- Érico
The graphics he had created were absolutely amazing.
A closer look revealed, as he himself mentioned in subsequent e-mail, that the top picture was not really in keeping with the restrictions imposed by the nature of semi-graphics mode 3. There is no attribute clash, for instance, between the orange feet of the two top dudes and the underlying green of the ground. The middle picture is more in line with the quirks of the semi-graphic characters used on the MC-10. You will notice that the feet are surrounded by black pixels, which is the only alternate for any color in one of the 32X16 zones of the screen grid. So I was drawn most directly to that image.
I had been wanting to make a better boxing program than the one I had scrounged up a few years back from the VZ-200/300. It had been a challenge to convert and I was hopeful that it would be fun to play, but I recall being somewhat disappointed once I had got it working. Here's what it looked like:
I can't recall exactly whether it was the game play or the graphics or both that I found somewhat lacking, but I do recall thinking that something better could be done.
One reason I wanted something better was because I had seen an interesting boxing game on another computer in the MC6847 video chip family, the APF Imagination Machine. Here's what it looked like:
APF Boxing
I remember when I saw these images and also some videos about the APF thinking "Hey I could probably do something like that in regular MC-10 Basic!"
But after seeing Érico's lovely mock-up image of the two karate fighters I realized that something even nicer could possibly be done. I could make a game with slightly more realism than the clunky boxer figures above, and also supply the MC-10 with a BASIC rendition of the classic martial arts game motif as well.
Making the game was not hard. First thing I did was fire up my trusty SKETCH program. It is a modified version of William Barden's "Computer Sketch" program from his book TRS-80 Color Computer and MC-10 Programs. I had modified it to output the screen to printer, which in the Emulator takes the form of an ASCII text file. Then it's a simple task of cutting and pasting the bits needed from the resulting file into Wordpad. You can use just pieces or even whole screens. You can usually recognize what is there and divide it up into strings as needed. Here's a sample of the kind of output you get from SKETCH:
This is a printout of the screen designed for my KONG program mentioned in my last post. Here's what the image looks like on the MC-10 screen:
After a while you get used to recognizing the symbols. For examples € is the standard black CHR$(128) character. You can leave more space around things if you are just drawing single items, which makes cutting things up into strings a little easier.
In the course of using my version of Sketch, I ran across a bug, so I got a little sidetracked for a few days tracking it down and fixing it and also making some nifty changes and updates. I added circle drawing and large text entry. It's just an occupational hazard to get distracted. I have a whole directory on my github filled with unfinished ideas and projects: https://github.com/jggames/trs80mc10/tree/master/quicktype/Current%20Projects
I got distracted cleaning up my repository too.
However, it didn't really take all that long to get a working game going. I had to sketch out some variations of the Érico's figures to provide animations for punching and kicking. I don't how well they turned out, but they'll do for now (unless Érico sends my some better variations). The tough part was refining the fighting routines. It's a very simple game. If you step close enough to your opponent, your character strikes out with a random move and knocks the other character backwards out of the hit zone. That is to say, they get knocked back unless they are already too far back (i.e. with their back against the "wall"). It doesn't pay to push your opponent to the point that his back is against the wall because then both player's just end up equally exchanging blows until the attacker steps back. In other words, the game is about trying to dart quickly into the middle area of the screen, strike a blow, and then hop back before your opponent strikes a return blow. Since the AI of the computer player is randomized, with slight variation according to level of play, it gets more and more difficult to achieve safe blow and retreat in time. The algorithm of the AI is more predisposed to attacking than it is to standing still or retreating at all levels, so basically it becomes more aggressive as you go higher in level. It works pretty well I think. The computer obviously can be very quick (since its continuously checking whether to attack, stand still or retreat), but you have the advantage of being able to think carefully about when to strike and how much to retreat (two or three paces is pretty much the most you can get). The best strategy is to always try to replay any blows and avoid pushing your opponent into a corner. Other than that its pure reflex speed and ability to button mash with gusto. Here's a vid:
I've slightly tweaked the AI since this video was made and fixed up some other things. For instance, I added multiple randomly occurring grunts from the the two players, instead of distinct one's for each. I watched some videos of real karate competitions, and I would have to say that many of them are darting duels of quick blows and retreats, interspersed with flying kicks.
I would like to thank Érico for sharing his ideas and his experiences as an Brazilian Color Computer clone user. It's nice to see a growing presence in the forums of people from this Brazilian aspect of the Color Computer family. The history of the 8-bit computing phenomenon there is fascinating and quite unique. I've really enjoyed learning about it over the years, including browsing some of the magazines such as the Brazilian version of Input magazine.
Érico also sent me an image of his recollection of a game he had made on his computer. He also described a little how it worked. Based on his recollection, I came up with another game, which I was able to cram into 10 lines in the hope of entering into the NOMAM 2016 competition, but I was too late for this year. Oh well, perhaps the "Monteiro Challenge" will make it into next year's comp:
Anyway, I don't know if any of these game are any good as games, but they're sure a lot of fun to program. So if there are any folks out there reading this blog (and I don't know if there actually are), and you have any ideas for games (or other types of programs), then please send them my way.
I was also contacted recently by Matt of of the MC-10 Facebook and invited to join. I unfortunately had to refuse, as I have tried to draw some lines in regard to the number of social media I will use (and types). He mentioned that some of the folks there are trying to create a better joystick mod/add-on for the MC-10. I told him I would be happy to fix any games to work with it when it comes to fruition. I hope that it does (the Matra Alice had one). But I should have also told him to convey my willingness to respond to suggestions for games from anyone on that group. So if there are any such folks reading this, feel free to send me suggestions by way of this blog, or plain old e-mail and to tell others on Facebook that I am open to such suggestions.
And please, testing my games and sending bug reports or suggestions of any kind will be much appreciated. Although I like making games, I'm not much of a player, so beyond some basic testing, many of them have not been tested to their limits. I'll try to acknowledge any such inputs here. Recently, for example, someone commented on my port of the TRS-80 classic, Atlantic Balloon Crossing, that the way the display worked seemed a little confusing. Notice the list of items at the bottom of the main display. The first line displays the title and the line below it displays the value:
Such an arrangement works fine on 63 character wide screen of the TRS-80 Model 1/3, but is too cramped for the 32 character wide screen of the MC-10. I should have realized this, as I have had lots of experience converting TRS-80 games to the MC-10. Such experience has taught me that there is almost always some way of arranging information using shortened messages, acronyms or taking advantage of the reverse characters available on the MC-10, to convert a display from the 1024 character screen of the TRS-80 to the 512 character screen of the MC-10 without much loss of clarity. So with some prompting from teddybearharv I got off my duff, and cleaned up the display a little more. Very helpful. Thanks teddybear! And thanks Érico and Matt! And thanks to Jim McGinely for his video about the gaming on the TRS-80 which inspired my port of ATLBALN.
Here's the updated version of that program:
Next post, some of the tricks used to convert the MAP screen and other graphics from TRS-80 to MC-10.
It's been a while since I posted. I have been busy mostly with creating 10-liner games for the NOMAM competition. The competition results came in and I was able to crack the top 10 in a number of categories. I think this is something to be reasonably proud of since the MC-10 is such a modest 8-bit computer and the competition included MSX systems, the Commodore 64 and the latest of the Atari 8-bit line, along with all their bells and whistles, including updated versions of BASIC. That being said, I too used a few tricks involving an updated version of Basic for the MC-10 called MCX Basic. This extension to the language by Darren Atkinson adds all kinds of commands. However, it is not compatible with a regular MC-10 without using add-on hardware or lots of fancy loading of special software. I generally want to stick to writing programs for an ordinary MC-10 so I only used MCX (under the emulator) to allow me to create programs with lines longer than the normal 128 character limit. It's nice to have the space to cram just a few more things onto a single line if I need. Of course I can already do this (somewhat) by replacing PRINT commands with questions marks ("?"). When these get expanded to full PRINT commands the line can go over 128 characters. Using MCX I can get lines almost up to 255 characters long and regardless of how they are entered, programs with long lines load just fine in a regular MC-10.
The 10-line programs I ended up submitting to the competition were the following:
MINIPAC (version of Pacman arcade game)
AREA51 (text adventure)
CAVMARS (descent in a randomly generated cave, while collecting fuel from the sides)
KONG (version of Donkey Kong arcade game)
MINDUNG (3D first person dungeon crawl)
DASH (Puzzle game based loosely on the arcade game Boulder Dash)
There were difficult challenges to fit these programs into only 10 lines each. I had to really refine some techniques to reduce the number of lines used. These techniques included new ways to process key input that don't require use of multiple IF statements and techniques using ON-GOTO commands, arrays and pointer variables and variable assignments combined with logical tests to accomplish multiple tasks, so that multiple IF statements could be done away with.
In regard to key input, I generally used a technique I've discussed before of using variable assignment commands with logical operators embedded in them. So a command like this:
will allow X and Y to be modified continuously depending on which of the standard cursor keys are pressed on the MC-10. If you need boundary checking this can also be added:
X=X+(I$="A"ANDX>0)
will only change the value of X if it does not drop below 0. This method takes advantage of the fact that logical operations return either 0 if false, or -1 if true on the MC-10 (I think some non-Microsoft Basics used 1 for true). This is why I have to subtract from Y in the example using (I$="Z"). When Z is pressed we want to move forward/downward one space, so we must negate the -1 returned by the operation to get a positive value added to X. If you need to modify your input by values other than 0 (i.e. no modification) or + or -1 just times the result by some value. Sometimes, for example, it might be speedier to have a single POKE or PRINT@ location for a moving object, and then changes its motion to +-1 for horizontal motion, or +-32 for vertical motion. In such a case you can just use:
POS=POS-(I$="Z")*32
to get the right kinds of changes to your object's position. Remember, if it turns out to be false the 32 will be times by zero resulting in nothing being added to POS. If you need bigger jumps just use bigger numbers (i.e. *2 in the horizontal, or *64 in the vertical).
This kind of method can save a lot of use of IF statements for boundary checking and determining which keys have been pressed.
The other method of doing multiple IF/THENs on one line that may not even be related to a single function is to change variables to some desired value, do a check using an ON-GOTO function, and then change those values back to what they were before the test before proceeding onto other variable changes and checks in the line. So, for example, you can have a line like this:
In this example line 9 can assign a new value to A and then branch to line 1. It can also assign a new value to C and proceed to line 2. As long as you have a good awareness about when the conditions you are searching for are triggered, it will be possible for you to construct lines that do a multiplicity of checks, variable changes and branchings and even other possible actions (sound events for example), even if these have nothing to do with each other. With the use of the MCX 255 character line technique, you can pack a lot of decision making activity into a single line. I had to use this technique a lot in my 10 line adventure game AREA51. Text adventures need to engage in lots of decision making and event triggering.
By using lots of array variables, loaded with different stuff in their various numbered slots, you can mimic lots of event decision simply by changing certain pointer variables to those slots in the array variable. For example, you can change whether a win or lose message is printed at the end of a game by changing the variable WINSTATUS used in an array WINMSG. If WINMSG$(0)="YOU LOSE" and WINMSG$(1)="YOU WIN" all you need to do is PRINTWINMSG$(WINSTATUS) at the end and make sure that WINSTATUS is set appropriately somewhere in the program, such as in one of the densely packed decision lines. In general, I had to use lots of arrays and lots o pointer variable in these programs, but hey the limit was just about the number of lines used, not the amount of memory wasted! I was also able to use variation on the techniques above used for processing key input to change the pointers values to array locations. So you could do something like this in regard to the WINMSG$ array. WINSTATUS=-(DEAD=1). Such a construction allows for something to be checked and an event like printing the right message at the end of a program to be done without having to use a line wasting IF command. The MC-10 doesn't have an ELSE command so any IF command will utilize one whole line just for itself.
By using the variable assignment structure of A=B with B replaced by a bracketed logical operations with the appropriate sign in front of it and multiplied by whatever values besides 1 that are required, along with arrays and point variables, you can fit a lot of actions into a single line. My sense is that these techniques really move Basic to being a lot like assembly language or higher level languages like C. If that's so, I guess I should really get off my duff and learn some of these other languages, instead of just persisting in my use of Basic. My fellow MC-10er Greg (phyber0pt1k) from the MC-10 group on Yahoo, for example, has generously created a whole set of machine language lessons (very professionally done I might add) to entice people like me into the joys of assembly language coding. It is a very generous contribution to the group on his part. I certainly recommend it to anyone with an interest (they're in the "Greg Folder" in the files section of the group). For me though, programming is more like knitting. Porting the existing Basic code from some other machine or writing my own small programs (the 10 line thing has been very nice) is something I can almost do without thinking while sitting with my wife in our den as she watches curling or the news in the evening. I don't think this would be possible while learning assembly, so I unfortunately have to pass on Greg's generosity, at least for the time being.
I'd like to thank the organizers of the 10-liner competition and especially Gunnar, for all the work they put into running, judging, and publishing the results of the competition. They had over 80 entries, which must have been a lot of work to get running (on various emulators) and then to judge. The large turnout is an indication of the vibrancy of the retrocomputing hobby. Here are some links to videos of my entries which I haven't already discussed or shared somewhere else in this blog:
CavMars
Kong
Area51
In my next postings I'll discuss some of my most recent ports from other computers (i.e. code scavenged from the net) and some games inspired by the suggestions/visual mock-ups of a Brazilian Coco clone user from back in the day, Erico Monteiro.
