FPGA VGA Controller for 8-bit computer

[BrianHG]

It sounds like all the endianess is all backwards.
Try swapping to 'Big' in the 'xxx_top' file.

If this fixes the problem, there are 2 places in the code to fix.  1 in the HW_REGS source and 1 in my line buffer.

Also, now my RS232 debugger's '+/-' key to inc/dec 16bit values will be f'ed up.

In HW_REGS.sv, lines 46 to 51, all the "B"s should change into "L"s.

and in 'BrianHG_GFX_Video_Line_Buffer.sv.', line 631,,,  Wait, I think I got that one right.  You will find out when writing 16bit text in tile mode.

[BrianHG]

Just in case... Update the attached file.
The endianess is now correct.

Now I need to fix my RS232 debugger....

[nockieboy]

I'll get that tested shortly - will need to remove some register-swapping code in my graphics driver too now; that'll be like pulling at a loose thread, but it'll make the code more streamlined.

Compile time is just under 4 minutes now.

[nockieboy]

Now I'm confused.  Did you just change the ENDIAN value to "Big" in that file to test whether that is the issue?  The HWREGS in memory are now in Little Endian format.

I've reversed the byte order on lines 46-51 in HW_Regs.sv, so the ENDIAN setting now matches the byte order of the HW_REGS values.

[BrianHG]

Now I'm confused.  Did you just change the ENDIAN value to "Big" in that file to test whether that is the issue?  The HWREGS in memory are now in Little Endian format.

I've reversed the byte order on lines 46-51 in HW_Regs.sv, so the ENDIAN setting now matches the byte order of the HW_REGS values.

Now I'm confused.  Did you just un-do the change I made which fixed the endian issue?
Yes, yes you did.
I reversed the ENDIAN's direction by changing the "B" to an "L" and you flipped the numbers around putting everything back to what it would be if you had the "B" in the 'IF'...

[nockieboy]

Now I'm confused.  Did you just un-do the change I made which fixed the endian issue?

 

Yes, probably.

EDIT: Working fine with ENDIAN set to 'Little'.

[BrianHG]

Here is the new RS232 debugger.
You can now swap endians so that editing with the +/- key will show and change the right memory cells in 16 bit.

Also, the endian swap will also affect the Quartus Save .mif file for 16bit and the new save Quartus 32bit .mif file.  This is usefull when generating a palette and tile .mif files which are 32bit .mif.

[BrianHG]

Now I'm confused.  Did you just un-do the change I made which fixed the endian issue?

 

Yes, probably.

Destroy your linked file so no one downloads it by mistake.

[nockieboy]

All done, working perfectly now.  Tidying up the GPU driver's init code nicely too without having to swap byte-order for the HWREGS.

[BrianHG]

EDIT: Working fine with ENDIAN set to 'Little'.

Just so you know, that 'ENDIAN' = "Little" parameter is set at the top of your 'GPU_DECA_DDR3_top.sv' on line 26.  Not inside the 'HW_Regs.sv' source file line 14 which is nothing more than a default value if it is not set elsewhere.

[nockieboy]

EDIT: Working fine with ENDIAN set to 'Little'.

Just so you know, that 'ENDIAN' = "Little" parameter is set at the top of your 'GPU_DECA_DDR3_top.sv' on line 26.  Not inside the 'HW_Regs.sv' source file line 14 which is nothing more than a default value if it is not set elsewhere.

Yeah, I know that, but it's been a long day.

[nockieboy]

1080p @ 60Hz with a 680x440 window scaled to 2x size.

I can now swap between 480p, 720p and 1080p with a single command in the DMI.  Have some work to do with getting the driver to recognise window width when it comes to text blitting, but that won't take long.

[nockieboy]

Took longer than expected this morning, but here's a flashy border linked to the serial interface:



Just have a couple of bugs in changing screen modes, but hopefully will get them sorted early this week.

[BrianHG]

You are lucky I didn't decide to latch all the window controls once every V-sync.

[nockieboy]

You are lucky I didn't decide to latch all the window controls once every V-sync.

I sure am.

What's next on the list?

[BrianHG]

Next you are getting 16-32 layers, a set or regs which will allow yo to swap layer priority, IE which layer is on top of any other layer, and a new block diagram documenting/illustrating my VGA system.

You will need to show me mastery of my system.

IE: Did you get the color tile/text mode working yet?

[nockieboy]

Haven't tried tile mode yet - will need to write a (or re-write the) driver in a CP/M test program for this.  This will take a little time and I'm not blessed with big blocks of spare time at the moment like I was last year.  I'm going to get the issues I'm experiencing with mode-changing in the DMI sorted, then I'll make a start on a tile mode demo/test program in CP/M.

[nockieboy]

I've been trying to sort his one bug for the last couple of days and I thought I had it yesterday, but it's back again today.

Under what circumstances would the GPU blit font tiles with the background bits transparent, despite alpha being 0x7F?

I've got the HWREGS alpha adjust set to 0x7F.  In fact, here's a dump of the HWREGS:

Code: [Select]

     ​+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
C100 00 50 00 00 83 7F A8 02 00 00 00 00 14 00 14 00  .P..............
C110 A8 02 B8 01 00 00 00 00 00 00 00 00 00 00 00 74  ...............t
C120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Text is appearing okay, until I backspace and try to overwrite text where it becomes obvious the text is being blitted with background pixels (entry 0 on the palette below) being treated as if they're transparent, so a mess is created as the characters are overdrawn.

Any text blitted with a different colour background selected, like the column and row headers in the screen dumps, appear with a transparent black background.

If I change the background colour, there is no change with the next line of text I write (the background colour is still being treated as transparent) - until I do a CLS, which uses GEOFF to clear the screen to background colour, when the background obviously becomes the colour I've selected.

The worst thing is, it seems to come and go.  I removed the routine that copies the font data from ROM to the GPU when the DMI starts up and the problem cleared up yesterday - so I thought I'd fixed it, although I didn't understand the issue.  Today, with no further code changes, the problem is back again.

Here's the palette:

Code: [Select]

     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
D000 00 00 00 FF 80 00 00 FF FF 00 00 FF 00 00 80 FF  ................
D010 FF 9D 00 FF 80 00 80 FF FE 99 99 FF 00 00 FF FF  ................
D020 A1 42 FF FF 00 40 00 FF C0 C0 C0 FF 6C 6C 6C FF  .B...@......lll.
D030 80 80 00 FF 00 80 80 FF E0 B0 FF FF 00 FF 00 FF  ................
D040 7A 87 FE FF 9F 62 00 FF 67 40 00 FF 00 5B 67 FF  z....b..g@...[g.
D050 FF FF 00 FF FF FF FF FF 52 9E 6B BF C2 DC D5 3F  ........R.k....?
D060 08 DB 56 C0 46 5E 98 F5 44 64 FA D1 A3 50 7E 59  ..V.F^..Dd...P~Y
D070 52 4B EC B4 FF DC FD 6E A5 7C 1D 3A BE 7C 30 59  RK.....n.|.:.|0Y
D080 97 DF 9E F3 3C 5F 2E 97 5F 19 95 7E AE EE 63 2B  ....<_.._..~..c+
D090 7F 11 7F C9 CD 59 F5 F1 4D 32 95 3D 18 FF 9F 3D  .....Y..M2.=...=
D0A0 49 27 B1 B6 6B 53 C5 53 DE DB FC 7B EC FC 70 57  I'..kS.S...{..pW
D0B0 E4 B7 88 06 7E EF CC FE 96 3E 6E C9 24 5B 05 03  ....~....>n.$[..
D0C0 FA 6B C7 5D 76 DF E5 17 84 5F 67 77 7C 01 A0 2A  .k.]v...._gw|..*
D0D0 FE 72 D4 2E 3B 49 75 AE 23 F8 33 34 5A 69 64 57  .r..;Iu.#.34ZidW
D0E0 D1 DB FE 92 6B CD C4 C1 9F 0B 5E 46 EE F5 CB A6  ....k.....^F....
D0F0 CD BA 39 2A DD 79 9F 14 2E FD 06 7F CD E5 4D DB  ..9*.y........M.

Is there anything else other than blitter mode (which blits text in mode 3 - i.e. activated with PM enabled) or the alpha adjust value that could cause this?  Neither the blitter mode, text blitting code or alpha adjust have been touched since this problem started, went away again and started again this morning...

[BrianHG]

     Blitting does not look at the palette.  That blitter's 'transparent' color only has to do with the blitter settings in the geometry settings.  In fact, the blitter can only choose to paint or omit the painting of a pixel based on the source pixel data and the chosen 'xor' reference stencil out color.  Have your tried turning off the blitter's transparency stencil so it plots every pixel when painting the background color?  You should be looking at the screen picture buffer data, not the palette.

     The alpha and transparency in the palette entries only affects how the onscreen picture color data is presented between the current window layer all the previous layers below it.  It has nothing to do with drawing pixels on the screen.

[BrianHG]

Well?

[nockieboy]

Funnily enough I've just sat down to spend some time on this issue - I haven't had a chance to look into it up til now.

[nockieboy]

Fixed it.   It was a 'minor' tweak to the DMI setup code I'd made at some point last week, causing the text transparency flag to not be reset at bootup, so it had a random value which caused the inconsistent nature of the bug. 

[BrianHG]

  Ok, here we go, 16 layers...

GPU_DECA_DDR3_version_16_Jan_20_2021.zip = 16 layers.

Parameters...
PDI_LAYERS     = 4
SDI_LAYERS     = 4

This means that the layers 0 through 15 =
PDI layer 0 -> SDI 0,1,2,3 = Layer 0,1,2,3
PDI layer 1 -> SDI 0,1,2,3 = Layer 4,5,6,7
PDI layer 2 -> SDI 0,1,2,3 = Layer 8,9,10,11
PDI layer 3 -> SDI 0,1,2,3 = Layer 12,13,14,15.

Note that to save on blockram resources, the TILE/FONT mode & memory is only available for PDI_LAYER 0.  This means the tile/font mode is only functional on layers 0,1,2&3.  The available ram for the font is set to 65536 bytes.  This means a 256 character 16x16 pixel font with 8bpp, IE 256 colors per pixel font is possible.

Remember, the 'CLK_DIVIDER' must be at least =3 to have all SDI layers 0,1,2,&3 functional.

IE, if the 'CLK_DIVIDER' = 1, (needed for 720p@60hz, or 1080p@30hz) then only SDI layers 0&1 will function meaning only layers 0,1,4,5,8,9,12,&13 are functional.  That's 8 functional window layers.

IE, if the 'CLK_DIVIDER' = 0, (needed for 1080p@60hz) then only SDI layer 0 will function meaning only layers 0,4,8,12 are functional.  That's 4 functional window layers.

Do not forget to disable any unused layers as they will still eat DDR3 bandwidth, especially in 1080p@60hz as that mode eats a ton of DDR3 bandwidth.  Even if the SDI layer arent functional, my controller will still try to do the DDR3 reading for those unseen SDI layers, but at full speed wasting bandwidth and potentially corrupting the display's line buffer.

The new layer swapping controls are at address 0x00F0 through 0x00FF.  These controls allows you to quick swap which layers sit on top of each other allowing you to move which window appears in front of one another.  This means you can also move a tile enabled layer in the 0,1,2,&3 to a different position in the window stack.  Documentation is coming.

Note that by default, layer 15 is the bottom window layer, layer 0 is the top window layer.  Only the BGC color setting is below layer 15 and it cannot be swapped anywhere above like all other windows 0 through 15.

You may take a look at the Debugger_test_bin_files.zip file and load the 14 layer bobafet example,and play with the swap controls in the RS232 debugger to see how you can swap which window sits in front of another.

Things left to do:
1. Fix a bug in my DDR3 controller to allow bug free support for 'Quarter Rate' mode to allow 400MHz DDR3 support fixing the current red timing report.
2. Have Nockieboy do something interesting with all 16 layers.
3. Add a hardware pixel collision detector between window layers.

[BrianHG]

Ooops, found a bug in the 'BrianHG_GFX_Layer_mixer.sv' when swapping SDI_LAYERS.  It can potentially kill the video.  Please download this patch and update the file in your 'BrianHG_DDR3_GFX_source_v16' folder.

[nockieboy]

No major issues that I can detect so far.