Hi all—

I've been working on a VGA interface for my SBC and I've finally managed to make some progress, so I thought I'd share and ask for some advice. In this post, I wanted to talk a bit about design choices and theory of operation, and then I'll write a follow-up post with some questions around a couple bugs that are stumping me a little bit.

The schematic is attached below. For now, I've decided to forego an attempt at interleaving RAM access between the CPU and the pixel clock circuit, and instead relegate CPU memory access to the blanking interval. I thought this was going to be much worse than it's turned out to be, so for now it's “good enough.”

The interface's operation is pretty simple. Borrowing from George's approach, five four-bit counters (U1-U5) are fed a 25.175MHz clock and use a 64kB EEPROM to generate the signals needed to synchronize the system, including horizontal and vertical sync, and three different blanking signals (I'll explain this in a bit). The counters are also buffered (U6-U8) so that they can share access to the main memory (U16) with a PIC18, which acts as a GPU of sorts (the idea being that my SBC can talk to it through a 6522 and ask it to perform advanced commands like, say, drawing primitives and managing sprites). The PIC, in turn, controls four '574 octal latches (U12-U15) that it uses to access the RAM's address and data buses. When it wants to take control of the bus, it brings /VD_SEL low, which turns on the latches and turns off the counter buffers.

The output of the RAM chip feeds to another '574 (U10), which is latched to the falling edge of the 320px per line clock, and whose output enable is tied to the blanking signal coming out of the EEPROM; the '574 is then connected to a resistor ladder, which goes out to the VGA connector, giving 8bpp colour.

There are two additional blanking signals coming out of the EEPROM. The first, /MCU_BLANK, is shortened by a few pixels so that the PIC can always just check whether it is in a blanking interval and have enough time to complete a pixel write cycle. If I were to rely on the regular blanking interval, there would be no way of telling whether there is enough time to write a pixel before control needs to go back to the counter because a new row has begun, and thus the code would always have to wait for the beginning of a new blanking interval before accessing the memory, which is very wasteful. The other blanking interval is triggered only on vsync, with the idea that it can be tied to the interrupt line on the SBC to help sync graphics updates with the monitor's frame rate.

Here's what this circuit looks like on a breadboard. Behold the nest of rats! (Bonus PIC18 hanging at the bottom because I ran out of space.)



I'm sure this can be simplified a great deal, and I would love everyone's feedback on improving it, but it seems to work quite well overall; the picture is very stable, and there is only a minimal amount of jailbars that I'm not too worried about. I haven't really sorted out the SBC interface yet, but here's a video of the PIC driving it (apologies for the poor quality… it really does look pretty good in real life):



I'm not going to make a PCB out of this, because there are a couple of improvements that I still want to make. The first is to reduce the resolution to 320x240, which is more era-appropriate and cuts the amount of memory that needs to be pushed around in half. The second is making access from the PIC to the video memory's data bus bidirectional, so that the memory can be used to store useful data, like, say, sprite information. There should be enough pins left on the MCU to make this possible without adding another buffer, and it seems like a worthwhile addition.

A big bummer here is that I had to use an SMD part for the RAM… there just doesn't seem to be anything that's fast enough and comes in a DIP package…

As promised, a quick follow-up post with a plea for some help.

First, I would love feedback on the design (including feedback on the schematic itself… it's the first time that I share one with anyone, and I would like to get proficient at making them well-organized and readable).

Second, there are two nagging bugs that I'm struggling to figure out, and could really use some advice on which strategies to pursue.

Bug One is that the first three rows of the display are shifted to the left by a few pixels (this is really evident in the videos). It's as though the monitor has to catch up for a few lines before it's properly synced, but I think that I'm sending the sync signals and resetting the counters at the right times; besides, if the sync were off, I would expect it to be consistently off and the entire picture skewed.

Bug Two is that memory updates cause some random, spurious extra pixels to be written. You can see this in particular if you look at the Moiré pattern demo (the last one in the set), where some very obviously extraneous white pixels show up in the middle of the screen. I am quite puzzled by this, as the PIC's timing is quite slow compared to the 25ns SRAM chip, and when the PIC is writing to the memory it has full control of the bus. What's really confusing is that the number of spurious pixels shrinks (though never entirely) if I make the /WE pulse longer… which makes very little sense. I think it's clear I'm dealing with some kind of synchronization problem, but I'm not quite sure where to look for it.

I welcome all ideas—and thanks for reading!


—Marco


PS: Getting to this point took a lot of work, but it's been a huge amount of fun, and I wouldn't have been able to get this thing to work without all the help from here. Thanks so much!

Looks good to me, and I think the 320x240 resolution is just fine. There's always the trade-off (to me at least) between resolution and the number of cpu cycles needed to do something like draw a line... And even 320x240 at 4 bits per pixel is still about 38KB of RAM needed. (Plus a read/modify/write operation for each pixel which more than halves the pixel poke speed )-: )

Then there is the eternal problem is interfacing to the 6502 bus... It's never easy!

This is probably where folks might turn to an FPGA to start to simplify life, but if (like me) you're new to them, it's a fairly big learning curve on-top of what you've done already...

I did 320x240x1 in an ATmega when I first started my Ruby project but while it worked well it used far too many CPU cycles there, so some sort of hardware generator would have been my next step if I'd continued down that route.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I'll study the schematic in more detail when I have time, but at first sight I think it's a very sensible design, especially the resolution choice. The memory usage is always annoying for these 640x480-based resolutions as they don't fit within a power of two very well. 320x200 does, but that is usually based on the 640x400 video mode, and I had trouble getting modern monitors to cope with that properly so wouldn't recommend it.

However, you could consider embedding 320x200 or 256x240 into the existing 320x240 space, with borders, keeping the existing well-supported, square-pixel timings. 256x240 in particular is interesting because all coordinates fit within one 8-bit register, and the video memory calculations are much better suited for a 6502 this way. I've been thinking of using the extra space as a text display, e.g. a 16x40 window of 8x12 pixel characters - it could be really effective and maybe easy enough to add in at a later date.


I've had something very like this in the past, and I would suspect that it is indeed due to not resetting the counters properly at the end of the frame. The monitor is kind of OK with it but takes a few scanlines to resynchronise. If you use counters with synchronous reset, you need to send this reset signal from the ROM one pixel earlier, on the last "pixel" of the 800x525 frame. In my own latest designs though I use counters with an asynchronous reset, so I have to put the reset signal one "pixel" later in the RAM - at least as far as I remember. It was certainly an issue that had very similar symptoms to what you see here.

Another option is to change the order of things in the ROM so the reset happens during the vertical blanking period rather than at the end of it. Ideally you'd fix the sync issue anyway, but if not, at least this way it would not be visible.


I'll have a closer look at this later on, I've certainly run into this sort of issue a lot in the past! To prevent spurious writes it's important that you drive the address bus a certain amount of time before enabling WE (and ensure the counters stop driving that bus early enough and quickly enough), and potentially that after disabling WE you still hold the address and data buses in the right state. Bus capacitance won't work to hold the address steady if you immediately let the counters drive the address bus after WE goes high.

A while ago I made a spreadsheet to help me check the timing requirements all fitted within the cycle time I was using (and found that they didn't). It was quite useful for letting me experiment with different chip speed options and find the ones that did fit better.


It is great work and always good to see more people getting this kind of thing up and running!

I found a bit of time.

I think this kind of feedback is always going to be personal and controversial, but these are my thoughts:

1. I like colour in schematics, but I know that others don't and don't want to start any arguments over it

2. I like the top/middle/bottom split, that works very nicely

3. Don't join up all the GND and VCCs with lines - use multiple GND and VCC symbols nearer the individual ICs. You can join them when it makes sense but if you do it with long lines across the diagram it obscures the view of the actual signals that matter.

4. It'd be clearer if you put the VGA Output connector on the right hand side - but maybe there was a reason to fit it into a rectangular region.

5. The CPU_BLANK line goes through one of the ICs (U16) - don't do that. For this kind of thing I also probably wouldn't draw the line across the diagram, I'd just use a named label on the line to show the connection. It's a matter of preference though, whether it's easier to follow one way or the other.

And on the circuit itself:

1. The oscillator X1 should be 25.175MHz - probably just a typo though

2. 74HC163 (U1-U5) is maybe not fast enough for 25MHz, I'd use 74AC163s

3. The ROM outputs really ought to be buffered, I'm surprised it works so well the way you have it there (it didn't for me in my first goes at this kind of design). I'd use another 74HC574 to latch them on the next clock, to ensure that nothing gets confused by any slack or glitchy transitions in the EPROM's outputs. This goes especially for the monitor itself.

First off, great job Marco! Excellent work, I love it, and watch out because I'm right behind you



I just soldered my 'sync' board recently (also using '163s), and I used H799 and V524 and it works great. No issues at all there. Like George is saying, if you are using sync counters then you will probably want to use: H639, H655, H751, and H799, always one less than the value you were thinking. Same goes for the vertical timing. If you are using an EPROM for these signals, it should be easy to at least try that out?

As for the second bug, I think I agree with George, and I'm likewise making some modifications to my own future plans because of this. Thank you!



So I see you have 320x480 right now, and you want to go to 320x240? AND you want to minimize use of RAM? This was a big battle in my brain for a long time. I found a way using 'pixel counters' alongside the 'horizontal' and 'vertical' counters. So on 4 additional '163s just tie CEP to H-BLANK, and then tie /MR to V-BLANK (plus or minus whatever logic/inverters). That way you only count pixels in visible space, and you leave it in reset mode until you are ready for pixels again. It works (in theory) on my CPLD, though I haven't connected it to RAM. BUT to be able to then reduce 480 to 240 is tricky! I then added latches for it to save the pixel counter on odd number H-SYNC rows. That is, at H656 I latch on an odd row, but I always load the latch back into the pixel counter at H752. I just used the H-SYNC numbers because it was convenient and H640 and H800 seemed to push the bounds a bit too much. Since CEP is low during that time anyways, it doesn't matter when exactly you latch/load. I have to do a bit more tests with it because I think my pixels are shifted to the right by one, again that's the sync counters doing their thing.

On my future design I tossed that idea entirely and went back to what George and everyone else does: overscan with RAM. You want 320 x 240? Just use RAM for 512 x 256. This makes the 240 SO much easier to obtain without that 'pixel counter' idea from above. Sure it's a waste, but whatever.

I see you are using 25ns RAM. I'm planning on using 55ns SRAM for my design. My sync board has 55ns RAM and I don't see anything wrong with it right now. I, like you, am writing to it only during blanking periods, so there shouldn't be conflict while it's trying to display. I'm sure your PIC18 handles all the nitty gitty's, but I'm planning on tying V-BLANK to /NMI and hoping for the best!

Lastly, you are wanting to put this on a 6502 board eventually? Bill (plasmo) does a section of the memory map, banked, just for this video RAM. I'm also doing that in my current design, but my next one will be a 'latch' design: everything going through just a couple of bytes of I/O space, or even through a 6522.

Well, there's my experience, however limited it is. You have already outpaced me! Glad to see your creation, very well done.

Chad

Very cool!

Speaking from my own inexperience, I have to ask: what is the purpose of the network of inverters and capacitors at the bottom of the diagram?

Yes—I would love to get into FPGAs at some point, but building an interface using discrete logic also seems like a great way to learn how to build circuits better. Also, FPGAs are really expensive!

Thanks for the feedback!

The 0.1µF caps are decoupling capacitors; once you lay out the board onto a PCB, they connect between the VDD and VSS pin of each IC (or, at least, as close as possible to them) to provide rapid burst of current when the chip needs it. The 4.7µF caps are bulk capacitors, and they prevent voltage from the power source from dropping too far.

The inverters at the bottom are just unused gates from U17, tied to to ground to prevent them from floating, as well as the power supply for that same IC. I find that it's easier to represent logic gates individually on the schematic, rather than just use a generic rectangle for the whole IC… it just helps understand what the gate does, but it inevitably leaves a few gates unused, and so they have go somewhere. This is just a personal preference, though—I have definitely seen others use the whole-IC approach.

Cheers!

Thanks for the explanation. I think I get it - for clarity's sake, you're keeping the digital/logic portions of the circuits visually separate on the diagram from most other components, even if the components like decoupling capacitors will be physically adjacent to the chips on the actual board.

George, thank you so much for all this great and thoughtful feedback!



I have actually thought about this… I was thinking of adding a separate counter for the memory, which I think might also be used to prevent any memory from being used during the blanking interval (as I could just disable the counters when /BLANK is low). This opens up some interesting opportunities, because it would allow 320x200 to fit in a single 64kB chip. Have you tried anything similar? I worry about keeping the two counters properly synchronized.

Also—I hear you on the 640x400 woes. My monitor handles it, but it thinks it's a much weirder resolution (like, 720x480, which isn't even a real VGA resolution).



I was actually thinking about this last night after I wrote my post… I did verify that the reset bit is being flipped on the last pixel, but it's occurred to me that the sync ROM operates at 1/8th the clock speed, which means that, as far as the monitor is concerned, the count restarts seven pixels too early, so I wonder whether that might be the problem. I will try to reset at the beginning of the lines instead and see if being one pixel too late a similar effect in the other direction.

I have had a bit of trouble sourcing 74AC163s, btw… very hard to find unless you want to buy 1,200 of them



Yes, I figure that's something like that… I'm going to hook it up the 'scope and trigger it on the transition of the /OE lines between the counter buffers and the PIC latches to see what happens on the bus… it might be that I'm underestimating the time it takes for the signals to stabilize.



I remember watching that video! I think I may have to do the same thing (crazy to think that there isn't any kind of readily-available software that will do these kind of simulations automatically… you'd think that by now this kind of functionality would be fairly routine.)



Thanks again… your videos and posts here have been a huge help in understanding how things are supposed to work.

Yes, correct! I don't think anything bad would happen if the caps were right by each IC, but it would probably clutter things up too much, and the diagram is supposed to be a logical representation of the circuit, rather than a physical one.

Thanks for all this feedback as well, it's great and it's definitely going to help me make the next diagram easier to understand. I also prefer colours, but I know that some folks have trouble telling them apart, and so B/W seems like a more inclusive solution (though perhaps I could just attach both, and then everyone can use the one they like best).



I was also surprised to find out that the ROM didn't need any buffering, but it's probably a good idea to add it for the next iteration, or at least once I make a PCB out of this.

As for the '163s… as I mentioned, I can't seem to find any AC ones, though I just bought some 'AC161s, so maybe I'll experiment with those. FWIW, the frequency is within spec from what the datasheet says (Nexperia quotes minimum 27MHz at 4.5V, and typical 51MHz at 5V), so hopefully it's not too big a deal.

Cheers!

Thanks, Chad—I've been following your work with great interest as well, and it's great to see all the progress!



The challenge in my design is that the sync EEPROM runs at 1/8th the clock (~3.14MHz). I do pulse the reset line on the very last byte of the sequence, but that's still 7 pixels behind where the monitor will believe the frame should end. I'm going to try switching to '161s and then pulsing the sync bit at the beginning of the next frame to see whether that makes any difference (for better or worse).



Yes, indeed, I think he's right on the money on that one as well.



That's exactly what I have in mind. The objective is primarily to minimize the amount of RAM needed so that the 6502 (or the PIC) doesn't have to push too much around to animate things. Right now, it takes many seconds to clear out the entire screen, which is not a great experience



That's what I did here as well, because it leads to simpler design choices, which really helped while I was trying to learn how things work. Ultimately, though, if I find a way to, I'd really like to halve the vertical resolution, because I think it'll make for better graphics performance. I also suspect that I will want to add a text-only mode, because vertical scrolling with this solution… ain't happening



Agreed—I just really wanted to eliminate as many variables as possible, given how little experience I have with figuring out the timing of a circuit. I have some 55ns memory on hand as well, so maybe I'll try it for the next iteration.



Yes, eventually I would like this to be part of my SBC. Right now I'm leaning towards a completely uncoupled approach, where the 6502 communicates with the PIC, and then the PIC deals with the video part. I don't know how I feel about paging banks in and out of the 6502's main memory, TBH… on one hand, I don't want to stray too far from the 8-bit spirit, but on the other a lot of computers from the 1980s era had graphics co-processors, so I don't feel that bad about my little PIC

Thanks again for all your comments and help!

The BBC Master early 80's) had a "shadow" RAM system where the operating system could swap the video RAM for "application" RAM. The downside was that user programs could no-longer "poke pixels", but they had been discouraged from doing that since the first days of the BBC Micro in 1981. So the do stuff with the screen, you would call a routine in the OS and the OS would flip the memories, do the pixel poking and glip back again.

This technique wasn't new to the BBC Master as the BBC Micro had been doing it to enable "sideways" ROMS - essentially ROM space from $8000 through $BFFF was one of up to 16 ROMs (and latterly RAM images) and there was well defined mechanisms to call routines from one ROM to another via the OS. The OS lives in $C000 through $FFFF with a small space for IO decoded out. Video ram was essentially from $7FFF downwards with the largest modes requiring 20KB.

So I'd suggest you're right in the 8-bit spirit right before the fancier ones aimed more at faster games went for BLITTERs and Sprite engines....

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/