FPGA VGA Controller for 8-bit computer

[BrianHG]

BrianHG mentioned previously a list of commands/functions that the module would perform and I have a basic checklist myself, like CIRCLE, LINE, FILL, etc and even perhaps basic sprite collision - how would this be implemented and where do I start? 

If you want to start with a geometry engine, then:
Begin with writing your code written in basic.
Try to get as many of the functions possible done with the same 2 for loops.  IE (x & y) counter.
Try to make the drawng codes always draw from left to right as your ram is 16 bit which may be as many as 16 pixels per word.
Start this far.  Make sure the final output resembles addressing screen memory from a pointer, not X&Y pointers.

Then we optimize a bit.
Then we make a verilog equivilant.

Now, because of memory constraints, even though another said no, I do recommend the 'FIFO command plotting drawing port'.  This doesn't mean you will stick with this, all it means is that lateron, you will get rid of the first command FIFO and replace it with a programmable loop sequence counter pointing into system graphics memory to fetch the commands automatically (which would probably still feed fill this FIFO anyways  ).

Now when I say basic, I mean use the 'Free Basic' compiler which I used for the RS232_Debugger.  It takes less than a second to compile and opening a graphics screen is 1 line command which emulating a dumb point placement is also 1 command.  You may use a 'C' compiler for windows to create your code, but, for this type of code fiddling around, you wont have such play-ability.  Also, you might end up coding too well and create code which will be more difficult to translate to verilog.

For the 'FIFO' port, the basic emulation code should read a file which contains the stream the Z80 would be sending to generate the graphics.

As we go further, you will need to add thing like screen base memory, limit X&Y coordinates so your commands don't end up erasing out of screen memory.  You also need to store the pixel bit-plane mode drawing type so the final section knows how to fill the ram.

The final part, written in verilog, pixel writer, takes the plotted memory coordinates and edits the ram's contents.  Because of the biplane system, you will need to read-modify-write each byte coming in.  In this small sequencer, you will want a smart 1 byte cache which will read a byte if needed, and edit contents.  It will not write the byte until it receives the next pixel write since it may be the same memory address as in that cache.  If so, it will re-edit the cache.  If not, it will write the current cache and read the next pixel byte to be edited.  (Now I know we talked about single bit masking for writing bitplane data, however, this may work inside the FPGA, however, if you want external DRAM or SRAM, we can only narrow this down to 8 bits.  So might as well put in the effort and do the cache for universal compatibility.)

I think I said enough for you to begin thinking....

As for every control listed above, I would probably engineer 2 banks of controls for 2 the drawing engine since you can display multiple graphics modes simultaneously on the screen, refilling all that data with 2 different window modes going on might offer an advantage.  This doesn't mean program it that way to begin with, just make allowances when storing all the control registers to hold the 2 banks.  The other choice is 2 distinct drawing engines taking up more FPGA resources.

As for compiling graphics command data.  I do have a universal configurable compiler I created for another project which can build 16 bit opcodes functions with data to create your 'FIFO' port file, however, you would be expected to create a Z80 driven controller of your own in the future.

A lot to think about...

-------------------------------------------------------------------------------------------
Sprite collision is handled inside the pixel-mixer just before the palette since part of the code already exists to discern  if a pixel is solid or not and which once is drawn on-top of one-another.  As for software rendered sprites in the Geometry engine, that will be located in the 'pixel writer which takes the plotted memory coordinates and edits the ram's contents.'  Another reason the read-modify-write pixel drawing command has additional use above simple blind writes into memory which contains 'bit' for 'bit' write enables to access individual bit-planes.

[nockieboy]

If you want to start with a geometry engine, then:
Begin with writing your code written in basic.
Try to get as many of the functions possible done with the same 2 for loops.  IE (x & y) counter.
Try to make the drawng codes always draw from left to right as your ram is 16 bit which may be as many as 16 pixels per word.
Start this far.  Make sure the final output resembles addressing screen memory from a pointer, not X&Y pointers.

Right, leave it with me.  I'll see what I can do.

Also, you might end up coding too well and create code which will be more difficult to translate to verilog.

There's little chance of me coding it too well! 

For the 'FIFO' port, the basic emulation code should read a file which contains the stream the Z80 would be sending to generate the graphics.

Okay, so I'll write a Free Basic program with the basic draw functions and get it to read a file with a list of commands and process them accordingly.  That's absolutely more than enough for me to be getting started with!  Just got to squeeze some time in to familiarise myself with Free Basic.

[BrianHG]

Almost done making a setup freebasic and a compiler for generating a drawing.binary file.
Give me a few more hours.

[BrianHG]

Here you go: 'geo.zip'.

Contents:
Command Prompt - Just a dos shell.  Nice big fat font...
c.bat            - Compiles 'Geo.bas'
geo.bas        - GPU geometry engine simulator/tester written in 'FreeBasic'
palette.bin    - Has your GPU palette so the simulator knows the color palette when drawing

fwasm.exe    - My assembly universal compiler, PIC-ASM16/18 mnemonic compliant, used to convert the 'Drawing.asm' into a binary 'drawing.bin'
instr.txt        - Used by fwasm.exe to define the opcode and operand structure to compile the 'drawing.asm'.  You will add to this file as you add GPU geometry commands.

Drawing.asm - An assembly code written similar to PIC-ASM16/18 mnemonic with a few test plotting commands
Drawing.lst   - Generated by my fwasm.exe, contains the compiled results, opcodes, memory addresses and errors
Drawing.bin  - Contains the fwasm.exe compiler binary which can be run using the geo.exe
Drawinf.mif   - the Drawing.bin in .mif format, less the 8 byte header.

geo.exe        - The compiled executable GPU geometry engine simulator which reads and executes the compiled 'Drawing.bin' file.  It's programmed to pause for a key-press after every plot command.  Once 'Drawing.bin' is finished, you will need to press the 'ESC' key to quit the program.

I've only setup a basic few things (yes it functions!), you will need to do a lot more.

[BrianHG]

     Note that if you do not like the current fixed 16bit instruction format, there is still time to go with an 8bit op-code method which compresses the unused bits and removes commands as 1 command may be used to load multiple settings and perform functions.

     It doesn't make much a difference in the end other than saving a few bytes of ram per operation while making the verilog a little more complex.  Fancy repeat commands or fancy sequencing of functions will no longer be possible.  Corrupt commands creating infinite loops or a crash of the sequencer will now also become possible.

[nockieboy]

Have completed the line function.  Will finish the circle function later tonight. 

[nockieboy]

     Note that if you do not like the current fixed 16bit instruction format, there is still time to go with an 8bit op-code method which compresses the unused bits and removes commands as 1 command may be used to load multiple settings and perform functions.

     It doesn't make much a difference in the end other than saving a few bytes of ram per operation while making the verilog a little more complex.  Fancy repeat commands or fancy sequencing of functions will no longer be possible.  Corrupt commands creating infinite loops or a crash of the sequencer will now also become possible.

Think I'll stick with the 16-bit format.  Less downsides and any loss of speed manipulating 16-bit instructions on an 8-bit processor will be more than made up for by having hardware-accelerated drawing anyway.

[BrianHG]

Have completed the line function.  Will finish the circle function later tonight. 

I fixed 2 sets of errors.
On lines 101 through 104, the srcmem has the wrong '#'  for the x'#' and y'#'.
Also, I wrote little and big endian in the REMarks backwards.

Now for the line algorithm.
Ok, for the screen limits, what we will do in the verilog/code is just skip the PSet/write to pixel ram if the coordinates fall outside the screen limits.  This will allow for geometry to go slightly outside the screen area, yet not be corrupted.  Yes the code will still be generating draw commands, but will ignore the pixel writes.

Now, is everything in your line algorithm 'integer' math?
Can you visualize it in verilog like almost everything else I have already written.

I believe this is another line generator written using ints only as reference.  It's basically the same thing written in C: https://www.eevblog.com/forum/microcontrollers/any-simple-blitter-around-(looking-for-fpga-design)/msg1803284/#msg1803284
Except is it as minimal as it gets and uses fixed point 16.16 mathematics.  Well, I guess we can get away with 12.12 in verilog with the 125Mhz fmax.

After the circle, we will build this module in verilog where the input is a 16 bit data input port with enable & CTS output.  And a 12bit x, 12 bit y, 8 bit color, write pixel enable output & we will simulate it in Quartus.

The actual write pixel will be a second verilog module which will compute the memory address from the coordinates, then do a read / modify / write from GPU ram.  It will have a similar CTS (clear to send) output and an inputs to receive the first geometry unit's coordinates.

Between all these modules, we will tie them together with FIFO, using the full and empty and shift inputs flags for the CTS and data ready inputs to cache and sequence everything, though, except for large flood fills, I doubt the Z80 will ever fill out more than 2 or 3 commands before the geometry unit has finished.

Later, we will improve the pixel memory writer to have a pixel copy function.

[nockieboy]

Now for the line algorithm...

Now, is everything in your line algorithm 'integer' math?
Can you visualize it in verilog like almost everything else I have already written.

Errr... no? 

I believe this is another line generator written using ints only as reference... Except is it as minimal as it gets and uses fixed point 16.16 mathematics.  Well, I guess we can get away with 12.12 in verilog with the 125Mhz fmax.

Attached is the updated Geo.bas, with a new line function based on the linked code.

[BrianHG]

Now, that line generator code can easily be written in verilog.

When doing the circle, it will look pretty similar.

We will skip a filled circle and a filled triangle in place of starting the first part of the verilog simulation.

  I want to modify the filled triangle to a 4 sided filled polygon.  Where the triangle will be a 4 sided polygon with 2 sets of coordinates being identical. The idea is to make 1 function perform 2 shapes.  Then, perhaps make that function plot only the outer edges performing the un-filled variants of the shapes.  All that changes is when you call the different shapes, it will just pass the appropriate x'#' and y'#' into the polygon engine with a fill on or off.

[BrianHG]

Oh, and a circle, filled or unfilled is just the 4 sided polygon with the 4 points generating a bezier curve.

With that 4 sided polygon, you can now make rotated rectangles, triangles & ovals, filled and unfilled completing a very functional geometry engine.

There are some old Amiga 100% polygon rendered game which you would now be able to run at 640x480 60fps on a Z80 where as the Amiga could only do 15fps at 320x200.

It would have been nice to play this buttery smooth and sharp at the time:


Maybe we should re-thing the 12 bit coordinates and go for 24 bit with a scaling and rotating transformation multipliers for the geometry engine, with Z coordinates and you will have a simple 3D rendering engine.

[BrianHG]

If you are going BGA, maybe taking a look at the Lattice 15$ fpga with 2 megabits ram may be useful.

I seem to recall us talking about the Lattice recently and discovering there could be licensing issues?  $99 a year for the IDE is beyond my meagre hobby budget.  If we're going the route of external RAM though, the internal RAM (or lack of) won't be an issue.

Licensing?
https://www.latticesemi.com/en/Products/DesignSoftwareAndIP/FPGAandLDS/LatticeDiamond#_FD13D8A25CBB47BD83F143E5B55DBC75

Under the 'ECP5U', it has a tick 'Free License'.  It's the 'ECP5UM & ECP5UM5G' which require the license, however, I don't think you are placing a 50$ FPGA on your Z80 GPU.

Everything else you have written on your own.
Too bad, but a cheap eval board would really help.

Maybe I might take a look at their Lattice Diamond FPGA design software.

You still need to choose what type of memory you might want for your GPU.

Note that the FPGA internal ram is required for the tile/font texture memory.  The external extended memory, DDR or Hyperbus RAM can only be used for background raster graphics display ram or tile layout ram unless you use the ZBT sram.  With ZBT SRAM, the external memory can do everything like the internal FPGA ram, except, it will only have access to 3 MAGGIES if you run it at 125MHz, 4 MAGGIES if you run it at 150MHZ, 6 MAGGIES at the max 200MHz.  This does not take away from the internal possible 15 MAGGIES, it would be added to them.  Subtract 1 MAGGIE if you want the pixel copy/blitter command to run at 2x speed.  You only need this if you want to display something like 100 large software sprites onscreen 30 frames per second.

[nockieboy]

Aargh. Having trouble with the Free Basic syntax now.  I've got (what I think is) the circle function in there, but I can't test it as I can't seem to successfully add a 'radius' parameter to the func_plot function.  Just getting loads of errors.  Attached current code at bottom.

Oh, and a circle, filled or unfilled is just the 4 sided polygon with the 4 points generating a bezier curve.

 

With that 4 sided polygon, you can now make rotated rectangles, triangles & ovals, filled and unfilled completing a very functional geometry engine.

From the circle function? 

There are some old Amiga 100% polygon rendered game which you would now be able to run at 640x480 60fps on a Z80 where as the Amiga could only do 15fps at 320x200.

 

[BrianHG]

Ok, I've updated the circle with the right command structure.

You were supposed to use the x0,y0 for the center, and the x1,y1 would be the x&y radius.

Now, I know that having 8 plotted points  is optimum since calculating the arc is considered processing intensive, but, inside the FPGA, with your architecture, the actual pixel writing is at the same speed or slower than the mathematics.

What I was thinking was running 4 curved line generators in a row, which each created an arc.  The top left, top right, bottom left, bottom right of the circle.  The reason behind this is when we will create a filled circle, the center of the circle is a right angle triangle filled to the edge of that generated line.

The reason behind this is if we move the left and right coordinates off the center axis and move the top and bottom coordinates off the Y axis, we can generate that oval with any rotation.

Start with drawing only the top left quadrant arc of the circle, using X0&Y0 as the circle's center, but use the X1&Y1 to stretch out the arc being generated.

The update I've attached just corrects your code, corrects the drawing.asm and instr.txt.

[asmi]

Under the 'ECP5U', it has a tick 'Free License'.  It's the 'ECP5UM & ECP5UM5G' which require the license, however, I don't think you are placing a 50$ FPGA on your Z80 GPU.

So it's a full 16x16 BGA matrix with 0.8 mm pitch... 0.8 mm pitch does not leave enough space to fit two traces between pads, so you can only breakout 2 rows on a top layer, 2 more on a next layer (as there are no vias), and only 1 on subsequent (because they will need to go between vias). I've assembled a full pinout matrix diagram for caBGA-256 (as it seems Lattice couldn't be bothered to), and it is 5 IO rows deep. That means you can't fully break it out on 2 signal layers (4 layer board) - you will need 3 signal layers and so 6 layer board.
You can try using a fab that offers 75 um traces - this way you will be able to fit 2 traces between pads on a top layer and so breakout 3 full rows. If that fab can also do 0.4 mm pad vias (or smaller), this will allow breaking out another 3 rows on a next layer, and 2 rows on any subsequent layers. All of that will dramatically reduce the total amount of layers, making 4 layer board absolutely feasible.
Or you can pick a different part that is available in 1 mm pitch BGA, this will mean even 0.1 mm traces will be more than enough to fully breakout a matrix on 4 layers.

[BrianHG]

Under the 'ECP5U', it has a tick 'Free License'.  It's the 'ECP5UM & ECP5UM5G' which require the license, however, I don't think you are placing a 50$ FPGA on your Z80 GPU.

So it's a full 16x16 BGA matrix with 0.8 mm pitch... 0.8 mm pitch does not leave enough space to fit two traces between pads, so you can only breakout 2 rows on a top layer, 2 more on a next layer (as there are no vias), and only 1 on subsequent (because they will need to go between vias). I've assembled a full pinout matrix diagram for caBGA-256 (as it seems Lattice couldn't be bothered to), and it is 5 IO rows deep. That means you can't fully break it out on 2 signal layers (4 layer board) - you will need 3 signal layers and so 6 layer board.
You can try using a fab that offers 75 um traces - this way you will be able to fit 2 traces between pads on a top layer and so breakout 3 full rows. If that fab can also do 0.4 mm pad vias (or smaller), this will allow breaking out another 3 rows on a next layer, and 2 rows on any subsequent layers. All of that will dramatically reduce the total amount of layers, making 4 layer board absolutely feasible.
Or you can pick a different part that is available in 1 mm pitch BGA, this will mean even 0.1 mm traces will be more than enough to fully breakout a matrix on 4 layers.

With a 2 layer board, and 1 trace between 2 pads, he would have access to at least 90 IOs with no VIAs.
The via drill would still need to be small enough to do the VCC and GND.
For a few additional signals above the 90, only a few though, I would reserve them for slow signals where you could afford to snake them around the power which would all need to come in from 1 side or 2 sides of the FPGA.
He could get away with another 20 IOs viaed from top to bottom layer still leaving room for VCC/GND.

A 4 layer board would give him a lot of freedom.
The nice thing about the ZBT ram is that it runs at 3.3v removing an IO supply voltage required by HyperBus ram or DDR2 ram.

[nockieboy]

The nice thing about the ZBT ram is that it runs at 3.3v removing an IO supply voltage required by HyperBus ram or DDR2 ram.

ZBT RAM is looking more and more appealing, and I don't think the cost will be a barrier either with the amounts I'd be using.

[asmi]

With a 2 layer board, and 1 trace between 2 pads, he would have access to at least 90 IOs with no VIAs.
The via drill would still need to be small enough to do the VCC and GND.
For a few additional signals above the 90, only a few though, I would reserve them for slow signals where you could afford to snake them around the power which would all need to come in from 1 side or 2 sides of the FPGA.

Wasn't the whole point of going to BGA is to use (a lot) more IO pins? Using only 90 is such ridiculous waste.

A 4 layer board would give him a lot of freedom.

I don't quite see "a lot of freedom". You still can't have a full breakout, unless you go for 75 um traces, or pick a different part in 1 mm pitch package. 4 layer board still only gives you 2 signal layers, same as 2 layer board.

The nice thing about the ZBT ram is that it runs at 3.3v removing an IO supply voltage required by HyperBus ram or DDR2 ram.

That mostly doesn't matter, because Vccio pins are mostly adjacent to the IO bank they serve, so you can easily place a planelet on a power layer. You will need to sacrifice a few hi-speed pins (use them only for slow signals as they won't have a reference plane directly below/above them) in order to bring in Vccint and Vccaux rails to the middle of the matrix though.

[nockieboy]

Now, I know that having 8 plotted points  is optimum since calculating the arc is considered processing intensive, but, inside the FPGA, with your architecture, the actual pixel writing is at the same speed or slower than the mathematics.

What I was thinking was running 4 curved line generators in a row, which each created an arc.  The top left, top right, bottom left, bottom right of the circle.  The reason behind this is when we will create a filled circle, the center of the circle is a right angle triangle filled to the edge of that generated line.

The reason behind this is if we move the left and right coordinates off the center axis and move the top and bottom coordinates off the Y axis, we can generate that oval with any rotation.

Start with drawing only the top left quadrant arc of the circle, using X0&Y0 as the circle's center, but use the X1&Y1 to stretch out the arc being generated.

So instead of drawing all 8 octants, you only want 2 to be drawn for the top-left quadrant of the 'circle'?  Won't this just require removing 6 of the 8 draw_pixel calls in the displayBresenhmCircle() function, or is there more to this?

[BrianHG]

With a 2 layer board, and 1 trace between 2 pads, he would have access to at least 90 IOs with no VIAs.
The via drill would still need to be small enough to do the VCC and GND.
For a few additional signals above the 90, only a few though, I would reserve them for slow signals where you could afford to snake them around the power which would all need to come in from 1 side or 2 sides of the FPGA.

Wasn't the whole point of going to BGA is to use (a lot) more IO pins? Using only 90 is such ridiculous waste.

Originally, it was the 15$ price each for a core with 2 megabits ram.

He currently has 90 IO on his Cyclone IV.  He would want at least another 44 IOs for 1 or 2 ZBT SRAMs, a few less for DDR2 operating at a lower IO voltage, or, 13 IOs for the Hyperbus Ram, with that IO bank operating at a lower voltage.

He would want 6 IOs to drive a CD Quality stereo audio DAC.
He would want another 4 IOs to improve his SD card interface to support parallel 4 bit mode.
Another 12 IOs to directly drive a HDMI port.  (Though, it can be a replacement for the current Video DAC.)

[nockieboy]

geo.zip attached with top-left quadrant arc drawing.  I've commented-out the circle function call and diverted it to the arc function, so it'll work with the existing drawing.bin.

[nockieboy]

Originally, it was the 15$ price each for a core with 4 megabits ram.

He currently has 90 IO on his Cyclone IV.  He would want at least another 44 IOs for 1 or 2 ZBT SRAMs, a few less for DDR2 operating at a lower IO voltage, or, 13 IOs for the Hyperbus Ram, with that IO bank operating at a lower voltage.

He would want 6 IOs to drive a CD Quality stereo audio DAC.
He would want another 4 IOs to improve his SD card interface to support parallel 4 bit mode.
Another 12 IOs to directly drive a HDMI port.  (Though, it can be a replacement for the current Video DAC.)

Yes, this is accurate, plus another 10 IOs max to fill out the buffer (level converter) direction controls for the command and address buses as well, so that I have the option of being able to run the whole show from the FPGA with a soft-core CPU if I (or anyone else) wanted to go that route.

[BrianHG]

geo.zip attached with top-left quadrant arc drawing.  I've commented-out the circle function call and diverted it to the arc function, so it'll work with the existing drawing.bin.

Ok, I think what I asked for was wrong.  What I'm looking for is Bresenham's Ellipse.  Remember, we don't want to make 2 codes in the FPGA for circles and ellipses.  When you call a circle, the Verilog will just copy and use the X1 coordinate as the X&Y radius while calling the ellipse.  When you want an ellipse, the same ellipse will be called using the separate X&Y figures stored in X1&Y1.  However, this will not allow you to rotate the ellipse.  The calculation speed in the FPGA for the ellipse will be just as fast as the optimized circle algorithm.
 
After this, we have the filled ellipse.

The triangle which calls 3 lines.
Filled triangle which calls 3 lines, while plotting a line from 1 coordinate of the rendering line.

I'm not sure what else you would like, but next we go to the Geometry_xy_plotter.sv and simulate.
Then will come Geometry_pixel_writer.sv and simulate on it's own.
The merge the 2 together and simulate.

[nockieboy]

Ok, I think what I asked for was wrong.  What I'm looking for is Bresenham's Ellipse.  Remember, we don't want to make 2 codes in the FPGA for circles and ellipses.  When you call a circle, the Verilog will just copy and use the X1 coordinate as the X&Y radius while calling the ellipse.  When you want an ellipse, the same ellipse will be called using the separate X&Y figures stored in X1&Y1.  However, this will not allow you to rotate the ellipse.  The calculation speed in the FPGA for the ellipse will be just as fast as the optimized circle algorithm.

Ah, my bad - thought it was too easy. 

I'm not sure what else you would like, but next we go to the Geometry_xy_plotter.sv and simulate.

What else do I need?  Plot, line, circle/arc and polygon (and their filled variants) are all I can think of, unless you have other suggestions?

[NorthGuy]

Remember, we don't want to make 2 codes in the FPGA for circles and ellipses.  When you call a circle, the Verilog will just copy and use the X1 coordinate as the X&Y radius while calling the ellipse.  When you want an ellipse, the same ellipse will be called using the separate X&Y figures stored in X1&Y1.  However, this will not allow you to rotate the ellipse.  The calculation speed in the FPGA for the ellipse will be just as fast as the optimized circle algorithm.

May I suggest. You can create just a simple drawer which draws an arbitrary curve given three points. Such curves can then be used to draw any sort of lines - straight, circles, ellipses, true-type fonts etc. Then you can organize everything into a pipeline:

drawing commands (circle, line etc.) ---> FIFO ---> parser which dissects shapes into simple curves ---> FIFO --> curve drawer ->

This way you need only a single drawing algorithm and save some logic. Later you can add other drawers, such as area fillers or blitters in parallel with the curve drawer, each with its own FIFO queue from the parser.