On 7/15/06, Patrick McNamara <[EMAIL PROTECTED]> wrote:
I have been looking at the code for the video controller. The idea is that this code is generated and loaded based on the X modeline or similar specifications. Following is a generic progressive scan program that should handle any timing we support. It is pretty well commented, though it will not compile with the compiler I wrote because there is a fair amount of math in some of the arguments that the compiler doesn't support yet. The macros at the top set the timing at compile time.;; Progressive scan output program. This program should support all ;; resolutions and timings of which the hardware is capable. The ;; following macro definings will control the display timing, ;; framebuffer location, and panning. No other program changes are ;; necessary.
That's pretty sweet what you did. BTW, I think it's important to ultimately have a C program to do this so we can embed the compiler into kernel and X11 driver code. This way, instead of embedding lots of precompiled video modes, we just embed the compiler. Should be simple enough. The video compiler C code should be a single function (or entry point--you can have it call other functions) that takes parameters as inputs and pointer to an array of ints as outputs, and it'll just produce code directly. I see the elegance of having an assembler that uses macros and defines, but this is best given as a reference for documentation purposes. Typically, I want people to just take this BSD/MIT licensed bit of code and drop it into their driver and go. Most drivers will be written in C, so this makes the most sense to me. Also think about embedded systems that won't have the luxury of running an external program to generate video code.
Here is another though. Rather than include immediate values in the opcodes, use a register bank. Something like this:
Oh, interesting. I hadn't thought of that. The only reaction I have right off is that it might not be possible due to the fact that we're talking about the critical path in the controller. That is, we could jam it in there, but the extra levels of logic would make the max clock rate too slow. Still, it's an elegant idea. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
