6502.org
http://forum.6502.org/

Concept & Design of 3.3V Parallel 16-bit VGA Boards
http://forum.6502.org/viewtopic.php?f=10&t=2247
Page 41 of 41

Author:  ElEctric_EyE [ Wed Oct 23, 2013 11:37 pm ]
Post subject:  Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

I've managed to accomplish something useful today. Maybe learned something with concatenation operator, {}, in Verilog. I will post a question in the proper thread...
10 circles on 5 PVB's. 1 circle plotted on page 1 of video memory, and a second circle on page 2. Same radius same color per board. Then they are scrolled horizontally left first back to the origin, then vertically back to the origin. Each board has it's own delay value, radius and each color is representative of each PVB output. Will have the video up on Youtube soon. Will post a link here.

http://www.youtube.com/watch?v=mRPOLg2Lmu8

Not perfect, but close! :mrgreen:

Author:  ElEctric_EyE [ Wed Oct 30, 2013 6:58 pm ]
Post subject:  Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Some major changes have been made to the project: There used to be 3 control bits from the cpu to various modules: CB0 for page 0 or page 1. CB1 for page flipping or scrolling and CB2 for scrolling horizontal or vertical. Also at this point I was having difficulty meshing the horizontal scrolling with the vertical scrolling. Also, I was using 2 11-bit offset registers in the form of 2 Accumulator registers pulled off of the 65Org16.b core. The O accumulator adds offset in the vertical, and the N accumulator for the horizontal offset.
Now I still use those registers, but only 1 control bit for the same functions goes to the SRAM interface module, CB0 for controlling resolution to maximize the 2MBx18 video RAM usage, either CB0 = 2048x1024 or !CB0 = 1024x2048. Also, CB0 will allow the hardware line/circle generator to plot offscreen in the set direction. The appropriate offset accumulators are used to page flip and scroll by adding the desired amount. Now they should be able to scroll diagonally. This will be the end-test for successful horizontal and vertical scrolling. That is the next...

BTW, I will be updating the header over the next few weeks. A new section will be added, called the 'Captain's Stardate Log'. :lol: Consider it an ongoing chapter reference that one can use to navigate through this long blog of a thread.

Anyway, here is my algorithm for the vertical and horizontal scrolling. I remembered finally from earlier testing (with higher priority problems present), that I had to pull the high bit out of the X for the MSb:
Code:
// optimize the SyncRAM address from the CPU for plotting.
// (X,Y) in the (LSB(byte=16bit),MSB(byte=16bit)) for indirect indexed on the 65Org16.b CPU address bus, in different plotting/scrolling modes
reg [20:0] cpuABopt;

always @*                                        
      if ( CB0 ) begin                                                // scrolling horizontal, 2048x1024
         cpuABopt [20:11] <= cpuAB [31:16] + OACCout [9:0];            //Y [9:0]
         cpuABopt  [10:0] <= cpuAB [10:0] + NACCout;                  //X [10:0]
      end
         else begin                                                   // scrolling vertical, 1024x2048
            cpuABopt [20:10] <= cpuAB [31:16] + OACCout;               //Y [10:0]
            cpuABopt   [9:0] <= cpuAB [9:0] + NACCout [9:0];         //X [9:0]
         end
      
//MUX the line generator, cpu and video pixel addresses to the external SyncRAM
always @*
      if ( CB0 ) SRaddr <= RAMWE ? { X1 [10] + OACCout [10], Y1 [9:0] + OACCout [9:0], X1 [9:0] + NACCout [9:0] }             // horizontal
                        : vramCS ? cpuABopt : { X [10] + NACCout [10], Y [9:0] + OACCout [9:0], X [9:0] + NACCout [9:0] };   
         else    SRaddr <= RAMWE ? { Y1 + OACCout, X1 [9:0] + NACCout [9:0] }                                                 // vertical
                        : vramCS ? cpuABopt : { Y + OACCout, X [9:0] + NACCout [9:0] };


EDIT: This is more correct, didn't need the cpuABopt register. :
Code:
//MUX the line generator, optimised-cpu and video pixel addresses to the external SyncRAM address
always @*
      if ( CB0 ) SRaddr <= RAMWE ? { Y1 [9:0], X1 }                         // horizontal
                        : vramCS ? { cpuAB [25:16], cpuAB [10:0] }
                        :          { Y + OACCout [9:0], X + NACCout };   
         else    SRaddr <= RAMWE ? { Y1, X1 [9:0] }                         // vertical
                        : vramCS ? { cpuAB [26:16], cpuAB [9:0] }
                        :          { Y + OACCout, X + NACCout [9:0] };

Author:  ElEctric_EyE [ Sat Nov 23, 2013 3:36 pm ]
Post subject:  Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

ElEctric_EyE wrote:
I guess this is a question more for Arlet since I'm using his HVSync module, but anyone feel free to post.
I have both boards working, but I have a problem syncing 100% to the first board...

I posted this back in Aug 14th.
I can now say I finally understand how to Sync to an incoming video signal and center all incoming video streams. After 3 months of wrestling with Verilog code trying to implement the idea, I finally understand what I was doing wrong!
Using Arlet's original HVSync generator I was resetting the Horizontal state machine just based on HSyncin alone. The same error for the Vertical state machine utilizing the VSYNCin.
I just found that this was incorrect...
2 days ago, I was thinking how does one board start to display it's signal? Answer: when both HSync and VSync outputs go high.
So resetting the STATE of the Horizontal and Vertical state machines based on the logic input signals (HSYNCin & VSYNCin), the picture was very close.
Now, resetting the horizontal counters and vertical counters to some specific values achieves the fine adjustment to center the pictures perfectly!

Also, I like his newer HVSync module found in this thread. I'm currently using it on all the boards and have 5 boards sync'd. Thanks!

This is exciting for me, because the soon to be designed controller board will be outputting it's own video stream from a camera.
Now I have full confidence the 5 PVB's will be locked on.

Author:  ElEctric_EyE [ Sun Dec 01, 2013 1:31 am ]
Post subject:  Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

With 5 boards correctly working and in Sync I began to think a buffer page would be a bit redundant. Currently the system(s) are running @ 70MHz for a 1024x768 resolution utilizing <50% of the SyncRAM for a single display page....
I removed the slower Cypress SyncRAM (133MHz) on the output board (v1.0h) and replaced it with the much faster GSI part (400MHz). Now all 4 boards are running with GSI SyncRAMs @70MHz successfully.
One board lays dormant awaiting a GSI SyncRAM part.
I would like to try to bump up the pixel rate to ~170MHz for a resolution of ~1600x1200...

Author:  ElEctric_EyE [ Tue Dec 17, 2013 11:24 pm ]
Post subject:  Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

I would like max each PVB's 2Mx18 SyncRAM usage by utilizing a single display page of 1920x1080.
This is going to require losing the 65Org16.b core on each PVB and creating a state machine to take advantage of the 8-bit parallel data lanes which will allow each PVB to run @ max speed, which has yet to be determined.

Presently ISE is telling me max speed of each PVB is 96 MHz with the 65Org16.b core present on each board (in order to easily test graphic functions), so I would expect the state machines to run at least 2x this speed initially.

Also it means I must finish re-designing and programming the K1 controller board. The 65Org16.b will not be sufficient in this regard as it only has a 16-bit databus.

The PVBs take advantage of 2 extra parity bits in the 18-bit video RAM. I will most likely pursue and develop a 65Org32 softcore after successful tests of the K1 controller board.

For the K1 controller board I had envisioned a camera module. As a camera module, it would have led the project towards a security type project, but...

Now I would like to try to make this into a simple DVR with great possibilities of video overlaying, with an RGB input.
There are many choices I am considering, most packages seem to be QFP.

Author:  BigEd [ Wed Dec 18, 2013 9:47 am ]
Post subject:  Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Hi EEye
sounds like maybe this new adventure deserves a new thread?
Cheers
Ed

Author:  ElEctric_EyE [ Tue Dec 31, 2013 11:03 pm ]
Post subject:  Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

I'm still making progress towards making these PVB's standalone units and finishing the controller board.

The hardware scrolling has been fixed with a realization. The simple method I am using by scrolling in a full page @1024 ([9:0] bits) x768 ([9:0] bits) with a 2M RAM ([20:0] bits), it can do either horizontal or vertical scroll, not both like for a diagonal scroll, and when switching between horizontal and vertical the screen must be cleared first. The realization is that a 2M RAM has an odd number of address pins. :? When scrolling horizontally, the code looks at 2048 ([10:0]) x 768 ([9:0]), actually 2048x1024. When scrolling vertically the RAM arrangement is 1024 ([9:0]) x 2048 ([10:0]). I could have done what I wanted to do at this resolution with a 4M ([10:0] x [10:0]) device, but diagonal scrolling is not at the top of my list.

Enough of that headache!

So, my state machine is growing larger, also some modules absorbing other modules. I made a hardware clearscreen, which I fine tuned into a region fill. So far the state machine only transmits data to the videoRAM with no consideration of what the vga module is doing, so there is a snow effect when plotting. Now I have hardware lines, circles and a square fill @35MHz. The cpu can copy and paste portions of the videoRAM @35MHz, which is 1/2 speed of the 70MHz pixel clock.

Author:  ElEctric_EyE [ Sun Jan 05, 2014 1:40 am ]
Post subject:  Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Currently running Arlet's HVSync module @180MHz with the 65Org16.b running @ 90MHz for 1920x1200 resolution. I have to run smartExplorer to get the project to pass the speed constraints.

Also all the HVSync timing parameters now have programmable registers, which are working and being programmed by the 65Org16.b, but the values are not yet perfect for the monitor. EDIT: Woops, 1200 vertical exceeds the 2MB RAM I'm using. Will Aim for 1920x1080. That will utilize 2,073,600 out of the available 2,097,152 memory.
Code:
      32'h8000_0016: htiming[VIDEO] <= cpuDO;   //    htiming[VIDEO] = 1920;
      32'h8000_0017: htiming[FRONT] <= cpuDO;   //    htiming[FRONT] = 128;
      32'h8000_0018: htiming[SYNC]  <= cpuDO;   //    htiming[SYNC]  = 208;
      32'h8000_0019: htiming[BACK]  <= cpuDO;   //    htiming[BACK]  = 336;
      32'h8000_001A: vtiming[VIDEO] <= cpuDO;   //    vtiming[VIDEO] = 1080;
      32'h8000_001B: vtiming[FRONT] <= cpuDO;   //    vtiming[FRONT] = 62;
      32'h8000_001C: vtiming[SYNC]  <= cpuDO;   //    vtiming[SYNC]  = 3;
      32'h8000_001D: vtiming[BACK]  <= cpuDO;   //    vtiming[BACK]  = 168;


Currently the output is going into an older 27" Viewsonic TFT monitor. I resurrected this monitor after 3 years of use. The cheap capacitors were overused in the digital switching power supply and so I had to replace them all with a similar Ebay kit costing $18 in order to get it back up and running, which it has been functional now for over a year. I value it more than another 1080p higher contrast monitor I had used yesterday for initial testing.

Author:  ElEctric_EyE [ Tue Jan 07, 2014 5:34 pm ]
Post subject:  Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards

Flat panel displays are a whole different beast I've discovered. Older ones seem to recognize a wider array of HSYNC/VSYNC/pixel freq's. They will display them, but some parts of the pixel display may be fuzzy.
Now, I've been doing research into TFT/LCD flat panel display freq's in their owner's manuals to find out the exact HSYNC/VSYNC/pixel freq's expected.
For 1920x1080, I got it to work on the old viewsonic at a pixel clock of 140MHz, much lower than I expected but some parts were blurry. Not acceptable.
This will not work on my ASUS MT276HE, which is why I am currently doing research into the owner's manuals of other flat panel displays of newer production, in order to see what the expected freq's are for 1920x1080p.

This is from the MT276HE manual, it should be no problem getting a proper display soon:

Attachments:
LCD op modes.jpg
LCD op modes.jpg [ 162.69 KiB | Viewed 1662 times ]

Page 41 of 41 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/