Видео

I've built a few concept design boards for VGA output over the years, mostly just on Breadboard but a couple on Veroboard. In all situations I've used TI 74HC components and never had issues with timing or bounce. I'd imagine I wouldn't be so lucky if I was using old chips (or fakes) rather than brand new, but I thought I'd just put that out there.

This is _fabulous,_ Dave. I was so pleased for you when it worked! Wonderful! 👏 (And thanks _again_ for doing this without the music! 👍🙏)

i love you sir

Nice work. Thnak you for this build with clear explanation what/how/why! BTW: what wire do you use for your prototyping? Your results are so neat...

bro i need more of it, I truly enjoy learning this stuff, I love learning about computers hardware, thanks,

Fantastic! Thank you so much for uploading this version. There's a lot to process, and you run through it quickly. Needed this to be able to focus. Thank you! 🙏🙇

It would be interesting to have a video explaining the logic of the pixel generator and what discrete chips and IC it would have required. The convertion to GAL logic would also be interesting, but there are a lot of video on that subject.

I uploaded an alternate version of this video without any background music during the narration: ruclips.net/video/M6Xigigz1Ow/видео.html

Based on viewer feedback, I've uploaded an alternate version of this video without any background music during the narration: ruclips.net/video/r6SRkNa0OIo/видео.html

Music is bad. Remove it please.

zelda dlc over vga is crazy

Fantastic work. Amazingly stable video. Another request for less music please!

Awesome progress, Dave. Very impressive!

just after the shooting the cat got a mild punishment ,

Great work! Congrats on the successful design! Good luck with the PCB design! Question: why jump to FPGA and not go through a 5v CPLD design phase using something like an Altera MAX7000 series device? A 10ns EPM7128 may be large enough and fast enough to incorporate most if not all your VGA hardware logic.

Hey Dave, meant to ask last time, but please can you consider not including the "elevator music" in the background? 🙏 I realise I'm just one, but being _very_ hard of hearing (essentially deaf) and on the spectrum, I find it almost impossible to process what you're saying. I love your videos and have been subscribed for years (since covid, iirc), but I haven't been able to watch episodes 3 or 4 because of it … 😊🙏 (Edit: just read further comments and see I'm not alone. 👍)

Thanks, very interesting !

idk if it's just me, but the background music makes it hard to listen.

I just successfully executed this repair using the linked Alibaba replacement drivers. Since I only use these headphones for monitoring and not mixing I felt comfortable only replacing the single driver (right side) that was broken. I cannot tell the difference between the original and replacement driver, but my bar is set very low.

This video is gold as I'm looking at adding VGA to a 6502 computer that I'm building. If you look back at computers by Commodore etc., they all had custom video chips. The FPGA is the easiest way for us to make our own custom chips, so there's no real argument against using them for retro computers.

My combo for simulating FPGA designs (Verilog and SystemVerilog) is Icarus + GTKwave. At first it may seem weird to write simulations in Verilog but since I got used to it I prefer it over any interactive/schematic based solution.

James Sharman has built beautiful 8 bit computer with logic chips with pipelined CPU, multichannel audio, serial port and awesome display controller. Check out his channel.

Have you considered storing the character data and the attribute data in physically separate RAMs? This would allow both to be accessed simultaneously by the read out module, requiring only 12 bits of counting. I _think_ it should still be possible to arrange the RAMs so that the CPU interface to them still appears as contiguous pairs of bytes instead of separate blocks, e.g. by using A1-A12 from the CPU as A0-A11 to the RAMs, with the CPU's A0 line instead of A12 as the CS/~CS line. Alternatively, maybe having them as separate blocks might be better anyway from a programmer's PoV?

Take a look to see if the part you need is available in 74AHC ... nearly as fast as 74ACT, but doesn't switch quite as hard so no ground bounce. (Though, those are all CMOS-level parts so might be an issue with the low output drive of the GAL... not very many 74AHCT...)

I also like building things, which is why I now design and assemble PCBs with FPGAs 😁 The difference of course is those boards are much more complex, have 6, 8 or even 10 layers, contain big and small BGAs, so instead of messing with a ton of logic chips, I have to deal with high-speed signals like HDMI or 10G Ethernet, DDRx memory interfaces, delay matching, controlled impedance and all that fun stuff. I did learn all of it myself over time without any formal education, so it's absolutely possible to figure all of this out if willingness and persistence is there. As for your arguments against FPGAs, of course none of them (except for "(not) having fun" - this one is subjective) hold any water as FPGA design is simulation, simulation, simulation, and only after than testing it on a real hardware - and of course you have full access to every single signal during simulation. Because of extensive use of simulation, testing/debugging designs on the actual real hardware usually doesn't take much time, and some vendors provide IPs which allow you to "see" any internal signal - just like having a logic analyzer with physical circuits - over JTAG connection. To me the best part about FPGAs is their flexibility, when the same physical board with the same FPGA can be a video-card on one day, a CPU on another, a network switch on yet another, or an entire computer system with CPU, RAM, video card and a bunch of peripherals on yet some other day. Sometimes I get bored of a project in-progress, so I set in aside and work on another one, and then return back to the first one when inspiration strikes again.

You still have to present the circuit that generates pixels based on character and character font, so maybe that will answer my question. However, based on this video alone, I wonder if you really need to go down to single pixel counters for the HSync signal. If the character width is always 8, I wonder if it would make sense to work in chunks of 8 bits (or 1 byte) at 1/8 the frequency for all the internal circuitry including the horizontal counters. Then use a shift register or other appropriate means to split the individual bits at the full pixel frequency just before applying color data to the VGA signal.

You're really smart and this is a well put together video. I wonder if you could create a dumbed down version of this video to appeal to a wider audience.

Dave, this is pretty cool! I've designed something similar for my 6809-based home-brew machine. Mine has 16 inputs, and uses some logic in a GAL to select between the two priority encoders and some other other handshaking because I also implemented auto-vectoring in mine, whereby the interrupt controller places the address of the IRQ table slot that holds the highest-priority handler address directly on the address bus when the CPU fetches the IRQ vector (sort of like Interrupt Mode 2 on the Z80).

I'm glad to see my suggestion for sending the VIS signal into the multiplexor's E line worked! :D

I need some of that wire. Do you remember what gauge it was? I have wire-wrap wire but it's way too thin for soldering (at least a lot of soldering).

This is good stuff, Dave! Following this one with interest!

I'm watching this project with interest. Thank you.

I haven't checked yet of course, but have been wondering if the 6309 bus cycle in my project leaves enough idle time to externally access the fast system SRAM without having to slow the bus clock down from 3.57MHz..

Very interested in the VGA card. Especially how you will interface the software with the hardware.

I dont think this was wire wrapped. If i understood Dave well, he used wirewrap-style wire and did P2P soldering. Real wirewrapping would be actually be faster. I wirewrap a 100mmx160mm eurocard-sized pcb with 20 or so ICs in 6 to 8 hrs.

You Seriously did wire-wrap those ICs. Hats off to your patience

I really loved this video! Do you know if the galasm will work with the ATF15XX CPLD's? I assume not since CPLD's area much higher level than "simple" GAL's.

With this simple DAC you get the "light" colors instead of "bright" ones. See, if intensity bit is set it mixes to all three chanels independent of it's states. You get i.e. 0x3FFF3F (light green) instead of 0x00FF00 (bright green). For CGA colors you need to use all 6 bit of DAC inputs with some "palette" logic, or open-collector/tristate outputs with some diode-logic :) And don't foget the IBM's brown :)

Great work me and your son are friends, your a smart man

good work dad👍

Cool project! Subscribed.

I really enjoy and I am curious about projects like this. The clock generated at 25.etc MHz specifically generates a 640x480 resolution pixel image. With 256 colors displayed on screen this would be considered similar to what was called SVGA, correct? If the clock can generate a 640x480 image, can it do lower resolutions like the more common 320x240, or 320x200? I know nothing of how any of this works. I would assume that the clock set at 25MHz would be insufficient to drive a higher resolution due to the amount of speed required to draw the vertical columns and the horizontal lines. Also, since I have no knowledge or experience with this sort of things, does the clock factor in on the number of colors that are displayed? I recognize that you have something that generates color, and will later generate pixels and colored pixels, but does that require its own clock generator, or is that tied into the 25MHz clock? Apologies if these are all stupid questions. I am just really curious how all of this works. Science and technology are so fascinating.

In the final output stage why use a second 74ACT157 to blank the output when the ~VIS signal could be fed (inverted) to the ~E input of the first '157? When ~E goes high all of the outputs go low, which is AFAICS exactly the behaviour you need.

1:43 "You certainly can't monitor internal signals with an oscilloscope or a logic analyzer." NOT true. At least not any more these days. All of the major FPGA vendors now have signal analyzer type things built in to their software. Basically it's a block of IP that gets automatically loaded onto the FPGA along with your code, and that IP block sits in the background and monitors and records whatever signals you configure it to. It can be set to trigger on various conditions (just like a real oscilloscope/logic analyzer) and you can configure it depending on how much data you want to log. (it uses the FPGA's built-in memory blocks to store the captured data.) So just like a traditional scope/analyzer there's a tradeoff between the resolution/amount of data you can capture vs. not overflowing available memory.) And best of all, this data can be monitored and/or downloaded in realtime to your PC. It's really quite amazing. And lest you think that this is a "professional" grade product that you need to pay big bucks for a professional license to get, that is also untrue. My FPGA dev board is a DE0-Nano which has a Cyclone V, and uses the free version of Intel/Altera's Quartus Lite software, and Signal Tap (their name for the signal capture/logic analyzer thing) is included in the free package and is available for use. If you're on the Xilinx side of the fence, their Vivado suite has a similar tool, though I don't recall its name off the top of my head. (Not sure about Lattice tho.)

Nice video... one thing I learnt that I don't remember reading anywhere is that not all vga monitors behave the same, I found this out as I was not making the RGB signals LOW during the non visible parts and this would upset the synchronisation on some monitors,. RGB signals forced low during non visible parts all monitors ( that I tried) seemed to behave the same.