Dude, just take the plunge. I avoided FPGAs for years for all the reasons you mentioned (seemed complex -- simulations, timing, verification, difficulty probing, etc.) Once I forced myself through these issues (for what it's worth you don't HAVE to do simulations or verification, it's just smart to do so), I had a new, modern skill, that has proven extremely valuable. Also, for what it's worth, you can probe absolutely any signal you want -- you just have to send it to an output pin. Basically everything you were doing in Logicsim, you more-or-less can do in an FPGA tool chain (including graphical blocks with signals that you later associate code with, more or less just like a bunch of GALs, without the tedium of having to program them). You can basically make your retro machine do anything with FPGAs. My most interesting project so far was retrofitting a TRS-80 Model 4 with HDMI and adding a programmable sprite layer over the top of the base output signal. I replaced a broken CRT in an old Model 4 with a custom FPGA board + HDMI LCD screen, fed the raster signals into the FPGA, got that upscaled to HDMI (it was originally a specialized RGB to HDMI project, because the 4 has some weird raster signals that can be switched on the fly between modes), and then realized it would be pretty trivial to add a data bus and an address bus decoder to give the Model 4 the ability to do anything I wanted to the video buffer, voila, colors and sprites. I then made some slight modifications and brought the whole thing over to a TRS-80 Model 1. That's right, color and sprites over HDMI on an 8-bit machine from 1977.
Exactly. I notice that you can buy one of those new Chinese FPGA boards, (Sipeed Lichee Tang Nano.) I mention this because even the cheap one @ around $12, has an LCD connector built into the board, and I'm pretty sure they have lots of example code to make it work. No need any more to re-invent everything from scratch, or spend $500 on a Terrasic board for that matter. I'm happy Dave made the video though, as it is very informative ... I just wouldn't do it this way. FPGA programming may be a bit daunting to begin with, but seriously, once you've done all the work by setting up the entire application on Logisim, and implementing it with logic chips, writing the Verilog hdl should be trivial.
Professional FPGA wrangler here... I would strongly suggest simulating things, else you can experience slight bugs like counters off by one, etc., so simulation is strongly recommended. My experience is with Xilinx or Lattice FPGAs, but they all have similar features. One useful feature is ILA (integrated logic analyser, formerly ChipScope) to let you probe internal signals via JTAG - sounds scary, but it just works and you see waveforms from the FPGA. Don't forget you can always MUX debug signals out to a spare pin, too, to help with debugging.
@@m1geo Thank you for the advice! I do plan to use simulation on my next go-round with FPGAs. I have brought signals out to external pins before, and that definitely has been useful. The internal logic analyzer functionality sounds great, although I stubbornly refuse to use closed-source vendor tools, which might limit my options.
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.
Great video, Dave. This is something I've also wanted to do for a while. My in-between step has been to use a Pi Pico. Very much not in the spirit of retro, but an easy way around many of the issues with the TMS9918A and much simpler to understand than the FPGA. Looking forward to your progress on this. If you need further inspiration for a discrete logic VGA circuit, I highly recommend checking out James Sharman's build (if you haven't already). Super impressive, and he's managed to go without the dual port SRAMs too.
Thanks, Troy! I like the Pi Pico idea quite a bit, actually, and there's precedent for even "classic" peripheral ICs to be implemented as an embedded micro running firmware (I think the Intel 8271 floppy controller works this way). I also agree I should check out James Sharman's videos. Maybe I'll do that once I get my display controller working, so I can see how someone who actually knows what they're doing would approach the problem :-)
@@davehohacks I think you'll really like it, especially for something like this. The PIO module is really cool in that it does its thing asynchronously and the "code" that they execute gives you loops without branching delays. It reminds me of my Honeywell mainframe days. The mainframe's Input/Output Multiplexer did something similar for handling peripheral accesses. When you invoked it through a system call (MME), you passed a little "script" telling it how to move data from its internal buffers into system RAM. The PIO module in the pico is much more powerful since it incorporates configurable state machines.
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.
In my project I use 74LS parts and target a 384x264 screen, with suitable variable border areas. That resolution is definitely more feasible and includes multiple display planes, sprites, scaled sprites, vectors, and scaling/rotating of tiles. It is however using many hundreds of 74LS parts. :)
Very interesting, subscribed to keep an eye on developments. Thank you. PS: I'm sure you've made your choices for very good reasons so apologies for raising an alternate scheme at this stage. While a character-mapped display is speedy and memory efficient it's often at the expense of logic count and flexibility. Just in case you hadn't considered - 16k will give 640x200 1bit, 320x200 2bit, 160x200 4bit. Apologies again, looking forward to the rest of the series. PPS: If you have a programable base-address for a bitmap display you can get pixel-character scrolling more-or-less for 'free' to help with an inevitably slower display that has to draw characters pixel-by-pixel in software. More 'registers' for pallets and an interrupt can get around a 'lack' of colours - more than 16k for a bit-mapped display on an 8-bit system could be sloooow.
Thanks for the suggestions! I have thought about graphics modes, sprites, scrolling, etc. However, I think there's a lot to be said for getting a "minimum viable product" done, and then adding more features in subsequent versions. Walk before you run, I guess :-)
Fun stuff! Looking forward to the end result! There is also a lot to learn from projects using 80's VLSI chip solutions such as NEC uPD7220/uPD72020, There are already a handful of homebrew projects using it, the chips are capable of both text and graphics modes but programming them is fairly complex. The other more modern take on VGA text mode I know of are also using dual port SRAM as you considered for yours. Bill Shen's retrobrew VgaxRAM project comes to mind. Good luck!
I would definitely consider a more modern/integrated display adapter if it could produce a signal that would drive a modern monitor (VGA or similar.) I actually ran across VgaxRAM when I did a web search for "IDT7134", so it's good to know there is an existence proof that what I'm considering is possible.
@@davehohacks In this case, you may want to check a few NEC uPD7220 projects. One posted on Hackaday (Dylan Brophy), the Z180GDC on retrocomputing forum (Andrew Lynch), and the Tavernier 6809 on system-cfg forum. May also want to look at projects based on EF9366-EF9367 (e.g., the kleincomputer GDP-64,) but I am unsure if VGA output is possible directly from it. Interestingly, with the right initialization, the uPD7220 is definitely capable of VGA output despite VGA not having been invented yet when it first appeared. And while complex and not trivial to program to use all their functions, there is quite a bit of documentation in form of user manuals, reference projects and code available. Enjoy the wonderful GDP/GDC/ACRTC rabbit hole, there is a ton of good stuff to learn...
Nice. I will follow the series. I do enjoy FPGA programming. I am still learning even after several years now at playing around w/ it. There is a huge learning curve and time commitment. A person still needs to understand digital logic to the degree you have shown here in LogSim. The FPGA is essentially doing the same thing -- you're simply describing the circuit at a higher level of abstraction. One thing I have found that has helped me a lot is to interface FPGA w/ retro CPU's and other chips, such as RAM, ROM, Video Controller, etc... Which turns out to be quite fun (for me). I learn how those components actually work at their core + how to write the FPGA to control them. But you have to work things out w/ simulation too. Quite important!
I do plan to come back to FPGAs at some point. I've heard good things about Verilator as a simulation platform. I'm actually kind of hoping that if I can get a display controller working using GALs and logic chips that the experience I gain might transfer to implementing something similar in an FPGA.
@@davehohacks And likewise you have sparked my interest in PALs and GALs. I get the idea of doing it the "retro" way. I actually do want to build a couple clone 8 bit machines w/o the use of FPGAs. However, I do believe that mixing retro w/ modern tinkerer/maker devices is fair game and a hobby in itself.
@@jamesross3939 Totally. My philosophy is that getting the job done is always more important than "authenticity", and if you're having fun, then by definition it's the right approach. And of course PALs were very commonly used back in the day (e.g., arcade machines, classic Mac motherboards, some PC motherboards), and GALs are just the "modern" equivalent.
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.
@@davehohacks Thinking about it a bit, if you are taking video requests, I would love to see a deep dive on the GAL and how to burn one. I really want to try my hand at a VGA circuit. I’m intrigued by the solution you came up with but im too ignorant on the subject to trust the search results which aren’t exact matches.
@@adamclark1928 I thought about making a dedicated video about GALs, so I will give that some serious consideration. They're pretty easy to get started with: buy some (I recommend 22V10s, so Lattice GAL22V10 or Atmel ATF22V10), get a programmer (both the TL866ii+ and T48 work well), use GALasm or Galette (search for "galette gal") to program your logic equation file into a .jed file, program it onto the device, and (as Dave Jones would say) Bob's your uncle. If you're just doing combinational logic, they're dead simple. If any of your outputs are registered, then your clock signal just needs to be on pin 1.
Check out James Sharman's VGA project, he's doing a similar thing but with only logic ICs and he has some really cool demos of what his circuit can do, just by exposing very specific signals of the GPU to his CPU, and he pulls off some really neat visual effects. Also, this has to be the first project like this I've seen where someone is actually opting to use the dual port RAM. The other popular options are either restricting access to VRAM to be during the vblank, and of course, using double data rate (i.e. letting the CPU access it on the rising edge of the clock and the video circuit have access on the falling edge, etc.) but for that, your system clock needs to run at some exact multiplier of your video clock. So downsides all around. It will be neat to see the dual port RAM solution. Also I've heard that dual port RAM is just like regular RAM but with extra logic and buffers and I'm wondering how that works. It would be neat if someone showed what logic is required to transform a regular SRAM bank into a dual port RAM bank... Anyway, cool project. I'm subscribed.
I definitely need to check out James Sharman's videos, although he's on a much higher level than I am, so it's a bit intimidating :-) I'm cautiously optimistic that the dual port RAM will work out. If you do a web search for "IDT7134" there's one hit where (IIRC) someone built a module that fits in a static RAM socket and uses an IDT7134 as a framebuffer to provide a VGA text output. So, quite similar to what I'm trying to do.
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 :)
Right, the intensity bit gets added to all of the color component values, so it de-saturates the color. I believe that this is how the CGA text-mode colors worked, aside from brown being a special case. I might revisit the DAC at some point if I'm not satisfied with how the colors look (e.g., if there isn't enough contrast between the non-intense and intense colors.)
Good to see you back in the saddle. I have a couple of points... A 6845 CRTC is defiantly capable of VGA frequency's (640*480) by slightly over clocking, and given your DIY computer is 6809 based wouldn't that be a more prudent choice? Also. even plain 1960's TTL is capable of 30+Mhz so LS TTL would be fine. Also Also, A monitor won't sync on green if it has two perfectly good sync signals ready to use! 🙂so you can over-scan. I used a 22V10 as a 4 of 12 mux to give a border colour like a Commodore 64 or ZX Spectrum. Looking forward to the next instalment.
Thanks! You could be right about most monitors ignoring color signals outside the visible area if there are valid sync signals, but I have an IBM POS monitor that gets very unhappy if it gets any non-black pixels outside the visible region. I should try LSTTL, that would be an interesting experiment. Interesting idea about the 6845: I've always sort of studiously avoided learning anything about it, but it totally makes sense that it would be an integrated solution for orchestrating a video signal, fetching character/attribute/font data, etc. But now that I'm on this particular train rolling my own solution I kind of want to see where it ends up :-)
I'm subscribing to see how you're gonna continue with this. Though it's kind of ... it's been done before and I'm not a fan of using GAL chips but I'm curious. I have to ask if you have considered going with DVI single link and designing a TMDS transmitter? You could cheat and use a ready made tmds transmitter and just feed it with the rgb bytes but the DVI standard actually supports 640x480 60 hz and 800x600 , and you only need a minimum of around 22.5 mhz for the link to be considered valid (and for 800x600 you need 40 Mhz)
I agree that lots of folks have done similar projects, but I guess I'm keen to figure out my own way to get a video display. I hadn't really thought of using digital video (DVI, etc.) since I'm familiar with VGA and it's still very easy to find VGA monitors. (I got one at one of our local thrift stores for $1 recently.)
Woot! A new daveho hacks! The V9958 I chose for my project is getting expensive. The FPGA solutions are tantalizing, but soo unapproachable. Considering using a pi pico which seems a tiny bit easier to learn, but then a retrocomputer project has a super-modern MCU as a peripheral, and it becomes a not-as-fun software project. :|
I feel like going with something like the Pi Pico makes a lot of sense if it gets the job done. It's not really any less "authentic" than the FPGA approach, and ultimately I think it makes sense to prioritize fun over authenticity. I definitely thought about the more modern MSX-type display controllers (9938, 9958), but like you said, they are getting pretty hard to source.
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.
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.
Color in VGA is analog: each color component (red/green/blue) is indicated by an analog voltage between 0V and 0.7V. So, there isn't really any inherent limitation on the number of colors, but from a practical standpoint, there needs to be a binary number specifying the pixel color, so the number of bits you dedicate to each pixel will determine how many distinct colors can be displayed. Regarding resolution, there are standardized timings for various modes (the website tinyvga.com is a good reference.) I believe that some of the lower-resolution modes like 320x240 are generated by making each pixel wider (e.g., two clocks rather than 1), and then doubling each scan line.
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.
It's very possible that parts of the design could be clocked at a lower frequency than the dot clock, although I haven't really considered doing that. If it allowed more of the hardware to work with 74HC/HCT parts rather than AC/ACT, that would be a significant advantage.
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.)
That's a good point. There are a couple of specific issues for me, though. One is that I'm reluctant to invest any time or energy into closed-source vendor tools that either might not work on my OS (Linux), or might not be available under reasonable licensing terms in the future, or both. The other is that I haven't invested the time to fully learn the workflow of any FPGA toolchain. I really do plan to return to FPGAs in the future, and I like the open-source IceStorm toolchain. I'm thinking that a way forward in the future might be Verilator for simulation and IceStorm for synthesis. But for now I'm having fun and making progress with GALs and 74ACT logic. Generally I need to spend quite a bit of time approaching a problem the wrong way before I'm able to appreciate the right way 🙂
good work dad👍
🎉
Dude, just take the plunge. I avoided FPGAs for years for all the reasons you mentioned (seemed complex -- simulations, timing, verification, difficulty probing, etc.) Once I forced myself through these issues (for what it's worth you don't HAVE to do simulations or verification, it's just smart to do so), I had a new, modern skill, that has proven extremely valuable. Also, for what it's worth, you can probe absolutely any signal you want -- you just have to send it to an output pin. Basically everything you were doing in Logicsim, you more-or-less can do in an FPGA tool chain (including graphical blocks with signals that you later associate code with, more or less just like a bunch of GALs, without the tedium of having to program them).
You can basically make your retro machine do anything with FPGAs. My most interesting project so far was retrofitting a TRS-80 Model 4 with HDMI and adding a programmable sprite layer over the top of the base output signal. I replaced a broken CRT in an old Model 4 with a custom FPGA board + HDMI LCD screen, fed the raster signals into the FPGA, got that upscaled to HDMI (it was originally a specialized RGB to HDMI project, because the 4 has some weird raster signals that can be switched on the fly between modes), and then realized it would be pretty trivial to add a data bus and an address bus decoder to give the Model 4 the ability to do anything I wanted to the video buffer, voila, colors and sprites. I then made some slight modifications and brought the whole thing over to a TRS-80 Model 1. That's right, color and sprites over HDMI on an 8-bit machine from 1977.
I will definitely revisit FPGAs at some point.
Exactly. I notice that you can buy one of those new Chinese FPGA boards, (Sipeed Lichee Tang Nano.) I mention this because even the cheap one @ around $12, has an LCD connector built into the board, and I'm pretty sure they have lots of example code to make it work. No need any more to re-invent everything from scratch, or spend $500 on a Terrasic board for that matter. I'm happy Dave made the video though, as it is very informative ... I just wouldn't do it this way.
FPGA programming may be a bit daunting to begin with, but seriously, once you've done all the work by setting up the entire application on Logisim, and implementing it with logic chips, writing the Verilog hdl should be trivial.
@@TH-camBorkedMyOldHandle_why I'm already thinking about replicating this design in an FPGA (assuming I can get it to work.)
Professional FPGA wrangler here... I would strongly suggest simulating things, else you can experience slight bugs like counters off by one, etc., so simulation is strongly recommended. My experience is with Xilinx or Lattice FPGAs, but they all have similar features.
One useful feature is ILA (integrated logic analyser, formerly ChipScope) to let you probe internal signals via JTAG - sounds scary, but it just works and you see waveforms from the FPGA. Don't forget you can always MUX debug signals out to a spare pin, too, to help with debugging.
@@m1geo Thank you for the advice! I do plan to use simulation on my next go-round with FPGAs. I have brought signals out to external pins before, and that definitely has been useful. The internal logic analyzer functionality sounds great, although I stubbornly refuse to use closed-source vendor tools, which might limit my options.
Great work me and your son are friends, your a smart man
Wow, thank you!
This is good stuff, Dave! Following this one with interest!
Thank you!
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.
I'm definitely planning to return to FPGAs in the future, and I am confident that simulation will help tremendously.
nice project, subscribed
Thank you!
Great video, Dave. This is something I've also wanted to do for a while. My in-between step has been to use a Pi Pico. Very much not in the spirit of retro, but an easy way around many of the issues with the TMS9918A and much simpler to understand than the FPGA. Looking forward to your progress on this. If you need further inspiration for a discrete logic VGA circuit, I highly recommend checking out James Sharman's build (if you haven't already). Super impressive, and he's managed to go without the dual port SRAMs too.
The Pi Pico is an amazing little microcontroller.
Thanks, Troy! I like the Pi Pico idea quite a bit, actually, and there's precedent for even "classic" peripheral ICs to be implemented as an embedded micro running firmware (I think the Intel 8271 floppy controller works this way). I also agree I should check out James Sharman's videos. Maybe I'll do that once I get my display controller working, so I can see how someone who actually knows what they're doing would approach the problem :-)
I need to check out the Pi Pico, I've heard good things.
@@davehohacks I emulated my entire HBC-56 on a single Pico. If you haven't seen it, take a look at my PICO-56 Intro or build vids.
@@davehohacks I think you'll really like it, especially for something like this. The PIO module is really cool in that it does its thing asynchronously and the "code" that they execute gives you loops without branching delays. It reminds me of my Honeywell mainframe days. The mainframe's Input/Output Multiplexer did something similar for handling peripheral accesses. When you invoked it through a system call (MME), you passed a little "script" telling it how to move data from its internal buffers into system RAM. The PIO module in the pico is much more powerful since it incorporates configurable state machines.
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.
I have a monitor that does that (freaks out if there are color signals outside visible area) too!
In my project I use 74LS parts and target a 384x264 screen, with suitable variable border areas. That resolution is definitely more feasible and includes multiple display planes, sprites, scaled sprites, vectors, and scaling/rotating of tiles. It is however using many hundreds of 74LS parts. :)
Very interesting, subscribed to keep an eye on developments. Thank you.
PS: I'm sure you've made your choices for very good reasons so apologies for raising an alternate scheme at this stage. While a character-mapped display is speedy and memory efficient it's often at the expense of logic count and flexibility. Just in case you hadn't considered - 16k will give 640x200 1bit, 320x200 2bit, 160x200 4bit. Apologies again, looking forward to the rest of the series.
PPS: If you have a programable base-address for a bitmap display you can get pixel-character scrolling more-or-less for 'free' to help with an inevitably slower display that has to draw characters pixel-by-pixel in software.
More 'registers' for pallets and an interrupt can get around a 'lack' of colours - more than 16k for a bit-mapped display on an 8-bit system could be sloooow.
Thanks for the suggestions! I have thought about graphics modes, sprites, scrolling, etc. However, I think there's a lot to be said for getting a "minimum viable product" done, and then adding more features in subsequent versions. Walk before you run, I guess :-)
Cool project! Subscribed.
Thank you!
Welcome back! Love your new project ideas.
Thank you! I'm excited to be actively working on this stuff again.
Fun stuff! Looking forward to the end result! There is also a lot to learn from projects using 80's VLSI chip solutions such as NEC uPD7220/uPD72020, There are already a handful of homebrew projects using it, the chips are capable of both text and graphics modes but programming them is fairly complex. The other more modern take on VGA text mode I know of are also using dual port SRAM as you considered for yours. Bill Shen's retrobrew VgaxRAM project comes to mind. Good luck!
I would definitely consider a more modern/integrated display adapter if it could produce a signal that would drive a modern monitor (VGA or similar.) I actually ran across VgaxRAM when I did a web search for "IDT7134", so it's good to know there is an existence proof that what I'm considering is possible.
@@davehohacks In this case, you may want to check a few NEC uPD7220 projects. One posted on Hackaday (Dylan Brophy), the Z180GDC on retrocomputing forum (Andrew Lynch), and the Tavernier 6809 on system-cfg forum. May also want to look at projects based on EF9366-EF9367 (e.g., the kleincomputer GDP-64,) but I am unsure if VGA output is possible directly from it. Interestingly, with the right initialization, the uPD7220 is definitely capable of VGA output despite VGA not having been invented yet when it first appeared. And while complex and not trivial to program to use all their functions, there is quite a bit of documentation in form of user manuals, reference projects and code available. Enjoy the wonderful GDP/GDC/ACRTC rabbit hole, there is a ton of good stuff to learn...
Nice. I will follow the series. I do enjoy FPGA programming. I am still learning even after several years now at playing around w/ it. There is a huge learning curve and time commitment. A person still needs to understand digital logic to the degree you have shown here in LogSim. The FPGA is essentially doing the same thing -- you're simply describing the circuit at a higher level of abstraction. One thing I have found that has helped me a lot is to interface FPGA w/ retro CPU's and other chips, such as RAM, ROM, Video Controller, etc... Which turns out to be quite fun (for me). I learn how those components actually work at their core + how to write the FPGA to control them. But you have to work things out w/ simulation too. Quite important!
I do plan to come back to FPGAs at some point. I've heard good things about Verilator as a simulation platform. I'm actually kind of hoping that if I can get a display controller working using GALs and logic chips that the experience I gain might transfer to implementing something similar in an FPGA.
@@davehohacks And likewise you have sparked my interest in PALs and GALs. I get the idea of doing it the "retro" way. I actually do want to build a couple clone 8 bit machines w/o the use of FPGAs. However, I do believe that mixing retro w/ modern tinkerer/maker devices is fair game and a hobby in itself.
@@jamesross3939 Totally. My philosophy is that getting the job done is always more important than "authenticity", and if you're having fun, then by definition it's the right approach. And of course PALs were very commonly used back in the day (e.g., arcade machines, classic Mac motherboards, some PC motherboards), and GALs are just the "modern" equivalent.
you are alive!!
Indeed!
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.
That is a really good idea!
welcome back! you were missed.
Thank you!
@@davehohacks Thinking about it a bit, if you are taking video requests, I would love to see a deep dive on the GAL and how to burn one. I really want to try my hand at a VGA circuit. I’m intrigued by the solution you came up with but im too ignorant on the subject to trust the search results which aren’t exact matches.
@@adamclark1928 I thought about making a dedicated video about GALs, so I will give that some serious consideration. They're pretty easy to get started with: buy some (I recommend 22V10s, so Lattice GAL22V10 or Atmel ATF22V10), get a programmer (both the TL866ii+ and T48 work well), use GALasm or Galette (search for "galette gal") to program your logic equation file into a .jed file, program it onto the device, and (as Dave Jones would say) Bob's your uncle. If you're just doing combinational logic, they're dead simple. If any of your outputs are registered, then your clock signal just needs to be on pin 1.
Check out James Sharman's VGA project, he's doing a similar thing but with only logic ICs and he has some really cool demos of what his circuit can do, just by exposing very specific signals of the GPU to his CPU, and he pulls off some really neat visual effects. Also, this has to be the first project like this I've seen where someone is actually opting to use the dual port RAM. The other popular options are either restricting access to VRAM to be during the vblank, and of course, using double data rate (i.e. letting the CPU access it on the rising edge of the clock and the video circuit have access on the falling edge, etc.) but for that, your system clock needs to run at some exact multiplier of your video clock. So downsides all around. It will be neat to see the dual port RAM solution. Also I've heard that dual port RAM is just like regular RAM but with extra logic and buffers and I'm wondering how that works. It would be neat if someone showed what logic is required to transform a regular SRAM bank into a dual port RAM bank... Anyway, cool project. I'm subscribed.
I definitely need to check out James Sharman's videos, although he's on a much higher level than I am, so it's a bit intimidating :-) I'm cautiously optimistic that the dual port RAM will work out. If you do a web search for "IDT7134" there's one hit where (IIRC) someone built a module that fits in a static RAM socket and uses an IDT7134 as a framebuffer to provide a VGA text output. So, quite similar to what I'm trying to do.
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 :)
Right, the intensity bit gets added to all of the color component values, so it de-saturates the color. I believe that this is how the CGA text-mode colors worked, aside from brown being a special case. I might revisit the DAC at some point if I'm not satisfied with how the colors look (e.g., if there isn't enough contrast between the non-intense and intense colors.)
@@davehohacks In fact, this simple palette looks quite attractive. Especially if you adjust DAC network alittle, if necessary.
@@TomaTLAB We'll see how it looks once I (hopefully) get some characters displayed.
Good to see you back in the saddle. I have a couple of points... A 6845 CRTC is defiantly capable of VGA frequency's (640*480) by slightly over clocking, and given your DIY computer is 6809 based wouldn't that be a more prudent choice? Also. even plain 1960's TTL is capable of 30+Mhz so LS TTL would be fine. Also Also, A monitor won't sync on green if it has two perfectly good sync signals ready to use! 🙂so you can over-scan. I used a 22V10 as a 4 of 12 mux to give a border colour like a Commodore 64 or ZX Spectrum. Looking forward to the next instalment.
Thanks! You could be right about most monitors ignoring color signals outside the visible area if there are valid sync signals, but I have an IBM POS monitor that gets very unhappy if it gets any non-black pixels outside the visible region. I should try LSTTL, that would be an interesting experiment. Interesting idea about the 6845: I've always sort of studiously avoided learning anything about it, but it totally makes sense that it would be an integrated solution for orchestrating a video signal, fetching character/attribute/font data, etc. But now that I'm on this particular train rolling my own solution I kind of want to see where it ends up :-)
I'm subscribing to see how you're gonna continue with this. Though it's kind of ... it's been done before and I'm not a fan of using GAL chips but I'm curious.
I have to ask if you have considered going with DVI single link and designing a TMDS transmitter? You could cheat and use a ready made tmds transmitter and just feed it with the rgb bytes but the DVI standard actually supports 640x480 60 hz and 800x600 , and you only need a minimum of around 22.5 mhz for the link to be considered valid (and for 800x600 you need 40 Mhz)
I agree that lots of folks have done similar projects, but I guess I'm keen to figure out my own way to get a video display. I hadn't really thought of using digital video (DVI, etc.) since I'm familiar with VGA and it's still very easy to find VGA monitors. (I got one at one of our local thrift stores for $1 recently.)
Woot! A new daveho hacks! The V9958 I chose for my project is getting expensive. The FPGA solutions are tantalizing, but soo unapproachable. Considering using a pi pico which seems a tiny bit easier to learn, but then a retrocomputer project has a super-modern MCU as a peripheral, and it becomes a not-as-fun software project. :|
I feel like going with something like the Pi Pico makes a lot of sense if it gets the job done. It's not really any less "authentic" than the FPGA approach, and ultimately I think it makes sense to prioritize fun over authenticity. I definitely thought about the more modern MSX-type display controllers (9938, 9958), but like you said, they are getting pretty hard to source.
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.
Thanks! I think GALAsm only supports the Lattice GAL devices (16V8, 22V10, 20RA10) and compatible devices (like the ATF22V10.)
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.
Color in VGA is analog: each color component (red/green/blue) is indicated by an analog voltage between 0V and 0.7V. So, there isn't really any inherent limitation on the number of colors, but from a practical standpoint, there needs to be a binary number specifying the pixel color, so the number of bits you dedicate to each pixel will determine how many distinct colors can be displayed. Regarding resolution, there are standardized timings for various modes (the website tinyvga.com is a good reference.) I believe that some of the lower-resolution modes like 320x240 are generated by making each pixel wider (e.g., two clocks rather than 1), and then doubling each scan line.
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.
It's very possible that parts of the design could be clocked at a lower frequency than the dot clock, although I haven't really considered doing that. If it allowed more of the hardware to work with 74HC/HCT parts rather than AC/ACT, that would be a significant advantage.
@@davehohacks I was mostly thinking about possibly less components, but that's just an intuition. That would need to be assessed...
@@RelayComputer That makes sense. Having to use fewer counter bits would be nice.
zelda dlc over vga is crazy
Tears of the Kingdom is an incredible game. I regret nothing :-)
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.)
That's a good point. There are a couple of specific issues for me, though. One is that I'm reluctant to invest any time or energy into closed-source vendor tools that either might not work on my OS (Linux), or might not be available under reasonable licensing terms in the future, or both. The other is that I haven't invested the time to fully learn the workflow of any FPGA toolchain. I really do plan to return to FPGAs in the future, and I like the open-source IceStorm toolchain. I'm thinking that a way forward in the future might be Verilator for simulation and IceStorm for synthesis. But for now I'm having fun and making progress with GALs and 74ACT logic. Generally I need to spend quite a bit of time approaching a problem the wrong way before I'm able to appreciate the right way 🙂