Below there is a reply to a mail not received in the list and that mail.
El Thu, 6 Jul 2006 07:53:50 -0400 "Timothy Miller" <[EMAIL PROTECTED]> escribio: > 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. I hoppe the video controler assember do that :P > > 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. do you mean 0 with 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. Please, explain this. > > > > > > > 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)
