The huge gap is because of LibreOffice's vector graphics export |
The display hardware is basically what is drawn on the right. There are 32 latches, 2 lots of 16 for rows and columns, one latch for each row and column of the display, each composed of 4 lots of 4 bit latches* (because the interface is 4 bit)
Lighting a pixel on the display involves loading these latches with bit patterns. Any pixel which has its row latch set, and its column latch set, is lit (e.g. darkened as its an LCD display).
If you want to write something different on each row (and the row has at least one pixel on), then you have to fill these latches 16 times - one for each row, or if you prefer, one for each column - mentally it's probably easier to do it as a row by row, but there's no technical reason I can see why you can't do it column by column.
Lines that are empty don't need to have anything done to them, and lines that are duplicate can be done together (by setting the column bits to the pattern and one or more row bits).
The TMS1100 microprocessor does 50,000 instructions a second. The recommended refresh rate is 30-50Hz.
Let's say 30Hz as a workable rate, which means each frame is 1,667 cycles.
To do a full screen needs 16 write sessions, so that's about 100 each per line. Each of those lines requires 8 writes to the display, which gives you 12 or 13 instructions per write. This isn't a lot for a TMS1100 as its instructions are pretty basic.
This is probably the reason a lot of Microvision games only have the odd pixel displayed, or maybe a line or two. Connect Four I recall has a pretty full screen,but then it's not an action game.
Using an Intel 8021 gives you double the speed more or less automatically, plus it is a more powerful 8 bit processor.
But still, what would a challenge be if it wasn't a challenge. So I've decided to stick with the TMS1100 and put the i8021 code in abeyance unless I find it is just too slow. But I think it is doable. It was only about 30 minutes to convert it, and to make it useable won't take much longer.
One issue is I don't know how much you can bully it. I did some programming for TI Calculators and you could get a lot more out of those by ignoring the TI stuff and telling the LCD Driver to do things directly.
The LCD has this rather odd thing about "DC Build Up" which I don't fully understand yet. Every frame you "switch the polarity of the LCD" and if this isn't 50-50 then DC static builds up with presumably hilarious consequences. It says 'exactly' but this isn't possible. I'm a bit loathe to start torturing real Microvision hardware :)
* it's a bit more complicated than this but not much.
The DC build up is most likely an electrostatic charge present in or within the glass and liquid crystal of the display. This will tend to cause the liquid crystal to "permanently" polarize.
ReplyDeleteSince LCD components work best with a +/- voltage swing at a 50% duty cycle on each swing, DC build up is normally not an issue in most applications. The constant polarity reversal collapses any potential DC build-up that might occur.
I'm guessing that there were a lot of "shortcuts" taken when designing the LCD system (and physical display) of the Microvision in that the display itself is prone to DC build up if the polarity reversal isn't done fast enough.
Thanks for that :) I guess the duty cycle isn't too important as long as it is reasonably close.
ReplyDelete