[Coco] A bug in Basic09/RunB

[Gene Heskett]

On Sunday 06 December 2009, Robert Gault wrote:
>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/pack
>>>>ag 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.

Thanks for the clarification Robert.  Now the question is what was removed to 
shrink it by over a page of memory in the latest version?

>--
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco
>


-- 
Cheers, Gene
"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.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

Avec!