ZX Spectrum graphics specifications

[1024MAK]

Well, shows what a good idea it is, even if my thoughts have turned out not to be original

Mark

[Bubu]

And the thing is, do you think that if Sinclair put more colors instead of the bright and flash attributes, would have been increased the cost?
or the cost would have been minimal?

[1024MAK]

Yes, the cost would have been higher. Which would be why Sinclair would not have done it.

This statement assumes that there is insufficient spare capacity in the ULA, and / or, it is not practical to generate sufficiently fine analogue voltages for 32 colours within the ULA (which remember is only supposed to handle digital logic signals).

If either of the above is true, a separate chip would be needed to provide the keyboard input lines (say a 74LS365) to free up some ULA pins. Then replace the LM1889 colour encoder chip with the TEA2000 (as used in the 128K) or something similar.

I don’t know the relative cost of the LM1889 and the TEA2000. But I don’t think the cost of these changes would have increased the selling price by more than £10.

Mark

[Einar Saukas]

Using the bits unevenly gives you a higher max colours on screen, but at the cost of being more tricky to use. If you look at the composition of Speccy loading screens, it's pretty common for edges of a single "colour" area to use PAPER or INK bits depending on adjacent areas. Not so easy to do when only a handful of colours are available for the PAPER parts.

It's certainly trickier for artistic images like loading screens. Although we already have a limitation on the colors you can combine in the same character (you cannot use bright and non-bright together), so that's not much different.

However in-game graphics is a different matter. A lot of games use a single predominant background color (usually black). A larger variety of INK colors would benefit them a lot more than PAPER.

[Sol_HSA]

A larger variety of INK colors would benefit them a lot more than PAPER.

Sigh, I guess I'll have to write a converter to this hypothetical graphics mode just to see the results...

[1024MAK]

There is a case for maybe the paper colour being selected via a simple palette register. But this would have, IMHO, most likely have increased the complexity of the ULA so much, that two ULAs would have been required. This would have significantly increased the cost…

I think that the use of five bits (hence 32 colours) for the ink colour and three bits for the paper (the existing eight colours) is the best compromise without significantly increasing the cost.

If a higher priced model was intended, then I think increasing the colour resolution would be a better area to spend the money on, something like the Timex video mode.

Mark

[Einar Saukas]

Sigh, I guess I'll have to write a converter to this hypothetical graphics mode just to see the results...

If you are serious about it, then you will need names for these graphics modes so you can refer to them.

In this image you can refer to the top 16 colors as ZEN16A, and the brighter 16 colors at the bottom as ZEN16B.

In this image the top half is ZEN32A and the brighter bottom half is ZEN32B.

And in this image it's simply ZEN27, without a brighter variation.

[Einar Saukas]

BTW to make it easier for Spectrum users to use these new colors, I would always keep the same numbers 0..7 for the original colors.

In ZEN16A and ZEN16B, simply add 8 to each number to get the closest new color. Like this:



The criteria for closest new color is clear in this new image:

[Einar Saukas]

... and I just noticed I inverted black and dark gray in the last image, here's the correct one:

[Joefish]

The trouble with colours selected by hue is that they don't easily translate into discrete logic. The C64 and MSX had that sort of colour system, but then they had custom graphics chips which cost more.
The Amstrad style palette with 3 levels per R,G,B component gives you 3 x 3 x 3 = 27 colours (including one grey), but now dividing the colour number by 3s to work out the RGB levels isn't quite so simple in discrete logic; you again more realistically end up with a look-up table.

This was my simple 5-bit colour palette, designed for implementation in discrete logic. It uses 2 bits each for the Red and Green components, and one bit for Blue. (Similar to the thinking behind the '8-bit RGB' palette, which has 3 bits for Red and Green and 2 for Blue). I'll admit it doesn't have any specific greys, only tinted blue-grey, but it can be achieved with literally five hi/lo discrete outputs, and a few diodes and resistors to combine the pairs of R bits and G bits.

The Spectrum's original 8 colours are still there, in the four corners of the two square palettes below.

[Joefish]

This is taking a similar logical approach to a 4-Bit palette. This just uses the extra bit to give you a 2-bit Green register and 1-bit Red and Blue. this is the "4Bit-G" palette:



On the plus side, nice shades of green and cyan-blue for sea and sky landscapes, and two oranges!
On the negative side, overdoes it on the pinks and no grey. But at least, again, the colours can be formed from resistors and diodes on logic output lines. You might even be able to get something similar out of the existing circuitry, if you could somehow just apply the BRIGHT bit to the Green line, and force the Blue and Red lines to BRIGHT all the time. Except it would still affect both INK and PAPER at the same time...

[catmeows]

Fun fact - french Thomson MO5 also uses 4 bit palette but it is rather saturationRGB than intensityRGB. Second stage of video is small fast PROM that maps 4bits to 6bit RGB. Since saturated black and white doesn't make sense, they are mapped to 50% gray and orange.

[Sol_HSA]

Okay, at this point the slowest bit of progress for me is typing in the potential target palettes.. here's partial results, I haven't done any 3:5 things yet, but let's roll anyway.

First off, reference.


That's four 256x256 images. I picked some random things one might want to display on a computer screen. Maybe.

ULA:


I go through the whole image, 8x8 tile at a time, finding the ink/paper/bright combo for each that yields the smallest error, and go with that.

ULA with 2 bright bits:

Here instead of having the bright bit toggle each 8x8 tile can have two colors from the full 16 color palette.

zen16a:

Same as ula2bb with the zen16a palette.

zen16b:

..and the zen16b palette.

I do realize that these are just random test images instead of an artist actually planning things, so the results might not be ideal. I'm also not ruling out bugs in the converter.

[Sol_HSA]

Here's the three 8/32 palette versions. It's pretty clear the greys yield the smallest error in these images and thus things get a bit monochrome.

zen32a:


zen32b:


zen27:

[Sol_HSA]

And here's the inevitable heresy one.



(2 colors from palette of 16 colors per 8x8 tile)

If there's some other palettes you want me to try, feel free to poke me.

[AndyC]

How are you calculating error? It seems odd that the wider the palette available the more and more it seems to deviate towards the middle grey.

[Sol_HSA]

How are you calculating error? It seems odd that the wider the palette available the more and more it seems to deviate towards the middle grey.

Sum of squared difference per channel. So something like:

Code: Select all

err = (ra-rb)*(ra-rb) + (ga-gb)*(ga-gb) + (ba-bb)*(ba-bb)

[Joefish]

Please could you try that '4Bit-G' palette I posted? 16 colours where Green is two bits, Red and Blue only one.

There aren't a lot of saturated colours in those test images though. I'm not surprised a modern PC RPG just turns everything into greys!
The Wikipedia page on palettes uses an image with a bit more colour to it. If we want to display landscapes then that's a whole different approach. I'd suggest any of this is more suited to the top-end arcade games of the time or comic book style images.
https://en.wikipedia.org/wiki/List_of_color_palettes

[Sol_HSA]

Okay, here's a set of more colorful images..

ref:


ula:


ula2bb:


zen16a:


zen16b:


zen32a:


zen32b:


zen27:


heresy:

[AndyC]

Sum of squared difference per channel. So something like:

Code: Select all

err = (ra-rb)*(ra-rb) + (ga-gb)*(ga-gb) + (ba-bb)*(ba-bb)

Yeah, I suspect that doesn't work well in RGB space when you have big gaps in the colour space. Everything just tends towards grey because it's numerically average even though it doesn't work that way from a visual perception view. It might be better to convert RGB to something like HSL first and try it with that.

[1024MAK]

The trouble with this, is that without a human artistic input, the resulting image/picture will always be dominated by the low attribute resolution.

A human graphic artist would be able to slightly move things around to have as many colour changes on the edge of each attribute cell.

Plus would maybe use other tricks, such as stippling.

The point of having a bigger selection of available colours, is that more realistic colours can be used rather than having to be severely restricted to only eight (or 15 if bright is used).

Try using some existing Speecy pictures and recolouring with the different colours.

Mark