more chars with VGA_Text.spin?
Martin Hodge
Posts: 1,246
Is VGA_Text.spin capable of producing more characters on screen than 32x15? Most importantly more than 32 cols?
Comments
If you want to speed up the VGA clock you must use another cog to fetch the pixel lines so that the cog drawing the raster doesn't need to do multiple Hub reads for each character. This will get you to 40 horizontal columns.
There's not much you can do about the 15 lines except throw away some of the ROM font lines, which tends to look awful.
There are also the Hirez drivers (which are included with the proptool and in the obex) which provide much higher text density using two clogs, a smaller custom font, and a very clever back and forth cooperation as one cog draws while the other prepares for drawing the upcoming line. These drivers don't provide for setting the individual character colors, but you can set different color combinations for each line. Again, there's just no time to set a different value for the colors parameter in the time it takes to draw a character.
Dr_Acula, that is the hirez driver. The original version is VGA_HiRes_Text.spin which is in the Propeller Tool Library. The same driver can, by un-commenting the appropriate parameter block, do:
' 1024 x 768 @ 57Hz settings: 128 x 64 characters
' 800 x 600 @ 75Hz settings: 100 x 50 characters
' 640 x 480 @ 69Hz settings: 80 x 40 characters
It's unfortunate that there isn't much to bridge the gap between VGA_Text at 32 x 15, and the lowest resolution of the Hirez at 80 x 40. I spent January writing a 3-cog driver but it's actually even lower resolution than VGA_Text, because it provides for half- and double-high ROM font characters and two styles, high and low resolution, of user defined character tiles. All that logic requires two cogs pre-processing the odd and even lines while a third draws the raster. But it is very frugal with memory while giving the versatility I need for certain projects.
That's what I was looking for unfortunately. Thank you for the valuable information, it's one more piece to the puzzle for me.
This got me looking back at the timing. The problem is that any inner loop that has to do two Hub reads takes a minimum of 47 clocks. Since the Hub isn't synchronous with the VGA raster you have to assume 22 clocks for the first read, you get two instructions free and then 16 for the next. Then you need the waitvid (5) and djnz (4). And that's assuming no other logic such as incrementing pointers.
At 25 MHz (the dot clock rate for 640x480 VGA) a 16-pixel waitvid block takes 51 cycles, so it would be just barely possible to write a driver using a helper cog to stuff the pixel and color buffers to get full resolution of 40 horizontal characters. To do it in 1 cog Chip had to drop the resolution a bit to get the pixel clock down to 21 MHz so he could cram a couple more instructions in there.
For 800x600, which would give 50 characters by 18 rows, the dot clock is 36 MHz. That gives you 35 clocks to set up 16 pixels. Even if you do only one Hub read, that's 22 clocks, then 5 for waitvid and 4 for the djnz or 31. So it might just barely be possible to do a single hub read loop with helper cogs stuffing the pixel buffer. The problem with the ROM font is that you can't just set a color for the line, because the color determines which of two interleaved characters gets displayed. However, if we're using helper cogs, we're not reading straight from the ROM, and the helper could mask out the unwanted character before putting it in the pixel buffer. That should make it just barely possible to do such a 50 by 18 ROM font display, with one color per line and probably needing 3 cogs.
I might just take a stab at this. There's quite a vacuum between the ROM font drivers and the super high density drivers, and using the ROM font looks beautiful while saving considerable RAM.
It's not necessary to spend a whole lot of time on it for my sake. I was just trying to understand how it all worked. I saw the rows / columns definitions at the top of the file and wondered why they were there if they could not be changed. I did come up with some new questions though.
1) Is it possible to "pixel-double" in VGA_HiRes_Text.spin so that it displays 20x40 text instead of 40x80 for the 640x480 res?
2) I notice that VGA_Text has str(), hex(), dec() functions but VGA_HiRes does not. Is that by design or do those functions just need to be added?
3) Why are the colors represented in quarternary?
-edit-
Okay, quarternary makes sense since there's only two resistors for each channel (four levels). Forgot about that.
2. I've never liked that the hex() and dec() functions are part of the video driver; they should be part of a string library if they're not part of the Spin language itself. You should be able to just copy the ones from VGA_text into the Hirez object and if the byte output function has the same name they should work.
I'm not sure what's on the table next week at work, but if I have some spare time I might look into an intermediate rez driver. If I have any luck I'll post the results here.
When I get potatotext 2 rendering properly on TV, I may consider this.
I'm new to video on prop (vop?) so constructive criticism is welcome.
vgatest.spin
VGA_HiRes_Text_Terminal.spin
You might want to check out my new thread
http://forums.parallax.com/showthread.php?129739-BETA-TEST-MikronautsVGA64-Single-Cog-hirez-64-column-text-driver!