FPGA VGA Controller for 8-bit computer

[BrianHG]

Must be a compiler setting then as the version of the project you uploaded compiles with exactly almost the same Fmax results as you're getting.  How odd - I was sure I hadn't changed anything but the results speak for themselves. 

EDIT:

I'm getting clk[0] Fmax = 125.94 MHz, clk[2] Fmax = 130.72 MHz.  Not quite the same as what you're getting.  Is that usual or is the Fmax sensitive to the host computer the project is compiled on? 

The slight change in FMAX was because I forgot a change which forced the filled shapes to draw as outlines.
The change lowered the FMAX slightly.  But no problem.  I'm now finishing the raster fill.  Update in an hour or so.

[BrianHG]

Here you go, V5 with fill, all shapes except ellipse.
Please test everything.
I've included the final project EP4CE10 & simulation test bench Geo_Writer_V5.
Some optimization sacrifices were made to make the code editable by you.  For this, the odd additional clock cycle happens during line generation.

Test everything as I'll add the blitter next.

[nockieboy]

Initial testing is throwing up a problem.  I'm using the identical test that I've been using for the last couple of weeks.

Looks like the bottom line of the filled rectangle isn't getting drawn and there's an issue with certain orders of triangles?

Line renderer seems to be working:



However, the multi-shape test is showing that the bottom-most horizontal line of filled and frame rectangles isn't being drawn.  Weirdly, neither are the two pixels in either of the bottom corners.  I have checked the output of previous GPU versions and they are there normally. Also, there should be two more triangles on the screen after the first one, which is draw as both filled and frame just fine, but the next one that should overlap it slightly below it, isn't drawn properly.  You might see the black pixel at the bottom of the first triangle where the second one starts and overlaps it slightly.  No quad is drawn, either.



Drawing random filled/frame rectangles shows up a strange error in their rendering too:



I have to reset the hardware after the rectangles are drawn, otherwise I can't get any graphical output at all if I run the tests again - seems the geometry engine is locking up somewhere?

[BrianHG]

Only proceed onto the this code once you fully verify the previous code.
Well too late.  I need to see why you are getting those errors.
Just ry this code, without using the blitter, the errors will probably be identical.


Here is the code with a fully functional blitter.  Here are the blitter functions:

1.  Functions 0x78ZZ,0x79ZZ,0x7AZZ,0x7BZZ
Like the pixel write base address commands 0x7C-0x7F, this tells the blitter pixel copy command where in memory the source image is located.  The address taken from the contents of regs x/y[0-3].

2.  Functions 0x70ZZ and 0x72ZZ:
Like the write raster width & bitplane depth commands 0x71 and 0x73, this tells the blitter pixel copy command the source image width and source image bitplane depth.  The width is taken from registers x/y[3 & 2] (I know this 1 control is reversed order compared to all other commands.  You never asked to switch this.) and the bitplane depth is taken from the 'ZZ'.

3. Functions 0x74ZZ & 0x75ZZ:
This function sets the blitter width and height box size to be copied +1.  This means a setting of 7x, 7y will copy a box of 8 pixels by 8 lines.  The width and height are taken from regs x/y[ 2 & 3 ].  (This one is in proper order.)

4. Functions 0x76ZZ & 0x77ZZ:
This function sets the source image offset.  The copy read position offset are taken from regs x/y[ 2 & 3 ].  (This one is in proper order.)

5. Function 0x00ZZ:
This sets the blitter function.  It is controlled by the contents of the lower command byte 'ZZ'.  Here are the bit functions:

Code: [Select]

//************************************************************************************************************************************************
// p_blit_features bitmask features:
// 0 = Enable blitter       1 = run biltter copying source to output coordinates, 0 = Simple pixel write command
// 1 = Enable paste mask    1 = Pasting pixels with transparency mask, 0 = Always paste pixels even if the source has the selected transparent color
// 2 = Enable center paste  1 = Offset the paste up and to the left by half of blit_width/height, 0 = Use the paste coordinates as the top-left
//************************************************************************************************************************************************

6. Function 0x08ZZ:
This one sets a color transformation on the blitter pixel copy command.  This means the read pixel is XORed with the contents of 'ZZ'.  Since when using the mask feature, the transparent color is '0x00', XORing the read pixels with a custom number here other than '0x00' will change the read color which will simultaneously change what color will become transparent when a paste/write pixel is done with mask enable.

Blitting: All draw commands will blitt.  This mean if you use command '0x01ZZ', the paste will begin at coordinates x/y[0], or be centered shifted depending on set width & height when 'Enable center paste' is enabled.  If you use the line command '0x02ZZ', the blitter will paste a new copy of the source image for every single pixel in the source line coordinates x/y[0] - x/y[1].

The chosen drawing 'ZZ' color will perform a second XORing of the first XORed pixel copy, then allow you to change the color once again before the pixel is written.  So, if your source image is monochrome 1 bit color and your destination screen is 4 bit 16 colors, you can XOR a number like 0x04 which make to output color 0x04 and 0x05 instead of 0x00 and 0x01.  Careful not to choose an XOR number larger than the available colors on the destination screen, otherwise garbage will bleed into adjacent pixels.

Things you need to test:
A)
Keep using your current 16 color screen.
Set the source raster width to 8 pixels and 1 bit color depth with the base memory address set to your font memory address.
Set the blitter width and height to 8x16.
Now, keeping the source image offset X at 0, choose a character by setting the source offset Y to 16 X ASCII char #.
Blitt a copy onto a chosen screen coordinates using a command 0x01ZZ, pixel write.
Blitt multiple letters all over the place.
Test the mask enable feature.
Try changing test colors & invert the transparency making negative outline colors.

B) Attempt emulating carriage return of the bottom of the screen by using the biltter to copy begining 16 lines down, all the way to the bottom of the display, copied up to the first line of video, then draw a black box on the bottom 16 lines of video.

C) Attempt a smooth vertical scroll carriage return by making the above routine blitter copy beginning 1 line down, all the way to the bottom, pushing the image up only 1 line, waiting for a vsync, then doing this again 16 times in a row.

D) Attempt drawing a line/triangle/box/quad with a thick pen by making a 1 bit small monochrome circle 8x8 pixels.  Then turn on the blitter and mask and center offset correction, and draw the shape.  Your geometry lines should be painted with the circle pen you created, with it's color changes to the XORed 'ZZ' color setting.

I've attached the V6 geo blitter test bench and full EP4CE10 project.  Your FPGA is >90% full.  Going to a bigger chip will make achieving the FMAX easier, though right now, it will take almost 5 minutes to compile.

[BrianHG]

Drawing random filled/frame rectangles shows up a strange error in their rendering too:

Ok, see the filled rectangle bug.
I need to vertically sort the Y coordinates.

[BrianHG]

Initial testing is throwing up a problem.  I'm using the identical test that I've been using for the last couple of weeks.

Looks like the bottom line of the filled rectangle isn't getting drawn and there's an issue with certain orders of triangles?

Line renderer seems to be working:

Need to analyze, I did not verify your code which sorts these triangles vertices...

In the meantime, work on the blitter as it will still work and you have a number of things to test.

The other problems seem to be that the command system isn't stopping immediately once the drawing has begun.  At least I think so...

[nockieboy]

Only proceed onto the this code once you fully verify the previous code.
Well too late.  I need to see why you are getting those errors.
Just ry this code, without using the blitter, the errors will probably be identical.

Yes, same errors on this version too.

Here's another pic - this one is the grid test, showing the line generators seem to be working fine but the red filled rectangle that normally jumps from cell to cell when I move it isn't drawing properly.  Doesn't seem to be missing the bottom row this time, but the top row is either missing or drawing to the edge of the screen.  You can see artefacts in previous cells where the red rectangle has been.

(Basically when the rectangle 'moves', it is overdrawn with a black filled rectangle, then the red filled rectangle is drawn in the next cell.)

[BrianHG]

Yup, the new version only adds the blitter.  No other changes.
I need to sleep now.  I'll look at the bugs tonight.
For now, you can start playing with the blitter using simple plot pixel and line commands.

[nockieboy]

Yup, the new version only adds the blitter.  No other changes.
I need to sleep now.  I'll look at the bugs tonight.
For now, you can start playing with the blitter using simple plot pixel and line commands.

I'll make a start looking at the blitter commands and see if I can get some text on screen with the graphics, but I'll document the new commands first.   Oh, one other thing I noticed - Fmax is down to 119.77 MHz.

[BrianHG]

Yup, the new version only adds the blitter.  No other changes.
I need to sleep now.  I'll look at the bugs tonight.
For now, you can start playing with the blitter using simple plot pixel and line commands.

I'll make a start looking at the blitter commands and see if I can get some text on screen with the graphics, but I'll document the new commands first.   Oh, one other thing I noticed - Fmax is down to 119.77 MHz.

Were the timing analyzer results clock result RED?
Did the compiler say that timing constraints were not me?
Was that 119.77MHz limit result for CLK[0], the one which needs to be at least 125MHz?
Or was that CLK[2], your PS2 keyboard clock which is only running at 50MHz where the 119.77MHz limit is actually 2x fine and CLK[0]'s limit was >126MHz?

Remember, I fixed all the IO and core timing constraints, if the compiler doesn't make that section 'RED', then everything is ok.  That took hours to fix a month ago thanks to poor documentation on Intel's part.  Remember, the timing analyzer used to always light up red...

Your FPGA is 90% full, squeezing in any more logic and trying to maintain CLK[0]'s 125MHz minimum means other slower sections will begin to loose placement and routing priority dropping their top FMAX is there is clearance to do so.

[nockieboy]

Were the timing analyzer results clock result red?
Did the compiler say that timing constraints were not me?
Was that 119.77MHz limit result for CLK[0], the one which needs to be at least 125MHz?
Or was that CLK[2], your PS2 keyboard clock which is only running at 50MHz where the 119.77MHz limit is actually 2x fine?

Remember, I fixed all the IO and core timing constraints, if the compiler doesn't make that section 'RED', then everything is ok.

Uh, never mind, I'm having a bad day.  It was for clk[2], not clk[0]. 

I've had a little free time to try and get a character to blit onto the screen, but having mixed results because I'm clearly making a mistake in setting the base source address or the offset or something.

What I'm trying to do to test the blitter is this:

1. Set the base memory address to the start of the font table (0x0200)

• Send 0x200 to X[0] - command 0x8200
• Send 0x00 to Y[0] - command 0xC000
• Set base memory address - command 0x7800

2. Set the source raster width to 8 pixels with 1-bit colour depth

• Set Y[2] to 8 - command 0xE008
• Set raster width to Y[2] pixels and bpp to 1 - command 0x7200

3. Set blitter width/height to 8x16

• Set X[2] to 7 - command 0xA007
• Set Y[2] to 15 - command 0xE00F
• Set copy width/height - command 0x7400

4. Set source offset to 16xASCII char # - in this case, capital 'X' (0x58 x 0x10 = 0x580)

• Set X[2] to 0 - command 0xA000
• Set Y[2] to 0x580 - command 0xE580
• Set source image offset - command 0x7600

5. Turn on the blitter, with Paste Mask and Centre Paste turned off

• Enable blitter, disable PM + CP - command 0x0001

6. Blit the character 'X' to 100,100 on the screen

• Set X[0] to 100 - command 0x8064
• Set Y[0] to 100 - command 0xC064
• Plot a pixel in yellow (colour 0x0E) - command 0x010E

The output I get is this:



Two things are immediately obvious - it's not a capital X and there's a pixel missing at the very end.  I'd hesitate to call either of these an issue with the blitter just yet as I'm not 100% confident I'm setting it up properly, hence the rambling list above of commands I'm using to get this output.

EDIT:  Definitely something wrong with my base memory and offset address setup.  I'm getting the letter 'j' appear in 1-bit mode.

[nockieboy]

Your FPGA is 90% full, squeezing in any more logic and trying to maintain CLK[0]'s 125MHz minimum means other slower sections will begin to loose placement and routing priority dropping their top FMAX is there is clearance to do so.

I'm working on the schematics for the EP4CE22F17 version currently, after getting a little scared off by the potential power supply requirements for the Cyclone V and lack of reference designs anywhere I can make use of.

The only hints of schematics I've found use QFN power chips, which means there's more of a learning curve for me than just trying to solder a BGA, coupled with the extra power draw that my existing power board in my uCOM just won't keep up with - so I'd have to re-design and up-rate the power card first.  Seems the EP4CE22 should be okay though, and I have reference schematics I can use to confirm my design with.  I need some time to be able to make headway on its design though.

[BrianHG]

Were the timing analyzer results clock result red?
Did the compiler say that timing constraints were not me?
Was that 119.77MHz limit result for CLK[0], the one which needs to be at least 125MHz?
Or was that CLK[2], your PS2 keyboard clock which is only running at 50MHz where the 119.77MHz limit is actually 2x fine?

Remember, I fixed all the IO and core timing constraints, if the compiler doesn't make that section 'RED', then everything is ok.

Uh, never mind, I'm having a bad day.  It was for clk[2], not clk[0]. 

I've had a little free time to try and get a character to blit onto the screen, but having mixed results because I'm clearly making a mistake in setting the base source address or the offset or something.

What I'm trying to do to test the blitter is this:

1. Set the base memory address to the start of the font table (0x0200)

• Send 0x200 to X[0] - command 0x8200
• Send 0x00 to Y[0] - command 0xC000
• Set base memory address - command 0x7800

2. Set the source raster width to 8 pixels with 1-bit colour depth

• Set Y[2] to 8 - command 0xE008
• Set raster width to Y[2] pixels and bpp to 1 - command 0x7200

3. Set blitter width/height to 8x16

• Set X[2] to 7 - command 0xA007
• Set Y[2] to 15 - command 0xE00F
• Set copy width/height - command 0x7400

4. Set source offset to 16xASCII char # - in this case, capital 'X' (0x58 x 0x10 = 0x580)

• Set X[2] to 0 - command 0xA000
• Set Y[2] to 0x580 - command 0xE580
• Set source image offset - command 0x7600

5. Turn on the blitter, with Paste Mask and Centre Paste turned off

• Enable blitter, disable PM + CP - command 0x0001

6. Blit the character 'X' to 100,100 on the screen

• Set X[0] to 100 - command 0x8064
• Set Y[0] to 100 - command 0xC064
• Plot a pixel in yellow (colour 0x0E) - command 0x010E

The output I get is this:

(Attachment Link)

Two things are immediately obvious - it's not a capital X and there's a pixel missing at the very end.  I'd hesitate to call either of these an issue with the blitter just yet as I'm not 100% confident I'm setting it up properly, hence the rambling list above of commands I'm using to get this output.

EDIT:  Definitely something wrong with my base memory and offset address setup.  I'm getting the letter 'j' appear in 1-bit mode.

Something weird is going on, it may be the pixel address generator.
It's also yellow?
The last pixel also looks missing.  OK, I see the bug.  Will fix tonight.

Try Character 01, IE offset Y=16.  This should generate the VGA font's happy face.
PAGET and Pixel Writer has never been tested with reading 1 bit color under strict scrutiny.
Or something's overwritten your font.
But, Yellow?  Unless you used a weird write paste color, maybe the Pixel Writer needs to be checked.

Try making the base address the screen memory, and raster width of 320 and match the 4 bit color.
Then copy, after painting your other test triangle and blue box.
Make copy blit width & height 160x200 and paste blit at 160,0.  A copy of the left half of the screen should appear on the right hand side.

[BrianHG]

Your FPGA is 90% full, squeezing in any more logic and trying to maintain CLK[0]'s 125MHz minimum means other slower sections will begin to loose placement and routing priority dropping their top FMAX is there is clearance to do so.

I'm working on the schematics for the EP4CE22F17 version currently, after getting a little scared off by the potential power supply requirements for the Cyclone V and lack of reference designs anywhere I can make use of.

The only hints of schematics I've found use QFN power chips, which means there's more of a learning curve for me than just trying to solder a BGA, coupled with the extra power draw that my existing power board in my uCOM just won't keep up with - so I'd have to re-design and up-rate the power card first.  Seems the EP4CE22 should be okay though, and I have reference schematics I can use to confirm my design with.  I need some time to be able to make headway on its design though.

Schematic 1.
https://software.intel.com/content/www/us/en/develop/articles/de10-nano-board-schematic.html
Another:
https://www.analog.com/media/en/technical-documentation/eval-board-schematic/c5_soc_devkit_c.pdf
Another:

Search for libraries.
For switching regulator DC-DC converters, try this guy: AOZ1284.
It's cheap and only requires an external 10uH SMD power inductor and 1 diode with a few resistors and caps.
4 amps output, no heatsink.
Adjustable voltage from 0.8v to beyond 5v.
http://www.aosmd.com/res/data_sheets/AOZ1284PI.pdf

Also, TI's: Anything on this page will do:
https://www.ti.com/power-management/non-isolated-dc-dc-switching-regulators/step-down-buck/buck-converter-integrated-switch/products.html#p451max=3;4&p634max=5;90&p20min=1000;5700

Example 'TLV62090', 5v in, adjustable out... Only needs a 1uH inductor and delivers 3 amps, no heatsink.
'TLV62130A' up to 17v in, 0.9v and up adjustable output. 2.2uH inductor, also 3 amps.

'TPS563249' TI sells this one direct for only 62cents each. Also 3 amps.  That's cheaper than linear regulators...
https://www.ti.com/store/ti/en/p/product/?p=TPS563249DDCR&HQS=OCB-tistore-invf-storeinv-invf-store-findchips-wwe
It's only downside is that it needs at least 4.5v in, but the Vin goes up to 17v.
For 3amp load @ 3.3v, I would power these with 6v - 12v in.
For 3amp load @ 1.8v, I 4.5v in would be fine.

The more expensive 'TLV62130A' @1$ can deliver the same full 3 amp current with a smaller Vin-Vout voltage gap, IE 4.5v to 3.3v.
I think Farnell/RS Components has stock of this one, but they jacked up the price compared to the TI store.

[nockieboy]

Something weird is going on, it may be the pixel address generator.
It's also yellow?
The last pixel also looks missing.  OK, I see the bug.  Will fix tonight.

Try Character 01, IE offset Y=16.  This should generate the VGA font's happy face.

This is what I get if i change X[2] to 0 (0xA000) and Y[2] to 16 (0xE010) and set the source image offset to that (0x7600):



I'm blitting the character using this command - 0x010E.  So write pixel (0x01) and colour yellow (0x0E).  It seems whatever colour I choose, that colour replaces the transparent/0 bits in the copied image, and the next colour up (in this case 0x0F or white) replaces the 1-bits in the copied image.

The character hasn't changed, though, which was why I was thinking it was something to do with my base or offset addresses earlier.

PAGET and Pixel Writer has never been tested with reading 1 bit color under strict scrutiny.
Or something's overwritten your font.

Nothing has overwritten the font as far as I know.

But, Yellow?  Unless you used a weird write paste color, maybe the Pixel Writer needs to be checked.

As outlined above, I'm using yellow as the write pixel colour, but I haven't got paste mask on.

Try making the base address the screen memory, and raster width of 320 and match the 4 bit color.
Then copy, after painting your other test triangle and blue box.
Make copy blit width & height 160x200 and paste blit at 160,0.  A copy of the left half of the screen should appear on the right hand side.

That didn't work as expected.  I'm still not 100% sure I'm setting up the blitter properly though.  For that last image, I did this:

• Set base memory address to 0x1200 - 0x8200, 0xC001, 0x7800
• Set source raster width to 320 pixels, 4 bpp - 0xE13F, 0x7202
• Set blitter width/heigh to 160x200 - 0xA0A0, 0xE0C8, 0x7400
• Set image offset to 0 - 0xA000, 0xE000, 0x7600
• Blit - 0x80A0, 0xC000, 0x010E

[BrianHG]

Need to do a full sim tonight...
Arrrg, so many setup variables...
Except for the last missing pixel, the Blitter inside the geometry unit is generating the correct commands and read and write coordinates which are being sent to the address generator.  I need to see what's happening after inside the address generator.  The originally, the pixel writer did perform correct reads and writer when I did a simulation of it.  And, it could not draw proper geometry shapes on a 16 color screen if it weren't first reading GPU ram, then editing the correct bit mask, then doing a pixel write.  And the current screen copy shows a 0 color transform, going from 16 color to 16 color screen.

The destination being in the right screen location, but with stretched line images, I would bet the address generator isn't generating the right read address.  Probably a typo somewhere as the read address generation mirrors the write address which we knows it works.

[nockieboy]

Need to do a full sim tonight...
Arrrg, so many setup variables...
Except for the last missing pixel, the Blitter inside the geometry unit is generating the correct commands and read and write coordinates which are being sent to the address generator.  I need to see what's happening after inside the address generator.  The originally, the pixel writer did perform correct reads and writer when I did a simulation of it.  And, it could not draw proper geometry shapes on a 16 color screen if it weren't first reading GPU ram, then editing the correct bit mask, then doing a pixel write.  And the current screen copy shows a 0 color transform, going from 16 color to 16 color screen.

The destination being in the right screen location, but with stretched line images, I would bet the address generator isn't generating the right read address.  Probably a typo somewhere as the read address generation mirrors the write address which we knows it works.

I'd feel much happier if you were able to confirm that the commands I'm sending are correct before you go too far down the sim and bug-hunting route.  I'd hate for this to all be because I'm doing something wrong with the setup.  Wouldn't be the first time. 

[nockieboy]

Schematic 1.
https://software.intel.com/content/www/us/en/develop/articles/de10-nano-board-schematic.html
Another:
https://www.analog.com/media/en/technical-documentation/eval-board-schematic/c5_soc_devkit_c.pdf

Problem with those schematics is they're for the SoC version of the Cyclone V.  Whilst you're probably quite comfortable looking at those schematics and deciding what is needed and what isn't for a more stock (non-SoC) Cyclone V E, they just confuse the heck out of me.  The SoC requires more power rails, and there's a lot of stuff in there that I have no need for and doesn't translate directly to an E-version Cyclone V.  I'm stretching my understanding (and luck) designing for an E, without the complication of trying to translate the schematics for a SoC version.

Here's what I've been using as a guide - the DE0 Nano:
https://wiki.bu.ost.ch/infoportal/_media/fpga/boards/de0_nano/de0-nano-schematic.pdf

Search for libraries.
For switching regulator DC-DC converters, try this guy: AOZ1284.
It's cheap and only requires an external 10uH SMD power inductor and 1 diode with a few resistors and caps.
4 amps output, no heatsink.
Adjustable voltage from 0.8v to beyond 5v.
http://www.aosmd.com/res/data_sheets/AOZ1284PI.pdf

Hey, good spot!   That looks to be a perfect replacement for the existing 7805 I have providing the 5V power rail on my uCOM currently.  It's probably going to be stretched to the limit with an EP4CE22, let alone anything larger.  It'd also replace my 3.3V rail AMS1117 which really isn't up to anything more than its current application (providing the EP4CE10 and I2C with 3.3V).

The more expensive 'TLV62130A' @1$ can deliver the same full 3 amp current with a smaller Vin-Vout voltage gap, IE 4.5v to 3.3v.
I think Farnell/RS Components has stock of this one, but they jacked up the price compared to the TI store.

So which is better - the TLV62130A or the AOZ1284?  I'd be using them to provide a 5V and 3.3V rail to the entire uCOM system, as well as the GPU - which would have more chips supplying the 1.2 and 2.5V rails from the 5V rail.  The uCOM draws about 120mA without the GPU.

[BrianHG]

That didn't work as expected.  I'm still not 100% sure I'm setting up the blitter properly though.  For that last image, I did this:

• Set base memory address to 0x1200 - 0x8200, 0xC001, 0x7800
• Set source raster width to 320 pixels, 4 bpp - not clearing 0xA000 0xE13F, 0x7202
• Set blitter width/heigh to 160x200 - 0xA0A0, 0xE0C8, 0x7400
• Set image offset to 0 - 0xA000, 0xE000, 0x7600
• Blit - 0x80A0, 0xC000, 0x010E

4bpp is 0x7203, the screen width is larger than 12 bits.
And, 0xAxxx and 0xExxx, if I am not mistaken, you have the width set to $13F000?  1306624 X pixels?
Shouldn't it be $000140? X=320 pixels?  this explains some of the mess.
How did you set the screen width.  It should have the same  0xAxxx and 0xExxx values. IE 0xE000 & 0xA140.
And instead of 0x7203, you should have 0x7103 or 0x7303 depending on which XY regs you choose.

Ok, the 'ONE' fix in this code is just the missing last pixel.
I need to see blitts with the right settings before I go messing around in the pixel writer.

I'm working on the sorted coordinates and 'Filled' polygons now.

[BrianHG]

So which is better - the TLV62130A or the AOZ1284?  I'd be using them to provide a 5V and 3.3V rail to the entire uCOM system, as well as the GPU - which would have more chips supplying the 1.2 and 2.5V rails from the 5V rail.  The uCOM draws about 120mA without the GPU.

The TI has far more suppliers, though it's double price the AOZ1284.  Use it only for the 3.3v & VCC 1.8v core.  The 2.5v PLL you may use a cheap linear 50ma regulator in sot23 package.  The VCC analog for the DAC you may also use a 100ma regulator.  The TI part doesn't require a diode on the output and it's inductor is far cheaper and smaller at 2.2uH 4 amp instead of the AOZ1284's required 10uH 5 amp inductor.

As for the Cyclone V, the smallest one is actually the next size up and you then get 49K logic cells and 3 megabits ram.  Your current design almost reaches 10k logic gates and, well, you know.  If not, the first one is 25K logic and 1.75 megabits ram.

If I were you, look into the latest KiCad.  It's public domain and it may already have the Cyclone V component in it's library, or online library.  This is the biggest hurdle for you if you are worried about mistakes.

The Cyclone V schematics I sent you will tell you how to hook up the JTAG/Active serial programming ports & configuration lines and filters for the analog PLL core voltages, unless you can find an existing online Cyclone V project which you can load and edit.

[nockieboy]

That didn't work as expected.  I'm still not 100% sure I'm setting up the blitter properly though.  For that last image, I did this:

• Set base memory address to 0x1200 - 0x8200, 0xC001, 0x7800
• Set source raster width to 320 pixels, 4 bpp - not clearing 0xA000 0xE13F, 0x7202
• Set blitter width/heigh to 160x200 - 0xA0A0, 0xE0C8, 0x7400
• Set image offset to 0 - 0xA000, 0xE000, 0x7600
• Blit - 0x80A0, 0xC000, 0x010E

4bpp is 0x7203, the screen width is larger than 12 bits.

Hmm.. I need to clarify this setting then, as the only notes I have pertain to the MAGGIE settings in the hardware registers, where bits 2-0 of the BP2RAST_cmd are:

Bit 2  Bit 1  Bit 0   Video Mode
  0       0       0      1-bit colour
  0       0       1      2-bit colour
  0       1       0      4-bit colour
  0       1       1      8-bit colour
  1       0       0      16-bit, 8 pixels-per-word
  1       0       1      16-bit, 4 pixels-per-word
  1       1       0      16-bit, 2 pixels-per-word
  1       1       1      16-bit, true colour

I've been using these to set the bpp for the geo unit previously.  0x7203 should be 8-bit colour if I'm using the right table?

And, 0xAxxx and 0xExxx, if I am not mistaken, you have the width set to $13F000?  1306624 X pixels?
Shouldn't it be $000140? X=320 pixels?  this explains some of the mess.

I knew in my bones I'd made some mistakes.   I've spotted some more too (like not setting destination raster width for the letter blit, or the source raster width for the half-screen blit.  I blame my lack of concentration and being in the early stages of a cold.

Ok, the 'ONE' fix in this code is just the missing last pixel.
I need to see blitts with the right settings before I go messing around in the pixel writer.

I'm working on the sorted coordinates and 'Filled' polygons now.

Here's the latest image, with the updates mentioned above.



Blitter is being enabled with 0x0001, and both blits are being done with 0x010E commands.

[nockieboy]

The half-screen blit with zero colour (0x0100 command instead of 0x010E).



Looks like I've still got some work to do to sort out that character tile blit. 

[BrianHG]

That didn't work as expected.  I'm still not 100% sure I'm setting up the blitter properly though.  For that last image, I did this:

• Set base memory address to 0x1200 - 0x8200, 0xC001, 0x7800
• Set source raster width to 320 pixels, 4 bpp - not clearing 0xA000 0xE13F, 0x7202
• Set blitter width/heigh to 160x200 - 0xA0A0, 0xE0C8, 0x7400
• Set image offset to 0 - 0xA000, 0xE000, 0x7600
• Blit - 0x80A0, 0xC000, 0x010E

4bpp is 0x7203, the screen width is larger than 12 bits.

Hmm.. I need to clarify this setting then, as the only notes I have pertain to the MAGGIE settings in the hardware registers, where bits 2-0 of the BP2RAST_cmd are:

Bit 2  Bit 1  Bit 0   Video Mode
  0       0       0      1-bit colour
  0       0       1      2-bit colour
  0       1       0      4-bit colour
  0       1       1      8-bit colour
  1       0       0      16-bit, 8 pixels-per-word
  1       0       1      16-bit, 4 pixels-per-word
  1       1       0      16-bit, 2 pixels-per-word
  1       1       1      16-bit, true colour

I've been using these to set the bpp for the geo unit previously.  0x7203 should be 8-bit colour if I'm using the right table?

And, 0xAxxx and 0xExxx, if I am not mistaken, you have the width set to $13F000?  1306624 X pixels?
Shouldn't it be $000140? X=320 pixels?  this explains some of the mess.

I knew in my bones I'd made some mistakes.   I've spotted some more too (like not setting destination raster width for the letter blit, or the source raster width for the half-screen blit.  I blame my lack of concentration and being in the early stages of a cold.

Ok, the 'ONE' fix in this code is just the missing last pixel.
I need to see blitts with the right settings before I go messing around in the pixel writer.

I'm working on the sorted coordinates and 'Filled' polygons now.

Here's the latest image, with the updates mentioned above.

[ Attachment Invalid Or Does Not Exist ]

Blitter is being enabled with 0x0001, and both blits are being done with 0x010E commands.

Maggie settings are different from the geometry settings, remember...
For setting up the geometry controls, the bit depth is number of bits per pixel -1.  Not the table you provided.

I would like to see the text working....
Try character 0 and character 1, that would be a blank square and the happy face...

0x010E would change the resulting colors on the output.

Almost done fixing the geometry unit.
It's given me a headache.

[nockieboy]

Maggie settings are different from the geometry settings, remember...
For setting up the geometry controls, the bit depth is number of bits per pixel -1.  Not the table you provided.

Yeah, that's where I've been going wrong.  Well, one of the places. 

I would like to see the text working....
Try character 0 and character 1, that would be a blank square and the happy face...

It seems whatever I put into the image offset, I'm still just getting the '!!' double exclamation mark.  The weird thing is that if I load a new character set over the default one, which has thinner exclamation marks, I still see the same double exclamation mark on the screen in the GPU test. 

I'm setting the image offset by setting X[2] to 0 (0xA000), Y[2] to 0x10 (0xE010), then command 0x7600.  Source base address is set with 0x8200 and 0xC000 to set X[0] to 200 and Y[0] to 0, then 0x7800.  Is that right?

[BrianHG]

Ok, here is the fixed geometry unit.
You will need to test everything.

For the filled quadrilateral, you need to run them like this:
Set the 4 xy coordinates.

xy[0]   xy[1]

xy[2]   xy[3]

Then send 2 draw commands
0x0Bzz   - This draws a filled triangle coords xy[0,1,2] color zz
0x0Dzz   - This draws another filled triangle coords xy[3,2,1] color zz.

To draw an unfilled quad, draw command 0x05zz should work on it's own.

My head hurts, I'll look at your blitter question tonight.  You can always read the code in the geometry_xy_plotter.sv to double check.

Let me know how all the drawing commands work...
(I know the FMAX only reached 123MHz, just use it for now.)