FPGA VGA Controller for 8-bit computer

[BrianHG]

Looking good.
Don't forget to move the screen base address away from 0 so that you have room for the Z80 to store fonts.
See line 749 in _top.

Code: [Select]

   .DISP_mem_addr       ( 32'h00000000          ),    // Beginning memory address of bitmap graphic pixel position 0x0.
Don't worry about the FMAX.  My DDR3 V1.5 multiport is now working.  That CLK[4] 71MHz is no longer a problem even with 16 or even more read/write ports.

[nockieboy]

No worries - have moved the base address back to 1200H where it was before for the moment whilst I'm working on the display driver.  Had to do some workarounds for the previous screen modes that I'm having to backtrack on now - like I was using the same colour for foreground and background previously, whereas I can now use completely separate values for the pen and paper.

Here's a screenshot of progress so far, with a mid-grey background to show the display area of the screen.  I haven't quite got the settings right - since changing the base address, I'm now getting the extra bit of text appearing down the right hand side of the screen.

Also getting individual black pixels against the background that I've noticed and highlighted in the attached image.  Not sure what their source is, to be honest.

[BrianHG]

That extra bit of text on the right is there because the display area is 720x480 and you have my display address generator set to 640x480.  Change all the 640s to 720, as well make the changes in your Z80 code as well to recognize a 720 pixel wide screen and everything will look good.

As for the pixel dots, maybe try this.  In 'geo_pixel_writer.sv' line 173, change it from:

Code: [Select]

    ram_addr_C[19:0] = pixel_cmd_data[19:0] ; // select the R/W address.
to

Code: [Select]

    ram_addr_C[19:0]   = wr_ena_ladr ? wc_addr[19:0] : pixel_cmd_data[19:0] ; // select the R/W address.

[nockieboy]

 

For some reason I can't fix this Y_INC offset problem since changing to 720x480.  At least I assume it's Y_INC that's the problem, but I've sought out every mention of 640 pixels wide (and 639, where if it cropped up), and replaced them with 720s as appropriate, but I'm getting this on the screen:



Any ideas what I'm missing?

[nockieboy]

That extra bit of text on the right is there because the display area is 720x480 and you have my display address generator set to 640x480.  Change all the 640s to 720, as well make the changes in your Z80 code as well to recognize a 720 pixel wide screen and everything will look good.

As for the pixel dots, maybe try this.  In 'geo_pixel_writer.sv' line 173, change it from:

Code: [Select]

    ram_addr_C[19:0] = pixel_cmd_data[19:0] ; // select the R/W address.
to

Code: [Select]

    ram_addr_C[19:0]   = wr_ena_ladr ? wc_addr[19:0] : pixel_cmd_data[19:0] ; // select the R/W address.

That's got rid of the 'dead' pixels.

[BrianHG]

For some reason I can't fix this Y_INC offset problem since changing to 720x480.  At least I assume it's Y_INC that's the problem, but I've sought out every mention of 640 pixels wide (and 639, where if it cropped up), and replaced them with 720s as appropriate, but I'm getting this on the screen:

Any ideas what I'm missing?

Remember, there are no MAGGIE controls anywhere.  The screen is hard wired.
Please show me the settings you used for my 'BrianHG_display_rmem'.

The one and only thing you should have done is change both:

Code: [Select]

   .DISP_bitmap_width   ( 16'd640               ),    // The bitmap width of the graphic in memory.
   .DISP_xsize          ( 14'd640               ),    // The video output X resolution.

To 720.

In your code, the  (see: GEO_tb_Blitter.txt in the geometry test bench)
@SET_PAGET  dest 00a000 640 8
should change to:
@SET_PAGET  dest 00a000 720 8

(assuming you want 00a000  as your display base address)

(See: GEO_tb_command_results.txt  in the geometry test bench after running a 'setup_ModelSim.do' then a 'test_blitter.do')
From

Code: [Select]

Line#  98, SET_PAGET Dest addr(h00a000) width(  640) depth( 8)
           TX CMD > $e00a  =  (224) - ( 10) = (11100000 00001010).
           TX CMD > $a000  =  (160) - (  0) = (10100000 00000000).
           TX CMD > $f000  =  (240) - (  0) = (11110000 00000000).
           TX CMD > $b280  =  (178) - (128) = (10110010 10000000).
           TX CMD > $7e07  =  (126) - (  7) = (01111110 00000111).
           TX CMD > $7107  =  (113) - (  7) = (01110001 00000111).
to:

Code: [Select]

Line#  98, SET_PAGET Dest addr(h00a000) width(  720) depth( 8)
           TX CMD > $e00a  =  (224) - ( 10) = (11100000 00001010).
           TX CMD > $a000  =  (160) - (  0) = (10100000 00000000).
           TX CMD > $f000  =  (240) - (  0) = (11110000 00000000).
           TX CMD > $b2d0  =  (178) - (208) = (10110010 11010000).
           TX CMD > $7e07  =  (126) - (  7) = (01111110 00000111).
           TX CMD > $7107  =  (113) - (  7) = (01110001 00000111).


Also don't forget to change:
@SET_MAX_XY  640 480             Sets the pixel writer coordinate XY limits.
to
@SET_MAX_XY  720 480             Sets the pixel writer coordinate XY limits.

[nockieboy]

For some reason I can't fix this Y_INC offset problem since changing to 720x480.  At least I assume it's Y_INC that's the problem, but I've sought out every mention of 640 pixels wide (and 639, where if it cropped up), and replaced them with 720s as appropriate, but I'm getting this on the screen:

Any ideas what I'm missing?

Remember, there are no MAGGIE controls anywhere.  The screen is hard wired.
Please show me the settings you used for my 'BrianHG_display_rmem'.

The one and only thing you should have done is change both:

Code: [Select]

   .DISP_bitmap_width   ( 16'd640               ),    // The bitmap width of the graphic in memory.
   .DISP_xsize          ( 14'd640               ),    // The video output X resolution.

To 720.

Aha! That was it.   I knew it was something silly I'd missed - I had made all the changes in the Z80 code, but had forgotten about it all being hardwired in HDL and having to change the settings in BrianHG_display_rmem.

720x480x8 working nicely (so far - I still have to clean up the scrolling as it's leaving artefacts when the screen scrolls upwards, but that's nothing to do with the HDL).

[BrianHG]

Don't worry about color.  Just do the basic draw text without transparency and make a palette where you can see the text.
We are changing the pixel writer and address generator and all other regs to support 16bit signed X&Y coordinates plus 32bit addressing for full 4gb access and displays up to 32k x 32k pixels.  Except for reading and copying and tile memory source bitmaps, we will probably be dropping support for anything other than 8bit, 16bit, 32bit displays.  This means you will be able to show and blit/copy 1/2/4/8/16/24/32 bit images, but the target color modes will only be 8/16/32 bit color.  Only the tile memory or direct showing of buffers & tiles will support the 1..32 bit, but pixel/geometric drawing destination color depths with/without blits will be limited to 8/16/32 bit.  This will multiply the draw speed in the DDR3 since we will not need to support reading the existing byte of ram, then modifying the selected bits, then writing the result color as DDR3 writes can only mask out 8 bits at a time, not individual bits.

[BrianHG]

You should be able to now to 1080p text and graphics.

[nockieboy]

Don't worry about color.  Just do the basic draw text without transparency and make a palette where you can see the text.

Oh I was just playing with the different shades of grey and being able to display multiple 'colours' on the screen at one time.

Your comment re: transparency concerns me though.  I'm running the blitter in mode 3 at the moment to display text in the DMI and CP/M.  Mode 1 (CP & PM off) just displays filled rectangles for each character in the foreground colour:



(Above shows me changing the blitter to mode 1 and the subsequent result).

We are changing the pixel writer and address generator and all other regs to support 16bit signed X&Y coordinates plus 32bit addressing for full 4gb access and displays up to 32k x 32k pixels.  Except for reading and copying and tile memory source bitmaps, we will probably be dropping support for anything other than 8bit, 16bit, 32bit displays.  This means you will be able to show and blit/copy 1/2/4/8/16/24/32 bit images, but the target color modes will only be 8/16/32 bit color.  Only the tile memory or direct showing of buffers & tiles will support the 1..32 bit, but pixel/geometric drawing destination color depths with/without blits will be limited to 8/16/32 bit.  This will multiply the draw speed in the DDR3 since we will not need to support reading the existing byte of ram, then modifying the selected bits, then writing the result color as DDR3 writes can only mask out 8 bits at a time, not individual bits.

No that's fine - can't see any reason to support <8 bpp to be honest.

[BrianHG]

Once everything is confirmed good with the HDL, upload the project so I may convert it over to my DDR3 V1.5.

This will fix FMAX and add a port for the new system REGS and allow you access to write the palette memory as well.

Once working, we will need to make the new MAGGIE with it's new smart regs so you may get back multiple layers.

Then upgrade the pixel writer and geometry unit for all 16&32 bit regs as well.
No more stuffing bytes into compact partial 8 bit arrays to save space as the new arrays will be stored, copied to and from the DDR3 and memory address space has grown from a few 10kb to megabytes.

[nockieboy]

You should be able to now to 1080p text and graphics.

Right, just so I don't waste too much time scratching my head and making mistakes, what do I need to change to switch to full 1080p?  This is going to involve changes to clock speeds in the video generator etc., or just the three parameters in BHG_display_rmem?

[BrianHG]

Ok, on 'BrianHG_display_rmem' lint 737 _top. (change DDR3 read memory display size)

Code: [Select]

   .DISP_bitmap_width   ( 16'd1920               ),    // The bitmap width of the graphic in memory.
   .DISP_xsize          ( 14'd1920               ),    // The video output X resolution.
   .DISP_ysize          ( 14'd1080               ),    // The video output Y resolution.

Next, vpg_source/pll/pll.sv lines 107-109 (Change PLL to output 148.5MHz)

Code: [Select]

altpll_component.clk0_divide_by = 100, // Make this 200 for 74.25MHz.
altpll_component.clk0_duty_cycle = 50,
altpll_component.clk0_multiply_by = 297,

Next, sync generator settings vpg_source/BHG_vpg.v:
disable lines 164-166
enable lines  179-181

don't forget to '@SET_PAGET  dest 00a000 1920 8'

[BrianHG]

  Your current GEOMETRY address output is only 20 bits long.  Sorry.  You can do 720p's 1280x720 which is 921600 bytes for 8 bit color, but not 1080p which requires 1 more address line because it is 2073600 bytes which requires 21 address lines.  At least once we upgraded this to 32bits, we will never speak of it again.  (Now, never come back to me and say you want a Z80 to access a video card with more than 4 gigabytes of ram on it.  Your life is on the line here.)  Remember, we designed this to work on a 6k gate FPGA.  Every logic cell counted.

Ok, you need to run the PLL at 74.25MHz and add a new mode in the vpg_source/BHG_vpg.v.

I mentioned the math here: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3758837/#msg3758837

[nockieboy]

Not sure what's going on here - made the changes you mentioned above, just getting this on-screen now:



Can read/write RAM fine, but can't seem to clear what's on the screen.  Can't see any screen changes from anything being written to RAM - haven't noticed any major issues with timing in the build report either, other than this in the setup summary:

[nockieboy]

Sorry, just seen this post - must have missed it when I posted my last.

Your current GEOMETRY address output is only 20 bits long.  Sorry.  You can do 720p's 1280x720 which is 921600 bytes for 8 bit color, but not 1080p which requires 1 more address line because it is 2073600 bytes which requires 21 address lines.  At least once we upgraded this to 32bits, we will never speak of it again.  (Now, never come back to me and say you want a Z80 to access a video card with more than 4 gigabytes of ram on it.  Your life is on the line here.)  Remember, we designed this to work on a 6k gate FPGA.  Every logic cell counted.

You know, I was more than happy with 640x480 originally.

Ok, you need to run the PLL at 74.25MHz and add a new mode in the vpg_source/BHG_vpg.v.

I mentioned the math here: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3758837/#msg3758837

 

[BrianHG]

OK, I think this is it:

vpg_source/BHG_vpg.v: (we are getting rid of this garbage DECA code.)

Code: [Select]

//1280x720@60, 74.25MHZ (720p)
assign {h_total, h_sync, h_start, h_end} = {12'd1649, 12'd39, 12'd259, 12'd1539};
assign {v_total, v_sync, v_start, v_end} = {12'd749, 12'd4, 12'd24, 12'd696};
assign {v_active_14, v_active_24, v_active_34} = {12'd226, 12'd418, 12'd610};

pll.v:

Code: [Select]

altpll_component.clk0_divide_by = 200, // 100=148.5MHz.
altpll_component.clk0_duty_cycle = 50,
altpll_component.clk0_multiply_by = 297,

BHG_display_rmem:

Code: [Select]

   .DISP_bitmap_width   ( 16'd1280              ),    // The bitmap width of the graphic in memory.
   .DISP_xsize          ( 14'd1280              ),    // The video output X resolution.
   .DISP_ysize          ( 14'd720               ),    // The video output Y resolution.

I've tested it on my end and I get a picture with display buffer underun problems.  It's that even odd 'Y' buffer line selection which will become obsolete soon.

Just stick with 480p until we upgrade the output.

Damn 9 minute compile time...

[nockieboy]

OK, I think this is it:

vpg_source/BHG_vpg.v: (we are getting rid of this garbage DECA code.)

Code: [Select]

//1280x720@60, 74.25MHZ (720p)
assign {h_total, h_sync, h_start, h_end} = {12'd1649, 12'd39, 12'd259, 12'd1539};
assign {v_total, v_sync, v_start, v_end} = {12'd749, 12'd4, 12'd24, 12'd696};
assign {v_active_14, v_active_24, v_active_34} = {12'd226, 12'd418, 12'd610};

pll.v:

Code: [Select]

altpll_component.clk0_divide_by = 200, // 100=148.5MHz.
altpll_component.clk0_duty_cycle = 50,
altpll_component.clk0_multiply_by = 297,

BHG_display_rmem:

Code: [Select]

   .DISP_bitmap_width   ( 16'd1280              ),    // The bitmap width of the graphic in memory.
   .DISP_xsize          ( 14'd1280              ),    // The video output X resolution.
   .DISP_ysize          ( 14'd720               ),    // The video output Y resolution.


Saw this post as I was compiling changes my end - pleased to say I'd done everything right apart from a few minor discrepancies in the BHG_vpg.v timings - this is what I arrived at:

Code: [Select]

//1280x720@60 74.250MHZ (720p)
assign {h_total, h_sync, h_start, h_end}       = {12'd1649, 12'd39,  12'd257, 12'd1537} ;
assign {v_total, v_sync, v_start, v_end}       = {12'd749,  12'd4,   12'd23,  12'd743}  ;
assign {v_active_14, v_active_24, v_active_34} = {12'd203,  12'd383, 12'd563}           ;
Got a 720p signal on the TV with those settings, but I'll switch to yours as I'm sure they're more accurate.

Damn 9 minute compile time...

Oh jeez, really?   Here I was complaining to myself that the compile time had jumped from just shy of 2 minutes to 2m12.

I got recognisable output my end, probably would have been a lot better if I sorted out the Z80 driver code to set the blitter up properly, but if you think we should stay with 480p for the moment, that's what I'll do.

[BrianHG]

Once everything is good, upload the full project.

I'll do a test switchover to my V1.5 controller tonight.

Basically the same except each CMD_xxx is a read/write port combined instead of a separate read channel and write channel.

Basically a CMD_ena[] with a CMD_write_ena[], read vector[] / write data[] / mask[] inputs, read data[] / vector out[].  All parameters and basic functionality remain the same.

[nockieboy]

Once everything is good, upload the full project.

I'll do a test switchover to my V1.5 controller tonight.

Marvellous - thank you.

All is good - latest version of the project attached.

[nockieboy]

... apart from the issue I raised in this post: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3781079/#msg3781079

Haven't gotten to the bottom of that one yet.

[BrianHG]

Demo for V1.5 of my BrianHG_DDR3_Controller here: https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3785711/#msg3785711

And on my Github page here: https://github.com/BrianHGinc/BrianHG-DDR3-Controller

[nockieboy]

... apart from the issue I raised in this post: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3781079/#msg3781079

Haven't gotten to the bottom of that one yet.

This is causing me issues now.  I'm running the DMI and CP/M with the blitter text in mode 3 (PM and CP on).  If I change the background colour, there's no change until I clear the screen with GEOFF.  The issue being that the text is getting blitted with no background colour at all.  If I turn off PM on the blitter, I'm just getting foreground-coloured squares when I type anything.

Is there any way I can specify which background colour and which foreground colour to blit the source image as?  I need to be able to colour the background behind the text - blitting the text with a custom background colour seems to be the easiest way to do it, otherwise I'll have to calculate X/Y positions for the character being blitted and get GEOFF to draw a rectangle in the background colour first, then the character in the foreground colour over it.

[BrianHG]

Remember, the font is a 1 bit color image.  With transparency on, you can make the 0 or the 1 value transparent by changing the transparent color from 0 to 1 which inverts the transparent color.

Then, when painting, you can choose what color, the '1' opaque color gets painted and XORED with on the screen when transparency is enabled.  Disabling the transparency means that both 0 and 1 are being painted together and the XOR paint color means all you can do is paste 2 adjacent colors in the palette instead of 2 hard selected colors when doing 2 x paste, with transparency on each time at the same coordinates and flipping which part of the font appears to be a '1' and a '0'.

[nockieboy]

Remember, the font is a 1 bit color image.  With transparency on, you can make the 0 or the 1 value transparent by changing the transparent color from 0 to 1 which inverts the transparent color.

Then, when painting, you can choose what color, the '1' opaque color gets painted and XORED with on the screen when transparency is enabled.  Disabling the transparency means that both 0 and 1 are being painted together and the XOR paint color means all you can do is paste 2 adjacent colors in the palette instead of 2 hard selected colors when doing 2 x paste, with transparency on each time at the same coordinates and flipping which part of the font appears to be a '1' and a '0'.

Okay, so this is going to require palette modifications for whatever purpose the software needs.  I'll leave this until we've done the upgrades required to allow palette writing.

In other news, the new interface card works nicely.  Can't say there's any improvement in WAIT release times, but at least now I can measure it!  See image below:



In the SignalTap trace above, you're looking at a memory read op that has missed the cache and the Z80 bridge has signalled a WAIT to the Z80 to hang on while the data is retrieved from DDR3 memory.

• The trigger line shows when the bridge signals to the LVC06 to pull the Z80's WAIT line low.
• One CMD_CLK tick later, WAIT is low (see Z80_WAIT_INn).
• 11 ticks after the trigger (start of orange area), the bridge has its data to return to the Z80 and signals to the LVC06 to release the WAIT line and let the Z80 read the data bus.
• It takes 28 ticks for the line to show HIGH (end of orange area).