[Coco] A bug in Basic09/RunB

[Robert Gault]

Gene Heskett wrote:
> On Sunday 06 December 2009, Wayne Campbell wrote:
>> James,
>>
>> 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:
>>
>> RUN GFX2("FCOL",col.bl)
>>
>> but you cannot pass:
>>
>> RUN GFX2("FCOL",col.fg.bl)
>>
>> 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.
>>
>> Wayne
>>
>>
>>
>> ________________________________
>> 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
>>
>> Wayne
>>
>> 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
>> james
>>
>> 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:
>>>
>>> a:BYTE
>>> a:=1
>>> RUN myProc(a+0)
>>> END
>>>
>>> PROCEDURE myProc
>>> PARAM a:BYTE
>>>
>>> PRINT a
>>>
>>> END
>>>
>>> The result should be
>>>
>>> 1
>>>
>>> Instead,, it is
>>>
>>> 0
>>>
>>> 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)
>>> END
>>>
>>> PROCEDURE recPars
>>> DIM cntr:INTEGER
>>> PARAM d(3):INTEGER
>>>
>>> FOR cntr:=1 TO 3
>>> PRINT d(cntr)
>>> NEXT cntr
>>> END
>>>
>>> Results:
>>>
>>> 1
>>> 2
>>> 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
>>> processed.
>>>
>>> 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.
>>>
>>> http://nitros9.cvs.sourceforge.net/viewvc/nitros9/nitros9/3rdparty/packag
>>> es/basic09/?sortdir=down
>>>
>>> I'll report anything else I find out as I go.
>>>
>>> Wayne
>
> 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.
>

The stock Basic09 for OS-9 Level Two has a length of $5ACC and a CRC of 
$F0388C. It exhibits the same error in passing a:byte as a+0 as Wayne 
reports.
The most recent Basic09 with NitrOS-9 6309 version has a length of $5955 
and a CRC of $22CA28. Same error is present.

The most likely thing that is happening is that the +0 is causing the 
parameter to be passed as an integer. Since an integer is two bytes, 
$0001 will be reported as $00 since a byte was expected.
This is, I think, confirmed since if you change the statement in the 
second program to PARAM a:INTEGER, the correct value is obtained by the 
called program.

One could argue as to whether this is a bug or feature. I think we need 
to know what was intended by Microware.