Hi !
As i was a games programmer long time ago, progging assembler code on 6502 Systems and later on 68000 CPU's on machines that didn't have 24 Bit graphics, i remember one dirty trick to get more shades of gray out of the display that might work with the empeg too ...

The trick is to flip between 2 displays so fast, that you mix pixel brightnesses visually:

So now we have brighness levels of 0, 1, 2, 3.
If we paint one pixel with 1 and paint it with 2 shortly afterward and then with 1 again -> 1 -> 2 -> 1 -> 2 -> ....
The human eye will se a brightness of 1.5 !!!
So if you want to display a picture containing 8 gray scales you basically flip between two 4 grayscale pictures very fast and ... voila ! it looks good if you flip fast enough ...

The question is, what is the "refresh" rate for the plasma display, and is there an interrupt telling you when it is finished ??
(Or is ther no real refresh rate, so we could use a timer interrupt of ... hmmm ... 50 Hz or so to flip between the images )

Someone of you that played around with displaying bitmaps on the empeg could alter the software to flip between 2 pictures as fast as possible, and tell us about the result ...
This mechanism could be implemented for all screen display functions, upgrading the display to 8 shades of gray, which would vastly improve graphics ...


Any opinions ??

Nils


If the display allows it, speed shouldnt be an issue, i did that in a raster interrupt on those crappy cpu's mentioned above ...

The technique you refer to is known as "time dithering", and Toby's visuals already do this. Watch them closely, especially the ones that leave gray "trails" like Funnelweb.

Until Hugo mentioned it to me, I hadn't noticed it, either, but there it is.

___________
Tony Fabris

A better way to notice the time dithering: Hit "Pause" on the "Tripping Prisoner 256" visual...

___________
Tony Fabris

remember one dirty trick to get more shades of gray out of the display that might work with the empeg too ...

Tricks are nice. However, I think this is atleast partially already in use. I belive the display is refreshed around 200Hz and I guess the brightness levels 1 and 2 (out of 0, 1, 2 and 3) are generated by having the pixel on only 50Hz or 100Hz, instead of the full 200Hz (brightness level 3) refresh rate.

If you have any moving scroll text or similar on the screen, you'll quickly notice that brightness level 1 and 2 are not good for anything that moves fast, because the refresh rate for those levels seem to be too low for fast moving areas. Though, they work perfectly on static or slowly moving image. I guess it would be possible to add even more brightness levels but I think they only could be used on static images.

One other way for achieving more brightness levels could be some sort of dithering patterns which might change every frame. But that falls more into the visualization/effect category and therefore wouldn't produce any additional grayscales that could be used on general level.

Kim

Hmm interesting ...
anyone of empeg ltd that could clear things up ??

( Maybe it would be possible to change things a bit, so that the two shades are more like 33% and 66%, and not both very dark and hard to see the difference between them ...

Nils

The VFD on the empeg is refreshed at a very high rate, I believe as you say currently about 200Hz. However, it has zero phosphor persistence.

The grey scales from the SA1100 LCD port are produced by time-domain multiplexing, which produces 16 possible levels, ranging from a pixel being on for no time (black), to being on 100% of the time (white). Mid-level grey is produced by turning the pixel on for 8/16ths of the time, and off for the rest,
a much dimmer grey is on for 1/16th, off for 15/16ths, and so on. This is all done in hardware.

The effective result is that shades other than black or white are done by turning a pixel on for n out of 16 frames, and off for m out of 16 frames, where n + m = 16. This means that you wouldn't get very pleasing (or effective) results if you also frame-multiplexed different grey-scales.

The real problem is as I mentioned earlier, the VFD's lack of any real persistence. A CRT, and most mono (usually passive-matrix) LCDs, have a relatively long persistence, which allows a TDM scheme like this to produce convincing grey scales. Unfortunately, no persistence equals horrible flicker for most of the potentially available grey levels. Only black, white, and two intermediate shades were deemed suitable for public viewing, and that only due to the very high refresh rate. Most of the rest are good epilepsy-inducers, but not very viewable. Moving graphics look even worse!

This sort of problem is not limited to VFD technology. Plasma panels, particularly the older ones used for things like the old Compaq and Toshiba luggables, were awful for it. I've run some old EGA grey-scale programs on an old Compaq I have, and anything other than black or white gives you a headache almost instantly.

Incidentally, I devised a circuit for driving those old plasma panels from a normal VGA card, and in theory it would be possible to run one from an empeg, giving a 640x400 bright orange screen! It would need a lot of work rewriting the display drivers, at the very least, but perhaps a future project?

(I managed to get X driving one of the things, and since each is only one bit, 8 in parallel can be driven from one VGA card. I and a friend are planning on constructing a completely digital dashboard for our incredibly ugly kit car using 4 displays for the instruments, one larger one with a touch screen for the controls, and a final one for a HUD.)

Opinions expressed in this email may contain up to 42% water by weight, and are mine. All mine.

Ah thx for the info, so it IS already implemented where it belongs -> In the Hardware ...
So if i got you right, it *has* 16 levels, but to minimize flicker, we only use 4 of them ??
Maybe then at least someone at empeg should check if there are to other gray values that still don't flicker too much yet come closer to a visual perception of 33% white and 66% white than the chosen ones ...
Don't know if its possible though ...

Nils

It's hard - we did check all the levels out originally, but when John tried it again recently we did find another greylevel which looked ok (I suspect last time we tried it, it was pretty early on in the process and we were running the screen slower).

If we get another grey, you'll know :)

Hugo

I'll let the code clear up some confusion here:

	/* We only have 4 shades, including black & white. This isn't
	   strictly true as the SA1100 provides 14 greyshades on a LCD
	   display, but due to the low persistence of the VFD pixels,
	   other shades tend to be very very flickery and not very
	   effective. They could be used for trippy special effects, I
	   suppose... */
	
	static short palettes[][16]= {
		/* All-black */
		{  0, 0, 0, 0,  0, 0, 0, 0,  0, 0, 0, 0,  0, 0, 0, 0 },
		
		/* Special palette to support Toby's code */
		{  0, 1, 2, 15, 0, 1, 2, 15, 0, 1, 2, 15, 0, 1, 2, 15 },

		/* Standard palette */
		{  0, 0, 0, 0,  1, 1, 1, 1,  2, 2, 2, 2, 15,15,15,15 },
		
		/* One-to-one mapping */
		{  0, 1, 2, 3,  4, 5, 6, 7,  8, 9,10,11, 12,13,14,15 },

	};

If we get another grey, you'll know :)

Cool!

If you do, may I suggest that user-created bootup logos that wish to use this new shade should have a different tag header at the beginning. i.e., the current "empg" for a four-shade logo, "emp5" for a five-shade logo, etc.

That way, existing software would continue to work, and new kernels applied atop existing logos would still display existing logos correctly.

___________
Tony Fabris

To clear up any confusion about the number of colours available on the empeg display:

The Strongarm 1100 includes an LCD controller that the empeg makes use of. This basically allows a pixel to be strobed in hardware to emulate a shade of the constantly on intensity. The chip is actually quite clever and will look at the values of neighbouring pixels in order to determine the required strobe value for a pixel.

The empeg uses four of the hardware strobe rates to emulate the shades used on the display. These are as follows:

Pixel Value........Intensity..............Modulation Rate

0..................0%.....................0
1..................11.1%..................1/9
2..................20%....................1/5
3..................100%...................1

This provides us with a 2bpp palette, although a 4bpp palette with 16 shades is possible with the Strongarm. The 4bpp palette was dropped very early on in prototyping as it was found that the VFD (vacuum flourescent display) had very short persistence and therefore that the increased number of shades was both inneffective, and caused a dot crawl effect on animating an image using many shades.

The Prolux software incorporates a technique known as time dithering which increases the colour range over a period of time by calculating probabilities from the hardware intensity of a pixel value of whether a pixel should increase in value by 1 for a particular frame. I expand the palette to 8bpp when incorporating time dithering and thus 254 intensity levels (plus off and full intensity). The screen buffer is drawn approx every 38th of a second, and each frame drawn is drawn at 2bpp, so the effect can only be noticed over a number of frames.

Time dithering does however reduce the integrity of an image, and it is therefore preferable to stick to the 2bpp palette where possible, particularly when dealing with detailed images such as bitmaps, or where an image is moved around the screen.

Hope this clears up some of the confusion - Happy to answer any further questions on the topic, or any other empeg visuals/display related topic.

Toby

Hi Toby.. One thing... To me at least, the gray shades look almost exactly alike. Why were 11.1% and 20% chosen as the intensities for the gray shades? I can hardly see any difference between these two shades, in fact, the only way I could see them was to pause the "Grampian" visual to see them side by side. It just seems to me that this is not enough variance to offer any detectable difference, so it's like having only 3 "colors" for the visuals. Why not have color 01 be 11% (1/9) and color 10 be 33% (1/3)? I'm sure there's a technical reason, like 1/3 would look too close to 1/1, but it just looks like the two grays are almost identical, yet the "always on" brightness is much brighter than both of them. Anyone else have any opinions on this? It sound picky but I think more distinct shades would result in better looking visuals...


---
MkII 080000554

To me at least, the gray shades look almost exactly alike. Why were 11.1% and 20% chosen as the intensities for the gray shades?

I think that Hugo said that those shades were chosen because they were the least "flickery" shades on the VFD display.

As I understand it, it's possible to program your own shades if you're writing your own software for the unit. So if, for example, you wanted to code up your own movie-player applet, you could do it and be in control of the palette yourself. Then you could make your own choices as to what was "too flickery" or not.

___________
Tony Fabris

The number of shades available on the VFD is determined by a combination of the rate at which it is refreshed and the persistence of the cells. The display is refreshed at around 200Hz, and this should be more than adequate to dither cells over time to increase the number of perceived shades. Each cell is either on or off, and the persistence of each VFD cell is such that dithering over time is only effective for darker shades. We found in early prototypes that there was little difference between cell shades except at the lower end of the brightness scale, and that for moving images a large number of shades made it appear flickery.

We are still playing with different pixel timings and find that on a 16 shade kernel, only the lower shades are noticably different, and there is therefore little point in using more shades than the current 3.

Thanks for the very detailed explanation. I was certain you had already found the best timings, but was curious as to the details. I'm sure you'll have a lot more fun with the visuals if the Mark III has a TFT screen. :)

---
MkII 080000554

OK! but maybe it would be great for static or almost static purpose... like the GPS 3rd part project (for maps display), bootup logos, and also for better text fonts...
And with the coloured screens, the flickering should be less noticable...




__________________________

David Clesse
Belgium/Luxembourg
Mk2-36g(full)-red-tuner-stick

Hi David.

Map displaying (if you are talking about street maps) is virtually useless on a 128x32 display like the empeg. And any other display that might be interesting in combination with the GPS/nav project, even just 2 shades (dark/bright) would be enough.
Regarding bootup logos, this might be interesting however.
Text fonts won't get any better if you used more shades, what would you expect from that? Anti-aliasing? That would only make them more unreadable, given the low resolution of the display.

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Of course dear Sven,
but (this is just a suggestion for your wonderful kicking-ass projet) for example, if you split the screen in 2(2x64x32) or 3 parts: 1st 32x32 for left infos (way,arrow...), 64x32 for a small but not useless map (normal or 3d suggestive view ;-), and 32x32 right infos (speed, time, compass...), it could be nice.
Or we could have an optional virtual screen map able to scroll w/ the knob/stalk or st like that...
For the text stuff, yes a-a of course! I remember on my old CPC464 w/ green screen, once a text was a-aed, it looks very much nicer with a dpi resolution lesser than the empeg! It's obvious with the 4 gs a-a small empeg logo during bootup.
An other use: if you wanna put a real (b/w) picture on the VFD; it's impossible with only 4 greyscales.
I'd like to help you for your project, but i'm not used w/ linux; maybe in a couple of month...

regards.

__________________________

David Clesse
Belgium/Luxembourg
Mk2-36g(full)-red-tuner-stick

Have you already some pics, screen captures or schemes of your GPS project? It could be nice to post them

__________________________

David Clesse
Belgium/Luxembourg
Mk2-36g(full)-red-tuner-stick

I will post them as soon as they are ready.
(Sounds familiar?)

Ok, kidding aside: I have an almost completely free week next week, and besides one other (comparably small) project, this is dedicated to get the nav project really going. Stay tuned.
To help, you will probably only need to know C/C++, I am almost certain that the OS layer will be completely hidden by a nice API (that still needs to get finished though).

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

It could be ok. I have been used with Java for 4 years now, but I learned & did some borland C before, So feel free to contact me!
(mailto: [email protected])

__________________________

David Clesse
Belgium/Luxembourg
Mk2-36g(full)-red-tuner-stick

Could you -or somedy else able to do it- a little 16 grey scales demo? (just a static image)
This way maybe you can give REAL COLORS to the empeg: after 2 or 3 minutes watching a psychedelic bad flickering monochrom screen, you have a chance to see pink elephants or flying blue cows I think ;-)

No, without kidding, just to see how it looks like. Personnaly, I prefer a flickering color than a dithered one for static pics, and 4 scales is definitely not enough for pictures...

But with 16 colors, you would still have to dither. So you'd have flickering as well as dithering.

Hi Tony,
(Do you sleep sometimes?)
yes of course, but I also prefer (a lot) a 16 colors non-dithered pic than a 4 colors dithered one. don't you? ...and each acceptable color we can win is welcome I think.