Computing Start‑class Mid‑importance

This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles Start This article has been rated as Start-class on Wikipedia's content assessment scale. Mid This article has been rated as Mid-importance on the project's importance scale.

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)[reply]

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)[reply]

• 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)[reply]

• 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)[reply]

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)[reply]

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[reply]

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[reply]

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[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

"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)[reply]