40 col x 18 row VGA ROM Font Driver
localroger
Posts: 3,452
OK, the bad news about this VGA driver is it needs 3 cogs. The good news is, that's the only bad news! Since it uses the ROM font the whole driver uses only 757 longs of Hub RAM, and that's without trying to reclaim the PASM images. And it plugs a big gap in Prop VGA driverland between the 1-cog 32x13 ROM font driver and the lowest resolution 80x40 Hires driver.
In addition to getting lots of pretty characters on the screen, it has actual features too:
UPDATE: I have replaced the demo with a new version that adds functionality at the _text level for including user defined characters in constant strings, added some constants for the various control functions, and rewritten the demo to use these features. The result is more verbose but it's much easier to tell what's going on.
How it works:
There are a raster cog which draws the display and two helper cogs, one for odd lines and one for even lines, which interpret the tile data and convert it to raw pixel data for the raster cog's waitvid. 600 x 800 timing is used with a 32 MHz clock, which gives 640 horizontal pixels and thus 40 16-pixel characters. At 80 MHz, the number of spare clock cycles in the inner tile loop is ... drumroll please ... ZERO. Adjusting the timing for 43 characters across caused it to start to miss waitvids.
I had thought of unrolling the inner loop to see if I could get it rolling at 1024x768, but it looks like I won't need to bother. In each of the helper cogs the inner loop requires 3 hub operations -- read the tile, read the pixel data, and write the pixel data to the line buffer for the raster cog to read. At this timing, the number of extra instructions I can accommodate in there is ... wait for it ... ZERO. Actually I could put a couple of NOPs before the DJNZ, but it's hard for them to accomplish anything there.
Since the raster can only do one read per waitvid it can't fetch color information. Colors are generated by the helpers, which shift the appropriate interleaved ROM character into position, mask it off, and then invert or shift it to the alternate bit position to generate a second color or reverse video. The helpers also take care of loading from the user character set instead of the ROM if appropriate. The raster does read a new color long for each line.
In addition to getting lots of pretty characters on the screen, it has actual features too:
- Within a line each character can be normal or alternate colored, and normal or reverse video
- Each line can have its own 3-color palette
- Up to 512 16x16 pixel user defined characters can be created and mixed with ROM font
- The driver is written through VGA_text interface, so if you've used VGA_text or TV_text for a project this should almost drop right in, with a little jiggering of the color scheme.
UPDATE: I have replaced the demo with a new version that adds functionality at the _text level for including user defined characters in constant strings, added some constants for the various control functions, and rewritten the demo to use these features. The result is more verbose but it's much easier to tell what's going on.
How it works:
There are a raster cog which draws the display and two helper cogs, one for odd lines and one for even lines, which interpret the tile data and convert it to raw pixel data for the raster cog's waitvid. 600 x 800 timing is used with a 32 MHz clock, which gives 640 horizontal pixels and thus 40 16-pixel characters. At 80 MHz, the number of spare clock cycles in the inner tile loop is ... drumroll please ... ZERO. Adjusting the timing for 43 characters across caused it to start to miss waitvids.
I had thought of unrolling the inner loop to see if I could get it rolling at 1024x768, but it looks like I won't need to bother. In each of the helper cogs the inner loop requires 3 hub operations -- read the tile, read the pixel data, and write the pixel data to the line buffer for the raster cog to read. At this timing, the number of extra instructions I can accommodate in there is ... wait for it ... ZERO. Actually I could put a couple of NOPs before the DJNZ, but it's hard for them to accomplish anything there.
Since the raster can only do one read per waitvid it can't fetch color information. Colors are generated by the helpers, which shift the appropriate interleaved ROM character into position, mask it off, and then invert or shift it to the alternate bit position to generate a second color or reverse video. The helpers also take care of loading from the user character set instead of the ROM if appropriate. The raster does read a new color long for each line.
Comments
Note that I didn't bother to update all comments re: resolution change. It was more about whether it could be done.