[Coco] A bug in Basic09/RunB

[Gene Heskett]

On Sunday 06 December 2009, Wayne Campbell wrote:

>Gene,

>

>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.

>

>Wayne

>

>

>

>

>________________________________

>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:

>>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/packa

>>>g 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.

>

I have an icon editor that passes params by the trainload, and I don't recall 
that I had any problems that resemble what you have described.  OTOH, since 
the serial mouse driver was removed from co80 or cc3io I haven't been able to 
use the mouse as I had before, and I've not had the time to run it down..  
Only the left mouse button works out of 3 now, and years ago all 3 buttons 
worked.  Button data is getting to the mouse packet, but is seemingly being 
ignored by gshell & multivue now.

-- 
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>

Certainly the game is rigged.

Don't let that stop you; if you don't bet, you can't win.
		-- Robert Heinlein, "Time Enough For Love"