David Kuehling wrote: > wow this looks great. What kind of resolution is possible with this > approach?
I don't quite know yet. I've tried some higher resolutions but didn't get stable images. My old XEN-1510 monitor seems to be happy enough with the 1024x768 vertical timing (1024x768 is that monitor's maximum) but gets confused with the horizontal timing. At 800x600, things look better, there's still too much horizontal flickering going on. The MMC controller can go up to twice the clock rate I've used for 640x480, so 1024x768 with a similar pixel clock (about 20-30% slow) might be feasible. One general problem with the timing is that it's generally very unstable and there appears to be a memory effect: once I find a stable timing, it work basically all the time, but if I try some different timing and then return to the know to be good timing, it all of a sudden fails and I need to tweak parameters until I "catch" another good timing. Or I can just let it rest and it'll work fine on the first try after I return from a nap. I'm not sure yet what this is. Possible explanations would be some aliasing, where some timing is actually far off, but we just happen to synchronize on some other event that occurs at the right time, or small timing variations that are modulated on the base timing and that confuse the monitor's clock synchronization. The monitor seems to use PLLs to track the signal timing, which could be susceptible to modulation of their reference clock. I suspect there's also a something the monitor's firmware remembers about the signal it found. Maybe there's even a timeout after which it tries a wider range of possible settings. (Just power cycling doesn't do the trick.) > You're still using double-scan (sending every line twice)? I still had the double-scan it at the beginning, but I now do real VGA. When converting the Ben's frame buffer, I just put each pixel four times. > Guess we could use the extra pixels to do some dithing for showing > more colors. Yup, that would be possible. Now with the PPM input, one can also precompute an image at the full VGA resolution and display that. I should also add a raw mode where the color mapping gets bypassed. > Maybe even some temporal dithering, if the flicker is > acceptable? Hmm, you could have multiple frame buffers, yes. Flicker would depend on what vertical frequency the monitor is willing to accept. At least at VGA resolution, we could send up to twice the current pixel clock, so something like "100 Hz" should be possible. > When running the VGA port, any chance that other software can still > execute in parallel? That would be nice, wouldn't it ? :-) So far, things don't look too promising, though. Even turning on the LCD refresh throws off the timing badly. I also think that I don't have much of a time budget left in the periods before and after the pixel data, i.e., front and back porch, and hsync pulse. If I can get multi-block operations to work, I could use DMA, which may make things easier. For the hsync pulse, I'd still need a low-latency timer interrupt plus a delay loop for fine-tuning. (The total time budget is about 25 us, so the timer would have to be set to t0 + 25 us - maximum interrupt latency. Then, the driver would have to busy-loop until the end of the line or the beginning of the next line.) Oh, something you could do right now is pre-compute a short video sequence. One VGA frame is 150 kB, so you should be able to squeeze at least 2 seconds of video at 50 fps into the Ben's little memory. More if you pick a lower frame rate and do pixel/line duplication on the fly. > Just speculating how your code could be reused as an mplayer vidix > video-out driver :) Hehe, the Ben home entertainment system ;-) Would also be nice to be able to run an X server with VGA output on it. - Werner _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
