Author Topic: FPGA VGA Controller for 8-bit computer  (Read 425758 times)

0 Members and 2 Guests are viewing this topic.

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7738
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1775 on: October 01, 2020, 09:15:10 pm »
Please just send the coordinates of the grey quad with the white outline...
I don't know when I will have free time.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1776 on: October 01, 2020, 09:18:27 pm »
Please just send the coordinates of the grey quad with the white outline...

; 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 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

Is this what you're after?
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7738
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1777 on: October 01, 2020, 10:05:03 pm »
Please just send the coordinates of the grey quad with the white outline...

; 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 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

Is this what you're after?
Well, almost, the 2 y[2] coordinates are different.  Of course the outline wont sit ontop the quad.
I'm assuming you miss understood my instructions.

Which y[2] number, both drawn with the same coordinates generates the bug?

To tell, just do this:
; Draw filled quad and outline with a different color
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
Send command 0x05FFH        ; draw quadrilateral

Visually inspect, the clear the screen and do this:

; Draw filled quad and outline with a different color
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 0x0BFFH        ; draw filled quadrilateral
Send command 0x0DFFH        ; draw filled quadrilateral
Send command 0x05FFH        ; draw quadrilateral


Wait, without different colors on the outline, how do you know if the bug appears?
« Last Edit: October 01, 2020, 10:10:11 pm by BrianHG »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7738
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1778 on: October 02, 2020, 05:35:37 am »
Ok, the non-filled quad automatically changes the direction of the edge lines to match the re-ordering that happens when using the filled quad due to the triangle sorting algorithm.

Also, I finished the blitter.  It now has a bunch or new features:

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 is the source has the selected transparent color
// 2 = Enable H-center paste  1 = Offset the paste to the left by half of blit_width, 0 = Use the paste coordinates as the beginning left
// 3 = Enable Mirror paste    1 = Mirror the output on the X axis.
// 4 = Enable V-center paste  1 = Offset the paste up by half of blit_height, 0 = Use the paste coordinates as the beginning top of the paste
// 5 = Enable Flip paste      1 = Flip the output on the Y axis.
// 6 = Enable Rotate 90 degree paste  1 = Swaps the X&Y coordinates on the paste.
// 7 = Enable Rotate 45 degree paste  1 = Increments/decrements the X&Y coordinates on the paste in unison.
//************************************************************************************************************************************************

As you can see, now I separated the center paste feature into separate H&V.
You also now have individual horizontal mirror and vertical flip function.
You also now get a 90 degree rotate.
It gets even better, you even get a 45 degree rotate.
Note that the 45 degree is experimental and you need to paste 2 adjacent pixels of the same image to fill in the checker board results.  You may use draw a line, from a-b by 1 x horizontal pixel to fill out the checkerboard.

You got to clean up you blitter Z80 code and get all the earlier tests done as well as the new ones as all the new flags can be combined.
« Last Edit: October 02, 2020, 05:59:13 am by BrianHG »
 
The following users thanked this post: nockieboy

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1779 on: October 02, 2020, 04:59:26 pm »
All seems to work fine so far.  :-+

; Draw filled quad and outline with a different color
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 0x0BFFH        ; draw filled quadrilateral
Send command 0x0DFFH        ; draw filled quadrilateral
Send command 0x05FFH        ; draw quadrilateral


Wait, without different colors on the outline, how do you know if the bug appears?

I didn't bother posting my code that sets the colour of the object - it wasn't relevant so I left it out.  Although my post states, "Send command 0x05FFH", the low byte (FF) is overwritten with whatever colour I've chosen for that particular part of the test.

This issue hasn't reoccurred - it's either very picky or I genuinely did get a coordinate wrong in the test code (thought I'd copy-pasted them, but you never know..)  I'll keep an eye out for this later, but I'm not busting a gut worrying about it right now.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1780 on: October 02, 2020, 07:40:45 pm »
Character blitting fixed.  I'd made a mistake on setting the source raster width for the blitter, got X and Y mixed up.  :palm:

1081176-0

Will get to doing proper testing of the blitter functions over the weekend with more character-based blitting, hopefully.  :-+
 
The following users thanked this post: BrianHG

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1781 on: October 02, 2020, 10:24:46 pm »
Just spent ten minutes working on the character blitting.  Can now type into the graphics screen, but it's a long way from supporting DEL, CR, LF etc just yet.  Still promising though!

One question - it's probably just me, but I can't seem to change the colour of the blitted characters - they're all pale blue, no matter what I try, it seems.

1081262-0

This next image shows 90-degree rotation active on the blits too:

1081266-1

EDIT: Alternate fonts work as expected too:

1081274-2
« Last Edit: October 02, 2020, 10:30:23 pm by nockieboy »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7738
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1782 on: October 02, 2020, 10:54:24 pm »
I see the font translucency is working.
When calling the actual blit, IE draw dot, the chosen color get's it's value 'XOR' with the source image.

This means the source without a transparency mask is color 0 or 1.

If you XOR in a color number of 4, the output color becomes 4 or 5.

If the transparency mask is on, the '5' will be drawn while the '4' will be ignored.

If you changed the 'source copy mask color', draw command 08, since the source is 1 bit color, only 0 or 1 will work.  Using a value of 1 will invert the copy output 0 or 1, meaning that the font transparent color becomes 1, no longer 0.  The output would be plotting the voids in the front instead of the character lines.

You still need to choose a output color in the 'draw pixel' command to set/XOR the pasted color output.  IE the color chosen with the draw pixel/line/triangle/box/quad/ellipse command.  You cannot use an XOR color larger than the current number of colors on the paste bitmap side, otherwise, the output may get corrupted.

As for the 90 degree rotate, remember that the font is 16 pixels tall, not 8, so you need to shift the paste coordinates by 16 not 8.

Also, for your alternate font, don't forget to include an X increment table which has a different value for each character giving you proportional spacing.
« Last Edit: October 02, 2020, 11:43:01 pm by BrianHG »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7738
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1783 on: October 02, 2020, 11:03:02 pm »
I think there is a character in the font which is a 6x6 or 8x8 circle.  Use that character when drawing an outline of one of your triangles with blit enabled.  This should draw a thick outer border.

Just think, with the second tier Cyclone V, you could do this at 640x400 256 colors, or 640x480 at 16 colors with an additional shit load of space for quite a bit of blittable graphics.  Or, even double/triple buffered, or 3 playfield MAGGIE layers each at 320x240 at 256 colors, or all 8 layers at 16 colors, each with their own palette.  Or mix hardware font-tile layers with graphics layers and generate huge over-screen sized, multi-depth panoramic scrolling games.
« Last Edit: October 02, 2020, 11:16:19 pm by BrianHG »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7738
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1784 on: October 03, 2020, 07:16:49 am »
Ok, here is blitter V3, now with H&V zoom and shrink by floating point 'fractional' amounts.

Instructions:
Draw Command 0x09##.  The ## is a bit-field control.
Bit 0 = Set the source bitmap up-sample/zoom scale with regs x[0] and y[0].
Bit 1 = Set the paste bitmap down-sample/zoom scale with regs x[1] and y[1].

Since both settings use different regs, you may set both simultaneously by sending draw command 0x0903.

How to calculate a zoom:
Valid scale factor settings go from 1 through 2048.
Error values outside this range will default the setting back to 2048.

To enlarge the source bitmap, set the paste down sample to 2048.
The set the source up-sample using this ratio:
2048:(set x/y[0])

IE, if you want your image to be 1:1, then use a down sample setting of 2048 and an up sample setting of 2048.
If you want your image to be double size, 2:1, then use an up sample setting of 1024.
If you want your image to be 2.32992:1, then use an up sample setting of 879.

To shrink the destination bitmap, set the source up sample to 2048.
Then set the destination down-sample using this ratio:
(set x/y[1]):2048

If you want your pasted bitmap to be 1:1, then set the down sample setting to 2048.
If you want your image to be half size, IE 1:2, then use a down sample setting of 1024.
if you want your image to be 0.707:1, or, 1:1.41421, then use a down sample setting of 1448.  (See if you (Or anyone else here) could figure out why this magic down-sample figure is really important...)

You may mix different X&Y scale figures including zoom on X and shrink on Y, or, vice versa.
Note that the H&V center paste will not work properly with any zoom setting other than 1:1.
This is because to obtain the proper center offset based on the source width and height, we need to calculate the reciprocal of the source scale setting to determine the size of the final image which can give us the center offset of that image.  A reciprocal is long division and there is no more space in the current FPGA.

Remember you are dealing with paletted images, these scales are nearest neighbor only.  You need true-color and more gates if you want to generate a scaled image with bi-linear/bi-cubic filtering.  With the Cyclone V your switching to, you will have enough memory to do 320x240 16bit true color & with some big additions to the pixel writer, you could do anti-aliased rendering, both in blitter scale and with the geometry plotter.

You should also have enough gates in the Cyclone V to enable the other x/y[2&3] to define a quadrilateral shape which will render any perspective views of your source bitmap.  LOL, a Z80 will be able to do a 3D accelerated version of Doom I/II with this GPU.  Better than the original, though I wonder if the Z80 can keep up with the engine's 35fps.

Get the latest attached files...
« Last Edit: October 03, 2020, 07:36:18 am by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1785 on: October 03, 2020, 09:23:29 am »
Just think, with the second tier Cyclone V, you could do this at 640x400 256 colors, or 640x480 at 16 colors with an additional shit load of space for quite a bit of blittable graphics.  Or, even double/triple buffered, or 3 playfield MAGGIE layers each at 320x240 at 256 colors, or all 8 layers at 16 colors, each with their own palette.  Or mix hardware font-tile layers with graphics layers and generate huge over-screen sized, multi-depth panoramic scrolling games.

That's just too tempting. :o  I need to stop wasting my time with the EP4CE22 and get developing the Cyclone V, then.  I guess the only real difference in the design is the cost if I get it wrong.  :-//

Had a little time to play this morning, now have multi-line text cycling through the palette as you write.  Will test more later.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7738
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1786 on: October 03, 2020, 10:23:55 am »
Ok, I doubled the quality of the scaling.  It now scales in fractions of 4096 instead of 2048.
To disable the scaling, just set the scale registers to 0 and the blitter scaler will take that value and change it to 4096.  All other integers from 1 to 4095 will be use as the 4096:scale for enlarge and scale:4096 for shrink.

I now fully documented the source code geometry_xv_plotter.sv.  You can now make head and tails of it all.
The only thing left is ellipse.  Generating a center ellipse is not too difficult.  But, making one rotated at any angle will take a little thought on how to best implement it.  There is just enough space left in the EP4CE10 to make it just fit.
 
The following users thanked this post: nockieboy

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1787 on: October 03, 2020, 12:57:04 pm »
Hmm... seems blitting isn't working now?  I'm not getting the half-screen blit appearing at all, and character blits - if I'm lucky - I'm getting a single pixel.

Am I supposed to be turning the scaling off before blitting (didn't have to before this update) or is there a bug in the system?
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7738
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1788 on: October 03, 2020, 02:35:42 pm »
Hmm... seems blitting isn't working now?  I'm not getting the half-screen blit appearing at all, and character blits - if I'm lucky - I'm getting a single pixel.

Am I supposed to be turning the scaling off before blitting (didn't have to before this update) or is there a bug in the system?
Weird, are you sure you 'arent' using the scale feature and you never called draw command 0x09xx?
Go backward 1 version for now & I'll double check tonight.
Please leave me a copy of your blitt setup.

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1789 on: October 03, 2020, 07:00:41 pm »
Hmm... seems blitting isn't working now?  I'm not getting the half-screen blit appearing at all, and character blits - if I'm lucky - I'm getting a single pixel.

Am I supposed to be turning the scaling off before blitting (didn't have to before this update) or is there a bug in the system?
Weird, are you sure you 'arent' using the scale feature and you never called draw command 0x09xx?
Go backward 1 version for now & I'll double check tonight.
Please leave me a copy of your blitt setup.

No, no commands to 0x09xx are sent in the entire program.

Blit setup - note, this is pseudo-code - I haven't included code that specifies particular colours for the blit, or positions the blit according to row and column offsets. The code comments are intact, however:

Code: [Select]
; Set base memory address to start of font table ($0200)
Send command 0x8200H        ; set X[0] to 200
Send command 0x0C000H       ; set Y[0] to 0
Send command 0x7800H        ; set base memory address
; Set the source raster width to 8 pixels and 1 bit color depth
Send command 0x0A008H       ; set X[2] to 8
Send command 0x0E000H       ; set Y[2] to 0
Send command 0x7200H        ; set raster width to Y[2] pixels, 1 bpp
; Set the destination raster width to 320 pixels and 4 bit color depth
Send command 0x0A140H       ; set X[2] to 320
Send command 0x0E000H       ; set Y[2] to 0
Send command 0x7303H        ; set raster width to X[2] pixels, 4 bpp
; Set the blitter width and height to 8x16
Send command 0x0A007H       ; set X[2] to 7
Send command 0x0E00FH       ; set Y[2] to 15
Send command 0x7400H        ; set copy width/height to 8x16 pixels
; Turn on the blitter
Send command 0x0001H        ; Blitter enabled - blitter features are enabled in code not included, changing the 01 to 00-FF according to command-line parameters
; Keeping the source image offset X at 0, choose a character by
; setting the source offset Y to 16 x ASCII char #.
Send command 0x0A000H       ; set X[2] to 0
Send command 0x0E000H       ; set Y[2] to computed offset according to character to be displayed
Send command 0x7600H        ; set source image offset to Y[2]
; Blit character at screen coordinates (0 + offset),100
Send command 0x8000H        ; set X[0] to 0 + horizontal offset
Send command 0x0C064H       ; set Y[0] to 100 + vertical offset
Send command 0x010EH        ; blit single character
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7738
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1790 on: October 03, 2020, 07:20:54 pm »
Found the bug:



See the purple arrows, I was comparing the output coordinates, a 24 bit value with the screen maximum X&Y size coordinates which are a 12 bit value.  That IF() protects writes outside screen memory.  I was only supposed to compare the integer part, the upper 12 bits only.  So the paste coordinates were always outside the screen coordinates since the results were seen as being multiplied by 4096.  I guess pixel 0x0 made it through.



Also, I accidentally made the screen offset (red arrows) 24 bit, but they were only supposed to be an integer 12 bit number.

See, I make blunders as well.  I've attached the corrected code.
« Last Edit: October 03, 2020, 07:35:46 pm by BrianHG »
 
The following users thanked this post: nockieboy

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7738
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1791 on: October 03, 2020, 07:36:05 pm »
 |O Hang on, 1 more error...  See, the problem existed twice...  I've attached the fix...

« Last Edit: October 03, 2020, 07:40:08 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1792 on: October 03, 2020, 07:45:57 pm »
See, I make blunders as well.  I've attached the corrected code.

Not as many as I do.  ;)
« Last Edit: October 03, 2020, 07:52:11 pm by nockieboy »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1793 on: October 03, 2020, 08:00:31 pm »
Blitting all good again.  :-+
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7738
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1794 on: October 03, 2020, 09:11:27 pm »
Ok, here is a minor enhancement.  It should not affect your current work.  All it does is originally, when the blitter paste coordinates where outside the max_x&y allowable bitmap area, it would skip both copy and paste commands, but it would still cycle each process meaning each new coordinate in that copy and paste would still eat 2 clock cycles even though no commands where being sent to the pixel writer.
     The new enhancement will skip one of those clock cycles if the paste pixel coordinates would end up located outside the max_x&y allowable bitmap area making off screen blitter coordinates process through twice as fast.
     The outside screen coordinates still need to be counted in the blit since zooming bitmaps, or rotating the output by 45 degrees may land pixels off screen, but we still want to compute the relative offset and continue onto the next line which may still have pixels on valid screen coordinates.

     I've included the source and built project in case you arent achieving FMAX where I turned up the compiler fitter's effort level to achieve the FMAX.  (Arrrg, 5 minute compile time.)

     If the scale works, and it now seems to fully simulate properly, all we have left is to give the 2 linegens the ability to generate arcs / fixed radius bezier curves, where running the 2 linegens each twice for the 4 quadrants will generate a rounded quadrilateral, in other words, an ellipse.  For the filled quadrilateral, only the linegen drawing the hypotenuse will have the bezier curve.

Updates attached below...
« Last Edit: October 03, 2020, 11:48:28 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1795 on: October 03, 2020, 09:59:28 pm »
 :o Can you just clarify the scaling feature?  Is it just part of the blitter's rotate function, or is it an entirely separate function that can be used?  If so, how is it set?
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7738
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1796 on: October 03, 2020, 10:17:52 pm »
Ok, here is blitter V3, now with H&V zoom and shrink by floating point 'fractional' amounts.

Instructions:
Draw Command 0x09##.  The ## is a bit-field control.
Bit 0 = Set the source bitmap up-sample/zoom scale with regs x[0] and y[0].
Bit 1 = Set the paste bitmap down-sample/zoom scale with regs x[1] and y[1].

Since both settings use different regs, you may set both simultaneously by sending draw command 0x0903.

How to calculate a zoom:
Valid scale factor settings go from 1 through 2048.
Error values outside this range will default the setting back to 2048.

To enlarge the source bitmap, set the paste down sample to 2048.
The set the source up-sample using this ratio:
2048:(set x/y[0])

IE, if you want your image to be 1:1, then use a down sample setting of 2048 and an up sample setting of 2048.
If you want your image to be double size, 2:1, then use an up sample setting of 1024.
If you want your image to be 2.32992:1, then use an up sample setting of 879.

To shrink the destination bitmap, set the source up sample to 2048.
Then set the destination down-sample using this ratio:
(set x/y[1]):2048

If you want your pasted bitmap to be 1:1, then set the down sample setting to 2048.
If you want your image to be half size, IE 1:2, then use a down sample setting of 1024.
if you want your image to be 0.707:1, or, 1:1.41421, then use a down sample setting of 1448.  (See if you (Or anyone else here) could figure out why this magic down-sample figure is really important...)

You may mix different X&Y scale figures including zoom on X and shrink on Y, or, vice versa.
Note that the H&V center paste will not work properly with any zoom setting other than 1:1.
This is because to obtain the proper center offset based on the source width and height, we need to calculate the reciprocal of the source scale setting to determine the size of the final image which can give us the center offset of that image.  A reciprocal is long division and there is no more space in the current FPGA.

Remember you are dealing with paletted images, these scales are nearest neighbor only.  You need true-color and more gates if you want to generate a scaled image with bi-linear/bi-cubic filtering.  With the Cyclone V your switching to, you will have enough memory to do 320x240 16bit true color & with some big additions to the pixel writer, you could do anti-aliased rendering, both in blitter scale and with the geometry plotter.

You should also have enough gates in the Cyclone V to enable the other x/y[2&3] to define a quadrilateral shape which will render any perspective views of your source bitmap.  LOL, a Z80 will be able to do a 3D accelerated version of Doom I/II with this GPU.  Better than the original, though I wonder if the Z80 can keep up with the engine's 35fps.

Get the latest attached files...

Blitter copy stage.
Set x[0] to enlarge the width of the source during the copy.
Set y[0] to enlarge the height of the source during the copy.
0=off, 4095=little bigger, 4094=little bigger, 2731=50% bigger, 1.50x size, 2048 = 2x larger.

Blitter paste stage:
Set x[1] to shrink the width of the source (enlarged or not) being pasted.
Set y[1] to shrink the height of the source (enlarged or not) being pasted.
0=off, 4095=little smaller, 4094=little bit smaller, 3072=0.75x size, 2048 = 0.5x size.

Just set all 4 and use draw command 0x0903 to transfer the 4 values to the blitter.
These just scale the bitmaps.  If is completely separate of everything else.  All other rotate & flip functions work fine simultaneously.
Only the 'center paste' feature will not properly center the output on your draw pixel command when the scaling isn't set to off.

Let's see a video of you smoothly with smooth steps zooming a letter 'A' from a chosen font from the top left corner of the screen all the way up to a full screen image.
IE redrawing the 'A' from the font again and again while increasing the magnification from 1:1 all the way up to 12:1.
Or, maybe better looking, fix the magnification to 12:1 so the A is larger than full screen, but set the output shrink to divide the image down by 12:1, then slowly decrease that divide down factor down to 1:1 making it appear to zoom/enlarge.  (This takes more blitter clock cycles, but, you get far more refined scale steps when the image 12x large due to a multiply, then divide.  You may play with other ratios to get the zoom refinement you like which cutting down on blitter clock cycles, but, the blitter is so F--KEN fast, your Z80 would have to run 2700 such combo scales a second for it to over-run the blitter.  That's painting (8x16x12x12)=18432 pixels per blit while the pixel writer will do better than 50Million copy&paste combos per second in this instance.)

 |O (Shit, I just thought of a way to almost double this speed in the case where you zoom the source image...  With more than 2:1 on the source zoom, make that 50% faster, with a zoom of 10:1, make that almost 100% faster, IE 2x speed.  I wont bother tackling it until you confirmed the current code, the ellipse is done and if I have time since it will eat more gates.)
« Last Edit: October 04, 2020, 01:35:39 am by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1797 on: October 03, 2020, 10:25:57 pm »
Latest project working with no bugs I can see with basic testing. :-+  If I have time tomorrow, I'll try to push the blit testing further.

I've included the source and built project in case you arent achieving FMAX where I turned up the compiler fitter's effort level to achieve the FMAX.  (Arrrg, 5 minute compile time.)

Took 4m30secs to compile here - it's not the end of the world.  Gives me time to go make a mug of tea. ;) clk[0] Fmax is 125.47 MHz.

Is this expected, though (the next bit)?  I know you mentioned chequer-boarding earlier, so I'm just checking:

When I do a 45 degree rotation:



And the half-screen blit:



Ok, here is blitter V3, now with H&V zoom and shrink by floating point 'fractional' amounts.

Sorry, I must have completely missed that post!
« Last Edit: October 03, 2020, 10:30:29 pm by nockieboy »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7738
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1798 on: October 03, 2020, 10:47:18 pm »
See the 45 degree angle hatchet...
Also notice the letters are larger...

Remember my line: 0.707:1, or, 1:1.41421 ... (See if you (Or anyone else here) could figure out why this magic down-sample figure is really important...)

Remember this A2 + B2 = C2...

The checker board issue, the letters being larger, my fancy numbers, and that Pythagorean, and the right scaling settings can be setup to solve the 45 degree issue perfectly.
« Last Edit: October 03, 2020, 10:54:54 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1799 on: October 03, 2020, 10:52:03 pm »
See the 45 degree angle hatchet...
Also notice the letters are larger...

Remember my line: 0.707:1, or, 1:1.41421 ... (See if you (Or anyone else here) could figure out why this magic down-sample figure is really important...)

Remember this A2 + B2 = C2...

The checker board issue, the letters being larger, my fancy numbers, and that Pythagorean, and the right scaling settings can be setup to solve the 45 degree issue perfectly.

Ah, of course.. If the image being blitted has dimension AxB, when it's rotated 45 degrees its side A will be 1.41421 times longer due to good old Pythagoras and his squared hypotenuse.  Okay, no worries, I'll just need to downscale the blits by 0.707 to 1 to remove the chequer-boarding and make them less overweight.  ;)

Hitting the sack now - will hopefully have more time tomorrow.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf