Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!pro-carolina.cts.com!stowekeller From: stowekeller@pro-carolina.cts.com (Stowe Keller) Newsgroups: comp.sys.apple Subject: Re: Applesoft bugs (was GS/OS SCSI) Message-ID: <9001151702.AA19657@trout.nosc.mil> Date: 14 Jan 90 23:56:46 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 109 Re: kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) who asks: > ... I ask anyone to name an actual *BUG* in Applesoft, other than > the ONERR cannot-have-another statement-on-the same-line quirk? > Applesoft is amazingly stable for v1.0... Methinks you don't use Applesloth very much! 8-) There are a fair number of bugs in Applesoft, ranging from annoyingly common to extremely obscure. I don't have a single list of them, but I will pass along a few here. I had found a few of my own about ten years ago, but Cornelis Bongers (of the Netherlands) and Glen Bredon (of Merlin and ProSel fame) have probably done some of the most extensive research into Applesoft's internals and its bugs. The older versions of the Merlin assembler used to have Bredon's own commented disassembly of Applesoft in which, among other things, he found bugs and often told how to fix them. Those of us who used DOS 3.3 and had 16K language cards could place a patched version of Applesoft into that RAM and run Applesoft from there instead of from the ROMs. Here are some of the Applesoft bugs that I can think of: -As someone else mentioned, there is a bug in the floating point multiply routine which can cause the bottom 8 bits to be wrong, resulting in loss of precision. Bredon's examples of this are: PRINT 1*998244415 or PRINT 1*10.0000009 Calculations which make use of the multiply routine, like SIN() and COS(), EXP() etc also suffer as a result of this bug. -I believe there is a bug with the sign bit in certain divide calculations. I think that PRINT -3E-39 / 1 will show this. -Applesoft in some situations, like PRINT statements, fails to trap excessive decimal points in a number. Instead of giving a SYNTAX ERROR, it ends up with a silly number. Try something like: PRINT 1...3..4 -The integer constant for -32768 in the ROMs is incorrect, causing certain range comparisons for integers to fail. Try X% = -32768.00049 : REM illegal value for integer var. PRINT X% <---- will yield POSITIVE 32767 !! -Placing ridiculously large line numbers after a GOTO or GOSUB can cause Applesoft to crash into the monitor. Try something like: GOTO 437761 or GOTO 440319 or values in between. -The pseudo random number generator is essentially worthless, and the most authoritative articles say that there is no way to patch the existing algorithm to get it to work - it should be completely replaced with a new algorithm. Call-APPLE published such an article using machine language and the USR() function several years ago. -Not only is the string garbage collection routine unbearably slow, it too can screw up and trash variables. Bredon gives the example: LOMEM: 10000: HIMEM: 10012: A$ = "A":A$=A$+"B": A$=A$+"C":PRINT A$ which incorrectly yields "ABA" instead of "ABC". -Due to conflicting use of the keyboard buffer, using an immediate mode GOSUB command which invokes a subroutine that uses INPUT or GET can give a very bizarre error. Try the following: 10 GET A$ 20 RETURN GOSUB 10: PRINT A$ <-- from immediate mode; you will get an error message along the lines of ?SYNTAX ERROR IN 16826 . This results from the fact that your immediate mode commands which reside in tokenized form in the keyboard input buffer get overwritten by the ASCII chr(s) that you enter for the GET or INPUT statement, and when Applesoft tries to resume execution after the RETURN, it sees junk and generates a syntax error for a bogus line number. -Cornelis Bongers wrote another article for Call-APPLE explaining how an incorrect RETURN WITHOUT GOSUB error can occur. It's too long to explain here, but it involves FOR-NEXT loops and GOSUBs and having a loop variable stored across a page boundary and exiting from a subroutine that still has a FOR loop active. -I vaguely recall reading other articles about problems that could arise with overflowing the stack and Applesoft wouldn't correctly trap it as an OUT OF MEMORY condition. And I think there was a problem that could arise because the decimal printout routine uses memory locations $00FF through $110 (for building the ASCII string when printing out a floating point number) and if the stack grew low enough without getting caught by the out-of-memory test, something would get overwritten. Alas, I forget the details. If anyone has access to Randy Wigginton (sp?), who did most of Apple's work on the Applesoft code when they got it from Microsoft, he might be able to list off a few other known bugs of Applesoft. Hope this answers your question! Stowe Keller ------------------------------------------------------------------------ Stowe Keller Author of ProDOS8 LIST utility CompuServe: 71540,725 GEnie: SKELLER BIX: stowekeller UUCP: [ sdcsvax nosc ] !crash!pro-carolina!stowekeller ARPA: crash!pro-carolina!stowekeller@nosc.mil INET: stowekeller@pro-carolina.cts.com ------------------------------------------------------------------------ Stowe Keller Author of ProDOS8 LIST utility CompuServe: 71540,725 GEnie: SKELLER BIX: stowekeller UUCP: [ sdcsvax nosc ] !crash!pro-carolina!stowekeller ARPA: crash!pro-carolina!stowekeller@nosc.mil INET: stowekeller@pro-carolina.cts.com