6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 7:14 am

All times are UTC




Post new topic Reply to topic  [ 155 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9 ... 11  Next
Author Message
PostPosted: Wed Oct 03, 2012 5:27 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Arlet, thanks for checking the sim.
Arlet wrote:
...The noise you're seeing could be from setup/hold time violations at the data inputs of the FPGA...

Could be, I don't see much noise on 1280x1024 using the CRT like I did with 1024x768. I tried looking at the 1280x1024 video through the flat panel display and noticed just a slight, barely noticeable, darker waves going up the middle of the screen. Like it might be power supply noise. Not noise on the edge of pixels. On the CRT with 1024x768, I did see some noise on the edge of certain colored pixels. More observation is needed. Maybe time to solder in the high frequency bypass caps...

I got 1024x768 & 1280x1024 working also, using 108MHz. I realized the problem with the value 1024 since it sits right on the boundary. Binary 1024 is 100_0000_0000, 11 bits. So one would assume to use [10:0] for the load registers, but this is not this case. I have to use [9:0] in order for the value 1024 to work.

Also, for 1280x1024 to display I had to increase the vertical front porch to 10 and decrease the vertical back porch to 29. A value of 1 for the VFP would not display.

Progress!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 03, 2012 5:40 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
ElEctric_EyE wrote:
I got 1024x768 & 1280x1024 working also, using 108MHz. I realized the problem with the value 1024 since it sits right on the boundary. Binary 1024 is 100_0000_0000, 11 bits. So one would assume to use [10:0] for the load registers, but this is not this case. I have to use [9:0] in order for the value 1024 to work.

[10:0] for the load registers should work too. It's okay to have more bits than you need. However, hcount should have 1 bit more than hload, and that bit should be tested for hcount_done.
I have this in my sims, and it works as expected:
Code:
reg [11:0] hcount = 0;          // down counter for horizontal state
reg [10:0] hload;               // next load value
reg [1:0] hstate = FRONT;       // horizontal state
wire hcount_done = hcount[11];  // done when count < 0


Quote:
Also, for 1280x1024 to display I had to increase the vertical front porch to 10 and decrease the vertical back porch to 29. A value of 1 for the VFP would not display.

It should be enough to increase front porch to 2. Due to pipeline delays, that's the minimum value.


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 03, 2012 6:23 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I will do more testing, I was sort of rushing, but I've made notes of the timings that have worked.

Had to do one last one today:320x200 :lol: :lol: :lol: Not really worth messing around with this low res without interlace capability. I have the 1280x1024 settings in one PROM and 320x200 in the other PROM. Takes about 2 seconds of black screen init time before switching...
Image

Working on the camera settings for a closeup of 1280x1024. Initial try was washed up, I think because the camera is compressing the pic...

Time for a beer! :mrgreen:

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 03, 2012 7:31 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Arlet wrote:
[10:0] for the load registers should work too. It's okay to have more bits than you need. However, hcount should have 1 bit more than hload, and that bit should be tested for hcount_done...

Now that I've all the timings down I went back and rechecked 1024x768. It works with:
Code:
// horizontal counters and state
reg [10:0] hcount = 0;      // down counter for horizontal state
reg [9:0] hload;      // next load value

and
Code:
// horizontal counters and state
reg [11:0] hcount = 0;      // down counter for horizontal state
reg [10:0] hload;      // next load value

with the appropriate hcount value (either 10 or 11) set in 'x':
Code:
wire hcount_done = hcount[x];   // done when count < 0


Well, this just about brings a close to this thread, now that the initial goals stated in the header have been reached...

Although I would like to get my hands on the algorithm for coming up with the timings based on desired resolution.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 03, 2012 7:40 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
ElEctric_EyE wrote:
Although I would like to get my hands on the algorithm for coming up with the timings based on desired resolution.

Here's an explanation (section 10 and 11)
http://www.linuxdoc.org/HOWTO/XFree86-V ... index.html


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 03, 2012 9:02 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Excellent reading there. I think it might be desirable to do a power-up test from the lowest resolution to the highest resolution to test a monitor's functionality, then pop back to 640x480x60Hz and ask the user if all resolutions were visible, each resolution having a number in the upper left. An interactive self-test.

This is the code I have for the 2 main modules that display 1280x1024. The first is a modified version of your code, running on one clock:
Code:
/*
 * vga.v
 *
 * VGA timing generator
 *
 * This module only generates the VGA sync signals and control signals
 * for the actual video generator. Add a suitable video generator to
 * create real outputs.
 *
 * +-------+       +-----------------+
 * | vga.v | ----> | video generator | ----> RGB outputs
 * +---+---+      +-----------------+
 *     |
 *     `-----------------------------------> Hsync/Vsync ouputs
 *
 * The hstart/vstart and blank signals are short enable pulses with a
 * width equal to the pixel clock (pclk). They are intended to drive
 * a state machine in the video generator. All outputs are fully
 * registered. The 'hstart' pulse signals that next pclk will shift out
 * the leftmost pixel of each line. The 'hblank' pulse signals that the
 * next pclk must be blanked. Likewise, the 'vstart' and 'vblank' enables
 * do the same thing for vertical blanking, but with less precise timing.
 *
 * So, use the vstart/vblank to update state machine, and use hstart/hblank
 * for pixel timing.
 *
 * The hsync/vsync signals are delayed by 1 pclk period with
 * respect to the vstart/hstart/blank signals. It is intended that
 * the video generator will introduce a 1 pclk pipeline delay so that
 * the signals will align again. If the video generator requires a
 * larger delay, the hsync and vsync signals need to be delayed as well.
 *
 * The design has been optimised for speed (>200 MHz on Spartan-3
 * with ISE 9.2 and one-hot FSM encoding selected).
 *
 * (C) Arlet Ottens, <arlet@c-scape.nl>
 */
module vga( input clk108,         
            output reg hsync,      // horizontal sync
            output reg vsync,      // vertical sync
            output reg hstart,      // line start on next clock
            output reg vstart,      // field starts on next clock
            output reg hblank = 1,   // hblank on next clock
            output reg vblank = 0   // vblank on next clock
            );
// timing parameters
parameter
    HFRONT  = 53,      // front porch (+right border)
    HVIDEO  = 1280,      // active video area
    HSYNC   = 112,      // hsync
    HBACK   = 243;      // back porch  (+left border)

parameter
    VFRONT  = 10,      // front porch (+bottom border)
    VVIDEO  = 1024,      // active vide area
    VSYNC   = 3,      // vsync
    VBACK   = 29;  // back porch  (+top border)

// states (used for both H and V state machines)
parameter
    VIDEO  = 2'd0,
    FRONT  = 2'd1,
    SYNC   = 2'd2,
    BACK   = 2'd3;

// horizontal counters and state
reg [11:0] hcount = 0;      // down counter for horizontal state
reg [10:0] hload;      // next load value
reg [1:0] hstate = FRONT;   // horizontal state
wire hcount_done = hcount[11];   // done when count < 0

// vertical counters and state
reg [10:0] vcount = 0;      // down counter for vertical state
reg [9:0] vload;      // next load value
reg [1:0] vstate = FRONT;   // horizontal state
wire vcount_done = vcount[10];   // done when count < 0

// enable signal for V state machine
wire venable = (hstate == FRONT) & hcount_done;

// preload next timer value depending on state
// subtract 2 from timing value to compensate for pipeline delays
// This should be synthesized as a small LUT ROM, so it's quite
// efficient.
always @(posedge clk108)
   hload <= (hstate == BACK)  ? HVIDEO - 2:
            (hstate == VIDEO) ? HFRONT - 2:
       (hstate == FRONT) ? HSYNC - 2:
                   HBACK - 2;

// do the same for vertical
always @(posedge clk108)
   vload <= (vstate == BACK)  ? VVIDEO - 2:
            (vstate == VIDEO) ? VFRONT - 2:
       (vstate == FRONT) ? VSYNC  - 2:
                   VBACK  - 2;

// adjust down counter. Reload when it's done.
always @(posedge clk108)
        if( hcount_done )
        hcount <= { 1'b0, hload };
        else
        hcount <= hcount - 1;

// when down counter is done, go to next state
always @(posedge clk108)
   if( hcount_done )
       case( hstate )
          VIDEO : hstate <= FRONT;
          FRONT : hstate <= SYNC;
          SYNC  : hstate <= BACK;
          BACK  : hstate <= VIDEO;
       endcase

// start of active line
always @(posedge clk108)
       hstart <= (hstate == BACK) & hcount_done & ~vblank;

// vstart pulse to signal end of vertical blanking
always @(posedge clk108)
       vstart <= (vstate == BACK) & venable & vcount_done;

// adjust down counter. Reload when it's done.
always @(posedge clk108)
   if( venable ) begin
        if( vcount_done )
        vcount <= { 1'b0, vload };
        else
        vcount <= vcount - 1;
   end

// when down counter is done, go to next state
always @(posedge clk108)
   if( venable & vcount_done )
       case( vstate )
          VIDEO : vstate <= FRONT;
          FRONT : vstate <= SYNC;
          SYNC  : vstate <= BACK;
          BACK  : vstate <= VIDEO;
       endcase

// update registered outputs
always @(posedge clk108) begin
       hsync  <= hstate == SYNC;
       vsync  <= vstate == SYNC;
       hblank <= (vstate == VIDEO) & (hstate == VIDEO) & hcount_done;
       vblank <= vstate != VIDEO;
   end
endmodule

Code:
module SRAMif( output reg [20:0] SRAddr = 0,
               output reg WEn = 1,
               output reg SRCS = 1,
               input [15:0] SRD,
               output reg [4:0] Red_data,
               output reg [5:0] Green_data,
               output reg [4:0] Blue_data,
               output reg DACBLANKn = 1,
               input clk108,
               input hstart,
               input vstart,
               input hblank
               );

reg [15:0] SRDtemp;
reg countflag;

always @(posedge clk108)
      if ( hstart )
         countflag <= 1;   //countflag active in display area
      else if ( hblank )
         countflag <= 0;
      
always @(posedge clk108)
   if ( vstart )   //reset address counter at top left of screen
      SRAddr <= 0;
   else if ( countflag )
      SRAddr <= SRAddr + 1;         //increment RAM address counter
      
always @(posedge clk108)
   if ( countflag )
      begin
         SRDtemp <= SRD;   //latch incoming data
         Red_data <= hblank ? 0 : SRDtemp [15:11];      //outgoing data to videoDAC
         Green_data <= hblank ? 0 : SRDtemp [10:5];
         Blue_data <= hblank ? 0 : SRDtemp [4:0];
      end
         
endmodule



EDIT: I'm thinking my code could be further compacted (untested):
Code:
module SRAMif( output reg [20:0] SRAddr = 0,
               output reg WEn = 1,
               output reg SRCS = 1,
               input [15:0] SRD,
               output reg [4:0] Red_data,
               output reg [5:0] Green_data,
               output reg [4:0] Blue_data,
               output reg DACBLANKn = 1,
               input clk108,
               input hstart,
               input vstart,
               input hblank
               );

reg [15:0] SRDtemp;
reg countflag;

always @(posedge clk108)
      if ( hstart )
         countflag <= 1;   //countflag active in display area
      else if ( hblank )
         countflag <= 0;
      
always @(posedge clk108)
   if ( vstart )   //reset address counter at top left of screen
      SRAddr <= 0;
   else if ( countflag )
     begin
         SRAddr <= SRAddr + 1;         //increment RAM address counter
         SRDtemp <= SRD;   //latch incoming data
         Red_data <= hblank ? 0 : SRDtemp [15:11];      //outgoing data to videoDAC
         Green_data <= hblank ? 0 : SRDtemp [10:5];
         Blue_data <= hblank ? 0 : SRDtemp [4:0];
      end
         
endmodule


EDIT (10/5/12): Tonight, I tested this last bit of code. I also compared the resource usage numbers in the ISE summary report (short of looking at the RTL schematic) after synthesis and it is the exact same as the previous bit of code... My goal when learning Verilog is to use the least amount of characters/typing as possible. I already skim across my 65Org16.b code and see alot I will change and update/test.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 5:12 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Can someone help me? I'm having a difficult time trying to generate successful timing signals using a 3.1MHz pixel clock. It's just an experiment to observe the lowest resolution possible. I was aiming for something like 160x100 or even lower. Need some good values for H&V sync pulses and porch values.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 6:15 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
These low resolutions are probably not supported by the monitor. If you really want low resolutions, you'd be better off using a line doubling implementation.


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 7:18 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I was able to get down to 280x180@around 10MHz. For some reason, noise is easier to see at lower resolutions. Tomorrow I will start soldering in the bypass capacitors starting at the videoDAC and it's 3.3VReg, then moving onto the SyncRAM bypass cap's, and finally the S6's, and report back my findings.

So far I have 4 resolutions working:
320x200
640x480
1024x768
1280x1024
I will add 800x600. 256x256 might be interesting too.
I think it would be a good idea to post the settings for each resolution along with the aspect ratio, and how much RAM they use and how many frame buffers are possible with each.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 7:58 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
ElEctric_EyE wrote:
Tomorrow I will start soldering in the bypass capacitors starting at the videoDAC and it's 3.3VReg, then moving onto the SyncRAM bypass cap's, and finally the S6's, and report back my findings.

I'm curious, why do you wait so long to put the bypass caps in ? When I build a board, I always put them in right away. Seems to me that you only risk the chance you'll be chasing problems caused by the lack of bypass caps.


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 8:08 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Regarding the code rewrite: I always prefer to update different signals in different blocks, except when they are clearly related as a group (like the red/green/blue channels). Right now, it looks nice that SRAddr and Red_data are in the same block, but at some point in time, you'll discover there are situations where you want to update only one, and not the other, and then it becomes messy to keep them together.

For instance, in this case, you don't keep track of the latency of the SRAM. If you were to implement that properly, you'll find that you need to update the address earlier in the pipeline than the RGB channel data.


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 8:58 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Arlet wrote:
I'm curious, why do you wait so long to put the bypass caps in ?

I had once spent a year troubleshooting an insidious noise problem. When I finally figured it out, I swore to never relive that experience again, and this was 20+yrs ago (I still remember after a 10yr respite from electronics). Now instead of allowing a noise issue play with me, I play with it... I am ultra-confident in my power supply layout and was curious how far it would go before noise became an issue. I suspect hi speed video would be more of an "ultimate test" of noise versus an oversampling audio circuit. (1) because it is higher speed, and (2) the eyes are more discerning than the ears. What I learn here, I will apply to future construction.

Arlet wrote:
Regarding the code rewrite...at some point in time, you'll discover there are situations where you want to update only one, and not the other, and then it becomes messy to keep them together...

I discovered this today when I was thinking about how to implement a simple write module. A hardware clear screen would be especially useful. I started to realize early on that I would need separate Read and Write buses in 2 separate module, joined for bidirectional use at the top module. Now my top module is schematic only, which is what halted my progress. I am currently making a new project where the top_level is also Verilog.

Arlet wrote:
...you don't keep track of the latency of the SRAM. If you were to implement that properly, you'll find that you need to update the address earlier in the pipeline than the RGB channel data.

Yes, I guess I do it haphazardly. I try to figure out a total timing and try do it within a window. I was never good at timing diag's. Pipelines is a subject matter I must and will learn with some help.

So today I just retreated abit and decided to try to finish off the v1.0h board.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 9:31 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
(I think the ears are more discerning...)


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 9:49 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
BigEd wrote:
(I think the ears are more discerning...)

Don't invite Garth to another 'Golden ears" discussion! :lol: J/K Garth!

I realized I should have said that I am nearsighted to the point of astigmatism. So, although legally blind without glasses, the vision is like a microscope at close range. Also I think I have excellent ears. I don't tolerate 192Kbps MP3s. I hear a difference in the cymbals. They sound compressed. I always back up my CDs with 320Kbps rips. Of course it depends on your speaker construction too, or who you bought them from...

It's interesting though BigEd, usually the human body makes up for losses, so if one can't see well, hearing takes up for the slack.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 10:15 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8544
Location: Southern California
Yeah, MP3 stinks.  Oh wait a minute—that's the nose, not the ears.  :lol:

golden-ears audio discussion starts in the middle of the post at viewtopic.php?f=4&t=2188&p=19749#p19749

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 155 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9 ... 11  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 18 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: