Re: Integer BASIC Question

[pausch@saaf.se (Paul Schlyter)]

In article <mfumu-75E84E.07335416042002@news.alphalink.com.au>,
Bill Robbins  <mfumu@alphalink.com.au> wrote:
 
> A touch of trivia:  Integer BASIC was written by Woz, and AFAIK is rock 
> solid.
 

:-) ...you might be interested to read this, from the documentation
to "Flash! An Integer Basic Compiler" by Mike Laumer:
 
---------------------------------------------------------------------
 
A BUG IN INTEGER BASIC.
                       
 
You may be interested to know of a very bad bug in the Integer BASIC
Interpreter.  The bug does not appear in the FLASH! runtime package.
The problem is very difficult to get to occur on purpose but if it
does occur your program will execute erratically.  The bug is in the
FOR loop execution.  When Integer BASIC starts up a FOR loop it
checks to see if the FOR loop variable is currently on the stack of
FOR loops.  If the variable is found on the stack, then the whole
stack of FOR loops is shuffled to delete that entry from the stack.
The FOR loop stack is accually 10 separate stacks in Integer BASIC
and they are at memory locations $140-14F, $150-15F, $160-16F,
$170-17F, $180-18F, $190-19F, $1A0-1AF, $1B0-1BF, $1C0-1CF, and
$1D0-1DF.
 
These contain; the FOR loop variable in the $140,150 stacks, the
upper limit value in the $1C0,1D0 stacks, the step value in the
$160,170 stacks, the line address of the statement with the FOR loop
start in it (FOR) in the $180,190 stacks, and the offset following
the FOR loop statement to begin execution at when looping back from
the NEXT statement is in the $1A0,1B0 stack.  All stacks get shuffled
but the $1A0,1B0 stack only has the $1A0 stack shuffled twice!!  And
the MSB of the return address does not get shuffled at all!
 
This bug can cause a bad loopback to occur if each FOR loop shuffled
is not in the same page of memory as the inner loop beneath it on the
stack.  Most of the time it works because the page addresses are the
same or because FOR loops are not branched out of and the NEXT
statement will drop the loop from the stack when the loop falls
through the NEXT statement.
 
This explains some strange problems which occasionally defy debugging
and disappear when you change the program a little bit.  The
offending code is at memory locations $F288-$F2DF with the bad
instructions being:
 
    F2CE- B9 A1 01   LDA  $01A1,Y
    F2D1- 99 A0 01   STA  $01A0,Y
    F2D4- B9 A1 01   LDA  $01A1,Y
    F2D7- 99 A0 01   STA  $01A0.Y
 
If the following two instruction changes are made the problem becomes
fixed.
 
    F2D4- B9 B1 01   LDA  $01B1,Y 
    F2D7- 99 B0 01   STA  $01B0,Y
 
If you use a RAM card and run Integer BASIC in it then you could
patch the code to run all programs correctly.  What a difference two
bytes will make!
 
 
---------------------------------------------------------------------
 
A BUG IN PROGRAMMER'S AID ROM.
 
 
There is another bug located in the programmers aid ROM in the XDRAW
hires graphics subroutine.  It is located at $D29A-D2F8 in memory.
The offending instruction is at $D2E1:
 
    D2E1- 20 D9 D0   JSR $D0D9
 
If you run Integer BASIC in a RAM card you can make the following
instruction change.  The XDRAW subroutine can then be used, even
though the calling seguence is not described in the manual (because
it doesn't work).
 
    D2E1- 20 C1 D0   JSR  $D0C1
 
The XDRAW graphics routine is important for drawing a shape and later
erasing it allowing the screen to be completely restored to its
previous value before it was XDRAWn.  The routine is used just as
with the DRAW subroutine except that to erase a shape previously
plotted use the same scale, rotation, color and x,y position and call
XDRAW.  The shape will then disappear from the screen even if it was
plotted over the top of existing shapes and lines.  An alternate
entry XDRAW1 will allow linking of shapes together just as DRAW1 does
with the DRAW routine.  The entry points for the Integer BASIC
programmers aid XDRAW subroutine(s) are:
 
    10 XDRAW = -11449 : XDRAW1 = -11452
 
FLASH! will of course allow you to use the XDRAW command with an
active REM extended statement.  And it does not have the problem that
the programmers aid ROM does.  The XDRAW routine in FLASH! will work
without a patch.
 
      (This bug is corrected in Applesoft's hi-res routines)
 
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se
WWW:     http://hem.passagen.se/pausch/index.html
         http://home.tiscali.se/~pausch/