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! |
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'. 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. |
Page 41 of 41 | All times are UTC |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |