VGA from an EPROM, is it possible. 

Loved my GeForce GTX 460 a lot. Really stable card and surprisingly capable for the time. Thank you for your work on that!

This video appeared in my recommended videos. Just from the title and screenshot, not yet having watched your video, I recognized that you might be using a ROM sequencer, a technique which I love and I myself used before in the early 80s to create fast complex control circuits in place of using a slower and more expensive microprocessor where the algorithm was straightforward and repetitive. Such designs were common in tech companies in Southern California that I worked for in those days. A few years later I was using PALs to do similar things. I might be wrong, as I'm writing this before having watched your video as I wanted to reply to your request as to how I found your video. 😊

This was very interesting for me. I have been scouring youtube for videos on how to design VGA circuits for retro computers. I have seen this type of formula before. First time I have seen it using eproms. It gave me a couple aha moments so I will need to study this video several times. Thanks for all your hard work.!

The way you configured latch, the way you drive the RGB outputs, and even the control signals using only ROM data and avoiding as much logic calculation in the components as possible were very helpful. Thanks!

Out of interest (for my benefit), to anyone who had just discovered this channel for the first time, how did you find it?

Thanks Ben Eater... as I can now enjoy a video such as this, and follow along with most of it. Thanks Matt for your pleasant walk through style and the detailed information.

Congratulations on getting so many viewers for this video. Your material deserves an audience. I liked how you stored the next pixel address in the EEPROM. That simplified your circuit compared to similar projects I've seen. They usually use external counter IC's plus logic to reset the counters. Your approach has a much smaller part count.

I used this technique (loosely) to make a ballistics bullet speed display with selectable fps/mps display on an LCD. it was also just an EPROM and some latches at its heart. It's a lovely technique, simple and reliable. Thanks for sharing this.

Man I wish I had you during my college years . Great explanation !!

Really great video and nice implementation. If only I had this kind of info when I tried bit banging basic VGA video on microcontrollers in the mid 1990s :) Would have saved me many weeks of hair pulling !!

4:24 отличное разъяснение! Nice explaining!

Great application of this technique. Woz built his Apple II floppy disk controller around a 256-byte PROM-based logic sequencer similar to this. The rest is software running on the Apple II host to manipulate an 8-bit command register. It saved dozens of chips and made the disk controller very inexpensive compared to contemporary ones. I'm sure you already knew this but it is a fascinating example of lateral thinking nonetheless.

This was very cool cool. thank you so much!

Your channel is 10/10

just found it. I'll be doing something similar in the next few weeks but rather than encoding an FSA using EPROMs, I've got a counter-based solution in mind. Just like you,all on bread boards so so many fun and games in the countless hours tracking down bad connections, mis-wiring, defective/toasted components, missing jumpers and bent legs and the like...😂 Really like your approach and explanations though. Please keep going!😊

Was just in my recommended 👍

Awesome video.

Neat! Now I wanna try something like this too

Now this is the kind of content that gets me rock hard.

Very very nice!!!

Darn. You're my hero!

Wow, it's literally been decades since I've seen anyone write GDI code :)

Nice build, I wondered about doing this a while ago as I had a need for a static image, the only thing extra I would have needed was a PAL encoder chip and different timings.

13:15 this is why I often use simple constexpr functions for doing odd bit manipulation like this. You could have something like the following (ignore the bad name): constexpr int getColorBits(int value, int color){ return (r&0xe0)

Excellent!

Interesting reminds me of how James Sharman started his VGA project. Except he used a ROM to handle the sync timings only but not the frame buffer.

interesting yt reccommended, very interesting

nice job!

It was fun. Love it. Figured out what's actually going (how it's EPROM?) when you ran VS2022 ) P.S. what's for timings issues 13:54 it's not actually correct : as I can see on M27C322 spec the ACCESS TIME: 80ns and PROGRAMMING TIME: 50μs/word; so it's actually even worse than I thought it's actually 80 ns for reading. But I think this time might be overrun by 'multiplying' this scheme. The idea is to split it to 2 parallel 'nodes' to read every second pixel from the second one while the first one is still being processed. It should give you exactly 40ns per pixel you need. It might ) I need to think over it; thanks again for the fun!

We’ll blow me down with a feather, but I’m impressed!!

thank you very much for making this video! I'm a computer engineering student and am currently making a VGA circuit that small and compact to go with my other projects. Say do you know how I could make a hardware text mode for these circuits?

I got this far with my thinking after watching your Apple II video generation series, and worked out that you could interleave EPROMs to generate full-resolution VGA, and then skipped past that to a RAM framebuffer. I even went the next step of working out making each pixel be a palette entry of 2048 colors. It fell down rapidly after that because designing a tiler engine is non-trivial at any resolution without resorting to CPLDs/FPGAs, and that's a bit beyond my ken for now.

Great!!👏👏

Awesome

When it's a green monochrome monitor it's referred to as a Rasta beam.

Poor ben eater. His card is now basically obsolete. Micronization got up to him

"Ok, that doesn't seem to work." Lol. As a fellow Australian programmer, this just sounded so familiar haha.

That EPROM isn’t available / in stock is it? I looked for some DIP EEPROMs and the ones available ( X28C512P-12 ) are pretty low capacity (64K x 8 bit) and slow (120 ns). Also I was starting to wonder how I’d build something that can support higher resolutions. Maybe some kind of RAM instead and you’d copy the ROM to RAM (with a CPU?) at startup to get the video working. Or using multiple EEPROMs and somehow divide the clock between them! I have an FPGA (Digilent Arty, with VGA PMOD hooked up to it) and it can put out 1080p VGA signal (148.5 MHz pixel clock), maybe even higher. But I hate the tool chain and dependencies involved (Vivado in my case, for Xilinx chips).

Cool !!!!!!

Well, given the design that you gave, the memory structure is a linked list. I'm sure you used it to simply the writing of the video memory on the CPU side by using row, column addressing which is convenient for addressing pixels. To make it contiguous, you'd have to set the pointer of the "next address" portion into the next address. Now, if you were not including the H-Sync and V-Sync as part of the contiguous region, I would imagine you'd need to have an additional counter, either as circuit or some sort of "microcode" that would drive the syncs and possibly the front and back porches via run-length encoding which would take up less memory. If doing that, I'd probably eschew the linked list pointer and pack 2, 2, 2, 1, 1 for R,G,B,H,V, as 8 bits. I imagine you could use the lower ROM for the actual video memory, later to be replaced with RAM. Then might could treat the other ROM as a state machine to do the counter, which while still practically the linked-list in practice, wouldn't be used as addressable to CPU. With that sort of design, might could have multiple ROMs that represent different "video modes" and use some sort of I/O address on the bus to select which ROM via a pair of latches to instantly change the resolution. Either way, would need to be careful of only updating lines that aren't scheduled for immediate render since it could create artifacts (I assume the cause of the CGA render bugs from my childhood); although, I suppose it could be a "feature" if exploited for controlled special effects. Speaking of latching, might could have multiple resistor banks coming off the R,G,B links and use another I/O to swap them using the lines currently tied to ground so you can vary the palette a bit and a few AND gates (at least in theory). I hope my thoughts on it was in the ballpark.

Hello Dr. Reagan. It seems like the 27c322 has been discontinued for some time. Do you know where to get it or any other good replacement for the memory chip? Thank you very much

Great video What is the EEPROM program u are using at 13:33 to debug if your VGA generation is working? Also how can you write a paper on something that is interesting to you? For instance: I am interested in transmission and receiving of analog audio and picture (CQUAM Stereo, PAL, NTSC, etc) But this is old and everyone wants digital nowadays so are there any guidlines on how to express this diferently so it would seam like something new and exiting, rather then giberish that some lunatic that is living in the past is writing about Sorry for wierd question I hope you understand it TLRD: how to take some old concept and turn it into something new and exiting that could be good enough for a research paper?

Is the integration video out yet? I tried to find it on YT, but didn't see it.

Cool video, though I’m not sure I entirely understand. Is that starman frame-buffer stored in the EPROM? Or is it coming live from somewhere else? Wonder what it’s like to bit-bang DVI, considering most non-CRT monitors have digital circuitry in them anyhow.

4:44 I don't think I could understand it clearly, but why set the horizontal sync, and the vertical sync at the INactive region instead of simply setting them at the *active* region?

I wonder what if would look like if you errased it while it was displaying an image

Since the whole frame is one big linked list so the words can be in any arbitrary order, including contiguous. The chosen order just makes it simple to generate the data.

oh ... good idea.

How feasible would this translate this model to DVI? I guess the speeds required would require much faster parts.

💥👍💥

c128 80 colunm any chace? NTSC RGBI

7:51 with one more eprom could you then get 8 bits per colour ?

Vga? From EEPROM? Ben Eater did this, it was pretty interesting 👍

Hmmmm. Could I get a motherboard with no CPU to do video out by violating the BIOS chip..? Need to look into what exactly requires the cpu, and what it can do without one. Curious if a modern chipset could be powerful enough to run doom. I feel like it’s a necessity for a good CMPE undergrad to get doom running on something new and I dont think anyone’s done an empty motherboard yet.

❤❤❤❤❤

Glad you liked it. If you're a Ben Eater fan you might like this ru-vid.com/group/PLjQDRjQfW-85S5QkX8wZbkqichM6TLYYt playlist

Seems like using a eprom for address rather than a counter seems expensive. You could probably bit bang out the signal using a cortex M0 nowadays. I did a greyscale NTSC video overlay for drones years ago using an M0. It ran fine.

Seems like a huge pain in the ass to generate NTSC with code. I still use an old 80s B&W television set that does all of this, purely analog, with a few handfuls of components and some good old fashioned high voltage to watch my old black and white movies. Sometimes nothing beats simplicity.

Why did you leave NVIDIA and what are you doing now?

have you ever considered making a low resolution HDMI circuit or is that not possible with these parts?

So I guess, for "changable" video, the data should come from ram, but pointer and all other stuff can still come from little eeprom? I mean the whole can come from ram, but sounds a bit wasteful. Very interesting idea!

How much bitcoin can it mine?

Am I missing something here... okay, yes, I am.... An Eeprom stores the image and and the code... but what's running the code? Where's the processor ??? And then, the Eeprom's binary output is just dumping right out to those HC whatever chips which turn logic level into something VGA can use ?

So, using sram instead of eeprom here and you have a display adapter :)

well hello...

Question. Why does the order of D0-D15 matter? If you write the data in any decent, order you should get the data out the same way. It's almost the same for the address lines, but since each address line could enable a bank, the reading delay won't be the same. This is very important for DRAMs since their addresses are multiplexed. Any reasonable arguments?

Ben eater did something similar

Why don't just use a counter? 😅

hm, if you used static ram instead of a rom, could add in sprites, cursors , text data etc by using extra memory for sprite and char lookup data. would also give you a direct way to update image data. if you offset the address bus via a secondary 'rom' lookup, text or image scrolling

It is a novel approach. Clearly quite simple and flexible, but also wasteful (~90% of memory is either unused or wasted for next address values). Still, its simplicity is why it is nice. Using binary counters and comparators for row and column, plus an adder (if the number of columns is not a power of 2) to fit it a contentious region, and no next addresses would be easy too tho. Another option is to have EPROM still for generating control signals, but RGB data stored separately. Like James Sharman 8-bit computer.

So many loops