----- Original Message ---- From: Timothy Miller <[EMAIL PROTECTED]> To: Patrick McNamara <[EMAIL PROTECTED]> Cc: Open Graphics Project List <[email protected]> Sent: Thursday, July 13, 2006 11:39:10 AM Subject: Re: Questions about the video controller...
> Possibly. I've already found a couple of minor bugs... > >> vactive: >> FETCH [+v,-h,-d] #1 ; last 4 pixels of hsync <--- Should this be #640? > > It should be pixels/8. (80 for this) > >> NOOP [+v,+h,-d] #2 ; back porch >> SEND [+v,+h,-d] #640 ; active period, but vblank > > And this should be 160. > Somebody had earlier mentioned that this translation should probably be handled at the compiler level. I tend to agree. I had updated my compiler to do the appropriate scaling of the operands. > Anyhow, the way it works is we have config registers that have the > initial counter values. When the cursor flags indicate "reset", then > the counter resets to that config value. When the flags mean to > increment, they increment. The cursor block is then designed to check > when the cursor coordinate values are within range of the cursor. > Changing the config registers changes the position of "in range". The lightbulb just went on. :) Pretty much, we turn on the x increment flag as we clock out valid pixels. When we switch lines (somewhere in the hsync period), we assert the y increment flag for one cycle. When we hit the vsync period, we assert the reset flags. Is that pretty close to correct? > I think so, but I can't say 100% for sure. I went digging some more in the fb.conf files and could not find a hsync or horiz porch value not divisible by 8. 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)
