[Open-graphics] Inconveniences with the video controller

[Timothy Normand Miller]

On 6/25/07, Paul Brook <paul at codesourcery.com> wrote:

> Is this worth the hassle compared to just rerunning the VC program generator?

Well... that's hard to say.  Keep in mind that the program is running
while this is happening.  Generally speaking, as long as nothing
structural is changed (moving program-control or changing loop
counts), it's safe to change it while it's running.

>
> If regenerating the whole program is undesirable, I suggest generating two
> functions: The existing function that generates a whole program, and a second
> function that just modifies the frame base of an existing program. Maybe have
> it return the region of the program that has been modified. That way all
> knowledge of the VC instruction set is confined to one place.

This might be the best solution.  The assembler would generate
multiple utility functions in the output C code.  And those would all
be based on the original asm code so they'd be reliable.

>
> > Example:  knowing when you're in vertical blank
> >
> > Windows drivers want to know when you're in vertical blank and when
> > you're not.
>
> Could we use the cursor position for this? Or expose the VSYNC signal?
>

The cursor position isn't so straightforward.  The numbers start out
negative and increment through positive values where the cursor is to
be displayed.  You'd have to look up where you put the cursor to make
sense of the numbers.

And vsync itself isn't asserted for the whole blanking period.

I guess we could count hsync rising edges (which would work for either
polarity) from the top of the program.


Thanks.

-- 
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project