FPGA VGA Controller for 8-bit computer

[nockieboy]

Hmm..  I've added two commands to the start of the previous test code - basically just to disable then enable interrupts, but they're both single-byte opcodes so there's no reading values after each opcode.

First opcode read:



Second opcode read:

[BrianHG]

As you can see, the 'WAIT' is still being triggered.
Try a value of 3 for both these 2 unless you made the mistake of changing the value in the Z80_Bus_Interface.sv instead of in GPU.sv line 253/(274 on GEO_on_DDR3.zip) where the parameter has been externally set.  It should not be edited on line Z80_Bus_Interface.sv line 24.

Code: [Select]

  .Z80_DELAY_WAIT_RI     ( 3       ), // 0 to 7, Number of CMD_CLK cycles to wait for DDR3 read_ready before asserting the WAIT during a Read Instruction Opcode cycle.
  .Z80_DELAY_WAIT_RM     ( 3       ), // 0 to 7, Number of CMD_CLK cycles to wait for DDR3 read_ready before asserting the WAIT during a Read Instruction Opcode cycle.

[nockieboy]

Unusually for me, I'm doing it right - I'm not adjusting the parameters in Z80_Bus_Interface.sv, I'm actually adjusting them in gpu.sv as required.

So it appears that changing these values doesn't make any difference.  As you'll see in the Signal Tap trace below, a WAIT is being inserted in the second opcode read still.

Code: [Select]

   .Z80_DELAY_WAIT_RI     ( 3       ), // 0 to 7, Number of CMD_CLK cycles to wait for DDR3 read_ready before asserting the WAIT during a Read Instruction Opcode cycle.
   .Z80_DELAY_WAIT_RM     ( 3       ), // 0 to 7, Number of CMD_CLK cycles to wait for DDR3 read_ready before asserting the WAIT during a Read Memory cycle.
   .Z80_WAIT_QUICK_OFF    ( 1       ), // 0 (Default) = WAIT is turned off only during a low Z80_CLK.  1 = WAIT is turned off as soon as a read_ready is received.


[BrianHG]

It's a bug in the Z80_bus_interface.
I'll fix it tonight.

I don't see any errors.  Are you sure you are editing the correct source code in the correct folder?
Is all your code up to date?

[nockieboy]

Okay, using the latest project you posted on the last page (the one linking the GEO unit into the DDR3), I'm getting a result:

Cache miss opcode read:



Two sequential cache hit opcode reads:



Graphical corruption is a genuine problem with this build, though - whilst text-tile mode works perfectly, the same can't be said of full-graphics mode:

[BrianHG]

Are you sure you placed a copy of the font in DDR3, or are you blitting random uninitialized data which was already there in the DDR3 since powerup?

[nockieboy]

Are you sure you placed a copy of the font in DDR3, or are you blitting random uninitialized data which was already there in the DDR3 since powerup?

   Of course, I forgot to copy the font across to DDR3.  Is there an easier way to do this without resorting to copying the raw data from the MIF in the project and transferring that to a ROM bank, so that I can copy it to DDR3 during startup?  That way is probably preferable, actually, as the font can be edited/changed by the user without messing with the GPU, I guess.

EDIT: Don't worry, I'll just copy the font into ROM, think it's the most flexible solution.

[BrianHG]

Ok, lets see if it works.
In the final GPU, if you want a pre-installed data in the DDR3 after reset, you will need to code it in the HDL to read data from blank flash ram on your DECA board as it has an onboard 64MB QSPI Flash, or you can use the onboard SD-Card slot.  Though, with the onboard SD-Card, you will need to code a filesystem, otherwise it will be nothing more than a rom chip.  You will also want to code a simple RLE encoding scheme for the 64MB flash as 64mb != 512mb, nor do you need to waste all that storage for what will mostly be 0x00.  But now, you could store a 1280x1024 Z80 in 24 bit color instead of that 16 color low res garbage.

[BrianHG]

Are you sure you placed a copy of the font in DDR3, or are you blitting random uninitialized data which was already there in the DDR3 since powerup?

   Of course, I forgot to copy the font across to DDR3.  Is there an easier way to do this without resorting to copying the raw data from the MIF in the project and transferring that to a ROM bank, so that I can copy it to DDR3 during startup?  That way is probably preferable, actually, as the font can be edited/changed by the user without messing with the GPU, I guess.

EDIT: Don't worry, I'll just copy the font into ROM, think it's the most flexible solution.

Rom banks take up ram blocks of identical size.  The rom you are talking about for now needs to be stored in your Z80 OS roms.

[BrianHG]

Recommendation for new video output modes:

Stick with 1 pll clock rate of 74.25MHz which equals official standard 720p, 1280x720@60Hz.

With that 1 PLL clock setting, you can achieve:
1280x720@60Hz.
1920x1080@30Hz.
1920x540@60Hz. (we can also make this 1920x544@60Hz. so that the Y axis divides evenly into 32 for fonts)
1920x480@60Hz. (with black borders, 1280x480 approximate a 4:3 on a 16:9 screen)

[nockieboy]

  Of course, I forgot to copy the font across to DDR3.  Is there an easier way to do this without resorting to copying the raw data from the MIF in the project and transferring that to a ROM bank, so that I can copy it to DDR3 during startup?  That way is probably preferable, actually, as the font can be edited/changed by the user without messing with the GPU, I guess.

EDIT: Don't worry, I'll just copy the font into ROM, think it's the most flexible solution.

Rom banks take up ram blocks of identical size.  The rom you are talking about for now needs to be stored in your Z80 OS roms.

Yes, that's what I meant.  I've got the font sitting in a 16KB ROM bank on my uCOM.  It's working nicely.

[BrianHG]

  Of course, I forgot to copy the font across to DDR3.  Is there an easier way to do this without resorting to copying the raw data from the MIF in the project and transferring that to a ROM bank, so that I can copy it to DDR3 during startup?  That way is probably preferable, actually, as the font can be edited/changed by the user without messing with the GPU, I guess.

EDIT: Don't worry, I'll just copy the font into ROM, think it's the most flexible solution.

Rom banks take up ram blocks of identical size.  The rom you are talking about for now needs to be stored in your Z80 OS roms.

Yes, that's what I meant.  I've got the font sitting in a 16KB ROM bank on my uCOM.  It's working nicely.

So, just to be clear, the geometry unit's pixel writer is working with the DDR3?
You can now move the font to an upper address in the DDR3 and leave all the available FPGA blockram for display, right?

OK, next we need to redo the MAGGIE system completely.
Now we need to change to a 2 clock domain system, the core system clock and the video output clock which runs on a separate PLL.
I also want to multiplex the 'tile' and palette dual port memories' read ports to run at 4x the pixel clock allowing 4 look-ups per pixel allowing 4 dedicated tile layers.  This means with a 74.25MHz pixel clock, we will need to run those memories' read ports at 297MHz.  This is within the DECA's Max10's 300MHz limit however, Lattice ECP5's limit on their fastest unit is 272MHz.  We can operate with a limit of 2 tile layers if you like.  At least this way, 148.5MHz will be slow enough for any FPGA out there.  The second port of those memories will be on the DDR3 & geometry system clock, either 100 or 200MHz.

[nockieboy]

So, just to be clear, the geometry unit's pixel writer is working with the DDR3?

Yes, it's working as it did before anyway - I haven't noticed any artefacts or corruption either, drawing filled circles, triangles etc.

You can now move the font to an upper address in the DDR3 and leave all the available FPGA blockram for display, right?

Well yes, I suppose I can.  Hadn't thought of that.  That'll require some changes to the HDL though, which I guess are next on the agenda, right?

OK, next we need to redo the MAGGIE system completely.
Now we need to change to a 2 clock domain system, the core system clock and the video output clock which runs on a separate PLL.
I also want to multiplex the 'tile' and palette dual port memories' read ports to run at 4x the pixel clock allowing 4 look-ups per pixel allowing 4 dedicated tile layers.  This means with a 74.25MHz pixel clock, we will need to run those memories' read ports at 297MHz.  This is within the DECA's Max10's 300MHz limit however, Lattice ECP5's limit on their fastest unit is 272MHz.  We can operate with a limit of 2 tile layers if you like.  At least this way, 148.5MHz will be slow enough for any FPGA out there.  The second port of those memories will be on the DDR3 & geometry system clock, either 100 or 200MHz.

Is that something that we could adjust easily with a parameter in the project, or is it more involved than that?

[BrianHG]

You can now move the font to an upper address in the DDR3 and leave all the available FPGA blockram for display, right?

Well yes, I suppose I can.  Hadn't thought of that.  That'll require some changes to the HDL though, which I guess are next on the agenda, right?

I don't think so.
Have you tried using the Z80 to read and write to higher sections of memory?
Does the Z80_bus_interface have a parameter to block access?
I know you can set the geometry unit to address to it's max address range even though the Z80 bus may have a limit.
It looks like there will need to be upgrades to access the 512mb as that requires 29 address bits.  Sadly 9 short of the current 20 bits.

OK, next we need to redo the MAGGIE system completely.
Now we need to change to a 2 clock domain system, the core system clock and the video output clock which runs on a separate PLL.
I also want to multiplex the 'tile' and palette dual port memories' read ports to run at 4x the pixel clock allowing 4 look-ups per pixel allowing 4 dedicated tile layers.  This means with a 74.25MHz pixel clock, we will need to run those memories' read ports at 297MHz.  This is within the DECA's Max10's 300MHz limit however, Lattice ECP5's limit on their fastest unit is 272MHz.  We can operate with a limit of 2 tile layers if you like.  At least this way, 148.5MHz will be slow enough for any FPGA out there.  The second port of those memories will be on the DDR3 & geometry system clock, either 100 or 200MHz.

Is that something that we could adjust easily with a parameter in the project, or is it more involved than that?

Nope, maggie needs to be redone.  DDR3 needs to transfer blocks of memory line by line to a bank of dual-port memories to feed the picture output.  Each line, it needs to process an address for each layer and feed DDR3 commands to fill these line buffers.  This is the job of the maggie.  Also, all the registers are too small.  You need 32 bit base ram address and display width settings of 16bit as well as begin and end line positions.  These used to be stored separately for your H&V cursors and maggie address controls.  But now, each maggie layer needs all this info to operate the DDR3 to line mem buffers.  Features and controls will be the same as before, but, everything will land on new addresses with either a 32bit integer, or 16bit integer, or 8 bit integer for the control.  No more funny stacked 8 bit integers with 4 bits for Y scale, and 4 bits Y offset.  Each maggie layer will have 64 bytes of reserved space for it's controls.  This will make your Z80 setting regs a whole lot easier.  Though, 16 layers means 1024bytes of address space.  Also, the tile/font will now be 32bits per character, not 16bit or 8 bit.  You will have 8bit foreground color, 8 bit background color, 2 bit for mirror and flip tile, 14bit for a font with up to 16384 characters.  Now you may include Greek and accent character fonts with math symbols and more complex graphics set.  You will also have tile width and heights of 8,16 and 32.  The only limit will be the 128 kilobytes for tile ram in the DECA and 192 kilobytes for the tile mem in the 16$ Lattice fpga, 384kb in the 34$ Lattice, but access to at least maggie 34 layers.

[nockieboy]

Have you tried using the Z80 to read and write to higher sections of memory?

No, but is there any reason to think it wouldn't work?

Does the Z80_bus_interface have a parameter to block access?

Not as far as I'm aware.

I know you can set the geometry unit to address to it's max address range even though the Z80 bus may have a limit.
It looks like there will need to be upgrades to access the 512mb as that requires 29 address bits.  Sadly 9 short of the current 20 bits.

The Z80 has a hard limit of a 512KB 'window' into the GPU's DDR3 RAM.  As it stands, it can only access the first half megabyte of DDR3 without some form of MMU within the FPGA - probably best controlled via an IO port in Z80_Interface to set which 512KB 'bank' to expose to the Z80.  The Z80 then would use the 32 banks in its 512KB 'window' to access that DDR3 bank.  By setting the GPU's DDR3 bank, the Z80 will be able to access any size of DDR3 memory, albeit in 16KB nibbles of a 512KB chunk at any one time, if that makes sense?

OK, next we need to redo the MAGGIE system completely.
Now we need to change to a 2 clock domain system, the core system clock and the video output clock which runs on a separate PLL.
I also want to multiplex the 'tile' and palette dual port memories' read ports to run at 4x the pixel clock allowing 4 look-ups per pixel allowing 4 dedicated tile layers.  This means with a 74.25MHz pixel clock, we will need to run those memories' read ports at 297MHz.  This is within the DECA's Max10's 300MHz limit however, Lattice ECP5's limit on their fastest unit is 272MHz.  We can operate with a limit of 2 tile layers if you like.  At least this way, 148.5MHz will be slow enough for any FPGA out there.  The second port of those memories will be on the DDR3 & geometry system clock, either 100 or 200MHz.

Is that something that we could adjust easily with a parameter in the project, or is it more involved than that?

Nope, maggie needs to be redone.  DDR3 needs to transfer blocks of memory line by line to a bank of dual-port memories to feed the picture output.  Each line, it needs to process an address for each layer and feed DDR3 commands to fill these line buffers.  This is the job of the maggie.  Also, all the registers are too small.  You need 32 bit base ram address and display width settings of 16bit as well as begin and end line positions.  These used to be stored separately for your H&V cursors and maggie address controls.  But now, each maggie layer needs all this info to operate the DDR3 to line mem buffers.  Features and controls will be the same as before, but, everything will land on new addresses with either a 32bit integer, or 16bit integer, or 8 bit integer for the control.  No more funny stacked 8 bit integers with 4 bits for Y scale, and 4 bits Y offset.  Each maggie layer will have 64 bytes of reserved space for it's controls.  This will make your Z80 setting regs a whole lot easier.  Though, 16 layers means 1024bytes of address space.  Also, the tile/font will now be 32bits per character, not 16bit or 8 bit.  You will have 8bit foreground color, 8 bit background color, 2 bit for mirror and flip tile, 14bit for a front with up to 16384 characters.  Now you may include Greek and accent character fonts with math symbols and more complex graphics set.  You will also have tile width and heights of 8,16 and 32.  The only limit will be the 128 kilobytes for tile ram in the DECA and 192 kilobytes for the tile mem in the 16$ Lattice fpga, 384kb in the 34$ Lattice, but access to at least maggie 34 layers.

I meant once the MAGGIE is redone, would it be possible to set the 'tile and palette dual port memories' clock speed via a parameter to match the target FPGA it's going to be working on?

As for the rest of your reply -  .  Seems some major changes to be done and I'm going to have to go away and read all that at least ten times over to try to understand it all. 

[BrianHG]

I meant once the MAGGIE is redone, would it be possible to set the 'tile and palette dual port memories' clock speed via a parameter to match the target FPGA it's going to be working on?

As for the rest of your reply -  .  Seems some major changes to be done and I'm going to have to go away and read all that at least ten times over to try to understand it all. 

Ok, maybe the better question I should ask is:
Are 2 tile layers + X graphic layers good enough for you?  (X being a parameter based on FPGA resources.)
Or, do you need more than 2 tile layers?
Note that a -8 Altera FPGA can only run it's blockram at 250MHz, so, that's less than the 297MHz requires for a 4:1 mux read running 720p.  Though, we might be able to do some fancy crap to work around this to get 3:1, but, how advanced do you want to go and the cheapest Lattice -6 can only run the core ram at 200MHz. (Not listed, just a guesstimate as only their highest speed 272MHz is in their data sheet.)

[nockieboy]

Ok, maybe the better question I should ask is:
Are 2 tile layers + X graphic layers good enough for you?  (X being a parameter based on FPGA resources.)
Or, do you need more than 2 tile layers?
Note that a -8 Altera FPGA can only run it's blockram at 250MHz, so, that's less than the 297MHz requires for a 4:1 mux read running 720p.  Though, we might be able to do some fancy crap to work around this to get 3:1, but, how advanced do you want to go and the cheapest Lattice -6 can only run the core ram at 200MHz. (Not listed, just a guesstimate as only their highest speed 272MHz is in their data sheet.)

I think two tile layers should be just fine.  I'm probably misunderstanding the value of tile layers, but afaik there's nothing they can do that a graphics layer can't and the tile layer was borne out of the need to fit an 80x25 character display into the small amount of block RAM we had available before DDR3?

[BrianHG]

Ok, maybe the better question I should ask is:
Are 2 tile layers + X graphic layers good enough for you?  (X being a parameter based on FPGA resources.)
Or, do you need more than 2 tile layers?
Note that a -8 Altera FPGA can only run it's blockram at 250MHz, so, that's less than the 297MHz requires for a 4:1 mux read running 720p.  Though, we might be able to do some fancy crap to work around this to get 3:1, but, how advanced do you want to go and the cheapest Lattice -6 can only run the core ram at 200MHz. (Not listed, just a guesstimate as only their highest speed 272MHz is in their data sheet.)

I think two tile layers should be just fine.  I'm probably misunderstanding the value of tile layers, but afaik there's nothing they can do that a graphics layer can't and the tile layer was borne out of the need to fit an 80x25 character display into the small amount of block RAM we had available before DDR3?

The difference is with the tile layers, to get a 256 color foreground/background display, for each line, we need to feed 320 bytes per line (80x4bytes) per line and the tile memory will do all the looking up in that 128kb blockram.  For graphics, that would be 640 bytes per line for 8 bit color.

But, with a blitter software font, not only do you need to display the 640 bytes each line, but graphically there is a new 640 bytes every line instead of a new 640 bytes every 16 lines.  And to do a blitter driven tile set into a normal graphics layer, you need to read from 1 section of memory, then write to another, 16 times for a 8x16 font.  And for every move and screen scroll, that's 32x the memory operations compared to the tile modes.  Regardless of blitter speed, if you are using the blitter to draw and fill in the tile section, that will run 32x faster to fill the screen.  And if you use the blitter to fill sections of the tile memory itself, you can animate 100s of characters/tiles simultaneously on display just by writing a few bytes without any other additional overhead.  With the tiles, you can draw huge tiled repetitive animated backdrops by blitting a few new tiles from upper DDR3 ram into the tile memory once every V sync without the Z80 even noticing anything happening.

If you wanted a 8 bit 256 color font, 8x16, 256 characters, that would be 32 kilobytes of ram.  You can create a 1024 character set with 128kb of ram, or, a 256 character set 32bit color font.  Mixes and matching fonts and color settings is also allowed.  Most likely, we will place 2 palettes at the output of the tile ram so each tile layer may have it's own color palette as well.

[BrianHG]

With the geometry unit reading and writing to the DDR3, and the Z80 not generating errors, we can safely say that my DDR3 controller works with a Z80 and GPU.  We now just need to get the picture to come directly from the DDR3 with the new maggie.  Then think about optimizing the geometry unit to work as fast as possible when drawing on the DDR3 plus update it to render with 16bit coordinates and address 32bits so it may draw within the full 512mb of available ram.

[nockieboy]

With the geometry unit reading and writing to the DDR3, and the Z80 not generating errors, we can safely say that my DDR3 controller works with a Z80 and GPU.  We now just need to get the picture to come directly from the DDR3 with the new maggie.  Then think about optimizing the geometry unit to work as fast as possible when drawing on the DDR3 plus update it to render with 16bit coordinates and address 32bits so it may draw within the full 512mb of available ram.

That'll make a huge difference as it means I won't be restricted by the block RAM size anymore - 640x480x8 here we come! Hopefully.   Okay, cool - what do you want me to do?

[BrianHG]

Ok, step 1:

Make take my 'BrianHG_DDR3_DECA_Show_1080p' project and use it's video output section trimmed down to 8 bit color and add a dummy palette between the 8 bit video output to drive a 32bit color result.  Change the PLL to 74.25MHz and the video settings to 720p.

(You will need to engineer a 32bit .mif file, 8 bit address input, 32 bit data out as your ARGB color.)

I would engineer and play with this as a new 'BrianHG_DDR3_DECA_Show_1080p' project first before committing to the GPU as the compile time is quick.  Note you can change the IO for the RS232 debugger so you may test writing data to the pixels.

Since the screen is 900kb, and you geometry unit can only address 1024kb and the Z80 can only do 512k, begin the screen base address memory at 64kb so that the Z80 can at least upload the font from Z80 into the beginning of memory.

Next, moving onto the GPU...

In your GPU, erase your:
GPU_HW_Control_Regs
data_mux_geo
sync_generator
vid_osd_generator
vid_out_stencil

Now, your output will be hard-wired 1280x720 8 bit color.  Graphics only.  1 layer.  So, you will need to blitter all your text setting the geo source to 1 bit color for the font, and 8 bit color for the output screen just like before.  All your other control regs are now gone.  (You can use the scale setting in the blitter to get a simulated 640x360 clean, or 640x480 with some scaling chunks on the Y axix, or, find a 16x24 font and without scaling, get the best Z80 text you have seen yet.)

In fact, with all the erased modules, it might be easier to just add the 'Z80_bus_interface' and 'geometry_processor', the only 2 modules from the old GPU, and add them into the 'BrianHG_DDR3_DECA_Show_1080p', rename it project as your new GPU project.

Note that the read and write channel numbers for the Z80 and geometry unit should remain the same and my single 1080p maggie channel should be moved onto the next additional DDR3 read channel.

[nockieboy]

Okay, literally just had ten minutes to scan your post.  Confused is an understatement, so I'm going to have to take granny steps to make sure I'm not doing it all wrong. 

I've copied your 'BrianHG_DDR3_DECA_Show_1080p' project, renamed it to something similar to our existing project and amended the project top-level files and Quartus meta-project files accordingly.  I've copied across Z80_Interface and geometry_processor files.  I've zipped the project up and attached it for reference.

Make take my 'BrianHG_DDR3_DECA_Show_1080p' project and use it's video output section trimmed down to 8 bit color and add a dummy palette between the 8 bit video output to drive a 32bit color result.  Change the PLL to 74.25MHz and the video settings to 720p.

Which file am I editing for these changes?  Just give me a few more pointers so I know I'm hunting in the right place for these settings.

(You will need to engineer a 32bit .mif file, 8 bit address input, 32 bit data out as your ARGB color.)

This is a new palette table?

Since the screen is 900kb, and you geometry unit can only address 1024kb and the Z80 can only do 512k...

... without an internal MMU managed by the Z80_Interface to switch to different 512KB blocks of DDR3.  Once I've gotten my head around how the new memory will be set up etc, shouldn't take long for me to create an MMU controlled by an additional IO port for the host.

Now, your output will be hard-wired 1280x720 8 bit color.  Graphics only.  1 layer.  So, you will need to blitter all your text setting the geo source to 1 bit color for the font, and 8 bit color for the output screen just like before.  All your other control regs are now gone.  (You can use the scale setting in the blitter to get a simulated 640x360 clean, or 640x480 with some scaling chunks on the Y axix, or, find a 16x24 font and without scaling, get the best Z80 text you have seen yet.)

Yeah, I think we're going to have to break this down into simpler steps so I don't royally mess this up.  Sorry.

[BrianHG]

Don't go too far too quick.
Before adding any Z80 bus or geometry unit, first take a look at the existing deca vpg files, it's pll and my bitmap display system.

You want to change the deca video mode from it's dedicated vpg pll settings and and comment in it's 720p settings in it's vpg section.

Then on my pixel address read generator, you also want to change to a 720p resolution with 8 bit color.

You can test uploading an image via rs232 debugger after you match the GPIO for the RXD/TXD to your current PCB.

But again, start with getting a 720p out.

Then we can look at hooking up the z80 and geo units.

[BrianHG]

I dont know anything about Z80 MMUs.  The only experience I ever had with 8 bit systems was the 6502 where we used bank switching.

For now, isn't 512k access enough?

Remember, it is the geometry unit which will access the graphics higher memory, you do not need to give the Z80 full access, only enough for uploading a font.

You will need to explain the earlier mentioned 16k system, what it doe, how it works...

[BrianHG]

Begin with taking a look at folder vpg_source.

Inside BHG_vpg.v, create a new video mode 720p in the assign section at the bottom.

This wasn't my original code, so you will have to deal with the math.  I've attached a 1080p and 720p standard so you may work out the true 720p numbers.

Next you will need to fix the PLL located in sub-folder 'pll' and edit file pll.v.
I would just change the 'altpll_component.clk0_divide_by = 100,' to 200 making the PLL 74.25 MHz.
Next, check that you are getting a 720p video output.

Next, go to the inputs on my 'BrianHG_display_rmem' initiation and fix them up for a 720p output.

Also inside 'BHG_vga_generator', you will want to make the 'altsyncram   Line_Buffer_DP_ram' buffer address and output 8 bit instead of 32 bit.  Just copy the r/g/b all to the 1 new 8 bit output making a monochrome image.

Get this much working and feed some data into the DDR3 via RS232 debugger and you should see a B&W image.