[Coco] CoCo Basic (was Re: CoCo Emulators)

[Joel Rees]

I don't think Steve is seeing this.

On Mon, Mar 22, 2021 at 1:07 PM William Astle <lost at l-w.ca> wrote:

> Note that none of this has anything to do with emulators, specifically.
>
> The manual is actually wrong about the array size anyway. It results in
> an array larger than required by a fair margin (about 25 times too big
> in this case). Any array will do, as long as its data size is large
> enough to contain the pixel data, which is *not* stored as one pixel per
> array element. Instead, as I recall from the code in Unravelled, the
> pixel data is stored "raw" (8 pixels per byte in the case of PMODE 4). I
> believe there has to be an integer number of bytes per row so in your
> case, a 17 pixels wide would need 3 bytes per row times 17 rows or 51
> bytes. Since an array has 5 bytes per element, that means you need an 11
> element (total, not per dimension) array. In theory.
>
> A quick test shows that the following works without an error:
>
> PMODE 4,1
> DIM A(10) ' 11 elements, zero based, remember
> GET (0,0)-(16,16),A
>
> The following gives an FC error:
>
> DIM B(9) ' 10 elements, zero based, remember
> GET (0,0)-(16,16),B
>
> So basically, if your array is too small, you'll get an error.
>
> What you're probably running into is coordinate rounding for
> "efficiency". Since 30 isn't a multiple of 4 (the internals of Extended
> Basic work on 2 bits per pixel/4 colours regardless of actual mode), it
> probably gets shifted up or down to 32 or 28. I think there's an
> "action" option that can be specified with PUT that will make it do
> things accurately. I think it might be ",G" after the variable name.
>
> On 2021-03-21 8:34 p.m., Steve Ostrom wrote:
> > Robert, I don’t think that is correct.  The definition of DIM says the
> array should be defined as (width,length), where width = x2-x1 and length =
> y2 – y1.  In my example, x1 and y1 = 0, and x2 and y2 = 16.  Therefore
> width and length = 16-0 = 16.  So DIM W(16,16) should define the array for
> a square from 0 to 16.  On page 69 of the Going Ahead manual, they even
> give an example of a 40x20 rectangle, which will require the array
> (39,19).  They give the reason for this as “Color BASIC arrays have a zero
> element”.  My array is 17x17, so should require a DIM 0f (16,16).
> >
> > --- Steve ---
> >
> >
> > Sent from Mail for Windows 10
> >
> > From: Robert Gault
> > Sent: Sunday, March 21, 2021 8:14 PM
> > To: CoCoList for Color Computer Enthusiasts
> > Subject: Re: [Coco] CoCo Emulators
> >
> > Keep in mind that when you DIM W(16,16) that is a 16 by 16 package.
> However, when you talk about a screen location at say 30 or a GET
> (0,n)-(16,m) you have moved 31 spaces or grabbed 17 units.When you start at
> 0 and go to n, that is a change of n+1.
> > Sent from AT&T Yahoo Mail on Android
> >
> >    On Sun, Mar 21, 2021 at 8:50 PM, Steve Ostrom<smostrom7 at comcast.net>
> wrote:   OK, I fired up my CoCo 3 and I get the same result as the
> emulator.  So I must be making an error in my understanding of the PUT
> function.
> >
> > PUT(30,0)-(46,16),W must not put the graphics starting at (30,0).
> >
> > --- Steve ---
> >
> >
> > Sent from Mail for Windows 10
> >
> > From: Steve Ostrom
> > Sent: Sunday, March 21, 2021 7:22 PM
> > To: CoCoList for Color Computer Enthusiasts
> > Subject: Re: [Coco] CoCo Emulators
> >
> > Thanks for confirming my suspicions about INT. The newer CoCo 3 manual
> does state it correctly and the older Getting Started manual does not.
> >
> > I am having a problem with the PUT function in the VCC emulator.  It’s
> not working like I assume it would, or I’m making a huge blunder.  Here is
> a simple code to illustrate.
> >
> > 100 PCLEAR4
> > 110 DIM W(16,16)
> > 120 PMODE 4,1
> > 130 PCLS
> > 140 SCREEN 1,0
> > 150 FOR X=0 TO 16
> > 160 FOR Y=0 TO 16
> > 170 PSET(X,Y)
> > 180 NEXT Y
> > 190 NEXT X
> > 200 GET(0,0)-(16,16),W
> > 210 PUT(30,0)-(46,16),W
> > 220 PSET(30,0)
> > 230 PRESET(30,0)
> > 240 GOTO 220
> > 250 END
> >
> > This code should create a 17x17 pixel solid square in the upper left
> corner of the screen starting at (0,0).  Then it should copy and paste that
> square 30 pixels to the right, starting at (30,0).  Then the PSET and
> PRESET loop should blink that pixel at (30,0).  When I run this program,
> the blinking pixel is not the upper left corner of the pasted square.  So
> PUT is not pasting the square at where I expect it to.  I’d appreciate it
> if someone could show me where I’m not understanding the GET and PUT
> functions.
> >
> > Thanks!  (I told you I’d probably have more questions about the emulator
> !!  😊)
> >
> > --- Steve ---
> >
> >
> > Sent from Mail for Windows 10
> >
> > From: Arthur Flexser
> > Sent: Sunday, March 21, 2021 6:23 PM
> > To: CoCoList for Color Computer Enthusiasts
> > Subject: Re: [Coco] CoCo Emulators
> >
> > The greatest integer in -2.3 is -3, since -2.3 is smaller than -2.  The
> INT
> > function is defined as the greatest integer in a number.
> >
> > Art
> >
> >
> >
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>


-- 
Joel Rees

http://reiisi.blogspot.jp/p/novels-i-am-writing.html