INSIGHT: Atari

Bill Wilkinson

More About HELP! On HELP?

Several of you were kind enough to write and point out (with only a few snickers) that I goofed in my February column's description of the HELP key. Specifically, I gave you the wrong value for SHIFT + HELP. Here is the corrected table. Remember, though, that you must POKE location 732 back to zero if you PEEK there and find that the HELP key has been pressed.

Key(s) Pressed	Value in 732 ($2DC)
HELP alone	17 ($11)
CONTROL + HELP	145 ($91)
SHIFT + HELP	81 ($51)

B Is For Bad BASIC

I was inundated with letters from people who responded to my request for help in that same February issue. I had asked if anyone knew how and why the Atari BASIC built into the XL machines caused the infamous keyboard lockup. As I stated then, I was under the impression that the oh-so-little (but oh-so-damaging) coding mistake which caused the problem with Atari cartridge BASIC had been fixed.

Well, it turns out that I was both right and wrong. I was right about that particular bug being fixed. I was right in believing that Atari had a version of BASIC which corrected the problem. What I had not been aware of was the number of 600XLs and 800XLs that Atari has sold which contain an intermediate version of BASIC with even more severe problems.

If we call the original Atari BASIC revision A, then the most current version being shipped and installed by Atari (in XE machines as well) is revision C. So what about revision B? In fact, Atari gave me an early release of rev B in cartridge form. ("Rev" is the usual contraction of "revision" if you're into techie language.) However, when I learned that it had significant problems and that Atari was dropping it in favor of rev C, I promptly ignored and forgot about rev B.

Unfortunately, Atari didn't do likewise. Atari (the old Atari, that is) ordered a few thousand (tens of thousands? hundreds of thousands?) ROMs using rev B, which they certainly weren't going to throw away, so kerplunk into all the 800XL and 600XL computers they went.

As I said, I had kind of ignored rev B because I was under the mistaken impression that very few machines using it had been shipped. Boy, did my mail tell me I was wrong! So now, how can I help all of you out there who are stuck with rev B BASIC? Three ways: First, show you how to tell what revision of BASIC you really have. Second, tell you how to avoid the problem most of the time. Third, tell you how to fix the problem permanently.

What Have I Got?

I am indebted to Matt Ratcliff for showing me a location within Atari BASIC which tells you what version of BASIC you have.

If you PRINT PEEK (43234) and see this value:	The you have this revision of Atari BASIC:
162	A
96	B
234	C

Despite what you may have heard or read from other sources, there is no practical way to avoid some of the problems associated with rev B. Many Atari "experts" won't believe me, but that's not surprising. Even though we wrote—and, in 1983, COMPUTE! published—The Atari BASIC Source Book, with the complete source code of Atari BASIC rev A and a detailed explanation of the keyboard lockup bug, I saw a user group newsletter just three weeks ago in which someone claimed that hitting SYSTEM RESET cleared up the problem. Honest, there is no reasonable way to avoid the bug in rev A, either.

However, there is a way to minimize the effects of the worst bug in rev B: Don't use the SAVE or CSAVE commands. Instead, use LIST and ENTER. (Disk users simply substitute the words LIST and ENTER for SAVE and LOAD, respectively. Cassette users use LIST"C" and ENTER "C" in place of CSAVE and CLOAD.) Even this technique will not help you avoid the bug. It will just make it easier for you to recover when you get bitten.

In a nutshell, the problem in rev B is that your program and/or your data can get hopelessly scrambled. Unlike rev A, though, you may not notice the scrambling until some time after it first occurs, since the scrambling often does not cause a lockup. How can you tell if your data is scrambled? You can't, easily. How can you tell if your program is scrambled? Just LIST it on the screen or a printer. If it looks okay, it probably is okay.

So start by deciding how much time you are willing to throw away, if worst comes to worst. (For me, that's about 15 minutes. If I were using cassettes, I might make that 30 minutes.) Then, every time you have typed that much time's worth of new material into your program, LIST the program on the screen or printer to be sure it's okay. If it is not okay, even if some lines just look funny or scrambled, turn off your power and reboot. Do not attempt to fix your program. The odds are you will only make the situation worse. Only after rebooting should you re-ENTER the last listing from your disk or cassette.

If the screen or printer listing appears okay, you can go ahead and LIST the program to disk or cassette. This way you can have reasonable confidence in that version if you need to re-ENTER it later.

Alternate Solutions

Sidelight for all Atari cassette users: The technique I just described is a good idea no matter what version of BASIC you are using. Remember that you can easily verify a LISTed tape by re-ENTERing it back over itself. Do not type NEW before using ENTER "C". If a tape has an error, the most you will wipe out using this trick is one line. If it has no errors, the ENTER will terminate normally. (Disk users may also use this verification trick, but it seems unnecessary if you always use write-with-verify mode on the disk. Atari DOS defaults to this mode.)

You probably noticed that I said there was no easy way to tell if your data (strings, arrays, etc.) had been scrambled. As far as I can tell, though, any scrambling in these areas is fixed every time you use the RUN command. (If you want to feel super-safe, type NEW and re-ENTER your last LISTed version.) And there appear to be only two ways the bug can occur while a program is running: (1) If you ENTER an overlay in the middle of your program. (2) If you DIMension a string or array when you are several levels deep in a GOSUB and/or FOR nest (several means 64 GOSUBs or 22 FORs or some combination of the two which uses about 256 bytes of stack space).

Maybe the best solution of all is to forget about rev B BASIC entirely and get a different BASIC for your computer. You could buy one of the enhanced BASICs available on disk or cartridge from several independent companies. Or you could buy one of the new XE-series computers, which have rev C BASIC built-in. Or you can order a rev C BASIC cartridge from Atari itself. Perhaps to atone for the bugs in rev B, Atari is offering the rev C cartridges at a nominal cost. Send $15 (no extra shipping and handling charges) to:

Atari Corp.
Customer Relations
390 Caribbean Drive
Sunnyvale, CA 94088

The cartridge works with all eight-bit Atari computers. (Remember that when you plug in a cartridge on an XL or XE, the built-in BASIC is disabled and control passes to the cartridge.)

Bits And Pieces

When I told you above that you need to LIST your program periodically, did you automatically start allocating two or three cassettes or a blank disk for each program? If you didn't, you might as well ignore my advice. Never use the same cassette or same filename on a disk to keep successive LISTings of SAVEd programs. If you have a good version of a program SAVEd as "D:MYPROG.SAV" and then, in the process of adding more lines to that program, you encounter one of the nasty editing bugs, what happens when you SAVE it again with that same filename? You just wiped out your last good copy.

At the very least, keep the last two versions of every program, every word processing document, every data file, etc. (I always keep three copies and usually keep at least as many as a blank disk will hold.) Unless, of course, you value your own time at less than 25 cents an hour.

More than a few of you have written with questions about my enhanced DOS 2.0S (from COMPUTE!, August and September 1984) for the 1050's dual density. First, I want to thank you for the nice words and shrug off the complaints. Then, I have the pleasure of telling you that Atari will soon be releasing DOS 2.5, which uses 1024 sectors (out of a possible 1040) on a 1050 drive in dual density mode. It is very, very compatible with DOS 2.0S. Do I have to tell you that it's completely incompatible with my earlier version? I don't? Good, then I won't mention who helped write it for Atari.

The ink wasn't dry on the March issue of COMPUTE! when I started getting letters (and even two phone calls) asking me to please explain how to read/write a sector directly from/to the disk. I said I would oblige if enough of you asked, so sector I/O, and a recap of Atari I/O in general, is a future topic. But first, next month's column will explain the bugs in rev C BASIC in more detail and even divulge how they happened.