PASTE's "width" and "height" arguments don't work?

[dansanderson]

Test Environment (required) You can use MEGA65INFO to retrieve this.

• ROM Release: 920407

Describe the bug The graphics subsystem PASTE command is documented as having width and height parameters, but these appear to have no effect. It will always PASTE what was put in the buffer by CUT or GCOPY.

To Reproduce The example in the manual can repro if you change the PASTE parameters, like so:

10 SCREEN 320, 200,2
20 BOX 60,60,300,180,1
30 PEN 2
40 CUT 140,80,40,40
50 PASTE 10,10,20,10
60 GETKEY A$
70 SCREEN CLOSE

Line 50 would imply that only the 20x10 sub-region of the paste buffer would be drawn, but it draws the full 40x40 image that was cut in line 40.

This should either be improved in the implementation, or removed from the documentation.

[sir-lazarus]

Suggested extensions to existing BASIC commands are described below:

LOADIFF “filename”, xpos, ypos Load the picture to the screen starting at the defined upper left corner

SAVEIFF “filename”, xpos, ypos, width, height Save the screen part to file

Providing clipboard slots, e.g. 8 slots from 0 to 7 for the following commands:

GCOPY x, y, width, height, slot Copy screen part to slot

CUT x, y, width, height, slot, fill_color Copy screen part to slot and fill the source with fill_color

PASTE x, y, width, height, slot Paste screen part from slot to screen

PASTE x, y, width, height, slot, transparent_color Paste part from slot to screen and takes into account the specified transparency color. So the pixels colored in the given transparent color will not overlay the base screen.

Other topic: We have the DMODE, DPAD and PEN (with two parameters) commands in BASIC65. Those commands are not intuitive, so a detailed description, in the e.g. BASIC65 book, with examples would be nice. I am not sure, if those commands works as designed. Gurce provided a basic test program of the DMODE (DPAD) commands in the BASIC65.D81 disk image.

[dansanderson]

A couple of notes, for what it's worth:

• PASTE was "not yet implemented" according to the C65 documentation, so I'm not sure where the width and height arguments originated.
• DMODE, DPAT, and PEN appear in our BASIC 65 reference with as much detail as is present in the C65 documentation. DMODE and DPAT were "subject to change" when the document was written.
• The DMODE demo on the BASIC65.D81 disk is appears to show that most of these features are not implemented, unless I'm misunderstanding how they're supposed to work. As far as I can tell, only the "complement" draw mode changes the behavior of the demo. None of the patterns, thicknesses, etc. change what is drawn.
• PEN's two-argument form claims to set the color of one of three "pens." Pen 2 is "unused," and pen 1 is related to the "jam" DMODE. If "jam" mode does nothing, then the two-argument form of PEN is not useful.

I'm inclined to remove the non-functional features from the documentation in the short term, and leave the feature requests in the queue for anyone who wants to work on them. (Personally I find the bitplane graphics subsystem a bit intimidating to work on. Hopefully someone braver than I will step up at some point. 😅)

[dansanderson]

Ooh, correction: the DMODE demo does demonstrate some DPAT functionality, when you press the $ key.

The jam, stencil, and thickness settings to DMODE still appear to be non-functional, per the demo.

[dansanderson]

DPAT only affects shape fill when DMODE style = 1 or 3. Styles 0 and 2 don't have an effect that I can see.

Circle fill warps the DPAT pattern in a fun way, but a way that might be difficult to use (unless you just like the result). A filled rectangle just uses on-off bit patterns across 1 to 4 bytes horizontally; there's no vertical pattern variation. A non-rectangle "box" fill seems to be unhappy with fill patterns.

DPAT's four "built-in" patterns have no effect. Only pattern 0 with custom values change anything (and again, only in DMODE style 1 or 3).

So in general this whole part of the API feels incomplete and undefined to me, which is probably more reason to officially declare it "undefined" so someone can complete it with a new definition later.

[dansanderson]

jam mode does something, but it doesn't seem to be related to PEN 1,c. (Maybe there's a specific circumstance where it uses the custom pen color.)

[dansanderson]

From code review and testing:

• Stencil and thickness are not implemented.
• Style 3 is commented as "reserved." Style 2 is commented as "tile" and is not implemented. The only implemented styles are 0=solid and 1=use DPAT pattern.

The four built-in patterns work fine, I just overlooked them in my testing.

    .byte %10001000   ;  thin dot
    .byte %11001100   ;  thick dot
    .byte %11101110   ;  dashed
    .byte %10011100   ;  dot/dash

Pattern rendering is not always intuitive. It's based entirely on the order in which a given draw command plots dots: it just marches across the pattern as it plots each dot. Circle fill and non-rectangle box fill gets weird because it doesn't fill in straight lines across the screen, like rectangles do.

[dansanderson]

I have made the following changes to resolve this issue:

• I updated the documentation to remove the unimplemented PASTE width and height arguments. These do not appear to come from the C65 spec, so they're just inaccurate. We can implement them later.
• I updated the documentation for DMODE, DPAT, and PEN to represent these findings of unimplemented features, along with code samples for the working features of DMODE and DPAT.
• I'm moving the PASTE, LOADIFF, and SAVEIFF position and clipping region feature requests to this issue: https://github.com/MEGA65/mega65-rom-public/issues/161

I don't think multiple clipboard slots will be feasible. There's already 1 KB reserved for graphics clipboard data. Eight slots would require 8 KB (and/or more sophisticated memory management), which is a lot to reserve for a seldom-used feature.

I'll admit that I still don't fully understand how jam combines color values, or if the secondary PEN is implemented in jam mode. If we discover a more precise definition of jam, we can add it to the documentation.