In order answer my challenge from 32 years ago, I need to get the original Colourflow code into an Atari. My original cassette tapes are long-gone, so all that’s left is the code listing as printed in Page 6 magazine. It’s only 34 lines of BASIC, but there’s a bit of a problem. The code displays the Atari fuji logo created with character graphics, but it’s difficult to figure out the individual characters from the listing.
Never mind. I’ll use the same technique that 15-year-old me used all those years ago – I’ll steal it. I ‘borrowed’ the fuji logo from the cassette loader portion of Atari’s SCRAM program (a fun little nuclear power plant disaster simulator).
I’m trying to address this challenge with minimal use of emulators, but I don’t have a working 410 cassette player (belt rot), so I used Atari800MacX to grab the loader from the cassette and transfer it to a floppy. Some quick edits, and typing in the rest of the code, and I’ve re-created my original BASIC program. Here’s an ATR image of a disk with the BASIC code as well as the SCRAM loader, if you’d like to play along at home.
Running the code an an NTSC machine doesn’t give me the proper display because of the difference in PAL and NTSC timing. However, if I boot up Atari800MacX with the PAL ROMs and set it to PAL timing, I actually get the original Colourflow display! So, by the end of the month, I need to re-create this in a region-independent version, along with keyboard interrupt, and who-knows-what-else functionality.
But what’s this BASIC bug I mentioned? Well, if you look at the screenshot of the SCRAM loader that’s posted on AtariMania, you’ll notice that there’s a blank line running through the middle of the fuji logo. What’s that all about? If I run SCRAM on my 800 I don’t see this. But on a 130XE the gap is there. Looking at the SCRAM loader source code, it looks obvious – check out line 50. What’s that extra PRINT at the end?
It turns out that if you remove this PRINT statement, the code works correctly on a 130XE, but breaks on an 800 – the output of line 50 and 55 get concatenated just like if there was a semicolon at the end of line 50.
After playing around a bit, I was able to determine that the problem was related to the revision A BASIC cartridge. If I placed a revision A BASIC cartridge in my 130XE, the problem followed. The 130XE contains revision C BASIC. I don’t have revision B convenient (without using an emulator) so I can’t determine if the problem occurs in revision B.
The problem is caused by the character at the end of line 50. This is character 0x15 or CHR$(21). It turns out that any PRINT statement that ends in this character will act as if there is a semicolon at the end of the line (i.e. surprise the carriage return). Atari was obviously aware of the problem, because they coded the SCRAM loader with the extra PRINT statement to force the carriage return.
Before I dig in to the cause of this, was Atari’s workaround the best way to do this? Obviously not, because they broke forward compatibility in later versions of BASIC. In hindsight, perhaps putting an extra space at the end of the PRINT statement would fix the problem without breaking once the bug was patched. Maybe Atari didn’t expect the bug to be patched?
Is this a known BASIC bug? I looked for an official bug list, but couldn’t find one. There are a few famous Atari BASIC bugs, some of which were listed in the July 1986 issue of Compute! magazine.
Looking at the source code for Atari BASIC, I’ve found the cause of the bug, and in a later posting, I’ll outline what I’ve discovered. If you can’t wait, the big clue is in the ASCII value for the suspect character, and the BASIC token table.
Day 1 for RetroChallenge 2015/07 is over, and I’m having fun. Spending half an hour typing in source code from a magazine really took me back to the old days of software distribution (and also reinforced my memory of just how bad the 130XE keyboard was).