Electronics > FPGA

FPGA VGA Controller for 8-bit computer

<< < (629/734) > >>

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. :palm:

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: ---     ​+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  ................
--- End code ---

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: ---     +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.

--- End code ---

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... |O

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?

Navigation

[0] Message Index

[#] Next page

[*] Previous page