14

I am reading about the history of the "game" Amazing that was converted to MS BASIC in BASIC Computer Games. These articles often note that the game has a bug in it, but I cannot find anyone that describes what that bug might be.

The first mention I found was on this now-dead blog, but he does not document the bug in the article or the resulting Java code. Nor do any of the other pages I found on the topic.

Does anyone know what bug they are referring to?

I ask, because I am seeing a bug when I run it in my interpreter, it goes into a loop maybe 1 in 5 times. But I suspect that's not the same; if it was that common it would have been fixed.

5
  • 3
    Many versions of MS BASIC have RND() functions that aren't terribly random, but return different patterns of output. I would not find it surprising if a bug would cause a program to get stuck in an endless loop for some sequences of random values that would never occur with common versions of BASIC, but would occur frequently with some obscure ones.
    – supercat
    Nov 17 at 21:43
  • 3
    He states (in the blog) that he fixed one bug (presumably, that is the bug to which you refer) whilst refactoring into Java. It wouldn't surprise me if one of the GOTO statements was incorrect, or missing - seeing how many GOTO statements that there are in the code.. Nov 17 at 22:08
  • 2
    @super: Also, some versions of BASIC required a RANDOMIZE statement if you didn't want the exact same "random" output every time you ran the program.
    – dan04
    Nov 17 at 22:55
  • The original code from texts DEC EDU Newsletter Issue Number 4 (1972) is extreme spaghetti code. There are lots of opportunities for runtime errors. I've keyed it, but I need to fix some typos
    – scruss
    Nov 18 at 4:05
  • 1
    FWIW, the chap that wrote the now-dead Mindspring blog (alanh) is actually Alan Hensel. From that wiki page, there is a link to his game of life page, at the bottom of which is his email address. Maybe it is worth dropping him an email and asking him - seems the best method to getting an accurate answer... Nov 18 at 15:05

2 Answers 2

20

I wrote an article on finding two bugs in Amazing for trs8bit - Volume 17 Issue 03 - Sept 2023.

I found two bugs, but no loop.

  1. No maze exit. The code can finish with Z=0 meaning no exit was drawn in the maze. This can be fixed with a check at the end and creating a random exit:

    1200 IF Z=0 THEN RND(H):V(X,V)=V(X,V)+1
    1205 FOR J=1 TO V
    
  2. Incorrect "up" direction. Line #695 of the Microcomputer edition reads:

    695 Q=1:GOTO 830
    

    But line 830 is internal to the "move up" routine. Examining the code, the only possible directions at this point are RIGHT and DOWN and the line should GOTO 710 which handles those cases.

    In the TRS-80 Edition, the problem is line 830 GOTO 990 which should be 830 GOTO 850 for the same reasons.

5
  • 1
    Very nice bug analysis in the PDF! It might be a good idea to include the actual line to fix point #1 in the answer above, i.e. 1200 IF Z=0 THEN RND(H): V(X,V)=V(X,V)+1 and the renumbering of the original line 1200 to 1205 FOR J=1 TO V - just in case the link to the PDF dies. Also, the last two paragraphs should be indented to make it clear that they belong to point 2. Nov 19 at 10:33
  • I've noticed that 2x2 mazes always produce the same design with no exit. I tried it on a PET emulator and get the same result. Does everyone else get the same? Nov 19 at 13:57
  • @MauryMarkowitz - Is that with the two fixes or without? Nov 19 at 14:12
  • 1
    Without, I'll try again with. But if this is the same bug I'm surprised it was not better known, I'm sure 2x2 entries were not that uncommon! Nov 19 at 14:21
  • 2
    Yes, that does fix it. Given how trivial it is to trigger I'm surprised it was not fixed by the time of BCG. Nov 19 at 14:26
6

I couldn't find exactly the source version you ran, Maury.

The original — written by Jack Hauber and first published in DEC EDU Newsletter Issue Number 4 in 1972, rekeyed by me here: amazin.bas — does not get stuck in a loop with either your interpreter or Michael Haardt's Bas. I ran it 10,000 times in this test harness that feeds it random dimensions from 3–13:

for i in {1..10000}
do
  w=$((RANDOM % 11 + 3))
  h=$((RANDOM % 11 + 3))
  echo -e "$w\n$h" | retrobasic ./amazin.bas
  echo ''
  echo $i $w $h
  echo ''
done

Like the version Peter Phillips tried, it sometimes generates mazes with no exit. This may be the bug referred to in other writeups.

The version from Scott Moore's archived page Classic Basic Games Page (amazing.bas) also doesn't get stuck in RetroBASIC. It too has the occasional no exit bug.

6
  • I just ran it about a dozen times at 5x5 and it went into the loop. It doesn't happen all the time. I turned on line tracing and it is actually looping between 210 and 1000, so that's what I'm looking at now. I used the same code you linked to. Nov 19 at 13:58
  • Ok, tried your script, it went into the loop in iteration 50. Are you running 1.8.5? Nov 19 at 14:06
  • And using the bug-fixed version found here, I am still looping: github.com/coding-horror/basic-computer-games/blob/main/… Nov 19 at 14:28
  • Most odd. I can't get RetroBASIC to get stuck at all. Running 1.8.5 (git clone …, then make clean to re-run bison and flex, then make) on both x86_64 (64-bit) and armhf (32-bit) Linux. I guess I can try building on Intel Mac, but seriously: no flaws in your interpreter here!
    – scruss
    Nov 19 at 16:33
  • Interesting. I'be been playing with the numbers and it only happens with small values, typically 5x5 or less. So with your script above it loops maybe one in 250 runs, but reducing 11 to 3 makes it happen about one in 5. And you're using the version I linked to above, not your rekey? Nov 20 at 15:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .