FPGA VGA Controller for 8-bit computer

[nockieboy]

Here it is.

[BrianHG]

Ok, you can change your line:

Code: [Select]

        if ( cmd_ready && ~geo_run && !draw_busy ) begin  // when the cmd_read input is high and the geometry unit geo_run is not running, execute the following command input
To:

Code: [Select]

        if ( cmd_ready && ~geo_run && !(draw_busy && draw_cmd_tx) ) begin  // when the cmd_read input is high and the geometry unit geo_run is not running, execute the following command input

All this has done is if after pulsing the 'draw_cmd_tx' for 1 clock, or the draw_busy just went high after the draw_cmd_tx' has ended, the geometry_xy_plotter can still receive new commands like setup x/y coordinates which do not get transmitted to the pixel writer, so those commands are still free to be run.

Also, let's see you make a cheap addition which will prevent the 'draw_cmd_tx' from going high when the drawing coordinates are outside the minimum and maximum screen view area.  Show a functional test.  (This one should be easy peasy)

Next, the pixel_address_generator.sv

This module sits in-between the geometry_xy_plotter.sv and pixel_writer.sv.
Like I said in my last post, it takes in the draw command, holds / intercepts the commands with registers settings it uses itself to calculate a memory address (2 of them, normal write pixel and read pixel), pixel bitplane type & pixel location on the bitplane, and passes the write / read command with pixel bitplane type and color to the next pixel_writer.sv module.

Let's see how you would begin this module.  Remember the commands which will be fed through this module:

Code: [Select]

    //  AUX=0  : Do nothing
    //  AUX=1  : Write pixel,                             : 31:24 color         : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=2  : Write pixel with color 0 mask,           : 31:24 color         : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=3  : Write from read pixel,                   : 31:24 ignored       : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=4  : Write from read pixel with color 0 mask, : 31:24 ignored       : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=6  : Read source pixel,                       : 31:24 ignored       : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=7  : Set Truecolor pixel color                : 31:24 8 bit alpha blend mix value : bits 23:0 hold RGB 24 bit color
    //                                                    Use function Aux3/4 to draw this color, only works if the destination is set to 16 bit true-color mode

    //  AUX=10 ; Resets the Write Pixel collision counter           : 31:24 sets transparent masked out color : bits 23:0 in true color mode, this holds RGB 24 bit mask color, in 8 bit mode, this allows for 3 additional transparent colors
    //  AUX=11 ; Resets the Write from read pixel collision counter : 31:24 sets transparent masked out color : bits 23:0 in true color mode, this holds RGB 24 bit mask color, in 8 bit mode, this allows for 3 additional transparent colors

    //  AUX=12 : Set destination raster width in bytes    : 15:0 holds destination raster image width in #bytes so the proper memory address can be calculated from the X&Y coordinates
    //  AUX=13 : Set source raster width in bytes,        : 15:0 holds source raster image width in #bytes so the proper memory address can be calculated from the X&Y coordinates
    //  AUX=14 : Set destination mem address,             : 31:24 bitplane mode : 23:0 hold destination base memory addres for write pixel
    //  AUX=15 : Set source mem address,                  : 31:24 bitplane mode : 23:0 hold the source base memory address for read source pixel

Now choose output buss which can drive the pixel_writer.sv.
Like mem address, bitplane size, read/write, color.  In fact, make it another 36bit pixel_cmd  bus with a 'pixel_cmd_rdy' and decide what the structure of the bits within will contain with 16 possible functions.

Let's see how your pixel_address_generator.sv will begin.

I have time now to work on the new data_mux_geo.sv.

----------------------------------------------------------------------
Maybe we should move :
' 31:24 bitplane mode ' in aux 14&15 into the top of aux 12&13.  This way, there is more space a larger address for future growth.
----------------------------------------------------------------------

[BrianHG]

Here it is, the new Data_mux_GEO.sv module.
If you care to decipher this sim snapshot, be my guest...



I've attached the Quartus project 'Data_mux_geo_sim.zip' for reference.
I've also attached the Quartus project 'GPU_EP4CE10_quick_Data_mux_GEO.zip' which contains a full new GPU project with the new Data_mux_geo wired into the top schematic block diagram.  There was also a minor change in the 16 port memory interface.  Please compile and use this new GPU project from now on as it will become obligatory within a few days as your geo_xy_plotter/pixel_writer requires it to function if you want to see any geometric objects.

There was even an addition to the 'rs232_DEBUGGER.v' to make it's 'host_rd_req's a single clock cycle long.  So you need to test the RS232 debugger display ram as well.

'rs232_DEBUGGER.v' ver. 1.1 located here: rs232_DEBUGGER forum thread.

(That lousy async VHDL PS2 keyboard decoder is screwing up your final fitter's results with tons of timing violations.)

[BrianHG]

A little math says that even under the worst case scenario, at 320x240x16 colors, your geometry plotter can fill the entire screen with triangles over 300 times a second.  Or, in 1/60th of a second, you can repaint the entire screen just over 5 times.

I'm not sure the Z80 can keep up unless all it did was re-transmit the same filled triangle / filled box / filled ellipse, 1 which would cover the entire screen with just a new color each time, written in assembly.  Maybe just a random number generator for making random screen shapes & random sizes / colors might peak the geometry unit.  You might need a 20MHz Z80.

Hurry up so we can get past the geometry engine to the blitter stage so I can force some upgrades there as well.
Though, your gonna want more ram very quick here.  But I guess you can work with 160x120@16 or 256 colors for now.

[nockieboy]

A little math says that even under the worst case scenario, at 320x240x16 colors, your geometry plotter can fill the entire screen with triangles over 300 times a second.  Or, in 1/60th of a second, you can repaint the entire screen just over 5 times.

I'm not sure the Z80 can keep up unless all it did was re-transmit the same filled triangle / filled box / filled ellipse, 1 which would cover the entire screen with just a new color each time, written in assembly.  Maybe just a random number generator for making random screen shapes & random sizes / colors might peak the geometry unit.  You might need a 20MHz Z80.

I was thinking along the  lines of a random line/triangle generator.  Will write one as soon as we finalise the interface. 

Hurry up so we can get past the geometry engine to the blitter stage so I can force some upgrades there as well.

Yeah, sorry - my day job is getting in the way at the moment.  I've downloaded the project files, but won't be able to look at anything for maybe another 8 hours as I'm out in a sec. 

[nockieboy]

Here it is, the new Data_mux_GEO.sv module.

There's some weird stuff going on with the attachments.  Looks like Data_mux_geo_sim.zip is okay, but GPU_EP4CE10_quick_Data_mux_GEO.zip is coming out as a PNG. 

The forum bug strikes again.

[BrianHG]

The forum is in meltdown mode, read here: https://www.eevblog.com/forum/chat/website-error-reports/msg3138580/#msg3138580

I'm re-posting the attachments here:

[BrianHG]

Warning, the Z80_bridge_v2 is missing the additions made over here:

https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3123790/#msg3123790

& the post right after...

[nockieboy]

Warning, the Z80_bridge_v2 is missing the additions made over here:

https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3123790/#msg3123790

& the post right after...

Can I just copy the Z80_bridge_v2.sv into your latest version of the project, or did you make any changes to that as well?

[BrianHG]

yes.  just copy is fine.

[nockieboy]

Okay, new project works fine (just had to key-in the correct memory size into the Z80_bridge's parameters).  In other news, the RS232_debugger update seems to be working fine as well, with no issues reading the GPU RAM so far.

[BrianHG]

Ok, lets see your setup of the pixel memory address generator.

[nockieboy]

Ok, lets see your setup of the pixel memory address generator.

I haven't had any time to really make progress with it.  This is all I've got so far:

Code: [Select]

module pixel_address_generator (

    // inputs
    input wire clk,              // System clock
    input wire reset,            // Force reset
   
    input wire draw_cmd_rdy,     // Pulsed HIGH when data on draw_cmd[15:0] is valid
    input wire [35:0] draw_cmd,  // Bits [35:32] hold AUX function number 0-15:
    //  AUX=0  : Do nothing
    //  AUX=1  : Write pixel,                             : 31:24 color         : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=2  : Write pixel with color 0 mask,           : 31:24 color         : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=3  : Write from read pixel,                   : 31:24 ignored       : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=4  : Write from read pixel with color 0 mask, : 31:24 ignored       : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=6  : Read source pixel,                       : 31:24 ignored       : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=7  : Set Truecolor pixel color                : 31:24 8 bit alpha blend mix value : bits 23:0 hold RGB 24 bit color
    //                                                    Use function Aux3/4 to draw this color, only works if the destination is set to 16 bit true-color mode

    //  AUX=10 ; Resets the Write Pixel collision counter           : 31:24 sets transparent masked out color : bits 23:0 in true color mode, this holds RGB 24 bit mask color, in 8 bit mode, this allows for 3 additional transparent colors
    //  AUX=11 ; Resets the Write from read pixel collision counter : 31:24 sets transparent masked out color : bits 23:0 in true color mode, this holds RGB 24 bit mask color, in 8 bit mode, this allows for 3 additional transparent colors

    //  AUX=12 : Set destination raster width in bytes    : 15:0 holds destination raster image width in #bytes so the proper memory address can be calculated from the X&Y coordinates
    //  AUX=13 : Set source raster width in bytes,        : 15:0 holds source raster image width in #bytes so the proper memory address can be calculated from the X&Y coordinates
    //  AUX=14 : Set destination mem address,             : 31:24 bitplane mode : 23:0 hold destination base memory addres for write pixel
    //  AUX=15 : Set source mem address,                  : 31:24 bitplane mode : 23:0 hold the source base memory address for read source pixel

    // outputs
    output wire pixel_cmd_rdy,
    output wire [35:0] pixel_cmd
   
);

wire [3:0]  aux_cmd_in;
wire [7:0]  command_in;
wire [11:0] command_data12;
wire [7:0]  command_data8;

assign aux_cmd_in     [3:0] = draw_cmd[35:32];
assign command_in     [7:0] = draw_cmd[15:8];
assign command_data12[11:0] = draw_cmd[11:0];
assign command_data8  [7:0] = draw_cmd[7:0];

always @(posedge clk or posedge reset) begin

    if ( draw_cmd_rdy && ( aux_cmd_in[3:0] == 1 || aux_cmd_in[3:0] == 6 ) ) begin   // AUX command 1 (write pixel) or 6 (read pixel)

    end

end // always @ posedge clk or reset

endmodule


[BrianHG]

You posted way too early.
Your commands have nothing to do with the AUX labels and data entities.

[nockieboy]

You posted way too early.
Your commands have nothing to do with the AUX labels and data entities.

You said you wanted to see what I'd done so far.    I have updated the code in my previous post with what I think is required for picking out the write and read pixel commands.

[nockieboy]

Also, let's see you make a cheap addition which will prevent the 'draw_cmd_tx' from going high when the drawing coordinates are outside the minimum and maximum screen view area.  Show a functional test.  (This one should be easy peasy)

Yeah, you say that, but... 

So, I've got max_x and max_y, geo_x and geo_y to work with.  So a simple check in the draw_cmd_rdy assignment should do the trick?

Code: [Select]

assign draw_cmd_rdy    = draw_cmd_tx && geo_x < max_x && geo_y < max_y;

I've simulated the code, but something odd is happening.  I've included the test project for you to try.  I'm setting max_x and max_y to 160,100 and the line to start at 25,20 and end at 175,110.  However, it seems the line doesn't reach x=175 and y=110 simultaneously, so it fails the end check and continues forever. (The 'outside screen bounds' check seems to be working, though). 

[gcewing]

I'm setting max_x and max_y to 160,100 and the line to start at 25,20 and end at 175,110.  However, it seems the line doesn't reach x=175 and y=110 simultaneously, so it fails the end check and continues forever.

You only need to check one of the coordinates to decide when to stop. Preferably whichever one you're taking single pixel steps along.

[BrianHG]

Also, let's see you make a cheap addition which will prevent the 'draw_cmd_tx' from going high when the drawing coordinates are outside the minimum and maximum screen view area.  Show a functional test.  (This one should be easy peasy)

Yeah, you say that, but... 

So, I've got max_x and max_y, geo_x and geo_y to work with.  So a simple check in the draw_cmd_rdy assignment should do the trick?

Code: [Select]

assign draw_cmd_rdy    = draw_cmd_tx && geo_x < max_x && geo_y < max_y;

I've simulated the code, but something odd is happening.  I've included the test project for you to try.  I'm setting max_x and max_y to 160,100 and the line to start at 25,20 and end at 175,110.  However, it seems the line doesn't reach x=175 and y=110 simultaneously, so it fails the end check and continues forever. (The 'outside screen bounds' check seems to be working, though). 

Arrrg, you found a line which fails... hang on a sec....
Looking back...

[BrianHG]

Geo.bas does not fail to find the end of the line where as we have this problem here with the verilog version:

Ending illustration:



Beginning illustration:



Debug time...

[BrianHG]

Found bug:
Line 311 was:

Code: [Select]

if (((errd+dy)<<1) < dx) beginShould have been:

Code: [Select]

if (((errd<<1)+dy) < dx) begin
errd had to be shifted first, then add the dy.

Next post, your limit-box drawing area code.

[BrianHG]

Ok, here are how the limits should have been done in the attached simulation project.

We need the check inside the plotting look since we may have other variables sent to be plotted other than geo_x/geo_y, like during the raster fill.

Because of F-MAX (we are on the red line), we may need to separate the plotting of pixels by 1 clock and doing the valid range test on those intermediate registers.  For now, let's continue as it is functional.  Remember, this will come back to us.  We may just make a range module in between the plotter and address generator, or part of the address generator.

[BrianHG]

I'm setting max_x and max_y to 160,100 and the line to start at 25,20 and end at 175,110.  However, it seems the line doesn't reach x=175 and y=110 simultaneously, so it fails the end check and continues forever.

You only need to check one of the coordinates to decide when to stop. Preferably whichever one you're taking single pixel steps along.

This solution would have led to never fixing our edge of line rounding error as our verilog Bresenham algorithm did an add before a bit shift coding error seen here: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3141704/#msg3141704

This is the reason for the geo.bas emulator.  Double verification of bugs.

Also validating only 1 coordinate means if we check the Y coordinate only, and we are drawing a 2 pixel tall, 100 pixel wide horizontal line, right at the last Y increment, we would have completed the line before drawing across the rest of the screen to the end x coordinate.

[BrianHG]

Awww, another future bug:
Line 137:

Code: [Select]

        if ( cmd_ready && ~geo_run && !(draw_busy && draw_cmd_tx) ) begin  // when the cmd_read input is high and the geometry unit geo_run is not running, execute the following command input

Should be switched back to:

Code: [Select]

        if ( cmd_ready && ~geo_run && !draw_busy ) begin  // when the cmd_read input is high and the geometry unit geo_run is not running, execute the following command input

I know I said otherwise but I forgot that the line drawing may be processing pixels off the edge of the visible display.

Attached is the latest:

[gcewing]

Also validating only 1 coordinate means if we check the Y coordinate only, and we are drawing a 2 pixel tall, 100 pixel wide horizontal line, right at the last Y increment, we would have completed the line before drawing across the rest of the screen to the end x coordinate.

A line like that would normally be drawn by incrementing the x coordinate, not the y coordinate.

[nockieboy]

Can I just clarify exactly what's going on with the pixel_address_generator?

As I understand it, it takes 36-bit draw commands in from the geometry_xy_plotter and converts the x and y coordinates into a memory address, then passes that memory address out (and associated command relating to what is to be done at that address) as a 36-bit pixel_cmd.

So it will need to act upon the following AUX commands (and maybe more?):

• AUX 1
• AUX 2
• AUX 3
• AUX 4
• AUX 6 (Is AUX 5 reserved for a later feature?)

But, initially at least, you want to work on AUX 1 & 6.  Is that right?

Code: [Select]

module pixel_address_generator (

    // inputs
    input wire clk,              // System clock
    input wire reset,            // Force reset
   
    input wire draw_cmd_rdy,     // Pulsed HIGH when data on draw_cmd[15:0] is valid
    input wire [35:0] draw_cmd,  // Bits [35:32] hold AUX function number 0-15:
    //  AUX=0  : Do nothing
    //  AUX=1  : Write pixel,                             : 31:24 color         : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=2  : Write pixel with color 0 mask,           : 31:24 color         : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=3  : Write from read pixel,                   : 31:24 ignored       : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=4  : Write from read pixel with color 0 mask, : 31:24 ignored       : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=6  : Read source pixel,                       : 31:24 ignored       : 23:12 Y coordinates : 11:0 X coordinates
    //  AUX=7  : Set Truecolor pixel color                : 31:24 8 bit alpha blend mix value : bits 23:0 hold RGB 24 bit color
    //                                                    Use function Aux3/4 to draw this color, only works if the destination is set to 16 bit true-color mode

    //  AUX=10 ; Resets the Write Pixel collision counter           : 31:24 sets transparent masked out color : bits 23:0 in true color mode, this holds RGB 24 bit mask color, in 8 bit mode, this allows for 3 additional transparent colors
    //  AUX=11 ; Resets the Write from read pixel collision counter : 31:24 sets transparent masked out color : bits 23:0 in true color mode, this holds RGB 24 bit mask color, in 8 bit mode, this allows for 3 additional transparent colors

    //  AUX=12 : Set destination raster width in bytes    : 15:0 holds destination raster image width in #bytes so the proper memory address can be calculated from the X&Y coordinates
    //  AUX=13 : Set source raster width in bytes,        : 15:0 holds source raster image width in #bytes so the proper memory address can be calculated from the X&Y coordinates
    //  AUX=14 : Set destination mem address,             : 31:24 bitplane mode : 23:0 hold destination base memory addres for write pixel
    //  AUX=15 : Set source mem address,                  : 31:24 bitplane mode : 23:0 hold the source base memory address for read source pixel

    // outputs
    output wire pixel_cmd_rdy,
    output wire [35:0] pixel_cmd
   
);

// 3     3 3             2 2               1     1 1     0 0             0
// 5     2 1             4 3               5     2 1     8 7             0
// |     | |             | |               |     | |     | |             |
// 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
// |-AUX-|                                 |--COMMAND IN-| |COMMAND_DATA8|
// |-AUX-|                                 |-CMD-| |----COMMAND_DATA12---|
// |AUX01| |----COLOUR---| |-----Y COORDINATE----| |-----X COORDINATE----|
// |AUX02| |----COLOUR---| |-----Y COORDINATE----| |-----X COORDINATE----|
// |AUX03|                 |-----Y COORDINATE----| |-----X COORDINATE----|
// |AUX04|                 |-----Y COORDINATE----| |-----X COORDINATE----|
// ...
// |AUX06|                 |-----Y COORDINATE----| |-----X COORDINATE----|
// |AUX07| |-ALPHA BLEND-| |-------------24-bit RGB COLOUR---------------|
// ...
// |AUX10| |-TRANSP MASK-| |RGB 24-bit MASK COLOUR OR 3 ADD TRANS COLOURS|
// |AUX11| |-TRANSP MASK-| |RGB 24-bit MASK COLOUR OR 3 ADD TRANS COLOURS|
// |AUX12|                                 |---DEST RASTER IMAGE WIDTH---|
// |AUX13|                                 |--SOURCE RASTER IMAGE WIDTH--|
// |AUX14| |BITPLANE MODE| |-------DESTINATION BASE MEMORY ADDRESS-------|
// |AUX15| |BITPLANE MODE| |----------SOURCE BASE MEMORY ADDRESS---------|

wire [3:0]  aux_cmd_in     = draw_cmd[35:32];
wire [7:0]  command_in     = draw_cmd[15:8];
wire [11:0] command_data12 = draw_cmd[11:0];
wire [7:0]  command_data8  = draw_cmd[7:0];

wire [11:0]              x = draw_cmd[11:0];
wire [11:0]              y = draw_cmd[23:12];

always @(posedge clk or posedge reset) begin

    if ( draw_cmd_rdy && ( aux_cmd_in[3:0] == 1 || aux_cmd_in[3:0] == 6 ) ) begin   // AUX command 1 (write pixel) or 6 (read pixel)



    end

end // always @ posedge clk or reset

endmodule


I'm hoping what I've done above is vaguely on the right track, but I'm short on ideas as to what to do next.  To translate to a memory address, we're going to need to take into account the screen mode (bits/bytes per pixel) and do some multiplication along the lines of:

memory_address = offset + ( y * screen_width + x ) * bytes_per_pixel