BTW: I like ozpropdev's example code here because it shows how to have the basic functions, like setting a pixel, drawing a line, etc. in cog RAM and also have the same cog run HUBEXEC code that calls on the cog functions.
Rayman,
What's the native resolution of the panel? If the panel is doing scaling, then you will get fuzziness for any resolution that isn't an exact multiple of the panels native resolution.
It's most important for fonts that the width be an exact multiple, and 640 goes into 1280, 1920, 2560, etc. nicely, while 800 and 1024 don't.
Comparing VGA and SVGA and WSVGA showing image of 8x16 font...
Have to say the VGA version is much better.
Maybe the real P2 will be better.
Or, maybe monitors try extra hard to do 640x480 right.
I guess I could use a bigger font, but that approach would seem to just use more memory for about the same result.
First is WSVGA, then VGA, then SVGA.
WSVGA is pretty fuzzy. SVGA isn't that bad but some pixels come out off or fuzzy.
The VGA appears near perfect...
I've got to say, when I see those VGA pictures I get excited, because I imagine that whatever is behind that is probably totally reliable and tight, unlike everything else today. I get excited because I imagine being able to get work done without any surprises or hang-ups. Trying to work on PC's today is maddening for me. While the PC does more than ever, it continually has me on edge and quite uncomfortable.
The std report is for 720 x 400 @ 70Hz , which is needed during PC Boot, so I doubt that is going away ever.
640x480 just might be different enough to have issues ?
I've found the auto-scale engines in Monitors, to be a little fussy around those areas.
To decide on centre, and clocks, I think they use those image-edges in the decision process, whilst the ancient CRT could not care less....
BINGO!!!
I was pretty happy with 640x400 8bit until I started playing with Ray's font editor and dropped the resulting bitmap onto an image... the font bitmap is all 0 or 255's. The monitor just displayed a hug black hole until I changed the bitmap to be either 0 or 128's. At first I thought maybe it was a problem in the image processing step, producing a faulty look up table from the combined bit maps. But after playing with the images a bit and reading your comments, I am thinking that my monitor just doesn't know what to do with the image.
I'm going to look at 720x400.
Ray
Are those images taken directly from your FONT EDITOR?
The std report is for 720 x 400 @ 70Hz , which is needed during PC Boot, so I doubt that is going away ever.
640x480 just might be different enough to have issues ?
BINGO!!!
[/quote]
I was playing with Ray's FONT EDITOR and when I dumped Ray's bitmap image into an existing bitmap, the result was a black hole where the font should have been. Originally I thought the image processing (ImageJ) was responsible, but after playing with it for a while, I don't think that is the problem.
Originally I thought the image processing (ImageJ) was responsible, but after playing with it for a while, I don't think that is the problem.
Not sure what is going on... didn't change my set-up or software, now the images are fine. The only thing I did was go back and see what Chip's driver did... it was fine and when I came back to my own version, it was fine too.
IDK... time to watch the CUBS... no spoiler alerts, I dvd'd it;
Interestingly, both my monitors recommend 1920x1080 for optimal resolution even though they have different aspect ratios and native resolutions.
Anyway, I hack'd ozpropdev's driver to do 1/4 of that.
960x540 with 80 MHz dot clock comes out close to the 60 Hz it wants.
This looks pretty good, but there are a couple of minor issues:
1. The horizontal porch settings appear to be different between monitors.
2. There is a slight ghost artifact in the horizontal direction. Faint, but noticeable.
3. Something is wrong with my hacked driver and it outputs one more horizontal line than I asked for.
So, #1 isn't so bad. Worst case, can read settings from monitor via I2C.
#2 may be improved with real P2 at higher freq. or maybe some delay between clock and data.
#3 is weird. I had to add a line to the video buffer so it wouldn't show noise... Not sure what's wrong...
Anyway, I'll post that code here even though you would probably need to modify the porch settings to make it work.
Interestingly, both my monitors recommend 1920x1080 for optimal resolution even though they have different aspect ratios and native resolutions.
Anyway, I hack'd ozpropdev's driver to do 1/4 of that.
960x540 with 80 MHz dot clock comes out close to the 60 Hz it wants.
This looks pretty good, but there are a couple of minor issues:
1. The horizontal porch settings appear to be different between monitors.
2. There is a slight ghost artifact in the horizontal direction. Faint, but noticeable.
3. Something is wrong with my hacked driver and it outputs one more horizontal line than I asked for.
So, #1 isn't so bad. Worst case, can read settings from monitor via I2C.
#2 may be improved with real P2 at higher freq. or maybe some delay between clock and data.
#3 is weird. I had to add a line to the video buffer so it wouldn't show noise... Not sure what's wrong...
Anyway, I'll post that code here even though you would probably need to modify the porch settings to make it work.
Solid. I don't see any ghosting... could it be my eyes?
I think jmg is right. 480p should be supported forever and probably has the most robust industry support.
For imaging, I think I will stick with 8-bit 640x400. It looks great, fills the whole screen and I don't care about aspect ratios:). I can get a 16 PropCam array on screen with a messaging area, squeeze in a full off-screen buffer and still have ~512KB to play with. The only change from ozpropdev's setting was to put nearly all of the blanks at the top. You have to use at least 1 bottom blank or it doesn't work.
I have a touch of dry eye and multifocal implants, so from time to time, everything looks
like it is coming from a slight mist. Which might account for why I sometimes have trouble
seeing the forest from the trees:)
Comments
I'm pretty sure this works will all monitors.
Did you mean 25.175MHz ?
http://martin.hinner.info/vga/timing.html
http://tinyvga.com/vga-timing/640x480@60Hz
Remembered that streamer requires that buffer be long aligned.
Added orgh, like this to fix it:
But, there's a problem with the nibble order from the streamer.
Had to change S in this line from 0 to %100:
Going to have to change the code in some other places to account for this though...
Have to say the VGA version is much better.
Maybe the real P2 will be better.
Or, maybe monitors try extra hard to do 640x480 right.
I guess I could use a bigger font, but that approach would seem to just use more memory for about the same result.
First is WSVGA, then VGA, then SVGA.
WSVGA is pretty fuzzy. SVGA isn't that bad but some pixels come out off or fuzzy.
The VGA appears near perfect...
What's the native resolution of the panel? If the panel is doing scaling, then you will get fuzziness for any resolution that isn't an exact multiple of the panels native resolution.
It's most important for fonts that the width be an exact multiple, and 640 goes into 1280, 1920, 2560, etc. nicely, while 800 and 1024 don't.
I've got to say, when I see those VGA pictures I get excited, because I imagine that whatever is behind that is probably totally reliable and tight, unlike everything else today. I get excited because I imagine being able to get work done without any surprises or hang-ups. Trying to work on PC's today is maddening for me. While the PC does more than ever, it continually has me on edge and quite uncomfortable.
We get that bench computer back. Not like we don't have it now, but the overhead will be a fraction of what it is now.
I'm gonna hunt down the killer SGI bitmap fonts to celebrate finally being able to fire mine up again.
Back soon.
BINGO!!!
[/quote]
I was playing with Ray's FONT EDITOR and when I dumped Ray's bitmap image into an existing bitmap, the result was a black hole where the font should have been. Originally I thought the image processing (ImageJ) was responsible, but after playing with it for a while, I don't think that is the problem.
Has to be the way my monitor is looking at it.
Rich
Not sure what is going on... didn't change my set-up or software, now the images are fine. The only thing I did was go back and see what Chip's driver did... it was fine and when I came back to my own version, it was fine too.
IDK... time to watch the CUBS... no spoiler alerts, I dvd'd it;
Thanks again.
Rich
That's to do with (not) balancing your start & end quote tokens.
Anyway, I hack'd ozpropdev's driver to do 1/4 of that.
960x540 with 80 MHz dot clock comes out close to the 60 Hz it wants.
This looks pretty good, but there are a couple of minor issues:
1. The horizontal porch settings appear to be different between monitors.
2. There is a slight ghost artifact in the horizontal direction. Faint, but noticeable.
3. Something is wrong with my hacked driver and it outputs one more horizontal line than I asked for.
So, #1 isn't so bad. Worst case, can read settings from monitor via I2C.
#2 may be improved with real P2 at higher freq. or maybe some delay between clock and data.
#3 is weird. I had to add a line to the video buffer so it wouldn't show noise... Not sure what's wrong...
Anyway, I'll post that code here even though you would probably need to modify the porch settings to make it work.
Solid. I don't see any ghosting... could it be my eyes?
I think jmg is right. 480p should be supported forever and probably has the most robust industry support.
For imaging, I think I will stick with 8-bit 640x400. It looks great, fills the whole screen and I don't care about aspect ratios:). I can get a 16 PropCam array on screen with a messaging area, squeeze in a full off-screen buffer and still have ~512KB to play with. The only change from ozpropdev's setting was to put nearly all of the blanks at the top. You have to use at least 1 bottom blank or it doesn't work.
... which is not a bad thing.
I have a touch of dry eye and multifocal implants, so from time to time, everything looks
like it is coming from a slight mist. Which might account for why I sometimes have trouble
seeing the forest from the trees:)
Nice work.