[Coco] A bug in Basic09/RunB

[Wayne Campbell]

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/packages/basic09/?sortdir=down
> 
> I'll report anything else I find out as I go.
> 
> Wayne
> 
> 
>      
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco



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