FPGA VGA Controller for 8-bit computer

[nockieboy]

The tile font base address will not do anything for a few reasons.

Ah yes, for some reason I was thinking that tile mode was being used when I wrote my last post.

As for the 'TILE_MIF_FILE' and 'PAL_MIF_FILE', it is just that Altera will no accept the parameter string.  I have hard wired the 2 parameters to 'VGA_FONT_8x16_mono32.mif' and 'VGA_PALETTE_RGBA32.mif' inside the source code and you will find the source .mif files inside the 'BrianHG_DDR3_GFX_source_v16' source code folder.  If you will be editing these, be sure to keep backups as receiving new updates from me may overwrite your changes.

The uCOM is overwriting the TILE_MIF_FILE with its own font anyway (or should be - have yet to see if it's working properly with the new memory locations for tiles etc).

One thing I've noticed so far is that changing the opacity almost makes the blitted text look bold.  Interesting side effect, I suppose.

I just have to get scrolling working again - I've made a lot of changes to the code to allow scrolling to work with any screen mode,  now I need to spend some time finishing it off tomorrow; then it looks like the uCOM will be as functional (well, more so given all the extra functions the GPU has now) than previous versions.

[BrianHG]

One thing I've noticed so far is that changing the opacity almost makes the blitted text look bold.  Interesting side effect, I suppose.

Could it be a background color difference?
Remember, the palette's contents counts and there are translucency levels for each palette color.  Forcing the 'opacity' to 100% will forcefully ignore the values in the palette.
Could it be a foreground color difference?

Please upload an example RS232-debugger capture of the memory.  IE save it as a .bin file.

Also remember, layer 0 is the top.  Layer 3 is the bottom.  So, if you want a HW text/tile layer on top, you will need to move your current GFX bitmap based layer down a level or more and configure the text window above.

Also, with the alpha adjust set to 0, transparent colors will take on the 'BGC' rgb color settings seen here:

Code: [Select]

CMD_BGC_RGB[23:16] = hw_reg8[HWREG_BASE_ADDRESS+16'h001A]     ; // Global system 24 bit color background color for where no active window exists,
CMD_BGC_RGB[15: 8] = hw_reg8[HWREG_BASE_ADDRESS+16'h001B]     ; // or any pixels where all the layers are transparent all the way through the bottom layer.
CMD_BGC_RGB[ 7: 0] = hw_reg8[HWREG_BASE_ADDRESS+16'h001C]     ; //

[nockieboy]

One thing I've noticed so far is that changing the opacity almost makes the blitted text look bold.  Interesting side effect, I suppose.

Could it be a background color difference?
Remember, the palette's contents counts and there are translucency levels for each palette color.  Forcing the 'opacity' to 100% will forcefully ignore the values in the palette.
Could it be a foreground color difference?
...
Also remember, layer 0 is the top.  Layer 3 is the bottom.  So, if you want a HW text/tile layer on top, you will need to move your current GFX bitmap based layer down a level or more and configure the text window above.

I'm using a full graphics mode with 'manually'-blitted fonts like previously in layer 0, just mentioned this as an interesting side-effect more than a bug or anything.  I was adjusting the 'alpha adjust' value at HWREG_BASE_ADDRESS+5 when I noticed this effect - hadn't changed any individual transparency values in the palette.

As soon as I sort out scrolling, I'll look into this in more detail if you want and get you a debugger-capture etc, but I don't think it's a bug as I'm not using multiple layers (yet).

[BrianHG]

If you are using only 1 layer, anything transparent or semi-transparent still needs to go somewhere.  This is the BGC register.   Also, I want to see what you are seeing.  'bold' is weird as that might mean a horizontal pixel shift when my HDL internally runs it's pixel mixer which is how the SDI-layer mixing works.  I want to see if I have a bug, or what you see is just an illusion.  The debug capture will provide me a frozen picture of your screen.  Well, at least 1mb worth...

[nockieboy]

Okay, a couple of images for you.  The first is normal settings:



The second is with alpha (HW_REGS +5) set to 0x20 (you can just about make out a dark vertical line separating the 0's between each pair):



And this third one is with alpha set to 0 (no separating line between each pair of zeros at all - can't even see it with my own eyes, this isn't a trick of the camera):



The blurring effect appears to reach a maximum at 0x00, then dies off as I set the alpha from 0xFF towards 0x80, probably because it's becoming transparent and mixing with the black background as its transparency increases.  At 0x80, there's no text visible at all due to (I presume) 100% transparency.

I'll see if I can get the RS232 debugger set up later for the memory dump.

[BrianHG]

The question is:  Is there a different translucent white in between the 0's dots stored in ram due to the geometry pixel writer screwing up, or is it my new pixel mixer screwing up generating/inserting that translucent white?

You would need to read the DDR3 pixel values of the screen to tell.

It looks like a bug on my side.

[BrianHG]

@nockieboy, if hooking up the RS232 debugger is such a problem, why not write a Z80 program to write a 1 megabyte file of the GPU ram into a .bin file and upload that?

[nockieboy]

Uh, sorry for the lack of consistency, but I've been messing with the palette trying to work out why it's a bit messed up at switch-on.  The end result is that now I'm only seeing the blurring of characters when I do a memory dump and it can be seen on the column and row headers.

1MB debug memory dump attached, along with a picture of the screen so you can see what's in the video memory at the time the dump was taken.

Previously, the palette contents were corrupted (I'm still searching for the cause) with odd values - most of the palette entries had some form of transparency.  The palette is still corrupted now, but appears partially erased to zero with only a few colours alpha set to 0xFF.  I'll have this sorted soon, but for the moment it has affected the test results in that previously ALL the characters on the screen showed this blurring effect, whereas now it's only the column and row headers.

(The memory dump in the screenshot is of the start of palette RAM anyway, showing the existing palette entries in use on the screen).

[BrianHG]

For future reference: All you had to do in the RS232 debugger was hit 's' and choose a file name.

Ok, I got your image.

The bold letters are colors 0x03 and 0x09 while the thin letters are 0x03 and 0x00.

In the palette, you have colors:
0x00 = 0x000000FF    = Black, 100% opaque.
0x03 = 0x602020FF    = Burgundy, 100% opaque.
0x09 = 0x00000000    = 100% transparent. (Also black if forced to 100% opaque through the CMD_win_alpha_adj control.)

Ok, this is a bug with my mixer code.  When you have a transparent pixel, it is using the color value from the previous pixel.

The reason for this is that we have the SDI Layers set to 4, IE 0,1,2,3,0,1,2,3.  But the clock divider is set to 0x4, a sequential divider of 5 meaning you are trying to address 0,1,2,3,4,0,1,2,3,4.  Now this supposed to work, but my SDI mixer relies on blending previous pixels sequentially in a pipe and since I forgot to code for 'blank' layers when you have a divider set larger than the available set SDI_LAYERS parameter, it is using the last known processed pixel as that missing data for the '4' position, meaning the last shown pixel making this smear effect with transparent pixels.

Forcing the top layer 100% opaque masks out the bug, but now you are stuck with 1 layer.

The other fix is to change the video mode @0x011F from 0x74 to 0x73.  You will now have 75Hz 480p, but now my processor will only see layers 0,1,2,3,0,1,2,3 where there is no empty 4 slot for garbage to creep in.

I'll patch my code to properly mute out those empty slots so you may use any divider regardless of the SDI_LAYERS parameter setting.  For now, to get the right picture, just use the 75Hz 480p mode.

[BrianHG]

Ok, fixed.
Just replace the attached .sv file with the one in your 'BrianHG_DDR3_GFX_source_v16' folder.


Ok, I know this note is meaningless, but, what the hell...

Line 475 went from:

Code: [Select]

    lb_lena[1]  <= win_line_ena[lb_phase[0]] ;to:

Code: [Select]

    lb_lena[1]  <= win_line_ena[lb_phase[0]] && (lb_phase[0]<SDI_LAYERS) ; // Make sure to mute out video line when the lb_phase is outside the available SDI layers

My 'lb_lena' just stands for Line Buffer output Enable, the 'lb_phase' stands for line buffer phase divider position, the 'win_line_ena' goes high when an active window layer pixels are to be drawn, and we know what the SDI_LAYERS is.

[nockieboy]

Yep, that works nicely.

There doesn't seem to be a noticeable difference between alpha values of 0x00 and 0x7F, with the text maintaining (what appears to be) full brightness down to 0x00, but transparency increases noticeably from 0xFF down to 0x80.  Is that as expected?

[BrianHG]

Yep, that works nicely.

There doesn't seem to be a noticeable difference between alpha values of 0x00 and 0x7F, with the text maintaining (what appears to be) full brightness down to 0x00, but transparency increases noticeably from 0xFF down to 0x80.  Is that as expected?

Yes.  You are making layer 0 progressively transparent as you go from 0 to -128.  (Alpha adjust is a SIGNED 8 bit number.)
Try changing color 9 in your palette, but keep it transparent then play with the adjust and then see what happens.

Then, create a custom BGC settings and then see what happens with the alpha adj.

Also, shrink you output window to 640 pixels wide and see the results.

Try loading in the 32bit color 512x512 alpha image into video memory and open it on another window to see what happens.
Swap around the top and bottom layer with that image to see what happens.

[BrianHG]

Well?
Did my above tutorial help you understand the mechanics of the layers and alpha settings?

[nockieboy]

Yes, thank you.  Haven't had a lot of time and what I have had I've spent working on my graphics driver to get it to a state where I can change screen modes on the go.

Quick question based on a random idea that just popped into my head - if I was to set window[0] to a smaller size than the display dimensions and centre it, say with a 40-pixel border around the left/right/top/bottom and filling it with an opaque non-system-default background colour, would changing the system-default-background colour allow me to have a coloured border?  I guess I could change the colour randomly during data transfers to emulate the old 80's 'stripy coloured border' you used to get when loading from tape, etc...?

[BrianHG]

Follow my instructions above and you will see... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...

[nockieboy]

I seem to be struggling to get a window set up smaller than the display size.

Could you possibly give me an example so I know what settings I should be changing and where?

I've tried just changing the width of the window at the moment:

HWREG+0000H - Base address for layer 0 - haven't changed this.
HWREG+0004H - Screen BPP - kept this the same
HWREG+0005H - Alpha - kept the same at 0x7F
HWREG+0006H - Bitmap Width - This is just the byte width of the layer, right? Should be the same as layer width in 8bpp?
HWREG+0008H - Bitmap X offset - Set to zero. Not sure what this does?
HWREG+000AH - Bitmap Y offset - as above.
HWREG+000CH - Window X pos - should offset the window across the screen.
HWREG+000EH - Window Y pos - should offset the window down the screen.
HWREG+0010H - Window width - set to some figure less than screen width.
HWREG+0012H - Window height - as above.
HWREG+0016H - Tile/font base address - unchanged.
HWREG+001FH - Video mode - unchanged.

I'm getting some odd behaviour when I reduce the window width, and I just want to know that I'm setting it up properly before I start combing my code for bugs.  If I set the window width to >0280 but <02D0 (720 px, the full-width value), the left edge of the screen is repeated on the right.  Anything less than 0280 for window width causes screen corruption or no text to be visible at all.  I'm probably misunderstanding a setting somewhere, or getting the Endianness of a value the wrong way around, but I just want to confirm that I'm at least trying to do the right thing.

[BrianHG]

I seem to be struggling to get a window set up smaller than the display size.

Could you possibly give me an example so I know what settings I should be changing and where?

I've tried just changing the width of the window at the moment:

HWREG+0000H - Base address for layer 0 - haven't changed this.
HWREG+0004H - Screen BPP - kept this the same
HWREG+0005H - Alpha - kept the same at 0x7F
HWREG+0006H - Bitmap Width - This is just the byte width of the layer, right? Should be the same as layer width in 8bpp?
HWREG+0008H - Bitmap X offset - Set to zero. Not sure what this does?
HWREG+000AH - Bitmap Y offset - as above.
HWREG+000CH - Window X pos - should offset the window across the screen.
HWREG+000EH - Window Y pos - should offset the window down the screen.
HWREG+0010H - Window width - set to some figure less than screen width.
HWREG+0012H - Window height - as above.
HWREG+0016H - Tile/font base address - unchanged.
HWREG+001FH - Video mode - unchanged.

I'm getting some odd behaviour when I reduce the window width, and I just want to know that I'm setting it up properly before I start combing my code for bugs.  If I set the window width to >0280 but <02D0 (720 px, the full-width value), the left edge of the screen is repeated on the right.  Anything less than 0280 for window width causes screen corruption or no text to be visible at all.  I'm probably misunderstanding a setting somewhere, or getting the Endianness of a value the wrong way around, but I just want to confirm that I'm at least trying to do the right thing.

How in heavens name it is difficult to just shrink these 2:
HWREG+0010H - Window width - set to some figure less than screen width.
HWREG+0012H - Window height - as above.
These need to fit within the screen width / height as well as be less than or equal to the bitmap width/height.  Otherwise you will see extra junk.  THEY ARE NOT ENDING COORDINATES, THEY ARE WIDTH AND HEIGHT.  0,0 means no window. 1,1 means a window 1 pixel wide by 1 pixel tall.  40,40 means a window 40 pixels wide by 40 pixels tall, regardless of the window's beginning screen offset X&Y coordinates.

HWREG+0006H - Bitmap Width - This is just the byte width of the layer, right? Should be the same as layer width in 8bpp?
No, this is the number of pixels wide your bitmap is in memory.  If the bitmap has 720 pixels, then you make this 720.  If the bitmap is 640 pixels wide, then make this 640.  If the bitmap is 22450 pixels wide, then you make this 22450.

[BrianHG]

HWREG+0008H - Bitmap X offset - Set to zero. Not sure what this does?
HWREG+000AH - Bitmap Y offset - as above.

If you have a bitmap in ram that is 18000x20000 and you want to show the center, or top left, or bottom right of that bitmap on the screen which is only 720x480, how to you expect to set that display position?

[BrianHG]

Like my debugger where I only need to click on a value and hold down the +/- keys on the numpad to scroll the 16 bit contents, you need to make yourself a window playing utility on your Z80 to you may play with the values in a controllable smooth animated fashion so you may see of the window system reacts and operates.

[BrianHG]

The only byte controls are the HWREG+0000H - Base address for layer 0 and tile base address.
Every single other control deals with quantity of pixels.
It no longer matters what you have chosen for pixel bpp depth.  My new window system internally works out where to look in ram to retrieve / address the correct memory to draw the image.  You just place in the coordinates / width and height sizes.

Even when using tile mode, the bitmap offset will figure out partial scrolling inside each tile to begin the display when you set the bitmap offset.  Your Z80 no longer needs to do any math.  It just needs to concern itself with a 16bit X&Y coordinate.

This is no longer a piece of code designed to squish into a small portion of a 6k logic gate FPGA.  It is now designed to eat up ~8k logic gates just to operate the windows all on it's own besides the additional requirements for layer mixing and huge tile-ram, then everything else for geometry and DDR3 processing.

[nockieboy]

Thank you - I just needed to know I was on the right track, and indeed I was - it was an Endianness issue.  Have a nice 20-pixel border all around the screen now.

If I'm not too busy tomorrow, I'll get a 'BORDER' command created so I can change the border colour easily in the DMI and try out some colourful borders when I paste data in via the serial console.

Increasing transparency on layer 0 produces a nice 'fade to red' (or whatever the global background colour is set to) effect.

[BrianHG]

Hun?  Didn't I ensure it was set to 'Little Endian'?

You can also try using 720p or 1080p with a H&V 'zoom/scale' setting for the window if you want sharper text.

[nockieboy]

Hun?  Didn't I ensure it was set to 'Little Endian'?

That could be another issue then.  As you can see from the screenshot showing the HW_REGS with the red border in my previous post, all the 16-bit registers (and the 32-bit one) are Big Endian.

You can also try using 720p or 1080p with a H&V 'zoom/scale' setting for the window if you want sharper text.

I'm working my way up to 720p and 1080p modes next.  Just making my graphics driver 'multi-mode', then I'll give this a try!

[BrianHG]

Hun?  Didn't I ensure it was set to 'Little Endian'?

That could be another issue then.  As you can see from the screenshot showing the HW_REGS with the red border in my previous post, all the 16-bit registers (and the 32-bit one) are Big Endian.

That would be a bug in the HW_REGS module, 32bit output assignment.
But, are you sure?
All the 16bit window regs have the MSB to the left (even addr ending in 0) and the LSB to the right (+1 addr).
This is the same with that window address reg, the MSB is on the left (even 0 addr)  and the LSB is on the right (+3 addr)...

[nockieboy]

Hun?  Didn't I ensure it was set to 'Little Endian'?

That could be another issue then.  As you can see from the screenshot showing the HW_REGS with the red border in my previous post, all the 16-bit registers (and the 32-bit one) are Big Endian.

That would be a bug in the HW_REGS module, 32bit output assignment.
But, are you sure?
All the 16bit window regs have the MSB to the left (even addr ending in 0) and the LSB to the right (+1 addr).
This is the same with that window address reg, the MSB is on the left (even 0 addr)  and the LSB is on the right (+3 addr)...

Yes, they're all Big Endian.  Up until your recent post reminding me of the endianness option, I'd just worked around the issue.

Code: [Select]

                ADDR  ADDR+1
Big Endian    = MSB,  LSB
Little Endian = LSB,  MSB


Code: [Select]

line 26 parameter string     ENDIAN                  = "Little",            // Endian for 8bit addressing access.
As you can see, ENDIAN is set to "Little" in the GPU_DECA_DDR3_top.sv file.  I can't test the "Big" setting just now, but I'm wondering if you've got them the wrong way around, maybe?