[FYI] Yet another 50 column VGA text driver (single cog)
kuroneko
Posts: 3,623
So what's different from [thread=129769]Bill's driver[/thread] you ask? While it uses the same font format and objects (default is 8x10, thanks Bill) its approach for mapping colours is slightly different. Bill's driver has per line colour, mine uses a colour entry per character code. Usefulness of the latter is debatable hence the POC tag (promoted to FYI).
During initialisation screen buffer and font definition have to be provided (palette is optional). All three of them can be changed at runtime (processed during vertical blank). Vertical blank (start) is indicated by writing cnt to the frame indicator. What else? Timing is standard 800x600/40MHz but the driver only uses half the resolution. The screen buffer is slightly odd in that it's upside-down and right-to-left but whether I add x and y or subtract them shouldn't matter as this is hidden in the UI. Note that the imported colours are not masked so stay away from the sync bits.
During initialisation screen buffer and font definition have to be provided (palette is optional). All three of them can be changed at runtime (processed during vertical blank). Vertical blank (start) is indicated by writing cnt to the frame indicator. What else? Timing is standard 800x600/40MHz but the driver only uses half the resolution. The screen buffer is slightly odd in that it's upside-down and right-to-left but whether I add x and y or subtract them shouldn't matter as this is hidden in the UI. Note that the imported colours are not masked so stay away from the sync bits.
'' mailbox layout '' '' long[par][0]: screen: [!Z]:addr = 16:16 -> zero (accepted), required during startup '' long[par][1]: font: size:[!Z]:addr = 8:8:16 -> zero (accepted), required during startup '' long[par][2]: palette: [!Z]:addr = 16:16 -> zero (accepted), optional '' long[par][3]: frame indicatorHave fun!
Comments
You said "a colour entry per character code". Just to clarify...
You're not saying that all instances of some character code will have the same color are you?
Do you mean that every position on the screen can have a specified color?
This driver code is pretty impressive Kuroneko!
emit waitcnt cnt, #0 ' (coarse) re-sync after back porch (%%) mov vscl, hvis ' -8 1/8 mov phsb, #50 -1 ' -4 column count -1 :line rdbyte char, phsb ' +0 = get character movd :one, char ' set colour index add char, eins ' add font base address rdbyte temp, char ' +0 = read font definition :one cmp 0-0, temp ' WHOP sub phsb, #1 wz rdbyte char, phsb ' +0 = get character movd :two, char ' set colour index add char, eins ' add font base address rdbyte temp, char ' +0 = read font definition :two cmp 0-0, temp ' WHOP if_nz djnz phsb, #:line emit_ret ret ' +0 =Long ago Linus was working on his demo for Propeller, after having been sent one at several forum members insistence. He posted up an 800x600 VGA screen with a particular attribute. That attribute was he could eliminate the waitvids and still see the image. At the time, it was suggested this WHOP was happening just right, and nothing ever came of it, and the post was removed, to be replaced by some other code and Turbulence.
We had one other thread, where the WHOP was not well understood, and at the time it was thought impractical. Wrong!
I'm going to study this hard. Thanks for posting it. Still lots to do in the Prop I yet.
I was wondering the same thing.
The color is per character code, but still useful considering it's a single cog, by balancing number of different symbols and number of colors.
For example, by having the font to repeat 4 times the same 64 chars, a mode similar to C64 extended color text mode can be made.
Another option is having the first 128 chars as ASCII with a single fixed color, and chars 128..255 as semigraphic chars with 2x2 subpixels, grouped by 16, for 100x60 with 8 colors.
Not bad at all for a single cog!
Had some fun with it, so I'm attaching a mod that include a test with semigraphic chars.
@kuroneko
I've tested this (and your previous demos too) on two monitors, one being extremely picky for scan frequencies, and found out it syncs perfectly with both 5MHz and 6.25MHz crystal, WHITHOUT changing anthing, At 100MHz the monitor will simply indicate 800x600 75Hz.
But even more funny... at first I've been running with 6.25MHz crystal but forgot even to change xinfreq, and it still synced OK... now that's what I call plug and play
If it could be done in color, the GUI might look a lot better. Even if there were only 2 or 4 possible colors...
There are still many things being discovered about the prop. I still believe the counters hold other possibilities for their use, if only we could get a clear circuit of what they do.
I have wondered about using 2 cogs interleaved for the left and right half of the screen (i.e. cog 1 does the first half of each line and the second cog does the second half). I am not sure if PLL synchronisation can be achieved this way. Perhaps you or someone else may like to coment on this aspect.
I have also postulated about using 2 or more props in parallel to output parts of the screen. My CpuBlade pcbs make this a simple exercise to try this, but alas too many prop projects to give this a try yet.
That translates into pixel density over time. Interleaving on a scan line basis gets one the most liberal pixel density over time metric, but the cost is more time spent buffering, and or limits on COG storage space.
There really isn't a good way to queue for a quick burst, which would be required for the COG to just do it's half of the scan line, IMHO. Unrolling the active pixel loop is about the best option, yielding a high pixel density with the fewest HUB ops requiring the least loop management. (ideally no loop) Maybe some counter as address trickery changes that. I've not yet tried it.
Given the loop above, I think I would go for fetching a LONG at a time, which would be likely to free enough cycles to specify color on a more granular basis. Combine that with a unrolled waitvid loop, perhaps just writing it for the highest possible character density. Not too tough to build one COG image for each desired resolution. Would be a much larger bit of code, but there is a lot of room in the COG too.
Re: Two props!
I've seen it, but I can't say from who. Maybe they will say it.
Two props work very well outputting every other scan line. There are costs on where to put the screen memory. For a text display, maybe external RAM might work out nicely. If there are sprites, complete copies need to exist on both props, which doubles sprite memory cost.
FWIW, interleaving the display gets one about the same result. On many newer LCD displays, interlace signals just get fixed and are flicker free. I've got an old CRT display that flickers using 640x200 timing, looks solid on the LCD. IMHO, interlace on VGA may have merits today that it didn't back in the CRT days. If interlace is acceptable, then one COG can likely do the job that two would have on a progressive scan.
I've been itching to port Potatotext to VGA, using 640x200 timings and a fast pixel clock. 640x200 appears to display on most all devices I've seen. So that's another out; namely, going with lower sweeps.
The main reason is to be able to increase the density (pixels/line) which are limited by hub memory. This way the 2 props can both work together, but only keeping their respective half display in each hub.
Another possibility is to increase the colors by outputting two cogs simultaneously with a different resistor ladder network.
Both these methods are simple to test the concepts with prop pcbs that can be stacked.
Oh so many possibilities and so little time.
Rayman
With this driver two colors is possible, but you'd end replacing the "reverse" attribute (normally built in the second half of the font), with an "high intensity" attribute.
Four colors too, 2 bit for attribute/color and 6 for character code, then using only uppercase, early Apple II style
I imagine that reason for not having a separate attribute map is to save bandwidth.
IMHO with all the limitations, is still one more useful option for specific projects that can't afford more than a cog for display, compared to per-line color in other drivers.
Anyway if multiple cogs are available, we already have a multicog VGA implementation with per-cell attribute, made by Pullmoll. I always wondered why it's not more widely used. (sorry if I'm saying an obvious thing here, just trying to act as collective memory
I am trying to build a 80x25 color text terminal with ANSI/VT100 emulation. I tried MicroVGA, but it doesn't handle some of the escape sequences I have to deal with. I wrote the company that makes it, but have not gotten a response.
This project is replacing a large 20+ year old terminal. I wanted to update it with something smaller that could be customized. I really only need a PS/2 keyboard for input, VGA for output, and serial connection to talk to the host system.
A PC is overkill (has too many possible points of failure) for this project, so I wanted to look at the Propeller. I bought the Prop Proto board, and VGA kit. Got it built, and loaded PocketTerm on it. Works great, but the display is larger than I want. I could just buy some off the shelf solution like a Wyse terminal, but I wanted to challenge myself.
Embedded systems are somewhat new to me, but I am a very competent programmer. I also have an excellent engineer to work with, so the electronics aspect of this is pretty much covered.
How tough would be be to create a 80x25 text driver for VGA that would allow different colors per character on the screen?
Also, can anyone recommend a good book or two to get started with programming the Propeller? Any other tips, suggestions or advice would be appreciated as well.
Thanks in advance,
Smalldog
But, I will tell you that a 1280x1024 VGA driver from Parallax exists already that gives you 80 cols and 32 rows of text and every position can be a different color.
But, it uses 3 or 4 cogs and a sizeable amount of memory compared to the one in this thread.
@AntoineDoinel: Nice demo!