Talk:Apple II graphics

Merge discussion

This has no hope of becoming an article; it's just a list. It should be shoved into the Apple II article. I could point out more of it's shortcomings, but it isn't worth it. Just move the content there and be done with it. — Frecklefσσt | Talk 11:55, 3 April 2008 (UTC)

It could use a lot of restructuring. But it's is a sufficiently complex subject to be an unwieldy addition to the main article. I'll try to remember to keep banging on it.
—überRegenbogen (talk) 15:59, 8 September 2008 (UTC)

I agree. Vote NO to merge. Not only is this a sufficiently complex subject, but also the Apple II is notable enough to deserve more than afew articles on Wikipedia. Let's keep in mind how historically important vintage computers are. --Bill Buckels (talk) 00:11, 7 December 2009 (UTC)

Double lo-res mode

Some serious inaccuracies were in the section about enabling this mode. Whilst it is bordering on how-to-ism, i rewrote a couple of paragraphs. Most notably:

• PR#3 does work within a programme, but must be followed by sending a character before the GR command, because the command only changes the character output subroutine vector, leaving initialisation to occur upon the first character sent to the newly assigned device. Without the character, that initialisation will not have happened by the time the GR command is invoked and checks to see if the relevant soft-switches are turned on. (I also pointed out that only the IIgs and (i think) IIc firmware support this mode. On a IIe the programmer must provide the support.)

• Whilst send output to the printer without upsetting the screen can be a complicated affair, due to the 80 column firmware also looking like a printer, it is not impossible—merely tricky.
  —überRegenbogen (talk) 16:17, 8 September 2008 (UTC)

Interleaving: "the usual 2:1 factor"? which machine even has it?

Can you name even one machine from the era that uses a 2:1 interleaving in graphics mode? It was certainly not usual. I will remove the phrase unless somebody cites some examples here. -- 92.224.247.169 (talk) 16:17, 15 September 2012 (UTC)

The article doesn't really explain what it means by interleaving and you're correct to have removed the text since it's fairly uncommon on the whole but assuming a 2:1 interleave describes the effect of using two different blocks of RAM simultaneously that ordinarily are addressed individually in order to get double the data rate for video output then the MSX 2 also does this. That's exactly the one other example I can think of. — 64.48.93.0 (talk) 20:09, 2 April 2018 (UTC)

the article claims that many home computers, including the IBM PC, used interleaved graphics memory. which graphics devices and/or modes on the IBM PC used interleaving? I've done a lot of graphics programming on various IBM PC type machines, and I have never encountered an interleaved video mode, so I'm skeptical that there is one. due to addressing limitations some graphics devices and some modes have used bank-switched memory, but that's something different entirely --- and those are still laid out sequentially. I can't speak to how many other home computers of the day did or didn't use interleaved graphics memory. it wouldn't surprise me if the statement is true, that "many" did, but it certainly requires a reference to be cited. 133.11.21.117 (talk) 08:57, 14 February 2023 (UTC)

"color fringes" [...] occur in all modes?

Per the article as currently written:

A second peculiarity of Apple II graphics—the so-called "color fringes"—is yet another by-product of Wozniak's design. While these occur in all modes

Per Page 14 of the Apple II Reference Manual:

When the Video Display is in Text mode, the video circuitry in the Apple turns off the color burst signal to the television monitor, giving you a clearer black-and-white display.*

[...] * This feature is not present on the Revision 0 board.

Most TVs and monitors will suppress all colour decoding if a colour burst is not recognised. Therefore it seems to me that the article is inaccurate in claiming that colour fringes occur in all modes — on all but the earliest machines they should not occur in text mode.

That being said, I write this without ever having witnessed an Apple II in real life. So is the reference manual correct? — 2620:0:1003:1004:4D65:F504:4C88:9623 (talk) 15:02, 28 April 2016 (UTC)

Good find. Yes, the reference manual is correct. I've adjusted the text accordingly. 28bytes (talk) 18:57, 28 April 2016 (UTC)

Nearly Impossible to follow

This article is poorly organized and completely impenetrable to anyone who doesn't understand the technology. It ought to begin with a summary section listing the broad parameters of the various graphics modes, and thereafter drill down into all of its peculiarities.

An example of a summary would be something like the following...

The resolution of many of the graphics modes the Apple II is effectively different depending on the type of display, dependent on the technology of the display type. On a color TV or color composite monitor pairs of horizontal pixels display as different colors, whereas on a monochrome display the underlying pairs can be discerned. As such, on a color monitor the HIRES display visually appears to be 140 pixels wide because of the way the color display works, but the same screen on a monochrome display appears to be 280 pixels wide.

• TEXT mode displays 40 columns by 24 rows of ASCII characters, wherein each character is seven pixels wide and eight pixels tall.
• An 80 character text mode was possible with an expansion board.
• LORES mode displays 48 x 40 pixels in any of 16 colors, of which the two greys are indistinguishable.
• HIRES displays, effectively, 140 x 192 pixels in any of six colors, but is subject to color "fringing" due to the peculiarities of the technology and how it exploits the color CRT display technology.
• MIXED mode displays four lines of text in place of the lower portion of a LORES or HIRES screen.

Not that this is perfect, but I think something like that would be a better way to introduce the subject. --MrNeutronSF (talk) 07:11, 26 March 2018 (UTC)

Suggested 90° phase shift in double high resolution mode: would surely be useless?

As currently written: "Double high resolution also displays four pixels per cycle. (Again, a 90° phase shift would double the colors available, but is not supported in double high resolution mode)"

If there are four pixels per cycle, a 90° phase shift is achievable by just shifting the source data one bit to the right, gaining zero extra colours. 360/4 = 90.

Did the author perhaps mean to suggest a 45° phase shift? Following the pattern of allowing a whole byte to be delayed by half of its native output clock? — 64.48.93.0 (talk) 20:06, 2 April 2018 (UTC)

Restructuring of article for readabilty

I have been working on reworking this article to make it more readable for the typical user. I have commented out some sections entirely and I would like some feedback on whether or not I should remove these. I don't have the technical knowledge to do much besides reword stuff, but the removed sections are as such because they didn't seem relevant to me. Wondering if I could get a second opinion on whether these changes were justified. Work in progress article here Vghfr (talk) 00:36, 10 December 2023 (UTC)

Color tables defective

The color tables suffer from serious defects. They confuse the U,V from YUV as used by PAL-encoded and (the later post-YIQ variant of) NTSC-encoded composite signals with the Pb, Pr from YPbPr as used by three-wire separate-signal connections; in reality, Pb≈U/0.872021, Pr≈V/1.229951, so the scaling factors are different. Also the relative Pb and Pr are wrong even with regard to other values in the tables, they should have the same magnitudes for lo-res colors 3,6,9,12 as for the others (only the total length of the color vector is greater, and that by a factor of √2 rather than by a factor of 2, but not the separate U and V values), so all values should be either 0 or -1 or +1, the 0.5 values are just wrong. Also we can determine the absolute U,V and therefore Pb,Pr values by turning the signal into a fourier series and just looking at the first two coefficients, a(0) and a(1). This gives absolute U, V signal values of either 0 or ±√2/π for all colors, from which we can then calculate (approximate values given) Pb = 0 or ±0.7301, Pr = 0 or ±0.5176. From that one can then calculate the real RGB values for all 16 colors; quite a few will be out of gamut and have to be clamped to 00 or FF. The result will be noticeably different from what is currently in the article. One thing that is not taken care of this way is the fact that the Apple contains an analog phase-shifting pot; its adjustment can be simulated by rotating the U,V coordinate values of all colors around the origin by an equal angle. Apple Documentation instructs users to adjust so that yellow, pink and purple "look like their names say". 2003:C0:9715:9E00:1A07:7E20:B066:1ECB (talk) 22:21, 18 February 2024 (UTC)

I've taken the liberty of correcting this now in the tables, minus the pot adjustment which is a matter of personal preference anyway. The images are still wrong. -- 2003:C0:9715:9E00:1A07:7E20:B066:1ECB (talk) 23:41, 18 February 2024 (UTC)

Here are the hex values for Apple II colors my code generates, with their Apple Inc given names:

0 #000000 black

1 #BF1A3D magenta

2 #452DFF dark blue

3 #FE43FF purple

4 #00813D dark green

5 #808080 grey 1

6 #369CFF medium blue

7 #C39EFF light blue

8 #3E6A00 brown

9 #FC6E00 orange

10 #808080 grey 2

11 #FF86C1 pink

12 #3AEC00 light green

13 #C2EB00 yellow

14 #57FFC0 aqua

15 #FFFFFF white 2003:C0:9715:9E00:1A07:7E20:B066:1ECB (talk) 23:55, 19 February 2024 (UTC)

here is the GNU bc code I used for calculating the color values:

#!/usr/bin/bc -ql
scale=64
define abs(x) {
    if (x >= 0) return (x)
    return (-x)
}
define round(x) {
    auto rs, res
    rs = scale
    scale = 0
    res = (x + 0.5) / 1
    scale = rs
    return (res)
}
define odd(n) {
    auto rs, res
    rs = scale
    scale = 0
    res = (n % 2)
    scale = rs
    return (res)
}
/* shift arithmetic right */
define sar(n) {
    auto rs, res
    rs = scale
    scale = 0
    res = (n / 2)
    scale = rs
    return (res)
}
/* print two-digit hex value between 00 and FF */
define void prhex(n) {
    auto rb
    rb = obase
    obase = 16
    if (n < 16) print "0"
    print n
    obase = rb
}
define clamp(x) {
    if (x < 0) return (0)
    if (x > 1) return (1)
    return (x)
}
/* undo gamma correction gamma=2.2 */
define linearize_ntsc(x) {
    if (x > 0) return (e(l(x)*2.2))
    if (x < 0) return (-e(l(-x)*2.2))
    return (0)
}
/* do gamma correction according to sRGB formula */
define gammaize_srgb(x) {
    if (x < 0.0031308) return (12.92 * x)
    return (1.055 * e(l(x)/2.4) - 0.055)
}
pi = a(1.0) * 4.0 /* pi is 4 times arc tangent of 1 */
/* the following value is from the fourier series expansion of a
   1/4 duty cycle rectangular wave, see here:
   https://www.dspguide.com/ch13/4.htm
*/
sr2op = sqrt(2.0) / pi /* Square root of 2 Over Pi */
/*
  you have to change the following a0 loop for pot settings
   other than 0 degrees
*/
for (a0 = -0; a0 <= 0; a0 += 1) {
    /* convert degrees to radians */
    a = (a0 / 180.0) * pi
    /* loop over the lo-res color numbers */
    for (c = 0; c < 16; c += 1) {
        /* start with Y = U = V = 0 */
        y = 0
        u0 = 0
        v0 = 0
        /* add up Y, U and V for the "basic" colors contained in a
           given color's 4-bit pattern (i.e. the dark colors) */
        h = c
        if (odd(h)) {
            y += 0.25
            v0 += sr2op
        }
        h = sar(h)
        if (odd(h)) {
            y += 0.25
            u0 += sr2op
        }
        h = sar(h)
        if (odd(h)) {
            y += 0.25
            v0 -= sr2op
        }
        h = sar(h)
        if (odd(h)) {
            y += 0.25
            u0 -= sr2op
        }
        /* rotate U, V by angle A (in radians), a no-op unless
           the a0 loop above has been changed */
        u = u0 * c(a) - v0 * s(a)
        v = v0 * c(a) + u0 * s(a)
        /* calc R, G, B (in range 0-1)
           see article "YUV-Farbmodell" in German Wikipedia */
        b = y + (1.0 / 0.493) * u
        r = y + (1.0 / 0.877) * v
        g = (y - 0.299 * r - 0.114 * b) / 0.587
        /* linearize the RGB value, i.e. remove gamma correction */
        r = linearize_ntsc(r)
        g = linearize_ntsc(g)
        b = linearize_ntsc(b)
        /* go from linearized SMPTE-C to CIE1931 XYZ
           http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
        */
        xl =  0.3935891 * r + 0.3652497 * g + 0.1916313 * b
        yl =  0.2124132 * r + 0.7010437 * g + 0.0865432 * b
        zl =  0.0187423 * r + 0.1119313 * g + 0.9581563 * b
        /* go from CIE1931 XYZ to linearized sRGB */
        r =  3.2404542 * xl - 1.5371385 * yl - 0.4985314 * zl
        g = -0.9692660 * xl + 1.8760108 * yl + 0.0415560 * zl
        b =  0.0556434 * xl - 0.2040259 * yl + 1.0572252 * zl
        /* do gamma correction */
        r = gammaize_srgb(r)
        g = gammaize_srgb(g)
        b = gammaize_srgb(b)
        /* restrict to 0-1 range */
        r = clamp(r)
        g = clamp(g)
        b = clamp(b)
        /* store final values */
        rd[c] = r
        gr[c] = g
        bl[c] = b
    }
    print "angle (pot setting): ", a0, " degrees\n"
    for (c = 0; c < 16; c += 1) {
       /* output 16 results as six-digit hex RGB values,
          two digits each for R, for G and for B */ 
        r = rd[c] * 255.0
        g = gr[c] * 255.0
        b = bl[c] * 255.0
        r = round(r)
        g = round(g)
        b = round(b)
        print "#"
        prhex(r)
        prhex(g)
        prhex(b)
        print "\n"
    }
}
quit

2003:C0:9715:9E00:1A07:7E20:B066:1ECB (talk) 16:42, 19 February 2024 (UTC)