I've made the text routine faster again. I realized that no single letter or number used more than 7 draw commands, and since I encode and use the actual numbers for each draw command, I could encode every character using only 7 digits instead of 9. That's a substantial reduction of processing for each character.
Here is the new routine:
0 CLS:CLEAR500:DIMT,A,G,A$,B$,A$(58),I,J,M$,P(5),C$(5),C(5),M$(10),ML(10,1),MZ(10,1):I=64:J=47:GOTO15 1 DRAW"BD6":FORG=1TOLEN(M$):A=ASC(MID$(M$,G)):IFA>ITHENA=(A-I)*7:FORT=ATOA+6:DRAWA$(ASC(MID$(A$,T))):NEXT:DRAW"BR8":NEXT:DRAW"BL255BD2":RETURN 2 IFA>JTHENA=(A-J)*7:FORT=ATOA+6:DRAWA$(ASC(MID$(B$,T))):NEXT:DRAW"BR8":NEXT:DRAW"BL255BD2":RETURN 3 DRAW"BR8":NEXT:DRAW"BL255BD2":RETURN REM A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 15 A$=" 10345671256700123600014567001234670123070002345671250700900000014560001250780000008912345801234500123456012347000234570123400023567000000789120456024007091245609205078902045671340670" 16 B$=" 123456000000891346700345670024507002356700123567034500001234567234570034000090000700" 17 A$(48)="":A$(49)="NU3":A$(50)="BU3U3BD6":A$(51)="BU6NR5BD6":A$(52)="BR5BU3U3BD6BL5":A$(53)="BR5NU3BL5":A$(54)="NR5":A$(55)="BU3NR5BD3":A$(56)="BU6BR3D3BD3BL3":A$(57)="BR3NU3BL3"
I'm now up to AKALABETH_MCX12.TXT in terms of versions of the source. I'm not sure if there are any other possible speed-ups hiding in the code, but you never know. Also made some changes to the introductory screen to put all the questions on one screen. Be nice to add some instructions too, but memory is at a premium. In fact, I had to pare down some of the messages that get displayed when you enter Lord British's Castle for your various missions. So in case people were wondering, the arrow controls for movement are:
I
J K L
And the other commands are as follows:
A=attack
S=stats
Space=pass turn (wait)
P=Turn pause combat messages on or off
I have been debugging my initial attempt to port of Akalabeth to MC-10 equipped with MCX. I found a number of bugs I had put into the code, and possibly one that is from the original program.
The first bug that I discovered that was my fault was that I missed putting a few 1s at the end of LINE commands. In MS Basic for the MSX standard, you can leave off a number for the color of lines to be drawn by the LINE command. If it is left off the default color set by a COLOR command is used. But with the Extended Color Basic of the MCX you have to supply either a color number or PSET or PRESET. PSET is the way to designate the default color, PRESET provides the default background color. So I had to add lots of 1s to all the LINE commands, and there are lots of them, so I missed a few in my initial edit.
I also found a place where I hadn't replaced a PRINT command with a call to my hires text routine. When MCX BASIC hits a PRINT command while in hires mode it automatically bumps you out of hires and back into text mode. This is different from regular extended basic, which can just print the text to the text screen, which is kept in a separate place in memory. This happened in the Magic Amulet routine when you choose the BAD option and get turned into a Toad rather than a Lizard Man. You'd be switched to text mode and the message "You have been turned into a toad" would be printed on the text screen. I fixed that problem.
I also noticed that I was down to only 240 bytes after all the main variables had been DIMed and the program had run through most of its routines. So I decided to trim the program down a little more by consolidating a few more lines using colons and switching a few main array variables from two character long variable names to singles. Now the DN() and TR()--dungeon and terrain variables are just D() and T(). I also changed the Stats to just three character shorthand (STR/INT/WIS/STA etc.). This not only saves memory but provides more space on the setup screen, as I realized that Stats and Items can rise to the level of 3 digits, if not more. Now there should be space for up to five digits for items and stats.
I found a number of errors with the Pause routine. I also added pauses and clear text window commands in a few places to improve the display of information in the bottom left "Command" window.
I found an interesting website that had playthrough information. It was really helpful in allowing me to playtest and find some of these bugs:
I turns out there is a bit of trick for getting an easy win. Just choose the Mage, rather than Fighter, and in the first battles, choose the BAD option of the Magical Amulet, which can possibly turn you into a super powerful lizard man. If the Bad magic turns you into a Toad, then just re-start. Using this technique and the high speed setting of the emulator allowed me to play through many attempts at getting down to lower levels to see most of the higher level monster. This is how I noticed that I had missed putting 1s on a few LINE draw commands. The high speed option of the VMC10 is really helpful for game testing.
Balrog which only appears at level 8 and deeper
I also sped up the text rendering by switching to using ASC to test component of the array that stores the info to draw the letters rather than using VAL. The text draw data takes the form of numbers 1-9. Now this triggers references to an array with elements containing DRAW commands with those elements stored using numbers 48-57 rather than 0-9. The nine drawing elements created a coarse set of letters and numbers from drawing element arranged like this:
All I have to do is encode 9 digits for each character, such as the G, as follows: 023456700
As you can see, the 1 location and the 8 and 9 locations are zeros and therefore render blanks. The others using the ASC code will select for their appropriate draw string (48-57) for rendering that character. By using ASC to do this I can also use a MID$ command without its length argument, since ASCII just send back the ASCII value of the first character of any string. So this shaves off a further two characters in the command: From MID$(A$,T,1) to MID$(A$,T). Every little bit helps and I think the ASC command probably is just faster than VAL command too. I chose to render letters as lowercase because this seemed to give the most differentiation between letters and also generally used fewer lines. Again, every little bit helps. Some of them like the K and X are a little abstract, but for the most part they seem basically readable.
A Bug that's not mine?
The bug in the original code that I think I found involves a rare condition in which all your items have been stolen (no weapons) and a thief is attacking and randomly stealing items. The routine for it to randomly select an item stored in your items array simply keeps looping back on itself if it finds an array element that is empty. But if all the items are empty it just keeps looping back in an infinite search for something for the thief to steal-- freezing program execution and never triggering the "you starved to death" routing that will allow the game to end properly. I fixed the problem by doing a check that all items aren't empty before allowing the program to proceed to the theft search.
Well, as usual, the projects that I described in my entry for this month's Retrochallenge have very little to do with what I have actually ended up doing.
I really can’t take much credit for this one project.The well-known retro programmer Oscar Toledo
G. aka nanochess ported the Apple II source of Akalabeth World of Doom to MSX Basic. This game was the forerunner to the Ultima Series and was programmed by Richard Garriott aka Lord British. I stumbled across a posting that Nanochess made about his project. Since the MSX1 standard, graphically speaking, works on 256 X
192 resolution and is pretty close in syntax to Extended Color Basic, it was pretty
easy for me to fix up the source for running under the MCX (i.e. extended color
basic) for the MC-10.Here’s the link to Nanochess’spage:
Akalabeth_MCX8.TXT
is my latest as of this posting version.
The most important change that I had to make was to create a high-res text routine since MCX/Extended Color Basic has no built-in way for printing text on the screen. The MSX graphic standard uses a later standard of Microsoft Basic that provides for printing text on the graphic screen. My routine went through many iterations, of course, in which I tried to squeeze more and more speed out of Basic. Hard to discern, but you might be able to notice a slight uptick in rendering from each of the following videos:
REM 123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789
REM A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
This routine should be useful for Coco or MC-10. It's meant to render in PMODE2, which is the highest resolution available in the MC-10. Not sure how it will look in other modes (PMODE 3 or PMODE 4). It's a bit chunky and still a bit slow, but it gets the job done without having to resort to M/L code.
Curtis Boyle has contacted me about getting the source to try a conversion to Basic09. This should be possible since the GFX module has all the routines you would need. However, I think the X index is reversed, if I recall, from that of Extended Color Basic so that coordinate numbers do not go from top to bottom but bottom to top.
This is a text adventure called "Haunted House." You explore the house and collect treasures.
I have ported the game to the TRS-80 MC-10. The original is from a book called Write Your Own Adventure Programs For Your Microcomputer, which you can read here.
The program was part of a 1980s series of programming books for children from the Usborne publishing company. That company has posted PDFs of all their books from the programming series. I highly recommend introducing them to your children if they have any interest in coding. Usborne also have modern programming books, including ones for Scratch and Python!
The adventure games book shows how to design and implement a text adventure game in BASIC. The Haunted House game is the main example. The book is clearly written, consice and well illustrated, and assumes almost no prior programming knowledge. It uses BASIC, but the concepts are useful for modern languages.
If you find yourself frustrated, a walkthrough can be found on the CASA Solution archive.
Recently I became aware of Steven Wozniak's short time working for Atari to create the major arcade hit "Breakout." I hadn't realized that this experience was in part what led him to design the Apple II. He wanted to be able to create games just using software rather than huge numbers of ICs. No surprise that when he got the Apple 1 working and finished making a BASIC for it (called "integer Basic" but originally called "Game Basic") that he programmed a simple version of Breakout out called "Little Brick Out." It was really hard finding source code for the game, which is surprising considering the influence of it. There are thousands of versions of Breakout programs out there, but they can all trace their origins to Atari Breakout and Woz's program.
I eventually gave up trying to find a copy of it and some way to run it on an emulator. Instead I turned to the MC-10's implementation of the Breakout concept in the form of one of the programs for Tandy's "Game Pack" for the MC-10. These games were examples of the fewer than a dozen official programs released for the machine. It is not a very good program. It is slow. The paddle doesn't move quickly enough, so sometimes it is impossible for you to move it to the ball in time causing you to lose a ball through no fault of your own.This is a terrible sin for a game to commit. I decided to apply some of the tricks that I've developed over the last decade to speed up program execution. Carlos Camacho calls these my "black magic" tricks. Here's an incomplete list:
remove all spaces in code except in strings
put frequently used subroutines at the top of the program
use single letter variables
replace common numeric constants with variables
renumber lines by stepping by 1 and keep main loops at the top of the program with the shortest line numbers
pre-calc commonly used values and store them in arrays
use . instead of 0 when assigning variables, in calculations, or in logical comparisons (this only works in MS BASICs)
replace IFtestANDtestTHEN with IFtestTHENIFtest
replace IFvar<>0THEN with IFvarTHEN (also good for test >0 if you know value will only be positive)
pack lines using colons. Use search and replace to see if a line number is called from elsewhere in the program, if not add it to previous line using colon (to max line length of 128)-- use ? instead of PRINT to pad lines even further (beyond the 128 limit)
use for ONK(keyinput)/GOTO or ONK(keyinput)GOSUB instead of multiple IF/THENS for parsing key input
use NEXT to return from GOTOs out of main loop defined by a FOR/NEXT loop (you can use FORA=1TO0 to define an endless loop which can be terminated by setting A to 1 within the loop or a subroutine)
USE POKEs instead of PRINT@s
reuse small # of scratch variables rather than assigning new variables for each unique task. Keep your list of variables as small as possible
DIM all variables, including non-arrays at program start up, with the most frequently used variables (e.g. X,Y coordinate for object used in graphic animation) at the front of the list and non-speed-critical variables at the end of the list (e.g. SCORE, HIGH SCORE, Player name)
I applied many of these to BREAKOUT for the MC-10. I renamed my version BRICKOUT in honour of Woz's original program. Now the paddle moves twice as fast as the original. But if you lightly tap the keys you can still make the paddle move one pixel at a time for fine tuning. I changed the way the number of balls is reported to a countdown to 0 rather than expecting the player to simply know that you get 5 balls. I added a few instructions and a title screen. I also added performance assessment messages at the end of the game, which I had noticed were a part of the Woz's original version. I made a few other minor cosmetic changes as well.
The Sharp MZ is a series of personal computers sold in Japan and Europe (particularly Germany and Great Britain) by Sharp beginning in 1978. In a 2017 posting on AtariAge some people were discussing possible games they would like to see ported to TI99. Oracle Jedi made a few suggestions:
Coup d'Etat - a Sharp MZ80 magazine listing game published back in 1982. Wraithchild was going to take a stab at converting it to the 8-bit Atari.Subspace Striker - a ZX81/VIC20 game from Pixel.
Trader - a three-part "adventure" for the ZX81 and VIC20 - also from Pixel.
Football Manager (the VIC version had no graphics)
Looking forward to trying Oregon Trail when I get my TI out next.
A little searching on the Net didn't turn up any scans of the particular magazine. However I found an interesting reference in a users magazine for fans of the Sharp 8-bit systems. The magazine had some grainy pictures of the original article, but the details of the listing were unreadable. However, the author's comments confirmed that the program had been well thought of.
However, I was still no closer to getting a listing. I thought I would try looking for a version of the program possibly converted to another system. The Sharp was a 40 column screen machine, so I thought I would try to see if there had been a Commodore conversion. Sure enough I found a loadable cassette version for the C64. I was able to use WinVice to load it up and print it to a text file.
Now I had the code, but it was obviously, as the Sharp fan went on to note, a "huge" program. The bulk of the listing was taken up with a dozen very detailed full screen character-graphic pictures of the various locations in the simulation ranging from the President's Palace to the TV Station-- Well over 30K. I'd have to bump off over 10K to get it to fit into an MC-10. There was also a very elaborate intro screen with a graphic of a Tank, which would turn its turret to point at the viewer before firing and the display would then switch to a large letters spelling the title. Cutting out all of these pictures and title screen stuff got me down to around 20K. Then I just had to spend a few hours condensing the code, such as taking multiple lines and putting them on one line separated by colons. Distinct line numbers for single commands really eats a lot memory. These old games, typed in using primitive editors, really prevented such efficiencies, since it was so difficult to move code around. Some of the IF statement lines were also doubled up, probably because the C64 has an 80 character line length, which severely limited what could be done with one IF command. All this got me the space I needed for the variables and arrays used in the program.
I found a number of annoying bugs in the program, such as lines that would never be reached in program flow. For example, there was a funny remark, about your "liberation" of a "case of beer" that was missed. Sometimes this was just because a random number wasn't big enough to trigger all the possibilities in ON/GOTO commands, in other cases, lines were orphaned by the way checks for IF commands occurred. Again, such aspects could easily be lost when one only had easy access to a program via an awkward line editor, which doesn't really allow for a bird's eye view of the code (printouts might... but few would bother continually printing out code as they developed it). However, there was what appeared to be a catastrophic error in the C64 which would prevent one from winning:
I thought the variable bz was a typo because it was never used anywhere else in the program (I did a search). It will always contain a zero and therefore trigger the result that "your men" are "wiped out" no matter what happens in your attack on the palace of El Presidente. You could "take" the Palace, but your men would still be wiped out and you would be taken to the losing screen. However, after (finally) getting a copy of the original MZ80 source from Wrathchild on the Atari forums, I discovered that the original source set bz to 1 when you take the barracks and capture a Bazooka. The Commodore source also sometimes transcribes the "FO" variable for "FD," which means food boxes will not be handled correctly.
The attack routine also seemed a little messed up. For one thing, there was no difference between the "Capture" and the "Raid" options, except that you wouldn't take control of the site under the Raid option, even if your attack succeeded. I made the RAID option use the same attack routine as assassinate, except you choose the number of soldiers involved rather than a standard 30. The casualties for both of these types of attack are consistently reported back to their calling routines for the various locations which can be attacked (Bank, Barracks, Police Station, Prison, Palace). There seemed to be an error in the C64 and MZ80 source involving the variable FA for a failed Capture attack. In some cases the variable used in the checks after the return from the attack subroutine was "A" and not "FA." I think this was a typo.
Another apparently incoherent aspect of the code was the management of the various observation towers of the game (see the numbered items in the C64 screenshot above). They were supposed to be attached to specific sites, but the locations didn't seem to match the map, which you occasionally are allowed to view in the game revealing the numbers for each tower. This meant that choosing to destroy a specific tower based on the map wouldn't necessarily aid you in your attacks on a specific location. I thought this was a result of an incompletely implemented system for shuffling the towers locations from game to game. There was an array PT(13) assigned this task, and randomized list of the tower numbers were assigned to it at startup, but then no other major references were made to that array. It turned out after seeing Wrathchild's source file, that I had simply hacked out the complex poke routines attached to the original map. However, this mistake worked to my advantage, as the MC10 version of the map that I made was too crowded to handle possible two digit numbers being displayed next to all the towers by a reshuffling routine. I rejigged the combat routines and other references to towers to use fixed locations of the towers. Your chances of taking a site are reduced if you do not subdue its specific tower.
I was also able to create some simple graphics for each location. Icons really. They're not full screen text graphic wonders like the original, but they get the job done. There were also some simple text graphics displayed when you win and lose: A firing squad for when you lose and you being carried in litter by two lackies, from which you get un-ceremoniously dumped (by mistake I'm sure) when you reach the right side of the screen. Since I was still somewhat pressed for memory I replaced the litter routine with a re-display of the statue of "the leader" displayed when you visit the "Square." The game now concludes with the observation that the statue the people erect to you in gratitude looks a lot like the one for the old El Presidente.
Even with these changes and fixes the game seemed extremely hard to win, so I added a level option and used it to nerf many of the hazards you face and to increase the magnitude of the possible benefits. I have now been able to win on level one (see below). However, this is using my intimate knowledge of the program. I suspect it will be harder for the uninitiated to figure out the optimal strategies needed. But if you want to play the game like the original author intended, try level 3 but it seems way too hard to me. One benefit I added for all levels, was main menu option to visit the Towers. On any level it is pretty important to blow up towers as you seek to take-over various sites, and the random appearance of the option for attack towers, which only happened when visiting the barracks, were simply too rare in my opinion. So now there are 0-13 options for the main menu, which make for a slightly more balanced menu screen display.
If you view the video at the start of this article, you will notice that I changed the map slightly from my original. This was a result of trying to make it more clear which towers are connected with which specific sites. Unlike the original, I have attached only a single tower to each site.
Hopefully now there is a winnable version of this imaginative type-in simulation from the early 1980s. My version can be played on-line using the MC-10 Javascript emulator provided by Mike Tinnes (with some additions by Greg Dionne:
Choose "Play Game" then "Classic BASIC games" from the menu. Select COUP from the Cassette menu and then type RUN and hit Enter in the main screen of the emulator.
P.S. I added some "flag" graphics. When the flag is controlled by the regime, the colour is cyan. When you take a site over, the flag becomes red. "The workers flag is deepest red!" Vive la revolution!
P.P.S I added back a "partial shuffling" of the location numbers (the single digit important locations).
A few years back I ran across a neat type-in program in a french computer magazine called "Microgouilles" by Dominique Laroche.
It certainly is a wonder of the Internet age that I can lay my hands on a scan of a French magazine from 1983. A further wonder is Google Translate, which helped me read the article. Here is the intro to the game from the magazine followed by a translation from Google (cleaned up a little by me):
Biologiste ou pas, si vous aimez jouer, vous prendrez plaisir à combattre les microgouilles, les derniers agresseurs en date de votre organisme. Un jeu de réflexes, en Basic standard, pour vous mesurer à votre ordinateur.
Biologist or not, if you like to play, you will take pleasure in fighting the microgargoyles the latest aggressors to afflict our species. An action game, in standard Basic, to measure yourself against your computer.
The article continues:
Your body is invaded by a new kind of aggressor: Microgargoyles ("microbes + gargoyles"). These organisms have the ability to reproduce in abundance and die after a brief existence. Microgargoyles then become indestructible dead cells. There's only one way to win-- bring them into contact with a dead cell! To do this, your immune system has produced a new antibody. It's up to you to use it against the proliferation of microgargoyles. How long can you keep alive?
The game's rules
The game takes place on a checkerboard where you will find the microgargoyles " X", dead cells of "0", and the antibody cell "H". To play, you have 5 commands, four to move: W up
left AS right Z down
and the spacebar that allows you to choose your mode of travel, either to push one or more dead cells, or to draw one cell. Pressing the spacebar switches from one mode to another. Whenever a micrgargoyle encounters a dead cell, the microgargoyle is destroyed and you score a point. If the antibody strikes a microgargoyle, they will both become dead cells. As time goes by, the dead cells invade the checkerboard. It's up to you to score the maximum points before the end of the game.
Another neat thing about this program was that it was designed using only the most simple and universal BASIC language commands. At that time the competing computer systems were completely unique in their operation. There were no standard operating systems like Windows, Android, Linux/Apple standards of today. The article provided alterations for 8 different systems:
Transpositions
The lines 90 and 100 of the program allow to position the cursor in XT, YT on the screen. Here's how to write this part of the program for different microcomputers. TRS 80:
90 PRINT@ ((YT-1)*64+XT-1); ATARI:
90 POSITION YT, XT NEW BRAIN:
90 PLACE XT, YT TI99:
90 CALL HCHARL (YT, XT, 1) ZX81:
90 PRINT AT YT-1, XT-1 T07:
90 LOCATE XT, YT, 0 VIC 20:
90 POKE781, YT-1: POKE782, XT-1
100 POKE 783, 0 : SYS 65520 ORIC:
The program also illustrates another feature of the type-in program, the ability, or even expectation, of the users to hack the code. I certainly applied as many tricks as possible that I have learned over the years for speeding up execution. So don't expect my code to look very much like the original. The program is not long. If you're looking for a simple exercise to rekindle your BASIC programming skills, it is certainly worth typing in and modifying the original. Try to get it to work on your specific system. Even in un-sped-up form, the game is fun. The following is a translation of the description of the code from the magazine.
The program
This program was written in a BASIC as simple as possible to be compatible with a large number of microcomputers, with the exception of two parts indicated in the listing.
The disadvantage is that this program does not exploit the possibilities of a specific machine (graphics, sound effects, optimization for the speed of execution).
It is possible and even advisable to modify this program to make it more compatible with your specific computer.
In lines 1980 to 2010, you can change the location of orders.
In lines 1780 to 1795, you can change the dimensions of the checkerboard.
In lines 1800 to 1810, you can change the maximum number of microgargoyles.
In lines 2030 and 2040, you can increase or decrease the difficulty of the game, by increasing the values of the variables DR or TM.
The game can be played using and emulator here: https://archive.org/details/@james_gerrie. Just search "Microgouilles" In my distro of the VMC10 emulator, the game file is in the JimG subdirectory of the Cassette directory and is labelled "MICROBES.C10" for the sake of providing a somewhat understandable English 8 character filename.
MC-10 Microgouilles with simple text graphics possible on any 8-bit computer
Fundamentally the game is a variation of the global arcade hit "Pengo" released in 1983. In that game the protagonist is a penguin who must slide and push ice blocks to crush the attacking sno-bees and their eggs. In this unique French variation this premise is modified to something more appropriate to the land that gave us the medical breakthroughs of Joseph Lister and his discovery of the microscopic world, with a little Gothic ambiance thrown in from the architecture of Notre Dame Cathedral.
