Reader Comment

BBS correction.

In issue 23's Reader Comment (page 7), we gave an incorrect phone number for H.A.C.E. (or Houston Atari Computer Enthusiasts). Paul Mitchum, the reader who originally brought the Texas BBS (and others) to our attention, caught this error and asked that we print the following, correct number for H.A.C.E.:

713-644-6400

Sorry, Paul. -Ed.

Atari BASIC Revision C.

I have not seen information on Revision C of Atari BASIC in your magazine. I tried the BASIC bug described in issue 23, page 56 with the Revision C Atari BASIC, and the bug does not exist any more.

Revision A is the cartridge that came with the Atari 800 or was purchased for the Atari 400. Revision B is the built-in BASIC for the Atari 600XL or 800XL. Revision C is a new cartridge that can be obtained from Atari Customer Relations at a cost of W.

You can determine the version of Atari BASIC you have by examining location 43234 with the PEEK command.

Revision	Value
A	162
B	96
C	34

To order your own copy of the Revision C Atari BASIC, request part number CA024948-001 and send $15 to this address:
Atari Customer Relations
1312 Crossman Ave.
P.O. Box 61657
Sunnyvale, CA 94088

Sincerely,
Allan Frink
Lino Lakes, MN

Yet another BBS.

Please tell your readers of a new BBS called T.R.A.I.N. BBS, Ennis, Texas at 214-875-9818.

T.R.A.I.N. has no password or time limit. It offers a message center for all and download (XMODEM) for Atari computers.

Call 214-875-9818 5:00 pin till midnight, or anytime on Saturdays. There is a password contest for all computers.

My thanks to you for having a great Atari magazine.

Brady Mooney
SYSOP
Ennis, TX

I've been using the ANALOG Card File to organize my magazine collections. While using it, I have encountered one problem.

I have a RANA 1000 disk drive, and it has a protect switch that I've accidentally turned on when inserting the disk a couple of times. It got me frustrated when I hit the START button to save the screen, and - because of the protect feature - the program encountered an error and went to the menu screen, destroying the card.

I changed and added some lines to fix this problem. The program will beep if the disk is protected, if there isn't enough memory, or if any other error occurs during disk I/O.

The changes I made are as follows:

With these changes, I don't have any disk-error problems that destroy my cards.

Sincerely,
Mark Grande
Willow Grove, PA

Selling my smaller 5K computer and getting my Atari 600XL was as exciting as typing in my very first program and seeing it RUN.

I then, of course, got the "bug" and started buying every back issue of ANALOG Computing that I could.

The game programs and utilities kept me busy at the keyboard, but sooner or later I wanted to try the features in magazines that started "for Atari computers with a minimum of 24 or 32K" At this point, there were no RAM expansions yet available for the 600XL.

While paging through an issue with hopes of finding a 16K listing for a game, I spotted a very small ad. "600XL expansion module, 32K (48K total), $99.95 "

The ad (R. C. Systems) prompted a phone call to Bothell, Washington. The price was so reasonable that I was curious. After gaining assurance that this unit had been tested and retested, and that the price was, indeed, $99.95, 1 ordered the expander.

When it arrived, I found the surprise of a lifetime - a 32K module weighing less than 3 ounces and measuring 41/2 " x 13/4 " x 3/4 ". And its color matched my 600XL to a "T."

I followed the simple instructions and CLOADed a 32K game tape. It ran, and the expander did everything it was supposed to do-and more.

I am happy that I didn't wait for larger (and, I'm told, bulkier) expanders that would have cost more.

Congratulations, R.C. Systems and ANALOG Computing from a very satisfied computer hobbiest.

Milson Luce
Kenner, LA

I'm an Atari 800 user and a data processing professional who is hooked on the C programming language. If you want an excellent programming language, read on ... and if you already use C on an Atari, please drop me a line, so we can swap functions and tricks.

Here are three very good reasons to program in C:

1. In the business world, a lot of people are making big bucks writing in C. AT&T and IBM are betting that C will be the language of the future for business micros, and a lot of IBM followers are already on the bandwagon. The problem is that there aren't very many C programmers out there. So lately, in the computer industry's trade journals, there have been a lot of ads for programmers knowledgeable in C and UNIX offering salaries at $30-$50,000! And this is with little other DP experience. A BASIC, assembler or COBOL programmer is lucky to get a job for half that much.

2. It's a high-level language that produces compiled code which runs rings around BASIC programs, yet is infinitely easier to use than assembler.

3. It has many of the familiar

BASIC verbs, like PEEK and POKE, as functions that are used in a similar fashion. Yet-since these functions are written in C, and you are provided the source code-you can make them act differently by modifying the C code.

So, if you want to program in the language of the future-that uses many of your favorite BASIC verbs, that allows modular development, that produces fast programs, and that costs very little-buy a copy of Deep Blue C. Then write to me, Don Vuckovich at: Friends of the C, 584 Crescent Ave., East Aurora, NY 14052.

Don Vuckovich
East Aurora, NY

Balldrop modified.

Here is a modification of Balldrop (ANALOG Computing, issue 22) that labels the marble bins, and allows the user to choose the number of balls to be dispensed . In addition, a reRUN prompt is presented at the end of the run. The modification lines are compatible with both the BASIC and the version that uses a machine language subroutine.

Ronald Starkey
Green Bay, WI

Another BASIC Bug Bug.

I just read Another BASIC Bug by R.T. Dolbeare in your October issue (23) and feel I can clear up some misconceptions raised, offering a more satisfactory remedy.

The author says he has found a "previously-undocumented error in Atari BASIC," which isn't the case. The bug he describes is not caused by the VAL statement, but is simply a manifestation of a problem with the GET statement-which is described by Bill Wilkinson in the Atari BASIC Source Book, page 277.

The error is caused by the failure of GET to reinitialize INBUFF, the BASIC buffer pointer located at $F3. VAL changes INBUFF so that it points to the string whose value is to be taken. To GET a byte, BASIC calls an 1/0 routine which uses the contents of INBUFF as CIO buffer address. The failure to reset INBUFF to point to the general purpose BASIC buffer at $580 then causes the byte gotten to be placed in the string that VAL pointed to, instead of in the safe buffer area.

To remedy this, Wilkinson suggests executing a statement known to reset INBUFF, like DUMMY$ =STR(0) or PRINTing a number, before executing GET. A better solution, which won't require a dummy string or upsetting the screen display, is to initialize INBUFF via the following statement:

This, in effect, JSRs to the INTLBF routine at $DA51 in the floating point package ROM, precisely the step which GET omits.

Incidentally, the INPUT statement doesn't cause this bug, since it does properly initialize INBUFF. However, a problem will occur if you are using page 6 for a machine language subroutine and then INPUT (from disk or cassette) a string longer than 128 bytes.

Since the string is stored starting at $580, the excess will spill over into page 6, wiping out the code you had stored there. The second half of page 6 ($680-$6FF) is still safe, because INPUTs are limited to 255 bytes plus an EOL.