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

0 Members and 3 Guests are viewing this topic.

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #575 on: December 06, 2019, 10:50:33 am »
I've just spent far too long trying to find a program online that will output a file of 565 hex values for a 256-colour palette.  :palm:

Here's my 32-colour text/sprite palette.  I've just based it off of the old Amstrad palette for the moment, there's obviously lots of room in the .mif for more palettes and the potential to swap palette LUTs on the fly, I'm guessing.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7747
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #576 on: December 06, 2019, 11:16:56 am »
Sprite mode is 4444, 4A, 4R, 4G, 4B.  The 565 is the 256 color mode.  Instead of throwing something together, I would do the conversion in something like MS Excel.

Also, I noticed that 0 is black, ok, but color 1 is dark blue?
ok.

Better, here is a source code generator where you can calculate any output you like. 
https://github.com/canidlogic/vgapal

Code: [Select]
palette=(
000000 0000AA 00AA00 00AAAA AA0000 AA00AA AA5500 AAAAAA 555555 5555FF
55FF55 55FFFF FF5555 FF55FF FFFF55 FFFFFF 000000 101010 202020 353535
454545 555555 656565 757575 8A8A8A 9A9A9A AAAAAA BABABA CACACA DFDFDF
EFEFEF FFFFFF 0000FF 4100FF 8200FF BE00FF FF00FF FF00BE FF0082 FF0041
FF0000 FF4100 FF8200 FFBE00 FFFF00 BEFF00 82FF00 41FF00 00FF00 00FF41
00FF82 00FFBE 00FFFF 00BEFF 0082FF 0041FF 8282FF 9E82FF BE82FF DF82FF
FF82FF FF82DF FF82BE FF829E FF8282 FF9E82 FFBE82 FFDF82 FFFF82 DFFF82
BEFF82 9EFF82 82FF82 82FF9E 82FFBE 82FFDF 82FFFF 82DFFF 82BEFF 829EFF
BABAFF CABAFF DFBAFF EFBAFF FFBAFF FFBAEF FFBADF FFBACA FFBABA FFCABA
FFDFBA FFEFBA FFFFBA EFFFBA DFFFBA CAFFBA BAFFBA BAFFCA BAFFDF BAFFEF
BAFFFF BAEFFF BADFFF BACAFF 000071 1C0071 390071 550071 710071 710055
710039 71001C 710000 711C00 713900 715500 717100 557100 397100 1C7100
007100 00711C 007139 007155 007171 005571 003971 001C71 393971 453971
553971 613971 713971 713961 713955 713945 713939 714539 715539 716139
717139 617139 557139 457139 397139 397145 397155 397161 397171 396171
395571 394571 515171 595171 615171 695171 715171 715169 715161 715159
715151 715951 716151 716951 717151 697151 617151 597151 517151 517159
517161 517169 517171 516971 516171 515971 000041 100041 200041 310041
410041 410031 410020 410010 410000 411000 412000 413100 414100 314100
204100 104100 004100 004110 004120 004131 004141 003141 002041 001041
202041 282041 312041 392041 412041 412039 412031 412028 412020 412820
413120 413920 414120 394120 314120 284120 204120 204128 204131 204139
204141 203941 203141 202841 2D2D41 312D41 352D41 3D2D41 412D41 412D3D
412D35 412D31 412D2D 41312D 41352D 413D2D 41412D 3D412D 35412D 31412D
2D412D 2D4131 2D4135 2D413D 2D4141 2D3D41 2D3541 2D3141 000000 000000
000000 000000 000000 000000 000000 000000
)



Now, I'm sure you can output this into 565 and 4444.  Remember, the 4444 is for the text and sprites while the 565 is for the graphics layer.

For the text layer palette, we want to copy the first 16 into the second 16 colors, unless we change a wire in the 'bitplane_to_raster' module.
« Last Edit: December 06, 2019, 11:22:26 am by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #577 on: December 06, 2019, 11:52:41 am »
Sprite mode is 4444, 4A, 4R, 4G, 4B.  The 565 is the 256 color mode.  Instead of throwing something together, I would do the conversion in something like MS Excel.

Also, I noticed that 0 is black, ok, but color 1 is dark blue?

Like I said, I'd based the palette off of the old Amstrad 27-colour palette.  Just realised, might have confused you with the naming of the palette .mif file.  It's the text/sprite palette, but I just called it 'sprite' palette for brevity (I guess the text could be considered sprites in their own way).

So, just to clarify, the text palette is just 32 colours (two copies of 16, essentially)?  Is the sprite palette the same thing, or a separate palette after the text palette?

Better, here is a source code generator where you can calculate any output you like. 
https://github.com/canidlogic/vgapal

I did find that code during my searching, but disregarded it as I felt it needed a few hours development to turn into what I needed.  ???
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7747
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #578 on: December 06, 2019, 12:12:08 pm »
Sprite mode is 4444, 4A, 4R, 4G, 4B.  The 565 is the 256 color mode.  Instead of throwing something together, I would do the conversion in something like MS Excel.

Also, I noticed that 0 is black, ok, but color 1 is dark blue?

Like I said, I'd based the palette off of the old Amstrad 27-colour palette.  Just realised, might have confused you with the naming of the palette .mif file.  It's the text/sprite palette, but I just called it 'sprite' palette for brevity (I guess the text could be considered sprites in their own way).

So, just to clarify, the text palette is just 32 colours (two copies of 16, essentially)?  Is the sprite palette the same thing, or a separate palette after the text palette?

Better, here is a source code generator where you can calculate any output you like. 
https://github.com/canidlogic/vgapal

I did find that code during my searching, but disregarded it as I felt it needed a few hours development to turn into what I needed.  ???
Again:
Code: [Select]
palette=(
000000 0000AA 00AA00 00AAAA AA0000 AA00AA AA5500 AAAAAA 555555 5555FF
55FF55 55FFFF FF5555 FF55FF FFFF55 FFFFFF 000000 101010 202020 353535
454545 555555 656565 757575 8A8A8A 9A9A9A AAAAAA BABABA CACACA DFDFDF
EFEFEF FFFFFF 0000FF 4100FF 8200FF BE00FF FF00FF FF00BE FF0082 FF0041
FF0000 FF4100 FF8200 FFBE00 FFFF00 BEFF00 82FF00 41FF00 00FF00 00FF41
00FF82 00FFBE 00FFFF 00BEFF 0082FF 0041FF 8282FF 9E82FF BE82FF DF82FF
FF82FF FF82DF FF82BE FF829E FF8282 FF9E82 FFBE82 FFDF82 FFFF82 DFFF82
BEFF82 9EFF82 82FF82 82FF9E 82FFBE 82FFDF 82FFFF 82DFFF 82BEFF 829EFF
BABAFF CABAFF DFBAFF EFBAFF FFBAFF FFBAEF FFBADF FFBACA FFBABA FFCABA
FFDFBA FFEFBA FFFFBA EFFFBA DFFFBA CAFFBA BAFFBA BAFFCA BAFFDF BAFFEF
BAFFFF BAEFFF BADFFF BACAFF 000071 1C0071 390071 550071 710071 710055
710039 71001C 710000 711C00 713900 715500 717100 557100 397100 1C7100
007100 00711C 007139 007155 007171 005571 003971 001C71 393971 453971
553971 613971 713971 713961 713955 713945 713939 714539 715539 716139
717139 617139 557139 457139 397139 397145 397155 397161 397171 396171
395571 394571 515171 595171 615171 695171 715171 715169 715161 715159
715151 715951 716151 716951 717151 697151 617151 597151 517151 517159
517161 517169 517171 516971 516171 515971 000041 100041 200041 310041
410041 410031 410020 410010 410000 411000 412000 413100 414100 314100
204100 104100 004100 004110 004120 004131 004141 003141 002041 001041
202041 282041 312041 392041 412041 412039 412031 412028 412020 412820
413120 413920 414120 394120 314120 284120 204120 204128 204131 204139
204141 203941 203141 202841 2D2D41 312D41 352D41 3D2D41 412D41 412D3D
412D35 412D31 412D2D 41312D 41352D 413D2D 41412D 3D412D 35412D 31412D
2D412D 2D4131 2D4135 2D413D 2D4141 2D3D41 2D3541 2D3141 000000 000000
000000 000000 000000 000000 000000 000000
)

How hard is it to separate the RGB 8 bit values, divide by 16 on this source data, then multiply by 1,16,256 and add the sum?
Or in the case of the graphics palette,divide by 8 for red and blue, divide by 4 for green, then multiply by 1,32,2048 and add the sum?

Bit shifting would also work...

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #579 on: December 06, 2019, 01:58:17 pm »
Does this look right for RGB565?

Code: [Select]
0000 0015 0540 0555 A800 A815 AAA0 AD55 52AA 52BF 57EA 57FF FAAA FABF FFEA FFFF
0000 1082 2104 31A6 4228 52AA 632C 73AE 8C51 9CD3 AD55 BDD7 CE59 DEFB EF7D FFFF
001F 401F 801F B81F F81F F817 F810 F808 F800 FA00 FC00 FDE0 FFE0 BFE0 87E0 47E0
07E0 07E8 07F0 07F7 07FF 05FF 041F 021F 841F 9C1F BC1F DC1F FC1F FC1B FC17 FC13
FC10 FCF0 FDF0 FEF0 FFF0 DFF0 BFF0 9FF0 87F0 87F3 87F7 87FB 87FF 86FF 85FF 84FF
BDDF CDDF DDDF EDDF FDDF FDDD FDDB FDD9 FDD7 FE57 FEF7 FF77 FFF7 EFF7 DFF7 CFF7
BFF7 BFF9 BFFB BFFD BFFF BF7F BEFF BE5F 000E 180E 380E 500E 700E 700A 7007 7003
7000 70E0 71C0 72A0 7380 5380 3B80 1B80 0380 0383 0387 038A 038E 02AE 01CE 00EE
39CE 41CE 51CE 61CE 71CE 71CC 71CA 71C8 71C7 7227 72A7 7307 7387 6387 5387 4387
3B87 3B88 3B8A 3B8C 3B8E 3B0E 3AAE 3A2E 528E 5A8E 628E 6A8E 728E 728D 728C 728B
728A 72CA 730A 734A 738A 6B8A 638A 5B8A 538A 538B 538C 538D 538E 534E 530E 52CE
0008 1008 2008 3008 4008 4006 4004 4002 4000 4080 4100 4180 4200 3200 2200 1200
0200 0202 0204 0206 0208 0188 0108 0088 2108 2908 3108 3908 4108 4107 4106 4105
4104 4144 4184 41C4 4204 3A04 3204 2A04 2204 2205 2206 2207 2208 21C8 2188 2148
2968 3168 3168 3968 4168 4167 4166 4166 4165 4185 41A5 41E5 4205 3A05 3205 3205
2A05 2A06 2A06 2A07 2A08 29E8 29A8 2988 0000 0000 0000 0000 0000 0000 0000 0000
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7747
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #580 on: December 06, 2019, 02:55:22 pm »
If I've done my math right, the first 5 should read:

0000 0015 0560 0575 A800

Remember the green is /4, not divide by /8 since the green retains 6 of 8 bits, not 5 of 8 bits like the red and blue.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #581 on: December 06, 2019, 04:09:01 pm »
Probably because I'm just dropping the least-significant bits - this is my code to reduce from 3 bytes to 2 (C#):

Code: [Select]
rgb_out[1] = (rgb[0] & 0xF8) | (rgb[1] >> 5);
rgb_out[0] = ((rgb[1] & 0x1C) << 3) | (rgb[2] >> 3);

rgb[0] is red, [1] is green, [2] is blue.  rgb_out is an array, rgb_out[1] is MSB, rgb_out[0] is LSB.  They are output like this:

Code: [Select]
String.Format("{0:X2}", rgb_out[1]) + String.Format("{0:X2}", rgb_out[0]) + " ";
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7747
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #582 on: December 06, 2019, 06:23:57 pm »
Probably because I'm just dropping the least-significant bits - this is my code to reduce from 3 bytes to 2 (C#):

Code: [Select]
rgb_out[1] = (rgb[0] & 0xF8) | (rgb[1] >> 5);
rgb_out[0] = ((rgb[1] & 0x1C) << 3) | (rgb[2] >> 3);

rgb[0] is red, [1] is green, [2] is blue.  rgb_out is an array, rgb_out[1] is MSB, rgb_out[0] is LSB.  They are output like this:

Code: [Select]
String.Format("{0:X2}", rgb_out[1]) + String.Format("{0:X2}", rgb_out[0]) + " ";
:palm: Yup, your color codes are correct...
Just do the 4444 as well.  That one is hard to mess up...
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #583 on: December 06, 2019, 06:28:39 pm »
 ;) Okay, this is the output for RGB4444:

Code: [Select]
-- PALConverter-generated Memory Initialisation File (.mif)
-- For use with Quartus II & Quartus Prime.
-- Generated at: 06/12/2019 18:28:05

WIDTH=16;
DEPTH=256;

ADDRESS_RADIX=HEX;
DATA_RADIX=HEX;

CONTENT BEGIN
    000  :   0000;
    001  :   000A;
    002  :   00A0;
    003  :   00AA;
    004  :   0A00;
    005  :   0A0A;
    006  :   0A50;
    007  :   0AAA;
    008  :   0555;
    009  :   055F;
    00A  :   05F5;
    00B  :   05FF;
    00C  :   0F55;
    00D  :   0F5F;
    00E  :   0FF5;
    00F  :   0FFF;
    010  :   0000;
    011  :   0111;
    012  :   0222;
    013  :   0333;
    014  :   0444;
    015  :   0555;
    016  :   0666;
    017  :   0777;
    018  :   0888;
    019  :   0999;
    01A  :   0AAA;
    01B  :   0BBB;
    01C  :   0CCC;
    01D  :   0DDD;
    01E  :   0EEE;
    01F  :   0FFF;
    020  :   000F;
    021  :   040F;
    022  :   080F;
    023  :   0B0F;
    024  :   0F0F;
    025  :   0F0B;
    026  :   0F08;
    027  :   0F04;
    028  :   0F00;
    029  :   0F40;
    02A  :   0F80;
    02B  :   0FB0;
    02C  :   0FF0;
    02D  :   0BF0;
    02E  :   08F0;
    02F  :   04F0;
    030  :   00F0;
    031  :   00F4;
    032  :   00F8;
    033  :   00FB;
    034  :   00FF;
    035  :   00BF;
    036  :   008F;
    037  :   004F;
    038  :   088F;
    039  :   098F;
    03A  :   0B8F;
    03B  :   0D8F;
    03C  :   0F8F;
    03D  :   0F8D;
    03E  :   0F8B;
    03F  :   0F89;
    040  :   0F88;
    041  :   0F98;
    042  :   0FB8;
    043  :   0FD8;
    044  :   0FF8;
    045  :   0DF8;
    046  :   0BF8;
    047  :   09F8;
    048  :   08F8;
    049  :   08F9;
    04A  :   08FB;
    04B  :   08FD;
    04C  :   08FF;
    04D  :   08DF;
    04E  :   08BF;
    04F  :   089F;
    050  :   0BBF;
    051  :   0CBF;
    052  :   0DBF;
    053  :   0EBF;
    054  :   0FBF;
    055  :   0FBE;
    056  :   0FBD;
    057  :   0FBC;
    058  :   0FBB;
    059  :   0FCB;
    05A  :   0FDB;
    05B  :   0FEB;
    05C  :   0FFB;
    05D  :   0EFB;
    05E  :   0DFB;
    05F  :   0CFB;
    060  :   0BFB;
    061  :   0BFC;
    062  :   0BFD;
    063  :   0BFE;
    064  :   0BFF;
    065  :   0BEF;
    066  :   0BDF;
    067  :   0BCF;
    068  :   0007;
    069  :   0107;
    06A  :   0307;
    06B  :   0507;
    06C  :   0707;
    06D  :   0705;
    06E  :   0703;
    06F  :   0701;
    070  :   0700;
    071  :   0710;
    072  :   0730;
    073  :   0750;
    074  :   0770;
    075  :   0570;
    076  :   0370;
    077  :   0170;
    078  :   0070;
    079  :   0071;
    07A  :   0073;
    07B  :   0075;
    07C  :   0077;
    07D  :   0057;
    07E  :   0037;
    07F  :   0017;
    080  :   0337;
    081  :   0437;
    082  :   0537;
    083  :   0637;
    084  :   0737;
    085  :   0736;
    086  :   0735;
    087  :   0734;
    088  :   0733;
    089  :   0743;
    08A  :   0753;
    08B  :   0763;
    08C  :   0773;
    08D  :   0673;
    08E  :   0573;
    08F  :   0473;
    090  :   0373;
    091  :   0374;
    092  :   0375;
    093  :   0376;
    094  :   0377;
    095  :   0367;
    096  :   0357;
    097  :   0347;
    098  :   0557;
    099  :   0557;
    09A  :   0657;
    09B  :   0657;
    09C  :   0757;
    09D  :   0756;
    09E  :   0756;
    09F  :   0755;
    0A0  :   0755;
    0A1  :   0755;
    0A2  :   0765;
    0A3  :   0765;
    0A4  :   0775;
    0A5  :   0675;
    0A6  :   0675;
    0A7  :   0575;
    0A8  :   0575;
    0A9  :   0575;
    0AA  :   0576;
    0AB  :   0576;
    0AC  :   0577;
    0AD  :   0567;
    0AE  :   0567;
    0AF  :   0557;
    0B0  :   0004;
    0B1  :   0104;
    0B2  :   0204;
    0B3  :   0304;
    0B4  :   0404;
    0B5  :   0403;
    0B6  :   0402;
    0B7  :   0401;
    0B8  :   0400;
    0B9  :   0410;
    0BA  :   0420;
    0BB  :   0430;
    0BC  :   0440;
    0BD  :   0340;
    0BE  :   0240;
    0BF  :   0140;
    0C0  :   0040;
    0C1  :   0041;
    0C2  :   0042;
    0C3  :   0043;
    0C4  :   0044;
    0C5  :   0034;
    0C6  :   0024;
    0C7  :   0014;
    0C8  :   0224;
    0C9  :   0224;
    0CA  :   0324;
    0CB  :   0324;
    0CC  :   0424;
    0CD  :   0423;
    0CE  :   0423;
    0CF  :   0422;
    0D0  :   0422;
    0D1  :   0422;
    0D2  :   0432;
    0D3  :   0432;
    0D4  :   0442;
    0D5  :   0342;
    0D6  :   0342;
    0D7  :   0242;
    0D8  :   0242;
    0D9  :   0242;
    0DA  :   0243;
    0DB  :   0243;
    0DC  :   0244;
    0DD  :   0234;
    0DE  :   0234;
    0DF  :   0224;
    0E0  :   0224;
    0E1  :   0324;
    0E2  :   0324;
    0E3  :   0324;
    0E4  :   0424;
    0E5  :   0423;
    0E6  :   0423;
    0E7  :   0423;
    0E8  :   0422;
    0E9  :   0432;
    0EA  :   0432;
    0EB  :   0432;
    0EC  :   0442;
    0ED  :   0342;
    0EE  :   0342;
    0EF  :   0342;
    0F0  :   0242;
    0F1  :   0243;
    0F2  :   0243;
    0F3  :   0243;
    0F4  :   0244;
    0F5  :   0234;
    0F6  :   0234;
    0F7  :   0234;
    0F8  :   0000;
    0F9  :   0000;
    0FA  :   0000;
    0FB  :   0000;
    0FC  :   0000;
    0FD  :   0000;
    0FE  :   0000;
    0FF  :   0000;
END;


My program now outputs Quartus-compatible .MIF files.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7747
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #584 on: December 06, 2019, 06:39:51 pm »
Perfect.  Just for address 0, make the word = F000.

Wire in a memory module called 'palette_mixer.sv'.

For now, wire the 4444 palette address to the pixel_out_top wire & pass through the hde,vde,hs,vs.

Make sure you now use the clk enable on the ram unless you are using my 5 port ram.
« Last Edit: December 06, 2019, 06:43:43 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #585 on: December 06, 2019, 08:02:36 pm »
For anyone following along, the software I wrote to convert these palette values is PALConverter, on github here and the .exe is available below.
 
The following users thanked this post: BrianHG

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7747
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #586 on: December 06, 2019, 08:08:54 pm »
For anyone following along, the software I wrote to convert these palette values is PALConverter, on github here and the .exe is available below.
Makes me wonder if we should have wasted the ram and just done a 24bit RGB and 32bit ARGB palette.
@nockieboy, you know it's your GPU, you could have said so at any time.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #587 on: December 06, 2019, 08:13:08 pm »
For anyone following along, the software I wrote to convert these palette values is PALConverter, on github here and the .exe is available below.
Makes me wonder if we should have wasted the ram and just done a 24bit RGB and 32bit ARGB palette.
@nockieboy, you know it's your GPU, you could have said so at any time.

Would need to work out how much RAM we'd need for 24bit RGB mode at 640x480.  Wouldn't be a massive increase (33%) I suppose.  I think a graphics mode would be out of the question with internal RAM, though.  Would have to look at using an external SRAM for that?

Something I've been wondering - how easy is it to change the text display mode from the current 64x32 to 80x40, or some other arbitrary value?  I haven't looked yet, but I'd like to add parameters to the design to make that an easy option to set.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7747
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #588 on: December 06, 2019, 09:26:22 pm »
For anyone following along, the software I wrote to convert these palette values is PALConverter, on github here and the .exe is available below.
Makes me wonder if we should have wasted the ram and just done a 24bit RGB and 32bit ARGB palette.
@nockieboy, you know it's your GPU, you could have said so at any time.

Would need to work out how much RAM we'd need for 24bit RGB mode at 640x480.  Wouldn't be a massive increase (33%) I suppose.  I think a graphics mode would be out of the question with internal RAM, though.  Would have to look at using an external SRAM for that?

Something I've been wondering - how easy is it to change the text display mode from the current 64x32 to 80x40, or some other arbitrary value?  I haven't looked yet, but I'd like to add parameters to the design to make that an easy option to set.
Your S-Ram would need to read 175 megabytes a second + CPU access + what about the 125 megabytes a second for the display.  we are at 325 megabytes a second, random row & column access, not counting an accelerated drawing engine.
3ns Fully static ram anyone?  Not only 3ns, but ZBT ram. (Zero Bus Turnaround)  Allows a write, then a read, then a write on adjacent cycles.


#2.  Address generator.  That's what it is for.  You will have to basically erase the OSD generator.

« Last Edit: December 06, 2019, 09:47:02 pm by BrianHG »
 

Offline jhpadjustable

  • Frequent Contributor
  • **
  • Posts: 295
  • Country: us
  • Salt 'n' pepper beard
Re: FPGA VGA Controller for 8-bit computer
« Reply #589 on: December 06, 2019, 10:53:28 pm »
That would be kind of expensive, as BrianHG pointed out. But... how about some variation on Amiga HAM (hold-and-modify) mode? :)
"There are more things in heaven and earth, Arduino, than are dreamt of in your philosophy."
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #590 on: December 06, 2019, 11:02:48 pm »
Makes me wonder if we should have wasted the ram and just done a 24bit RGB and 32bit ARGB palette.
@nockieboy, you know it's your GPU, you could have said so at any time.

Would need to work out how much RAM we'd need for 24bit RGB mode at 640x480.  Wouldn't be a massive increase (33%) I suppose.  I think a graphics mode would be out of the question with internal RAM, though.  Would have to look at using an external SRAM for that?

Okay, further to the above with some "back of an envelope" maths:

640x480 text mode = 80x30 = 2,400 tiles.  So 2.4 KB required for the text mode screen space.
256 colour palette x 3 bytes (RGB888 'true colour' gamut) =  768 B for the palette, OR
2,400 tiles x 4 bytes (RGB888 + character value) = 9.6 KB for a true colour text mode.

For graphics, the story isn't so optimistic:

For true colour graphics, you're looking at 640x480x3 = 921.6 KB.  Couldn't even manage RGB565 graphics at 320x240 on an FPGA with less than 160 KB RAM.

Your S-Ram would need to read 175 megabytes a second + CPU access + what about the 125 megabytes a second for the display.  we are at 325 megabytes a second, random row & column access, not counting an accelerated drawing engine.
3ns Fully static ram anyone?  Not only 3ns, but ZBT ram. (Zero Bus Turnaround)  Allows a write, then a read, then a write on adjacent cycles.

You know, looking at engineering problems like this and some of the amazingly tight timings involved really gives me an appreciation of GPU card manufacturers.  Can't be easy making a GPU that can pump enough pixels to support a 4K display at 100Hz.  Yet they use external memory chips too (is it still GDDR?) - can't imagine the technical issues they must face designing those things.  :scared:

#2.  Address generator.  That's what it is for.  You will have to basically erase the OSD generator.

Ah - great. :D  I'll shut up and press on, then!  :-+

That would be kind of expensive, as BrianHG pointed out. But... how about some variation on Amiga HAM (hold-and-modify) mode? :)

Now, forgive me if I'm completely wrong, jhpadjustable, it's been a few years since I've used my Amigas... but HAM mode - didn't that work by using two bytes for the colour, but reserved the top two bits to create a 4-value command that modified the remaining colour bits for the next pixel, or from the previous pixel (or something)?

That seems like it would require some serious horsepower from the Z80 CPU to get that to work - but that's coming from me with little understanding of how it works in the first place.
« Last Edit: December 06, 2019, 11:05:56 pm by nockieboy »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7747
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #591 on: December 06, 2019, 11:24:00 pm »
That would be kind of expensive, as BrianHG pointed out. But... how about some variation on Amiga HAM (hold-and-modify) mode? :)
He has a true 16bit capability.  Right now, 565 with dithering will outdo the Amiga.  Though, If I were to implement 422 8 bit grey, 1 pixel U, 1 pixel V, he would have 24 bit color, DVD Grade, but without MPEG2 compression artifacts.  I'm waiting for him to place the palettes, and then the 'nightmare' of getting nockieboy to visualize the address generators, especially 2x2dimensions running with variable increment rates (address 16/32 bit memory steps), and increment sizes (periods), on X&Y axis with a secondary pointed address begin fed through the memory auxiliary port I had designed early in to point to the tiles/fonts, all of this reset, incremented, and enabled/disabled by 5 HV_Trigger inputs which will allow a variable sized floating text/graphics window on the screen.

My design is now running the ram at 5x, meaning, 125Mhz, 5 read ports per pixel.  When going to the Lattice FPGA, or even this CycloneIV, we can use the 250MHz ram with 10 read ports per pixel, meaning 1 ram for everything, including palettes.  And the 14$ Lattice FPGA has 2 Megabits which can run at 400MHz.

I haven't tried, but I wonder if the current CYClone IV memory core can be pushed to 270MHz...  The data sheet says the -c8 can do 235MHz & C7 can handle 274MHz.  We would probably need to extend the 'MUX' tree to a 2 layer pipe since 10:1 on the addressees would probably be too slow for 250MHz-270MHz.
« Last Edit: December 06, 2019, 11:26:38 pm by BrianHG »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7747
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #592 on: December 06, 2019, 11:33:07 pm »
The address generator shows what memory will be displayed inside the hardware window.
The HV_Triggers control the size and position of the window.

There are 2 hardware windows.  Each with font or true graphics capability.  The top window has 4096 color palette with 16 transparency levels to the second window beneath which uses 565 style 65536 colors.

The sprites share the top window, so you have access to the variable translucent colors on each sprite pixel.
Each sprite size and position will also be set by 4 HV_trigger markers.

We may scrap the 565 color for the bottom window and also use 4096 colors plus an alpha channel, however, what should we do with those 4 programmable bits?
« Last Edit: December 06, 2019, 11:35:34 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #593 on: December 06, 2019, 11:40:04 pm »
I'm waiting for him to place the palettes, and then the 'nightmare' of getting nockieboy to visualize the address generators, especially 2x2dimensions running with variable increment rates (address 16/32 bit memory steps), and increment sizes (periods), on X&Y axis with a secondary pointed address begin fed through the memory auxiliary port I had designed early in to point to the tiles/fonts, all of this reset, incremented, and enabled/disabled by 5 HV_Trigger inputs which will allow a variable sized floating text/graphics window on the screen.

 :o

Again I'm worrying that the hardest parts are yet to come and I won't get this done in time.  :-\

I'm making a start on the palette module now (though it's late here and I'm going offline in a sec) - just want to clarify something though;  you mentioned previously to create a 'palette_mixer.sv' file (after the creation of the 4444 palette) - will this module handle both palettes, or will I be creating (and tweaking) a copy of this module for the 565 palette?

 
The following users thanked this post: BrianHG

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7747
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #594 on: December 06, 2019, 11:44:14 pm »
You know, looking at engineering problems like this and some of the amazingly tight timings involved really gives me an appreciation of GPU card manufacturers.  Can't be easy making a GPU that can pump enough pixels to support a 4K display at 100Hz.  Yet they use external memory chips too (is it still GDDR?) - can't imagine the technical issues they must face designing those things.  :scared:
In all honesty, if you insisted on DDR memory, we would have scrapped any low color modes, and make a 2D drawing/rendering engine to emulate a text and palette low res color video modes.  We would be just beyond a frame buffer at this point and the architecture would be complex enough that we would need block diagrams and system commands/functions with an instruction FIFO port and we would need to weave around both the DDR ram and system memory blocks as when emulating the palette, we would still want that instant access as we render pixels again and again every vsync every-time you modify a single palette number.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7747
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #595 on: December 06, 2019, 11:49:22 pm »
I'm waiting for him to place the palettes, and then the 'nightmare' of getting nockieboy to visualize the address generators, especially 2x2dimensions running with variable increment rates (address 16/32 bit memory steps), and increment sizes (periods), on X&Y axis with a secondary pointed address begin fed through the memory auxiliary port I had designed early in to point to the tiles/fonts, all of this reset, incremented, and enabled/disabled by 5 HV_Trigger inputs which will allow a variable sized floating text/graphics window on the screen.

 :o

Again I'm worrying that the hardest parts are yet to come and I won't get this done in time.  :-\

I'm making a start on the palette module now (though it's late here and I'm going offline in a sec) - just want to clarify something though;  you mentioned previously to create a 'palette_mixer.sv' file (after the creation of the 4444 palette) - will this module handle both palettes, or will I be creating (and tweaking) a copy of this module for the 565 palette?

Other than sprites, as they are a piggy back measure, unless you only want 4 of them, the address generator will complete this project to V1.0.  You will need to concentrate and document everything as those 15 settings will create any display possible from your memory's contents.

Fiddle with setting here, and your text or graphics will move on the screen, change in scale and size, even bend/tear horizontally.

Playing with the palette will change color/brightness or everything.

You will need to get the Z80 doing things after this.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7747
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #596 on: December 07, 2019, 01:47:38 am »
I'm making a start on the palette module now (though it's late here and I'm going offline in a sec) - just want to clarify something though;  you mentioned previously to create a 'palette_mixer.sv' file (after the creation of the 4444 palette) - will this module handle both palettes, or will I be creating (and tweaking) a copy of this module for the 565 palette?
Both palettes will be in 1 .sv module running in parallel, though, their Host address should have a different address point.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7747
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #597 on: December 07, 2019, 11:32:32 am »
@nockieboy, I hate to do this to you, but once you get the initial palette working, you will need to make a change to the 'multiport_gpu_ram.v' and 'gpu_dual_port_ram_INTEL.v'.  Now, I want to get this change right in 1 shot, so, we will need to go over it after the text palette is fully 100% functional without a single pixel in error.

On the read only port side, we will change the 8 bit data port to 16 bits.  This will double our read speed, however, we still want 8 bit address capability.  To do this, in the 'gpu_dual_port_ram_INTEL.v' altsyncram settings, you will make read port 16 bits, effectively lowering the address size by 1 bit.  However, the module 'gpu_dual_port_ram_INTEL.v' will still take the same read address size, and pass it through.  Into the altsyncram, you will feed the upper address beginning at 1 instead of 0.  For the 16 bit data coming out, you will swap the upper and lower 8 bits of that data depending if the read address[0] is high or low.

Effectively, if the proceeding modules use just the bottom 8 bits of ram data, like the 'bitplane_to_rasterbitplane_to_raster.v' we should be backwards compatible.  However, using the upper 8 bits as a font color for example, within 1 read we get 1 byte ascii text, 1 byte color.  When reading a font, we may now also have a few new pixel modes where we have a 16 pixel wide font, or, 4 color per pixel font on top of the base 16 foreground and 16 background offset colors.

The 'multiport_gpu_ram' will also now need to change the 5 read data_out_# ports to a 16bit word.

Next, change the 5 cmd_(in/out)_# ports in the 'multiport_gpu_ram.v' module from 16 bit to 32 bit.  Don't forget the single cmd_(in/out) pass through in the 'gpu_dual_port_ram_INTEL.v' will need to change to 16 bit as well.

As for the 'bitplane_to_rasterbitplane_to_raster.v', take in a 16 bit word for the '.ram_byte_in()', but, leave everything else the same.  For now, ignore the upper 8 bits.  I will specify the minor alterations once everything else is working.

« Last Edit: December 07, 2019, 11:44:10 am by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #598 on: December 07, 2019, 05:49:53 pm »
@nockieboy, I hate to do this to you...

No worries - I just need to focus on one thing at a time, otherwise details get lost in the confusion.  :-+

Hoping to get some palette module work done if I can string together a few hours tonight or tomorrow.  :-\
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #599 on: December 07, 2019, 06:19:21 pm »
Okay, some intermediate guidance required...  ???

Palette #1, specialized for the ASCII text and sprites.

On the Read only port, IE, pixel_in -to- text_pixel out, you will have:
8 bit address input, ie pixel_in[7:0].
On the data output, you will have a 16bit pixel_out[15:0].

I'm struggling to follow this.  Dual-port RAM, but one port is read only?  That port has an 8-bit address input and one 16-bit output?

The 16 bit output will be wired as follows:
text_pixel_out[15:12] -will be sent to- text_a[3:0]
text_pixel_out[15:12] -will be sent to- text_r[7:4] -and- text_r[3:0]
text_pixel_out[15:12] -will be sent to- text_g[7:4] -and- text_g[3:0]
text_pixel_out[15:12] -will be sent to- text_b[7:4] -and- text_b[3:0]

This refers to the 16-bit output mentioned above?

Do I need clkb?

On the pixel side you will want the 'CLOCK ENABLE' feature for the address latch coming in and data latch going out.
The clock enables will be connected to the (pc_ena[3:0]==0) wire.

Is this the read only side?  Are the clock enables the .clockenx entries in the altsyncram component declaration?  Also, and perhaps most importantly, can I create these palette memories by just copying and editing the code for the GPU RAM?  Or do they have to be created using the wizard?

On the 'host' memory side, you will have a 9 bit address [9:0] and 8 bit data in and out.
The write ena will need attention as you will need to position this memory withing the system not to conflict with the main graphics memory.

Okay, below are two files - palette_mixer.sv and dual_port_palette_ram_text.v.  Neither are finished, I'm just putting them up here for feedback and guidance whilst I work on them and to check I'm going in the right direction.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf