Timothy Miller wrote:
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.
I was about to complain about how ugly and hard coded this would be, but
as I was browsing back through the assembler code, I had a small idea
that I think will provide a workable and still flexible solution. More
details at the end of the message.
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.
I was thinking about this on the way to dinner and kind of came up with
the same thoughts. You would add at least one level of delay in the
form of a mux to select the register to read. And since the arguments
are not part of the instruction anymore, you can't begin execution
immediately after decode. You have to wait for the data to be ready. I
don't know how close the timings are on the current design though, so I
don't know what the impact would be. But, I think it may be a moot point
anyway.
We need the driver and/or BIOS to be able to compile the appropriate
arguments into the video controller program so that we can get any
possible video mode we can support and we need to do it without
embedding source code into the driver. What if we did the following.
Each defined assembler instruction is a C function call. It's arguments
are the same as the arguments to the assembler instruction. It returns
the compiled opcode. The assembler programs we have been writing are,
instead of being compiled, are written as a series of function calls.
The "compile" function takes the timing parameters, "compiles" the
program it contains by calling all the functions and either returns the
binary code, or uploads it. Below is a small example snippit that
represents the scanline routine from the code I posted earlier.
program[offset++]=asm_wait((hfp/4)-1, NULL);
program[offset++]=asm_inc(fb_offset, HSYNC);
program[offset++]=asm_wait(hsync-1, HSYNC | XRESET);
program[offset++]=asm_wait((hfp/4)-1, NULL);
program[offset++]=asm_fetch(vp_width, NULL);
program[offset++]=asm_send(vp_width, DATA_VALID | RETURN);
Where asm_wait(), wait for example looked something like this:
unsigned int asm_wait(unsigned int delay, unsigned char flags) {
unsigned int opcode=0;
opcode|=flags << 24;
opcode|=0x00E00000 & (ASM_WAIT_OP << 21);
opcode|=((2049 - delay) & 7FF) << 9;
return(opcode);
}
Please note that there are errors in the above code, I am sure. I just
typed it on the fly in this email to provide an example of what I was
thinking. I need to give some more thought to a good what to handle
labels and subroutine calls. It's not the most elegant way of writing
programs, but since we shouldn't need to write a whole lot of them it
think it would suffice.
Patrick M
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
