FPGA VGA Controller for 8-bit computer

[nockieboy]

Okay, got the new project working, code is up on github - but I'll only update that repo with working commits.

I'm with you on the versioning - it will clear up confusion with all these updates and corrections.

(This took hours to proof by simulation....)

Make this attachment your new project and if it works and you are ready, we will tackle the universal pixel pointing read address generator.

  It works...

(If everything works and you are waiting for me, think about getting the 4 bit RGB dac working...)

This might have to wait a day or so, depending on how much free time I have tomorrow.

Also, install:

Code: [Select]

https://www.intel.com/content/www/us/en/programmable/downloads/software/quartus-ii-we/91sp2.htmlYour going to need it for engineering the address generator.

I'm having real trouble downloading that package - seems the download link is broken?    I'll keep working at it.

[SiliconWizard]

Wow, BrianHG has been really helpful and really patient...

[nockieboy]

Wow, BrianHG has been really helpful and really patient...

I feel bad enough as it is. 

[BrianHG]

Here nockieboy, and to anyone else who wants a copy of '91sp2_quartus_free.exe' install.
91sp2_quartus_free.rar
(The file will be at this link for only 7 days.)

It's the official Windows download version, just after the point when Altera removed the licensing features.
Note that you should still use the new Quartus Prime USB Blaster Drivers especially with Windows 10.
Both Quartus can be installed in one system and they can both run at the same time.
When simulating your verilog code, in QuartusIIv9, you need to select a CycloneIII or earlier FPGA.  Cyclone IV will compile for the chip, but will not simulate.
Making small dedicated projects to test out each xxxx.v core before adding them to your main project is the norm.

[BrianHG]

Wow, BrianHG has been really helpful and really patient...

I feel bad enough as it is. 

For the new year, I'm leaving electronic engineering and heading into management.  I'll never have time left to do electronic ever again.  Since I'm currently at the last of my free time, I figured, I'm going to do 1 last special thing, and 'nockieboy' hit the jackpot.  I don't know who he's going to sell of push this little core to, but, It will be capable of doing more than a SuperNintendo and quite a bit towards a full VGA card, up to 720x480 modes, memory dependent.  I hope he is ready for documenting all the function controls which are coming up next, making a board with HDMI (DVI) out, and perhaps we might have time for stereo 16 channel sound too.  All by January....

[BrianHG]

Just found a source code for a HDMI serializer with audio support!.
https://www.realdigital.org/doc/189f72e0ee822643d7946fb639754841

It's good as a guide, but we don't want realdigital.org copyright (We are allowed to use it if we give credit & ask permission), and the final verilog output module uses Xilinx specific serdes function.  It's enough to work with to create a 480p version which uses non-dedicated serdes hardware and will compile on all FPGA vendor suites.

[BrianHG]

Lattice FPGA part numbers price VS ram:

4 megabit / 512kb for 30$ usd, 26.60$ for 25.  (actual 400 kilobytes realistically.)
LFE5U-85F-6MG285C
(LOL, with an added flash card reader port added to the FPGA, your GPU could playback full motion 360x480 video with 65k colors...)

2 megabit / 256kb for 16$ usd.    (actual 200 kilobytes realistically.)
Unfortunately, not pin-pin compatible with the 4mbit version.
LFE5U-45F-6BG256C
(360x240 65k color full motion video possible with an accelerated flash card reader.)

Strangely enough, these are the faster -6 grade, not the slowest -8 grade versions of the chips.

[nockieboy]

For the new year, I'm leaving electronic engineering and heading into management.  I'll never have time left to do electronic ever again.  Since I'm currently at the last of my free time, I figured, I'm going to do 1 last special thing, and 'nockieboy' hit the jackpot.  I don't know who he's going to sell of push this little core to, but, It will be capable of doing more than a SuperNintendo and quite a bit towards a full VGA card, up to 720x480 modes, memory dependent.  I hope he is ready for documenting all the function controls which are coming up next, making a board with HDMI (DVI) out, and perhaps we might have time for stereo 16 channel sound too.  All by January....

Well, first of all, thank you.    Secondly, it's a hobby project that started out as an attempt to learn about electronics and broaden my programming skills - it has clearly ballooned into something much bigger than anything I could have wished for at the start.    I'm not intending to sell anything - I seriously doubt I could make a living (or even some pocket money) from what I've developed, but I do want to get my act together and create a website that will document my journey and help anyone else out wanting to try the same thing.

My original end goal, simple as it was (on the face of it  ), was to create a little 8-bit system I can plug into my TV and play some games I've written for it, like Pong or a Rogue-like - with better specs than my first computer I had as a kid.  The GPU (and sound, I guess) is the last part of the puzzle, really.

[nockieboy]

Lattice FPGA part numbers price VS ram:

4 megabit / 512kb for 30$ usd, 26.60$ for 25.  (actual 400 kilobytes realistically.)
LFE5U-85F-6MG285C
...
2 megabit / 256kb for 16$ usd.    (actual 200 kilobytes realistically.)
Unfortunately, not pin-pin compatible with the 4mbit version.
LFE5U-45F-6BG256C
(360x240 65k color full motion video possible with an accelerated flash card reader.)

Strangely enough, these are the faster -6 grade, not the slowest -8 grade versions of the chips.

Those Lattice chips are quite tempting. So it looks like I need to start getting my head around designing for and soldering BGA packages, as that's the way the GPU card is going, it seems.  Whilst the MAX10 is very desirable in terms of features and simplicity, the cost is prohibitive.

(LOL, with an added flash card reader port added to the FPGA, your GPU could playback full motion 360x480 video with 65k colors...)

Sheesh, you're kidding, right?  I knew using an FPGA for the graphics was going to be overkill, but that takes the biscuit! 

[BrianHG]

Ok, next step, not only will you want to simulate test, but, you will want to actually modify memory while running the GPU.  Do you have any means of doing this?

Which CycloneIV dev board are you using?  Do you have schematics of it?  Is there a way to interface with it?

[nockieboy]

Ok, next step, not only will you want to simulate test, but, you will want to actually modify memory while running the GPU.  Do you have any means of doing this?

Which CycloneIV dev board are you using?  Do you have schematics of it?  Is there a way to interface with it?

I'm using one of these:



Have found some good resources here for it: http://fpga.redliquid.pl

Have attached a file called VGA Schematic.pdf.  It seems to show extra connections for more VGA colour resolution?  Hmm.. seems that's an add-on module, perhaps.  There's certainly no resistor networks on the board...

[BrianHG]

Next is the address generator/graphics instruction engine.

Here are the targeted controls/capable features:  (We want to make 1 identical algorithm which will be used 4 times.)

1) Enable/disable.  Requires 1 bit.

2) The base/beginning of a memory address which contains either the screen text data, font data, graphics data and sprite data.  (This eats 20 bits since we can address 1 megabyte for this address)

3) Vertical memory increment size.  When beginning a new line, this is the amount added every time to the base address.  (16 bits is fair, maximum 64kb wide picture.)

4) Pixel type.  1bit=8 pixels wide per byte 2 colors per pixel,
                       2bit=4 pixels per byte 4 colors per pixel,
                       4bit=2 pixels per byte 16 colors,
                       8bit=1 pixel per byte, 256 colors,
                      16bit=2 bytes per pixel, 65k true-color
          = 5 settings possible meaning requires 3 bits for this setting.

5)  X scale.  Counts the number of pixels wide each bitmap image pixel will occupy.  1 through 16 (4 bits)

6)  Y scale.  Counts the number of lines each bitmap image line  will occupy.  1 through 16 (4 bits)

7) Sub-pixel starting X&Y coordinates.  This setting vertically & horizontally shifts the image up and to the left by single pixels in text mode and 4/2/1 bit color modes.  IE, smooth scrolling of text horizontally by up to 7/8th of 1 character, then you can change the base memory address by 1 character and reset this setting back to 0 allowing you to move the text pixel by pixel horizontally and vertically. The shift 16 pixels x by 16 pixels y , or 8 bits total.

8 )  Special control for font size.  8x8 pixel bitmap to 16x16 bitmap.  4 bit control.

9)  Total number of video lines to render before loading a new set of the above controls.  This will allow you to switch video modes mid screen, EG: have a window of 40 column text for half the screen, then switch to 80 column text for the bottom half.

Have I missed anything.  The total here is around 14 control bytes, or, we will reserve 16 bytes per address generator and call it safe.

Extra Note: The horizontal and vertical windows and enables for the 16 sprites will be stored separately.  10bit X 10 bit Y.
Palettes also have a dedicated separate set of registers.  A programmable interrupt generator based on a selected line of video will also be added for smooth animation apps.

[nockieboy]

Ok, next step, not only will you want to simulate test, but, you will want to actually modify memory while running the GPU.  Do you have any means of doing this?

Okay, so this is the Z80<->GPU interface.  I'll need a block of logic in the GPU that responds to memory reads in the desired address range and passes the data from the GPU RAM to the host, and accepts writes to the desired address range and updates the GPU RAM with the written data.  This may take a little time and trial-and-error to build, but I'll get right on it.

[BrianHG]

Oh, I see you have RS232.  Good.  Do you have terminal software on you PC?

I can stuff together an ultra stupid bridge to your HOST_ram port so you may set memory contents.
Can you create a dumb utility on your PC to read and write binary to the com port in a format I will describe?

Let's face it, once the stuff I listed above begins to function, immediately, you will want to test and play beyond just seeing a simulation and static tests once every Quartus compile and you can work on a PC making test scripts.

Note if you do not hace any programming language on your PC, if you can program Basic, I have a free 64bit basic compiler which can access the com port.

[nockieboy]

Next is the address generator/graphics instruction engine.

Here are the targeted controls/capable features:  (We want to make 1 identical algorithm which will be used 4 time.)

1) Enable/disable.  Requires 1 bit.

2) The base/beginning of a memory address which contains either the screen text data, font data, graphics data and sprite data.  (This eats 20 bits since we can address 20mbytes for this address)

3) Vertical memory increment size.  When beginning a new line, this is the amount added every time to the base address.  (16 bits is fair, maximum 64kb wide picture.)

4) Pixel type.  1bit=8 pixels wide per byte 2 colors per pixel,
                       2bit=4 pixels per byte 4 colors per pixel,
                       4bit=2 pixels per byte 16 colors,
                       8bit=1 pixel per byte, 256 colors,
                      16bit=2 bytes per pixel, 65k true-color
          = 5 settings possible meaning requires 3 bits for this setting.

5)  X scale.  Counts the number of pixels wide each bitmap image pixel will occupy.  1 through 16 (4 bits)

6)  Y scale.  Counts the number of lines each bitmap image line  will occupy.  1 through 16 (4 bits)

7) Sub-pixel starting X&Y coordinates.  This setting vertically & horizontally shifts the image up and to the left by single pixels in text mode and 4/2/1 bit color modes.  IE, smooth scrolling of text horizontally by up to 7/8th of 1 character, then you can change the base memory address by 1 character and reset this setting back to 0 allowing you to move the text pixel by pixel horizontally and vertically. The shift 16 pixels x by 16 pixels y , or 8 bits total.

8 )  Special control for font size.  8x8 pixel bitmap to 16x16 bitmap.  4 bit control.

9)  Total number of video lines to render before loading a new set of the above controls.  This will allow you to switch video modes mid screen, EG: have a window of 40 column text for half the screen, then switch to 80 column text for the bottom half.

Have I missed anything.  The total here is around 14 control bytes, or, we will reserve 16 bytes per address generator and call it safe.

No, it sounds like you've covered everything and more besides. 

This (multiple) address generator/graphics instruction engine (let's follow in the footsteps of the Amiga architects and call it MAGGIE - jhpadjustable will be proud  ) - if this is going to handle graphics as well as (tiled) text modes, would this be where we'd want to consider adding hardware-accelerated drawing commands?  i.e. the host could pass a command, say 'FILL', 'LINE', 'BOX' or 'CIRCLE', and a parameter or two and MAGGIE would fill the GPU RAM according to that command and parameters?  If so, is 16 control bytes enough?  Am I getting ahead of myself?

[Berni]

There is a "JTAG to Avalon MM bus" block provided by Quartus for doing exactly this.

You instantiate the block inside the FPGA and then use TCL scripting in Quartus to issue read and write commands to it. I used it a few times to exercise some peripherals on a bus, but my bus was Avalon based to begin with so it worked out of the box. If you have a different bus type (Like a Z80) you need to build a adapter for it. Also TCL is not that great of a language in my opinion.

Tho building your own UART and a simple protocol parser for it is a pretty good exercise in HDL. It also lets you easily write PC software in any language you like since serial ports are easy to use under Windows or Linux in all the common programing languages. Just make sure that the UART protocol is really simple so that the FPGA can parse it without much work. It will also probably also  come in very useful once you have your Z80 running since you can use it as a debug interface into your GPU, Especially if you write a nice tool that displays the state of memory registers and a hex editor to roam around video RAM.

In principle it could also have the debug interface tell the FPGA to single step the Z80 trough gating its clock or holding the wait line. But if you wanted to live debug the Z80 a better solution is getting some Z80 ICE system to put a "Emulated Z80" into the socket and get all of the real time debugging functionality like seeing all the CPU registers

[nockieboy]

Oh, I see you have RS232.  Good.  Do you have terminal software on you PC?

I use PuTTY to access my Microcom at the moment via a USB-TTL interface (FT232) on the Microcom itself - but I don't have a RS232<->USB adapter, so the RS232 port is a little useless on the FPGA board as I have no way of using it.

I can stuff together an ultra stupid bridge to your HOST_ram port so you may set memory contents.

I was going to wire up the Microcom to the FPGA and get access to the RAM that way, as it would mostly just require the electrical connection between the two systems and some logic in the FPGA to read the memory accesses from the Microcom.  I could POKE data into the FPGA with no software development necessary, or even get it sending console output to the FPGA with a little tweaking of the BIOS/monitor software.

The FPGA board has a USB connector on it that I use to power the board - not sure that would be a viable alternative route?

Can you create a dumb utility on your PC to read and write binary to the com port in a format I will describe?

Yes - might take a little trial and error, but that's how I program, it seems. 

Note if you do not hace any programming language on your PC, if you can program Basic, I have a free 64bit basic compiler which can access the com port.

I use C# in Visual Studio 2017 on the (rare) occasions  I need to do something in a language other than Z80 assembly, PHP or Javascript.

EDIT:  re: the Z80<->GPU interface, the one complicating factor I keep forgetting about is the level conversion.  Going to need a breadboard with a few chips on it to convert between 5v and 3.3v...

[BrianHG]

No, it sounds like you've covered everything and more besides. 

This (multiple) address generator/graphics instruction engine (let's follow in the footsteps of the Amiga architects and call it MAGGIE - jhpadjustable will be proud  ) - if this is going to handle graphics as well as (tiled) text modes, would this be where we'd want to consider adding hardware-accelerated drawing commands?  i.e. the host could pass a command, say 'FILL', 'LINE', 'BOX' or 'CIRCLE', and a parameter or two and MAGGIE would fill the GPU RAM according to that command and parameters?  If so, is 16 control bytes enough?  Am I getting ahead of myself?

     Nope, lateron you might make a graphics co-processor which will share the HOST memory interface.  It should be able to fill or draw 130 million 8 bit pixels a second, or, copy 65 million pixels a second, with a transparent color.  (IE Software sprites)  This one would roast anything the Amiga AGA chipset can do when in 256 color mode, or, any color mode.  Expect the Lattice FPGA to double this speed.  This wont be register control based, rather it would be a script of instructions gathered from system memory.  I would engineer it to operate this way so you may have a compiled script screen elements to render in multiple tight strings of bytes which your CPU can request it to run.
     Realtime scaling of images during the copy is possible, but, you wont get there using simple QuartusIIv9.1 as a simple simulation tool.  You will need to learn how to use Modelsim and deal with M.N floating point math in verilog.  I've done it on my video scaler and you are talking about a serious commitment, like a month or 2 just learning how to use Modelsim effectively, (this will be the most boring month of your life, I avoided it) at your beginner level.   Especially when trying to maintain that high FMAX which is needed to fill pixels as fast as possible.

[BrianHG]

Oh, I see you have RS232.  Good.  Do you have terminal software on you PC?

I use PuTTY to access my Microcom at the moment via a USB-TTL interface (FT232) on the Microcom itself - but I don't have a RS232<->USB adapter, so the RS232 port is a little useless on the FPGA board as I have no way of using it.

Ok, so yes, you do have a serial interface.  Yes?  Doesn't matter, as long as you can make your PC talk to the board, right?

If so, let's see what I come up with.

[nockieboy]

Erm... I thought Quartus II had some way of updating FPGA memory while it was on...?  Found this - not sure if this is of any use at all?

In-System Updating of Memory and Constants

Perhaps it only works with single-port memory, but for the purposes of testing we could scrub the host port to the RAM and give Quartus II access to the RAM that way?

[Berni]

Erm... I thought Quartus II had some way of updating FPGA memory while it was on...?  Found this - not sure if this is of any use at all?

In-System Updating of Memory and Constants

Perhaps it only works with single-port memory, but for the purposes of testing we could scrub the host port to the RAM and give Quartus II access to the RAM that way?

Yeah you can also do those for editing things that are memory blocks. It looks like its fully TCL scriptable too. Tho it will likely eat up one port on a dual port RAM block, so if you still need them being dual port in your design that might be an issue.

Also you will most likely keep hardware configuration registers as normal register rather than block RAM. Those won't show up in the memory editor. So the best universal way that works for everything is injecting read and write commands just like the Z80 would. It also inherently tests tests things are accessible at the right addresses since its accessing them in the same way the Z80 would.

Or if you want to be really authentically oldschool with this project you can wire up the address bus to switches and have LEDs show bits like it did on the Altair computer. Just joking, some things are best left in the past.

[BrianHG]

Ok, next step, not only will you want to simulate test, but, you will want to actually modify memory while running the GPU.  Do you have any means of doing this?

Which CycloneIV dev board are you using?  Do you have schematics of it?  Is there a way to interface with it?

I'm using one of these:

(Attachment Link)

Have found some good resources here for it: http://fpga.redliquid.pl

Have attached a file called VGA Schematic.pdf.  It seems to show extra connections for more VGA colour resolution?  Hmm.. seems that's an add-on module, perhaps.  There's certainly no resistor networks on the board...

Copy their DAC design, only the top 4 bits of each color, wired to a header where the 12 wires all come from 1 bank if possible.  Take a look at the SEG and DIG resistors R46 to R57, that's 12 bits there (Remove those resistors).  Copy the resistor dac schematic you sent me, the upper 4 bits of each color, and wire in place of R14,R15,R16. by the VGA connector.  Key the current H&V sync wires attached.

[nockieboy]

Erm... I thought Quartus II had some way of updating FPGA memory while it was on...?  Found this - not sure if this is of any use at all?

In-System Updating of Memory and Constants

Perhaps it only works with single-port memory, but for the purposes of testing we could scrub the host port to the RAM and give Quartus II access to the RAM that way?

Yeah you can also do those for editing things that are memory blocks. It looks like its fully TCL scriptable too. Tho it will likely eat up one port on a dual port RAM block, so if you still need them being dual port in your design that might be an issue.

Yes, it looks like it uses one of the ports as it says in the document I linked that it only supports single-port RAM, so that's most likely why.

Also you will most likely keep hardware configuration registers as normal register rather than block RAM. Those won't show up in the memory editor.

Really?  The only way the Z80 will be able to access the GPU is via a window in its physical memory space where the GPU exposes its own RAM - so a section of the GPU RAM will need to be reserved for configuration, the rest for the GPU RAM itself, and the Z80 will be writing to RAM whether it's setting or reading hardware configuration or screen memory.  What the GPU does with the configuration bits is another matter, but they'll be set in RAM initially.

So the best universal way that works for everything is injecting read and write commands just like the Z80 would. It also inherently tests tests things are accessible at the right addresses since its accessing them in the same way the Z80 would.

Yes, and I hope to get some sort of interface with the Z80 up and running as soon as possible for just that reason - maybe at the weekend, if I'm lucky.  I suspect it will require fair bit of debugging to get working - probably another thread's worth, knowing me - but I could just be being pessimistic. 

Or if you want to be really authentically oldschool with this project you can wire up the address bus to switches and have LEDs show bits like it did on the Altair computer. Just joking, some things are best left in the past.

Hahaha - you're a funny guy. 

[BrianHG]

Also you will most likely keep hardware configuration registers as normal register rather than block RAM. Those won't show up in the memory editor. So the best universal way that works for everything is injecting read and write commands just like the Z80 would. It also inherently tests tests things are accessible at the right addresses since its accessing them in the same way the Z80 would.

Or if you want to be really authentically oldschool with this project you can wire up the address bus to switches and have LEDs show bits like it did on the Altair computer. Just joking, some things are best left in the past.

It's a combination of ram and addressable registers.
I already have a dumb verilog UART to parallel ram read/write debug port.
The interface is a really dumb 1 byte command, 1 response, but, It's idiot proof. (I hope)
I'll fetch it tonight.

It's also good for forcing memory read and writes while the Z80 is wired in.  With 125Mhz dedicated ram port for the HOST, I dont think the speed of the Z80 will ever eat any significant access time.

[Berni]

Yeah these dumb, zero configuration, "it just does one thing" kind of peripherals are what i like in FPGAs.

And yes the Z80 will be using it trough a memory window, but its not practical for this memory window to be all block RAM. Its only possible to access one word at a time in block RAM trough one port. This is great for buffers, character maps, lookup tables where you only need to look at one (or a few) locations in memory at a time.

Hardware configuration registers are different. Because these register need to affect the operation of your circuitry means that the bits in those registers are wired out to individually so that there state can affect the input of some logic gate inside the logic circuitry. To make this possible you can build your own RAM with flip flops in the logic fabric. This is usualy what "reg something; something <= 1" ends up being. Since they are individual flip flops means they can be wired up in any way you like. To make these memory mapped you need a tiny local address decoder that selects the correct register when its address is fed in. So perhaps the first 1KB of the Z80 visible memory map might be reserved for hardware registers and the rest is passed trough as a window into block RAM.

These registers are more expensive in terms of FPGA resources so you generally only use them when you need it. They would store things like config bits, status bits, adjustable video timings, pointers to memory... etc that only take a single word to store, not store big things like image data in these.