[Coco] CoCo Basic

[Steve Ostrom]

Very interesting, William.  I did see the G option, but I thought it was used to convey full graphic detail, such as color.  My understanding of PMODE 4 was that the programmer had full control of each pixel on the PMODE graphics screen, which meant the ability to address each pixel.  I will try the G option, because that would explain why PUT was not working correctly.  In the CoCo 3 manual, G is required when using PMODE 3 or 4 with colors, or when using any of the PUT action parameters such as NOT and OR.

You go into a great deal of explanation of the DIM command below, but if I understand correctly, my DIM should be OK, and is what the manuals say to use, but that programmers have found that you can reserve a lot less space for the array than what was stated in the books.

I really appreciate your insight into using Get and PUT.

--- Steve ---


Sent from Mail for Windows 10

From: William Astle
Sent: Sunday, March 21, 2021 11:07 PM
To: coco at maltedmedia.com
Subject: Re: [Coco] CoCo Basic

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