Robert has really been working hard on BDASH game. I really like the BDASH016 version that he has created. His animation of the little "miner" character is a really nice touch. And the sound and visual effects he has contributed (the explosive flash and stepping noise) have really punched it up. And he's wedged in some instructions too! I think we must be approaching a definitive version for the 10-liner contest, if not finally reached it. Thanks Robert!
I have also been working on a new program for the contest called MINIDUNG. It's a graphic 3D first-person dungeon crawler, and all in 10 lines. Because of the limits of 10 lines the user interface has to be fairly primitive. You are basically limited to the INPUT command using numbers. So, for example, entering 1,2 in response to the MOVE,DIR prompt means "move 1 space in the 2 direction (i.e. West). Entering 0,2 means stand on the spot and simply turn West. Still it's not too bad. Here are some screen shots:
The blue blob with a red centre is supposed to be a Giant Spider. The purple dude is supposed to be a Demon. The red dude is supposed to be "the Evil Wizard." There are also other monsters. You must defeat the wizard to win the game. Here's what walls look like as you navigate the maze:
The 10X10 mini-map on the right slowly fills in as you explore. The little green blocks represent clear areas whereas the black blocks represent walls. Colours also will appear indicating the different monsters you run across as you explore. You can choose to fight them or run, but if you run there is still a reduced possibility of damage. There are 10 levels of play (more if you really want to try them). Here is the source: https://github.com/jggames/trs80mc10/tree/master/quicktype/Dungeon/MiniDung
Anyway, this is where you can download the VMC10.exe emulator, which has all my Basic programs in the JimG directory under the Cassette directory: "Jim and Charlie's TRS-80 MC-10 Games"
This is also likely my last post for the 2016 January Retrochallenge. Thanks to Mark Wickens and all the other participants for a month of fun and learning.
My fellow MC-10er from the Yahoo group, Robert Sieg, showed me how to access 256 character long lines on the MC-10 instead of just being stuck with the standard 128. He used the MCX version of Basic (a modified version made by Darren Atkinson from the group), which adds all kinds of commands and improvements, including longer lines. The downside is, one cannot use any of the special added commands, since regular MC-10s wouldn't be able to run the program. The upside is that the regular MC-10s can load programs with longer than 128 char lines just fine! So edit in MCX, CSAVE and then load and run on a regular MC-10!
With all the extra space I have added a few functions to Dash. Now the program displays the "code" for whatever puzzle is currently on-screen. This is really just the four peek addresses of the random number generator seed, which is a 32 bit number stored in 4 bytes (thanks to Darren for informing me where they were located). So if one discovers a very interesting puzzle, the code can now be written down. Also, during any game hitting "P" will call a routine that allows you to enter the four numbers and poke them back in to memory and then display that specific puzzle (after you also enter the difficulty Level #, which also must be recorded).
I know its unlikely that legions of people will be clamouring for such a feature, but its nice to have. I've run across a few puzzles that were quite challenging and regretted not being able to retrieve them in some way. My son told me that some games like Civilization and Minecraft, actually have features to "set the seed" so that specific "randomly" generated worlds can be recreated by other people. In fact, he told that alpha codes can used and some have been discovered to strangely correspond to the worlds created, like the word "hell" ends up creating a largely lava world in Minecraft, or something like that...sounds a bit mythical, but...
So now there is something like that, in miniature, for the MC-10.
Robert also did a modification where he replaced many commonly used multiple digit numeric constants with single character variables, which could now be added to a longer line 0. I reordered his variable declaration just a little to put some of the more critical main loop and commonly used variables earlier in the list. It's my understanding that earlier is better as the variables get stored in a lookup table and the earlier they are in the list the faster they can get used by the interpreter. I therefore put variables only used during initialization later in the first line. Don't know if any of these ideas are true, but Robert's use of single variables certainly produced a quantum leap in speed.
Here's some of what he wrote:
Hi Jim,
First I carefully added variables that were not used before by the program using a text editor.
Then once I was happy with all the changes I saved the text file and loaded that into the MCX with quicktype because the MCX has a longer 256 limit per line. Then I saved that loaded text file with a CASVE. Now the good old MC-10 can load it and run it.
I was surprised that the speed increased so much. The way I checked the speed was to clear the top and have the hero ----> X walk across the entire screen timed. In both versions I got 16.13 seconds for the original and 12.92 seconds for the optimized.
12.92 / 16.93 = .8009 ----> a %20 difference. kind of shocking I was thinking it would be maybe half that.
Sure we could do a dual authorship but the prize is offered at the expo right? Are you going?
By the way it could be tweaked just a bit more but it can be quite time consuming to do the conversion.
Warm regards,
Robert
Since Robert had been so helpful, I put his name on a new title screen I added to line 0.
Robert also made some suggestions about scoring. It became clear that since he was playing the game by himself that he needed some way to see whether he was improving in his play. I, on the other hand, was primarily playing the game against my son and therefore repeating maps with him trying and then me, and so on.
It became clear that there were possibilities for whole bunch of alternative "play modes." If it weren't for the 10-liner restriction these could be easily handled in one program with some menus.
What I added to try to satisfy some of these different ways of playing was a timer function and report of the number of tries for each puzzle. These were in keeping with what my son and I had been doing. We would take turns trying to complete a map, and the person who got the highest score and lowest time and # of tries was "the dude" for that puzzle. I guess you could call this "two-person" or "competitive mode."
I think what Robert wanted was something that could be called "tournament mode." A person tries to get the best total score for a fixed number of maps and also gets rewarded from trying maps of higher difficulty level. So I also added an aggregate score for all maps completed that takes into account the time factor in the scoring for each map and the number of tries needed for the total number of maps completed, etc.
I was also able to combine some lines from the old program and use more IFs instead of an ON-GOTOs (256 chars to play with certainly is very liberating), which freed up a line for the puzzle # entry routine that allows the player to select specific puzzles. Robert also pointed out a number of places where he though program logic could be rationalized, which was very helpful.
The biggest change that his feedback prompted was from a suggestion to add a "bomb" if there was a wall that totally blocked passage to the exit it could be removed. So I added a bomb (wait the NSC will flag this)-- I mean to say I added a routine to the game source code so the player can now blast virtual obstacles once per puzzle in our computer puzzle game;) Just hit the SPACE key and a series of reverse boulders will appear in the 4 cardinal directions around you. The player is able to move through these boulders. Blue wall units around the edge will not be destroyed, nor will regular boulders. However, the exit and diamonds can be destroyed so one must be careful.
I also added an auto level select feature where if the player just hits ENTER between maps the game uses the level selected for the last map.
I also streamlined the key entry routine quite a bit so the game no longer uses any Ctrl keys, just regular keys:
ASWZ to move
R to restart a map
N for a new map
P to enter a code for a specific map/puzzle (4 numbers separated by zeroes)
SPACE to blast around you.
I also changed the exit character to a reverse "E"
Now, I should start thinking about porting it to the Dragon and Coco.
Addendum:
After another set of helpful suggestions by Robert I made some more changes.
Now you can choose skill level at start-up. If you choose 1 then the program uses the standard boulder fall routine where only being in positions like this can kill you: @ X █ ███
But if you choose 2 then any boulder falling next to you (or even just flying past) can potentially kill you such as:
@
X █
███
This makes skill level 2 much harder. Score is also affected. Now the higher the difficulty level of the puzzle and the higher the skill level makes each diamond worth more.
Also different difficulty levels provide different numbers of bombs: 1-29=1 bomb, 30-59=2 bombs, 60-89=3 bombs.
Dave Maunder (Bushy555), a member of the Yahoo MC-10 group and an avid user of the VZ200/300 posted that there is an up-coming 10-Liner Basic game programming contest being hosted by the Retrocomputing site Homputerium and posted on Vintage is the New Old. I decided to give it a try, so I dredged up an old project based on a video I saw on YouTube for a text based game written in C++ called "Dash." It is a version of the classic game "Boulder Dash." The use of text graphics inspired me to try to recreate the boulder rolling mechanics on the MC-10. Obviously, Basic is not as fast as C++, but with some tight coding and a limited number of boulders it might be doable. But could it be done in 10-Lines?
I think the answer is yes. The program I have created is 2 parts puzzle game, one part quick reflex arcade game. Well, one part might be pushing it. It's not super fast, but occasionally good timing will be critical to solving the randomly created puzzles, because the boulders do move and are erratic unless blocked in or wedged against each other.
The game mechanic is simple. Boulders fall when there is green space beneath them. They roll randomly from side to side if there is green space on either side of them. They won't crush you if they are next to you or right above you. The only way they can crush you is if they tip off something (have green on either side) and then roll into you. In other words if you are the X and boulders are @s then:
@
X █
███
is a very dangerous position to be in. I think of it as the boulder rolling down off something and then on into you. Normally, as a confident miner, you can easily handle boulders, using bracing to keep them above you or temporarily wedging them in place when they are next to you, or blocking them if they are on level ground rolling toward you. But if they roll off something and then immediately head towards you, you're doomed.
Obviously, to solve the puzzle you must also not become blocked in by boulders, so you must be careful where you mine and be wary of how avalanches will occur so as not to hinder your movement to the exit (symbolized by a reverse "I"). It might also be necessary to create avalanches in specific ways to effectively clear the way. That being said, the puzzles are random so sometimes there will be no way to exit, or you might be trapped from the beginning. If that is the case just hold down Ctrl-J (Junk the maze/puzzle) to get a new puzzle.
Also, if you hold down Ctrl-D (Do-over) before exiting the maze, the maze will be redrawn in its initial starting layout, and you can try again. In fact, I found this feature useful when playing the game with my son. The first person tries the maze and gets to a point before exiting but having gathered as many of the treasures ("*" symbols) that are also scattered throughout the maze as possible, and then hits Ctrl-D. The score achieved to that point is reported and the maze is redrawn in its starting condition. Then the other player can try to get a better score. We found it interesting for the person waiting for their try to sit away from the screen so they couldn't see the mistakes being made by the other player, so each player gets a fair try at solving it on their own. Then the scores can be compared and a new maze created.
The game starts with a level prompt. This simply determines how many immovable ("█") wall blocks get scattered around. It also influences the scoring. You get a number of points equal to the level for every treasure ("*") that you collect. I found that 20 is a good starting number. Numbers below that might be useful for young kids, and much above, that starkly increase the number of unsolvable puzzles that are generated.
Addendum
One of the little annoyances I have with the current code is that it is too tightly packed to add a random number seed feature. If you load from a cold start the game will always proceed through a set sequence of pseudo random mazes. However, my son Charlie and I were able to overcome this by typing in a command like this: PRINT RND(some number)
to reseed the pseudo random number to something less predictable than the last number called by the RND function. However, in Color Basic if you use a negative number in the RND function, the pseudo random number generator gets set to begin at that specific number, so that you can repeat specific desired sequences. So typing something like: PRINT RND(-17026)
will generate a specific puzzle (in this case one with a blocked exit). Try it! Using this method people could in principle "discover" and keep track of unique puzzles that they find particularly challenging. Also, of course, you will have to choose the same Level for the exact puzzle to be regenerated so for puzzle (-17026) use level 20 to see the blocked exit.
I ported the simple empire simulation game "Ministry" from C to Micro Color Basic back in mid November. Now I have made the few minor edits needed to make it work on Color Basic for the Colour Computer and Dragon.
The original code wasn't very hard to translate to Basic. Not too much in the way of distinctive C programming techniques were present and only the simplest of commands were used. I wouldn't be surprised if the program was originally Basic and then translated to C. My other hypothesis is that it was some kind of educational assignment. In any case it is quite complex in its game play and options despite its relative simplicity as a program. It provides a simple example of a "God Game" for the MC-10 (and now the Coco and Dragon) in Basic. You don't play to "Win" because as far as I can tell, there are no "winning" conditions or a win routine. Instead, you play to achieve the highest amounts of wealth, land and scientific achievement for your society as possible.
Back when I was first playing such "type-in" style games I could imagine playing a game like this for a score to compare with a friend's achievement. However, I think the game could actually be easily modified to allow two players to play against each other or to add some kind of arbitrarily determined set of winning conditions. I would also like to add some kind of map function to visually represent the territorial expansion of your "empire." I take it that the title represents the player's ability to manipulate "with God like power" all the major "ministries" of government, which makes me suspect that Wesley may is a Brit, or from somewhere else that uses a Westminster system. Here's a video to give you a sample of the game play:
If anyone plays the game please let me know if you run across any errors, bugs or suggestions. I try to play it enough to make sure there aren't any obvious programming errors, but you just never know.
For instances, I realized that there were several places where I added some INT functions to clean up the display of numbers in the MC-10 version right near the end of my editing back in November (last minute changes), which ended up making 2 lines (2040, 2301) too long for the 128 character limit of the MC-10. When you "quick type" the program into the Emulator, which just takes a text file and dumps it into the MC-10 as if you are typing it at the keyboard, these lines just get chopped. By revisiting the project to port the program to Coco and Dragon, I had one more opportunity to find such snags.
Since it didn't take too much effort to fix Ministry I turned my attention to the Mini Pac-Man program I discussed a few postings back. There were a few things niggling at me about the game. One was that it had an an extra Sound statement in the original source code, which really slowed the game down. It sounded for each move you made even when you were not eating dots. It was noisy and slow and I couldn't hear it in the video of the original Atari version, so I took it out. I also didn't like the reverse video greater-than symbol for Pac-Man. I thought some simple changes would allow me to use either a normal less or greater-than symbol combined with a "=" sign to simulate mouth movement. I also wanted to add variable scoring for the different levels (higher scoring for higher levels) and a visual image of whichever character (Pac-Man or the Ghost) that is left standing on the field at the end of the game. Finally I wanted to add the Quick Keys pokes for the Dragon version, which are really necessary to make the game playable on keyboard of that system. Anyway, here's a video of most of the changes:
Since the video I also added a slightly more satisfying sound and representation (via some additional Pokes) of the player or ghost eating the the other at the end. Here's the source code of the Dragon version with the Quick Keys pokes in line 0:
0 REM FOR DRAGON->IFPEEK(269)+PEEK(270)<>1THENPOKE65283,52:POKE256,116:POKE257,1:POKE258,81:POKE259,126:POKE260,PEEK(269):POKE261,PEEK(270):POKE269,1:POKE270,0:POKE65283,53 1 POKE65495,0:INPUT"LEVEL (1-9)";E:CLS0:M=1024:FORY=0TO9:FORX=0TO9:POKEM+X+Y*32,46:NEXT:NEXT:DIMF(255):F(0)=60:F(8)=62:F(94)=62:F(9)=60:F(10)=60:X=0:Y=0:A=9:B=9:W(0)=98:W$(1)="YOU WIN!!" 2 P=M+X+Y*32:G=M+A+B*32:C=PEEK(P):D=PEEK(G):POKEP,F(S):POKEG,98:S=0:IF(PEEK(344)ANDPEEK(343)ANDPEEK(342)ANDPEEK(341))<>255THENS=PEEK(135) 3 Q=(S=8ANDX>0):Q=Q-(S=9ANDX<9):R=(S=94ANDY>0):R=R-(S=10ANDY<9):X=X+Q:Y=Y+R:IFC=46THENPOKEP,61:SOUND99,1:C=32:T=T+E:PRINT@11,T; 4 P=M+X-Q+(Y-R)*32:G=M+A+B*32:POKEP,C:POKEG,D:IFRND(11)<=E THENA=A-(X>A)+(X<A):B=B-(B<Y)+(B>Y) 5 ON-((X=A)+(Y=B)<>-2)GOTO2:W(1)=F(S):C=-(T=(E*100)):P=M+X+Y*32:POKEP,61:SOUND99,1:POKEP,W(C):PRINT@353,"gAmE oVeR";:PRINT@385,W$(C);:PRINT@416,;:RUN1
Grand Master Chess Version 0.9 is a program I found on a moldy old 5 1/4 disk from my basement. I've been looking for Basic and C code that I worked on back in the 90s to put up on my new Github repository. It wasn't one of my own programs, but it was on a disk labeled "Basic09 programs." I found a scan of a July 1992 issue of Rainbow Magazine that mentions the program as being uploaded to the OS9 SIG on one of the the early on-line services:
GRAND MASTER CHESS 0.9 MATIIOMPSON Matthew Thompson
Didn't know how it would play, but I tried to load it up into Basic09 on my OS9 level 1 Coco and run it. It wouldn't run because of some obscure error. Tracked it down to a Print statement that indicated that a certain string was causing a problem. The string contained a reference to CHR$(31). After searching through the OS9 Level 2 manual I realized that the code was not meant for OS9 Level 1, but rather was used to turn on reverse video on Level 2 screens. It was strange, because the code looked formatted for a 32 character wide screen. Running it on my Coco 3 under OS9 though showed that the screen was switched to a 40 X 24 Window by an embedded use of a Display command being piped to the system. However, it looked like the main part of the screen could still easily fit on a 32 X 16 screen, and that besides the use of reverse video, there were nothing else too fancy going on. I thought that I could convert it to MC-10 with the use of my reverse video subroutine:
Well, as the above screenshot indicates it was possible, however, I don't know how much of a success it was as a port. It plays a terrible game of chess:
If you're wondering, the original code on OS9 Level 2 also plays that way...
There was a 5 line Basic mini game for the Atari 8-bit demoed on Youtube:
The original was written by Robin Edwards in 1987 and published in Atari User in its September edition. I created an MC-10 version back in December and have now ported the code to Coco and Dragon). It shows how the TRS-80 MC-10 (and Coco and Dragon) could implement the program in 5 lines contrary to what RPKVids suggests in the video. He says about mid way through the video:
"I'm not sure if something like this could be done with such a small amount of code on most of the other old school computers..."
Challenge accepted and met (I think).
You be the judge.
Thanks to RPKVids for the Retrocomputing inspiration. Here's the Dragon/Coco version of the code:
I made a few minor changes to Square Force to try to squeeze a few more microseconds of speed out of the main loop. As always, it's an exercise in futility,as the game will obviously be too slow for any serious gamers (like my son) raised on the adrenaline rush of modern consoles. However, for old farts like me, a nostalgic romp with a plodding type-in can be a pleasant way to while away a few minutes.
On an entirely different note, in the course of doing some painting in my home over the Christmas break I took down a sensor for an home security system (We've never used it and never intend to). I noticed that it is just about a perfect size and shape to cover my MCX attachment for the MC-10. My mind was jogged about this possibility by a recent post on the Coco mailing list by Ed (the Zippster):
MCX BASIC is an extension of the MC-10's Micro Color BASIC, including a number of additional commands and the ability to use Emcee server.
Emcee server lets you use directories on a PC or Mac as a virtual drive in order to store and run programs and data easily over a serial connection (same cable as you'd use for Drivewire).
The MCX-128 is another design by Darren Atkinson, creator of the CoCo SDC, and a great upgrade for the MC-10 Color Computer.
I just sawed a centimetre slot in the bottom and the MCX fit right in and easily plugged into the back of the MC-10. Now instead of an old plastic package for screws spray painted beige, I have what looks like a legitimate case from a computer peripheral manufacturer called DCS (the security company):
I had thought that for this Retrochallenge I would stick to cleaning up some recent programming projects and porting those projects to Coco and Dragon. However I couldn't resist the temptation to make a new game after I saw a video on Rudi Horne's Youtube channel "Let's Compile." I really like Rudi's channel. He gets his hands on some really nice source code. He compiled a game called "Square Force" made in Quick Basic, which is a variation on the classic arcade game "Targ." Thanks to Allen Huffman for pointing out this connection and also for his OS9 utility "Towel" which helped me do some work recently on cleaning up my OS-9 files for the Coco! Anyway, here's a video from Rudi's site:
In addition to making "Square Force" I completely reorganized my mess of source files for my Basic, Basic09, QuickBasic and C programs using Github. Now whenever I change the source code, my files are kept up to date in my Github repositories for the MC-10, Coco and Dragon (and old DOS programs). My Github can be found here:
Part of doing this clean-up involved digging into OS9 (a unix like operating system for the Coco 2 and 3) in order to get some of my old source files un-archived from the Coco's version of LZH zipped files using the archiver utility LHA.
This is a screen capture of the VCC Coco emulator running OS-9 level 2 and its Multivue GUI. Here you see my "Sources" directory with a bunch of directories with some of the programs I have written for that operating system. I had all these files on my website in .lzh archives which 7zip can't deal with, so I had to head back into the land of OS-9 in order to break them out again and put them up on Github. Lots of fiddly command line work, which is something I have't done in a while since I have been mostly focussed on 8-bit Basic programming on the MC-10.
So this weekend I was able to accomplish a bunch of things:
Github setup to be a repository for all my source files
Dug up most of my old OS9 source code (some is still AWOL though)
Made a new Basic game "Square Force" for the TRS-80
Well I've got one more program ported from MC-10 to Coco and Dragon. Took a little longer than it might because I'm using a new computer, a broken-screened laptop from my eldest daughter salvaged by hooking it to a monitor, mouse and keyboard, which runs Windows 10. Thanks Maddie! Had to clean that up and get all my old software installed, including some VB basic macros for MS Word to modify the code from the MC-10 (mostly to put spaces back in where Coco Basic needs them).
Road Race is a program I wrote a few months back. It's your topical overhead race track game. I saw a version for an Atari 10-liner game contest. It had a track which you basically maneuvered a dot representing your car around while random dots appeared on the track making it harder and harder to avoid a collision.
The game play didn't appeal to me very much (although the sound is very nice), so I wrote a little routine to record all the coordinates of a dot which I maneuvered around the track I had made, which I then recorded into DATA statements and load into an array at start up. I arranged my trip so that you could add an offset in the X or Y or both for each point and end up with a slightly different "route" for each lap. Then I just replayed each of these with random offsets and starting points for three competing cars. For speed I just randomly choose for each iteration of the main loop from either moving through the array coordinates by jumps of 1 2 or 3. Since I choose for each iteration the average "speed" is about 2 for each car for each lap as a whole. When the cars reach the end of the array a new random offset is chosen and a new lap is begun.
Now my dot was racing against three competing dots going around the track. My speed is similar. My dot either moves by jumps of 1, 2 or 3. Three is really hard, so it's only really good for straightaways. Speed 2 is good for general driving and speed 1 is useful if you need to back off from other cars, because collisions with anything including them or the walls ends the race. The result is a game needing a lot of careful "gear changing" and steering. I hope you like it. Here's a YouTube video of it. Needless to say, the authentic race car sounds are not coming from my MC-10 but are courtesy of YouTube.
This is my second post for the month long 2016 January Retrochallenge. My hope for my next activity is to move on to the Civilization-like simulation "Ministry..."
Well, this is my first post for the month long January Retrochallenge 2016. My goal is to document some recent programming projects of mine for the MC-10, specifically my efforts at final debugging and porting of these programs to the TRS-80 Coco and Dragon. My most recent programs have been the following:
RUBICON + (A coco war game simulation)
CANFLAG * (a graphic with some music, which still needs work)
ROADRACE * (a overhead track car race game)
MINISTRY + (a text simulation a la "Civilization")
BARREL + (simple moving dot game from a Coco magazine)
The ones with the + are ports from Basic code scavenged from the net in various ways. The ones with * are programs the code I have completely (or substantially) written myself. Some are rather minor basic programs, so I wont bother trying to transfer them to Coco and Dragon. I generally try to transfer only the programs I have written myself or ones that are more substantial and might actually be of interest to others. This principle reveals a basic divide in my hobby programming.
When it comes to the MC-10 the main goal of my retrocomputing hobby is to simply add as many Basic programs to the stable of those available for the machine as possible. This is motivated by a desire to overcome some of the neglect of the machine that occurred back when it was released and then orphaned by Tandy in 1983 and by my love of the early style of program distribution known as the "type-in." Since, the MC-10, as an orphan computer, never had a large software base, the majority of my experience as an early user was largely of trying to convert programs from the Coco and other systems from those published in magazines. A little later I got a modem and was able to get a few programs from that source.
Later I got my hands on a Coco, which was a more serious computer (my sister got it for university, but I had it for a summer). Then my computing allegiance shifted (somewhat) to the Coco and to higher levels of programming (BASIC09, C, Pascal). So my experience with the Coco was really more about programming than just fooling around with "type-ins."
So I think, I will focus on porting ROADRACE, MINISTRY, FPANIC and 11ASTER to Coco and Dragon. All of these programs are more substantial programs that are completely new to the Coco. Some of them required serious conversion work, such a Ministry, which was originally written in C.
I have a wish list of things to work on.
- I'd like to possibly ad a graphic element, like say a map depicting your empire, to Ministry and maybe some other simple graphic flourishes
- and make a better win graphic to FPANIC (coco version)
I have already managed to port FPANIC to Coco, but there are some differences in how it handles the weird Semigraphic 6 video mode from how the MC-10 does that led me to cut out an elaborate win graphic to get it running in time for distribution on Christmas day (an arbitrary deadline). I also tweaked the MC-10 version's win routine, and would like to add those elements to the Coco version.
