Hippy, if you could post your video init code changes, that would be excellent. I've had a complete swine of a time getting the protoboard stuff right. Don't have one and was attempting to use GEAR to test it virtually. It's television plug in will display stuff that will not display on real hardware. Maybe seeing those will highlight where GEAR breaks down, making future attempts easier.
@ Oldbitcollector, potatohead : I'll get the latest Char8_Text_Demo.zip downloaded and running ( hopefully with no problems ) then I'll list the changes and post the changed .spin code.
Char8_Text_Demo.zip downloaded and working on my ProtoBoard, pins 12-14 ( forgotten I'd added the R's myself, so not all ProtoBoards are the same as DemoBoard but I guess mine is in that respect ), 5MHz. Composite video into Panasonic TV, PAL region but NTSC compatible (usually ).
Three changes to char_mode_08_TV.spin, and that's it ...
I won't pretend to understand how your driver actually works, so I'm not sure if either 165 or 213 should change. Changing 165 to %0_11_011_000 and the grey border disappeared but still ran. Changing 213 to %0_11_111_000 and TV completely lost synch. With 165 as %0_11_011_000 and 213 as %0_11_111_000 there's an image, but it's a complete 'colourful mess' wrt the text.
I think part of the confusion comes from the comment in Line 100 ...
100 : ' %x_10_x_x_x_xxx : Composite video to top nibble, broadcast to bottom nibble
That's not right; that puts composite to bottom nibble, as per the Propeller Manual ...
10 Composite Mode 1; broadcast on VPins 7:4, baseband on VPins 3:0
11 Composite Mode 2; baseband on VPins 7:4, broadcast on VPins 3:0
I'll look over what I was doing. Nice catch on the nibble bit. I see where I had that backwards now.
The two color mode and 4 color mode lines are necessary for these reasons:
On the Prop, we draw the entire signal. Most, if not all, other graphics systems let the programmer deal with timing, but not the signal itself. The character display is a two color display, meaning each bit is either on or off, with color information specified at the time they are drawn to the screen.
The 4 color mode is used to draw the sync signals. The two color mode draws the actual active display pixels.
@ Oldbitcollector : Your latest .ZIP worked straight out the box. Well done and thanks.
In return, a version which passes base TV pin number via param[noparse]/noparse at run-time. Only tested on Pin 12-14. Filenames as original .ZIP, so be careful.
Putting on flame-proof and kick-proof underwear ... what's the likelihood of a PAL version, or is that a project left for an interested party to do that ? Is it a major job or would it be mainly a case of leveraging the PAL settings from one of the Parallax drivers ? I guess this would be a good enough time and place for me to start learning about video drivers
Double Ooops : Add a WZ to line 115 in char_node_08_TV.spin and change the constant value to %100 *not* %1000 - "and A,#%100 WZ"
Not a mess at all. Cool actually. I've not given the BASIC a try. I'm gonna have to now.
I'll take a look at PAL. Don't know much about it, but I just looked and saw my video capture card will take a PAL signal.
(goes off to run some PAL stuff to see if the cable is right or not)
IMHO, the way this one is built, one should just be able to do the timing calcs, rewrite the sync, and leave the rest alone. I'm interested in the low level stuff for a coupla reasons. One being to learn enough to complete the overlay project. (That's for one COG doing core background video, another doing sprites, and'ed with the background electrically instead of programatically) The other being to build up a few more graphics options. It's just cool too. Wanted to do this stuff since I was a kid. I'm here now, better late than never!
This one still needs the full NTSC spec color timing too, though that will break the retro look... Oh well.
Since Oldbit has a good handle on the TV_text part, I'll just skip working on that stuff, and see about extending the lower level stuff, for a while longer.
Fantastic! I'll have to use this driver for the Z-Machine that I'm working on in between trying to figure CLUTs in the high color driver for my fractal demo. [noparse]:)[/noparse]
I love the retro Atari fonts! I grew up with an Atari 800, so seeing the white on blue with ATASCII fonts. Whee!
hippy said...
@ Oldbitcollector : Your latest .ZIP worked straight out the box. Well done and thanks.
In return, a version which passes base TV pin number via param[noparse]/noparse at run-time. Only tested on Pin 12-14. Filenames as original .ZIP, so be careful.
Putting on flame-proof and kick-proof underwear ... what's the likelihood of a PAL version, or is that a project left for an interested party to do that ? Is it a major job or would it be mainly a case of leveraging the PAL settings from one of the Parallax drivers ? I guess this would be a good enough time and place for me to start learning about video drivers
Double Ooops : Add a WZ to line 115 in char_node_08_TV.spin and change the constant value to %100 *not* %1000 - "and A,#%100 WZ"
Anyone test this on a Hydra? All I'm getting is a blank screen, despite changing the pins to a Hydra-specific configuration. It seems to me that the oriignal Hydra-specific zipfile was edited out by oldbitcollector?
Anyone test this on a Hydra? All I'm getting is a blank screen, despite changing the pins to a Hydra-specific configuration. It seems to me that the oriignal Hydra-specific zipfile was edited out by oldbitcollector?
-Wes
Wes,
Just drop in the "char_mode_08_TV" from the zip are the top of the thread... The Demo should then work
perfectly on the Hydra. Perhaps I should refresh the .zip with both versions of "char_mode_08_tv" until
we can test them completely.
Anyone test this on a Hydra? All I'm getting is a blank screen, despite changing the pins to a Hydra-specific configuration. It seems to me that the oriignal Hydra-specific zipfile was edited out by oldbitcollector?
-Wes
Wes,
Just drop in the "char_mode_08_TV" from the zip are the top of the thread... The Demo should then work
perfectly on the Hydra. Perhaps I should refresh the .zip with both versions of "char_mode_08_tv" until
we can test them completely.
Oldbitcollector
Hmm. Which one is known working on a Hydra? I tried the version at the top of the thread, post #1. Didn't seem to take. [noparse]:)[/noparse] Now, I'm uncertain as to if it's because of my apparent TV/Hydra synch issues, so it could be that.
The "08" version from the first post should work perfectly on your Hydra. (Given something hasn't gone wrong)
Then replace everything except "char_mode_08_TV" from my zip and it should continue to work with controls.
(Don't forget to change the speeds in the replacement files)
Sorry we've forked this a bit, and sadly I only have the protoboard, and Doug only the Hydra.
I'm sure it will get sorted out a bit more in time. [noparse]:)[/noparse]
Oldbitcollector said...
The "08" version from the first post should work perfectly on your Hydra. (Given something hasn't gone wrong)
Then replace everything except "char_mode_08_TV" from my zip and it should continue to work with controls.
(Don't forget to change the speeds in the replacement files)
Alas, the driver mentioned doesn't work out of the box in 16 bit mode. It does work in two colors, though, once I comment out the 16 bit stuff.
Is the 16 bit mode doing strange things that my TV wouldn't agree with? [noparse]:)[/noparse]
Allows you to code your bit maps left to right as seen on screen or reversed as they currently are. If left to right, set the first byte / top line of the space character to non-zero. Because it corrects that byte, the code will only do it's thing once regardless if called again. Put it at start of 'PUB Start' in the high level handler.
@ Oldbitcollector : I've moved my font definitions into a sub-object which makes it easier to switch between fonts. Instead of using @fonttab use object.GetPointerToFontTable.
The font I'm using is attached. As per your original with some block characters, arrows and a few minor changes to suit what I need to display. Characters $00-$1F and $7F can be changed to suit individual preferences.
You'll need to include the pixel reversing code given earlier and change fill commands to use $20 (space) not $00 to clear the screen and the scrolled line.
Would you guys, who didn't have any luck with two color / character mode, be willing to try the following?
-set it to 20 chars
-define colors, for the chars that differ only in intensity. (use any hue you want, or black for background)
I've actually tried something different -- I modified the color divisor used in displayb[noparse][[/noparse]index] in LSB to various values. When it is set to a value like 6 rather than 4, it actually produces a decent image as shown in the first screenshot.
When it is 7, 8 and 14, we can see some tearing on the edges, though it's a fairly good image.
And when it is 12, and other values such as 11, 13, 15, 16, it rolls off the screen.
4, 5, 9, 10 produces no image on the TV as it doesn't like it.
This leads me to believe that it's certain patterns of colors closer to the edge of the screen that the TV doesn't like, as the divisor just modifies the patterns.
Setting it to 20 character mode (160 instead of 320) produces similiar results, except it has more trouble synching interestingly -- there are no divisor values that produce a in-synch image that doesn't roll off the screen on a consistent basis.
Some of those colors are low intensity ones. Too low, and actually may be sync values. My video capture card clearly ignores this issue, as do some displays. The colors in the quick demo are going outta spec for sure.
My fault for not doing a color check. The capture card is a little too tolerant. Would have seen that on a TV.
That's actually good news. It's really just some color bounds checking. Timing and all of that is highly likely to be fine.
When I get to another release, after folding in some changes posted here, I'll change the quick demo to prevent those colors from being specified. Or make it very clear how to specify the right ones. (USE THE CLUT)
You are spot on about the edges being important. Once, when working through possible colors, I tried inserting the below black colors in different places, just to see what the display would tolerate. Edges get confused with HSYNC, middle of the screen, in small amounts is nearly always tolerated.
Changing the divisor is just getting lucky about which color specs end up where.
There is a CLUT in the program. Color values that fall into that table, will display nicely. (I hope)
I spent most of my time in front of my PC today instead of my Prop. [noparse]:([/noparse]
But I did get something accomplished (besides the work I was suppose to do.)
Attached is a CBM/PETSCII font mapped to ascii positions. I'm getting alot of purple/cyan smearing with
this one. Can someone verify this? I don't think it's my trusty 1702...
Now the Commodore heads and Atari heads are equally served.. <smirk>
(You'll need to incorporate hippy's reversal code for this to work correctly. )
Oldbitcollector
Historical note: It's commonly believed that Atari ripped off the Commodore font.
If Doug's original is accurate, I seriously doubt that. Every UPPERcase character had to
be edited. (Yes, I used a real 64 font editor for my match) Interestingly the lower case
characters were a dead match.
Oldbitcollector said...
I'm getting alot of purple/cyan smearing with
this one. Can someone verify this? I don't think it's my trusty 1702...
Do you mean 'pixel tinting' ( the best words I can think to describe it ? ... I altered the background colour and borders to black and I've seen that since I started with the previous font. I suspect it was there all along but I didn't notice it with the retro-blue background.
The actual tint colours seem to vary slightly depending on the foreground/background colour, and also changes across the screen. Create some characters with single pixel vertical or horizontal lines and it's more noticeable.
Added : Just tried the CBM font; you're right it is somewhat more tinted. I don't know if you're seeing the same as me, but on my TV the tint seems to change mainly when there's a pixel which is on but not on in the above/below line, or something like that.
Oldbitcollector said...
I'm getting alot of purple/cyan smearing with
this one. Can someone verify this? I don't think it's my trusty 1702...
Do you mean 'pixel tinting' ( the best words I can think to describe it ? ... I altered the background colour and borders to black and I've seen that since I started with the previous font. I suspect it was there all along but I didn't notice it with the retro-blue background.
The actual tint colours seem to vary slightly depending on the foreground/background colour, and also changes across the screen. Create some characters with single pixel vertical or horizontal lines and it's more noticeable.
Added : Just tried the CBM font; you're right it is somewhat more tinted. I don't know if you're seeing the same as me, but on my TV the tint seems to change mainly when there's a pixel which is on but not on in the above/below line, or something like that.
That's exactly what it is, and that's the major reason why the retro-blue backgrounds were in common use with the home computers that used a NTSC display. White on blue really is one of the better colors to avoid such, and its contrasty enough to read easily, so I would say that the default colors of the 8x8 text driver should be this rather than a black background.
The original Amiga workbench 1.x also had high contrast colors, as they had support for composite/RF out.
@ Wes : Thanks for the explanation. I've not done anything with retro-computers or NTSC so just shrugged my shoulders and lived with it. On a 32" widescreen from 15' away it's not that noticeable
Unfortunately that caused me a problem ... I've entirely rewritten the driver based on the demo ( which says a lot for the implementation and quality there ) and it's working fine except ( using just a fixed text color ) if I put a character in the rightmost display column I get some random color artefacts at end of line. If I switch colors per character I also get colours in the horizontal flyback. I'm sure it was working so something is different to the earlier 8x8 .zips but I missed noticing it when it first appeared so cannot easily tell what the problem is.
I'm still trying to convert the driver to PAL and when I'm back in the right OS I'll check to see what the questions are I have to ask.
Comments
Nice work Jeff!
Hippy, if you could post your video init code changes, that would be excellent. I've had a complete swine of a time getting the protoboard stuff right. Don't have one and was attempting to use GEAR to test it virtually. It's television plug in will display stuff that will not display on real hardware. Maybe seeing those will highlight where GEAR breaks down, making future attempts easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 12/25/2008 7:47:45 PM GMT
You will save some hair on my head!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Working on implementing color selection.. (as soon as I work my brain around how your routine works) [noparse]:)[/noparse]
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Three changes to char_mode_08_TV.spin, and that's it ...
Line 94 did not need changing and I left lines 165 and 213 as was ...
I won't pretend to understand how your driver actually works, so I'm not sure if either 165 or 213 should change. Changing 165 to %0_11_011_000 and the grey border disappeared but still ran. Changing 213 to %0_11_111_000 and TV completely lost synch. With 165 as %0_11_011_000 and 213 as %0_11_111_000 there's an image, but it's a complete 'colourful mess' wrt the text.
I think part of the confusion comes from the comment in Line 100 ...
That's not right; that puts composite to bottom nibble, as per the Propeller Manual ...
10 Composite Mode 1; broadcast on VPins 7:4, baseband on VPins 3:0
11 Composite Mode 2; baseband on VPins 7:4, broadcast on VPins 3:0
I'll look over what I was doing. Nice catch on the nibble bit. I see where I had that backwards now.
The two color mode and 4 color mode lines are necessary for these reasons:
On the Prop, we draw the entire signal. Most, if not all, other graphics systems let the programmer deal with timing, but not the signal itself. The character display is a two color display, meaning each bit is either on or off, with color information specified at the time they are drawn to the screen.
The 4 color mode is used to draw the sync signals. The two color mode draws the actual active display pixels.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Ok:
@Doug: I suspect we've made a mess of your release, but it looks like hippy solved the issue.
@Hippy: I owe you again... [noparse]:)[/noparse]
Attached is a fresh copy of char_mode_08_demo for the demo/protoboard
It will drop-in and replace an instance of TV_Text nicely.
Now that's teamwork gentlemen.. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Post Edited (Oldbitcollector) : 10/20/2007 6:57:04 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
The TV_Text code for everything except color control has also been included.
Just dropped your driver onto Femtobasic. Had to cut back the programming space a little, but
it just looks beautiful.
Oldbitcollector
Image doesn't do it justice.. Looks great..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Post Edited (Oldbitcollector) : 10/20/2007 8:01:26 PM GMT
In return, a version which passes base TV pin number via param[noparse]/noparse at run-time. Only tested on Pin 12-14. Filenames as original .ZIP, so be careful.
Putting on flame-proof and kick-proof underwear ... what's the likelihood of a PAL version, or is that a project left for an interested party to do that ? Is it a major job or would it be mainly a case of leveraging the PAL settings from one of the Parallax drivers ? I guess this would be a good enough time and place for me to start learning about video drivers
Double Ooops : Add a WZ to line 115 in char_node_08_TV.spin and change the constant value to %100 *not* %1000 - "and A,#%100 WZ"
Post Edited (hippy) : 10/20/2007 9:06:48 PM GMT
I'll take a look at PAL. Don't know much about it, but I just looked and saw my video capture card will take a PAL signal.
(goes off to run some PAL stuff to see if the cable is right or not)
IMHO, the way this one is built, one should just be able to do the timing calcs, rewrite the sync, and leave the rest alone. I'm interested in the low level stuff for a coupla reasons. One being to learn enough to complete the overlay project. (That's for one COG doing core background video, another doing sprites, and'ed with the background electrically instead of programatically) The other being to build up a few more graphics options. It's just cool too. Wanted to do this stuff since I was a kid. I'm here now, better late than never!
This one still needs the full NTSC spec color timing too, though that will break the retro look... Oh well.
Since Oldbit has a good handle on the TV_text part, I'll just skip working on that stuff, and see about extending the lower level stuff, for a while longer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
I love the retro Atari fonts! I grew up with an Atari 800, so seeing the white on blue with ATASCII fonts. Whee!
-Wes
Maybe after I get a handle on the color controls...
@potatohead, you'll have to add a Cr=13 to the CON(Char8) & downsize the "programsize" to get Femto working..
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Anyone test this on a Hydra? All I'm getting is a blank screen, despite changing the pins to a Hydra-specific configuration. It seems to me that the oriignal Hydra-specific zipfile was edited out by oldbitcollector?
-Wes
Wes,
Just drop in the "char_mode_08_TV" from the zip are the top of the thread... The Demo should then work
perfectly on the Hydra. Perhaps I should refresh the .zip with both versions of "char_mode_08_tv" until
we can test them completely.
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Hmm. Which one is known working on a Hydra? I tried the version at the top of the thread, post #1. Didn't seem to take. [noparse]:)[/noparse] Now, I'm uncertain as to if it's because of my apparent TV/Hydra synch issues, so it could be that.
-Wes
Then replace everything except "char_mode_08_TV" from my zip and it should continue to work with controls.
(Don't forget to change the speeds in the replacement files)
Sorry we've forked this a bit, and sadly I only have the protoboard, and Doug only the Hydra.
I'm sure it will get sorted out a bit more in time. [noparse]:)[/noparse]
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Alas, the driver mentioned doesn't work out of the box in 16 bit mode. It does work in two colors, though, once I comment out the 16 bit stuff.
Is the 16 bit mode doing strange things that my TV wouldn't agree with? [noparse]:)[/noparse]
-Wes
ptr := @fonttab if byte[noparse][[/noparse] ptr+constant(" "*8) ] byte[noparse][[/noparse] ptr+constant(" "*8) ] := 0 repeat constant(128 * 8) byte[noparse][[/noparse] ptr++ ] := byte[noparse][[/noparse] ptr ] >< 8Edited : More optimal code ...
ptr := @fonttab if byte[noparse][[/noparse] ptr+constant(" "*8) ] ~ repeat constant(128 * 8) byte[noparse][[/noparse] ptr++ ] ><= 8Allows you to code your bit maps left to right as seen on screen or reversed as they currently are. If left to right, set the first byte / top line of the space character to non-zero. Because it corrects that byte, the code will only do it's thing once regardless if called again. Put it at start of 'PUB Start' in the high level handler.
Post Edited (hippy) : 10/23/2007 4:37:16 PM GMT
@hippy: Nice code addition!
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
PS great driver by the way, it opens many possibles
Would you guys, who didn't have any luck with two color / character mode, be willing to try the following?
-set it to 20 chars
-define colors, for the chars that differ only in intensity. (use any hue you want, or black for background)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
The font I'm using is attached. As per your original with some block characters, arrows and a few minor changes to suit what I need to display. Characters $00-$1F and $7F can be changed to suit individual preferences.
You'll need to include the pixel reversing code given earlier and change fill commands to use $20 (space) not $00 to clear the screen and the scrolled line.
I've actually tried something different -- I modified the color divisor used in displayb[noparse][[/noparse]index] in LSB to various values. When it is set to a value like 6 rather than 4, it actually produces a decent image as shown in the first screenshot.
When it is 7, 8 and 14, we can see some tearing on the edges, though it's a fairly good image.
And when it is 12, and other values such as 11, 13, 15, 16, it rolls off the screen.
4, 5, 9, 10 produces no image on the TV as it doesn't like it.
This leads me to believe that it's certain patterns of colors closer to the edge of the screen that the TV doesn't like, as the divisor just modifies the patterns.
Setting it to 20 character mode (160 instead of 320) produces similiar results, except it has more trouble synching interestingly -- there are no divisor values that produce a in-synch image that doesn't roll off the screen on a consistent basis.
Some of those colors are low intensity ones. Too low, and actually may be sync values. My video capture card clearly ignores this issue, as do some displays. The colors in the quick demo are going outta spec for sure.
My fault for not doing a color check. The capture card is a little too tolerant. Would have seen that on a TV.
That's actually good news. It's really just some color bounds checking. Timing and all of that is highly likely to be fine.
When I get to another release, after folding in some changes posted here, I'll change the quick demo to prevent those colors from being specified. Or make it very clear how to specify the right ones. (USE THE CLUT)
You are spot on about the edges being important. Once, when working through possible colors, I tried inserting the below black colors in different places, just to see what the display would tolerate. Edges get confused with HSYNC, middle of the screen, in small amounts is nearly always tolerated.
Changing the divisor is just getting lucky about which color specs end up where.
There is a CLUT in the program. Color values that fall into that table, will display nicely. (I hope)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
I spent most of my time in front of my PC today instead of my Prop. [noparse]:([/noparse]
But I did get something accomplished (besides the work I was suppose to do.)
Attached is a CBM/PETSCII font mapped to ascii positions. I'm getting alot of purple/cyan smearing with
this one. Can someone verify this? I don't think it's my trusty 1702...
Now the Commodore heads and Atari heads are equally served.. <smirk>
(You'll need to incorporate hippy's reversal code for this to work correctly. )
Oldbitcollector
Historical note: It's commonly believed that Atari ripped off the Commodore font.
If Doug's original is accurate, I seriously doubt that. Every UPPERcase character had to
be edited. (Yes, I used a real 64 font editor for my match) Interestingly the lower case
characters were a dead match.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Post Edited (Oldbitcollector) : 10/23/2007 4:18:27 AM GMT
Do you mean 'pixel tinting' ( the best words I can think to describe it ? ... I altered the background colour and borders to black and I've seen that since I started with the previous font. I suspect it was there all along but I didn't notice it with the retro-blue background.
The actual tint colours seem to vary slightly depending on the foreground/background colour, and also changes across the screen. Create some characters with single pixel vertical or horizontal lines and it's more noticeable.
Added : Just tried the CBM font; you're right it is somewhat more tinted. I don't know if you're seeing the same as me, but on my TV the tint seems to change mainly when there's a pixel which is on but not on in the above/below line, or something like that.
Post Edited (hippy) : 10/23/2007 6:07:01 AM GMT
That's exactly what it is, and that's the major reason why the retro-blue backgrounds were in common use with the home computers that used a NTSC display. White on blue really is one of the better colors to avoid such, and its contrasty enough to read easily, so I would say that the default colors of the 8x8 text driver should be this rather than a black background.
The original Amiga workbench 1.x also had high contrast colors, as they had support for composite/RF out.
-Wes
Unfortunately that caused me a problem ... I've entirely rewritten the driver based on the demo ( which says a lot for the implementation and quality there ) and it's working fine except ( using just a fixed text color ) if I put a character in the rightmost display column I get some random color artefacts at end of line. If I switch colors per character I also get colours in the horizontal flyback. I'm sure it was working so something is different to the earlier 8x8 .zips but I missed noticing it when it first appeared so cannot easily tell what the problem is.
I'm still trying to convert the driver to PAL and when I'm back in the right OS I'll check to see what the questions are I have to ask.