How does the PMD 85 display colour or greyscales?

Question

I stumbled across this computer in an article on hackaday, Home computers behind the Iron Curtain and since it has this bizarre resolution, I looked closer into it.

Some claims from Wikipedia:

• 288×256 resolution
• 4-level attribute (flickering, grayscale or colours, depending on model), selectable per 6-pixel-wide stripes

I found these numbers rather strange so I tried to work out what was happening here. I managed to track down this memory map. According to this graphic, memory is laid out 48 bytes to a scanline, and scanlines are 64 bytes apart, so that there are 16 bytes' space available to the user, between those scanlines.

48 bytes equal 384 bits, but if each byte has 6 pixels, that could explain where the horizontal resolution of 288 pixels comes from, and neatly coincides with the 6-pixel wide stripes that share an attribute. Now, this is all speculation, so I'd appreciate if anyone can confirm this.

So my question is how each byte is decoded. Those two left-over bits presumably encode an attribute of sorts, but that doesn't seem nearly enough to enable reasonable colour graphics.

Answer 1

Well, original PMD85 was greyscale, so SECAM does not come into the picture (pun intended).

The lower 6 bits display as pixels, and these are stored back-to-front. The upper two bits encode an attribute - originally flash (bit 7) and low intensity (bit 6), but in PMD 85-3 this was reinterpreted as 4 level greyscale, or these 4 colours if using an RGB output:

• 00 - Green
• 01 - Red
• 10 - Blue
• 11 - Magenta

See this link (in Slovak) for more information.

Answer 2

Keep in mind, my speculations are based on my knowledge of how the Apple II works.

Which is, graphics wise, a total different beast than any other computer on this planet. It's basically analogue display digital encoded.

It's not NTSC. Czechoslovakia used SECAM at that time.

Which only affects colour, which in turn wasn't used at all, so it's all about a classic European 50 Hz B&W picture.

48 bytes equal 384 bits, but if each byte has 6 pixels, that could explain where the horizontal resolution of 288 pixels comes from, and neatly coincides with the 6-pixel wide stripes that share an attribute. Now, this is all speculation, so I'd appreciate if anyone can confirm this.

Exactly that way it is. Each byte holds six on/off pixels plus two used for attributes. In grayscale mode it did set the intensity for these 6 pixels.

memory is laid out 48 bytes to a scanline, and scanlines are 64 bytes apart,

That very much simplifies the design for the counters for a scan line length. All that's needed is a 6 bit counter, which is used generate the lower 6 bits of screen address, as long as its top bits are not 11. Feeding this counter with half the CPU clock (2,048 MHz) produced a line length of 64 µs, exactly (*1) what a line should be, while the output carrying part will be 48µs, so close and well within the allowed 52 µs (*2)

Similarly, the 256 lines are a way for needing only a single 8 bit line counter providing the address, and its carry as 'end of field' marker. An 8 bit line counter plus a 6 bit pixel (group) counter can now easily provide a 14 bit memory address. All what's needed to finalize is another counter (maybe even an analogue circuit) to define picture length.

so that there are 16 bytes' space available to the user, between those scanlines.

Yup, much like the screen holes on the Apple II. After all, video logic is here formed around the TV signal (just as in many machines). Just not as special as with the Apple.

So my question is how each byte is decoded. Those two left-over bits presumably encode an attribute of sorts, but that doesn't seem nearly enough to enable reasonable colour graphics.

Sure it does. It allows to either select two on/off attributes, or one with four values. On a colour output this can be used to give one colour to each switched on bit within that byte, and another to the next. Effectively giving 4 colours plus black on screen. So it's a bit like the restriction the Apple II got - just less weird.

Restricting colour to character positions has always been a common trick - just think C64 - here it's narrowed down to on colour selection per 6 horizontal pixel.

---

*1 - Well, it's a tiny bit less, but way within the tolerances defined.

*2 - Using the whole line width would have allowed 312 pixels to be shown, but now the 'comparator' would have been more complex than a simple 1/4 7400.

Answer 3

Each byte is 2 bits of attributes and 6 bits of pixels.

• Bit 7: 1 = Flashing
• Bit 6: 1 = Lower brightness (or "darkness" if you want so)
• Bit 5: "Leftmost" pixel (1 = white, 0 = black)
• ...
• Bit 0: "Rightmost" pixel

PMD-85 version 3 has four levels of brightness instead (on a black paper): 00 is the most bright white, 11 is dark grey. There was a possibility to use an RGB output with green (00), red (01), blue (10) and magenta (11) color.

And that 16-bytes stripes of unused memory were often used for short routines, usable from BASIC-G too.

Disclaimer: I am the author of the article mentioned in the question.