Some Bugs in Basic

[José Pereira]

just saw this on AtariArchives

BasicBugs.txt

 

 

"A8 ON HIS BEST!..."

 

 

José Pereira.

[flashjazzcat]

Interesting. I recall Turbo Basic XL preserved the behaviour of bug number 8.

[emkay]

The only bug that I approached with Basic was the calculation bug like "2+2=3.9999"

[José Pereira]

Emkay, as you can see this is from oldest 400/800 models that need BASIC cartridge.

On the end the author says to try in a XL (Basic inside) and now in a real machine.

Mine is broken. Who can try this?

 

José Pereira.

[+Stephen]

This was definitely referring to the original Rev.A BASIC. I remember the "? A = NOT B" lockup bug on my original 400.

 

Stephen Anderson

[thorfdbg]

Interesting. I recall Turbo Basic XL preserved the behaviour of bug number 8.

Indeed. This is because the TurboBasic source was "borrowed" from the original Atari basic ROM rev. A (yuck!). If a fix is required, I'd have one...

 

So long,

Thomas

[+bf2k+]

This was definitely referring to the original Rev.A BASIC. I remember the "? A = NOT B" lockup bug on my original 400.

 

Stephen Anderson

 

Yep I agree... its Rev A. There is no mention of the "S."d:prog.bas" extending the size of the program everytime you save it (a rev B bug).

[Synthpopalooza]

As I recall those bugs are Revision A, there is also a Revision B lockup bug as well, which oddly enough occurs when you are deleting lines, I think?

 

And all of these bugs (I think) were fixed for Revision C.

[+Larry]

just saw this on AtariArchives

BasicBugs.txt

 

What is the source of this? It says appendix six, so I presume it is a book or something, and looks to have been written quite early in the A8's life.

 

To quibble a little with the author, some of these and other "complaints" about Atari Basic aren't really "bugs" -- some are limitations which are not quite the same thing. Others are multiple manifestations of the same root cause. Of course to the user, that is probably "cold comfort."

 

Bill Wilkinson (one of the authors of Atari Basic, Basic XL, and Basic XE) covered these over the years in his Insight: Atari column in Compute! magazine. Some of these columns are scanned/archived at http://www.atarimagazines.com/

Unfortunately, not too many of his Insight: columns have been scanned. Great stuff until they cut Bill down to one page per month during the last year(s) covering the A8 at Compute!

 

Also, look on the web for the Atari Basic Source Book, published by Compute! Books. Look at Appendix B (The Bugs in Atari Basic). (Odd that it is not at the atariarchives.org site, but it's not.)

 

If interested, Rev. C Basic eradicted all of the real nasties. There are still some obscure things left, but little that would cause any serious issues. Arguably the "lock-up" (editing) bug was the worst afflicting unsuspecting users in Rev A.

 

-Larry

[Rybags]

Most of these fixed in Rev B, of course the Move bug relating to strings and program addition/deletion of lines was probably made worse in "B" thanks to someone deciding to "fix" a perfectly good piece of code elsewhere.

 

Some of these bugs are OS/Floating Point related and no fault of Basic's. I believe some of these still exist.

 

I knew nothing about 4 or 8.

 

"Basic doesn't like variables starting with NOT" - Basic doesn't much like any variable names starting with a reserved word. But that's true with many other computer's Basic interpretors also.

 

The "bugs" relating to long program lines aren't really bugs.

[drac030]

Most of the file is outdated. The bug no. 8 does not occur in the rev. C (but it does in TBXL).

 

Here is a list of bugs I have found in the rev. C. They're minor and mostly limited to syntax control:

 

1) DIM allows no arguments, even if this is illegal. Type 10 DIM: DIM: DIM: DIM it will get accepted.

 

2) NOTE and STATUS allow a numeric dimension element to be an argument, even if this is illegal. STATUS #1,A(0) gives undefined results.

 

3) the ESC character is accepted in place of the colon as statement separator. TBXL has it too.

 

4) comparison of two CHR$ is always true, try IF CHR$(1)=CHR$(2) THEN STOP

 

5) 10 TRAP 10:GET #1,A overflows the 6502 stack (it is harmless except when on 65C816).

 

Similar stuff for TBXL:

 

1) %GET, %PUT and -MOVE are not accepted unless written in uppercase

 

2) GET accepts string arguments, even if this is illegal

 

3) DEC returns meaningless results if the hex numer passed is written in lowercase

Edited August 11, 2009 by drac030

[Urchlay]

1) DIM allows no arguments, even if this is illegal. Type 10 DIM: DIM: DIM: DIM it will get accepted.

 

Not only is it accepted, trying to RUN the program will trigger behaviour just like the infamous revision B lockup bug (RESET gives a READY prompt, but anything you type causes it to freeze until you RESET again). I suppose for the same reason, program memory gets corrupted and the interpreter gets lost in never-never land trying to find line 32768 (the direct statement fake line number).

 

The only trouble I remember having with revision C wasn't caused by the rev. C ROM... I used to run revision C BASIC in RAM, being too poor to buy a cartridge of it. During a GR.0 or clear-screen, the OS had a bug where it would clear the first 64 bytes past the end of screen memory, aka the start of BASIC itself. ROM BASIC of course isn't hurt by this, but mine was in RAM... the symptom this caused was that NEW wouldn't work any more. First time it happened, it was quite a head-scratcher. The fix for it was to lower RAMTOP by 1K (POKE 106,PEEK(106)-4:GR.0) before switching to RAM-based BASIC... or else use Turbo BASIC XL, which was nicer anyway.

 

3) the ESC character is accepted in place of the colon as statement separator. TBXL has it too.

 

This one is almost cool:

 

10 FOR I=1 TO 4<esc>FOR J=1 TO 4<esc>? I;" x ";J;" = ";I*J<esc>NEXT J<esc>NEXT I

LIST

10 FOR I=1 TO 4

FOR J=1 TO 4

? I;" x ";J;" = ";I*J

NEXT J

NEXT I

 

The code runs fine, and the escapes get printed as carriage returns, making the code a lot more readable... too bad there's no way to edit a line of code like that

[Rybags]

I never knew that Esc one.

 

The bugs could for the most part be worked around, but the Move bug in A & B was just an annoying time-bomb waiting to go off.

[atariksi]

I never knew that Esc one.

 

The bugs could for the most part be worked around, but the Move bug in A & B was just an annoying time-bomb waiting to go off.

 

How about this bug:

 

? ASC("")

 

Is it suppose to print 44?

[drac030]

I never knew that Esc one.

 

The bugs could for the most part be worked around, but the Move bug in A & B was just an annoying time-bomb waiting to go off.

 

How about this bug:

 

? ASC("")

 

Is it suppose to print 44?

 

"44" is the token value for the closing parenthesis, if I remember correctly. What else it is supposed to print, anyway? An empty string has no ASCII value.

[drac030]

1) DIM allows no arguments, even if this is illegal. Type 10 DIM: DIM: DIM: DIM it will get accepted.

 

Not only is it accepted, trying to RUN the program will trigger behaviour just like the infamous revision B lockup bug (RESET gives a READY prompt, but anything you type causes it to freeze until you RESET again).

 

Obviously, as the line's syntax is improper, so the interpreter goes crazy and corrupts memory. This is not an unexpected behaviour. The buggy part is the syntax controlling code (or rather the syntax controlling table) which should never approve a DIM statement without an argument.

[atariksi]

I never knew that Esc one.

 

The bugs could for the most part be worked around, but the Move bug in A & B was just an annoying time-bomb waiting to go off.

 

How about this bug:

 

? ASC("")

 

Is it suppose to print 44?

 

"44" is the token value for the closing parenthesis, if I remember correctly. What else it is supposed to print, anyway? An empty string has no ASCII value.

 

Having programmed on many different BASICs, it should do something different from returning a valid value. 44 is for a "," so ASC(",") and ASC("") is the same. QuickBasic on PC gives an error. Commodore 128 Basic gives NULL (0). Null seems logical. There's must be some ATASCII value that's assigned NULL (it can't be same as a comma).

[Rybags]

-1 would be the logical choice... of course they'd then have to hard-code it which mightn't have fit.

 

Then again, -1 is a "nicer" alternative for many functions when out-of-range parameters are supplied, rather than returning an Error or rediculous value.

[atariksi]

-1 would be the logical choice... of course they'd then have to hard-code it which mightn't have fit.

 

Then again, -1 is a "nicer" alternative for many functions when out-of-range parameters are supplied, rather than returning an Error or rediculous value.

 

They could go with 65535 which is -1 when interpreted as an integer. Then the inverse function CHR$(65535) would also work whereas CHR$(-1) returns an error. Of course, returning an error is still better than giving the wrong value.

[drac030]

There is no "NULL" value, and returning a 0 would be basically the same as returning a 44 - either one is an invalid value. The best idea is to return an error, but it would require calling a subroutine that could recognize if there is a valid parameter. Bypassing that and fetching anything that can be found after the first quotation mark is a sort of speed optimization.

 

Trying to determine an ASCII value of an empty string is a programming error anyways.

[kenfused]

The following prints 0, so it should probably do that for PRINT ASC("") to be consistent.

 

10 DIM A$(10)
20 A$=""
30 PRINT ASC(A$)

[drac030]

I guess it prints 0 accidentally, i.e. the 0 is accidentally a value of A$(1,1) for an empty A$ because the memory is zeroed at OS startup.

[Kr0tki]

Sounds plausible. Running

DIM A$(10):A$="ABCD":A$="":? ASC(A$)

gives an "expected" result of 65

Edited August 15, 2009 by Kr0tki

[Nukey Shay]

The following prints 0, so it should probably do that for PRINT ASC("") to be consistent.

 

It is consistant, because a string has an actual memory location(s) of it's contents. When you DIMension a variable, a stretch of ram is picked for it to reside (as mentioned, ram which has already been zeroed during powerup). Calling a string directly in PRINT ASC("") is doing exactly the same thing. There is no string...what exists there in memory is the closing parenthesis of the line.

 

In both cases, it's reporting what value exists in memory. Not really a bug. Just an oversight. Hey, it's better than locking up the machine!

[kenfused]

The following prints 0, so it should probably do that for PRINT ASC("") to be consistent.

 

It is consistant, because a string has an actual memory location(s) of it's contents. When you DIMension a variable, a stretch of ram is picked for it to reside (as mentioned, ram which has already been zeroed during powerup). Calling a string directly in PRINT ASC("") is doing exactly the same thing. There is no string...what exists there in memory is the closing parenthesis of the line.

 

In both cases, it's reporting what value exists in memory. Not really a bug. Just an oversight. Hey, it's better than locking up the machine!

"Oversight", going have to remember that for work . I actually have a copy and have read through the Atari Basic Sourcebook and even the source code in the book (but it's been a while). I find it pretty amazing what they did fit into 8K. I remember finding the syntax table stuff very interesting, almost a language in itself.