FPGA VGA Controller for 8-bit computer

[nockieboy]

Uhh, I'm clearly missing something or doing something wrong, I can't get valid video output at all.  I've got the project set up as you said, then amended GPU_DECA_DDR3_top.sv and BHG_vpg.sv for 720x480 output, but what am I missing?

[BrianHG]

You are running the PLL at 148.5MHz.
That's 330Hz progressive at 720x480.
Can your monitor show that?
I know mine cant.
Inside PLL.v you have:

Code: [Select]

altpll_component.clk0_divide_by = 100,
altpll_component.clk0_duty_cycle = 50,
altpll_component.clk0_multiply_by = 297,
That's 50MHz divide by 100=0.5Mhz, multiply by 297=148.5MHz.
Try changing the divide by to 50 and the multiply by to 27.

[BrianHG]

Also, for my module BrianHG_display_rmem settings, you may use 640x480 and also set the .DISP_bitmap_width to 640.  This way, the bitmap and display res will be compatible with your current 640x480 settings except you will see a little repeat of the bitmap on the right hand side of the screen.

[nockieboy]

Yeah, that's it.  Knew I'd missed something.

[BrianHG]

Ok, that looks correct.

Next, we can move to 8 bit pixels.

This means changing how 'BHG_vga_generator' addresses the output of the 'Line_Buffer_DP_ram', going from 32bits down to 8 bits.

Then, taking that 8 bits and piping it through a second 256 word x32bit rom/altsyncram with .mif file containing your palette and for now, let's ignore the incurred 2 pixel delay unless you want to go ahead and fix that.  (We will be changing this module anyways into the new MAGGIE & BART, so don't worry about the fine details...)


Next, wire in the Z80bus to the DDR3.

Then wire in the geometry unit to the Z80 bus and DDR3.
Now, you should have your first accelerated 640x480 256 color display working on your Z80.

You may then upgrade your resolution to 1280x720, IE 720p.

[nockieboy]

Next, we can move to 8 bit pixels.

This means changing how 'BHG_vga_generator' addresses the output of the 'Line_Buffer_DP_ram', going from 32bits down to 8 bits.

Okay, but it looks like the Line_Buffer_DP_ram instance output is all high (well, data_b is anyway)?   Very confused about how that all works, tbh.

Then, taking that 8 bits and piping it through a second 256 word x32bit rom/altsyncram with .mif file containing your palette and for now, let's ignore the incurred 2 pixel delay unless you want to go ahead and fix that.

So I need to create another altsyncram instance, 256x32 bits in size, with its contents set by a .mif file that I need to generate, with one address and data input (in case I want to change palette values on the fly?) and one data output.  The address input of this second altsyncram instance needs to be the 8-bit output from the Line_Buffer_DP_ram instance, and the palette altsyncram instance's output needs to be a 32-bit value that is fed to... here?

Code: [Select]

CMD_line_mem_wdata
Is that right?

[BrianHG]

Next, we can move to 8 bit pixels.

This means changing how 'BHG_vga_generator' addresses the output of the 'Line_Buffer_DP_ram', going from 32bits down to 8 bits.

Okay, but it looks like the Line_Buffer_DP_ram instance output is all high (well, data_b is anyway)?   Very confused about how that all works, tbh.

Ok, how it works...

Port A/clock0 is hard wired as a write data located on the DDR3 CMD_CLK domain.
It is 128bits since this is the DDR3 bus width and that is the fastest way to get DDR3 read data into the buffer.
This buffer was designed to be 2 lines of video long.  IE, the DDR3 will fill 1 line in the buffer as the output shows the alternate line in the buffer.
------------------------
Port B/clock1 is hard wired to be 32bits wide and clocked on the VGA pll output clock domain.  On each horizontal line, it will show/draw the opposite line which Port A is working on filling from the DDR3.
Now when reading pixels,  since the read address points to 32bit instead of 128bits, and the data is in the wrong Endian, I'm inverting the bottom 2 bits flipping around the order of every 4 pixels being shown.
Here is what I'm asking you to change, hard wire that port B output to 8 bit and adjust the read pixel address.  Don't forget that this will change the read address width.  IE: .widthad_b, .width_b, &, .numwords_b.

You want 8 bit pixels since 8 bit mode is compatible with the current geometry unit.  IE, you must set the video output mode to 8 bit when writing or blitting graphics.

You also want a palette ram at the output since 256 shades of grey is boring.

Then, taking that 8 bits and piping it through a second 256 word x32bit rom/altsyncram with .mif file containing your palette and for now, let's ignore the incurred 2 pixel delay unless you want to go ahead and fix that.

So I need to create another altsyncram instance, 256x32 bits in size, with its contents set by a .mif file that I need to generate, with one address and data input (in case I want to change palette values on the fly?) and one data output.  The address input of this second altsyncram instance needs to be the 8-bit output from the Line_Buffer_DP_ram instance, and the palette altsyncram instance's output needs to be a 32-bit value that is fed to... here?

Code: [Select]

CMD_line_mem_wdata
Is that right?

No writing to the palette yet.  You just want a default which will give you some color for your text/graphics tests.  Palette writing will come with the new BART system.


Don't worry about the huge wasted dual port memory for 2 lines of 32bit color video at 2048 pixels long for 1080p.  I'm working on a sequential filling as needed tiny 1kb buffer for the MAGGIE instead of this huge 2 line 16kb buffer.  You need 1 of these buffers per maggie layer and 16 layer x16kb would eat up the entire FPGA's blockram.  But the minimum 1kb means 16 maggie layers would eat up 16kb of block ram.  Not to mention having a 1kb palette for every 2 layers eating away another 8kb.

[nockieboy]

Port A/clock0 is hard wired as a write data located on the DDR3 CMD_CLK domain.
It is 128bits since this is the DDR3 bus width and that is the fastest way to get DDR3 read data into the buffer.
This buffer was designed to be 2 lines of video long.  IE, the DDR3 will fill 1 line in the buffer as the output shows the alternate line in the buffer.
------------------------
Port B/clock1 is hard wired to be 32bits wide and clocked on the VGA pll output clock domain.  On each horizontal line, it will show/draw the opposite line which Port A is working on filling from the DDR3.
Now when reading pixels,  since the read address points to 32bit instead of 128bits, and the data is in the wrong Endian, I'm inverting the bottom 2 bits flipping around the order of every 4 pixels being shown.
Here is what I'm asking you to change, hard wire that port B output to 8 bit and adjust the read pixel address.  Don't forget that this will change the read address width.  IE: .widthad_b, .width_b, &, .numwords_b.

You want 8 bit pixels since 8 bit mode is compatible with the current geometry unit.  IE, you must set the video output mode to 8 bit when writing or blitting graphics.

Something like this?

Code: [Select]

altsyncram  Line_Buffer_DP_ram (

   // ********* PORT A *************
   .address_a      ( CMD_line_mem_waddr         ),
   .clock0         ( CMD_CLK                    ),
   .data_a         ( CMD_line_mem_wdata         ),
   .wren_a         ( CMD_line_mem_wena          ),
   .aclr0          (1'b0),
   .addressstall_a (1'b0),
   .byteena_a      (1'b1),
   .clocken0       (1'b1),
   .q_a            (),
   .rden_a         (1'b1),
   
   // ********* PORT B *************
   .address_b      ( ({pixel_line, pixel_x[10:0]}) ^ 12'd3 ),  // Don't forget that Endian swap....
   .clock1         ( clk                              ),
   .q_b            ( {wvga_a, wvga_b, wvga_g, wvga_r} ),
   .aclr1          ( 1'b0 ),
   .addressstall_b ( 1'b0 ),
   .byteena_b      ( 1'b1 ),
   .clocken1       ( 1'b1 ),
   //.data_b         ({32{1'b1}} ),
   .data_b         ( { 8{1'b1} } ),
   .rden_b         ( 1'b1 ),
   .wren_b         ( 1'b0 ),
   
   .clocken2       ( 1'b1 ),
   .clocken3       ( 1'b1 ),
   .eccstatus      (      )
   
);
defparam
   Line_Buffer_DP_ram.address_aclr_b = "NONE",
   Line_Buffer_DP_ram.address_reg_b = "CLOCK1",
   Line_Buffer_DP_ram.clock_enable_input_a = "BYPASS",
   Line_Buffer_DP_ram.clock_enable_input_b = "BYPASS",
   Line_Buffer_DP_ram.clock_enable_output_b = "BYPASS",
   Line_Buffer_DP_ram.init_file = "line_buf_init.mif",
   Line_Buffer_DP_ram.init_file_layout = "PORT_B",
   Line_Buffer_DP_ram.intended_device_family = "MAX 10",
   Line_Buffer_DP_ram.lpm_type = "altsyncram",
   Line_Buffer_DP_ram.numwords_a = 1024,
   //Line_Buffer_DP_ram.numwords_b = 4096,
   Line_Buffer_DP_ram.numwords_b = 16384, // **** THIS HAS BEEN CHANGED FOR 8-BIT
   Line_Buffer_DP_ram.operation_mode = "DUAL_PORT",
   Line_Buffer_DP_ram.outdata_aclr_b = "NONE",
   Line_Buffer_DP_ram.outdata_reg_b = "CLOCK1",
   Line_Buffer_DP_ram.power_up_uninitialized = "FALSE",
   Line_Buffer_DP_ram.widthad_a = 10,
   //Line_Buffer_DP_ram.widthad_b = 12,
   Line_Buffer_DP_ram.widthad_b = 14,     // **** THIS HAS BEEN CHANGED FOR 8-BIT
   Line_Buffer_DP_ram.width_a = 128,
   Line_Buffer_DP_ram.width_b = 8,        // **** THIS HAS BEEN CHANGED FOR 8-BIT
   //Line_Buffer_DP_ram.width_b = 32,
   Line_Buffer_DP_ram.width_byteena_a = 1;
Is that along the right lines, or have my guesses at the correct values completely missed the mark?  The changes to the parameters are based more on educated guesses than true understanding of how they relate.

[BrianHG]

Correct except for this line:

Code: [Select]

   .address_b      ( ({pixel_line, pixel_x[10:0]}) ^ 12'd3 ),  // Don't forget that Endian swap....
You now need 2 more bits in the read address and remember 8 bit has 16 pixels inside 128 bit, not 4 pixels.

It should look something like this:

Code: [Select]

   .address_b      ( ({pixel_line, 2'b00, pixel_x[10:0]}) ^ 12'd15 ),  // Don't forget that Endian swap....

[nockieboy]

Correct except for this line:

Code: [Select]

   .address_b      ( ({pixel_line, pixel_x[10:0]}) ^ 12'd3 ),  // Don't forget that Endian swap....
You now need 2 more bits in the read address and remember 8 bit has 16 pixels inside 128 bit, not 4 pixels.

It should look something like this:

Code: [Select]

   .address_b      ( ({pixel_line, 2'b00, pixel_x[10:0]}) ^ 12'd15 ),  // Don't forget that Endian swap....

Okay, that makes sense I guess. 

So now I need to create another altsyncram for the palette memory and a .MIF with some palette values?  I'm a little unsure how this will be wired into the existing Line_Buffer_DP_ram instance.  For some reason I'm confused about the Port A/Port B business.  Port A appears to be permanently reading data, Port B permanently writing data?  Or should that be the other way around?

[BrianHG]

Well, this line:

Code: [Select]

.q_b            ( {wvga_a, wvga_b, wvga_g, wvga_r} ),
Is returning the current read as 32 bit data.  The problem is that the data is now only 8 bit.
What you want is a single 8 bit wire placed inside the brackets here.

That 8 bit wire will feed the 8 bit read address of your 32bit palette ram.
That 32bit read data out will then become equivalent to the line above giving you the 32bit palette colored pixels.

The write enable & write address will be disabled.

[nockieboy]

Of course.  I'd completely missed the .q_a/b outputs from the syncram.   I was trying to work out how the data was coming out of the syncram and had completely missed those connections.

The palette RAM doesn't need to be dual-port, does it (at least not initially)?  The 8-bit feed from the line buffer will supply the address, the 32-bit data out (.q) will feed these wires below?

Code: [Select]

{wvga_a, wvga_b, wvga_g, wvga_r}
I suppose I'd set it up as DP ram, but leave port B disconnected for the moment?

[BrianHG]

If you are copying the above 'altsyncram' for the palette, then, port b is the read and port a will be connected to ( 0 ),.

The size is 256x32.
For now, match port a to that as well.

[nockieboy]

Here's a stab at setting up the palette syncram:

Code: [Select]

// Initiate the 32-bit palette memory.
altsyncram  Palette_DP_ram (

   // ********* PORT A *************
   .clock0         ( clk          ),
   .address_a      ( palette_addr ),
   .data_a         ( { 8{1'b1} }  ),
   .wren_a         ( 1'b0 ),
   .aclr0          ( 1'b0 ),
   .addressstall_a ( 1'b0 ),
   .byteena_a      ( 1'b1 ),
   .clocken0       ( 1'b1 ),
   .q_a            ( {wvga_a, wvga_b, wvga_g, wvga_r} ),
   .rden_a         ( 1'b1 ),
   
   // ********* PORT B *************
   .clock1         (  ),
   .address_b      (  ),
   .data_b         ( { 8{1'b1} } ),
   .wren_b         ( 1'b0 ),
   .aclr1          ( 1'b0 ),
   .addressstall_b ( 1'b0 ),
   .byteena_b      ( 1'b0 ),
   .clocken1       ( 1'b0 ),
   .q_b            (  ),  // output
   .rden_b         ( 1'b0 ),
   
   .clocken2       ( 1'b1 ),
   .clocken3       ( 1'b1 ),
   .eccstatus      (      )
   
);
defparam
   Line_Buffer_DP_ram.address_aclr_b = "NONE",
   Line_Buffer_DP_ram.address_reg_b = "CLOCK1",
   Line_Buffer_DP_ram.clock_enable_input_a = "BYPASS",
   Line_Buffer_DP_ram.clock_enable_input_b = "BYPASS",
   Line_Buffer_DP_ram.clock_enable_output_b = "BYPASS",
   Line_Buffer_DP_ram.init_file = "palette_init.mif",
   Line_Buffer_DP_ram.init_file_layout = "PORT_A",
   Line_Buffer_DP_ram.intended_device_family = "MAX 10",
   Line_Buffer_DP_ram.lpm_type = "altsyncram",
   Line_Buffer_DP_ram.numwords_a = 256,
   Line_Buffer_DP_ram.numwords_b = 256,
   Line_Buffer_DP_ram.operation_mode = "DUAL_PORT",
   Line_Buffer_DP_ram.outdata_aclr_b = "NONE",
   Line_Buffer_DP_ram.outdata_reg_b = "CLOCK1",
   Line_Buffer_DP_ram.power_up_uninitialized = "TRUE",
   Line_Buffer_DP_ram.widthad_a = 8,
   Line_Buffer_DP_ram.widthad_b = 8,
   Line_Buffer_DP_ram.width_a = 32,
   Line_Buffer_DP_ram.width_b = 32,
   Line_Buffer_DP_ram.width_byteena_a = 1;
palette_addr is an 8-bit wire from .q_b in the Line Buffer.  palette_init.mif is an as-yet-non-existent palette table, 256 words long by 32 bits wide.

If you are copying the above 'altsyncram' for the palette, then, port b is the read and port a will be connected to ( 0 ),.

The size is 256x32.
For now, match port a to that as well.

The above just popped up whilst I was writing this post. I'll amend the above syncram setup and post again in a sec.

[nockieboy]

Attempt 2:

Code: [Select]

// Initiate the 32-bit palette memory.
altsyncram  Palette_DP_ram (

   // ********* PORT A *************
   .clock0         (  ),
   .address_a      (  ),
   .data_a         ( { 8{1'b1} }  ),
   .wren_a         ( 1'b0 ),
   .aclr0          ( 1'b0 ),
   .addressstall_a ( 1'b0 ),
   .byteena_a      ( 1'b0 ),
   .clocken0       ( 1'b0 ),
   .q_a            (  ),
   .rden_a         ( 1'b0 ),
   
   // ********* PORT B *************
   .clock1         ( clk ),
   .address_b      ( palette_addr ),
   .data_b         ( { 8{1'b1} } ),
   .wren_b         ( 1'b0 ),
   .aclr1          ( 1'b0 ),
   .addressstall_b ( 1'b0 ),
   .byteena_b      ( 1'b1 ),
   .clocken1       ( 1'b1 ),
   .q_b            ( {wvga_a, wvga_b, wvga_g, wvga_r} ),  // output
   .rden_b         ( 1'b1 ),
   
   .clocken2       ( 1'b1 ),
   .clocken3       ( 1'b1 ),
   .eccstatus      (      )
   
);
defparam
   Line_Buffer_DP_ram.address_aclr_b = "NONE",
   Line_Buffer_DP_ram.address_reg_b = "CLOCK1",
   Line_Buffer_DP_ram.clock_enable_input_a = "BYPASS",
   Line_Buffer_DP_ram.clock_enable_input_b = "BYPASS",
   Line_Buffer_DP_ram.clock_enable_output_b = "BYPASS",
   Line_Buffer_DP_ram.init_file = "palette_init.mif",
   Line_Buffer_DP_ram.init_file_layout = "PORT_A",
   Line_Buffer_DP_ram.intended_device_family = "MAX 10",
   Line_Buffer_DP_ram.lpm_type = "altsyncram",
   Line_Buffer_DP_ram.numwords_a = 256,
   Line_Buffer_DP_ram.numwords_b = 256,
   Line_Buffer_DP_ram.operation_mode = "DUAL_PORT",
   Line_Buffer_DP_ram.outdata_aclr_b = "NONE",
   Line_Buffer_DP_ram.outdata_reg_b = "CLOCK1",
   Line_Buffer_DP_ram.power_up_uninitialized = "TRUE",
   Line_Buffer_DP_ram.widthad_a = 8,
   Line_Buffer_DP_ram.widthad_b = 8,
   Line_Buffer_DP_ram.width_a = 32,
   Line_Buffer_DP_ram.width_b = 32,
   Line_Buffer_DP_ram.width_byteena_a = 1;

[BrianHG]

.data_a/b is 32bit.  It's the address which is 8 bit.

[nockieboy]

.data_a/b is 32bit.  It's the address which is 8 bit.

Dang it.  Forgot to update that line. 

Code: [Select]

.data_a         ( { 32{1'b1} }  ),

[BrianHG]

Ok, make a 256 word, 32 bit .mif with some color and compile and look.

Since the DDR3 is uninitialized random junk, the .mif needs to be full with something otherwise you will see nothing but black.  For now, you can fill it with 0,0,0,0-0,255,255,255.

That can be easily enough done with Quartus generating an auto-increment per address fill in the .mif editor.

Once done, wire in the Z80 bus interface to the DDR3 ram.

[nockieboy]

Ok, make a 256 word, 32 bit .mif with some color and compile and look.

Since the DDR3 is uninitialized random junk, the .mif needs to be full with something otherwise you will see nothing but black.  For now, you can fill it with 0,0,0,0-0,255,255,255.

That can be easily enough done with Quartus generating an auto-increment per address fill in the .mif editor.

Yep, got a lovely random snow pattern in various colours (I went for a pseudo-colour palette rather than a greyscale).

Once done, wire in the Z80 bus interface to the DDR3 ram.

Will let you know when this is done.  Should be a straightforward cut 'n' paste from the previous project, in theory at least.

[BrianHG]

Once done, wire in the Z80 bus interface to the DDR3 ram.

Will let you know when this is done.  Should be a straightforward cut 'n' paste from the previous project, in theory at least.

Close.  You will be placing the Z80_bus_interface in the GPU_xxxxx_top.sv and wire the read write to a ddr3 read/write port 1.  Move the current show graphics port from 1 to 2.  Configure the DDR3 widths.

Once you see that the Z80 can read/write to the DDR3, next wire the geometry unit into the top and wire it's command port to the Z80 IO port and wire it's R/W to the DDR3 as seen in the previous working project.  I guess the show graphics now on port 2 will move to read port 4.  (The geometry unit uses 1 write port and 2 read ports.  Dont get them backwards as the order optimizes draw speed.)

You can change the base display ram address to give room to store a font and other stuff at the beginning of DDR3 ram.  If you configure the blitter correctly, 8bit color output/proper display raster width and base mem address, and copy over the font to DDR3, you should be able to draw on a 256 colour screen anything you like with the geometry engine.

You can then try moving up to 720p.

[nockieboy]

Close.  You will be placing the Z80_bus_interface in the GPU_xxxxx_top.sv and wire the read write to a ddr3 read/write port 1.  Move the current show graphics port from 1 to 2.  Configure the DDR3 widths.

Okay, so I'll need to wire the Z80_Bridge inputs/outputs directly to DECA IO pins, whereas previously they went through the GPU.sv intermediary.

Whilst looking through the HDL and trying to familiarise myself with the changes required, I've noticed there's some differences in parameter values between the current project and the previous working one - like CLK_IN_MULT is 32 in the current project, but it's 40 in the previous (working) version.  I know we changed some of these around because of different screen resolutions and (I think) some issues with talking with the Z80, but do we need to change any of these for the current project?

[BrianHG]

If you feel better just placing in GPU.sv intermediary, the do so except you will want to erase everything I posted above... https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3746599/#msg3746599 ... which is pretty much everything.


Leave the clock divider at 32 as this new code has a separate PLL for the video out and we no longer need to force overclocking the DDR3.

Obviously the DDR3 number of ports and their data widths need to be adjusted.

[nockieboy]

Latest version of GPU_DECA_DDR3_top.sv attached.

I'm really struggling with this at the moment.  I'm finding myself staring at a wall of HDL code, really straining to make sense of connections and links I need to make.   I really found all this much easier with the old diagrams/graphical way of connecting modules up.  Having a long, continuous block of time to spend on it would also make my life much easier, but I have to make do with spare half-hours here and there.

Anyway, enough of me whinging and being defensive about the mistakes I'm no-doubt making, here's where I am so far and my understanding of what needs to be done:

As you'll see from the attached top-level file, I've instantiated the Z80 bridge (lines 481-635) and left the parameter settings untouched.  I've connected up the majority of the ports directly to the DECA's IO pins, leaving unused ports unconnected or still with their old wire names whilst I work out what to do with them (leave them unconnected or create matching wire names with constant values) - this relates almost solely to the legacy IO ports on lines 610-620, but the GEOFF also isn't instantiated yet and there's connections in the bridge that relate to it, so I'll leave those disconnected (although there's wire names there currently).

I've wired up a reset line to the bridge in lines 439-473 - fingers crossed that matches the old system.  I've wired the bridge clock to DDR_CLK_25 (I think that's right).

I've changed the DDR3 port value to 2 for the BrianHG_display_rmem module (lines 647-677) and BHG_vpg (lines 688-710).

I've changed PORT_R/W_TOTAL by incrementing them by 1.  Likewise, I've adjusted the values in PORT_R/W_DATA_WIDTH and _PRIORITY arrays.

Hope this is right.   No, I haven't tested it yet.

[BrianHG]

When interfacing with my DDR3 CMD_xxx lines, everything must be on the CMD_CLK.
Do not play with the things like the 'DDR3_CLK_25' unless you're specifically are doing something special.

[nockieboy]

When interfacing with my DDR3 CMD_xxx lines, everything must be on the CMD_CLK.

Oops.  Must have mis-traced the clock line from the bridge upwards in the old project then.