On 7/5/06, Diego Sáenz <[EMAIL PROTECTED]> wrote:
El Wed, 5 Jul 2006 18:48:10 -0400
"Timothy Miller" <[EMAIL PROTECTED]> escribio:
> On 7/5/06, Diego Sáenz <[EMAIL PROTECTED]> wrote:
> > Hello to the list. It seems that there is no vbp subrutine in the example.
>
> The vblank routine works for both vfp and vbp. Unless I forgot something?
I speak about this two lines:
CALL [+v,-h,-d] #1 vbp+1
CALL [+v,-h,-d] #1 vbp
For your comment i think that it must be
CALL [+v,-h,-d] #1 vblank+1
CALL [+v,-h,-d] #1 vblank
Yes, you are right.
To see if i have understand correctly the video controler y send a version of
interlaced 640x480 based in your example.
Timings not modified so surely bad
Good. We need to do that sort of thing.
; Simple interlaced 640x480 program
; hfp = 8
; hsync = 8
; hbp = 8
; vfp = 3
; vsync = 3
; vbp = 3
; vsync,hsync negative-assertion, data-enable positive assertion
; Entry point
.addr = 0
; Vertical program
; First even lines
ADDR [-v,-h,-d] 0 ; vid addr = start of framebuffer
CALL [-v,-h,-d] #1 vsync+1
CALL [-v,-h,-d] #2 vsync
CALL [+v,-h,-d] #2 vblank ; back porch
FETCH [+v,-h,-d] #640 ; Fetch for first scanline
One thing I forgot: When fetching, divide by 8. When sending, divide
by 4. So, this fetch should be for 80.
CALL [+v,-h,-d] #1 vsync+1
CALL [+v,-h,-d] #1 vsync
CALL [+v,-h,-d] #239 vactive
NOOP [+v,-h,-d] ; Already fetched last scanline
CALL [+v,-h,-d] #1 vactive+1
CALL [+v,-h,-d] #2 vblank ; front porch
CALL [+v,-h,-d] #1 vblank_short
; 2nd semiframe odd lines
ADDR [-v,-h,-d] 640 ; vid addr = first odd line of framebuffer
CALL [-v,-h,-d] #1 vsync+1
CALL [-v,-h,-d] #2 vsync
CALL [+v,-h,-d] #2 vblank ; back porch
FETCH [+v,-h,-d] #640 ; Fetch for first scanline
CALL [+v,-h,-d] #1 vsync+1
CALL [+v,-h,-d] #1 vsync
CALL [+v,-h,-d] #239 vactive
NOOP [+v,-h,-d] ; Already fetched last scanline
CALL [+v,-h,-d] #1 vactive+1
CALL [+v,-h,-d] #2 vblank ; front porch
CALL [+v,-h,-d] #1 vblank_short
JUMP [+v,+h,-d] 0
I modified the design so that the last 3 instructions here can be replaced by:
CALL [+v,-h,-d,ret] #3 vblank
That is, a return from the top level resets the program counter to start.
vsync:
NOOP [-v,-h,-d] #1 ; last 4 pixels of hsync
NOOP [-v,+h,-d] #2 ; back porch
NOOP [-v,+h,-d] #640 ; active period, but vblank
NOOP [-v,+h,-d,ret] #2 ; front porch
vblank:
NOOP [+v,-h,-d] #1 ; last 4 pixels of hsync
NOOP [+v,+h,-d] #2 ; back porch
NOOP [+v,+h,-d] #640 ; active period, but vblank
NOOP [+v,+h,-d,ret] #2 ; front porch
vblank_short:
NOOP [+v,-h,-d] #1 ; last 4 pixels of hsync
NOOP [+v,+h,-d] #2 ; back porch
NOOP [+v,+h,-d] #640 ; active period, but vblank
NOOP [+v,+h,-d,ret] #1 ; front porch
vactive:
FETCH [+v,-h,-d] #1 ; last 4 pixels of hsync
INC [+v,+h,-d] 640 ; skip a line
NOOP [+v,+h,-d] #1 ; back porch
SEND [+v,+h,-d] #640 ; active period, but vblank
NOOP [+v,+h,-d,ret] #2 ; front porch
Move the INC to after the SEND. The FETCH will take half the
scanline, during which the memory address is counting. You have to
wait until the counter is idle before incrementing it.
But you have the right idea!
After the INC, you need another two cycles for the sum to complete, so
you can't use a FETCH right away. So, right after SEND, do the INC,
then the rest of the fp; any other cycles will be absorbed in the
CALL, the sync, and the bp. (SEND reads from the other end of the
FIFO, so it's independent of that.)
.end
Now a lot of doubts:
How do you put the cursor in a (pixel_pos & 3 != 0) position if each video word
is 4 pixels?
I posted the cursor code earlier, but I haven't checked it into SVN.
The idea is that the cursor position increments by 4 each cycle, but
you ca have the lower 2 bits set to something other then zero. The
cursor overlay code then handles the shifting.
If i understand it you need to change the video controler program each time the
cursor position changes and it can need to unroll counter loops breaking a word
in two.
No. The cursor overlay code intercepts the pixels coming out of this
block and mixes the cursor in. The coordinates coming out are just
for convenience; we could infer them from data-enable and syncs if we
wanted to.
I do not see a clean way to change video controler program in a vertical
retrace. Only writing the new program after the old and then overwriting the
old program jump 0 with a noop.
Yes. You would want to halt it, reprogram it, and reset it when
changing the program. SOME minor changes would be okay, like changing
the starting address for panning. (For fine-grained panning, you need
ADDR followed by INC at the top.)
About the free bit i can only think in extend the opcodes with a move opcode
like the amiga copper one, but i do not known if it is usefull or if video
controler is the right place.
Another idea can be a pair of opcodes to store and restore internal registers
to break the call stack limit and allow some tricks. Useless again?
We need to have a look at serration pulses. We might need to use the
extra opcode and bit for that. I can't remember.
>
> > Software code to stress-test any OGP/Traversal product
> > HDL code to stress-test OGD1 boards
> > HDL code
> > Layout/Schematic design
>
> Awesome. We could definitely use your help!
What i was trying to do was to order the task list of the wiki by
qualification. I must admit that i can help very little at the 2 last, nothing
at layout design :(
Oh, that's alright. Everyone finds a way to be helpful!
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
