Author Topic: FPGA VGA Controller for 8-bit computer  (Read 510747 times)

0 Members and 31 Guests are viewing this topic.

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1475 on: August 12, 2020, 05:24:40 am »
Damn, you forgot to place the 'ram_mux_busy' input on the simulation, so, I forgot to code for it...

Here is the updated Quartus project and simulation with the 'ram_mux_busy' input.
The rd_collision counter is now functional as well.

I still need to make the paste, mask & wr_collision functions work, but basic pixel writing now works.

Let's see you integrate everything into the GPU project.
« Last Edit: August 12, 2020, 05:59:26 am by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1476 on: August 12, 2020, 12:02:26 pm »


Wow.  That's really impressive.

Here's what my geometry_processor.sv looks like.  It compiles, but I haven't tried connecting it up to the modified Z80_bridge in the actual GPU project yet (that's next) - I'm just hoping there's no obvious mistakes.  ;)

EDIT: Hmm.. Fmax is coming out at 108.28 MHz..  How do you identify which part of the HDL is causing the slow down?
« Last Edit: August 12, 2020, 12:07:52 pm by nockieboy »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1477 on: August 12, 2020, 12:50:32 pm »
Final compilation after inserting the geo_unit into the GPU project shows an Fmax on clk[0] of 101.79 MHz.  :-BROKE
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1478 on: August 12, 2020, 04:12:11 pm »
Arrrggg, all you needed was this beginning part:
(We are still developing, testing and adding code to all the geo_xxx.sv  modules.  After changes and simulations you cannot expect to cut and paste code without errors and messing things up.)

Code: [Select]
module geometry_processor (

// inputs
input logic clk,                    // System clock
    input logic reset,                  // Force reset
    input logic fifo_cmd_ready,         // 16-bit Data Command Ready signal    - connects to the 'strobe' on the selected high.low Z80 bus output port
    input logic [15:0] fifo_cmd_in,     // 16-bit Data Command bus             - connects to the 16-bit output port on the Z80 bus

// data_mux_geo inputs
    input logic [15:0] rd_data_in,      // input from data_out_geo[15:0]
    input logic rd_data_rdy_a,          // input from geo_rd_rdy_a
    input logic rd_data_rdy_b,          // input from geo_rd_rdy_b
    input logic ram_mux_busy,           // input from geo_port_full
   
    // data_mux_geo outputs
    output logic rd_req_a,              // output to geo_rd_req_a on data_mux_geo
    output logic rd_req_b,              // output to geo_rd_req_b on data_mux_geo
    output logic wr_ena,                // output to geo_wr_ena   on data_mux_geo
    output logic [19:0] ram_addr,       // output to address_geo  on data_mux_geo
    output logic [15:0] ram_wr_data,    // output to data_in_geo  on data_mux_geo
   
    // collision saturation counter outputs
    output logic [7:0]  collision_rd,   // output to 1st read port on Z80_bridge_v2
    output logic [7:0]  collision_wr    // output to 2nd read port on Z80_bridge_v2
   
);

// wire interconnects for the sub-modules
logic draw_busy        ; 
logic [35:0] draw_cmd  ;
logic draw_cmd_rdy     ;
logic fifo_cmd_busy    ;
logic [39:0] pixel_cmd ;
logic pixel_cmd_rdy    ;

geometry_xy_plotter geoff (

// inputs
.clk            ( clk            ),
.reset          ( reset          ),
.fifo_cmd_ready ( fifo_cmd_ready ),
.fifo_cmd_in    ( fifo_cmd_in    ),
.draw_busy      ( draw_busy      ),
//outputs
.draw_cmd_rdy   ( draw_cmd_rdy   ),
.draw_cmd       ( draw_cmd       ),
.fifo_cmd_busy  ( fifo_cmd_busy  )

);

pixel_address_generator paget (

    // inputs
    .clk           ( clk           ),
    .reset         ( reset         ),
    .draw_cmd_rdy  ( draw_cmd_rdy  ),
    .draw_cmd      ( draw_cmd      ),
    .draw_busy     ( draw_busy     ),
    // outputs
    .pixel_cmd_rdy ( pixel_cmd_rdy ),
    .pixel_cmd     ( pixel_cmd     )

);

 geo_pixel_writer pixie (

    // inputs
    .clk              ( clk           ),
    .reset            ( reset         ),
    .cmd_rdy          ( pixel_cmd_rdy ),
    .cmd_in           ( pixel_cmd     ),
    .rd_data_in       ( rd_data_in    ),
    .rd_data_rdy_a    ( rd_data_rdy_a ),
    .rd_data_rdy_b    ( rd_data_rdy_b ),
    .ram_mux_busy     ( ram_mux_busy  ),
    .collision_rd_rst ( 1'b0          ),
    .collision_wr_rst ( 1'b0          ),
   
    // outputs
    .draw_busy        ( draw_busy     ),
    .rd_req_a         ( rd_req_a      ),
    .rd_req_b         ( rd_req_b      ),
    .wr_ena           ( wr_ena        ),
    .ram_addr         ( ram_addr      ),
    .ram_wr_data      ( ram_wr_data   ),
    .collision_rd     ( collision_rd  ),
    .collision_wr     ( collision_wr  )

);

endmodule


Redo it with just that.

Remember all you need to do in Quartus is add-files-to project and add all the separate geo_xxxx.sv. source files.  Quartus will seek out the initiated module names in all the source files which you are calling inside this 'geometry_processor.sv' and automatically link in the code.  You can even add source files from another directory where you are doing the simulating and editing.  But I personally prefer just copying over each proven single .sv file to my main project folder when changes have been certified.

Also, even if you arent using them, make sure you list all the inputs and output of each module when calling their instances.  And don't forget the parameters.  They are also missing.  To fix the FMAX, it may just be a parameter change.
« Last Edit: August 12, 2020, 04:20:21 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1479 on: August 12, 2020, 08:55:54 pm »
Arrrggg, all you needed was this beginning part:
(We are still developing, testing and adding code to all the geo_xxx.sv  modules.  After changes and simulations you cannot expect to cut and paste code without errors and messing things up.)
...
Redo it with just that.

There I was thinking I was doing good by putting them all into the same file as you'd mentioned that previously.

Remember all you need to do in Quartus is add-files-to project and add all the separate geo_xxxx.sv. source files.  Quartus will seek out the initiated module names in all the source files which you are calling inside this 'geometry_processor.sv' and automatically link in the code.  You can even add source files from another directory where you are doing the simulating and editing.  But I personally prefer just copying over each proven single .sv file to my main project folder when changes have been certified.

Yep, happy with that - I prefer copying the files over from the test folders into the main project folder too, rather than linking to the test files directly.

Also, even if you arent using them, make sure you list all the inputs and output of each module when calling their instances.  And don't forget the parameters.  They are also missing.  To fix the FMAX, it may just be a parameter change.

Ah okay.  I'd only removed the PX_COPY_COLOUR output from pixel_write as (I think?) we only added it for simulation testing.  Am now listing all the I/O for each module.

It all compiles - as it should - but I'm still only getting an Fmax on clk[0] of 103.16 MHz.  I suspect the (slight) increase in Fmax is more due to me changing one of the compilation settings.  I'd changed Compiler Settings -> Optimisation mode to Performance (Aggressive - increases runtime and area), whilst I was searching the net for information on trying to track down bottlenecks in Fmax.

 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1480 on: August 12, 2020, 09:17:45 pm »
It all compiles - as it should - but I'm still only getting an Fmax on clk[0] of 103.16 MHz.  I suspect the (slight) increase in Fmax is more due to me changing one of the compilation settings.  I'd changed Compiler Settings -> Optimisation mode to Performance (Aggressive - increases runtime and area), whilst I was searching the net for information on trying to track down bottlenecks in Fmax.

Please do not choose any compiler options for 'AREA', it means it's trying to shrink the design giving you more area at the cost of FMAX.

I'll look at the code tonight.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1481 on: August 12, 2020, 10:21:22 pm »
It all compiles - as it should - but I'm still only getting an Fmax on clk[0] of 103.16 MHz.  I suspect the (slight) increase in Fmax is more due to me changing one of the compilation settings.  I'd changed Compiler Settings -> Optimisation mode to Performance (Aggressive - increases runtime and area), whilst I was searching the net for information on trying to track down bottlenecks in Fmax.

Please do not choose any compiler options for 'AREA', it means it's trying to shrink the design giving you more area at the cost of FMAX.

I'll look at the code tonight.

I thought that particular option was the other way around - it optimised and prioritised Fmax over area and compilation time.  It did actually increase Fmax from 101.8 MHz to 103.16 MHz, but I was just experimenting whilst trying to find the bottleneck.  :-//
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1482 on: August 13, 2020, 04:26:41 am »
Ok, here you go.  Everything has been updated.
The current bottleneck is a signal path in the pixel_address_generator.sv  limiting the FMAX to 132MHz.
I also increased the maggie layer count to 5.

All 3 quartus projects have been updated and supplied here in separate .zip.
(geo & pixel writer are the simulation projects.  GPU has everything inside.)

You forgot a few connections in the geometry_processor to the Z80_Bridge_v2.sv.
Take a look at the top.bdf so you see the connections and how to drive the geo unit.

Let's see a few pixels, lines, boxes & filled boxes being drawn.
I know of 1 bug I intentionally didn't fix regarding the endian of the stored 16bit graphics, but, let's see this work first before we swap the high & low data byte in the 16bit word.  The error pattern generated when drawing lines will be predictable.
« Last Edit: August 13, 2020, 04:33:14 am by BrianHG »
 
The following users thanked this post: nockieboy

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1483 on: August 13, 2020, 11:16:35 am »
Uhh, really sorry, I seem to have fallen at the first hurdle.  :-[  |O

Here's what I'm trying to do:

1. Set the destination memory pointer to 0x6000
2. Set destination raster width
3. Send command to draw a line from 5,5 to 10,7

I don't mind what colour really, it's overwriting an existing image being displayed in an existing MAGGIE.

I'm clearly not setting up the drawing commands properly as I can't get anything to appear on screen.  I've switched to simulation to test the commands I'm using, and I'm getting the output I've attached at the bottom of this post (seems the forum doesn't like inline images still).

It appears from the simulation that I'm not setting the destination memory pointer properly, as it's writing to address 0000 no matter what I send in the first command.

Obviously I wasn't taking sufficient notes as we built the geo_xy_plotter.  :-[

Oh - the attached image shows a spurious value for the destination memory pointer as I was testing random values to try to get it to write to a memory address other than 0000...  :-/O
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1484 on: August 13, 2020, 12:25:24 pm »
If you don't set the 'cmd_rdy' high, the command isn't accepted.
See:


Also, make sure you arent forcing the GEO unit into a constant reset.  Make sure port 'GEO_STAT_WR' = 0.

Remember, you also need to set the screen pixel width and bits per pixel...

With no screen width set and a bits/pixel setting of 0 as well, your line would only occupy only a single pixel on a 256 color bitmap and 1.2 pixels on a 16 color bitmap.  On a 1 bit color bitmap, your line would occupy 6 horizontal pixels, once again all on Y-coordinate 0, all of them white if the color is an odd number, all black if the color is an even number or 0.
« Last Edit: August 13, 2020, 12:43:06 pm by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1485 on: August 13, 2020, 01:50:15 pm »
Ok, here is what I did.

I tied some of the geometry functions to the RS232 debugger.

When debug port Out0[0] = 0, then
Port In0 = GEO_WR_HI / geo_cmd[15:8].
Port In1 = GEO_WR_LO / geo_cmd[7:0].
Port In2 = geo_ram_addr[15:8].
Port In3 = geo_ram_addr[7:0].
When setting debug port Out0[0] = 1, then only port In2 changes to:
Port In2 = collision_rd[7..0] / RD_PX_CTR.

Ports In0 and In1 should hold your last sent command.
Ports In2 and In3 should hold the last write memory address by the pixel writer.

When port Out0[0] = 1, then In2 increase every time you write a pixel on top of anything other than color 0.  IE:  If the place where the pixel is being written does not contain a value of 0 black, that counter will increase.  IE, plot a white line on a black screen from 0,0 to 9,0, the counter will stay at 0.  Plot the same line again on the same coordinates, since those 10 pixels are white and you are drawing a white line on top, the RD_PX_CTR should increase to 10.  Redraw the same line again and the counter will become 20.  To clear that counter, you will need to read the RD_PX_CTR port which would return that 20, then is should be cleared to 0 on the debugger.

Now, if you were to set the screen width to 16 and 256 color image.
Plotting a line from 0,0 to 0,0 with color 0x25, viewing the base memory address in the RS232 debugger should place the number 0x25 in that first character.
In fact drawing a line from 0,0 to 15,15 should draw a diagonal line on the RS232 debugger's memory window.  Box fills should fill up the debugger's memory window with the selected color.
You may also select a screen width of 32 and 16 color image.  Now the drawn pixels will every half byte.

I've attached the Quartus project in the next post.
« Last Edit: August 13, 2020, 03:20:57 pm by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1486 on: August 13, 2020, 02:07:43 pm »
Woops, stop, I'm fixing the debugger...

Ok, here is the patched _v2 debugger.
The write pixel address now properly shows only the last address where any data has been written to alone.

Here is the attached updated Quartus project:
« Last Edit: August 13, 2020, 02:15:51 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1487 on: August 13, 2020, 03:32:58 pm »
Okay, the simulation seems to be running okay now but I'm not getting comparable results in the hardware.  :-BROKE

I've attached an image of the simulation output - the commands and data being entered into the simulation are the same as I'm entering into the GPU via 'OUT' commands, i.e.:

Code: [Select]
OUT 246,19;:OUT 247,160
Ready
OUT 246,7;:OUT 247,115
Ready
OUT 246,0;:OUT 247,128
Ready
OUT 246,6;:OUT 247,192
Ready
OUT 246,1;:OUT 247,124
Ready
OUT 246,90;:OUT 247,128
Ready
OUT 246,100;:OUT 247,192
Ready
OUT 246,0;:OUT 247,95
Ready
OUT 246,1;:OUT 247,128
Ready
OUT 246,4;:OUT 247,192
Ready
OUT 246,20;:OUT 247,4
Ready
OUT 246,4;:OUT 247,208
Ready
OUT 246,255;:OUT 247,1
Ready

As you can see, I'm entering them one 16-bit command at a time.  In theory (at least), when that last OUT 247,1 is executed, the geo_unit should draw a broken (dotted?) line across my image.  The RS232_debugger confirms that the GPU is receiving the commands - so either I'm making a silly mistake (likely) or there's a problem in the HDL?
« Last Edit: August 13, 2020, 03:38:32 pm by nockieboy »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1488 on: August 13, 2020, 03:36:52 pm »
Does the debugger show a write address?
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1489 on: August 13, 2020, 03:44:21 pm »
Does the debugger show a write address?

Yes, shows the following:

Code: [Select]
In0[7:0]=8'b00000001 =8'h01=8'd001.
In1[7:0]=8'b11111111 =8'hFF=8'd255.
In2[7:0]=8'b01100000 =8'h60=8'd096.
In3[7:0]=8'b10100010 =8'hA2=8'd162.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1490 on: August 13, 2020, 04:07:46 pm »
Now when looking at that address in the debugger, what is the value.  Is it the written color number?

BTW, if the geo didn't send a true write comman, that address would read 0.

Making a line to a new ending coordinate, as long as it is at a different address will also change that number..

When testing, try making a single point line where you know the address would be.
Reading that address in the debugger will show you if and what data has been written in real time.

« Last Edit: August 13, 2020, 04:10:54 pm by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1491 on: August 13, 2020, 04:13:01 pm »
Now, am I wasting my time making building your latest project into my fixture and programming the geo unit byte-by-byte using the rs232 debugger to verify your results?
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1492 on: August 13, 2020, 04:14:40 pm »
Okay, I've cleared the image to zero and it appears to be writing to 604C and 604D - both FF values.  That doesn't match the sim output?

Now, am I wasting my time making building your latest project into my fixture and programming the geo unit byte-by-byte using the rs232 debugger to verify your results?

You know me too well.  :-[
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1493 on: August 13, 2020, 04:41:49 pm »
Okay, so a single-pixel write at location 1,1 causes a write to GPU address 6015, value FF.  As the RS232_debugger confirms, it looks as though the base memory address is set slightly higher than 6000.

Single-pixel write to location 2,2 causes a write to GPU addresses 6014 AND 6029 (with just 6028 appearing in the simulator).

Drawing a line from 1,1 to 18,20 causes three bytes to be written to - in no particular geometric order - and the last byte at 6076 remains at FF, no matter what I do to change it in the RS232_debugger.  :-//
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1494 on: August 13, 2020, 04:47:56 pm »
Okay, so a single-pixel write at location 1,1 causes a write to GPU address 6015, value FF.  As the RS232_debugger confirms, it looks as though the base memory address is set slightly higher than 6000.

1,1 is not 0,0.
Also, why is you screen width an odd number like 15 instead of 16.

This means that at line 1 (IE +15) and pixel 1 (IE+1) + shave off the LSB, wait hold on, are some figures here decimal and others hex and you are mixing the 2?

Also when you plot on a screen, you need to match the MAGGIE's pixel width count, NOT the byte count which we use in the MAGGIE HW control register unless it is an 8 bit 256 color screen where these 2 figures will match.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1495 on: August 13, 2020, 04:50:56 pm »
YOU DIRTY RAT BASTARD.  You know I don't have a Z80 to fix this problem:

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1496 on: August 13, 2020, 05:09:39 pm »
YOU DIRTY RAT BASTARD.  You know I don't have a Z80 to fix this problem:
(Attachment Link)

Fix it high and it'll be fine.  :-+  It's not a feature I use (at the moment - it may be useful later), it was just something I added to test IO writes early on.

Okay, so a single-pixel write at location 1,1 causes a write to GPU address 6015, value FF.  As the RS232_debugger confirms, it looks as though the base memory address is set slightly higher than 6000.

1,1 is not 0,0.
Also, why is you screen width an odd number like 15 instead of 16.

This means that at line 1 (IE +15) and pixel 1 (IE+1) + shave off the LSB, wait hold on, are some figures here decimal and others hex and you are mixing the 2?

Also when you plot on a screen, you need to match the MAGGIE's pixel width count, NOT the byte count which we use in the MAGGIE HW control register unless it is an 8 bit 256 color screen where these 2 figures will match.


Yeah, fair point. I've gone back to the MAGGIE settings for the image and have corrected the width and height - they should be 74 and 91 pixels respectively.  That'll teach me to use ballpark figures.

I've just tried plotting to 2,2 and got a write to 6003, when the sim says it should be 6028.  I'm going to keep testing though to rule out user error.  ::)

I've also been contending with a problem with accessing GPU RAM.  It seems the GPU doesn't like the Z80 doing block writes - i.e. I've tried to clear a block of RAM (erase the image) using LDIR and it results in some very... interesting... behaviour.  The Z80 reads the RAM and sees all zeroes, as it should be, but the RS232_debugger sees some zeroes and mostly FFs.  I have to power-off the whole thing and restart to be able to write to RAM properly again.  Odd.  Has anything changed with regard to the Z80_bridge bus timings or something?
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1497 on: August 13, 2020, 05:39:25 pm »
Is the bit order backwards?  Plotting to 1,0 changes the first byte from FF to FC in 2-bits per pixel.  Even then, it's still out by 1 bit-pair - it should be zeroing bits 5 & 4, not 1 & 0.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1498 on: August 13, 2020, 05:40:52 pm »
Ok, I've done this.  I'm only getting the first 5 out of 10 pixels, but, they are correct except for the endian error.

Take a look at photo 1 for the commands I sent to the GPU.

Take a look at photo 2 for the memory before executed draw line.

Take a look at photo 3 for after the line draw.  (Ignore endian error)

Endian patch coming in 10 minutes.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #1499 on: August 13, 2020, 06:12:40 pm »
Here is the output after the endian patch.

I've attached the new quartus project.

For some reason, the geo unit seems to freeze after 5 pixels are drawn.

Need to create a simulation test bench with all 3 modules tied together.



 
The following users thanked this post: nockieboy


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf