Operator Interface Panel demonstration
Channel: Simon Brattel
Date: 2012-04-27

Just a very shaky video of an operator interface panel I designed back in 2005, filmed on a mobile phone.

Uses a 200MHz ARM (not 300MHz as I thought when I was filming this) - an early Cirrus single-chip device (EP9315) with the video display and serial ports, etc on the device.

The software doesn't use any video acceleration hardware. It's just straightforward C, compiled with GCC - all the software, OS, demo and the actual application code (that isn't shown here) was written by me over about a week - it was a rush job for a demo. 

The display there was 800 by 600 pixels running in 256 colour mode, and all the construction lines drawn when I'm playing with it are just debugging aids I was using when testing the windowing system, they show the individual rectangles that the windowing software has chosen to use when drawing the screen.

Watching this I've noticed that there are a couple of visible flickers as debugging windows get thrown up in the background for a frame and then removed, those aren't glitches - the thing is moving perfectly smoothly and redrawing everything at frame-rate. It's a pity that this video can't show just how nice that looks in reality.

Actually, that demo wasn't even pushing the thing very hard, it's only moving a few windows there and a later demo had it drawing several dozens at frame-rate. It's not obvious from the poor video but all the windows there are doing something. The 'active wallpaper' in the background is slowly rendering a Mandelbrot - slowly by design - as is a huge window that drifts across, and the small ones are having characters rendered onto them at different rates. It all looks very nice in real life, and the code isn't even particularly optimal, other than being written cleanly and without stupid overheads; there's no assembler in it at all and the compiler makes a real mess of some things that would be easily fixed. With graphics code and especially windowed display systems there are usually a handful of simple routines (drawing characters, copy and align a rectangular area of pixels onto the display, as examples) that get used very often. I'd normally spend a few minutes doing those properly in assembler, but here I couldn't even be bothered. The OS and windows system was already far faster - as you can see - than the application required.

Anyway, this should give people an idea what you can do with an ARM when it's not crippled by having to run vast masses of pointless and incompetent software... and don't forget that cheap modern ARM devices run 6 times faster than this one did, have multiple cores, and much higher memory bandwidth. And that's ignoring the video acceleration hardware most of them have... There's just no excuse for slow jerky displays these days. There's no excuse for windows systems that aren't frame-locked and capable of soft-scrolling everything. It's just incompetent programming.

Amuses me that the device I used to film it is a (very) distant relative of the thing...