FPGA VGA Controller for 8-bit computer

[BrianHG]

Just redid the tuning test with the latest firmware.
Write window = +1 to -3, 5 functional positions for DDR3_CLK_WDQ.
Read window = +2 to -4, 7 functional positions for DDR2_CLK_RDQ.

The WDQ center is off by 1, this needs to be fixed.  It's probably that stupid 'PHASE' int to string problem.  I'll look at that tonight.  I wont play with the RDQ yet as I am trimming a lot of fat in my code first.

I am not using any special timing or tuning, or fine DLL features available for a DDR PHY interface.  This is purely a set counter phase on the system PLL and an .SDC file to constrain the IO timing.

[asmi]

Is it the same for both byte lanes?

[BrianHG]

When tuning from +2 to +3 on the reads, there is data corruption across many of the data bits, with jiggling bit errors.  However, strange enough, at the end of the 'BL8', the last 16bit word/2 bytes don't have any errors, it's just the first 7 of 8 with the errors.  I assume it's just capacitance on the DQ buss holding that last word steady since the DDR3 has placed the DQ outputs into tri-state mode.

-4, I can't see anything since my code detects a DQS timing violation and reports the error scrapping the data read all together.

Going from -4 to -5, no errors seen as my code detects the DQS fault.

As for writes, stepping outside the tuning range messes up everything randomly to hell, like shiftng data or complete gibberish.  I have a feeling some of this is due to internal clock domain cross-boundary issues in the FPGA, not on the ram bus as I would expect to see a clean 2 byte data shift as I continue to tune, not the 4/8 bytes I see with repetitious blocks.

Note that I am not using FPGA dual port ram to store and shift data between clock domains.   This code is 100% logic elements.  For those who want the dual clock multi-clock domain features of embedded ram blocks, you would just use them to feed my controller's command inputs with another one on my controller's output.

[NorthGuy]

Write window = +1 to -3, 5 functional positions for DDR3_CLK_WDQ.

This is only 200 ps off centre. The skew between different clocks from the same PLL might be around 100 ps.

I did some experiments with SODIMM modules few years back. As I remember, the skew between different traces of the same byte may  ps (although the IDELAY resolution was only 40 ps).

Also, as FPGA warms up by 30-40 degrees from ambient, the delay can easily increase by around 100 ps. The temperature shouldn't be a problem for writes, but when you read, it may shift the window. Same with voltage.

If your FPGA has an internal temperature sensor you can build a "thermostat" design which keeps FPGA at the desired temperature. Then you can investigate how the window changes with temperature.

[BrianHG]

Write window = +1 to -3, 5 functional positions for DDR3_CLK_WDQ.

This is only 200 ps off centre. The skew between different clocks from the same PLL might be around 100 ps.

Even ModelSim also shows it is off by 1 step when I measure the PLL clock output waveforms.  It's like Altera has forgotten that their phase tap calculation begins at 0, not 1, or it is an integer rounding error in their code.  These are not the only bugs I've encountered.  Coding the memory controller was the easy part and done in the first week running great in ModelSim.  In that part, nothing has changed since then.  Uncovering all these little undocumented, or erroneous documented functions, waiting for Quartus to compile and test was the other  > 90% of the work.

[RoGeorge]

waiting for Quartus to compile and test was the other  > 90% of the work.

Just curious, how much time does it take to complete a compilation, and how long to run the tests/simulations?

[NorthGuy]

Even ModelSim also shows it is off by 1 step when I measure the PLL clock output waveforms.  It's like Altera has forgotten that their phase tap calculation begins at 0, not 1, or it is an integer rounding error in their code.  These are not the only bugs I've encountered.  Coding the memory controller was the easy part and done in the first week running great in ModelSim.  In that part, nothing has changed since then.  Uncovering all these little undocumented, or erroneous documented functions, waiting for Quartus to compile and test was the other  > 90% of the work.

This is bizarre. May be Vivado is not that bad after all

[BrianHG]

waiting for Quartus to compile and test was the other  > 90% of the work.

Just curious, how much time does it take to complete a compilation, and how long to run the tests/simulations?

ModelSim in RTL takes around 1 seconds to compile.  To simulate, around 1 second when I have the power-up reset timer set to 200ns instead of the authentic 1000uS.

Quartus takes around 2 minutes total to full compile/fit.  Doing a gate-level simulation with the phony 200ns power-on reset timer, using my accidental discovery of bypassing the speed limiter put in place takes around 10 seconds to setup the sim, then 5 seconds of simulating before I reach the first refresh command after initialization and calibration of the DDR3.  It's ~3x slower if you let it run the normal way with the 'Altera-Modelsim' speed limiter in place.  Having the 1000uS powerup timer in place makes it take almost 1 minute, almost 4 with the speed limiter in place.  A timing-gate level sim is around 50% slower.

As you can see, working 100% within ModelSim, I can see the results of code edits within 2 seconds flat, less than a second if there were coding errors, and in FPGA terms, you can almost call this real-time.

All the above simulations had Micron's DDR3 simulation model wired into my test-bench code simulating the DDR3 ram chip.  It would report any timing/command violations and what the DDR3 ram chip is doing in the console window as each command went out.  All my code and simulation test bench files will be available in my DDR3 thread next week.

(Yes it is a fluke, but I did not know about the Model-Sim speed limiter in place for the FPGA Vendor versions instead of the full version of the simulator and without knowing, I accidentally been bypassing the speed limiter and only recently learned what it was.  My setup script for quick compiling and running my sims just happened to disable/bypass the limiter and made ModelSim simulate at full speed since day one.)

[BrianHG]

Even ModelSim also shows it is off by 1 step when I measure the PLL clock output waveforms.  It's like Altera has forgotten that their phase tap calculation begins at 0, not 1, or it is an integer rounding error in their code.  These are not the only bugs I've encountered.  Coding the memory controller was the easy part and done in the first week running great in ModelSim.  In that part, nothing has changed since then.  Uncovering all these little undocumented, or erroneous documented functions, waiting for Quartus to compile and test was the other  > 90% of the work.

This is bizarre. May be Vivado is not that bad after all

(In the ModelSim stage) 2 second turn around for compile and see your coded results is great.
Waiting 2 minutes a compile, and not even having a scope to tell you even your clock isn't coming out because you are using an outdated 'altddio_bidir' instead of the newer 'altera_gpio_lite' specifically designed for the MAX10 wasted 10 days.  Whats worse is that the 'altddio_bidir' (Used for all Cyclone and Arria fpgas) still compiled and was partially functional in the MAX10, fully functional in the simulations fu..ing everything up...

[nockieboy]

Just as an aside from the discussion on DRAM timings, I had a little time over the weekend to do some more work on Pong.  Sorry the video is a little long, but watch towards the end and you'll see the ball accelerates when hit nearly straight-on.



Would have uploaded it much earlier, but the eevBlog servers were under water in Ogden.    Speaking of, who uses water as a fire suppression agent (yes okay, unless it's water mist) in a room full of high-value (both financially and data-wise) electronics?  Most data centres use gas suppression systems for obvious reasons. 

[BrianHG]

Ok Nockieboy, it is time to wire up your DECA board to a Z80.  Please think of a sturdy way to get those connections to the TTL 5v translators.

Get the current project working.
Also, make sure the basics and !WAIT is wired with an NPN transistor so we may pause the Z80 if a read isn't ready in time.

Your current code should work as is + you will have access to >128 kilobytes onchip graphics ram and 15 MAGGIE layers.

Next week, expect to wire-in my DDR3 controller in a limited fashion since current GPU core will need updating as it was only designed to address 1 megabyte, but the DECA board has 512 megabytes.  There is a lot of crap to update all over the place.  Might as well bring everything up to 30-32 bit addressing supporting 1-4 gigabytes, though, I do not know how a Z80 can address all that...

[asmi]

Next week, expect to wire-in my DDR3 controller in a limited fashion since current GPU core will need updating as it was only designed to address 1 megabyte, but the DECA board has 512 megabytes.  There is a lot of crap to update all over the place.  Might as well bring everything up to 30-32 bit addressing supporting 1-4 gigabytes, though, I do not know how a Z80 can address all that...

The simplest method I can think of is this: implement six memory-mapped 8 bit registers (Z80 is 8bit right?) -
4 registers for the address (32 bit address)
1 register for stride
1 data register
The idea is that once you set up address and stride, you just keep writing data into a single data register (or reading from it), and FPGA will auto-increment the address as per stride value after every successful read from or write to the data port. And now you can address any 32 bit location of the video memory, and pump the data at max CPU speed because it doesn't need to adjust address all the time. Using stride also allows for some advanced scenarios like writing every other byte (common with text modes, which encode each symbol position with two bytes of memory - one for the symbol itself, and another one for background/foreground color).

[nockieboy]

Ok Nockieboy, it is time to wire up your DECA board to a Z80.  Please think of a sturdy way to get those connections to the TTL 5v translators.

Get the current project working.
Also, make sure the basics and !WAIT is wired with an NPN transistor so we may pause the Z80 if a read isn't ready in time.

Your current code should work as is + you will have access to >128 kilobytes onchip graphics ram and 15 MAGGIE layers.

Next week, expect to wire-in my DDR3 controller in a limited fashion since current GPU core will need updating as it was only designed to address 1 megabyte, but the DECA board has 512 megabytes.  There is a lot of crap to update all over the place.  Might as well bring everything up to 30-32 bit addressing supporting 1-4 gigabytes, though, I do not know how a Z80 can address all that...

Okay, will get on that ASAP.  Can't say how long it will take as I'm really short on spare time at the moment .

Next week, expect to wire-in my DDR3 controller in a limited fashion since current GPU core will need updating as it was only designed to address 1 megabyte, but the DECA board has 512 megabytes.  There is a lot of crap to update all over the place.  Might as well bring everything up to 30-32 bit addressing supporting 1-4 gigabytes, though, I do not know how a Z80 can address all that...

The simplest method I can think of is this: implement six memory-mapped 8 bit registers (Z80 is 8bit right?) -
4 registers for the address (32 bit address)
1 register for stride
1 data register
The idea is that once you set up address and stride, you just keep writing data into a single data register (or reading from it), and FPGA will auto-increment the address as per stride value after every successful read from or write to the data port. And now you can address any 32 bit location of the video memory, and pump the data at max CPU speed because it doesn't need to adjust address all the time. Using stride also allows for some advanced scenarios like writing every other byte (common with text modes, which encode each symbol position with two bytes of memory - one for the symbol itself, and another one for background/foreground color).

Ditto.  It would be easy enough to set up an MMU or register-based access in the FPGA as you've suggested to allow the Z80 to access any part of an arbitrarily-sized RAM space - the question is how useful it would be.  Even if I start thinking about using the GPU RAM as a ram drive for the Z80's operating system (CP/M), it will only need a few megabytes of space (the 64MB CF card I'm currently using is way too big for it to fill any time soon and my BIOS provides 16 drives within that space, of which I'm using four that aren't even close to being filled yet).

However, where that kind of memory space would be more useful is if the host system is 16-bit.  This GPU card could be used with any homebrew computer system - if I ever get enough free time again I'll be building a 16-bit Motorola 68010 system which will use this GPU card.

[asmi]

Ditto.  It would be easy enough to set up an MMU or register-based access in the FPGA as you've suggested to allow the Z80 to access any part of an arbitrarily-sized RAM space - the question is how useful it would be.  Even if I start thinking about using the GPU RAM as a ram drive for the Z80's operating system (CP/M), it will only need a few megabytes of space (the 64MB CF card I'm currently using is way too big for it to fill any time soon and my BIOS provides 16 drives within that space, of which I'm using four that aren't even close to being filled yet).

However, where that kind of memory space would be more useful is if the host system is 16-bit.  This GPU card could be used with any homebrew computer system - if I ever get enough free time again I'll be building a 16-bit Motorola 68010 system which will use this GPU card.

I think it will be useful if you combine it with DMA channel into VRAM from your storage, so that you can load assets directly into VRAM at high speed bypassing CPU (once it sets up the transfer).
This is actually quite common - a lot of my designs do very intensive data processing (like handling FullHD streams), but entire design is controlled by a fairy weak Microblaze CPU running at 100 MHz or even lower. The point is - since a CPU is only used to process user input and control/configure various processing blocks, but  is not directly involved in the data processing itself, you don't really need a beefy CPU.  Come to think of it - even in modern PCs a GPU is typically orders of magnitude more powerful than CPU, which is why a good application that efficiently utilizes GPU will make sure to offload as much of processing onto GPU as possible.

[nockieboy]

It's been a while again (this is the busiest time of the year for me and working two jobs means I have even less time to do anything hobby-wise.  )  I hope everyone is fit and healthy and haven't given up on me just yet. 

I've finally had some time to look at wiring the DECA up to my computer to start testing the GPU code on it and make some progress on the DRAM controller.  I was looking at my old Dupont leads that I used previously with the EasyFPGA Cyclone IV board to test the original GPU FPGA and realised they were terrible and caused me no end of headaches with loose connections, so I've designed a dedicated adapter PCB so that I can plug my DIY computer stack directly onto the DECA board, complete with 3.3V/5V translation and some additional features to allow future testing of more stuff on the FPGA (it'll be able to grab the bus from the Z80 and do DMA etc, so the entire address bus is now bidirectional).

I just want to check that I'm not making any silly mistakes with IO selection on the DECA.  From what I can gather, the Beaglebone Black-compatible headers P8 and P9 provide more than enough IO to do what I want, so I'm using P8 for all the address lines, outgoing control lines and I²C (these are for future features).  I'm using P9 for bidirectional data and incoming control signals.  I've referenced the DECA schematic and manual to choose the right pins.  I've done it this way because of the physical location of the address, data and control buses on the host computer.  Schematic attached.

[nockieboy]

Also, make sure the basics and !WAIT is wired with an NPN transistor so we may pause the Z80 if a read isn't ready in time.

Ah yes, nearly missed this - added the WAIT driver in as well.  Schematic updated.

[nockieboy]

PCBs are on order.  Have checked and cross-checked IO allocation in the DECA manual, all appears good.  Have drivers to pull all the 5V control lines low that I need for WAIT and to request and take control of the bus from the Z80 and perform memory and IO ops.

[Ted/KC9LKE]

 Nockieboy et al.

I have been watching this topic for several months and its great to see something like this being developed for homebrews or existing vintage systems, quite an awesome project.
I have read all 103 pages and am trying to sort some things out, I am a bit confused about the GPU RAM.

It looks like GPU RAM will now move on to the DECA board DDR3 for GPU operations and DMA to the Microcom can be done for additional DECA FPGA projects.
What I am asking is it now possible to use the GPU and terminal emulator for other 8 bits that only have 64k RAM and 256 or less I/O locations?

On a different note, could a .ttf font be used on the VT100 terminal emulator easily?
 
Thanks again for this awesome project

[asmi]

It looks like GPU RAM will now move on to the DECA board DDR3 for GPU operations and DMA to the Microcom can be done for additional DECA FPGA projects.

nockieboy will correct me if I'm wrong, but my understanding is that segway onto DECA board is just a way to validate DDR3 controller with other bits and pieces in hardware, with eventual goal of designing a custom PCB to house everything.

What I am asking is it now possible to use the GPU and terminal emulator for other 8 bits that only have 64k RAM and 256 or less I/O locations?

Again, as per my understanding right now the VRAM is mapped into CPU memory address space (because 6502 doesn't have dedicated I/O bus), but technically you can use a suggestion I offered just few posts above, when you map up to 6 8-bit locations into I/O space (4 for 32bit address, 1 register for stride, 1 data register), which will allow your CPU (which I assume is some variation of Z80) to access any 32bit address, and write bursts at the maximum IO speed. You will probably need to map a DMA controller's control registers into IO space as well. You will have to lean heavily on DMA and GPU hardware functions because there is no way you can achieve any sort of acceptable performance with the CPU itself.

I've been thinking for a while to create a system with a bunch of 8bitters in a sort of SMP system just for the hell of it, but unfortunately real life gets in the way so much so I don't have enough time to even complete my current projects

[BrianHG]

It looks like GPU RAM will now move on to the DECA board DDR3 for GPU operations and DMA to the Microcom can be done for additional DECA FPGA projects.

nockieboy will correct me if I'm wrong, but my understanding is that segway onto DECA board is just a way to validate DDR3 controller with other bits and pieces in hardware, with eventual goal of designing a custom PCB to house everything.

Correct.

I just finally got the multichannel/multiport 'BrianHG_DDR3_COMMANDER.sv' working.  It is the front end for my DDR3 controller providing 16 read and 16 write ports, each with a user set individual data widths and a DMA through function for all the read channels.  Right now, I just need to clean up the 'priority' selection encoder and I will post the entire DDR3 controller on a separate thread.  This should be enough for Nockieboy to add CPU data & program IO access ports to the controller, + video access, + audio access, + SD-Card read & write access, + Geometry processor access, + anything else he wants.  All accessed like a huge internal multiport FPGA static ram with the 1 caviot that you occasionally need to wait for a busy flag to clear, or read data ready flag on each individual port.

[nockieboy]

Nockieboy et al.

I have been watching this topic for several months and its great to see something like this being developed for homebrews or existing vintage systems, quite an awesome project.

You're absolutely welcome - it's actually really great to hear from others who might find the project useful! 

It looks like GPU RAM will now move on to the DECA board DDR3 for GPU operations and DMA to the Microcom can be done for additional DECA FPGA projects.
What I am asking is it now possible to use the GPU and terminal emulator for other 8 bits that only have 64k RAM and 256 or less I/O locations?

ALL the GPU RAM is in the FPGA currently - this limits me to about 42KB (off the top of my head) with the current Cyclone IV EP4CE10 FPGA that I have in the prototype GPU card for the uCom (I've changed the name to uCom - or muCom; the 'u' is the Greek symbol mu, as apparently there was a Microcom in the late 70's or something similar).

You'll have read the discussions I've had with very knowledgeable and experienced FPGA users previously in this thread and will understand that to get more than 200KB of in-FPGA RAM will make the FPGA rather cost-prohibitive, pretty much whichever brand of FPGA I switch to.  My constraints for this project are quite tight, which isn't a bad thing in itself as it pushes the limits of what can be done.

The GPU intercepts memory reads and writes to a 512KB 'window' in the uCom's physical memory space (it equates to an empty socket on the memory card) and responds to RD/WR ops to its internal RAM within this 512KB window.  The HDL allows explicit definition of exactly where the window starts and its size in the physical memory space in which the GPU will intercept memory ops.  I have it set to present the GPU RAM within a 512KB window starting at 1.5MB, for example; I just map the appropriate 16KB bank into the Z80's 64KB logical memory space to read or write to it (my hardware MMU uses 16KB banks - but I might redesign this with 4KB banks in the GPU FPGA itself at some point).  You could just as easily set up and compile the HDL to present the GPU RAM within a 16KB window between 32-48KB if you wished, you'd just need to make sure your RAM/ROM select logic kept the RAM/ROM disabled when memory was accessed in this window, otherwise you'd have bus contention as the GPU fought with a memory chip to respond to the memory access.

We're looking at using DDR3 RAM to support the FPGA's internal RAM, or replace it entirely as the home for the GPU's RAM and frame buffer.  BrianHG has been working very hard on a platform-agnostic DDR3 controller we can use and the latest development steps require me to have a working testbed with DDR3 RAM so that we can test the new controller.  This is where the DECA comes in.  Previously, when testing with the EasyFPGA dev board on the Cyclone IV, I used a breadboard with level converters to bridge the 5V host bus to the 3.3V FPGA bus, with a rat's nest of Dupont leads connecting it all together.  It was unstable to say the least, so I've designed a proper card (PCB) that will sit on the bottom of the uCom's stack and I can just plug the whole thing onto the DECA.  It'll be just as good as having a prototype GPU card, just without the extras like PS2/USB/audio etc.

nockieboy will correct me if I'm wrong, but my understanding is that segway onto DECA board is just a way to validate DDR3 controller with other bits and pieces in hardware, with eventual goal of designing a custom PCB to house everything.

Yes, exactly.  The DECA will be the test-bed for the DDR3 controller, HDMI output and any further development on the GPU itself, as the Cyclone IV has effectively run out of space.

On a different note, could a .ttf font be used on the VT100 terminal emulator easily?
 
Thanks again for this awesome project

The font/character set is bitmapped, so a conversion program would have to be written to translate the TTF to a bitmap hex file that could be uploaded into the FPGA (or soft-loaded into the GPU RAM from the host when it's running).

Again, as per my understanding right now the VRAM is mapped into CPU memory address space (because 6502 doesn't have dedicated I/O bus), but technically you can use a suggestion I offered just few posts above, when you map up to 6 8-bit locations into I/O space (4 for 32bit address, 1 register for stride, 1 data register), which will allow your CPU (which I assume is some variation of Z80) to access any 32bit address, and write bursts at the maximum IO speed. You will probably need to map a DMA controller's control registers into IO space as well. You will have to lean heavily on DMA and GPU hardware functions because there is no way you can achieve any sort of acceptable performance with the CPU itself.

I've been thinking for a while to create a system with a bunch of 8bitters in a sort of SMP system just for the hell of it, but unfortunately real life gets in the way so much so I don't have enough time to even complete my current projects

I've mapped the VRAM into memory rather than IO space as it's memory, really.  The host has access to the entire GPU VRAM using the usual memory ops - so for a Z80, it has some pretty speedy memory access commands and can copy data to the GPU RAM/VRAM pretty quickly (for a late '70s 8-bit processor).  So setting up a text screen and outputting text to the screen is all done in memory.  The GPU, on the other hand, uses IO space and is controlled by sending data and commands via IO addresses.  Again, these are fully customisable and (currently) there are no plans to use anywhere near 256 IO address ports..  without checking I think we're using about 10. 

I just finally got the multichannel/multiport 'BrianHG_DDR3_COMMANDER.sv' working.  It is the front end for my DDR3 controller providing 16 read and 16 write ports, each with a user set individual data widths and a DMA through function for all the read channels.  Right now, I just need to clean up the 'priority' selection encoder and I will post the entire DDR3 controller on a separate thread.  This should be enough for Nockieboy to add CPU data & program IO access ports to the controller, + video access, + audio access, + SD-Card read & write access, + Geometry processor access, + anything else he wants.  All accessed like a huge internal multiport FPGA static ram with the 1 caviot that you occasionally need to wait for a busy flag to clear, or read data ready flag on each individual port.

You sir, are a legend. 

[Ted/KC9LKE]

Thanks to everyone for the detailed explanation!

"The GPU intercepts memory reads and writes to a 512KB 'window' in the uCom's physical memory space (it equates to an empty socket on the memory card) and responds to RD/WR ops to its internal RAM within this 512KB window."

Yes makes sense to me now, wouldn't make sense to have the GPU constantly accessing screen RAM on the uCom's bus.

"The DECA will be the test-bed for the DDR3 controller,"

Yes proven hardware plus physical layout to test the new DDR3 controller

" there are no plans to use anywhere near 256 IO address ports..  without checking I think we're using about 10."

Good news as more than 16 bytes per I/O slot would be a bit cumbersome for my system

Just thinking out loud, in a 64k system with only 56k of RAM for the operating system there is not a lot of address space left for VRAM.
Would an approach like asmi suggests, sort of like the TMS9918 where you send a start address through an I/O port and subsequent reads or writes increment the internal address counter, be possible without a complete redesign?  This is just a curious question not a wish list.   

I was looking through your Github and found the "Z80_Bridge.v".  Is it still the same or close to the current version that you are using?
I am  considering going back to the start of this thread and try to understand how the bridge works.

Quote from: BrianHG on May 26, 2021, 07:30:06 pm
I just finally got the multichannel/multiport 'BrianHG_DDR3_COMMANDER.sv' working.  It is the front end for my DDR3 controller providing 16 read and 16 write ports, each with a user set individual data widths and a DMA through function for all the read channels.  Right now, I just need to clean up the 'priority' selection encoder and I will post the entire DDR3 controller on a separate thread.  This should be enough for Nockieboy to add CPU data & program IO access ports to the controller, + video access, + audio access, + SD-Card read & write access, + Geometry processor access, + anything else he wants.  All accessed like a huge internal multiport FPGA static ram with the 1 caviot that you occasionally need to wait for a busy flag to clear, or read data ready flag on each individual port.

You sir, are a legend. 

Yes Brian has a considerable amount of work in this project.

Again thanks for this project

Ted - Patiently following the project 

[nockieboy]

Just thinking out loud, in a 64k system with only 56k of RAM for the operating system there is not a lot of address space left for VRAM.
Would an approach like asmi suggests, sort of like the TMS9918 where you send a start address through an I/O port and subsequent reads or writes increment the internal address counter, be possible without a complete redesign?  This is just a curious question not a wish list.   

Yes, absolutely.  As you've already identified, the Z80_Bridge.sv module is what interfaces the GPU and video HDL to the host system.  This is the one module you really need to understand to get the GPU to work with another system.  Because it's specific to my uCOM and not just the Z80, there's a lot of specific addresses for IO and memory access - but these are all accessible and changeable in the Quartus schematic overview to make it easier to adjust/adapt to a different system.  There's also specific stuff like returning 0xFF if a read is attempted to the 512KB window, but outside of the RAM space for the GPU, or returning bytes from a preset string if the last 16 bytes of the 512KB window is read.  This is so that software on the uCOM can identify the presence of a graphics card.

I was looking through your Github and found the "Z80_Bridge.v".  Is it still the same or close to the current version that you are using?
I am  considering going back to the start of this thread and try to understand how the bridge works.

The github project is up-to-date with the latest Cyclone IV version of the HDL.  If you were to build a video card using the EP4CE10 for your system, the github repo has everything you need to get it working and doing everything we've talked about so far with regard to text and bitmapped graphics routines.  It doesn't yet have any of the work I've done around USB interfacing or BrianHG's DDR3 controller work.  It might have a folder for the Cyclone V project, but it won't work as I haven't got a Cyclone V (yet) to build it for.  This will probably be a last step, or next-to-last step once I get a prototype graphics card up and running with a Cyclone V on it.

In the meantime, all future dev work will be done on the DECA (MAX10 FPGA) until such time as I get the Cyclone V GPU card designed and built.  As well as DDR3 support, I've yet to really design the card (can continue where I left off a few pages back, but need to update for DDR3 and that'll take time as I don't have a clue at the moment!)  I also have to finalise the USB interface, which will now be using a SAMD21 microprocessor, and do some more research and work on the audio interface, so it'll be a while yet.

[Ted/KC9LKE]

Ok great,

I need to develop an interface like the frontend of a 6850 for the 6800-6809 in Verilog, fully test it and get it running on the DECA, then I will start looking at the "bridge" interface.

Have to finish my Quartus install first.....

[BrianHG]

@Nockieboy, looking at your PONG video above, it looks like you are getting an impossible interlace artifact.  Do you actually see that in person, or is it just your video camera recording?