DIY 8-bit computer, Episode 1A: DIsplay controller host interface

In this video, I implement a host interface that will allow the 6809 system to send commands to the FPGA-based display controller via an IDT7202 FIFO chip. It was a bit of a comedy of errors, but I did eventually get it to work :-)

I'm struggling with Verilog and FPGA programming, so if you have good resources to recommend, please do so in the comments! I'm old enough that a book is my preferred way to learn about a technical topic, but recommendations for good online resources would also be appreciated.

Apologies for the video quality: OBS kept reverting the HDMI capture to 1280x720 for no apparent reason.

[alexsinclair]

Your channel is a hidden gem I'm glad I found!
There are _many_ ways to implement a keyboard controller and yours I found really interesting. Haven't seen someone use a FIFO.
There's this one ASCII keyboard that uses only a dozen 74 series logic devices. It was originally supposed to be used with an Apple 1.

[TroySchrapel]

Essentiallly, a great video, Dave. I have essentially no FPGA experience, but I'm essentially keen to give it a go to replace my TMS9918 eventually. Looking forward to the next video... essentially.

[spacedock]

In the FPGA: a "single byte FIFO" isn't a FIFO - it's a latch! 😁👍 It is quite possible (and in fact common) to implement a FIFO entirely within an FPGA as most have at least a small amount of dual port memory. It is possible to implement them with single port memory too but you have to be careful. Clocks are the single biggest headache I have found in FPGA's. Most YouTube "tutorials" do exactly what you do - run a counter from a "proper" clock and use an output of that counter as a clock. The problem with this method is that the counter-generated "clock" is distributed across the FPGA fabric as a logic signal not a clock. This introduces issues with latency and clock skew at higher speeds. Many FPGA's have dedicated clock lines to mitigate this issue. This means that in many cases you cannot treat any FPGA as a generic device - you need to have some appreciation of it's actual design. With regards to the issue you had with the FIFO IC, I have a long standing aversion to leaving pins unconnected unless explicitly told to do so in the datasheet. Floating pins are one of the most common causes of flakiness in logic designs. I know it's a bit of a faff ensuring every pin is connected to something on a breadboard prototype but it also forces you to look at the purpose of each pin in order to determine whether it should be tied high or low. This in itself can avoid issues like the one you had. Having said that, the video is really interesting and I'm looking forward to the next one. Yet again we work in parallel - I too was intending to use an arduino as a test bench for my Upduino VDC development! I find designing data transfer protocols such as the one you need from your host to the video controller quite fun and interesting to do. I am very interested to see what solution you decide on 🙂

[bobweiram]

You might want to use a more structured and self verifying language like VHDL. I initially hated it's verbose syntax; it seemed to take forever to implement the simplest operations. The exercise, however, made me think deeply about my design and its implications. It also prevented careless mistakes from reaching the final synthesis and executed flawlessly 9 times out of 10. VHDL is an analogue of ADA and shares similar structure and syntax.

[tehaxor]

Are you able to get 40Mhz directly out of the PLL?

You might be violating the fMAX of the FPGA depending
on the design complexity and FPGA speed grade.


I'm assuming the reason you are going for a higher clock speed is to do the attribute/palette/GFX look ups in between VGA pixel writes.



You could pipeline your design and get the same pixel throughput at 40Mhz.