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

All times are UTC




Post new topic Reply to topic  [ 155 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 11  Next
Author Message
PostPosted: Thu Sep 27, 2012 12:37 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
To simplify the code (and removing a cycle of latency at the same time), you can also remove the SRAddrtemp registers, and write directly the SRAddr. Something like this:
Code:
always @(posedge clk50)
   if ( vstart )   //reset address counter at top left of screen
      SRAddr <= 0;
   else if ( pclk & countflag )
      SRAddr <= SRAddr +1;         //increment RAM address counter


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 27, 2012 5:07 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Excellent.

I was thinking, with this much RAM at this low resolution, would it advantageous to do bank switching? Like a scheme where we could R/W to the memory at any time without the 'snow' effect?

EDIT: or maybe we would need 2 separate memories piggybacked... I heard of this being done somewhere, but I can't remember the details of how it was hooked up.

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 27, 2012 6:04 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
ElEctric_EyE wrote:
I was thinking, with this much RAM at this low resolution, would it advantageous to do bank switching? Like a scheme where we could R/W to the memory at any time without the 'snow' effect?

It could be interesting to make multiple banks, so you can do double buffering. The CPU would write one buffer, while displaying the other one. When the CPU is finished, the two buffers are flipped, creating a smooth change.

The snow effect is caused because the data fetch from the video generator collides with CPU access. Creating multiple banks wouldn't help, since you'd still only have a single shared address/data bus.

However, the snow effect can be fixed by buffering the data inside the video generator. You can read a bunch of data from the SRAM at 100 MHz clock speed, and store that data inside the FPGA in a FIFO. While the video generator sends the pixels at only 25 MHz, the CPU can have full access to the memory, without any conflict.


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 27, 2012 7:19 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Arlet wrote:
... You can read a bunch of data from the SRAM at 100 MHz clock speed, and store that data inside the FPGA in a FIFO. While the video generator sends the pixels at only 25 MHz, the CPU can have full access to the memory, without any conflict.


Ah that's right. You did something similar for the last project, I think. Didn't you use one scanline for the FIFO?

Anyway, I will leave this complicated development for you and I will study... With the amount of mistakes on this board, I will send in the new board version to be made soon.

I think these graphic boards are going to be very rewarding as far as speed.

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 27, 2012 7:41 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
ElEctric_EyE wrote:
Ah that's right. You did something similar for the last project, I think. Didn't you use one scanline for the FIFO?

I used a block RAM as a FIFO. That's 1024 pixels @ 16 bits per pixel. The nice part about a FIFO is that it's really easy to work with. You get a 'vtrigger' signal that indicates it's time to start a new frame. When you get that signal, you have to send 640x480 pixels into the FIFO. Whenever the FIFO is full, you get a signal, and you pause. Since the vtrigger signal comes early (during border), you get plenty of time to fill up the FIFO. The VGA module is then responsible for taking data from the FIFO and match it exactly with the VGA timing.

I have the code for the CS4954 module, so I would still need to make a VGA version.


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 28, 2012 8:18 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I've made the suggested changes. Now the pixel clock going to the videoDAC and the syncRAM are the same. Also using vstart to zero my address counter, and getting rid of SRAddrtemp. Now it's rock steady, and clean signal. Pic is deceiving as there are no borders yet. I will try to push the limits of the SyncRAM and see the upper limits of resolution. Aiming for 1024x768 next, @768K there is enough RAM for a framebuffer. I think 1280x1024 will be out of the question. One thing I would like to do is add registers to Arlet's HSync module, so variables can be programmed by a cpu on the fly.
Image

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 28, 2012 6:32 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
I can't understand why there are those horizontal bars at the right hand side of the screen.


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 28, 2012 6:50 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
It looks like whatever is pushing new pixel values stops when it thinks it is at the of the line. (It's pushing them from the wrong source, or wrong locations, I suppose)


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 28, 2012 6:54 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
I think the RGB outputs need to be set to black during front/back porch and blanking interval. The monitor is probably getting confused about the resolution now.


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 28, 2012 7:04 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I have tried to do a quick test and logical NOR the vblank and hblank signals for the active low DACBLANK signal. It drives the RGB outputs to the blanking level. My little experiment didn't work when I was working with the vertical bar test.

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 28, 2012 7:11 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
I mean something like this:
Code:
always @(posedge clk50)
   if ( pclk )  begin
      Red_data   <= countflag ? SRDtemp [15:11] : 0;      //outgoing data to videoDAC
      Green_data <= countflag ? SRDtemp [10:5] : 0;
      Blue_data  <= countflag ? SRDtemp [4:0] : 0;
   end


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 28, 2012 7:17 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
That would be nice if that works and I can save another pin from the FPGA for something else.

Unfortunately, I can't try this until Sunday, after a brief retreat to the beach with family.

Will report back!

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 28, 2012 9:37 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Also, I'm thinking I should also test to see how this picture is looking on an older non-multisync VGA crt. I can do this test next wed. May have to use the PLL to get closer to the ideal 25.175MHz, will still be a couple hundred Hz off though.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Sep 30, 2012 7:20 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Did some testing on an older CRT manufactured in 1998, unsure if it has the multi-sync hardware built in. There were vertical borders present, clearly seen about 1/2" on top and bottom. Also, bars like the ones on the right side of the above pic (flat screen monitor), were on both sides of this monitor. So the observation seems to be inline with some of my readings, that the newer flat screen monitors automatically trim HSYNC and VSYNC timings so that there are practically no visible borders.

I changed my code by memory from what Arlet had mentioned before. I thought he had used hblank as the trigger, but I saw he chose countflag. Maybe it doesn't matter? But it works. Interesting thing though, the picture is much brighter than before. I will add the 75ohm load resistors back to the videoDAC RGB outputs.

So this means I will have 1 more global clock pin freed up on v.1.0h, since I can just tie the videoDAC Blank pin high. EDIT: I think this pin will best be used for a separate MicroSD adapter serial clock apart from the serial clock common to the FLASHs.

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 clk50,
               input pclk,
               input hstart,
               input vstart,
               input hblank
               );

reg [15:0] SRDtemp;
reg countflag;

always @(posedge clk50)
   if ( pclk )
      if ( hstart )
         countflag <= 1;   //countflag active in display area
      else if ( hblank )
         countflag <= 0;
      
always @(posedge clk50)
   if ( vstart )   //reset address counter at top left of screen
      SRAddr <= 0;
   else if ( countflag )
      SRAddr <= SRAddr + 1;         //increment RAM address counter
      
always @(posedge clk50)
   if ( pclk & 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

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 02, 2012 12:01 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
@Arlet. I'm trying to 'up' the resolution to 1024x768x60Hz by using the settings shown in the tinyvga site. Can your vga module go up to this 1024 horizontal resolution? I've changed all the parameters to match the tinyvga site, I also made the odd parameters even, by adding 1, since your counters seem to subtract by 2...

I still struggle with top_level clock interconnects. What I thought should work is not working at this point. The old settings for 640x480 and the new settings, I'm trying for 1024x768 as far as HSYNC & VSYNC, are both negative edge triggered so no mod's there to your code. And you Horizontal counter goes up to bit [10]...

EDIT: clk50 input frequency is now 130MHz outputted from a DCM from the main 100MHz input.

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


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

All times are UTC


Who is online

Users browsing this forum: No registered users and 16 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:  
cron