Tuesday, 18 May 2021

An Iron Curtain Adventure: Miroslav Fídler's P.R.E.S.T.A.V.B.A

In the past I ported a Hungarian game and translated it to English (A Hös Lovag) with the help of Google and a lot of guess work. I recently came across another game from "behind the Iron curtain." It's a Czech game with an anti-Soviet theme, written as a protest when Czechoslovakia was still under the thumb of the USSR. It’s called P.R.E.S.T.A.V.B.A.

I picked up on this fascinating game from Arron Reed’s fascinating writeup. The author, Miroslav Fídler, was one of the few good programmers in Czechoslovakia at the time and knew how to code in assembler, so he intentionally used humble Sinclair Spectrum Basic to program the game in order to disguise his identity.  It was funny to read about how Basic was used as a screen to prevent his identity from being rumbled by the authorities– The people’s language being used to protect him against "the people’s government."  He also apparently, according to Reed, intentionally mangled the code to further disguise his identity.

However, the code was generally pretty clean. I'm not sure if he designed it completely himself, or drew on some standard Basic text adventure engine. There was an error in the room DATA that would have the program read beyond the room description strings available, at least in my Micro Color Basic version. There are only 19 room descriptions, but there is no reference to room 19 (which is the location outside the church), but instead some rooms send you to room 20. In any other machine than the Spectrum, this would cause some kind of error, but due to some quirk in Speccy Basic this discrepancy doesn't seem to cause a problem. I think Fidler might be taking advantage of some features of the Speccy that allows it somehow to ignore anomalous reads so that the data from room 19 is left in place despite there being no room 20 data. So no harm no foul.  But I'm not 100% sure what's going on.

I believe that string DATA items and number DATA items are handled completely separately in a Speccy and you can RESTORE to the beginning of any line number you desire, which is a feature Fídler uses extensively. This means you can read all the strings in order or all the number items in order– the Speccy just doesn’t care. But in other BASICs you have to read all items, string and numeric, in their precise sequence, so I had to do some fixing of how DATA statements were read. The program also has a hidden DATA statement that never gets used. Line 103 reads DATA”DON’T BE AFRAID OF THEM!” Chilling.

The program also contains a weird technique of using the PI function along with the functions NOT, SGN, and INT as replacements for the numbers 0, 1 and 3.  For other numbers, instead of using simple digit, Fídler uses the VAL function and then the number expressed as a string "11."  This might be why Reed suggests that the code was somehow mangled as a further protection against detection by the authorities.  However, this might just be a memory saving trick of Speccy Basic. Instead of multiple bytes being used for each numeric value, 2 bytes, one for each keyword token, is all that is needed. I know in Micro Color Basic floating point numbers require 5 bytes, but it might be more in Speccy Basic. Perhaps then even the VAL plus a string and its 2 quote marks can provide a memory saving.  Again, I can't be sure, and I'm not going to pour over the idiosyncrasies of Sinclair Basic to find out.  Reed might be right that it is some kind of red herring for the authorities.

I also fixed a few quirks and annoyances in the parser and added some responses that are shown by Reed, but were not part of the Speccy version.  I think Reed might have used an Atari port as the basis for his translations and discussion. I was able to draw on Reed's translations to help with my own, especially his English transliteration of the satirical acronym used as the title.

I also added a few tweaks to the descriptions.  I added the date to the slogan about "golden February" since most non-Czechs will be unfamiliar with the year of the February coup that brought in communism.  The downstairs hall now "echoes strangely" to give some clue of where to dig. It now prints a message when you hit your item max, chiding you not to be a "hoarder." And a few others. All the graphics and sound in my version are my additions, including a flashing screen for the pyrotechnics at the end.

Info about the game can be found here: https://jggames.github.io/jgames.html

The game can be played here: https://archive.org/details/@james_gerrie

Saturday, 1 May 2021

4K Tandy Micro Checkers: Another Bug Found

Well I think I uncovered another bug in Micro Checkers for the TRS-80 MC-10.  In my initial post about this program I noted that there was some spottiness regarding the implementation of forced jumping by the A.I.  What prompted this comment was my recollection of a moment when the computer moved a piece from its back row, despite the fact that lower down the board there was an opportunity for it to jump one of my pieces. This struck me as odd for two reasons. First, as noted, it is normal to expect mandatory jumping. Second, it is a normal strategy in checkers to protect your back row, in order to delay or prevent the opponent from kinging their pieces. So I resolved to examine the movement algorithm of the A.I to see if there was some obvious mistake. To help me do this I decided to do a line by line comparison  of the similar code from the GWCheckers program I found online on a French blog site.  I found some differences.  The key one I think is this line in Micro Checkers:

230 IFY=7THENN=N+2

(In my updated and renumbered version, as a memory saving measure, this line became: 23 IFY=7THENN=N+2). The corresponding line from the GWCheckers version was:

960 IF Y = 7 THEN Q = Q-2

Since in Micro Checkers the top line is line 7 (computer's side), I had the suspicion that the function of this line was to "demote" moves from the computer's back row in terms of priority.  The N variable in Micro Checkers and the Q variable in GWCheckers seem to be a count for prioritizing moves. The higher the value, the more attractive the move. In other words, the move option that gets the highest N/Q value is the one that gets selected. I think it is possible that the aberrant behaviour I witnessed might have been a result of this + sign instead of a - sign in line 230.  Why else would a back row move be prioritized over a possible jump?

However, I also found an additional check as part of the Micro Checkers code:

100 FORX=7TO0STEP-1:FORY=7TO0STEP-1:IFS(X,Y)>-1ORS(X,Y)=-3THEN130

Whereas, the corresponding line from the GWCheckers version was:

230 FOR X = 0 TO 7: FOR Y = 0 TO 7: IF S (X, Y)> - 1 THEN 350

Also, you will note the Micro Checkers searches from the top row (7) down (0-- the player's side), whereas GWCheckers searches from the bottom row up.  I don't know what the significance of that change is.  I did try simply removing the red highlighted check for S(X,Y)=3, but the resulting game play was terrible, with the A.I moving into positions in which it could be jumped.  So I obviously didn't make that change permanent.  However, I wondered whether I should adopt the bottom up direction of  search.  I suspect that the algorithm simply selects any move with a higher N/Q value as it does its search.  So if it searches from bottom of the board (the human player's side) up, as in the GWCheckers, then a certain priority is given to offensive moves, since they could then be prioritized over any equal weighted top of board (computer side) moves.  I want the program to be more aggressive, especially early in the game, so I made the change to the GWCheckers search order.

Here is the line in Micro Checkers where the move is selected:

290 NEXTC:IFN>R(0)THENR(0)=N:R(1)=X:R(2)=Y:R(3)=J:R(4)=K

GWCheckers:

1080 NEXT C: IF Q> R (0) THEN R (0) = Q: R ( 1) = X: R (2) = Y: R (3) = U: R (4) = V

Because the check is for if a move (N/Q) is greater than any prior highest move, if a move further down the board (towards the human player) has the highest number, no equally high numbered move further back will be able to supplant it. Whereas in the original Micro Checkers, any back row move that gets established as highest (such as the aberrant back row move I noted above) can never be supplanted by any equally high move closer to the human side of the board (i.e more "offensive" plays). I'm not 100% sure the GW Strategy will result in better play and I am starting to lose my taste for playing these games of Checkers against a fairly simple A.I.  But I will continue testing and let you know if I think it needs to be changed back.

Another change that I made is that I noticed that the initial move was always the same from a fresh boot of the computer. The game had no way of randomly seeding the random number process.  However with a little change this could be easily accomplished via the initial INKEY$ input routine for asking whether one wanted to move first.  By relocating the RND assignment to variable T, within that key press routine, the operator's initial key press would randomly seed the random number sequence. So I changed:

50 PRINT@20,"CHECKERS";:SOUND150,5:PRINT@51,"MOVE FIRST?";
60 A$=INKEY$:IFA$=""THEN60
70 IFA$="Y"THEN450
80 R(1)=(RND(4)*2)-1:R(2)=5:T=RND(2):T=T-1:IFT=0THENT=T-1

To:

4 PRINT@20,"CHECKERS";:PRINT@51,"MOVE FIRST?";:T=RND(2):A$=INKEY$:ON-(A$="")GOTO4:IFA$="Y"THEN43
7 R(1)=RND(4)*2-1:R(2)=5:T=T-1:T=T+(T=0):R(3)=R(1)+T:R(4)=4:ON-(R(3)>7)GOTO7:GOTO32

I also found some more memory savings by consolidating a lot of additions and subtractions to N by way of simply adding and subtracting appropriately multiplied results from logical comparisons, rather than having separate lines using IF statements.  This allowed me to fix up the prompt clearing function.  Now when you change your mind about a move, and hit <ENTER> on an inappropriate square, the cancellation and return to the FROM prompt is signaled by the CLEARING of the TO prompt.

The Game MCCHKRS can  be played >>>here<<<. Select the "Play Game" button, then select the "Play Our Other 8-Bit Basic Game Ports" link, and then choose the filename from the Cassette list and type RUN.

Below is an image of the latest version of the game.  If you make a critical error in the early game, the computer can get and stay ahead of you.


Addendum: I put 100 FORX=7TO0STEP-1:FORY=7TO0STEP-1 back in place. It seemed that there was some suicidal behaviour of kinged pieces that might resulted from the change to a search order as in:
230 FOR X = 0 TO 7: FOR Y = 0 TO 7

I find this game interesting because clearly Tandy used an existing version of the program to create its 4K Checkers for the MC-10.  Either that, or someone took their version and debugged it and added graphics to create the PC version. It would be interesting to track down and verify the original author of the program. It doesn't appear that Tandy acknowledged the author of the program their documentation in any way: https://colorcomputerarchive.com/repo/MC-10/Documents/Manuals/Games/MicroCheckers/Micro_Checkers.htm
So despite all the "copyright stuff" in their manual, it is not entirely clear to me that they respected copyright in the creation of the program.  They might have simply paid someone to condense some original BASIC program, without proper consent.



Friday, 30 April 2021

4K Tandy Checkers Versus Tim Hartnell Checkers

Well it looks like I was perhaps a bit hasty in criticizing Micro Checkers by Tandy for the TRS-80 MC-10 (AKA GW BASIC Checkers-- see my last post).  While I was investigating that program I also came across Tim Hartnell's Basic Checkers program.  I was able to copy much of it from a scan and with a little editing to get it to work. The scan can be found here:

https://colorcomputerarchive.com/repo/Documents/Books/Giant%20Book%20of%20Computer%20Games%20(Tim%20Hartnells).pdf

Then I modified it a little by flipping the board display routine. This helped put it into an orientation that allowed me to input moves from Micro Checkers to make the two programs play each other.  It was Micro Checkers for the win!  Way to go Tandy! I might have called it a weak A.I. but at least it's not as weak as Tim Hartnell's Checkers!  I've seen someone on the net also try to put Tim Hartnell's Chess up against the 1K ZX81 chess program.  

Hartnell's Chess, which I also have typed in, bugged out of the contest not too far in. From my experience it is a pretty weak and buggy version of chess.

Micro Checkers gave Hartnell's game a fairly good trouncing. But who knows, it is only one game.  Perhaps I just caught Harrtnell's checkers on an off day. Here is a display of the final board layouts of the two programs running side-by-side:


The green pieces of Micro Chess (on the right) are the A.I. but on the left side those pieces are listed as "H"s (for human), since I was inputting those moves into Tim Hartnell's Checkers as my move (as the "Human" player).  The computer's pieces were listed as "C"s, but they have all been removed.  At least Hartnell's Checkers recognizes that it has been defeated, and I have to say that it has done so graciously.  Hartnell's programs might not be strong, but they always have class.  His checkers even posts the occasional random remark like, "Great move!" and "You got  me!", which is a nice touch.  But Hartnell's program was aimed at computers that probably had at least 16K, so such flourishes were possible.  The fact that Micro Checkers cannot recognize its own victory doesn't take anything away from its more powerful play.  Especially when one considers that it all fits in 4K!

Here's a rough breakdown of the match:














Addendum (2022):

I finally found the origin of Micro Color Checkers for the MC-10. It's just a rehash of Checkers from David Ahl's "BASIC Computer Games" compilation. Here's me playing the original, now also playable on the MC-10.


I had to fix a serious bug involving the computer kinging itself. I had to change line 1240 to make it GOTO 1310 instead of GOTO1420. Otherwise, it didn't remove the old piece position after moving it into the final row and kinging itself. This could result in a situation where it could spawn multiple kings!

I guess this post should be retitled to "David Ahl Checkers Versus Time Hartnell Checkers!"

Thursday, 29 April 2021

4K Basic Checkers Game Program Fixed After 30 Years

I was bored, so I added cursor control input (AWSD) to  "Micro Checkers" from Tandy.  This was one of only a half dozen, or so,  programs released by Tandy before they discontinued the TRS-80 MC-10 after only a year of production.  Like all but the machine language hires pinball game provided by Tandy, it works in the limited 4K memory space of the unexpanded computer.  My updated version of the program still runs in 4K.  I had to use the RENUM command from MCX Basic, and some other code condensing tricks to get cursor input added while still keeping the revised program small enough to fit in 4K.

The original game did not play a very good game of checkers.  You can see in this video that there are opportunities for multiple jumps that are missed.  This got me to wondering whether there was a bug in the program, because it seemed a pretty serious deficiency for the A.I not to exploit opportunities for multiple jumps:

It's a funny little game. Some compromises obviously had to be made to get it to fit in 4K. For example, it doesn't prevent you jumping your own pieces or making 2 space "jump like" moves, even if there is no intervening opposing piece (perhaps someday when I'm bored again I'll try to add this).  And you have to determine/declare your own game loss or end and hit break to re-run the program. Occasionally it completely misses an available jump and simply moves a piece, so enforced jumping is a bit spotty. As I noted, there also seemed to be a buggy routine that prevented the A.I. from doing multiple jumps. But I can't be sure if I somehow simply ended with a compromised version. I got my copy from the Internet of course, since my own original tape has gone to the great bit-rot bucket in the sky. Specifically from chazbeenhad's longstanding MC-10 site:

https://chazbeenhad.tripod.com/

But it also seems the problem is in the version on the Color Computer Archive:

https://colorcomputerarchive.com/repo/MC-10/Software/Games/Micro%20Checkers.c10

Chazbeenhad also helpfully provided a scan of the instruction booklet:

Perhaps the original program worked. But if that is not the case, then shame on Tandy for distributing a buggy program.

As I investigated the code of the program I was able to identify the routine that was supposed to process the possibilities for further jumps after an initial jump made by the computer:

360 X=R(3):Y=R(4):IFS(X,Y)=-1THENB=-2:FORA=-2TOASTEP4:GOSUB400
370 IFS(X,Y)=-2THENFORA=-2TO2STEP4:FORB=-2TO2STEP4:GOSUB400:NEXTB
380 NEXTA:IFR(0)<>-99THEN320
390 GOTO450
400 J=X+A:K=Y+B:IFJ<0ORJ>7ORK<0ORK>7THEN420
410 IFS(J,K)=0ANDS(X+A/2,Y+B/2)>0THENGOSUB210
420 RETURN

I was able to determine that the FOR/NEXT loops in 360 and 370 were meant to be searches for an uncrowned jumping piece designated by S(X,Y)=-1 in line 360, or a crowned piece, designated by S(X,Y)=-2 in line 370.  By inserting the STOP command and running the program I was able to determine that the 360 routine was not successfully searching and finding and acting on possible jumps.  Each search called the subroutine at 400 and that routine made use of a routine at 210 to actuate the jumps.  It used a similar check in line 400 as the main routine up in the 200s, so the problem had to be in the search in line 360.  Initially I was able cut out the special 400 routine and just use the main jump search routine up in 200, to get multiple jumps to occur.  You can see me demonstrating that here:

The only problem was that I had to add a bunch of fudges to the regular move and jump routine (at the 200s) to prevent certain kinds of behaviour. The general jump routine, would of course, process whether ordinary moves could be made in nearby squares, whereas I just wanted it to process further jump possibilities.  I was able to add kludges to that prevented unwanted movements when that routine was called from 360 and 370, but this was not ideal as it added new variables, and I was already redlined for memory space.  But while I was fiddling with the program I had also been investigating other BASIC checkers programs on the Net.  I came across a piece of code for a GWBasic version of checkers that looked surprisingly similar to the code for the MC-10.

You can see that code listed here from a French language blog site:

https://gw--basic.blogspot.com/2014/04/this-is-game-of-checkers-jeu-de-dames.html

It can also be found in this directory on Github:

https://github.com/robhagemans/hoard-of-gwbasic/blob/master/KindlyRat/CHECKERS.BAS

Although obviously a more complex program with graphics for the pieces and board, and different variable names, you can see the basic structure of both programs are similar.  I was able to locate the same multiple jump search routine:

1340 X=R(3):Y=R(4):IF S(X,Y)=-1 THEN B=-2:FOR A=-2 TO 2 STEP 4:GOSUB 1370:NEXT A
1350 IF S(X,Y)=-2 THEN FOR A=-2 TO 2 STEP 4:FOR B=-2 TO 2 STEP 4:GOSUB 1360:NEXT B,A
1360 IF R(0)<>-99 THEN LOCATE ,30:PRINT" TO "CHR$(65+R(3))","CHR$(49+R(4)):R(0)=-99:GOTO 1240
1365 GOSUB 3000:GOTO 1590
1370 U=X+A:V=Y+B:IF U<0 OR U>7 OR V<0 OR V>7 THEN 1400
1380 IF S(U,V)=0 AND S(X+A/2,Y+B/2)>0 THEN GOSUB 910
1400 RETURN

The most serious difference between the two code snippets is highlighted in red. The MC-10 version has FORA=-2TOASTEP4 instead of FOR A=-2 TO 2 STEP 4.

It was using the variable A in the FOR/NEXT loop and also using that variable, instead of 2 to define the scope of the search.  It was also missing the NEXT A at the end of the line. Similarly in line 370 a NEXT for A was also missing.  Instead, the programmer put a NEXT at line 380.  This was probably an attempt to shave off some memory use by using a single NEXT for either of the IF routines used to select between un-kinged and kinged pieces.  The problem is I think that the A was used instead of a 2 to define the search loop for un-kinged pieces.  By changing that and adding the NEXTs at the end of the lines (and removing it from 380), I was able to get the program to make multiple jumps, probably in the way the original programmer intended.

I also added a check to the program to prevent it from allowing you to jump in a backward direction with an un-kinged piece after your first jump.  So now with the added cursor key feature to select moves, hopefully the program is much more easy to play and perhaps a little more accessible for those interested in exploring early A.I. Basic game programming efforts. It's a petty amazing feat to fit a BASIC checkers game into 4K.  Such early A.I. coding efforts deserve to be remembered.

Final note: Instead of entering -1,-1 to signal that you have ended a multiple jump sequence of you own, simply move the cursor onto a white square and hit <ENTER>.  Cursor movement is by WASD.  Use <ENTER> to select piece to move, then select place to move and hit <ENTER> again.  If you make a mistake, just hit <ENTER> on a non-movement space and then restart the piece selection process.


Addendum

I think I might have found the original source of the code for both the GWBASIC and the Tandy Micro Checkers versions of Checkers.  They both might be variations of a demonstration program from John Krutch's Artificial Intelligence for Small Computers, 1981.  A link to this book can be found on the Internet Archive here:

https://archive.org/details/krutch-experiments_in_artificial_intelligence_for_small_computers-1981/mode/2up 

I haven't done a complete line by line comparison of the 3 programs, but from Krutch's description of the algorithm, it seems to go about choosing moves in much the same way as I have observed from the play of Micro Checkers. The result is a very defensive approach. In short, it looks for jumps, then it looks for endangered pieces and then it looks for any move.  Krutch mentions that his program doesn't allow multiple jumps, leaving that privilege to the human player.  So I think that Micro Checkers might be a slightly improved version of the program that continues to process for jumps until there are none, after the initial jump. But all this is just speculation at this point.  I'll have to follow up on this at some point in the future to confirm.  Or someone else interested in the history of the development of such programs will have to.

Friday, 4 December 2020

Ur-games of the First Person Game Genre


Here's the progression: 1974 Maze War by Steve Colley for the Imlac PDS-1, 1978 Escape! by Muse for the Apple II, 1979 Ratrun by Code Works for the Commodore PET. These are the origins of the entire first person virtual world games of today. I wanted to add at least one to my collection of classic games for the TRS-80 MC-10. Maze War and Escape were machine language games. The first one was for an early minicomputer system.  Here's the blurb from Wikipedia:
Maze, later expanded and renamed to Maze War, is a 3D networked first-person shooter originally developed by Steve Colley, Greg Thompson, and Howard Palmer for the Imlac PDS-1 computer. It was largely developed between the summer of 1972 and fall of 1973, at which point it included shooter elements and soon after was playable over ARPANET between multiple universities. It is considered the earliest first-person shooter; ambiguity over its development timeline has led it to be considered, along with Spasim (March 1974, on PLATO), to be one of the "joint ancestors" of the genre.

Very few people would have been directly influenced by Maze War. Most people would have got their first exposure to such games by playing either Escape! or Ratrun. The Digital Anitquarian has a nice write-up on Escape!  He reveals that Lord British was inspired to write Akalabeth by Escape! 

These early attempts at rendering a virtual reality are hilarious when compared to today's ray-traced wonders, but every software revolution has to start somewhere. And Ratrun is part of that revolution-- a very BASIC part. Because it was first published in Cursor Magazine (#13) it would have got fairly wide distribution. People could simply borrow the magazine from a library and type it in for themselves. Very few would have been able to purchase Maze War, but very many might have had their first experience of a computer generated artificial reality in the form of the slowly rendered lines of Ratrun running on a school PET.  As one commenter on the video of my version states "Such fun to see these old machines work like the ant that could."  For more info see:

https://github.com/jggames/trs80mc10/tree/master/quicktype/Strategy%20%26%20Simulation/RatRun

And here's a WAV file for those who would like to try it on real MC-10 hardware:

https://drive.google.com/file/d/1_cDK4VS7bDNg2mEpPTqgEFhvE7Rt9gvb/view?usp=sharing

Another early classic game I got around to porting this week was the original Star Trek game from 1971 by Mike Mayfield written HP BASIC.


The source code I was able to locate was copyrighted in 1972, but the literature clearly indicates 1971 as the beginning of this prolific line of games.  Mayfield must have continued to tweak the program just like everyone else. For one thing, I found a bug in it that affected the way that it handled the Photon Torpedo "trajectory calculator" menu option of the #7 "Computer" option.  It seems to have a problem with a FOR/NEXT loop to allow you to do multiple calculations for the different Klingon battle cruisers in your quadrant.  It runs into a NEXT without FOR error.

The code also seems to provide you automatically with a calculation for one of the cruisers when you first select the option but then flick a variable switch, which then means you must type in your own and the cruiser's sector coordinates for subsequent calculations.  It almost seems like there was some uncertainty or reluctance on the part of Mayfield about introducing this powerful feature, which can guarantee a "one-shot kill" of the enemy.  Part of the charm of the game as I played it in other (of the multiple) versions, is trying to develop the knack of figuring out shooting angles for your limited supply of photon torpedoes.  This feature seems to have been left out by others.

In any case I fixed the bug by getting rid of the NEXT statement and simply looping back to the prompt that asks if you want to do further trajectory calculations.  I also made an alteration to the symbol used for the Enterprise. I changed it from <*> to <^>.  I've seen many version that use <E> too. The original one using the asterisk was difficult to distinguish from the asterisk stars, and looked sinister-- more like an enemy.

Finally, at the suggestion of Paul Berg, one of the Aussie members of the MC-10 Facebook group, I was able to obtain an old Australian Coco magazine listing for the MC-10 "Cattle Baron".  Paul said he had some very fond memories playing this game back in the day.  I had some fun cleaning up the text that I was able to copy from the scan.  There probably hasn't been a working copy of this interesting board game/simulation of the Australian cattle industry for many decades. I added a little graphic of a cow multiplied across the screen to create a "herd," which I added to the round up screen. I also fixed what I think was a typo in the original listing for a little graphic of a bunch of blokes wearing Aussie hats at the "cattle auction."  I think the graphic characters translated to letter keys to be pressed  listed in a REM line just above the actual PRINT line was missing one character.  By looking at the graphic in actual PRINT line and counting the jumbled graphics that appear in the place of what are supposed to be the actual graphic characters, I was able to see that a character was missing and guess which character it was.


Paul will hopefully add some of his copies of the magazine to the small number available on the Coco archives.  That way I can look for a correction in subsequent issues, and perhaps find some more interesting type-in programs for the MC-10.

Well that wraps it up for my programming activities for the last couple of weeks. Now I just have to wait to hear about whether any of efforts earn any recognition from the "The Double-Do" contest being run by www.trs-80.org.uk


I submitted a number of entries from my efforts at writing original programs over the last year.

ADDENDUM

I got runner-up in the Colour program section of the Do-do contest.  You can read about it here:

Monday, 9 November 2020

Key Debounce Delay POKEs


Greg Dionne has been working on a TRS-80 BASIC compiler. In the midst of  corresponding with him about the developments we discussed my normal PEEK(2)ANDPEEK(17023) routine for continuous polling of key input. He then mentioned the "debounce" key delay, which could apparently be adjusted by way of a couple of POKEs.  Here are his comments, which might be helpful for MC-10 BASIC programmers:

More notes for you now that I'm looking at the keyboard routines.

1.  If you want the interpreter to go faster when a key is pressed, set the debounce delay to 1.  (POKE 16925,0 : POKE 16926,1).

2.  To examine the state of the BREAK key, (well, for the compiler at least), take a PEEK at 16955.  255=PRESSED  0=NOT PRESSED

3.  The keys for the KEYSCAN are stored in 16945 to 16952.  This gives you access to each individual key.  So you can tell if more than one key is pressed and which keys.  

4.  CONTROL, SHIFT and BREAK do not have dedicated memory allocated for them. You can query the SHIFT key state via doing a PEEK(3).  But the others will be lost since the interpreter will immediately stomp on the keystrobe after catching a key, so only SHIFT can (reliably) be caught this way.  The compiler will have no trouble querying the other states. 

To see all of this in action:

10 POKE 16925,0:POKE 16926,1 : REM MAKE IT SNAPPY

20 MC=16384:KS=16945

30 FOR I = 0 TO 7:POKE MC+I,PEEK(KS+I):NEXT

40 POKE2,254:POKE 16393,PEEK(3):REM CONTROL

50 POKE2,251:POKE 16394,PEEK(3):REM BREAK

60 POKE2,127:POKE 16395,PEEK(3):REM SHIFT

70 KY$=INKEY$:REM NEEDED FOR COMPILER ONLY

80 GOTO 30

I have added his debounce delay POKES (set to 1) to the following programs and updated my compilations:

DMCHASE

ADVENTUR

ALPHAFOR

BERZERK

BIGRED

BOARDER

CAVERAID

DANTE

DIGDUG

ELAVATOR

FROG

HEIANKYO

LODERUN

METEOR

MOUSE

PENGUINO

QBERT

ROVER

SABOT

SCRAMBLE

TOMB

XRALLY

NOSTRO

ABM

BRICKOUT

FARTGOAL

FLYWHEEL

GRIDFACT

LITTLEBR

MEANIES

MILLIPED

RCHASE

RESCUE

SHOPIFT

SPACEWAL

MCJOUST

PONGNEW

GOLDHUNT

GOTCHA

RCHASE

TANK

MILLI

CAR

It seems to make a noticeable difference.  Movement seems much smoother and responsive.  I'll be adding the POKEs to other programs over the next little while.


Sunday, 8 November 2020

Warren's World: The Lost Colony

I've been working on a conversion of "Warren's World: The Lost Colony," which is an old game written in GWBASIC for the PC. The following is a description I found on the Net, which I have fixed up a little (I think it was translated from Russian or the author was a Russian speaker).  I have also added a few highlighted terms for items that are needed during play):

Lost Colony is a turn-based economic strategy game that tells the story of the difficult fate of a human colony in a distant solar system. The game is based on the mechanics of the popular early 1980s game Hammurabi (the progenitor of the "construction and management simulation" video game subgenre), the essence of which boils down to the extraction and distribution of useful resources among the constantly growing population of the state/city/society.

There is a Lost Colony and the plot is as follows: In the distant future, during the exploration of deep space, a planet suitable for life was found, and since resources on Earth were dwindling, it was agreed to seek to colonize the newly discovered world. The first people sent were farmers and construction workers to prepare a new "home" to receive the rest of the settlers. But alas, everything did not turn out as planned. While the first starship was getting to the colony another war broke out on Earth and the colonists were left to fend for themselves. The pioneers, abandoned to their fate, suffered significant losses in the first years in a new place until they developed an ability to supply a minimum number of necessities. These had to be carefully issued per person. To organize production and distribution of these benefits an elected position was established-- "Chief Economist." This is the role the player takes on.

         Goal: To hold the position of Chief Economist for 15 years (i.e. 15 moves).

Management is quite simple: At the beginning it is necessary to distribute people and robots (the latter are intended only to increase productivity-- machines cannot completely replace people) across five sectors of the "economy" (Transport, Mining, Energy, Farms and Manufacturing). Then, each turn, the computer asks a series of questions: What products will be produced (Robots, Transports, Manufacturing Plants, and Consumer goods) and in what quantities, what amount of "wages" will go to the workers, and what percentage of those wages will go to taxes. Nevertheless, the player is not limited to being a mere "accountant"-- You will also be asked to explore new territories. To do this, a map of the entire colony is displayed divided into regions; just indicate the regions you wish to select with the cursor and the computer will display information on the resources located there. But it is not enough just to explore new lands-- full-fledged mining and expansion of farming of these lands requires that they be populated. Finally, at the end of the turn, a certain event can happen (or maybe not)-- as a rule they are not very pleasant, such as: epidemic, explosion, etc.

Remember, in Lost Colony you will have two "opponents"-- these are the ever-growing population and proper adjustments to the wage level required each turn. If you cannot provide people with everything they need, you will lose your post as chief economist, which will automatically lead to the end of the game.

Summarizing all of the above: this game, despite the relative simplicity of mastering it, is not suitable for only "a couple of evenings" of play. It requires a very detailed approach, preferably with a calculator. Also be prepared for the fact that Lost Colony does not have much in the way of graphics and looks more like a specialized piece of software for financial workers.

-- Skud

My TRS-80 MC-10 version is a port of a GW BASIC version for the PC. It's a work in progress.  My progress right now is hampered by my inability to play the game very well.  So if there's anyone out there willing to do some play testing, the game can be played online here:

https://archive.org/details/@james_gerrie

I'll leave it open to be played for a while during the debugging process before removing it until I can fully determine the original author's intentions regarding distribution.

Here is a screenshot of the PC version of the game map:


Here's another Description of the game that I found online:

Lost Colony is a resource management game which takes place on another planet, site of the first human settlement off Earth. As the economic administrator of the colony, your job is to keep the population happy and occupied, and to generally run things smoothly until the next supply ship arrives from Earth - in 15 years.

Each turn tasks you with allocating resources for the upcoming year, by dividing them among the five major industries (farming, mining, energy, manufacturing and transportation). These resources include human labor, robotic machinery and the planet's raw materials; production quotas can be diverted towards various goals, consumer goods handed out to keep the populace contented (and obedient), and new areas can be explored and settled.

Along the way, you'll have to deal with such misfortunes as labor strikes, famine, industrial accidents, plagues and natural disasters. Savvy governance will ensure that the struggling colony prospers, while continued mismanagement will have you booted out of office in disgrace.

Cebion # 2020-03-05 16:04:38

There is also a PC Magazine review of the game.