FPGA VGA Controller for 8-bit computer

[nockieboy]

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.

Have been reading the code - what is going on doesn't make sense.  The command appears to be correct, I'm setting the right register, but I'm getting odd stuff in the blit and it's not changing when I change the offset value.  This is confirmed in the test program (see attached image) - I'm blitting two character tiles, apparently from base memory address 0x1200 and offset 0 for the first one, offset 0x10 for the second, but they're both identical.

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

Mixed bag, really.  Quite a few things going on:

1. Lines and triangles seem to be working fine again, as are quads.
2. Filled rectangles are missing their last filled line.
3. Non-filled rectangles aren't drawing at all.

In the test, it looks like whatever is happening with the missing last line fill is affecting subsequent drawing commands, as I'm not seeing any diagonals drawn in the rectangle, or the outline rectangle (as mentioned earlier), or the pixels in the four corners.  When the diagonals are supposed to be drawn, the only thing that happens is a single pixel in the top left corner of the rectangle.  It disappears in the next step where the outline rectangle should be drawn (but may be being drawn in the same colour as the fill, causing the pixel to 'disappear'.)  Then the next step is the filled triangle on the left side of the screen - when this is drawn, the single pixel in the rectangle reappears in mauve, the same colour as the filled triangle.

Later lines are drawn just fine in the quad, however.

The character tile blit is corrupt garbage - but then I'm wondering if it ever was displaying the '!!' character - it may have been a random chunk of memory that coincidentally looked like a valid character.   The second character tile, which should be the smiley face character, is identical to the first one, which should be the blank/empty character.

The attached image shows the final output with paste mask disabled, blitting with yellow colour (otherwise the character blits are just black squares without PM enabled), and drawing the quad AFTER the blits.



If I draw the quad before the blits, strange things happen and the half-screen blit is corrupted:

[BrianHG]

Please provide 2 adjacent subsequent commands which generate the missing triangle line.

Again, 2 subsequent command which generate the bad box/box fill.

Try to shrink the error so that is is small enough to fit in the simulation.
Like 6x6 pixels each face, or, up tp 12x12 pixels for un-filled objects.

For now, just test the blitter with the mask and offset disabled.

[nockieboy]

Hmm.. okay, here's what the test program does (apologies for the potato-camera images, but they get the message across I think):

; Draw filled rectangle
Command 0x8020H        ; set X[0] to 32
Command 0x0C001H       ; set Y[0] to 1
Command 0x9024H        ; set X[1] to 36
Command 0x0D004H       ; set Y[1] to 4
Command 0x0CFFH        ; draw filled rectangle



; 1st diagonal
Command 0x8021H        ; set X[0] to 33
Command 0x0C002H       ; set Y[0] to 2
Command 0x9023H        ; set X[1] to 35
Command 0x0D03H       ; set Y[1] to 3
Command 0x02FFH        ; draw line X[0],Y[0] to X[1],Y[1]

; 2nd diagonal
Command 0x8021H        ; set X[0] to 33
Command 0x0C003H       ; set Y[0] to 3
Command 0x9023H        ; set X[1] to 35
Command 0x0D002H       ; set Y[1] to 2
Command 0x02FFH        ; draw line X[0],Y[0] to X[1],Y[1]



; Non-filled rectangle
Command 0x8020H        ; set X[0] to 32
Command 0x0C001H       ; set Y[0] to 1
Command 0x9024H        ; set X[1] to 36
Command 0x0D004H       ; set Y[1] to 4
Command 0x04FFH        ; draw rectangle

Attached images show the output of the FIRST filled rectangle block above, then the output after the first keypress (i.e. the diagonals) - although it all seems to have gone to rat food after the first rectangle.

There's obviously a couple of lines of code between setting the register coordinates and telling the GPU to draw the shape that I have missed out of the above - this just overwrites the 'FF' in the draw command to set a different colour and has worked fine all along, so I don't suspect anything wrong with that and have left it out for the sake of simplicity.

16-bit values starting with a letter have a leading zero in front because the assembler that I use, Z80ASM, requires it.

[BrianHG]

Ok, I've re-done it again.
This time, the way I like it instead of doctoring up older code.
You have a real X&Y counter for the raster fill with only 2 linegens operating just like the Freebasic code.
I've also documented it very well with illustrations.
It is now back down to 89% full, but since the new code is more efficient, the blitter is in there as well at that size.
The code is 33% smaller as well.

Now, I'm only queasy about the filled quad.  It has to do when one corner is on the same line as the other and the order of how the coordinates is sorted, but, give it a try.  Remember, to send a filled quad, you just repeat a filled triangle with the same color right after.  Well, you may use a different color to see the cross dividing line.

Give it a thorough test as I would like to put this code to bed if possible.

[nockieboy]

Something is happening between drawing a filled triangle and everything after it. 

I've run my usual test which draws a rectangle first, then diagonals within it, then an outline, then plots pixels at its four corners.  Seems to work fine (but more on this later).

The next thing the program does is draw a filled mauve triangle on the left side of the screen, then draws a white outline of a triangle over it.  That white outline never gets drawn - in fact nothing gets drawn after the first filled triangle - even if I exit the test program and re-run it, there's no graphical output from the GPU.

I added another filled triangle immediately after the first one to see if maybe it was the outlined triangle that was causing the lockup, but the second filled triangle doesn't get drawn either - so there's an issue with filled triangles?

Lines draw fine in their own test (if no filled triangles have been drawn since last reset).



Filled rectangles, however, are still showing artefacts in the grid test.  Not as bad as previously - the topmost line doesn't stretch to the right side of the screen anymore - but the attached image shows what is going on - the single red dots over the white lines are caused when the red box is moved right, the longer red lines are left behind when the red box moves left.  I have not changed any code in this test since the very start and it was working fine before the recent changes, but I'm confused as heck trying work out why the results are different based on the direction of travel of the rectangle - just doesn't make sense.  Moving up and down leaves no artefacts.



Second image shows a close-up of the first rectangle in the main test - this seems to draw just fine - showing the output of filled rectangle, rectangle, line and pixel drawing functions.



This last image is as far as the test gets - the filled triangle - before stopping all graphical output.  Exiting the test program reverts the GPU back to text mode and it works fine, but running the program again without a full reset leads to none of the tests outputting graphics, even if they worked fine before (like the linegen test).

[BrianHG]

need the filled triangle & triangle sequence exact.

[nockieboy]

Okay, I've translated my Z80 assembly into pseudo-code for ease of reading (but all values are unchanged).  This is the entire triangle test routine, but only the first triangle (up to the first 'wait for keypress') is drawn:

; Turn off blitter
Send command 0x0000H        ; Blitter, PM & CP disabled

; Draw filled triangle
Send command 0x8001H        ; set X[0] to 1
Send command 0x0C001H       ; set Y[0] to 1
Send command 0x9018H        ; set X[1] to 24
Send command 0x0D063H       ; set Y[1] to 99
Send command 0x0A003H       ; set X[2] to 3
Send command 0x0E064H       ; set Y[2] to 100
Send command 0x0BFFH        ; draw filled triangle

** wait for keypress  -- nothing after this point is drawn

; Draw filled triangle
Send command 0x8070H        ; set X[0] to 112
Send command 0x0C010H       ; set Y[0] to 16
Send command 0x9088H        ; set X[1] to 136
Send command 0x0D023H       ; set Y[1] to 35
Send command 0x0A073H       ; set X[2] to 115
Send command 0x0E06CH       ; set Y[2] to 108
Send command 0x0BFFH        ; draw filled triangle

** wait for keypress

; Draw triangle
Send command 0x8001H        ; set X[0] to 1
Send command 0x0C001H       ; set Y[0] to 1
Send command 0x9018H        ; set X[1] to 24
Send command 0x0D063H       ; set Y[1] to 99
Send command 0x0A003H       ; set X[2] to 3
Send command 0x0E064H       ; set Y[2] to 100
Send command 0x03FFH        ; draw triangle

** wait for keypress

; Draw filled triangle
Send command 0x800AH        ; set X[0] to 10
Send command 0x0C064H       ; set Y[0] to 100
Send command 0x9030H        ; set X[1] to 48
Send command 0x0D080H       ; set Y[1] to 128
Send command 0x0A001H       ; set X[2] to 1
Send command 0x0E0C0H       ; set Y[2] to 192
Send command 0x0BFFH        ; draw filled triangle

** wait for keypress

; Draw big filled triangle
Send command 0x8136H        ; set X[0] to 310
Send command 0x0C00AH       ; set Y[0] to 10
Send command 0x900AH        ; set X[1] to 10
Send command 0x0D01CH       ; set Y[1] to 28
Send command 0x0A032H       ; set X[2] to 50
Send command 0x0E0C8H       ; set Y[2] to 200
Send command 0x0BFFH        ; draw filled triangle

[BrianHG]

  Stupid mistake on the freeze, try this:

If the filled rectangle still gives trouble, lets see if we can minimize and replicate the glitch down to an image with only around 100 pixels total plotted so I can do a simulation and track down where the pixels are being lost.

(Ignore the slight FMAX violation.  I'll send you better compiler settings to prevent this when editing code in the future.)

[nockieboy]

No freezing now - the test completes without locking up the GPU. 

However, there's still an issue with the triangles - seems the first point of the second (red) triangle is leaving a horizontal line:



In the next image, you can see the topmost point of the third triangle is also leaving a line, but in the other direction now:



The last image is a closeup of the quad, after it has drawn a filled (grey) quad, then diagonals between its corners, then a white outline quad and finally four pixels, one in each corner.  You can see that the filled quad isn't completely overwritten by the unfilled quad.

[BrianHG]

No freezing now - the test completes without locking up the GPU. 

However, there's still an issue with the triangles - seems the first point of the second (red) triangle is leaving a horizontal line:


In the next image, you can see the topmost point of the third triangle is also leaving a line, but in the other direction now:

Need sequence.  I'm assuming that the X fill begin/end address has the wrong coordinate at the top of the triangle.

The last image is a closeup of the quad, after it has drawn a filled (grey) quad, then diagonals between its corners, then a white outline quad and finally four pixels, one in each corner.  You can see that the filled quad isn't completely overwritten by the unfilled quad.

This may be due to the direction/orientation of the lines being drawn after a sort when drawing the filled shape.
The un-filled quad always draws lines xy[0-1,1-3,3-2,2-0].
When filled, the bottom & right side of the quad may be drawn in xy[1-3,1-2,2-3] if y[3] is below, a Higher value coordinate than y[2].  But if y[2] is below, a Higher value coordinate than y[3], the line direction changes to xy[1-2,1-3,3-2].  This order change needs to be replicate when drawing an outline quad so that the Bresenham's line algorithm places lines on the same dots.

It's the direction change of 1 line going from xy[3-2] in one case, then xy[2-3] in the other.  Bresenham's line algorithm will slightly shift the pixels horizontally on that 1 line being generated/drawn in the opposite direction.
In your test, try changing the height of point xy2[2] so it is below (Higher value) than the y in xy[3] and see if it fixes the problem.  If it does, then I know where to attack the problem.

  I will think of a solution.  Though, this wouldn't be an issue with a floating point line generator, my new code has all the coordinate sorting done in advance, it's just that depending on the height of the top 2 corners and bottom 2 corners, the line coordinates flip around.

(When drawing triangles, I always sort the vertices filled or non-filled since it makes no difference.)

[nockieboy]

Need sequence.  I'm assuming that the X fill begin/end address has the wrong coordinate at the top of the triangle.

The sequence is identical to the one I posted earlier - no changes.

This may be due to the direction/orientation of the lines being drawn after a sort when drawing the filled shape.
The un-filled quad always draws lines xy[0-1,1-3,3-2,2-0].
When filled, the bottom & right side of the quad may be drawn in xy[1-3,3-2] if y[3] is a lower coordinate than y[2].  Bit if y[2] is a lower coordinate than y[3], the line direction changes to xy[1-2,2-3].  This order change needs to be replicate when drawing an outline quad so that the Bresenham's line algorithm places lines on the same dots.  I will think of a solution.  Though, this wouldn't be an issue with a floating point line generator, my new code has all the coordinate sorting done in advance, it's just that depending on the height of the top 2 corners and bottom 2 corners, the line coordinates flip around.

You just gave me an instant headache talking about floating point math... 

[BrianHG]

Need sequence.  I'm assuming that the X fill begin/end address has the wrong coordinate at the top of the triangle.

The sequence is identical to the one I posted earlier - no changes.

This may be due to the direction/orientation of the lines being drawn after a sort when drawing the filled shape.
The un-filled quad always draws lines xy[0-1,1-3,3-2,2-0].
When filled, the bottom & right side of the quad may be drawn in xy[1-3,3-2] if y[3] is a lower coordinate than y[2].  Bit if y[2] is a lower coordinate than y[3], the line direction changes to xy[1-2,2-3].  This order change needs to be replicate when drawing an outline quad so that the Bresenham's line algorithm places lines on the same dots.  I will think of a solution.  Though, this wouldn't be an issue with a floating point line generator, my new code has all the coordinate sorting done in advance, it's just that depending on the height of the top 2 corners and bottom 2 corners, the line coordinates flip around.

You just gave me an instant headache talking about floating point math... 

Reread, I just edited the paragraph and I have a test for you to do...

[nockieboy]

Okay, with that change to Y[2] on the quad, the GPU's graphics output hangs after drawing the filled quad...

[BrianHG]

Another edit, just fixed the order of the line draws.  But by now, you should get the idea.
Depending on the Y position of y[2] and y[3], I need to swap the line drawing direction of line xy[2-3].

Same goes for the top xy[1-2].  It just happens your current shape already has the proper orientation.

[BrianHG]

Okay, with that change to Y[2] on the quad, the GPU's graphics output hangs after drawing the filled quad...

(Attachment Link)

Ok, another bug.  Please send the coordinates of that quad and draw command order.
I also need the bad filled triangles since it may be a connected bug as the quad is just 2 back-back filled triangles.

[BrianHG]

Ok, you missed your window of opportunity for me to fix the bug, though I believe I see the problem.
I'm off until later today.

[nockieboy]

Okay, the triangles haven't changed since last time:

; Turn off blitter
Send command 0x0000H        ; Blitter, PM & CP disabled

; Draw filled triangle THIS ONE DRAWS FINE
Send command 0x8001H        ; set X[0] to 1
Send command 0x0C001H       ; set Y[0] to 1
Send command 0x9018H        ; set X[1] to 24
Send command 0x0D063H       ; set Y[1] to 99
Send command 0x0A003H       ; set X[2] to 3
Send command 0x0E064H       ; set Y[2] to 100
Send command 0x0BFFH        ; draw filled triangle

; Draw filled triangle
Send command 0x8070H        ; set X[0] to 112
Send command 0x0C010H       ; set Y[0] to 16
Send command 0x9088H        ; set X[1] to 136
Send command 0x0D023H       ; set Y[1] to 35
Send command 0x0A073H       ; set X[2] to 115
Send command 0x0E06CH       ; set Y[2] to 108
Send command 0x0BFFH        ; draw filled triangle

; Draw triangle
Send command 0x8001H        ; set X[0] to 1
Send command 0x0C001H       ; set Y[0] to 1
Send command 0x9018H        ; set X[1] to 24
Send command 0x0D063H       ; set Y[1] to 99
Send command 0x0A003H       ; set X[2] to 3
Send command 0x0E064H       ; set Y[2] to 100
Send command 0x03FFH        ; draw triangle

; Draw filled triangle
Send command 0x800AH        ; set X[0] to 10
Send command 0x0C064H       ; set Y[0] to 100
Send command 0x9030H        ; set X[1] to 48
Send command 0x0D080H       ; set Y[1] to 128
Send command 0x0A001H       ; set X[2] to 1
Send command 0x0E0C0H       ; set Y[2] to 192
Send command 0x0BFFH        ; draw filled triangle

; Draw big filled triangle
Send command 0x8136H        ; set X[0] to 310
Send command 0x0C00AH       ; set Y[0] to 10
Send command 0x900AH        ; set X[1] to 10
Send command 0x0D01CH       ; set Y[1] to 28
Send command 0x0A032H       ; set X[2] to 50
Send command 0x0E0C8H       ; set Y[2] to 200
Send command 0x0BFFH        ; draw filled triangle

Here's the quad test routine:

; Turn off blitter
Send command 0x0000H        ; Blitter, PM & CP disabled

; Draw filled quad
Send command 0x8020H        ; set X[0] to 32
Send command 0x0C032H       ; set Y[0] to 50
Send command 0x9040H        ; set X[1] to 64
Send command 0x0D028H       ; set Y[1] to 40
Send command 0x0A01CH       ; set X[2] to 28
Send command 0x0E041H       ; set Y[2] to 65
Send command 0x0B03AH       ; set X[3] to 58
Send command 0x0F03CH       ; set Y[3] to 60
Send command 0x0BFFH        ; draw filled quadrilateral
Send command 0x0DFFH        ; draw filled quadrilateral

; Draw diagonals
Send command 0x8021H        ; set X[0] to 33
Send command 0x0C033H       ; set Y[0] to 51
Send command 0x9039H        ; set X[1] to 57
Send command 0x0D03BH       ; set Y[1] to 59
Send command 0x02FFH        ; draw line X[0],Y[0] to X[1],Y[1]

Send command 0x801DH        ; set X[0] to 29
Send command 0x0C036H       ; set Y[0] to 54
Send command 0x903FH        ; set X[1] to 63
Send command 0x0D029H       ; set Y[1] to 41
Send command 0x02FFH        ; draw line X[0],Y[0] to X[1],Y[1]

; Draw outline quad
Send command 0x8020H        ; set X[0] to 32
Send command 0x0C032H       ; set Y[0] to 50
Send command 0x9040H        ; set X[1] to 64
Send command 0x0D028H       ; set Y[1] to 40
Send command 0x0A01CH       ; set X[2] to 28
Send command 0x0E037H       ; set Y[2] to 55
Send command 0x0B03AH       ; set X[3] to 58
Send command 0x0F03CH       ; set Y[3] to 60
Send command 0x05FFH        ; draw quadrilateral

; Now draw some corner pixels
Send command 0x8020H        ; set X[0] to 32
Send command 0x0C032H       ; set Y[0] to 50
Send command 0x01FFH        ; draw pixel at X[0],Y[0]
;
Send command 0x8040H        ; set X[0] to 64
Send command 0x0C028H       ; set Y[0] to 40
Send command 0x01FFH        ; draw pixel at X[0],Y[0]
;
Send command 0x0801CH       ; set X[0] to 28
Send command 0x0C037H       ; set Y[0] to 55
Send command 0x01FFH        ; draw pixel at X[0],Y[0]
;
Send command 0x0803AH       ; set X[0] to 58
Send command 0x0C03CH       ; set Y[0] to 60
Send command 0x01FFH        ; draw pixel at X[0],Y[0]

[BrianHG]

I wanted the tiny small quad filled which freezes the gpu.

[BrianHG]

Test this blind shot...

[nockieboy]

I wanted the tiny small quad filled which freezes the gpu.

Have highlighted the quad code that hangs the GPU in red in my original response.

[nockieboy]

Sorry for delay - work has been hectic last few hours.  Okay, have tested the hotfix from your last post and the triangles (and rectangles) are drawing cleanly now. 

Still hangs on the quad, though. 

EDIT: And the blit issues trying to get a character to blit, obviously.

[BrianHG]

Which quad?
I'm assuming that the vertical fill completes, but a linegen still may have horizontal pixels to draw.
There may be no closure in my code to handle this.
I need to see it happen in the sim to fix it.

[nockieboy]

Which quad?

The first quad drawn - the commands highlighted in red a previous post?

[BrianHG]

Ok, I did 4 things.

1. Fixed the hanging/frozen/un-finished linegen after a fill.  There is always a proper escape route now.
2. Cut the first linegen startup time by one clock cycle after each new command.
3. Removed the raster fill's final pixel from being plotted twice, once by the linegen generating it and then again by the raster fill algorithm itself.
4. Fixed Quartus compiler settings.  Achieving FMAX for now should no longer be a problem if the code isn't changed too much.

To do:
1. Make the outline Quad draw exactly on top of the same edge lines as a filled quad beneath it.  I need you online for this one since I cannot see the results and trying to decipher single dots at 2 different regions across a huge numerical sim time-line is near impossible and impractical.
2. Start testing the blitter more thoroughly.


Please generate me the quad filled, then quad outline example with a small shape and photo illustrating the lemon edge, then same script again modifying only the height of vertex xy[2] below/above xy[3] where the problem doesn't arise.  All other chords needs to be the same, just the y[2] vertex height difference should be opposite in relation to y[3]'s location.

Photograph both.  I will try to make the fix via simulation.

[nockieboy]

Okay, initial testing is good - no problems found with any of the drawing functions (other than the quad issue we know about).  Pixels, lines, triangles, rectangles and quads are drawing nicely. 

I'm not going to be available until tomorrow afternoon/evening, but if you're around then or over the weekend, let me know and I'll be online and ready to help. 

EDIT: Just the character tile blits not working, but we haven't really looked at them yet and I suspect it's my code that's at fault.