In my ongoing search for Basic game ideas I have found that trawling through the web for materials on machines sharing the Motorola MC6847 Video Graphics Display (VDG) chip to be useful. One particularly useful system for this has been the NEC PC6001. Over the years I have found several good game ideas for that classic Japanese 8-Bit computer. Since it uses a variation of Microsoft Basic sometimes even the source code can be recycled. However, since the PC6001 (known as the NEC Trek in North America) implemented quite a number of advanced features for the VDG and also had a very good sound chip there are often elements of the code that cannot be easily translated. Also, I can't say that a huge number of Basic programs can be found on the Net for the system, which indicates that there might not have been very many made for it. This is perhaps because there was a large number of machine language games for the system, which you can find videos for on YouTube. So it was a pleasant surprise when I came across a video by Akky Han sharing one of his own 8-Bit Basic programming efforts from "back in the day:"
The 32 character screen width gives away the fact that a variation of the MC6847 VDG lies at the heart of the system. However the character set is clearly custom. The characters use the entire 8X12 pixel space allocated for each character on a text screen and are taller than the regular built-in 8X8 characters mapped into the 8X12 spaces used on the Coco, MC-10 and most other machines. Also, the lines are from a special set of line drawing characters, which are also not available on Cocos and MC-10's. Still, the basic idea was doable, and unlike the original didn't require any machine code (evident from the source code that Akky Han helpfully provided) to help with the scrolling. In the following version for the MC-10 it's pure Basic baby!
You can see that I have used the course line characters possible using the standard Semigraphics 4 mode colour block characters. Also, the entire bottom half doesn't scroll, but only the actual pathway. I also used two red graphic characters representing "spaceships" or as I thought of them: "drones." I wanted to keep a connection to the original program, so I still called the game "Defense," but I thought of it as being a dual display of an operator controlling two drones simultaneously. If Akky Han had been programming it today, who knows, he might have called it "Drones."
I don't recall exactly how (probably a Google search on "NEC PC6001 Basic Game") but I stumbled across another graphic image of an old NEC PC game called "Nostromo." It was an animated GIF so I was able to see a little of the game play.
It was just enough information to reconstruct a variation in Basic. I don't know for sure, but I think the original may have been a machine language game. The following image posted along with the game screenshot looks like either a cover shot of a magazine for the PC6001 or just the box artwork of the original game. If it's a magazine then maybe its a type-in Basic program.
Notice again in the screenshot the nifty line drawing custom character set used to draw the boxes and the 4 items in the form of the 4 card suits. Also notice the fancy colours added to the regular MC6847 and the Japanese Katakana characters. In fact, I was informed on the Yahoo MC-10 group recently that it was actually a very unique variation of the MC6847 used in the PC6001 called the M5C6847P-1, which adds many advanced functions. Still, the fact that it uses the 32X16 text screen means it is relatively easy to implement a similar game just using Basic and the MC-10. Again, I don't know if the original game was machine language, but if the animated GIF is any indication, it wasn't particularly fast. There were some posts on the Yahoo group that suggested that there are various reasons that the NEC PC did not have the fastest execution speeds in either Basic or machine language. However, the game that I was able to create is fairly fast thanks to the relatively speedy version of Micro Color Basic that came with MC-10 (about 15-20% faster than stock Coco Color Basic):
If any Japanese users of the NEC PC-6001 should ever run across this blog and know about the original "Nostromo" program in more detail, I would really appreciate if they could drop me a line or make a comment on my attempt at a re-make. Whether it is an accurate representation or not, I hope it is an enjoyable game.
In my ongoing search for 8-bit BASIC game ideas and bits of code, I began looking into the classic British computer, the Acorn Atom. This machine caught my attention because it uses the same graphics chip as the TRS-80 MC-10, the MC6847 VDG. However, it predated the MC-10 by at least 3 years, coming out in 1980 or so, whereas the MC-10 came out in 1983. In searching YouTube for some videos of Atom games I ran across a couple of program playthroughs by a programmer called Dino Dini. Dini, it turns out, cut his teeth on the Atom and then went on to program some significant sports games (football/soccer) for a bunch of 8-bit systems in the late 80s. In the playthroughs, though, he is simply playing some of his original Atom games that he had thought were lost but then discovered were included with someone's Atom emulator.
What was most interesting for me about his playthroughs were the games that clearly used the obscure Semigraphics 6 mode of the MC6847.This mode is little used in Color Computer or Dragon games (which also use this chip) because the resolution it offers is only 64 by 48 pixels in 4 Colors (kinda like the graphics on a ZX81). On these machines, with their access to large amounts of memory, the high resolution modes of 128 X 192, 4 color and 256 X 192, 2 color graphics were what obviously attracted serious game programmers. And Microsoft BASIC never supported the mode. It only had commands for the 8 color Semigraphics 4 mode, which is 64 X 32, using the SET/RESET commands or the high res modes using PCLEAR/PSET/LINE/CIRCLE etc.
However, on the MC-10, which started out as a 4K ZX81-like computer, the hardware shortcuts used by Tandy to produce a small less-expensive machine resulted in a more limited set of wiring of the CPU to the MC6847 chip. This meant that graphics modes of that chip can only be memory addressed to the original 4K memory space. The results of these limitations are multiple. For example, since the highest 4 Color and 2 color modes of the VDG require 6K of memory to bitmap, when these screens are displayed on an MC-10 you only can see about two thirds of a screen before the screen "wraps around" the 4K memory space and you see the top 2K of the graphic memory repeated on the screen again. This means the highest resolutions are simply off the menu for any MC-10 programmers, including machine language coders. It is an unavoidable hardware limit. However, this didn't prevent one clever programmer using interrupts and special tricks to fool the VDG by changing modes through mid screen display, but there are still limits:
The result of all this quirky wiring is that the MC-10 is very limited in the kinds of graphics games that can be made for it. For instance it has only been able to have hires games that use the still somewhat chunky 128 X 96, 4 color mode. This hasn't prevented some clever machine language coders from producing some real classics. The most famous of these (using the term "famous" in it relative sense of renowned among the few dozens of MC-10ers on the planet) was Greg Dionne's implementation of Pac-Man. This version even received praise from one contemporary retro-gaming on-line magazine for its fidelity to the real thing:
But such wonderful games aside, there really just aren't that many graphic games for the MC-10. Being a BASIC programmer, limited only to the SET/RESET commands and the massive chunky pixels of 64 X 32, 8 color mode really gave me a craving to try to make some higher res games for the MC-10. However, there are other limits to using graphics. The way that BASIC is implemented means that some of the memory locations it uses are stored just after the end of the 512 bytes of memory used for regular screen display, so that even if you switch into higher res modes, you can't even POKE into the larger screen area without POKING into BASIC itself (the start of graphics memory cannot be changed--another limitation), which of course will bring the system crashing down.This means you have to stick to modes that only use 512 bytes of the normal screen memory, or program in machine language, and this means that from BASIC, you're pretty much stuck with using the 8 color super chunky SG4 mode.
Discovering that there was an alternative to SG4 was one of those wonderful moments I can remember of my early years in 8-bit computing. I read somewhere that POKEing into memory location 49151 would change the graphics mode. As I poked in various numbers, the different screen resolutions sprang into existence. Of course all of those above SG6 showed flickering pixels in the areas just after the text screen area, representing the changing values being stored by BASIC for various functions. However, one of these modes filled the whole ordinary screen, with no flickering. Its pixels were slightly finer than those of SG4. What was it? I figured out that I could turn the pixels on and off, but this required poking into screen mem different byte values representing different pixel combinations represented by different bit values encodes by those byte values. Eventually I was able to figure out a method for correlating specific X/Y values for the screen as a whole that needed to be poked to set the right bit in a screen memory location. Here's the routine:
This routine contains a lookup table that has to be READ into an array L(X,Y) first. If you set X and Y and GOSUB5 you can get a SG6 pixel turned on. GOSUBing 7 is used for erasing the pixel. Line 100-110 just uses these routines to draw a moving pixel to demo the routine. Line 3 is GOSUBed for turning SG6 on. Line 4 returns you to text mode (SG4). I had a new graphics mode! It was essentially equivalent to the resolution of an unmodified Timex 1000/Sinclair ZX81. One of the first useful programs that I made using these routines was a puzzle game called Monster based on the classic Theseus and the Minotaur puzzles:
As you can see, it also has some text. I created a routine for storing byte values for encoding two byte high by two byte wide characters (4X6 pixels). Still it was only a puzzle game, with limited animation of the characters (Theseus and the Minotaur). What I wanted was an arcade style game! My first attempt was to make a Missile Command like game. I eventually got one to work, but since line drawing was so slow, it really only involved moving flickering pixels. So I left the project aside for many years.
However, in the early 2000s I was able to reconnect with other MC-10 users using the wonder of the age--The Internet! I was able to find a group of people still interested in the machine on Yahoo. It was there that I came across Greg Dionne's wonderful Pac-Man. In time I asked if anyone could provide a BASIC implemented machine language routine for drawing lines in SG6. I was surprised when Greg replied with a routine to do just that:
0 SOUND1,1:CLS:CLEAR200:DIMA(90,3),K(255),I,J,X,Y,Q,R,Z,M$,F,G,A,B,C,L,E,S,V:GOTO100 9 PRINT@F,CHR$(A(Z,0))CHR$(A(Z,1));:PRINT@F+32,CHR$(A(Z,2))CHR$(A(Z,3));:RETURN 10 FORG=1TOLEN(M$):Z=ASC(MID$(M$,G,1)):GOSUB9:F=F+2:NEXT:RETURN 100 GOSUB2018 110 REM PROGRAM CONTINUES HERE
For good measure I have also included my text drawing routine. Set the string value M$ for the message. Set variable F for the starting screen location (0-511) and then GOSUB 10 to print the message. Obviously there has to be space for the length of the message. Look at line 2030-2040 for the instructions on using Greg's pixel setting and line drawing routine. It's a USR call with values I,J,Q,R. With this routine I was able to make a better version of my Missile Command:
Lately on the Yahoo group some people were talking about the graphic limits of the MC-10 and lamenting the weird wiring of the CPU and the MC6847. What prompted this were the contributions of Emerson, a user of another orphan machine, the CCE MC1000 computer from Brazil. Like the MC-10 it was a small chicklet-keyed economy computer. Like the MC-10 it used the MC6847 VDG, but it had a variation of Applesoft BASIC. And like the MC-10 it had various limitations to its wiring that prevented the full use of the VDG. Emerson told the group about his various attempts to physically mod the machine so that a fuller array of it graphic modes could be accessed. This prompted a lot of discussion of the limits in the MC-10s graphic capabilities. Another such limitation that I haven't mentioned yet is that even the SG6 mode is not fully wired so two of the 4 possible colours (in principle) are not actually available:
The first screen shows SG6 mode while the second shows the screen in regular SG4 mode. The weird green black lines represent the first 128 bytes of the character set. Only the pixel/bit combinations for byte values 128-255 are available on the MC-10. This is a result of another economy wiring decision to keep the component complexity and costs down (to be fair, the Coco ad Dragon also suffer from this limitation--only machines like the NEC PC6001 and Sanyo PHC-25 fully implemented all the features of the MC6847). Still, there are two colours available: Blue on Black and Red on Black. You can also select an alternate mode (POKE 49151,68) which gives Purple on Black and Orange on Black.
All the talk about the limits of the graphic wiring of the MC-10 got me thinking about trying to use the SG6 mode for some truly arcade style games. If I could find some good ideas and use all my latest fast BASIC programming techniques and knowledge and routines obtained from the group about SG6 over the years, maybe I could get some truly interesting effects.
It was with these thoughts in mind that I stumbled across Dini's demos of his old programs. The result is two programs DRIVE (source) and SPACEWAL (source) that attempt to recreate the games I could see being played on YouTube. DRIVE uses Greg's helpful line and pixel plotting routine. Unfortunately, that routine does not provide a way to determine if a pixel is turned on (i.e. an equivalent to the POINT function in Micro Color Basic for determining whether a pixel has been SET), so I had to figure out a quick way to determine if the moving pixel you control actually moves into any existing bit that is already turned on. Finally I figured out that all I needed to do was PEEK the BYTE location in which a pixel is going to be set using Greg's routine and then PEEK it again after the pixel has been set. If the two values are the same, then that means the pixel has been set in a location that already has a pixel turned on. This means a collision has occurred. Otherwise, not, and your "player" can keep moving. This allowed me to get the collision detection down to the level of the specific pixels on the screen that are being turned on and off and not just the level of the character bytes encoding that information. Greg didn't provide an erase function either (equivalent to the RESET command), so I just poke back the results from the peek test before the pixel was set. Here's DRIVE (a version before I had implemented pixel level detection, but its hard to notice):
SpaceWal is a neat space shooter that uses a horizontal screen orientation, instead of having the aliens descend from above. This allows for longer more complex movements of the aliens before they reach you than would be possible in the more standard vertical orientation of games like Space Invaders, etc. I pre-calculate at program startup 32 tracks that the aliens can take, which avoids a lot of checking and calculation going on in the main loop of the game. Since you shoot aliens at differing times in their approach, the randomly chosen tracks quickly "complexify" in the interactions between the two aliens that are always descending on you at any time. It also means that there is a kind of a simple AI element to the game, as once the aliens punch through an area of the wall there is a strong likelihood that they will eventually return to that area to try complete the job of flying through to the green layer and victory. You be the judge whether this trick can allow a player to predict the paths of attackers.
Random modifications to the 32 tracks occurs between games while the program waits for a new player to hit a key to play again. Since all the "sprites" in this game represent single byte characters I didn't need to use Greg Dionne's M/L routine. Instead, because of the horizontal orientation, object like the laser blast can be made simply by printing a long string of appropriate characters. Otherwise the individual sprites can be POKED into the right locations, which is slightly faster than using the PRINT@ command. You'll notice if you view Dini's video that the Acorn Atom can display SG6 graphics pixels and regular text characters at the same, so its wiring must be more complex than that of the MC-10. I used my graphics character routine in DRIVE to overcome this limitation of the MC-10 and simply shift to a separate text screen for reporting scores in SPACEWAL at the end of each game.
Anyway, so ends my retrocomputing efforts for the month of July 2015. I send greetings to all the other Retrochallengers and look forward to exploring everyone's work. I'm sure I'll find other sources of inspiration there. Thanks for another Summer Retrochallenge Mark! Sorry for the last minute entry (again).
The people of the Glenside Colour Computer Club decided to host an event celebrating the 50th anniversary of the development of BASIC. The Dartmouth Time Sharing System (DTSS) version of BASIC was the origin of the language and Kip Koon organized a programming contest to celebrate this historic beginning. He put out a call for people to try to write (fun/game) programs in Dartmouth BASIC on a DTSS Simulator. I got the simulator and began to play around with the language.
I learned a couple of surprising things. First, this earliest version of BASIC didn't originally have an INPUT command. This was because the programs were not interactive, but meant to be run on the main network hub and the result output on a teletype device. Second, the size of programs was quite limited, something less than 6 KB. Third, there was very limited string capabilities. Basically you can print literal strings, but you don't have string variables, or any string handling. So even though an INPUT command had been added to the simulator's implementation of the language, it would be hard to make a game that only used input of numbers.
My first thought was to make a version of the classic Star Trek game, since it only used numbers for input (1. Shields 2. Photon torpedoes, etc). However, the variation that I programmed ran up against the program size limit. My program was too large to fit into the DTSS. So, I moved on to thinking about other concepts. The ubiquitous "Hunt the Wumpus"-like game ideas seemed to be the only thing to be practical (small memory, number input). It was very challenging to think up anything entirely new.
I have enjoyed recently watching some of the episodes of "Tabletop" with Will Wheaton. He's of a similar age to me and a similar degree of geekyness. I grew up playing combat simulation board games like Blitzkrieg, and so the thought occurred to me of trying to create a simple board game simulation for the DTSS BASIC game contest. I had run across the Epyx game, "Crush Crumble Chomp" back when I was doing my port of "Temple of Apshai" to the MC-10. I knew it was a variation of a classic Board game, so I went and looked it up. The game was called "The Creature that Ate Sheboygan."
The game was originally designed by the brilliant board game designer Greg Costikyan. Although the project grew to such a size, far beyond the 6KB limit of DTSS, and for reasons of wanting to add some nifty graphics to represent the various different monsters (in purple below), or Kaiju as the Japanese call them, I decided to switch back to working on it in Micro Color BASIC. Still, with enough space, I think the resulting game could in principle be done completely in Dartmouth BASIC. In essence it only uses simple keystrokes and numbered directions for input. The main action takes place on a 16 X 16 grid, using only simple characters to represent the elements making up a map of the City of Sheboygan. Other than that, the game is all about combat tables and game rules and applying the results of simulated dice throws to the tables and rules.
Anyway, after a week of putting a push on in hopes of having it ready by the weekend of the Annual "Last" Coco Fest, I have produced a variation of the game that I believe faithfully captures all the elements of the original with only a few compromises to help the AI that I was able to implement to play the "human" side of the game.
The game and the VMC10.exe MC-10 Emulator to play it can be downloaded here or on the Javascript MC-10 Emulator. Just load the SHEBOYGN.C10 file after typing in CLOAD and hitting ENTER. Then type RUN and hit enter.
Coco Version of SHEBOYGN.BAS
A link to the Coco specific version can be found in my coco compilation zip on the JGGAMES10.DSK
You can press the "H" key during the *MONSTER MOVE* phase to receive some help about playing the game.
During your turn as the monster (M), when the other pieces (see right pic above) are stationary, you can choose (ASWZ) to move or (D) destroy stuff, (F) breath fire, (X) make a web, (C) scream sonically or hit (SPACE) to do nothing. You get a number of moves based on your abilities and your strength. At the end of your turn you can attack nearby enemy units by choosing a direction number or hit 0 to refrain from attacking. When you are prompted for a numeric value you can hit space to scroll through the range of options before hitting (ENTER) to initiate the action. Basically you want to destroy as much as possible to get to a certain level of destruction (based on your level of difficulty). You must defend yourself against the aggressive units and "eat" the civilians. All attacking units have certain ranges and certain movement characteristics.Troops, for instance can travel through/in buildings. Units within their relevant ranges wil pool their attacks on you each round. If you lose enough power and strength, you can be defeated by the measly humans.
I use some speedup techniques I've never used before. These involve doing checks and additions in the same line/command by using the logical operators and relying on the fact that they return either a zero (False) or -1 (True). If you are only moving by increments of 1, then you can efficiently use what these operators return to not only do boundary checking, but also, at the same time add or subtract a 1 if the check is okay. I suppose you could also multiply the result by another number to do additions for move increments other than 1, but it is especially efficient with movements of just 1 and helps avoid the use of lots of IF statements, which although generally fast commands, can when used in large numbers really slow down execution. So I have a command like this:
This line basically adds or subtracts a random number (R) to one section of the track location unless that will put the track too far left or too far right on the screen. In the past I would have had multiple IFs like this:
10 IFR=-1ANDV+R>0THENV=V-1:GOTO 30 20 IFR=1ANDV+R<16THENV=V+1 30 program flow continues
The new way also saves having to use multiple lines on the MC-10, which was also helpful for my 10-Liner programming contest entry code (see above).
I also had some recent comments on my NBLITZ about how to avoid flicker in BASIC game animations. I'll repeat my comments here for others who might have missed them.
Just make sure you remove all unnecessary spaces and pack lines as tightly as possible using colons (See my post here for advice on the few places you must leave spaces in for the Coco). I also find it is important to resist the temptation to stop working on a program's basic structure once you've got it basically working in terms of the animation. There are usually many ways to improve the logic and make the flow of a main loop more efficient. For example, if you're doing repetitive calculations in your animation loop, put them in a variable at start up, or do a pre-calculation loop at startup and store the results in an array. Then just consult the variable rather than do a calculation in your animation loop. Also, although in NBLITZ I use the SET command to display the planes, I don't use RESET to clear them. Instead, I have two large strings filled with CHR$(128)s (the black sky character) and the little graphic of London characters for the bottom of the screen. I just print these two strings @0, and they clear the entire screen to the background of black sky and city skyline (except for the very bottom left position, which I just pre POKE to the right color character at startup). Then I just redraw the planes in their new locations. This is much faster than RESETing the individual pixels of each plane or having complicated procedures to POKE them to black.
Also, in NBLITZ I originally checked that the location of my plane did not go beyond the boundary of the top, left, right or bottom of the screen, but I was also checking for any collisions with other planes or the city at the bottom the screen. So I was eventually able to remove the bottom bounds check since the city effectively blocks any movement towards that boundary. There's always some temptation when programming to leave such redundancies in, especially in the old days (or even still today) when you had to use to kludgy EDIT and LIST commands to make any changes. By programming using a good line editor like WordPad, such editing awkwardness is overcome. Here's a video showing the advantages of using the VMC-10 emulator and its quicktype feature to make quick and easy changes to one's BASIC source before "quicktyping" it in, which takes just a few seconds, and running it:
Well I've made another (possibly final) entry to Allen Huffman's 4K TRS-80 Color Computer Challenge. This program is a game idea I have been toying with since I first posted about it back in February 2013. It basically grew out of an attempt to represent the figure of an airplane pointing in 8 possible directions using only the chunky block graphics of the MC-10 (and as Allen suggested, probably inspired by Air Combat for the Atari). Here is the initial sketch I made using my simple but handy graphics program "Sketch."
I had also originally planned an elaborate graphic for the title screen:
However, this was obviously a no-go if I was going to make a game that could fit into 4K. However, I was able to wedge in the simple 8 direction plane graphics and the skyline of London (my apologies to any Londoners out there if it is a complete miss on accuracy). The game is much simpler than the one I had originally envisioned, which would have involved flack bursts and enemy planes that shot back. In the version I did create a single enemy plane travels back and forth from a random starting point on either side of the screen. However, I think that the game is probably much more playable than it would have been if I had not been constrained by the 4K limit. That limit really enforces a rigorous simplicity that probably results in a faster and more challenging BASIC game. But you be the judge. Here's a video:
The planes are less flickery in the real thing. The frame capture rate at which the Cam Studio software I use to create my videos is probably set too low to capture the animation accurately, but unfortunately the VMC-10 emulator is such a resource hog that I have to keep the rate low to prevent both programs from slowing each other down excessively.
I have submitted a variety of programs to Allen Huffman's 4K Color Computer Programming Contest. These programs were originally designed to run on the Radio Shack MC-10 with 16K ram pack. I had to "condense" many of them quite a bit to get them to work on the 4K CoCo since it provides even less RAM (2343 bytes) to BASIC than even the MC-10 without the 16K ram pack (3142 bytes). Some of the programs use the speedup poke 65495,0. This will always be located in line 0, so make sure to change this poke to poke 65497,0 if you are going to try to run these programs on a Coco 3.
Farfall is a text-mode arcade game based on John Linville’s Fahrfall. This game was already 4K, so I just tightened up the code a little bit and switched the key sensing peek routine so that it worked on a Coco 1. Whether a key is being pressed can be sensed directly on the MC-10 by looking at the result of PEEK(17023)ANDPEEK(2). If a key is being pressed the result will be the ASCII value of the key, otherwise the result will be zero. On the Coco you must look at a number of different memory locations that constitute a "keyboard rollover table." For example, PEEK(345) will return 255 if no key is being pressed and another value if the Space Bar is pressed. The table for all the keys is held at peek locations 338-345 (these represent different collections of keys on the keyboard). You can either search this table for the specific values returned by the key you are checking for (which don't correspond to ASCII values), or you can search the whole table for any change from the default 255 value and then check PEEK(135) to find the ASCII value of the last key pressed. However, it should be noted that in the Coco 2B Tandy modified the ROM so that the values of the table were not reset automatically after keys were released. To save space (and speed), and since the Coco 1 doesn't do this, I do not reset these values. So if you run these programs on a Coco 2, moves will continue even after you stop pressing keys. The Coco 3 returned to the original method.
JimVaders is a text-mode Space Invaders style game, with a stationary mother ship that makes a random appearance. The game speeds up as you go. This was already 4K ready. I had designed it to fit into limited memory when someone on the Yahoo MC-10 group mentioned that they only had an MC-10 without the 16k ram pack. The ram pack is essentially the "standard" way to run an MC-10, either in its real or emulated form. However, MC-10s often turn up in junk shops or on the Net without this essential item. People pick these computers up because they look cute and retro and then discover that they also have to track down the much more difficult to locate ram pack if they are to be able to run any descent software. They then become frustrated and their interest wanes. I thought it might help keep some of these folks involved in retro-computing with the MC-10 if I made some games that worked for its most basic layout.
Lander is a version of the classic Lunar Lander done with the 64×32 block graphics. Unlike my original version I had to remove the random and changing Earth generation routine (which was a quixotic feature that I quite liked) and all the instructions. Prompting had to be minimized and I had to scour the net for a line drawing routine that only uses integer math, since Micro Color BASIC lacks math functions like SIN and COS. I found the Bresenham algorithm, which nicely fit the bill.
Tetris is a version of the classic falling block game. It was one of my earliest programs for the MC-10. However, I abandoned working on it after John Dionne made an excellent machine language hi-res graphic version for the 20K MC-10, which included human voice and sampled sound effects! As a result, I always had a sense that it could have been improved so I appreciated the opportunity to return to it to see if I could whittle it down to 4K. However, with all its DATA statements detailing the orientations of all the blocks which had to be loaded into a fairly large array it was too large to fit in a 4K Coco. So I used the technique I developed to eliminate the redundancy of loading DATA statements into large array variables for text adventure info described in another of my blog postings. The result is that the program must be loaded in two chunks. You must first load and run the program file T1.BAS and then load the data file T2. If working from a real cassette T2 obviously should be saved after T1. Just leave the tape play button on as you run T1. To create the T2 data file on a real Coco or emulator use the TDAT.BAS file. Use Space and B keys to rotate blocks clockwise or counter-clockwise. G2048 is a 4K version of the current hit 2048 game (web-based and iPhone/Android). The original game is open source and so I used the posted JAVA code as reference to make it play like the original. I also had to find an alternative to the LOG function, which I had used in the original to calculate the changing colors, since there is no LOG function in Color BASIC.
R1.BAS
R1.BAS Loading Demo
Rail like Tetris is loaded in 2 parts. Load and run R1.BAS first. Then load data file R2. After that a prompt will appear. This is for the number of trains you would like to control. There is no error checking so make sure to enter only a number between 1 and 6. Use the RDAT.BAS program to create the R2 data file on a real Coco or emulator. The object of the game is to maneuver the blue train in the upper right to the yellow siding in the bottom left. Press the letters to curve or straighten the track at that point. If trains collide or run out of track the game is over. The prompt will reappear for how many trains you would like to control. This game is a port of a game originally for the Commodore Pet. Here’s a link to my blog posting detailing my production of the original for the MC-10.
AST4K.BAS
Asteroid Storm is a game that someone on the Yahoo MC-10 group described as a cross between Frogger and Asteroids. You must maneuver your ship from left to right across a moving asteroid field. However, your reverse thrust engines are broken. But don't despair, pressing the Space key will deploy limited shields to help you escape difficult situations, that is, if you haven't used them up already! This program uses a circle drawing routine for low res block graphics to create asteroids of various sizes. Then it basically snips the top line and prints it at the bottom of the screen to create the illusion of a moving field by taking advantage of auto screen scrolling. As levels are completed new asteroids are added to the field creating more challenge. Along the way you can collect replacement ships (up arrows) and extra points (@).
"Rail" is a Basic simulation/game program based on a Commodore PET program by Chris Torkildson originally published in Issue 19 of Cursor Magazine. Here are YouTube videos of the original program and my version re-programmed for the TRS-80 Micro Color Computer:
Original Pet Version
My TRS-80 MC-10 Version
My programming project was based entirely on this PET video provided by K. Moser and a few screenshots I was able to scrounge from the net. It took a while to draw out a representation of the original track layout and to settle on a standard format for the corner/switches. To do this I used my handy DRAW.C10 utility, which I have modified to "print" the screen to a text file using the VMC-10 emulator. This feature allows me to quickly sketch low res graphics screens and then transfer the characters constituting that screen into strings or DATA statements using a Windows text editor.
After getting the basic rail lines sketched out it was just a question of working out an algorithm for 64 X 32 set/reset graphic "trains." This task turned out to be much simpler that I thought. All I had to do was check in the direction that the pixel was going for a white rail pixel or pixel the color of the train itself (because of the artifact color effect the rail could alternately be turned to the color of the train). If no "rail" pixel was present then the program checks to either side of the obvious pixel in the direction being traveled (i.e. sense if a curve is occurring). If so, then it moves the train pixel to that location. Finally if no locations are available in the direction one is currently travelling (either straight ahead or to either side of the pixel straight ahead) then check if there is a rail pixel to either side of the current pixel. If so, then it changes to moving in a new direction of the pixel being sensed (i.e. changes from a horizontal to a vertical direction or vice-versa). If no such pixels are found, than that train has hit a dead end...
When this simple algorithm turned out to work effectively to move a pixel "train" around the track, then it was just a question of multiplying the number of pixels to run up to six trains and adding the track switching for each letter pressed. Due to the artifact effect of low res graphics on the MC-10, each train is always two pixels in width because colors can only be set for each 32 X 16 character position, so a 64 X 32 rail position to either side of the train pixel will always also be set to the train's color. positions behind the train get set back to the rail color of white. At the end of all train moves checks are made to see if any of the trains colors have been reset to the colors of other trains (i.e. a collision has occurred).
It took some fiddling to get the starting points worked out. I don't think in the original that this is completely random, as this would too easily lead to situations where it was impossible to avoid train collisions. From what I could see from Moser's video, it looked like there were some standard starting locations and that the other trains all started moving to the right, except for the player's train. After much trial and error I was able to work out a set of locations that would allow the player the possibility to complete any round with up to 6 trains. On the lower number of trains, however, I left some randomness in placement of the trains, to add some challenge. I don't know if the real game is like this. I do not have a Pet emulator setup to allow me to try the original program. I would greatly appreciate any input from Pet users who have played the original about the starting locations of the trains (other than the player's train).
Some may wonder why it is necessary to recreate an already existing program. Why not just fire up a PET emulator and play the original? This is not satisfactory to me for three reasons. One, I like Basic programming more than playing games. Two, I like contributing to the software collection of my favorite (but in its day neglected) 8-bit computer, the TRS-80 MC-10. Finally, having my son (and his friends) "beta test" my programs allows me to share my love of 8-bit computers and to re-live those long lost days of my youth when simple programs like this one, could fascinate kids like me for hours.
For Retrochallenge 2015 I ported to Microsoft Micro Color Basic Will Crowther's original Fortran source code for what became "Colossal Cave" or "Adventure." The new basic source code should be easily shifted to other Basics. I have fixed and finished certain uncompleted elements in the code and changed a few things to create a few additional challenges to provide a more complete game experience of what was obviously an uncompleted "work in progress."
I re-coded the program into Basic from the Fortran source code and data file that Crowther's wrote for the PDP-10, which was recovered a few years back from old backup tapes. This is not the classic "350 point" version created by Don Woods by the addition of many novel elements to Crowther's original source. My version contains only the numeric room movement info and the room and event text descriptions of Crowther's original game, reputedly written to entertain his children in the wake of a marriage breakup in the mid 70s.
I had to wedge it into 20K of my favourite 8-bit the TRS-80 MC-10, so some of the descriptions got “edited” a little, but I was able to transfer the map info from the data file into Basic DATA statements, so it's a fairly accurate rendition of the original map. I only made a very few tweaks where directions were quite clearly messed up or to eliminate a few NE, NW, SE and SW (diagonal) directions. In reconstructing the game play elements I was greatly helped by Renga in Blue's "Observations about Crowther's original Adventure".
Will Crowther 2012
I have also added a few new commands. The SCORE command will tell you how you're doing and if you have won. The HELP command will provide some rudimentary aid. The UNLOAD command will perform the same function as the more standard "drop all" command of other adventures. The QUIT command not only quits but prompts whether you would like to save the progress you have made. You are also prompted each time the program is run if you wish to load a previous game. The same file name "COLOSDAT" is used for each save, but in the TRS-80 MC-10 emulator (VMC10.exe) you can save the resulting virtual cassette file to any file name you like in order to differentiate between different saves. Just remember that when loading and prompted to "Press Play" you must select the file name containing the desired virtual "COLOSDAT" cassette file.
Download VMC10_073D.zip for the Virtual MC-10 emulator, which includes the game in the JimG sub-directory of the cassette directory. To play the game load the file "COLOSSAL.C10" after typing CLOAD and hitting <Enter> in the emulator. Virtual cassette files can be loaded via the File menu of the emulator. Then just type RUN <Enter>
I was also greatly aided by Neil Morrison of the TRS80MC10Club group on Yahoo. Neil uploaded a PDF to the group of a simple text adventure program "Tower of Mystery" used as an example in a Compute's Guide to Text Adventures (1984). Here's a description of the program from that book, which fittingly contains a story reference to the original Adventure:
Tower of Mystery is a BASIC program designed to illustrate some of the concepts of adventure programming and to serve as a starting point for writing your own adventure programs. The object is to enter an old factory building where the world's only remaining copy of Adventure is reputed to be stored, and to leave with a tape containing a copy of the program. I was able to modify this very useful program to do most of the work of text entry and analysis. I just had to modify its verb list and items and re-code the sections for each of these commands to handle the event and room descriptions of Crowther's program. I also had to add routines to handle the ongoing interaction of the dwarves, who show up periodically, and item and resource management of food, water and light, which were lacking from the Tower of Mystery. As mentioned above, I had to largely "normalize" NE, NW, SE and SW directions, since there were so few of them and it would have required too much modification of the Tower of Mystery text adventure engine's basic N, S, E and W direction handling. Using Renga in Blue's descriptions of the puzzles and other game challenges, and by examining Crowther's original source, I was able to recreate what I believe is an essentially accurate presentation of all the original game elements.
As I worked on the rooms in the Bedquilt (“Under Construction”) area of Crowther's original code I really could sense where his patience with the project petered out (sometime in 1975 or 1976) so I also ended up adding a few unique elements of my own to “complete” an unfinished work just begging for completion. I can understand what tempted Don Woods to make his additions in 1977 to create the classic 350 point version.
That being said, I did not like some of the more surreal fantasy elements that Woods added. Crowther's original version has a more austere set of locations, but they have a feel of realism that is absent from the classic version's chaotic hurly-burly of branches. Also, there is clearly a sense that Crowther's fantasy elements (Hall of the Mountain King, nasty little dwarfs, wandering into a cave) were drawn from a single classic narrative source, such as the story of Peer Gynt, rather than a hodgepodge of fantasy cliche's. I tried to respect this integrity in the few additions I made to fill out Crowther's obviously abandoned work.
Don Woods helped Crowther overcome the problem of the game's unfinished nature by significantly expanding the complexity of the cave and by adding improved scoring and win subroutines. It's this latter version which is normally referred to as "the original adventure." In homage to this latter title I have also made my re-coded version worth 350 points, although these points only represent six 50 point treasures. Only five of these treasures are present in Crowther's original. I have added one treasure and one puzzle and a few new threats to help add new challenge to the adventure. I have also slightly changed the operation of some of the magic of the original to prevent old hands from simply applying their prior knowledge.
Enjoy!
*Spoiler Alert * The following short video demo contains spoilers, so proceed at your own risk:
If you' want to know more about the history of Crowther's Colossal Cave Adventure, including the cave it was based on, see "Somewhere Nearby is Colossal Cave: Examining Will Crowther's Original 'Adventure' in Code and in Kentucky" by Dennis Jerz of Seton Hill University (Digital Humanities Quarterly, Summer 2007, Volume 1 Number 2). For a long time the original code was thought to be lost but Jerz was able to arrange its recovery from an old backup tape of Woods' student account. Jerz's analysis shows that Crowther's original program was a game and not simply a spelunking simulation as is commonly thought. It included magic words and other fantasy elements. If you want to compare my re-coded version to the original Fortran program someone has got the original Fortran source running under modern Fortran compiler conventions.
