8x8 TV Text driver up to 70 chars / line @ 2 colors per screen) Ver 2.x & 3.x
potatohead
Posts: 10,261
There are two drivers here. Both are 8x8 NTSC character mode (text mode) drivers. The notes for both are below. To avoid confusion, I've pulled the history text from this first post, leaving only the current notes 'n such. These releases are running good. I may be expanding on the feature set. If that happens, I'll update this thread again, leaving these versions here for the longer term, see the ToDo's / Plan for more on that.
****Why these drivers?****
The tile drivers require addresses, and use the ROM font, which is a lot of pixels for a TV. There are also a lot of parameters for those drivers. These drivers use a byte / character (tile) addressing scheme that keeps screen memory nice and simple, and have simple parameters that are small in number. Besides, I just like the older 8x8 fonts!!
****Version 3.0 **** (12)
This is the low memory foot print option. It's got less color capability, but takes the least amount of running HUB memory. 3.x drivers will always be low memory foot print options.
There are 4 on screen colors total. Two for the COG characters, two for the HUB characters, if used.
128 character definitions are possible in both the COG and the HUB, with the high bit of any one screen memory byte toggling between the two.
A max of 40 chars / line is possible @ 80 Mhz. Vertical rows range from a few to as many as 27.
The archive contains two programs. One is the TV driver, and it's COG font table. The other is a quick and dirty demo / test program that also contains a HUB font table. Feel free to make your own.
For your project, only the TV driver is needed, once you understand the setup. That's what the demo program is for.
More specific settings and such are in the code comments.
****Version 2.1**** (08)
This is the larger, though still small, memory foot print option. It's got more color capability, but does not have COG characters at all. Screen memory and font table must reside in the HUB.
Color works two ways. If two colors are defined, per screen, then that's it. All chars share those colors, just like the 3.x ones do. If those colors are both set to zero, then screen memory is increased and individual colors can be defined per character.
A max of 70 chars per line is possible. 64 is likely the fully viewable on most displays max, however. This is monochrome, two color per screen. If multi-color mode is on, that max becomes 40 chars / line.
Vertical rows range from a few to 27.
The archive contains two programs. One is the TV driver, the other contains a quick and dirty demo, plus the necessary HUB font table. Your project will need to incorporate that font table, and supply it's address to the driver, unlike the 3.x which can stand alone.
Todo's / current plan:
Add 4 color HUB char mode to 3.x driver. (In, progress. Current plan is 1/2 resolution for 4 color chars to keep screen memory sane.)
Add vertical pixel size to both drivers. (may get done, may not, depends on if it's needed...)
Reorganize font table for ASCII compliance. (also may get done, depends on how big of a deal that is.)
??? I see a batch of downloads. Anybody using these? If so, how's the fit? Need something, works good, etc...? Put your comments / flames / feedback in this thread or PM me. Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 10/16/2007 4:56:38 PM GMT
****Why these drivers?****
The tile drivers require addresses, and use the ROM font, which is a lot of pixels for a TV. There are also a lot of parameters for those drivers. These drivers use a byte / character (tile) addressing scheme that keeps screen memory nice and simple, and have simple parameters that are small in number. Besides, I just like the older 8x8 fonts!!
****Version 3.0 **** (12)
This is the low memory foot print option. It's got less color capability, but takes the least amount of running HUB memory. 3.x drivers will always be low memory foot print options.
There are 4 on screen colors total. Two for the COG characters, two for the HUB characters, if used.
128 character definitions are possible in both the COG and the HUB, with the high bit of any one screen memory byte toggling between the two.
A max of 40 chars / line is possible @ 80 Mhz. Vertical rows range from a few to as many as 27.
The archive contains two programs. One is the TV driver, and it's COG font table. The other is a quick and dirty demo / test program that also contains a HUB font table. Feel free to make your own.
For your project, only the TV driver is needed, once you understand the setup. That's what the demo program is for.
More specific settings and such are in the code comments.
****Version 2.1**** (08)
This is the larger, though still small, memory foot print option. It's got more color capability, but does not have COG characters at all. Screen memory and font table must reside in the HUB.
Color works two ways. If two colors are defined, per screen, then that's it. All chars share those colors, just like the 3.x ones do. If those colors are both set to zero, then screen memory is increased and individual colors can be defined per character.
A max of 70 chars per line is possible. 64 is likely the fully viewable on most displays max, however. This is monochrome, two color per screen. If multi-color mode is on, that max becomes 40 chars / line.
Vertical rows range from a few to 27.
The archive contains two programs. One is the TV driver, the other contains a quick and dirty demo, plus the necessary HUB font table. Your project will need to incorporate that font table, and supply it's address to the driver, unlike the 3.x which can stand alone.
Todo's / current plan:
Add 4 color HUB char mode to 3.x driver. (In, progress. Current plan is 1/2 resolution for 4 color chars to keep screen memory sane.)
Add vertical pixel size to both drivers. (may get done, may not, depends on if it's needed...)
Reorganize font table for ASCII compliance. (also may get done, depends on how big of a deal that is.)
??? I see a batch of downloads. Anybody using these? If so, how's the fit? Need something, works good, etc...? Put your comments / flames / feedback in this thread or PM me. Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 10/16/2007 4:56:38 PM GMT
720 x 540 - 449K
720 x 540 - 483K
720 x 540 - 334K
Comments
I tried to get your graphic driver going, but looks like I got wrong pins connected and/or can't figure out how change TV pin assignment.
It is encoded in those 2 lines, right?
Which 3 pins I should use to drive my TV monitor?
Jan
It definitely depends on where you plugged it in
The video hardware looks at the propeller pins in 4 groups of eight bits each
0: Pin 0..7
1: Pin 8..15
2: Pin 16..23
3: Pin 24..31
In worst case it will use all 8 bits, for modulated and unmodulated signals likewise.
So you ALSO have to block the unused signals to allow a different use of the pins:
When your (baseband) monitor is plugged to the higher 4 bit group you have also to swap the meaning of baseband and broadband in the "VMODE"-Bits 29 and 30. Have a look on page 317 of the manual. Everthing is well explained there...
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
You do change the pin definitions in that part of the program. However, it's highly likely you need to clock definition, depending on what you are running. Hydra uses a 10Mhz crystal. Demo board uses a 6. That's these two lines: (there is a thread here on HYDRA to demo board / other board conversions. oldbitcollector started it The info you need is likely to be there.
_CLKMODE = xtal1 + pll8x
_XINFREQ = 10_000_000 + 0000
Oldbit: Thanks! I need a debug display for the overlay stuff I've been working on. That's been a PITA.
Spent a long time, as a kid, looking at that font. It's kind of nice to have it back.
To do's on this one:
1. Move font table into COG RAM. This will free up 1K of HUB memory. The idea behind this one was to have a very low memory footprint driver. With the font in the COG, one can have a text display in as little as 480 bytes of HUB memory! Perfect for multiple or debug displays. I think I've got how to do this figured out today. Will see.
2. Deal with vertical height, though this is not a priority. If I do that, it will just be one scan line or two, for 192 or 96 pixel resolution, NTSC.
3. With core 128 char font in COG, use upper screen memory bit to trigger access to optional HUB memory font table. That way, if somebody wants to do graphics, they can stack some of the HUB char definitions together to form a tilemap and display their graphics. Hoping to allow 4 color mode on this, mixed with the two color text. The idea being to set that high bit, to access chars defined in HUB. If the 4 color thing works, mid scan, then HUB chars can be 4 color, while COG chars can be 2 color, thus keeping overall memory foot print really small.
4. Code cleanup & move video init stuff to SPIN. That's gonna allow for more pixel / timing variations, and make it easier to launch the driver from other code. That's all kind of messy right now --sorry.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
I also spent a lot of my childhood staring at a font like this one. (Commodore isn't far off from the Atari font)
Might even have to adapt this a bit.. Did I understand there was room for additions?? [noparse]:)[/noparse]
I've got a protoboard, so I'll work on a conversion as soon as I have time. (possibly later tonight)
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Are you planning to overwrite the HUB area once you have started the COG? Otherwise the table will still sit there consuming HUB space anyway.
Oldbitcollector, please do! I really do need to track down those differences, maybe put them into a table so people can just pick them as needed. I've been somewhat lazy about that part of things. My prop time comes when it comes and it seems like there is always something to do but that! I don't think those conversions will change much with the next coupla revs. I anticipate two more for a pretty feature complete driver. ...and a neatness pass or two.
Would be nice to have a few 8x8 fonts handy as well. The one included is the Atari international. It's good on having lots of special alphas, not so good on symbols, etc... Both the C64 and Atari have 2K fonts with lots of those things. Given the diverse geography present on the forum, I thought it a nice choice.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
And I've already done manic miner, so it shouldn't be that hard to do [noparse]:)[/noparse]
edit: just had a play, and yeah it's a nice small footprint too expecially byte mode would be good for a text adventure, or·dungeon style rpg.
Infact, this might tempt me to port my pic version of 3D Monster Maze to the prop. [noparse]:)[/noparse]
Post Edited (Baggers) : 10/1/2007 3:55:33 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
I understand what is happening with the color. Now I just need to figure out how to implement the fix.
As the driver stands right now, color timing is fixed on every frame. This limits effective resolution to 160 color pixels. The Atari font deals with this by never having a single pixel stand alone, so it looks good in color. The Atari also had a limitation in color high-res where high resolution pixels needed to be the same HUE, differing in intensity only. This driver essentially comes with that same limitation as the color timing is the same as output on the Atari, but for the fact that it is really possible to pick any two colors.
To see the problem, send the composite output into the luma input of an S-video capable device. This will show you the color pixels, as stripes. Those stripes really should be an alternating pattern of dots, that form a solid grey area, not stripes.
The net result, for this version, is you can do a monochrome char on a colored background nicely enough. You can also choose two colors that are similar in hue, or the same hue, but differing only in intensity. That will display OK too. Finally, you can choose black or white as the background, then have the char be some hue. Most of those will display somewhat ok.
If you have contrasting colors, the timing is not there to yield the full 320 pixel resolution possible. Of course, there is the 20x24 mode...
From what I understand, the phase of the color signal needs to alternate on both scan lines and frames by 180 degrees. The Parallax driver does this, but it's complex to decode. This driver is based on a static timing, so I'm going to have to adapt it. I've struggled with this aspect of NTSC the whole time! For a lot of things, the static timing is actually great. One good example of that working is the high-color demo I posted here a while back. It depends on artifacting. For text, it's not so good, so I'm gonna have to work through that. It's gonna have a bonus as it will help with the overlay graphics I've also been working on. (at some point, that means a cursor for things like this, on the TV, in color.)
I have an S-video capable capture device and display, but no cable! I would be very curious to see how that all resolves. My gut says it's still gonna be an issue, but it might not be. I don't fully grok just what the differences are in the S-video environment.
I do know, the phase shifting done correctly will make a 320 (40 char) display resolve perfectly on nearly all color combos. It will allow for a 64 char display on many combinations, monochrome, or S-video.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
See first post for it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
See first post for notes and project progress.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
1.x now depreciated. It's not ever gonna see any attention. See top of thread for the notes on 2.x & 3.x
Here's an example of the changes necessary to get this to run on a Demo Board: (You make these on the TV driver portion.)
'Setup the video generator hardware. 'use one long to setup VCFG, so it matches the bit fields in the Propeller Manual better setup_vcfg long %0_11_1_1_1_000_00000000000_001_0_11110000 initialization 'set up VCFG ' VCFG: setup Video Configuration register and 3-bit tv DAC pins to output mov VCFG, setup_vcfg 'Ignore these, depending on the mov instruction above... 'movs VCFG, #%0111_0000 ' VCFG'S = pinmask (pin31: 0000_0111 : pin24) 'movd VCFG, #1 ' VCFG'D = pingroup (grp. 3 i.e. pins 24-31) 'movi VCFG, #%0_11_111_000 ' baseband video on bottom nibble, 2-bit color, enable chroma on broadcast & baseband ' %0_xx_x_x_x_xxx : Not used ' %x_10_x_x_x_xxx : Composite video to top nibble, broadcast to bottom nibble ' %x_xx_1_x_x_xxx : 4 color mode ' %x_xx_x_1_x_xxx : Enable chroma on broadcast ' %x_xx_x_x_1_xxx : Enable chroma on baseband ' %x_xx_x_x_x_000 : Broadcast Aural FM bits (don't care) or DIRA, tvport_mask ' set DAC pins to output (You have to deal with this one, if you change pins!!)Note that last or instruction. That's the killer! Be sure and set tvport_mask, which does the pin direction stuff necessary for the signals to get out of the thing, like so:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 10/16/2007 5:01:32 PM GMT
@Desilva: Since I'm still having trouble with the conversion of this to demoboard, I assume that this ^^^^ is still a problem.
I've been all over 317+ in the manual and am starting to extract handfuls of hair. Elaborate?
I'm using this:
initialization 'set up VCFG ' VCFG: setup Video Configuration register and 3-bit tv DAC pins to output movs VCFG, #%0111_0000 ' VCFG'S = pinmask (pin31: 0000_0111 : pin24) movd VCFG, #1 ' VCFG'D = pingroup (grp. 3 i.e. pins 24-31) movi VCFG, #%0_10_111_000 ' baseband video on bottom nibble, 2-bit color, enable chroma on broadcast & baseband ' %0_xx_x_x_x_xxx : Not used ' %x_10_x_x_x_xxx : Composite video to top nibble, broadcast to bottom nibble ' %x_xx_1_x_x_xxx : 4 color mode ' %x_xx_x_1_x_xxx : Enable chroma on broadcast ' %x_xx_x_x_1_xxx : Enable chroma on baseband ' %x_xx_x_x_x_000 : Broadcast Aural FM bits (don't care) or DIRA, tvport_mask ' set DAC pins to outputand
Attached screenshot
Thanks
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Post Edited (Oldbitcollector) : 10/16/2007 11:56:08 PM GMT
So
movi VCFG, #%0_11_111_000 ' baseband video on upper nibble, 2-bit color, enable chroma on broadcast & basebandshould do the trick... I hope...
I'm pleased that at least I didn't overlook something stated..
Thanks
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
(I've got my little video-plug-in board in the same pins the hydra uses)
So I know it isn't timing issues..
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
It ran in Gear.... oh well. Have to track that down too, because I'm seriously thinking about just making plugins for the various setups out there to test virtually...
I've some confusion about the nibble thing too. On a HYDRA that mode setting (for the nibble) is 03, but the output is on the LOWER nibble!!
This is some of the confusion I had last night oldbitcollector.
The default for Gear is a demoboard setup, and it renders nicely, which of course, led to this post...
Saw your post too deSilva. 03, did not render in GEAR as expected...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
I've got an "out" and "str" functional, but found that I needed to move the font around a little to get
the expected results. All-in-all very nice!
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
I'll have prop time tomorrow... Tonight it's poker!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
I've modified the char_mode_08 to single color, moving the keyboard characters to expected positions
I've also added some basic "out" and "str" functionality.
A Text_Demo has been included, but there is no location control. (very simple)
It is set for Demoboard speed settings with Hydra video settings.
This could very easily become a nice drop-in replacement for TV_Text. [noparse]:)[/noparse]
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Post Edited (Oldbitcollector) : 10/20/2007 3:13:32 AM GMT
perfectly with very little modification. @Chip: you are a programming god...
I just moved several of the routines from TV_Text into Char_Mode8, a tweak here and there and
we have a drop-in replacement for TV_Text that does smooth 40x24.
Warning: Doug is still working on the video-pins issue so this .zip is set for Hydra compatible video
pins at demoboard speed. Otherwise it seems to work perfectly. There's gotta be a bug somewhere,
but I haven't found it yet... Ah ha.. Very minor bugs found.. fixed and file reposted below.
Someone jump and and lend a hand getting this running on demoboard video pins... [noparse]:)[/noparse]
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Post Edited (Oldbitcollector) : 10/20/2007 6:58:34 PM GMT
Not tied the latest version but I've had the previous versions working on ProtoBoard which I believe are the same pins as DemoBoard (P12-P14) and both 5MHz XTAL.
What help are you looking for exactly - List of changes to make, a version with the changes made, a version which can be set via a run-time parameter ?
Would you mind posting the adjustments you made to get them working on the Protoboard? I haven't had any luck moving it to 12-14.
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.