Talk:ZX Spectrum graphic modes

This information needs to be reviewed by someone who knows the ZX demo scene or has used any of these modes. I myself only have access to some image converters and emulators, and couldn't get much more information than what's here.

It would be good to sort out the proper names and machines on which they are avaliable as software or hardware supported modes.

Also, a list of graphic editors for each mode would be nice, along with some software that showcases its use. --Ricnun 15:55, 26 July 2006 (UTC)

Epilepsy?

I'm a bit worried about Image:Parrot rgb3.gif. I think it could give someone a fit, so a slower version would be better -- maybe with a link to the existing version, together with a warning? --StuartBrady (Talk) 22:30, 3 August 2006 (UTC)

• I've replaced both of the flickering images with links and warnings. The W3C's guidelines on this are available here.--Fastfission 14:45, 4 August 2006 (UTC)

• Good, looks fine to me. This "new" display modes do flicker a lot, even on a TV, so the GIFs really simulate the effect (50Hz flicker). I think a good solution is really to just keep the links. Slower gifs will not simulate the effect and still flicker a lot. This way people can see the simulated effect if they can and healht issues are prevented. Since I created and put the images here on the first place, I apologise for some possible inconvenience.

Sorry, I wasn't clear — the idea of using a slower version wasn't to simulate the effect, only to illustrate how the effect works. I should really have said "one or two frames per second". --StuartBrady (Talk) 19:45, 4 August 2006 (UTC)

Shock Megademo

User:Pak21 removed this sentence, citing Shock Megademo as a counter-example:

However, the Spectrum's processor is not fast enough to write to an entire row of attribute bytes in one scanline, so 8x1 attributes can only be achieved over half of the screen width.

Shock Megademo does not utilise 8x1 attributes. It uses 8x2 attributes on top of alternating paper and ink lines to achieve a different colour on each line; one colour per line equals two colours per 8x2 cell. Don't know if it's worth mentioning this particular example in the paragraph about 8x2... Slovakia 10:31, 28 February 2007 (UTC)

I kind of doubt that 8x1 mode could cover half of the screen width. For a 3.5MHz machine, one TV scanline takes 224 CPU clock periods (i.e. 64us) which is enough to change the color attributes for only 14 character blocks (112 pixels) using 14 LDI instructions (one of the quickest ways of copying blocks of memory) without adjusting the pointers back to the start of the hicolor zone (each execution of an LDI intruction takes 16 clock periods). In fact, David Webb propsed in "Advanced spectrum machine language" ([1]) a hicolour mode with a width of only 8 characters (64 pixels). I was able to extend this width to 11 or 12 character blocks (long time since then) by lengthening the code but this would be OR since I don't have anything published. However, if you'd use a single attribute byte per scanline, then yes, you could extend the hicolour zone to half of the screen width (or maybe more - again, David Webb has a full-screen horizon generator that changes the attributes for some 22 characters) but that wouldn't count anymore as 8x1 attributes.89.137.246.65 (talk) 21:48, 27 February 2011 (UTC)Apass

I rechecked the timmings and the Z80 instruction set and I guess, with enough RAM available during execution, it could be possible to change the attributes for about half a screen witdh on each scan line. For instance, a combination of LD HL,(Buffer); LD (ATT),HL; will take 26 t-states for 2 attributes, allowing for 16 bytes replaced during a scanline (and a timming sequence like 4 NOPs on each scanline) - however, the RAM needed for this would be quite large - 16 attribute bytes/scanline x 192 pixel rows x (1 byte/attribute in the Buffer zone + 3 bytes for LD HL,(Buffer) + 3 bytes for LD (ATT),HL) + 192*4 bytes for timing on each line, will make some 22272 bytes needed. Well, it could be done better than this using some tricks, but that's a new project for me :)89.137.246.65 (talk) 21:11, 28 February 2011 (UTC)Apass

I don't know what was wrong with me the other day... the instruction sequence would be, of course, LD HL,Attribute; LD (ATT),HL. And the amount of RAM would be 8x192x(3+3)+192x4=9984 bytes. I was off by a factor of 2.2 - I forgot that each intruction pair deals with two attributes, so only 8 pairs are needed to fill the 16 bytes per line and that each instruction contains all the attribute data needed, so the attribute table is not necessary...89.137.246.65 (talk) 21:26, 1 March 2011 (UTC)Apass

About the color palette section and the size of the thumbnails

Hello. I am the original writer of the section Color palette in the List of palettes article, ZX Spectrum section. I saw you have copy&pasted the section literally. I think that wikipedians must not to "copy-paste" between us! One of two: or the technical details must keep in this page and the color table keep in the palettes article with a link to the yours, or you should to put a simple paragraph (with your image, it's OK) and a link to the ZX Spectrum section of the "List of palettes" article.

Also, I think that the size you have put the sample thumbnails blurs the images (at least, in my PC) and the original effect is lost. A casual reader (and even an proffesional) will not note any difference between them. I think it's better to keep them at their original 256-width size.Ricardo Cancho Niemietz 20:05, 6 March 2007 (UTC)

I made the copy. Yes, it's a duplication and for me just some details and a link the Spectrum section on the palettes article is a good solution. Just like on other articles were you have "See main article". So that's fine for me.

As for the image size, good point. I formated the article for good layout out of experience. If the images are larger, someone will just edit and change their size. I've see this happen and really I don't have to time do keep reverting edits :-) Let me see if I can format this with 100% images and a good layout. Thanks for your input, I'll see to it when I have time if no one else does it first. Also, congratulations for the good job on the pallettes article ;-)Ricnun 00:31, 7 March 2007 (UTC)

I've changed the image sizes, let's hope nobody reverts them as this is pretty important. Moroz1999 (talk) 11:56, 17 February 2012 (UTC)

exact RGB values for palette.

The exact RGB values for the palette has been taken from the topic on ZX.PK.RU forum, where they have appeared as a result of a thorough discussion, hardware test and mathematic calculations. original topic (in russian)[2]

The mostly agreed result is on the 13th page (Unreal Speccy palette format):

pulsar=00,76,CD,E9,FF,9F:FF,00,00;00,FF,00;00,00,FF

Moroz1999 (talk) 19:06, 12 April 2009 (UTC)

That's great, except that noone understands it except the Unreal Speccy. For us mere humans, please convert this result to sRGB. 80.80.52.167 (talk) 08:51, 9 November 2023 (UTC)

Also, the linked discussion is in Russian, which makes it impossible to read.

Also, if the linked article doesn't include a conversion of primary colors from BT.601 (PAL) to Rec.709 (sRGB), then the result must be flawed. 80.80.52.167 (talk) 09:08, 9 November 2023 (UTC)

Too bright 'dim' RGB values suddenly – “PAL gamma”?

I am quite worried after 4throck's « PAL gamma approximation » that has set 224 as potential RGB values for the dim colors, lately.

→ MY SUMMARY:

I am not convinced at all from this undocumented and rough method, so I'd like to know more about the applied conversion, in scientific terms hopefully. From what I humbly know as a long-term pixel artist and coder, almost all the related users on the real hardwares and via emulators are pretty fine with the medium 192, even the brighter 205 at times, for at least 14 years…

→ MY QUESTIONS:

• What are the proofs of this sudden correction?
• Where is the paper of this possible research?
• Is your system original or modded?
• What is your display and which settings?
• Are you fine with these faulty dim colors?
  

→ MY DOUBTS:

• The difference looks too big and new to be true.
• The dimming looks flawed, not less inaccurate as expected.
• We won't edit millions of RGB conversions after a one-man decision.
• I remember my opposite experience here.

--_{d^⠚p^⠖l^⠃a^⠒.fr} 02:09, 13 September 2021 (UTC)

75% voltage (a linear value) corresponds to DN 192 of course, but that value was then PAL encoded and displayed on a CRT. That assumes a non-linear display gamma of 2.4. Today's displays are sRGB with gamma 2.2 (that's the web standard), so we need to change the values for proper display on Wikipedia. That's what I did, I simply gamma corrected the original value. Of course, I might have done a mistake somewhere. Feel free to apply a better correction or change it back, I'm not "territorial" about my contributions.

But one thing is certain, on an sRGB display the correct value won't be 192. Likewise the Spectrum's RGB primaries are BT.601 (PAL) and need to be converted to Rec.709 (sRGB) for accurate display. In practice the difference is minimal (ex: green will be something like 0,255,32 ), but mathematically it's there. So yes, all emulators are wrong unless you connect them to a PAL TV.

The point here is that Wikipedia is a web based, and web colors are sRGB (unless you use images with ICC profiles...)

Hope it helps 4throck (talk) 08:57, 14 September 2021 (UTC)

You are both using incorrect calculations.

If we assume the signal voltage amplitude of 85%, then on a PAL CRT with a gamma of 2.4, the luminance of the halfbright output color would be:

pow(0.85, 2.4) = 0.677 = 67.7%

When displaying on an sRGB-standard display, this would be a luminance with the index 215.

Therefore, (215, 215, 215) is the halfbright white.

Of course, this is all incorrect because it has to be recalculated to Rec.709 primaries, but they are somewhat close to PAL primaries, so the difference there is not large.

Also, there is an assumprion that the original Spectrum hardware is actually able to produce the output signal that fully saturates the output colors, and this assumption is also likely false.

So, the best way to get the actual colors is to connect an old Spectrum to an old PAL TV, and then to measure it with a colorimeter. 80.80.52.167 (talk) 07:06, 9 November 2023 (UTC)

Correction - if you redo the calculation with the 75% voltage value, then you get (188,188,188) as halfbright white. 80.80.52.167 (talk) 07:11, 9 November 2023 (UTC)

Since the currect article uses an obviously incorrect vaues, I'll edit it to the "205" in sRGB (#CDCDCD) as a compromise value.

To get actual values, you have to measure the Spectrum's output signal on an oscilloscope, find out the voltage of full-brights and half-brights, verify that it can produce fully saturated U-V chromacities, and then re-compute it to Rec. 709 primaries. Then, confirm all this with a colorimeter on a standard PAL TV. 80.80.52.167 (talk) 07:50, 9 November 2023 (UTC)

I recomputed it all to 81.4% voltage (0.529 V), which produces the half-bright at #CDCDCD (index 205) 80.80.52.167 (talk) 08:41, 9 November 2023 (UTC)

Under the assumption that some components of the ZX Spectrum hardware are performing their function perfectly, we can use the following computation to calculate the sRGB color values with the IEC 61966-2-1 primary colors:

---- Let's convert a bright green to the sRGB color primaries:

x = 0.29 (chromacity x of the green PAL phosphor)

y = 0.60 (chromacity y of the green PAL phosphor)

----- We have to set the CIE luminance Y value so that the brightest RGB component (green) equals 1:

Y = 1 / 1.415106666;

----- Now we compute the CIE 1931 X and Z coordinates:

X = Y/y × x = 0.34155258051

Z = Y/y × (1-x-y) = 0.12955442709

R_linear_sRGB = +3.2406 × X - 1.5372 × Y - 0.4986 × Z = -0.04403908

G_linear_sRGB = -0.9689 × X - 1.8758 × Y + 0.0415 × Z = 1.0

B_linear_sRGB = -0.9689 × X - 1.8758 × Y + 0.0415 × Z = 0.01180476

---- The R_linear_sRGB value is negative, so we clamp it to 0 (meaning that PAL BT.470 green color is outside the gamut of sRGB, so we select the nearest sRGB green color).

---- Finally, we apply the sRGB gamma compression OETF:

ZX Spectrum bright green in sRGB = (0, 255, 28) = #00FF1C

----- For half-bright green, we simply use the pow( (0.55 V / 0.65 V), 2.8) = 62.64% of linear values:

R_linear_sRGB = 0

G_linear_sRGB = 0.6264

B_linear_sRGB = 0.0073945

---- Again, we apply the gamma compression:

ZX Spectrum half-bright green in sRGB = (0, 207, 21) = #00CF15

---- Now, a bright blue to the sRGB color primaries:

x = 0.15 (chromacity x of the blue PAL phosphor)

y = 0.06 (chromacity y of the blue PAL phosphor)

Y = 1 / 13.85241667;

----- Applying the same computation, we get the sRGB of blue colors:

R_linear_sRGB = -0.0000433

G_linear_sRGB = -0.0000024

B_linear_sRGB = 1.0

ZX Spectrum full-bright blue in sRGB = (0, 0, 255) = #0000FF

ZX Spectrum half-bright blue in sRGB = (0, 0, 207) = #0000CF

----- Now, a bright red to the sRGB color primaries:

x = 0.64 (chromacity x of the red PAL phosphor)

y = 0.33 (chromacity y of the red PAL phosphor)

Y = 1 / 4.70227272;

R_linear_sRGB = 1.0

G_linear_sRGB = 0.00010504

B_linear_sRGB = 0.00002449

ZX Spectrum full-bright red in sRGB = (255, 0, 0) = #FF0000

ZX Spectrum half-bright red in sRGB = (207, 0, 0) = #CF0000

---- We conclude that only the PAL green phosphor is significantly out-of-gamut on sRGB displays.

---- Now we can add up the linear sRGB intensities to produce other colors:

ZX Spectrum full-bright magenta in sRGB = (255, 0, 255) = #FF00FF

ZX Spectrum half-bright magenta in sRGB = (207, 0, 207) = #CF00CF

ZX Spectrum full-bright cyan in sRGB = (28, 255, 255) = #1CFFFF

ZX Spectrum half-bright cyan in sRGB = (21, 207, 207) = #15CFCF

ZX Spectrum full-bright yellow in sRGB = (255, 255, 28) = #FFFF1C

ZX Spectrum half-bright yellow in sRGB = (255, 255, 21) = #CFCF15

----- DISCLAIMER: the entire above computation is valid only under the following assumptions:

- the ZX Spectrum hardware is supplying the built-in LM1889 color modulator with fully saturated R-Y and B-Y voltages (possibly true)

- the ZX Spectrum hardware is supplying the built-in LM1889 color modulator with proper and stable input reference voltages (likely false, especially because the LM1889 should be fed with the 15 V input instead of 12 V that ZX Spectrum provides)

- the cheap built-in LM1889 color modulator can actually perform correct color modulation (likely false)

- The built-in ASTEC UM1233 composite PAL coupler is not introducing any unwanted distortions (likely false)

Overall, the overwhelming likelyhood is that ZX Spectrum's colors are much more gray-ish (less saturated) than the values produced by the above computation. 80.80.52.167 (talk) 19:55, 9 November 2023 (UTC)

I have two copy-paste errors above, but all the computed values are correct:

G_linear_sRGB = -0.9689 * X + 1.8758 * Y + 0.0415 * Z;

B_linear_sRGB = +0.0557 * X - 0.2040 * Y + 1.0570 * Z;

The second error:

ZX Spectrum half-bright yellow in sRGB = (207, 207, 21) = #CFCF15 80.80.52.167 (talk) 20:03, 9 November 2023 (UTC)

I forgot the half-bright white. It computes to:

ZX Spectrum half-bright white in sRGB = (207, 207, 208) = #CFCFD0

Apparently, the difference in chromacity between the sRGB green filter and the PAL green phosphor is sufficient to increase the value of blue index to 208. 80.80.52.167 (talk) 20:20, 9 November 2023 (UTC)

I have found another small error in the computation above:

The linear sRGB values of simulated red, green and blue phosphors have to add up to the value of 1, so that the D65 white point is preserved. However, they do not add up exactly to 1, but very close. The problem is that I oversimplified the computation of CIE Y coordinate. Fortunately, the error is small and the above computation is more accurate than any previous computation. 80.80.52.167 (talk) 20:57, 9 November 2023 (UTC)

If I select the following CIE xyY coordinates to approximate the PAL bright green on sRGB, then I get a closer approximation than previously given:

x = 0.298194

y = 0.593493

Y = 0.7159

It computes to sRGB value (0,255,29) for bright green and (0,207,21) for half-bright green. But, then the bright blue should be (0,0,254) in order to add up to the exact D65 white point. Etc... Anyway, I think I'll levae a more accurate computation to others. 80.80.52.167 (talk) 21:59, 9 November 2023 (UTC)

Also, the sRGB standard doesn't use a gamma of 2.2 (or 2.4). Instead, it uses a composite transfer function, which is close to PAL gamma of 2.4. The standard sRGB composite transfer function was used in my recalculation to 81.4% voltage. 80.80.52.167 (talk) 09:22, 9 November 2023 (UTC)

I have just figured out that I'v got the gamma of analog PAL systems wrong (it's not 2.4). The relevant gamma value of analog PAL systems is given in ITU-R BT.470-6. The value of gamma exponent equals 2.8.

When recomputed to Spectrum's output voltage of 0.55 V = 0.84615%, it produces the sRGB index of 207 (#CFCFCF). I'm too tired to correct the article. 80.80.52.167 (talk) 11:03, 9 November 2023 (UTC)

The analog PAL standard (BT.470) is the relevant standard for all color computations on ZX Spectrum. It uses the same color primaries as BT.601 (digital PAL), but the transfer function is different in digital PAL. On analog PAL, the gamma equals 2.8. 80.80.52.167 (talk) 11:21, 9 November 2023 (UTC)

Well, at least the current value of #CDCDCD is much closer to the correct value #CFCFCF then what was given in the previous version of the article. 80.80.52.167 (talk) 11:37, 9 November 2023 (UTC)

You are correct about gamma 2.8. Keep in mind than you then have to reconvert the value to gamma 2.2 for sRGB... 4throck (talk) 13:26, 9 November 2023 (UTC)

No, the sRGB doesn't use gamma 2.2

Instead, it uses a complex transfer function. That function was applied.

The complex sRGB gamma transfer function is actually honored in most modern LCD displays. 80.80.52.167 (talk) 13:56, 9 November 2023 (UTC)

So, lets say you want to measure Spectrum's green color. You make the Spectrum produce an all-green screen. It will have a constant luma amplitude voltage, with a modulated color sub-carrier signal (a 4.3361875 MHz sine wave) added to it. You need to measure the amplitude of the color signal wave. Then, you also measure the phase-shift of that sine wave compared to the phase of the color-burst signal. That phase-shift will be different on the altentate lines of the signal ("PAL") by 180 degrees, so the actual phase shift must be calculated as the average of the phase shifts of two successive lines. 80.80.52.167 (talk) 15:04, 9 November 2023 (UTC)

More details: it is incorrect to refer to BT.709 standard in this article, because BT.709 is the standard for HDTV television. Instead, the relevant standard is sRGB (IEC 61966-2-1). The sRGB standard uses the same color primaries as the BT.709, which is the source of confusion.

To get actual sRGB values for ZX Spectrum, one needs to know the actual UV voltages that ZX Spectrum produces, where Umax = 0.463 V and Vmax = 0.615 V, according to the BT.470 analog PAL standard. Each of the Spectrum's 15 colors needs to be measured as UV voltages, and only from that data an accurate conversion to sRGB can be made. The values in the article are, obiously, only rough guesses, because Altwasser, the Spectrum's designer, couldn't have selected the chromacities of colors to match maximum values of the sRGB standard published 15 years later. 80.80.52.167 (talk) 13:53, 9 November 2023 (UTC)

I forgot to mention that the UV voltages are not directly measurable in the PAL TV signal. Instead, the UV voltages produce a phase-amplitude shift of the chroma sub-carrier, and that phase-aplitude-shift is measurable. From the phase-amplitude-shift, measured on an osciloscope, the UV voltages can be computed. 80.80.52.167 (talk) 14:20, 9 November 2023 (UTC)

I've updated the page to use the #CFCFCF value, as the best-approximation given the incomplete data (UV voltages or the aplitude-phase shift of the chroma sub-carrier is required for more accurate computation). 80.80.52.167 (talk) 15:54, 9 November 2023 (UTC)

I don't have any problems with your values. Your conversion method seems logical and well documented, and #CFCFCF seems to agree with empirical evidence. 4throck (talk) 10:38, 10 November 2023 (UTC)

Grammar error near start of "ULAplus" section

"If only used to slight modify" does not make sense. I'd change it myself but I'm not completely sure it should be changed to "slightly" or if it's trying to say something else.

It means "if changes to the original hardware palette colours are slight". With ULAplus you can redefine the hardware palette completely. For example, you can change Black to Orange. Viewing such graphics on original hardware would look bad, as the displayed colour wouldn't match in any way. But small changes, for example Yellow to Orange, or Blue to Teal, would still look good on original hardware. The displayed colours wouldn't be too far off. Feel free to make the original sentence clearer! 4throck (talk) 08:50, 23 June 2022 (UTC)