Fixing the display location
Earlier, I had mentioned that the display was now in the wrong place, so I put some additional display patterns, notably some triangularish shapes on the left, and a huge cross going across the X and Y axis.
After a bit of fiddling with the vertical porch settings, I was able to get this:
The top and bottom lines aren't displayed, but I can live with the other 598 lines.
Hardware alerts
At some point in time, I'll need to create an alert which needs to overwrite the display. In order to be non-destructive, I decided that I would get the FPGA to optionally switch to the remaining 54 lines about mid-way down (there's 524,288 bytes of memory, of which the first 480,000 are currently used).
By plotting to these hidden lines, and flipping a switch (controlled in software), I could keep the display that would've been there updated without having to mask out the warning area. It would limit the amount of information available to me, but I'd prioritise it somehow.
This is how it looks:
The red is testing the plotting.
A new instruction defines the display settings:
- 0x18 - Set display settings
Only bit 0 of the byte is currently used - 0 means "normal display map", and 1 means show "55 line warning"
Preparing for fonts
While I won't have enough memory in the PicoBlaze to hold a font, I'd have enough memory in the controller to do it. However, to make optimal use of proportional width fonts, drawing the glyphs vertically would be better than doing it horizontally. Originally, the aim was to use the pixmap instruction, but that was for horizontal.
I extended the instruction set to include:
- 0x7V - Draw vertical pixmap (V + 1 bytes)
Bit 0 of byte 1 would be the current line, and then it plots downwards for the bits in the pixmap byte until there are no more bytes to be fetched.
A quick test of this was used to plot the white bits in the warning box:
Minor 7-segment change
I decided to add a parameter to the 7-segment display code to allow the unlit colour to be specified - previously it had been calculated based on a logical AND of the current colour. However, I wanted more control over it (the camera doesn't pick up the contrast, and it was sometimes a little difficult to see the difference between the lit and non-lit colours).
The green and red unlit LEDs look like they're off, but they're actually one shade darker.
More exciting fonts
Since I've got an 8-bit display, I could do anti-aliasing. With 3-bpp per colour (although only 2 for blue), this would theoretically allow me up to 8 shades (3bpp). Unfortunately, though, 3 doesn't divide into 8.
What I decided to do was have two additional vertical pixmap instructions. One is "plot in 2-bpp palette" (4 pixels per byte), the other is "plot in 4-bpp palette" (where you get two pixels per byte).
And, in order to set the palette, an additional instruction was added:
- 0x19 - Restore Y back to previous stored value and increment X
- 0x8V - Set palette colour V
- 0x9V - Draw 2-bpp vertical pixmap (V + 1 bytes)
- 0xAV - Draw 4-bpp vertical pixmap (V + 1 bytes)
Instruction 0x19 is basically the same as 0x17, except it works in the Y-axis instead.
These modes don't allow any transparency, so are designed to be plotted against a fixed background colour.
This brings the PicoBlaze memory usage to 71%.
The new band to the right of the previous test is a test of the 2-bpp plotting, using the 4 grey-shades in the palette, and the band further to the right of that is a test of the 4-bpp plotting, with a mathematically calculated palette.
Now all I need is to generate some fonts...