vro_cpyfm and logical operations

[Kirkman]

I'm working on a little web app to let me draw art that can be exported to IGS ("Instant Graphics and Sound") format for use on Atari ST BBSes.

I'm trying to simulate IGS's "grab" (bit-blit) command in Javascript. In IGS on the Atari, this is basically a wrapper for VDI's vro_cpyfm. I don't quite understand how it works.

I thought that vro_cpyfm was comparing the color register values of the source pixel with the destination pixel, and computing a new value using whatever logical operation mode was set. So, for example, say that we use mode 7 ("S OR D" / transparent mode), and our source pixel (0,0) is set to color register 1, and our destination pixel (1,0) is set to color register 6. I thought that vro_cpyfm would perform the operation "1 | 6", which gives a result of "7".

But after implementing this approach, it doesn't match what I see on the Atari. Here's an example where I blitted a Calvin sprite on top of a cardboard box. The lefthand image was made in the IGDEV editor running in Hatari; the righthand image was made in my web-based program.

7.png (10.2 KiB) Viewed 1755 times

blit-js.png (11.97 KiB) Viewed 1755 times

palette.png (6.25 KiB) Viewed 1755 times

In my implementation (at right), color 1 (black) becomes 7 (brown) when blitted on top of color 6 (light brown) in mode 7. Similarly, color 13 (yellow hair) becomes 15 pink. 10 (white) becomes 14 (tan). I believe this follows the math: 1 | 6 = 7 ... 13 | 6 = 15 ... 10 | 6 = 14.

But on the Atari, it's mostly different. Color 1 (black) remains color 1 when blitted on top of color 6 (light brown) in mode 7; and color 13 (yellow hair) becomes color 1 (black). One change that matches mine is that color 10 (white) becomes 14 (flesh tone).

Anyway, I need to make my implementation match the Atari, and clearly I have misunderstood what's going on. Can anyone explain in plain language what operations vro_cpyfm actually performs?

[sporniket]

If memory serves right, VDI color index IS NOT THE SAME as the physical color index. Like black (color 1) is in fact physical color 15. You should build your map between VDI color and physical color.

[Kirkman]

Of course. I had completely forgotten about that, even though apparently I did a bunch of research on it last year.

Here are two references I found, in case anyone else comes across this in the future and wonders:

1. From section 6-3 of the GEM VDI Programmer's Guide (First edition, March 1985):

colors-table-3.png (204.46 KiB) Viewed 1720 times

2. "CONTROL GEM WITH ST BASIC" from Antic Magazine (vol. 4, no. 2, April 1986)

colors-table-2.png (40.48 KiB) Viewed 1720 times

The first reference gives me a pretty clear idea of what I need to do to my web app. I'll make some changes and test it, then report back if it works.

[Kirkman]

Yes, I did have to convert from color index to pixel value, then perform the logical operation, then convert back to color index. Now my code is working great, and the blits look just like the Atari. Woo-hoo!

[Darklord]

Congratulations!