Maybe a new-old bug in INTEGER BASIC... ?

3 posts / 0 new
Last post
Offline
Last seen: 10 hours 11 min ago
Joined: May 4 2021 - 06:35
Posts: 179
Maybe a new-old bug in INTEGER BASIC... ?
Dear Friends,
these days I am in the middle of another porting for Apple-1, when I came across an annoying "*** >8 FORS ERR" error.
 
I couldn't find any trace of it online, so there you go:
 
The error is caused by the presence of more than 8 nested FOR..NEXT loops, however in the listing these are not so evident, on the contrary. Moreover, it occurs randomly, when the game has been running for a while.
 
Problems of this kind can easily happen when trying to port to a less performing BASIC and, if they prove unsolvable, can result in the failure of the porting itself.
This happened, for example, with ANGELA GAME -even though it was GOSUB-related- so I decided to use Applesoft BASIC, which performed much better than the dated INTEGER.
But back to our point.
 
I'll get straight to the point: INTEGER BASIC does not "close" the FOR..NEXT loop when it is interrupted for whatever reason and then the same loop is run again.
 
This trivial program:
 
10 C=1
20 FOR I=1 TO 100
30 IF I=10 THEN 50
40 NEXT I
50 PRINT "CYCLE #";C
60 C=C+1
70 GOTO 20
 
causes the error "*** >8 FORS ERR" (see screenshot) because each FOR increases the internal "nested cycle counter" by 1.
A very similar routine just happens to be used in the program I am porting.
 
Now, fixing the nested cycles counter is a matter of a POKE, in this specific case it does no harm, solves the problem and saves the project (see photo).
 
I have discussed this with  Francesco Sblendorio  and we both agree that the nested cycles counter should not increment in this case. It should take into account both the actual start of the loop and the name of the variable used.
 
So if you are going to try out programming in INTEGER BASIC, this is definitely something to consider.
 
I know it could be a little OFF TOPIC for this group, but... the next question was: are there other BASICs that operate this way?
 
I tried what I had available to me: CBM BASIC V2, Casio PB-100, Sharp PC-1500, GWBASIC, QBasic, Applesoft BASIC (Apple-1 version) do NOT fail and continue to run the program indefinitely.
 
On the other hand, the BASIC of the Sharp PC-1211 Pocket Computer (the first of its kind, year 1980) fails after 4 cycles. The manuals states that the it's possible to nest up to four cycles, so that's another one (Error 3. below).
 
I would like to find out if there are other BASICs that behave like this, I would exclude the "modern" ones. I have doubts about the ALTAIR BASIC 4K...I can't try it at the moment but if someone would do so I would be very grateful!
 
What can I say, you can always learn something!
 
 
Until next time!  :-)
 
Claudio - P-LAB
 
 
 
^^
Sorry, I couldn't rotate the image
Offline
Last seen: 1 day 16 hours ago
Joined: Jul 31 2021 - 08:38
Posts: 25
Interesting behavior. Of

Interesting behavior. Of course I had to try it.

My Apple-1 clone with Interger Basic crashed after 8 cycles, as expected.

On the KIM-1 replica with KB-9 Basic V1.1 it runs without problems, probably forever.

The Sharp 1401 does exactly 5 cycles before an error message appears...

Offline
Last seen: 10 hours 11 min ago
Joined: May 4 2021 - 06:35
Posts: 179
Also 1403H!

Thanks for your contribution! :-)

 

Sharp 1401 is quite unexpected, though, and starts a new interesting thread of 'investigation'.

 

I've just tested the PC-1403H, aestethically very similar to yours although more modern, and it shows the very same behaviour: "ERROR 5" (Nesting Error - it occurs when you try to nest more than 5 loops).  :-O

1401 was introduced in 1983, 1403 in 1986. 1403 has a better display, more RAM (32kB vs 4kB) and more ROM (72 kB vs 40kB) but still have this inconsistency.

 

I am rather surprised by this findings, the bug was not present at all in the Sharp PC-1500 (year 1981), two years older than the 1401.

It was, however, present in the model 1211 (1980), much more 'archaic' and immediately preceding the 1500.

I thought that with the 1500 the problem had been solved for good, but clearly that wasn't the case.

 

By the way, this looks like a situation where the bug is inherited and propagated within the same 'product line/family'.

 

At this point I know that have to test all the machines.... :-D

 

Thanks again for your time, things are getting interesting!

 

Ciao,

Claudio - P-LAB

 

 

 

 

 

Log in or register to post comments