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

0 Members and 3 Guests are viewing this topic.

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2275 on: December 22, 2020, 06:50:31 pm »
Ok, I accidentally flipped around a few things.  Unfortunately, the FMAX is now 125.98MHz.
But it is still functional...
Test...
 
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 #2276 on: December 22, 2020, 07:46:37 pm »
That's looking good with testing so far.  :-+
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2277 on: December 23, 2020, 07:34:26 am »
Ok, you apparently never checked the 'quadrants'.  When mirrored or flipped, not both, the coordinate I was subtracting from the center coords was the wrong one as the X&Y coordinates supposed to be swapped when switching the 'INV' mode.

I already integrated the ellipse_generator into the main geometry unit, however, because of the way the geometry unit skips and begins on a new Y position after the half-way point, I could not use our existing in-built raster filler.  It requires that the Y axis continuously adds or subtracts to function.

I've attached the new ellipse_generator with an embedded semi-smart X axis raster fill.  And to make Nockieboy happy, I sort of used his old trick way back to automatically 'pause' the line_generator every time it changed a Y coordinate while drawing when I requested the feature for the filled triangles.

See and test the attached simulation.
( Sadly, the ellipse generator takes ~1k logic elements. )
« Last Edit: December 23, 2020, 07:36:50 am by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2278 on: December 23, 2020, 08:16:04 am »
Ok, here is the full ellipse generator fully integrated into the full geometry processor unit.  Yes, everything is there in the test-bench.  The pixel-writer currently disabled for ease of viewing when testing.

The ellipse uses X0 & Y0 to define it's center.
And it uses X1 & Y1 to define it's X & Y radius.

cmd_h 0x06 draws an ellipse with color cmd_l.
(Unless the blitter is turned on where it will paint the source raster image along plotted coordinates.)
cmd_h 0x0E draws a filled ellipse with color cmd_l.

cmd_h 0x07 will set the quadrant with cmd_l.

How to draw a complete ellipse:
Issue cmd_h=0x07 with cmd_l=00.     (set quadrant 0)
Issue cmd_h=0x06 with cmd_l=color.
Issue cmd_h=0x07 with cmd_l=01.     (set quadrant 1)
Issue cmd_h=0x06 with cmd_l=color.
Issue cmd_h=0x07 with cmd_l=02.     (set quadrant 2)
Issue cmd_h=0x06 with cmd_l=color.
Issue cmd_h=0x07 with cmd_l=03.     (set quadrant 3)
Issue cmd_h=0x06 with cmd_l=color.

For a filled ellipse, change the cmd_h=0x06 to 0x0E.

Let me know if everything looks ok.
Remember, this test bench has everything in hexadecimal.
And, if you are looking at the address generator pixel write commands, is drawn pixels are outside bounds, they will not generate a 'draw_cmd_rdy'.
 
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 #2279 on: December 23, 2020, 01:09:30 pm »
Ok, you apparently never checked the 'quadrants'.  When mirrored or flipped, not both, the coordinate I was subtracting from the center coords was the wrong one as the X&Y coordinates supposed to be swapped when switching the 'INV' mode.

Ah, no - I can't see the quadrants in geoarc, so I hadn't tested them.  This is why I'm not a beta- or product- tester.  :-[

I've attached the new ellipse_generator with an embedded semi-smart X axis raster fill.  And to make Nockieboy happy, I sort of used his old trick way back to automatically 'pause' the line_generator every time it changed a Y coordinate while drawing when I requested the feature for the filled triangles.

 ^-^ ^-^ ^-^ ^-^ ^-^

See and test the attached simulation.
( Sadly, the ellipse generator takes ~1k logic elements. )

Hmm.. well, I thought I'd just see how it looks in terms of resource usage after compiling for the EP4CE10 in Quartus Prime and, surprise surprise, it doesn't fit - it's over by around 1500 LEs and 130 LABs (very approximate ballpark figures as I wasn't taking notes).

Ok, here is the full ellipse generator fully integrated into the full geometry processor unit.  Yes, everything is there in the test-bench.  The pixel-writer currently disabled for ease of viewing when testing.

The ellipse uses X0 & Y0 to define it's center.
And it uses X1 & Y1 to define it's X & Y radius.

cmd_h 0x06 draws an ellipse with color cmd_l.
(Unless the blitter is turned on where it will paint the source raster image along plotted coordinates.)
cmd_h 0x0E draws a filled ellipse with color cmd_l.

cmd_h 0x07 will set the quadrant with cmd_l.

How to draw a complete ellipse:
Issue cmd_h=0x07 with cmd_l=00.     (set quadrant 0)
Issue cmd_h=0x06 with cmd_l=color.
Issue cmd_h=0x07 with cmd_l=01.     (set quadrant 1)
Issue cmd_h=0x06 with cmd_l=color.
Issue cmd_h=0x07 with cmd_l=02.     (set quadrant 2)
Issue cmd_h=0x06 with cmd_l=color.
Issue cmd_h=0x07 with cmd_l=03.     (set quadrant 3)
Issue cmd_h=0x06 with cmd_l=color.

For a filled ellipse, change the cmd_h=0x06 to 0x0E.

Let me know if everything looks ok.
Remember, this test bench has everything in hexadecimal.
And, if you are looking at the address generator pixel write commands, is drawn pixels are outside bounds, they will not generate a 'draw_cmd_rdy'.

Wow, thanks.  This is going to take some testing as it'll be purely test bench-based.  I've got some real reasons to get the design done for the CV board as quickly as possible now.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2280 on: December 23, 2020, 05:15:36 pm »
Ok, I put everything into the full GPU_EP4CE10 project.
It has the full geometry unit with the ellipse generator.
I had to lower the MAGGIE layers from 6 to 5 to get the ellipse to fit.

The FMAX only reaches 122MHz, but it should probably still work.

To achieve the 122MHz, I had to make an enhancement to the 'pixel_address_generator', so there may be a
new bug with the geometry processor.  Please test everything.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2281 on: December 23, 2020, 09:06:04 pm »
Oh yeah, I forgot I could reduce the number of Maggies... |O  Not thinking straight - have a lot going on.  Building the project as I write this, but won't be able to test until tomorrow now.

I'm guessing the reduced Fmax is because the FPGA is basically full, restricting the fitter to using whatever pathways are available rather than the quickest or most efficient.

EDIT: Yeah, the fitter is really working hard.  It's at 94% of LEs and took 4m44 to compile.  :o
« Last Edit: December 23, 2020, 09:09:16 pm by nockieboy »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2282 on: December 23, 2020, 11:26:42 pm »
Just had 5 minutes before I hit the sack to add ellipses to my Z80 test program.  It just draws ellipses based on random xc, yc and x/y radii so the vast majority of ellipses extend outside the visible screen area (I'll have more time tomorrow to set up a better test - concentric circles/ellipses in steadily-reducing radii) but from I can see so far, the ellipse engine is working beautifully.  ;D :-+
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2283 on: December 24, 2020, 06:25:28 am »
Remember, if your ellipses are centered, on a 320x200 screen, a radius of 160x100 would fill the screen.  The ellipses should look a lot better at 640x400.

Ok, I've attached all the updated consolidated test-benches and the complete GPU_EP4CE10 project.

The GPU_EP4CE10 now has an FMAX of 127MHz.  >:D
Let's see some videos of the speed of the ellipse routine.
(LOL, many are probably completely drawn before the 8 MHz Z80 even gets to execute the next opcode as it runs even ~4x slower than that.)

Next, maybe I can look at your HDMI stuff.
« Last Edit: December 24, 2020, 06:27:25 am by BrianHG »
 
The following users thanked this post: nockieboy

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2284 on: December 24, 2020, 09:08:00 am »
(This is a joke...)
@Nockieboy, can you do a comparison speed test of having the Z80 manually software render the ellipses VS using the geometry unit.  I wonder how the Z80 would handle all the 32bit integers needed for each iteration, then actually writing pixels through ram.  Yes, don't even think about using the built in geometry pixel write command.

What do you think the speed difference would be?
100000:1 is my bet for outline ellipses.
20000:1 for large filled ones.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2285 on: December 24, 2020, 12:06:12 pm »
(This is a joke...)
@Nockieboy, can you do a comparison speed test of having the Z80 manually software render the ellipses VS using the geometry unit.  I wonder how the Z80 would handle all the 32bit integers needed for each iteration, then actually writing pixels through ram.  Yes, don't even think about using the built in geometry pixel write command.

What do you think the speed difference would be?
100000:1 is my bet for outline ellipses.
20000:1 for large filled ones.

Yeah I'd thought of this myself a little while ago, but I need to edit my copies of MBASIC or BBCBASIC to insert the necessary graphics routines to get graphical output.  I don't have the time to do that at the moment (but it's on my to-do list).  I know the Z80 doesn't exactly have a high IPC :-DD, but this one isn't hamstrung like the 80's ones by only being able to access memory when the raster is in the non-display areas of the screen, plus it's running at twice the speed of a typical 80's Z80.  I think you're right though - it'd be four or five orders of magnitude slower than the GPU. 

I've attached three images showing the ellipse output at the three screen resolutions the EP4CE10 can muster.  If I get some time later, I'll see about drawing the quadrants in different colours, but it all looks good. ;D :-+
 
The following users thanked this post: BrianHG

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2286 on: December 24, 2020, 03:07:04 pm »
No video of randomly painted sized filled ellipses with different colored outline running all over the screen?

At least the ellipses are perfectly formed creating that nice moiré pattern.  It was worth going through the hassle of finding the right routine.

Once you have the CV working with DDR3, this GPU/Sound/Ram/SDcard board would be well suited to a CPU of caliber like 68020/68030 up to 50MHz.  If you ever get the time to make your geometry unit to execute self-compiled/interpreted geometric 2D/3D structures, it should be good for 68040/68060 @ 100-200MHz.
« Last Edit: December 24, 2020, 03:09:58 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2287 on: December 24, 2020, 04:22:35 pm »
Here's a couple of videos for you - the random circle fill isn't running at full speed as I have a keypress check each loop, but we know it's going to be pretty quick and tearing the screen up if I ran it at full speed.  ;)

https://youtu.be/kX6uaDxLaB8
https://youtu.be/jYf3ThImGpQ

If I don't appear on here again today, have a healthy and happy Christmas everyone. May Santa's sack be full of whatever is on your wishlist.  :)
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2288 on: December 25, 2020, 10:01:41 am »
Here's a couple of videos for you - the random circle fill isn't running at full speed as I have a keypress check each loop, but we know it's going to be pretty quick and tearing the screen up if I ran it at full speed.  ;)

https://youtu.be/kX6uaDxLaB8
https://youtu.be/jYf3ThImGpQ

If I don't appear on here again today, have a healthy and happy Christmas everyone. May Santa's sack be full of whatever is on your wishlist.  :)
Merry X-Mas everyone.

I'm assuming the first video is obviously not a palette trick which we would have done in the old days.
As with a 16 color screen, you have more than 16 circles to animate the shade through.
Though, you could have done that trick with a 256 color screen, but I know you don't have the ram.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2289 on: December 25, 2020, 07:08:28 pm »
I'm assuming the first video is obviously not a palette trick which we would have done in the old days.
As with a 16 color screen, you have more than 16 circles to animate the shade through.
Though, you could have done that trick with a 256 color screen, but I know you don't have the ram.

No palette tricks here. :) Each frame the grey circles are redrawn, then the one white circle is drawn.  The grey circles start at a radius of 200 and reduce by 4 every circle - so 49 circles.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2290 on: December 26, 2020, 06:15:08 am »
Just as an aside, I've got the attached project building now, but it appears to be using some sort of megafunction to set up the TMDS outputs and I cannot assign pins in the Pin Planner to get the project to work on my EasyFPGA board with the DVI Tester.  The pins are already assigned and read only when I go to the Pin Planner.

I'm thinking I should just remove the OBUFDS elements entirely from hdmi.sv (lines 319-334) and just connect tmds_current[] to the output pins whilst inverting the _n pin signal, allowing me to assign pins in Pin Manager as usual. Hopefully.  Seems OBUFDS uses the altera_gpio_lite megafunction, but I can't find it in the IP Catalog so I can't seem to find where it's assigning the IO pins to the TMDS signals.

I'm probably going to get a lot of flak for not just doing it from scratch, but I like the promise of being able to output an HDMI signal and include audio in the bit stream - that's a major benefit over straight DVI and is why I'm plugging away at this example project.


Ok,I attached the simulation test bench.

Warning, in file: audio_clock_regeneration_packet.sv
  I had to comment out line 41 and replace it with line 42 since Quartus 9.1 could not handle the " real' " in the formula.  Later versions of Quartus can handle the term properly, so, you should comment back in line 41 and comment out line 42.  The difference is a potential rounding error with huge numbers and dividers.

  I also bypassed the IOBUFF module to make it transparently pass the data through.

  When loading the project into Quartus Prime, you will need to first change the Cyclone to the one on your developer PCB.  You will only output the 'P' pins unless we inverted the N&P polarity in the circuit.  If we did so, only output the 'N' port pin.  Do not output the N&P together.  Right now, I wired only the 'P' channel to all 4 outputs.

  Next, you will need to first do a 'Start - Analysis & Synthesis'.  Then go into the 'Pin Planner' and set the ' I/O Standard ' to LVDS.  You will notice that the TMDS pins have automatically doubled to versions with and extra {n} at the end.  Now, drag the 'non {n}' versions of the pins onto the correct differential 'P' output on the FPGA.  Also set the CLK to the right Input as well.  (You will notice that the pin-planner will automatically position the {n} versions of the output port to the 'n' pair on the LVDS output.)

   Next, go into the assignment editor and copy & paste the assigned TMDS output pins and in the duplicate group, change their assignment name from IO standard to 'Fast Output Registers' and set the value to 'On'.  Save the changes then compile.  (Only the original 'output pin' names need the 'Fast output registers.)

  Note that my last 2 instructions (defining the output as an LVDS differential and Fast Output register) can be properly set and defined in the IOBUF, but that will take reading some documentation on your part and learning everything about specifying the output buffer.

  With your 20MHz scope, you should see a 25.2MHz signal on the TMDS_Clk pin on both FPGA IOs, N&P, of your test circuit, though if will look like a sine wave since your scope is even slower than 25MHz.  If it looks OK, then try plugging in an HDMI monitor.

« Last Edit: December 26, 2020, 07:05:47 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 #2291 on: December 27, 2020, 11:02:12 am »
Warning, in file: audio_clock_regeneration_packet.sv
  I had to comment out line 41 and replace it with line 42 since Quartus 9.1 could not handle the " real' " in the formula.  Later versions of Quartus can handle the term properly, so, you should comment back in line 41 and comment out line 42.  The difference is a potential rounding error with huge numbers and dividers.

  I also bypassed the IOBUFF module to make it transparently pass the data through.

  When loading the project into Quartus Prime, you will need to first change the Cyclone to the one on your developer PCB.  You will only output the 'P' pins unless we inverted the N&P polarity in the circuit.  If we did so, only output the 'N' port pin.  Do not output the N&P together.  Right now, I wired only the 'P' channel to all 4 outputs.

  Next, you will need to first do a 'Start - Analysis & Synthesis'.  Then go into the 'Pin Planner' and set the ' I/O Standard ' to LVDS.  You will notice that the TMDS pins have automatically doubled to versions with and extra {n} at the end.  Now, drag the 'non {n}' versions of the pins onto the correct differential 'P' output on the FPGA.  Also set the CLK to the right Input as well.  (You will notice that the pin-planner will automatically position the {n} versions of the output port to the 'n' pair on the LVDS output.)

   Next, go into the assignment editor and copy & paste the assigned TMDS output pins and in the duplicate group, change their assignment name from IO standard to 'Fast Output Registers' and set the value to 'On'.  Save the changes then compile.  (Only the original 'output pin' names need the 'Fast output registers.)

Okay, I got this far and compiled - but Quartus is throwing errors at me:

Error (169218): I/O standard LVDS on output or bidirectional pin TMDS_CLK_p is not supported by the device at location 49 (PAD_68) -- only input pins of this I/O standard are allowed at this location
   Info (169217): Consider using I/O standard LVDS_E_3R or mini-LVDS_E_3R instead of LVDS for pin at location 49; board resistor(s) will be needed
Error (169218): I/O standard LVDS on output or bidirectional pin TMDS_p[2] is not supported by the device at location 59 (PAD_83) -- only input pins of this I/O standard are allowed at this location
   Info (169217): Consider using I/O standard LVDS_E_3R or mini-LVDS_E_3R instead of LVDS for pin at location 59; board resistor(s) will be needed
Error (169218): I/O standard LVDS on output or bidirectional pin TMDS_p[1] is not supported by the device at location 54 (PAD_74) -- only input pins of this I/O standard are allowed at this location
   Info (169217): Consider using I/O standard LVDS_E_3R or mini-LVDS_E_3R instead of LVDS for pin at location 54; board resistor(s) will be needed
Error (169218): I/O standard LVDS on output or bidirectional pin TMDS_p[0] is not supported by the device at location 52 (PAD_72) -- only input pins of this I/O standard are allowed at this location
   Info (169217): Consider using I/O standard LVDS_E_3R or mini-LVDS_E_3R instead of LVDS for pin at location 52; board resistor(s) will be needed
Error (169218): I/O standard LVDS on output or bidirectional pin TMDS_CLK_p(n) is not supported by the device at location 50 (PAD_69) -- only input pins of this I/O standard are allowed at this location
   Info (169217): Consider using I/O standard LVDS_E_3R or mini-LVDS_E_3R instead of LVDS for pin at location 50; board resistor(s) will be needed
Error (169218): I/O standard LVDS on output or bidirectional pin TMDS_p[2](n) is not supported by the device at location 60 (PAD_84) -- only input pins of this I/O standard are allowed at this location
   Info (169217): Consider using I/O standard LVDS_E_3R or mini-LVDS_E_3R instead of LVDS for pin at location 60; board resistor(s) will be needed
Error (169218): I/O standard LVDS on output or bidirectional pin TMDS_p[1](n) is not supported by the device at location 55 (PAD_75) -- only input pins of this I/O standard are allowed at this location
   Info (169217): Consider using I/O standard LVDS_E_3R or mini-LVDS_E_3R instead of LVDS for pin at location 55; board resistor(s) will be needed
Error (169218): I/O standard LVDS on output or bidirectional pin TMDS_p[0](n) is not supported by the device at location 53 (PAD_73) -- only input pins of this I/O standard are allowed at this location
   Info (169217): Consider using I/O standard LVDS_E_3R or mini-LVDS_E_3R instead of LVDS for pin at location 53; board resistor(s) will be needed
Info (171121): Fitter preparation operations ending: elapsed time is 00:00:01
Warning (171167): Found invalid Fitter assignments. See the Ignored Assignments panel in the Fitter Compilation Report for more information.
Error (171000): Can't fit design in device
Error: Quartus Prime Fitter was unsuccessful. 9 errors, 9 warnings
   Error: Peak virtual memory: 4914 megabytes
   Error: Processing ended: Sun Dec 27 10:53:42 2020
   Error: Elapsed time: 00:00:06
   Error: Total CPU time (on all processors): 00:00:04
Error (293001): Quartus Prime Full Compilation was unsuccessful. 11 errors, 15 warnings


Either I've done something wrong with the assignments editor or we over-estimated the usefulness of the EP4CE6 for what we're trying to do... ???

Assignment Editor and Pin Planner images attached for info.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2292 on: December 27, 2020, 11:37:27 am »
Change the 'IO Standard' to LVDS_E_3R for now.

I need to check the code, but it appears the author is probably not be using Altera's LVDS SERDES function.

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2293 on: December 27, 2020, 12:25:02 pm »
That compiles just fine now. :-+  Uses 20% of the CE6's LEs (1,232).   Will see about testing the eval board later when I have time and post the results.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2294 on: December 28, 2020, 04:38:43 pm »
Ok, since I was getting bored waiting...
I added a new command to the geometry unit.  Hurray...  More things for you to test and demo.

Ok, you will be using cmd_h 0x07 (Shared with the 'Quadrant selection) and cmd_h 0x0F.

When setting cmd_h 0x0F, the register hw_position will be set with the contents of cmd_l.
The default is 0.

When setting cmd_h 0x07, cmd_l can be:
0x00 .. 0x03 => Set ellipse quadrant.
0x8# .. 0x8# => Wait for hw_position*1 to pass by # times/frames.  # = 1 through F/15 allowed.
0x9# .. 0x9# => Wait for hw_position*2 to pass by # times.  # = 1 through F allowed.
0xA# .. 0xA# => Wait for hw_position*4 to pass by # times.  # = 1 through F allowed.
0xB# .. 0xB# => Wait for hw_position*8 to pass by # times.  # = 1 through F allowed.

The hw_position, default being 0 means the vertical wait position is 1 line after the display frame has ended.  This gives you maximum time before the next frame begins to draw.  To request a delay before executing the next command, the # of cmd_l set with cmd_h 0x07 needs to be at least 1 or higher to wait multiple frames.  Having a hw_position of 100 and using the cmd_h 0x07 with cmd_l 0xA# means the pause position will be located 400 line/h-syncs after the end of the display frame.  If you choose a hw_position larger than the number of available lines in a frame, it will just abort trying to wait after 2 frames.  The larger numbers are there for future higher resolution support.

Go back to your smooth vertical text scroll example and before each vertical blitter jump, insert a wait command for 1 frame instead of using the Z80 delay and see if you get a clean vertical scroll without any visible tear.  Also try using wait for 2 or 3 frames to further slow down the vertical scroll.  Let me know if it works.  Since there are 16 steps, you can manipulate each frame count to have the carriage return begin slow, speed up, then decelerate during the 16 steps by a few frames.  The commands should allow additional Z80 processing even though the animation scroll sequence may not be complete by the next key-press/drawn graphics.

(Careful, you can now generate such slow animations that if you are not testing the geometry command FIFO full status, geo_stat_rd[0], before sending commands, you can overfill it...)

I've attached the new GPU_EP4CE10_vwait_inst.zip and test bench Geo_Writer_V10_complete_vwait_inst.zip which contain the wait commands.  The FMAX has 1 route a little too slow, but should still work.  FMAX is becoming difficult to achieve without some added work optimizing the core.
« Last Edit: December 28, 2020, 04:59:06 pm by BrianHG »
 
The following users thanked this post: nockieboy

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2295 on: December 29, 2020, 08:15:33 am »
For a cool smooth accelerating/decelerating looking carriage return below the screen, try these delays.

Code: [Select]
Wait 1 vs.  (Step 1), Blit screen up 1 line and clear bottom line.
Wait 4 vs.  (Step 2), Blit screen up 1 line and clear bottom line.
Wait 3 vs.  (Step 3), Blit screen up 1 line and clear bottom line.
Wait 3 vs.  (Step 4), Blit screen up 1 line and clear bottom line.
Wait 2 vs.  (Step 5), Blit screen up 1 line and clear bottom line.
Wait 2 vs.  (Step 6), Blit screen up 1 line and clear bottom line.
Wait 1 vs.  (Step 7), Blit screen up 1 line and clear bottom line.
Wait 1 vs.  (Step 8), Blit screen up 1 line and clear bottom line.
Wait 1 vs.  (Step 9), Blit screen up 1 line and clear bottom line.
Wait 1 vs.  (Step 10), Blit screen up 1 line and clear bottom line.
Wait 1 vs.  (Step 11), Blit screen up 1 line and clear bottom line.
Wait 2 vs.  (Step 12), Blit screen up 1 line and clear bottom line.
Wait 2 vs.  (Step 13), Blit screen up 1 line and clear bottom line.
Wait 3 vs.  (Step 14), Blit screen up 1 line and clear bottom line.
Wait 3 vs.  (Step 15), Blit screen up 1 line and clear bottom line.
Wait 4 vs.  (Step 16), Blit screen up 1 line and clear bottom line.
Done...
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2296 on: December 29, 2020, 12:03:54 pm »
As soon as I get time, I'll take a look at the smooth scrolling - thanks for that!  :-+

Okay, I had five minutes to dig the silly-scope out to take a look at the dev board's output and have got these traces to show for it - the first is the INC+ output on pin 31 of the header, the second is INX2+ on pin 24.  The scope is obviously working flat-out at its minimum time/div setting.  Looks like some form of coherent output.

Plugged the HDMI in to my monitor - nothing.  Have tried hot-plugging, switching the dev board on/off whilst connected, switching inputs on the monitor, getting no indication of a signal from the DVI tester. 

My first thought is to confirm there's actually a signal getting to the HDMI connector on the DVI tester board - I figure the biggest chance of error is with my soldering of the QFN, but I've used up my spare time today, so debugging will have to wait a little while longer.  :(

EDIT:  Of course, I've just realised I haven't changed VCCIO down to 2.5V yet! :o  :-BROKE
« Last Edit: December 29, 2020, 12:07:42 pm by nockieboy »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2297 on: December 29, 2020, 01:51:56 pm »
Don't worry about the 2.5v.  The QFN amp IC can operate with a  huge range of inputs.  It operates like an analog differential comparitor.  The lower voltage test is for when we use the 'True LVDS' mode on the lower voltage output CV board.

Also check your scope, it might have an X10 magnification for the horizontal scan rate.

Also, if you are using a computer desktop screen like the LG Flatron, make sure you use the HDMI input.  My old LG Flatron doesn't like HDMI feeding it's DVI input.  It doesn't care if you feed DVI into it's HDMI input.  IE, the HDMI input is backwards compatible, but the DVI input isn't forwards compatible.

Also, make sure we didn't swap any of the +&- on the TMDS signals.  Any swapped signals need to be inverted in the Quartus Block Diagram Schematic since we cannot do so in the pin-planner.

Also, the QFN amp might not output a signal without a load.


« Last Edit: December 29, 2020, 01:54:44 pm by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2298 on: December 29, 2020, 02:23:36 pm »
Also, the 'LVDS_E_3R' mode requires the pullup resistors...
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7818
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2299 on: December 29, 2020, 02:47:20 pm »
I looked at your schematic.
Are you sure you arent supposed to invert a signal?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf