[Coco] A bug in Basic09/RunB
asa.rand at yahoo.com
Sun Dec 6 23:13:25 EST 2009
As I said before, I can't be certain this problem didn't exist before the modifications. For all the work I did developing DCom, I don't recall looking that deeply into what was being passed. I assumed it would be correct.
Therefore, the bug may go all the way back to Basic09 1.00.00 and was never caught. It is possible.
From: Gene Heskett <gene.heskett at verizon.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Sun, December 6, 2009 7:28:51 PM
Subject: Re: [Coco] A bug in Basic09/RunB
On Sunday 06 December 2009, Wayne Campbell wrote:
>I would love to do that, but I have had a problem with booting the original
> OS-9 Level 2. I get a black screen with a magenta cursor. I can see that
> the system is booted and the startup file is being displayed by the
> movements of the cursor. I can set date and time, though I can't see what
> I'm typing. Using display commands from the command line yields no change.
> Until I can fix that, I can't test anything.
>In addition to the previous post, there is a third bug. I had almost
> entirely forgotten it. It also involves parameter passing, but deals with
> passing fields of records. You can pass one level deep:
>but you cannot pass:
>Basic09 does not return a compiler error, but the value passed during
> execution is incorrect.
>Since all 3 of these bugs are related to parameter passing, I think the
> routines dealing with establishment of the pointers in the list should be
> looked at first, and then the parameter counter for receiving parameters
> into called procedures to see why it's miscounting them.
>From: "jdaggett at gate.net" <jdaggett at gate.net>
>To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>Sent: Sun, December 6, 2009 5:56:32 PM
>Subject: Re: [Coco] A bug in Basic09/RunB
>One way of determing whether the original Basic09 has this bug or was
> introduced in later modifications is to run you tests on the stock version
> Basic09. Instead of booting with the newer NitrOS9, just boot up your
> system with the orignal OS9 Level II disks and with Basic09
>just my thoughts
>On 6 Dec 2009 at 17:49, Wayne Campbell wrote:
>> When I first learned Basic09, I did not possess the knoweledge and
>> experience that I now have. There were many things that were overlooked
>> in DCom, simply because I did not understand the function. Now, I know
>> more about the function.
>> I believe I have found a bug in Basic09. With all of the modifications
>> that were made to Basic09 between 2002 and 2006, I cannot be certain that
>> this bug did not exist prior to the modifications. However, if experience
>> is any guide, it may well have gotten broken during the modification
>> process and was never discovered.
>> The bug is in the way parameters are passed to called procedures. First,
>> any simple variable type (other than boolean) can be passed by value
>> using +0 on the byte, int and real variables, and +"" on strings. To pass
>> a boolean value, use TRUE or FALSE.
>> Second, as long as the receiving variable is of the correct size, it
>> doesn't matter what type or order you specify the parameter list in. It
>> just has to match the size.
>> The first bug occurs when you pass a byte by value:
>> RUN myProc(a+0)
>> PROCEDURE myProc
>> PARAM a:BYTE
>> PRINT a
>> The result should be
>> Instead,, it is
>> The wrong byte is being retrieved. All BYTE variables are expanded into
>> INTEGERs before being processed. In this case, the first byte of the
>> integer is being read, not the second. I can never remember which order
>> they are in, so I'm not certain which one is LSB and which one is MSB. To
>> be clear:
>> | 1 | 2 |
>> Byte 1 is being read, when byte 2 should be being read.
>> The second bug occurs when you pass multiple variables into a single
>> variable. Based on the fact that it works correctly, under the following
>> conditions, on the first 2 elements of the receiving array, it should be
>> working correctly for all of the parameters needed to equal its size. The
>> test procedure passed 3 INTEGER variables into 1 3-element INTEGER array.
>> PROCEDURE testParams
>> DIM a,b,c:INTEGER
>> a:=1 \b:=2 \c:=3
>> RUN recPars(a,b,c)
>> PROCEDURE recPars
>> DIM cntr:INTEGER
>> PARAM d(3):INTEGER
>> FOR cntr:=1 TO 3
>> PRINT d(cntr)
>> NEXT cntr
>> 56 (Parameter Error)
>> In addition, I added a fourth parameter, a second reference to a, and a
>> 4th element to d. The error occurred in the same position in the array as
>> before. Therefore, the accumulator that is supposed to count the
>> parameter sizes is exiting before the final parameters are being
>> I do not know enough about assembly language to track down these bugs.
>> Maybe someday, not not any time soon. If someone on this list wants to
>> see if they can figure it out, the source to the modified Basic09 and
>> RunB are on sourceforge.
>> I'll report anything else I find out as I go.
Wayne; AFAIK, only 1 byte has been changed is both basic09 and in runb since
the original distribution by Tandy. I don't have access to it at the moment
but a cmp should spit out the diff.
If this is no longer true, then Robert or Boisy please pipe up and clarify.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
"It is better to have tried and failed than to have failed to try, but
the result's the same."
- Mike Dennison
Coco mailing list
Coco at maltedmedia.com
More information about the Coco