Atari Basic Bug List

[thorfdbg]

Again a couple of observations. Atari Basic is very orthogonal in the sense that you can execute every instruction both in interactive mode as well as in a program. Every instruction? Almost every instruction! ENTER does not work this way. Actually, Basic jumps in circles to get LIST working in interactive and program mode, it rather pushes the current address of LIST onto the runtime stack (exactly as RETURN) and then continues at the position where it was executed as soon as the list is complete. Which causes another interesting defect: If LIST "<filespec>" fails by anything *but* a break-error, then the next RETURN will bring you back to LIST.

 

So try this as a program:

 

10 LIST "X:"

20 PRINT "HELLO!"

 

(provided there is no X: device in your system).

 

Execute by RUN. You'll get an error 130 then. If you now type "RETURN" you'll get a "HELLO" on the screen instead of an ERROR-16.

 

With ENTER, we have that ENTER unavoidably aborts program execution, even though - quite logically - enter should run into the next program line when done. There is no "execution position" pushed onto the run time stack. That's because ENTER is quite primitive, it doesn't do much rather than to redirect the STDIN of the basic parser to the given filespec.

[vitoco]

That last example reminded me another bug about CONT:

10 INPUT A
20 ? "HELLO!"

Run and press Break to stop at the "?" or Enter to force an ERROR-8. Then type CONT many times... you'll always get a greeting. I don't think this was on purpose.

[thorfdbg]

That last example reminded me another bug about CONT:

10 INPUT A
20 ? "HELLO!"

Run and press Break to stop at the "?" or Enter to force an ERROR-8. Then type CONT many times... you'll always get a greeting. I don't think this was on purpose.

What happens here is that Atari Basic stores the line where either a STOP was executed or where the program comes to halt by an error. This is the line CONT jumps to. It does not alter this line if the program comes to a regular halt by running off the last line. Hence, CONT continues to jump to the last line the program was stopped at, no matter what. So what should happen? Make CONT a no-op when the program is terminated regularly,I suppose?

 

Interestingly, if the last line contains END, then the stopped line is cleared, and CONT no longer continues. So Atari Basic distinguishes two cases: An "irregular program termination" due to falling off the last line of the program, from which you can still continue the program from the last position it was stopped at, or a "regular program termination" by the END statement, which not only closes all channels and shuts the sound off, but *also* tells CONT that there is nothing to continue.

 

So in some way, this does make a bit of sense.

Edited September 23, 2015 by thorfdbg

[thorfdbg]

So in some way, this does make a bit of sense.

Actually, not really. END also records its own stopping line, so CONT continues with the line below END. Hmmm. Does that make sense?

[thorfdbg]

More on CONT. Actually, not a bug, more a documented feature. The problem with CONT is that it does not continue compound commands, i.e. commands separated by colons.

 

So for example, this program

 

10 FOR I=1 to 10:PRINT I:STOP:NEXT I

20 PRINT "DONE"

 

aborts the FOR-loop if you enter CONT. It does not continue with "NEXT I", but line 20.

 

Unfortunately, that's unavoidable as STOP only remembers the line number and not the line offset where program execution stopped, thus it remembers that it stopped in line 10, but not *where* in line 10.

 

Unfortunately, unavoidable as the user could edit line 10 and remove or replace parts of it, in which case the command offset would be meaningless anyhow. It is quite hard to come up with a good solution here, so I'll currently leave this as it is. Probably : "Avoid compound commands if you want to play with STOP and CONT".

[devwebcl]

n00b question (not sure if it's a bug):

 

when entering a period and hit return then appears "ready" again.

What does a period on Basic ?

 

 

[+MrFish]

It's short-hand for "REM"

[devwebcl]

It's short-hand for "REM"

 

right, I remember now

thanks !

[thorfdbg]

Here's another one: Atari Basic does not check the dimensionality of arrays. Actually not at all.

 

So you can do a

 

DIM A(10)
A(9)=5
PRINT A(9,0)

even though A is one-dimensional.

 

It also works the other way around:

 

DIM B(10,10)
B(10)=1
PRINT B(10,0)

 

Thus, the missing dimension is treated as zero.

[thorfdbg]

Probably to complete the list, here are a couple of "Atari Basic wierdos". These are not bugs, just features that seem strange if you think about it.

 

Both FOR-NEXT and GOSUB-RETURN use both the runtime stack of the basic interpreter, however, their interaction is sometimes unexpected and Atari Basic is quite permissive concerning "bad programming practise". For example, the following program "works", though it probably should not:

 

 

10 FOR I = 1 TO 4
20 GOSUB 100
30 NEXT I
40 END
100 FOR J=1 TO 4
110 PRINT I,J
120 IF J=2 THEN RETURN
130 NEXT J
140 RETURN

 

The problem is here that in line 120 the for-loop over J still has an active stack frame, though the "RETURN" removes it and hence terminates the FOR-NEXT loop in the subroutine. This works, but is bad programming practise. The correct way would be:

 

 

120 IF J=2 THEN POP:RETURN

where the POP would remove the FOR-NEXT LOOP.

 

This also works for nested loops:

 

 

10 FOR I=1 TO 4
20 FOR J=1 TO 4
30 PRINT I,J
40 IF J=2 AND I<4 THEN NEXT I
50 NEXT J
60 NEXT I

 

The "strange and wonderful" part is here line 40 where the NEXT I terminates the outer loop without conflicting with the inner loop. Atari Basic automatically terminates the inner loop if it finds a NEXT from an outer loop. The correct way would be:

 

40 IF J=2 AND I<4 THEN POP:NEXT I

 

This is in case you wonder where the complexity of FOR-NEXT and GOSUB lies. Atari Basic (and also Basic++) is quite tolerant here...

[SoundGammon]

I remember the tip years ago about doing a LPRINT in immediate mode with no printer on to clear a buffer before you saved your work to disk or cassette.

[dmsc]

Hi!,

 

This also works for nested loops:

 

10 FOR I=1 TO 4
20 FOR J=1 TO 4
30 PRINT I,J
40 IF J=2 AND I<4 THEN NEXT I
50 NEXT J
60 NEXT I

The "strange and wonderful" part is here line 40 where the NEXT I terminates the outer loop without conflicting with the inner loop. Atari Basic automatically terminates the inner loop if it finds a NEXT from an outer loop.

 

This is supported in AtariBasic and also in TurboBasic XL, it is used in a few programs, any "NEXT" automatically closes all the inner FORs. If this was not the case, we would need a new error code for "NEXT not nested to corresponding FOR".

 

In the case of TurboBasic XL, the interpreter checks that any DO/LOOP, REPEAT/UNTIL and WHILE/WEND are correctly nested, gives an error if NEXT is not nested with a FOR but removes FOR loops of other variables from the stack.

[peteym5]

I seldom use Atari Basic, but have a 130XE. I prefer TurboBasic XL or Basic XE. Not sure how big the error list, but I prefer those because of the extra commands and more speed. However I remember having an issue with TurboBasic XL when making an DIM array and assigning a value to each one, then printing the values. Works fine in interpreted mode, but when compiled, all the values came back as 0.

[dmsc]

Hi!,

 

Probably to complete the list, here are a couple of "Atari Basic wierdos".

I discovered more bugs and one "weirdo" as you called it

 

In TurboBASIC XL, there is an interpreter bug repeated in many places, that increments the current token position before comparing for the end of statement. This does not work if the line length is exactly 255 bytes, as the pointer will be incremented to zero and the check fails.

 

This is an example for the "CIRCLE" statement, after reading 3 numbers the interpreter checks if there is a fourth parameter, and fails:

1 COLOR 1:? 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1,1+1+1+1+1+1+1+1+1,"123":CIRCLE 5,5,5

This bug is also in the "IF " statement without a "THEN", in a "FOR" statement while reading the "STEP", but the check is OK in other statements copied from Atari Basic: "LIST", "DIM", "COM", see the analysis at http://atariage.com/forums/topic/243394-basic-parsing-and-transformation-tool-new-version/?p=3432902

 

The weird thing is that "LIST" evaluates it's first argument twice, to check if it is a string or a number, so if you call a USR routine you can get twice the result!. This is because it evaluates the argument once to check if it is a string or a number, and then evaluates again to get the value.

[+JAC!]

so if you call a USR routine you can get twice the result!.

As you mention it in the context of Turbo Basic, that's the one thing that really sad is the bug that USR does not return the result correctly - a real incompatibility compared to Atari Basic. But that belong in the Turbo Basic Bug List of course.

[livorno]

Here is a weird bug I encountered while learning about Display Lists in the Altirra emulator (internal BASIC from largely default Altirra setup): Attached is my modification of Jason Moore's DLI tutorial from http://atariprojects.org/2018/11/23/learn-about-display-list-interrupts-in-basic-1-2-hours/

I modified to copy the color scheme of the Music Hall demo from the fandal site. But occasionally, I would get garbage in the form of "heart comma six hearts" appearing in the BASIC listing, usually in a REM statement, usually in line 2000, but not entirely predictable. This drove me nuts, so I started from my buggy listing and changed it bit by bit until it was almost identical to Jason's listing. The bug was nice and seemed to stay reproducible. The culprit seemed to be line 2010. You can probably reproduce this bug yourself in the attached (well-behaved) BASIC listing:

The well-behaved line is this:

2010 DL=PEEK(560)+PEEK(561)*256

 

My code that produced garbage in line 2000 of the BASIC listing after running the program:

2010 DL=PEEK(560)+256*PEEK(561)

 

Is there somehow a multiplication commutativity bug here? Is it Altirra BASIC?

How might the DL address be modifying the BASIC listing?

Could this be a consequence of my modifying the Display List while it is in use? (lines 2020 & 2030)

MYDLI4.BAS

[TGB1718]

3 hours ago, livorno said:

Could this be a consequence of my modifying the Display List while it is in use? (lines 2020 & 2030)

Could be, as a rule I only ever change the Display List during Vertical Blank processing, obviously with BASIC

it just happens when it happens and could cause data to be read from some random location.

[Rybags]

Weird one.  But it's overwriting the program regardless of how that DL= assignment is ordered.

 

I set a breakpoint in Altirra for write to $978 - it's being done by something in the Basic Rom itself.

Routine around $AC0C - RTNVAR (note the address is different to Atari Source Book listing since it's not Rev C)

 

I've not got time to look into it at the moment but the program itself doesn't seem to be doing anything wrong.

But absolutely that REM is being overwritten each time.  Change it back to just a string of AAAAA and RUN again and it gets zeroed again.

 

ed - I think I've found the problem.

Edited June 3, 2020 by Rybags

[Rybags]

OK - found the problem, it's in your USR routine.

 

4020 X=USR(1571)

 

That's $623

0623: A5 14             LDA RTCLOK+2
    0625: C5 14             CMP RTCLOK+2
    0627: F0 FC             BEQ $0625
    0629: A9 C0             LDA #$C0
    062B: 8D 0E D4          STA NMIEN
    062E: 68                PLA

    062F: 68                PLA

    0630: 68                PLA

   0631:  60                RTS

 

Too many PLAs which causes indeterminite behaviour, you land somewhere in the Basic Rom where you shouldn't be.

 

So the fix is to put the RTS at $62F (change your data in line 1060)

[livorno]

Darn it. I'd thought I'd found an obscure bug in BASIC, but it's my own darn fault. Well, I'm going to pass the buck and point out that Jason Moore's tutorial shows the ML data ends 104,104,104,96 like mine. If you follow the link at the bottom of his tutorial, the trio of 104's seems to come from someone who helped him mod his code so that it was timed to the VSYNC using the NMIEN address.

 

Thanks, Rybags. That's pretty impressive.

Edited June 3, 2020 by livorno
error attribution iterates deeper

[StickJock]

The 3 PLAs are used when passing a parameter from basic, as in X=USR(1571, 12345).

 

The first PLA will contain the number of 16-bit arguments.  Each subsequent pair of PLAs will return one of the 16-bit arguments.

 

Usually this will be at the top of the routine, though, not the bottom, as you would want to use the data passed in.

Edited June 3, 2020 by StickJock

[scitari]

On 6/3/2020 at 11:14 AM, livorno said:

Darn it. I'd thought I'd found an obscure bug in BASIC, but it's my own darn fault. Well, I'm going to pass the buck and point out that Jason Moore's tutorial shows the ML data ends 104,104,104,96 like mine. If you follow the link at the bottom of his tutorial, the trio of 104's seems to come from someone who helped him mod his code so that it was timed to the VSYNC using the NMIEN address.

 

Thanks, Rybags. That's pretty impressive.

 

Thanks for catching this! Yes, too many PLAs. I should have caught that. Regardless, I have updated the code on Atari Projects so others don't run into the problem.

[Gunstar]

Do Basic A+/XL/XE from OSS have the same bugs as Atari Basic revisions since they are based on Atari Basic? Is there a list for OSS BASIC bugs? I use BASIC XE so that's the main one I'm concerned about.

[_The Doctor__]

The whole purpose of basic a+ was to correct the errors and mistakes...

[QTZ]

On 10/10/2015 at 5:09 PM, devwebcl said:

not sure if it's a bug

when entering a period and hit return then appears "ready"

0REMSTOP [ENTER]

L.0 [ENTER]

0 REM STOP

 

unexpected:

0.STOP [ENTER]

L.0 [ENTER]

0 STOP
 

0 .STOP[ENTER]

L.0 [ENTER]

0 REM STOP

 

0 . [ENTER]

L.0 [ENTER]

0 REM

 

unexpected:

0. [ENTER]

L.0 [ENTER]

[LINE IS DELETED]

 

0 STOP:.STOP [ENTER]

L.0 [ENTER]

0 STOP :REM STOP