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

0 Members and 49 Guests are viewing this topic.

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2225 on: December 13, 2020, 05:18:03 am »
Ok, let's take a look at what needs to be done with your code.

The line generator outline is ok. maybe we should rename a few things for ease of understanding.

Code: [Select]
/*
 * ELLIPSE GENERATOR MODULE
 *
 * v 0.1.001
 *
 */

module ellipse_generator (
// inputs
  input logic                clk,              // 125 MHz pixel clock
  input logic                reset,            // asynchronous reset
  input logic                enable,           // logic enable
  input logic                run,              // HIGH to draw / run the unit
  input logic          [1:0] quadrant,         // specifies which quadrant of the ellipse to draw
  input logic signed  [11:0] Xc,               // 12-bit X-coordinate for center of ellipse
  input logic signed  [11:0] Yc,               // 12-bit Y-coordinate for center of ellipse
  input logic signed  [11:0] A,               // 12-bit X-radius, the width
  input logic signed  [11:0] B,               // 12-bit Y-radius, the height
  input logic                ena_pause,         // set HIGH to pause line generator while it is drawing
// outputs
  output logic               busy,             // HIGH when ellipse_generator is running
  output logic signed [11:0] X_coord,          // 12-bit X-coordinate for current pixel
  output logic signed [11:0] Y_coord,          // 12-bit Y-coordinate for current pixel
  output logic               pixel_data_rdy,   // HIGH when coordinate outputs are valid
  output logic               ellipse_complete     // HIGH when ellipse is completed
 
);

Next, some of the internal logic:

Code: [Select]
logic               draw_line     = 1'b0 ;
logic        [1:0]  quadrant_latch = 2'b0 ;  // This logic latches which quadrant to draw when run is issued
logic        [2:0]  geo_sub_func1 = 3'b0 ;  // This logic defines which step is running, IE first setup for first 45 degrees,
                              // draw the first 45 degrees if the radius is not 0, finish the ellipse if the remaining radius is <=1,
                              // setup for the second 45 degrees (inv), draw the second 45 degrees if the radius is not 0,
                              // finish the ellipse if the remaining radius is <=1, end the busy and await the next command.
logic signed [11:0] x                   ;  internal drawing x coordinate
logic signed [11:0] y                   ;  internal drawing x coordinate
logic signed [11:0] af                  ;
logic signed [11:0] ab                 ;
logic signed [23:0] a2                 ; // Note that the 4* fa2 & fb2 arent needed as they will just be a logic shift inside the code
logic signed [23:0] b2                 ;
logic signed [23:0] sigma            ;

logic               pixel_data_rdy_int   ;     // HIGH when coordinate outputs are valid
logic               busy_int             ;     // HIGH when coordinate outputs are valid

Now for the combinational logic:

Code: [Select]
always_comb begin

   pixel_data_rdy = pixel_data_rdy_int && !ena_pause ; // immediately clear the pixel_data_ready output when the pause is high.
   busy           = busy_int || run ;                  // immediately make busy flag high when run is asserted
   
end

This stays the same as these outputs are crucial to match & be compliant with the line-generator's output.

Now, for the next part:
Code: [Select]
always_ff @( posedge clk  or posedge reset) begin

   if ( reset ) begin
   
      // reset geometry counters and flags
// *********  Fill this in ********* //
       
   end
   else if ( enable ) begin // draw_busy_int must be LOW or the line generator won't run

      if ( run ) begin  // load values and begin drawing the line

         // Initialise starting coordinates and direction for immediate plotting
         quadrant_latch <= quadrant   ; // latch which of the 4 quadrants will be drawn

         if ((A==0) && (B==0)) begin // 0 X&Y radius, drawing only a single center point

         X_coord            <= Xc   ; // initialize starting X pixel location
         Y_coord            <= Yc   ; // initialize starting Y pixel location

            pixel_data_rdy_int <= 1'b1 ; // set pixel_data_rdy_int flag
            line_complete      <= 1'b1 ; // make sure line_complete is set.
            geo_sub_func1      <= 1'b0 ; // reset the phase counter
            draw_line          <= 1'b0 ; // no line to draw
            busy_int           <= 1'b0 ; // the line generator is busy_int  from the next cycle

         end
         else begin //  Drawing a full ellipse

// *********  Work on this  ********* //

Use the other code to begin.  First start initialize the variables and begin only the first 45 degrees.
Just output the X&Y, do not bother with any quadrants yet.
Setup a simulation test bench in Quartus driving the input and a clock.  No other modules.
Drive some test inputs and I'll prepare the Freebasic code to print out the rendered coordinates of the arc.


(Arrrrgggg, the page count is over 9000 ......)
« Last Edit: December 13, 2020, 05:27:02 am by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2226 on: December 13, 2020, 06:16:59 am »
Ok, here is the freebasic geoarc.bas & exe.
The green and red text show the two 45 degree phases of the computed X&Y arc coordinates.
The cyan and magenta text which occasionally appears shows the flat line remaining at the end of an arc or a flat arc.

Your verilog simulation test bench should spit out the same numbers given the same a&b radius.
 
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 #2227 on: December 13, 2020, 01:21:03 pm »
Bit confused - we've got no 'inv' input and what are 'af' and 'ab' for?  I guess they're 'a' and 'b' in the FreeBasic ellipse function - but instead of setting them via 'inv', am I supposed to set them via the current geo_sub_func1 value?  ???
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2228 on: December 13, 2020, 01:29:20 pm »
Bit confused - we've got no 'inv' input and what are 'af' and 'ab' for?  I guess they're 'a' and 'b' in the FreeBasic ellipse function - but instead of setting them via 'inv', am I supposed to set them via the current geo_sub_func1 value?  ???

geo_sub_func1 is just a logic register to store which state your sequencer is running.

IE, when run is asserted, do your setup and make it 1.
When it's 1, do something else like run the main first arc.
When that arc completes, make it 2 if you need to finish drawing a flat line, otherwise make it 3.
When it's 2, finish the flat line and make it 3.
When it's 3, for now, stop/complete line and make the module into it's idle non-running state.

(Though, states 3 through 6 would generate the 'inv' portion of the arc, but for now, just worry about steps 1-3).

Think of it like a program counter.
A program counter where you need to tell it to increment only when you are ready to stop what you are currently doing and get onto the next step, or jump somewhere else.

You have already done this before in the old line_generator and a number of other times using the 'case' command, or, if() / else if() sequences.
« Last Edit: December 13, 2020, 09:59:15 pm by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2229 on: December 13, 2020, 01:40:25 pm »
I'll be back lateron tonight, so, setup any sequencer & a sim test bench for now, even if you don't get the formula exactly right.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2230 on: December 13, 2020, 03:06:50 pm »
See attached for test bench setup.  I've just used the ellipse_generator.sv file, no frills or extra modules, to test its output.

As far as the ellipse_generator module goes, it's nowhere near finished yet.  I've added some logic to more closely match the FreeBasic function - things I feel were needed - but you may have been one or two steps ahead of me in optimising the HDL routine when you specified the inputs originally, so I may have added some things that aren't right / needed.

I have the very basic framework of the ellipse generation, but am not finishing the ellipse off yet.  It looks like I need at least one more geo_sub_func1 step to complete the final 'for...next' loop to finish the line.  Not sure I'm going down the right route, so feedback appreciated.  Will have more time tomorrow to work on this, today is busy unfortunately.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2231 on: December 13, 2020, 10:19:36 pm »
Please reserve the test bench/project names.

I believe we had the Geo-Writer as a complete build of the geometry system, actual commands in, written pixels to a memory module out.

Right now, all I wanted was the ellipse module, naked all on it's own for debugging.

Just it's inputs fed and outputs viewed.  No Z80 geometry command system.
Just like the first line_generator's test bench we had oh-so-many months ago.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2232 on: December 13, 2020, 10:32:57 pm »
Please reserve the test bench/project names.

I believe we had the Geo-Writer as a complete build of the geometry system, actual commands in, written pixels to a memory module out.

Right now, all I wanted was the ellipse module, naked all on it's own for debugging.

Just it's inputs fed and outputs viewed.  No Z80 geometry command system.
Just like the first line_generator's test bench we had oh-so-many months ago.

Yeah, that's what you've got.  Because I copied the folder from the geo_writer_v7 for the new project, it has the same name.  But all it is in the test bench is the ellipse_generator.sv, no other fluff.

The ellipse_generator.sv file is in the test bench project, but I've added it here as requested.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2233 on: December 15, 2020, 02:19:42 am »
     Ok, here we go.  You made a few mistakes like when you had to multiply by 2, you right left shifted by 2.   That's wrong.  A right left shift by 1 is a multiply by 2.  Though you did get the multiply by 4 correct???

     OK, that being said, I redone the 'case' statement layout and removed some glutt.

     In the TB, I changed all the coordinates from hex to signed decimal for ease of viewing.

     The current FMAX is 84 MHz, a far cry from the required 125MHz or preferred 150MHz.
We are also eating 24 9bit embedded multipliers.  It turns out this way because of all the parallel non-matched multiplies used all over the place.  Some we can get rid of by using 2 clock cycles 2 perform 2 different multiplies, such as the multiple '^2' for the X & Y used in the setup before the arc begins to draw.

     In the new Cyclone V, you using 7 DSP blocks out of 28.  Though the rest of the GPU only uses 2 more.  Also, it's sad that the CV FMAX has dropped to 80MHz.  (This might be due to other factors which may disappear when the logic becomes embedded deep within the core of the FPGA, like the way the IO pins are timed.)

     I've attached all the updates.

     The next step is to increase the FMAX before we continue as all the rest of the logic just reloads the current arc loop with flipped X&Y or, completes a straight line.  The final step is to add or subtract the ellipse center coordinates from the rendered X&Y depending on the requested 'quadrant'

     Step 1, looking at the code, how do you think we will attack the low FMAX and get it above 125MHz?

(For those reading, the current code only generates the first green part of the ellipse shown in the freebasic screenshot image)
« Last Edit: December 15, 2020, 03:14:06 am by BrianHG »
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15444
  • Country: fr
Re: FPGA VGA Controller for 8-bit computer
« Reply #2234 on: December 15, 2020, 02:21:20 am »
     Ok, here we go.  You made a few mistakes like when you had to multiply by 2, you right shifted by 2.   That's wrong.  A right shift by 1 is a multiply by 2...

You probably meant left shift?
 
The following users thanked this post: BrianHG

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2235 on: December 15, 2020, 02:24:06 am »
     Ok, here we go.  You made a few mistakes like when you had to multiply by 2, you right shifted by 2.   That's wrong.  A right shift by 1 is a multiply by 2...

You probably meant left shift?
My mild form of dyslexia kicking in.  I always flip things around, not just letters, but signs and directions when coding.  Thank god the only thing I don't flip around is +&- when powering electronics or diode orientation.
« Last Edit: December 15, 2020, 02:34:51 am by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2236 on: December 15, 2020, 06:39:30 am »
Ok, Nockieboy, I've attached an update.  It seems to function identical to the first code, but, it now compiles with an FMAX of 100MHz.  Double check my math.

I foresee problems.  Part of the trick I employed ate up a few more multipliers.  Plus, because of the damn While/If () loop which compares B^2*x with A^2*y, which was originally done/cropped to 24 bits, we may need to do it at 32 bits.  If the width of the ellipse is 2047, that 11 bits, square that + multiply that with the y, then you get a 33 bit result.  If I make the While/If condition compare 2x 33 bit numbers instead of the current 24 bits, our FMAX drops back down to 84MHz.

I will need to look at other integer Bresenham Ellipse functions to see if I can imagine a shortcut without having to resort to a multistaged pipelined version.

I attached the 100MHz version.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2237 on: December 15, 2020, 11:38:05 am »
     Ok, here we go.  You made a few mistakes like when you had to multiply by 2, you right left shifted by 2.   That's wrong.  A right left shift by 1 is a multiply by 2.  Though you did get the multiply by 4 correct???

Ah, typos.  I do understand that a bit-shift to the left each position is equivalent of multiplying by 2, and to the right is division by 2.  Just shows I shouldn't program when I'm in a rush. ::)

     Step 1, looking at the code, how do you think we will attack the low FMAX and get it above 125MHz?

My lack of knowledge and skill with HDL means I'm a bit of a blunt instrument when it comes to this sort of thing, so my first (and only) tactic to increase the FMax would be to break the calculations down into more, smaller steps.

Ok, Nockieboy, I've attached an update.  It seems to function identical to the first code, but, it now compiles with an FMAX of 100MHz.  Double check my math.

It seems to be running-on for an extra pixel at the end with a 25x25 ellipse, or I'm misreading the results? ???  Take a look at the simulation I've done with a 25x25 ellipse - simulation output doesn't quite match the FreeBasic one - it looks like the ellipse generator needs to stop a pixel earlier?  But otherwise, it's producing the right output.

However, if I run a simulation with a 27x27 ellipse, it seems to work fine?  I must be getting confused with X/Y output in the 25x25 case...?

I foresee problems.  Part of the trick I employed ate up a few more multipliers.  Plus, because of the damn While/If () loop which compares B^2*x with A^2*y, which was originally done/cropped to 24 bits, we may need to do it at 32 bits.  If the width of the ellipse is 2047, that 11 bits, square that + multiply that with the y, then you get a 33 bit result.  If I make the While/If condition compare 2x 33 bit numbers instead of the current 24 bits, our FMAX drops back down to 84MHz.

This is probably me being very short-sighted, but under what conditions would we ever need to worry about an ellipse 2047 pixels wide on a display that can only handle 640x480, or 720p?  If I was writing a flight simulator, I might need to draw the arc of an ellipse much larger than the screen to represent the horizon from high altitude, but there'd be more important things I'd have to worry about with the available memory and number-crunching power than whether the horizon is flat or curved.

I will need to look at other integer Bresenham Ellipse functions to see if I can imagine a shortcut without having to resort to a multistaged pipelined version.

Extra stages in the setup part of the function aren't the greatest of concerns - there'll be a limit to how quickly the Z80 can setup/request ellipses to be drawn and I don't think a few additional 8ns clock cycles in the setup of each request will be a performance-breaker (or even noticeable up to a point), but once the function starts hammering out pixels, I guess that's where we need to be careful.

Have added ellipse_generator.sv as well - same as the version you've posted previously, but have updated the version number to prevent mistakes and formatted the code a little.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2238 on: December 16, 2020, 07:37:30 am »

It seems to be running-on for an extra pixel at the end with a 25x25 ellipse, or I'm misreading the results? ???  Take a look at the simulation I've done with a 25x25 ellipse - simulation output doesn't quite match the FreeBasic one - it looks like the ellipse generator needs to stop a pixel earlier?  But otherwise, it's producing the right output.

However, if I run a simulation with a 27x27 ellipse, it seems to work fine?  I must be getting confused with X/Y output in the 25x25 case...?


Yes, you have found a bug.  There is a problem.  In the original 'Program' code, there is an order of operations.  The 'While (b2*x <= a2*y)' is being computed & checked after Y may have been decremented by 1 (depending on sigma's sign) and after X has been incremented by 1.  However, in Verilog, the problem is that the X&Y inside that while has the previous results even though the next output pixel is being computed.  I thought changing the ' <= ' to a ' < ' fixed the problem, however, apparently not in all cases.

So that's 1 thing to fix.  Looking at the code, the massive condition where:

sigma          <= sigma + (b2 * (( x << 2 ) + 3'd6 )) + ((a2 << 2) * ( 24'd1 - y )) ;
or
sigma          <= sigma + (b2 * (( x << 2 ) + 3'd6 )) ;

It has 2 large parallel multiplies with 3 adds  ''  24bit + (24bit * 14bit) + (26bit * (1-12bit))  '', or the second addition half depending on the sign of the 'sigma'.

Pipelining this is possible, yet complex since that While() also needs to take into account changes in the X&Y and it also has another two 24bit by 12 bit multiplies to also be done in parallel.

Before continuing, I will look at some other ellipse functions to see it they remove some of the cluster of math.   I suspect there is a shortcut for simplifying the 2 multiplies in the While() & perhaps 1 of the multiplies in the 'sigma' adjustment.

The high bitcount multiplies just on their own might need a 2 clock cycle pipe as well as the 3 way parallel add meaning pipelining has become truly troublesome since we need the sign of 'sigma' computed before we decide to subtract from Y or not.  The other method is to always wait to 2 + 2 clock cycles for each sum to come in meaning instead of 125 million pixels a second, this generator will only render 31 million pixels a second.  (Not counting the fill, the fill will still be 125mpps)  Running a fixed 2 clock cycle ALU here may also allow us to consolidate the math into 1 DSP element instead of using 7.
« Last Edit: December 16, 2020, 07:39:22 am by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2239 on: December 16, 2020, 04:56:25 pm »
After a little playing around, the best I could do with the current architecture is 110MHz, with the added bonus of cutting down the 9bit alu elements by 33% & logic elements by 25%.  However, even if it is possible to refine this design to 125MHz, it will create code which may become a bottleneck in the future if you ever need to change 1 little thing.

Time to look at other ellipse generators before committing to a multi-stage pipeline design.
« Last Edit: December 16, 2020, 04:58:20 pm by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2240 on: December 16, 2020, 05:17:48 pm »
Ok, here is 1 older box ellipse code which can be done with only 1 single 12bitx12bit multiply for the multiple squares during the setup, but, when drawing, it only uses add and subtract &the 'While' loop has no math at all, it just compares the magnitude of 2 final 12 bit coordinates (x0 <= x1).  >150MHz shouldn't be a problem:

Already coded here:
https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3287072/#msg3287072

This code behaves much more like the Bresenham's line-generator, except it has 2 error calculations on the x&y step instead of only 1.  Before we commit to this code, I will look through the other ellipse source .pdf I posted awhile back to see it a center-ellipse already exists without any multiplication during the rendering.
« Last Edit: December 16, 2020, 06:00:24 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2241 on: December 16, 2020, 10:38:05 pm »
Ok, here is 1 older box ellipse code which can be done with only 1 single 12bitx12bit multiply for the multiple squares during the setup, but, when drawing, it only uses add and subtract &the 'While' loop has no math at all, it just compares the magnitude of 2 final 12 bit coordinates (x0 <= x1).  >150MHz shouldn't be a problem:

Already coded here:
https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3287072/#msg3287072

This code behaves much more like the Bresenham's line-generator, except it has 2 error calculations on the x&y step instead of only 1.  Before we commit to this code, I will look through the other ellipse source .pdf I posted awhile back to see it a center-ellipse already exists without any multiplication during the rendering.

That sounds promising.  I didn't realise adding the ellipse generator would cause such problems, but it's interesting to see the issues caused by the additional of some simple (on the face of it) arithmetic.

In other news, I've finished one of the HDMI DAC cards - well, apart from the DIL header - I'm just hoping the QFN soldering is good.  I guess I can always remove it and try again if not.

Seems my biggest issue with soldering 0402s is trying not to get too much solder down!
« Last Edit: December 16, 2020, 10:40:03 pm by nockieboy »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2242 on: December 16, 2020, 11:53:47 pm »
That sounds promising.  I didn't realise adding the ellipse generator would cause such problems, but it's interesting to see the issues caused by the additional of some simple (on the face of it) arithmetic.
Arithmetic is not a problem.  Waiting for a result before deciding to add or subtract 2 figures before each iteration means the math needs to achieve the FMAX in a single clock, or if the math takes 2 clocks, you pipe in the numbers and wait for the result to change and decide whether to run the next iteration.

We already have a 2 clock multiply-add-shift 32 bits in our 'pixel coordinates' to 'memory address' generator.  Here it is not a problem since the input doesn't rely on the output results 2 clocks later, so, everything is just fed in a pipe manner.  Thanks to this, that part of the code can operate at ~200MHz instead or 100MHz.  Extending that pipe by another clock or two will get the FMAX up to the core's theoretical maximum frequency listed in the data sheet.

This next ellipse generator sort of computes 2 or the 'sigma' progressively by addition or subtraction waiting for them to approach each other instead of re-multiplying A&B by each sigma each iteration while adding an offset & when testing for the end of the arc.  However, I must test the angle of 1 of the ellipse quadrants in FreeBasic first to make sure it's the edge I want.  Plus, it needs to be simplified to a center axis ellipse.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2243 on: December 16, 2020, 11:55:23 pm »
In other news, I've finished one of the HDMI DAC cards - well, apart from the DIL header - I'm just hoping the QFN soldering is good.  I guess I can always remove it and try again if not.

Seems my biggest issue with soldering 0402s is trying not to get too much solder down!
Looks like you need a little flux-off and a firm bristle brush to clean off the residue and then you are ready to go.
Have you searched for the DVI specification so you may design your first serializer?
I believe it shouldn't be tough, when a sync change comes in, you insert the right code on the 30 bit data bus.  1 pixel before your vid_ena you send the video enable code, then place video data on the 30 bits with an offset.  1 pixel after the vid_ena ends, send the video disable.  (I think as this is how it was done on my SDI encoder, however, in DVI, the vid_ena may be encoded on the upper/lower bits.)  As for the last 10 bits, the pixel clock, it should have a fixed #, something like 10'b1111100000.

Altera's serdes function should do the job with the right configuration.  Make a default 4 channel unit, 40 bits in, 4 channel out in Quartus Prime for the CV and get the example generated SystemVerilog code function call so you may enter it into your DVI serializer module.
« Last Edit: December 17, 2020, 12:06:21 am by BrianHG »
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2839
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2244 on: December 17, 2020, 02:14:43 am »
DVI output works basically like VGA, except your color channel information and sync signals go into HDMI encoders and then into serializers (one of each per channel, all identical for all channels). A page or two back I posted a link to HDMI 1.3a spec pdf download page.

You will need to implement an HDMI encoder, which takes in 8 bits of color information and control signals (hsync/vsync, video enable), and turns them into 10 bit codes generated using specific algorithm described in the specification, and those 10 bit characters will need to be sent over the wire via serializers. During blanking blue channel (channel 0) will send codes for sync signals, other channels will send a pre-defined code for "nothing to see here".

For "native" HDMI mode, all the "magic" happens during blanking, as that's when all other data (audio, video metadata, etc.) is transmitted, but for DVI mode this is not required.

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2245 on: December 17, 2020, 03:27:50 am »
DVI output works basically like VGA, except your color channel information and sync signals go into HDMI encoders and then into serializers (one of each per channel, all identical for all channels). A page or two back I posted a link to HDMI 1.3a spec pdf download page.

You will need to implement an HDMI encoder, which takes in 8 bits of color information and control signals (hsync/vsync, video enable), and turns them into 10 bit codes generated using specific algorithm described in the specification, and those 10 bit characters will need to be sent over the wire via serializers. During blanking blue channel (channel 0) will send codes for sync signals, other channels will send a pre-defined code for "nothing to see here".

For "native" HDMI mode, all the "magic" happens during blanking, as that's when all other data (audio, video metadata, etc.) is transmitted, but for DVI mode this is not required.
First let him start with DVI as it should activate any monitor and it is dirt simple.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2246 on: December 17, 2020, 09:37:21 am »
Ok, take a look at these freebasic code.

Geoarc is the new code modified to generate a center ellipse.
Notice the 3 rendering errors.
A) offset errors as the ellipse becomes flat.
B) vertical ellipse has a top pixel error.
C) 32 bit error when the radius of the are becomes too big.

Carefully notice the rendering of the original geoarc_complex.bas.  Look at the precision coordinate positions of the beginning and ending as the ellipse as the ellipse becomes flat.

The simpler 'box-ellipse' seems to only be good at drawing an ellipse in a box as rendering connecting corner errors don't show as all 4 quadrants touch even if they are off by +/- 1 pixel.  You have no dot-precise measurement to see single pixel alignment errors on the 4 corners of the vertical and horizontal axis if they cleanly merge to produce what looks like a perfect ellipse.

I'll try another designed 'center-ellipse' code which has the add and subtract simplicity of the box-ellipse, yet calculates the ellipse from 2x 45 degree points generating a precise beginning and end.  Remember, we want to use the edges of 1 of the 4 quadrants of the ellipse to connect to boxes and lines drawn with your other geometry commands when you want to draw a rounded corners.

« Last Edit: December 17, 2020, 10:08:08 am by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2247 on: December 17, 2020, 09:44:49 am »
Ok Nockieboy, here is another ellipse generator:

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

Now, I extrapolated the .pdf code here (removed some stuff and simplified other stuff):
Code: [Select]
void ellipseMidpoint (int xCenter, int yCenter, int Rx, int Ry)

{

int Rx2 = Rx * Rx;
int Ry2 = Ry * Ry;

int twoRx2 = 2 * Rx2;
int twoRy2 = 2 * Ry2;

int p;
int x = 0;
int y = Ry;
int px = 0;
int py = twoRx2 * y;

/* Region 1 */

p = ( (Ry2 - (Rx2 * Ry) + (0.25 * Rx2)) ) + 0.5;

while (px < py) {

  x++;
  px += twoRy2;

    if (p < 0) {
               p += Ry2 + px;
               }
    else {
               y--;
               py -= twoRx2;
               p += Ry2 + px - py;
         }

  PlotPoints (xCenter+x, yCenter+y, 0,255,0);
  }

/* Region 2 */

p = ( (Ry2 * (x+0.5) * (x+0.5) + Rx2 * (y-1) * (y-1) - Rx2 * Ry2) ) + 0.5 ;

while (y > 0) {

  y--;
  py -= twoRx2;

    if (p > 0) {
               p += Rx2 - py;
               }
    else {
               x++;
               px += twoRy2;
               p += Rx2 - py + px;
         }

  PlotPoints (xCenter+x, yCenter+y, 255,0,0);
  }
}

This should render 1 quadrant of the ellipse, however, I do not like how the author has manipulated the structure of 'Region 2' which isn't a mirror match of 'Region 1'  Please convert to freebasic code & I have a feeling like with our current 'Geoarc_complex.bas', we will end up using just 'Region 1' twice flipping the X&Y coordinates and X&Y radius.  As you can see, this code has no complex iterations during the render or test to see if the 'Region' of the arc has completed.  (The 2 region differences may be used to complete the lines in a flat ellipse, but I prefer to do it externally.)

Send me a working Freebasic version for testing...
(Region 1&2 are your old 'Inv' function - green / red lines of the complex geoarc function...)
« Last Edit: December 17, 2020, 10:18:30 am by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2248 on: December 17, 2020, 04:53:47 pm »
Ok Nockieboy, here is another ellipse generator:

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

Now, I extrapolated the .pdf code here (removed some stuff and simplified other stuff):
Code: [Select]
void ellipseMidpoint (int xCenter, int yCenter, int Rx, int Ry)

{

int Rx2 = Rx * Rx;
int Ry2 = Ry * Ry;

int twoRx2 = 2 * Rx2;
int twoRy2 = 2 * Ry2;

int p;
int x = 0;
int y = Ry;
int px = 0;
int py = twoRx2 * y;

/* Region 1 */

p = ( (Ry2 - (Rx2 * Ry) + (0.25 * Rx2)) ) + 0.5;

while (px < py) {

  x++;
  px += twoRy2;

    if (p < 0) {
               p += Ry2 + px;
               }
    else {
               y--;
               py -= twoRx2;
               p += Ry2 + px - py;
         }

  PlotPoints (xCenter+x, yCenter+y, 0,255,0);
  }

/* Region 2 */

p = ( (Ry2 * (x+0.5) * (x+0.5) + Rx2 * (y-1) * (y-1) - Rx2 * Ry2) ) + 0.5 ;

while (y > 0) {

  y--;
  py -= twoRx2;

    if (p > 0) {
               p += Rx2 - py;
               }
    else {
               x++;
               px += twoRy2;
               p += Rx2 - py + px;
         }

  PlotPoints (xCenter+x, yCenter+y, 255,0,0);
  }
}

This should render 1 quadrant of the ellipse, however, I do not like how the author has manipulated the structure of 'Region 2' which isn't a mirror match of 'Region 1'  Please convert to freebasic code & I have a feeling like with our current 'Geoarc_complex.bas', we will end up using just 'Region 1' twice flipping the X&Y coordinates and X&Y radius.  As you can see, this code has no complex iterations during the render or test to see if the 'Region' of the arc has completed.  (The 2 region differences may be used to complete the lines in a flat ellipse, but I prefer to do it externally.)

Send me a working Freebasic version for testing...
(Region 1&2 are your old 'Inv' function - green / red lines of the complex geoarc function...)

Working FreeBasic version of code attached.  I can't split the Region 1 and Region 2 sections as Region 2 is depending on some value set by processing Region 1 - could be x,y, px, py or something else - but I have a working example of the above code.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #2249 on: December 17, 2020, 08:56:54 pm »
Did you not take a look at my above attached code (2 posts up) with the 2 versions and 3 errors and work from there???
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf