Hello everyone! I've been off doing my own thing for a while, and now back I come with a plan.

I've been inspired by Bill's (plasmo) discussion on Apple II style VGA graphics card: viewtopic.php?f=4&t=6955

So I am attempting something like that. 6502 accesses RAM on the high clock, VGA accesses RAM on the low clock.

My last attempt at VGA failed because of Video RAM access issues. I had stable timing and display, and VGA had clean access to RAM, but whenever I would try to change the image with the 6502, something would go wrong. I hope to prevent the same issues here.

Attached are my schematics in both color and B&W, and also my VCC/GND layout on the PCB, again in both color and B&W. I have run the auto-router already and it finishes in minutes (but optimizes via count for days!).

I am using 74HC' logic chips instead of a CPLD or something else convenient because I want to use this for training and educational purposes, granted that it actually works. I am trying to go for the most simplicity possible (as in, only 16K of Video RAM) while still retaining some basic features (as in, at least some color). I'm also going with a 2-layer board because of cost. I am able to increase the size of the board dramatically to accommodate all the chips without having a dramatic increase in price.

I've been through this thing a lot over the past weeks. I could have mistakes, but at some point very soon I'll just get it printed and test it out. If you want to check it over, I would appreciate the second set of eyes. But do not feel obligated. Making mistakes is how we learn!

Thanks everyone!

Chad

I think from the schematic it looks pretty sensible, and clocking it based on 8 pixels at a time should be comfortable enough that you won't suffer badly from propagation delays (things like the tranceivers having to switch back and forth).

Have you made a prototype already or are you going straight to PCB?

I think there may be an issue with the timing between U15 and U16. Firstly, you're using a latch at U15 - I think a flipflop would be better. The issue is that your latch is going to reload whatever is on the data bus throughout half of the eight-pixel cycle (when H4 is low), and for the early part of that time the data on the bus won't be stable (it takes a while for the transceivers U13,U14,U18,U19 to swap over, for the RAM to look up the new address, and for its data outputs to stabilise on the data bus as inputs to U15). In my designs I use a flipflop here and clock it at (or slightly before) the end of the half of the cycle when the video system owns the bus, so that there's been a whole half cycle of time for that data to become stable at that point, and we're about to release the bus to the CPU.

Another issue is with the timing of U16 - I tried something similar, for 320x480, using a quad 2-to-1 multiplexer to split out two pixels of data. The issue was that it's hard to ensure the multiplexer switches in sync with the point at which the new data is loaded into the latch U15 (or flipflop in my case, as I said above). In your case I believe this would be when H2 and H4 are both falling. The latch may operate faster than U16, and present new data before U16 changes which bits it is selecting; or slower, in which case U16 might change first, briefly outputting an old pixel value.

A solution to this is to put yet another flipflop on the other side of the multiplexer, clocked just after the multiplexer (and possibly the latch/flipflop U15) change state, so that there's a little time for both U15 and U16 to do their jobs and U16 to output the correct new signal. e.g. I think you could clock this flipflop with an inverted or otherwise slightly delayed H1 to achieve that. I would then pass HSYNC and VSYNC through that same flipflop, so that all transitions of the signals going to the monitor are in time with some master clock (in this case H1 rather than the VGA clock, but that should be fine as all the HSYNC boundaries are even numbers).

I didn't check the logic gates in detail but it also looks like your RAM is not active for the range that you stated in the notes on the schematic - it's only active for 0000-7EFF, and ~IO signal goes low for 7F00-7FFF, but the VIA is also only active for half that range because one of its CS lines is fed by A7. This might be fine, I just point it out because it differs from the notes.

First off, thank you for this VERY detailed response George. I really appreciate the time you took on it.



I'm so anti-breadboard right now that I have not made any prototype. I will be printing it and if it doesn't work, printing again later!



I had been thinking and debating this for a long while. Here's my quick reasoning, and then I'll elaborate on timing. A pro for the latch is that the pixel data from RAM is not changing during that low cycle anyways, so leaving LE high doesn't affect actual output. A con against the flip-flop is that the timing delay, that you were mentioning, could be off, resulting the wrong data being on the flip-flop, which would of course throw everything off.

But the point you are making is that the latch will have data from who knows where while the 244's are still switching over. Lets go through some timing:

First, H4 (which is PHI2) goes low. The 6502 is coming off of the address bus and counters are wanting on the address bus. The propagation delay on the 244's is 9ns and the enable delay is 13ns, so basically 13ns to get onto the address bus. Then it hits the RAM which is 55ns, then it comes back to the '373 latch at a total of 68ns. My full low clock is 158ns, so the data will definitely be latched! BUT what is the latch outputting before the 68ns? Before H4 went low, we had the previous color data. The propagation delay for LE to Q is 15ns, so I will definitely be putting something *else* on the latch for some time. Does that affect output? So H2 goes low and high every 79ns. So from H2 low to H2 high, we have only 11ns where the ACTUAL color data is on the latch, and with 15ns on the '153, well, disaster. After H2 goes high things are back to normal.

So indeed, there must be some other type of delay, as you were mentioning later, H1 could be used. Thank you for spotting this George.



So in a way, during your low PHI2, you are outputting Color Pixel 3, and then the new Color Pixel 0. PHI2 goes high and you are outputting Color Pixel 1 and then Color Pixel 2? I was thinking about this, and it seems like it would be an issue of consistency BUT because it's all continuous, it shouldn't matter. I might have 1 blank pixel on the left side, nothing to worry about.



The propagation delay for the '153 is 15ns, which is essentially the same as the '373. If there is any differentiation, we are talking not but a couple of nanoseconds. I know VGA is picky, but I don't think I could clean up a signal into the single digit nanoseconds. When exactly is the monitor accepting the incoming signal as the pixel color? At the very beginning?



Though of course this a great idea, is it required? How required? I am definitely able to get a nice solid picture without passing HSYNC and VSYNC through additional flipflops. My previous design was not bad in timing at all, the only issue was when I tried to *alter* the data. My reasoning then is that the monitor will display what it displays, and the signals don't need to be spot-on perfect. I am not a spot-on perfect kind of guy!

I definitely get what you are saying though. If they are all lined up, and you shoot them into the VGA all at the exact same time, there will never be any issues. Totally get it. I will be thinking about it George, thank you.



That was a BIG GOOF on my part! Sorry. I apparently had shifted everything over one hexa-digit. Correct, 7EFF, not 7FEF or something. Dyslexia The schematic is good, those notes were incorrectly typed. Thank you, I corrected them now.

So! The biggest question is: should I replace the '373 with a '374 instead? And if so, do I then use H1 to trigger the flip flops? I'll also be thinking about the '153, and perhaps a flip-flop after that one (with sync signals). Hm.

Thank you for this again George. I really appreciate it. I'll keep updating on changes. It was very good to have a second set of eyes!

Chad

No worries, I've spent quite a bit of time working on video circuits recently, learned a lot, and like thinking about different ones.


Be careful with saying the pixel data from RAM is not changing - the problem here is that at this specific point in the cycle, it very much is changing!


... plus the propagation delay of the inverter that's driving LE...

Yes, one way or another there's potentially a rather long period (more than one VGA pixel) during which the data you want to output is not available yet. Towards the start the latch is probably just still outputting the previously-held data; after its propagation delay is mostly complete it will start mirroring (and amplifying) whatever it can see on the data bus, which might be the last thing the CPU put there, or whatever data the RAM is outputting while it's receiving the wrong addresses, or not looked up the right data yet.


You could maybe drive LE such that it's high only when H4 is low and H2 is high simultaneously, so it doesn't latch new data until the second half of H4 being low. There's still potentially a brief period where the data isn't stable yet, it depends a bit though whether the RAM is being relatively fast - and from what I've seen in my own circuits, yes, the 55ns RAM tends to actually perform quite a bit faster. Bear in mind the timings in the datasheets aren't specifically reliable, they're just typical good/bad/average cases, often observed experimentally, and your actual silicon may vary in performance.


Not exactly, as I was only outputting two pixels per cycle (but at twice the cycle rate you're using, so the same resolution). But in principle, yes. Regarding the one blank pixel, analog input monitors will auto-adjust and compensate for it. But equally, this is also why I suggested feeding everything - including HSYNC and VSYNC - through a final flipflop to delay the actual signals going to the monitor by a consistent amount across the board.


For me it was really noticeable - see here for example: https://youtu.be/8Vbphmf4Ocw?t=1113 This is again just picking between two pixels within each cycle, but you can clearly see fragments of the wrong pixel getting displayed in some cases. Adding more inverters delays the signal by about 5-10ns each, I'd guess.

Bear in mind that even though you say those two parts have the same propagation delay, you kind of want to not start the multiplexer's propagation until the end of the latch's propagation, so that the multiplexer's input-to-output propagation overlaps with its selection input propagation - if that makes sense?


Yes, it's not exactly required - as I said above, VGA monitors tend to auto-adjust for this anyway. It's just that if you were already using an output flipflop there, you might as well put the other signals through it as well, and it would fix the mulitplexer sync issue pretty thoroughly I think.


Yes, lots of options. Using a shorter LE time with the latch will give similar results to a flipflop in any case.

Something else to watch out for - your write-enable signal seems to be changing in sync with PHI2. Normally this is fine in a 6502 build because the CPU is already outputting the address to the address bus ahead of this point. However, in your circuit that address is being blocked by the transceivers and the RAM has previously been supplied with a different address, from the video side of the circuit. So when H4 goes high, lots of things happen at once:

• PHI2 goes high
• ~WE goes low (during a write cycle) after one NAND propagation delay
• ~OE on the video counter transceivers goes high, so they begin to stop driving the address bus
• ~OE on the CPU transceivers goes low after one inverter propagation delay, at which point they begin to start driving the address bus

From the RAM's perspective, it will spot ~WE going low after one NAND propagation delay, and start trying to write whatever it sees on its data pins to wherever is specified on its address pins. This might be too early as the CPU transceivers might not be active yet. In theory I think you need to wait for:

• inverter propagation delay between H4 and CPU address bus transceivers' ~OE signal
• CPU address bus transceivers' ~OE-to-output-valid propagation delay
• RAM address setup time, if any

before you let ~WE go low. Otherwise I think you risk writing data to random memory locations, which may only happen sporadically and will be hard to debug.

Also note that all your address decoding is dependent on the transceiver outputs being valid, and for something like the 6522 that could also cause problems during read cycles, if it sometimes receives spurious read requests, as they can have side effects. It may be better to wire at least the non-RAM address decoding direct to the CPU address bus. Normally this isn't an issue in 6502 computers because the address bus is stable well before PHI2 begins, leaving time for address decoding to complete before that point.

George, this was very good information. And you are completely right. Thank you for that.

The information in particular about the /WE signal was very enlightening. Again you are right on. It is making me rethink the entire layout now, honestly. This 'double duty' RAM is very difficult to pull off, particularly with timing issues.

I noticed in your video that you were using those inverter gates for their propagation delay effect. Though of course that is useful, I have been warned many times to not do that. Not that you cannot, I believe you are using a breadboard anyways, which can easily be changed around to fit the particular needs. Like you said, any one's particular silicon will act a little differently.

Because of this, I'm going back to the drawing board. I have another idea for accessing Video RAM, similar to what I attempted last time. And though it might end up clunky, I won't have so many timing issues and other unknowns (such as just how fast is my 55ns RAM, just how many inverter gates I should be using, etc).

After I look it over a hundred times and check my timings, I'll repost it. It will not be the same computer!

Thank you again George, this really helps.

Chad

As in my videos, you can make relatively simple circuits that do work like this, but yes there are a lot of timing issues you need to get right. So although the part count can be low, there's still an intricacy that's hard to think through. It is also much easier if you use a simple PLD to manage and configure these things, as you tend to get more consistent results and you can also change the timing without having to change the circuit.

My mental model is separating the cycle into two halves, obviously - one for video and one for CPU access - but then splitting those halves into a kind of "get ready" part and a "go" part. For the video output half, "get ready" means the counters write to the bus, the RAM goes into output mode, and we wait for things to settle down; and the "go" part means once all that is stable, we latch the new data and let it flow to the monitor. For the CPU part, "get ready" again means allowing the CPU to write to the buses, but this time not enabling the RAM straight away (unless it was a read cycle, but I don't support those). And "go" means enabling the RAM write enable signal. I use separate RAM for general purpose use and the CPU address bus is directly connected to that, to the VIA, and to the address decoding logic.


Yes for sure, that was just a hack, I was only really doing it temporarily to experiment with. I mentioned it to illustrate how hard it is to actually synchronise this kind of thing! Using a simple PLD instead and lining things up to clock boundaries makes these things much easier, and again, keeping things synchronous makes it easier to reason about what will change and when.


It is a shame to abandon the design - I think it was close to working. But I also get very nervous about the idea of making such a complex PCB without prototyping it first, there are a lot of things that are easy to miss. As you've probably noticed, I do the opposite - I never stop prototyping to consolidate! Though I am planning to do just that very soon, and probably make a PCB design with the 6502 and VGA output (probably 320x240) based on my current lockstep design at 6MHz.


Looking forward to it!

George, this was a good illustration of what's going on. That really helped me understand the timing of things. I started setting up Excel spreadsheets with that in mind, and it has very much helped!



No shame in ditching what *might* work. In fact, I'm happy to have made those mistakes now, and not later, so that I learn from them. Prototyping and using CPLD would of course help, a lot. A lot lot. But if I set up everything in a CPLD and then want to go to the 74' logic, I will be right back to the same issue: propagation delays.

I would love to see your upcoming printed board! It is always neat to see what other folks use, how they make it look, what's important to them, etc.

EDIT:

I'm deleting what I had previously. While I have been looking into things further, I was quite off on many understandings. Will continue to work on this alone. Thank you all, and thank you especially to George.

Chad

I've been looking at George's schematics much more closely now. And I truly am confused about one little part!

https://github.com/gfoot/simplevga6502

On the '74 flip flops, George is using /CLK2 as the clock. That means, in my mind, that a falling edge is what triggers the flip flop.

But when I lay this out in Excel, I see that it should rather be CLK2, not /CLK2. That is a rising edge, instead of falling edge. I must be terribly confused!

If using the rising edge of CLK2, we get the flip flop holding CLK4 or /CPUBUS in the middle of CLK4. Basically shifting the signal by a time of CLK2.

But if we have the falling edge of CLK2, we get the flip flop holding simply the inverse of CLK4 or /CPUBUS, which is certainly not what George in intending.

I have looked at the datasheet for the '74 and I must be missing something small here. I know what George is wanting to do, but I don't see how the '74 does that in this particular configuration.

Thoughts? Assistance?

Thanks everyone.

Chad

Yes, I meant to mention it in the PM just now - that configuration is wrong and I'm not sure why it worked! I was very confused when I discovered that, and double-checked it between the schematic and the circuit because it shouldn't really work - but the schematic matches the circuit.

What I'm actually running at the moment though is a modified version, consolidating those two flip-flops and most of the logic gates into a simple PLD. I haven't had time to really write up the details of that yet though.

Edit: Here is the PLD code I'm using now, in case it's useful. Most of the signal names here are the same as on that schematic. LCP is the clock pulse to the flipflop after the RAM. VCP is the clock pulse to the vertical counters.

What simple PLD are you using? Is it programmable in a EEPROM programmer? I would love to know!

Anyways, that is strange indeed! So, going forward, should I... leave your design as it is? Or should I 'correct' it? Have you ever tried switching it to CLK2 and see the results? Just wondering.

Maybe I can leave it as a solder jumper option or something. Its still boggling my mind! Thank you George, great work, and I appreciate you posting this info for 'little' people like me

Chad

I'm using Atmel ATF16V8 or 22V10, depending on how many pins are needed - this fits easily in 16V8. I've been wondering how much more of the circuit to move in. It's programmable with the xgecu minipro EEPROM programmer at least.


When I discovered the problem I tried a variety of things but didn't really rethink it enough, and none of them worked. I'm thinking about it a bit now though, I might try something out this evening.


It's no problem, I'm not a 'big' person anyway - just a lowly hobbyist!

Yep, minipro is telling me it is possible to program those with a TL866-II+! Nice! Thanks. Good info.



I would *love* to hear the results.



Haha, I see your name pop up a lot around the internet. You're famous!

Chad

Well, here I am, giving it another go! I've had a fair amount of time at work to play around with this (no time at the house though!), so here we go:

Attached is my timing Excel spreadsheet, as well as the new schematic. On the schematic itself there is a 'graphical' timing display.

I borrowed heavily from George's design ideas. Instead of using the 74HC74's though, I decided to just use NAND's and NOT's, but the timing is the same.

I also slowed PHI2 down to 3.14 MHz, giving me plenty of time to grab data from the RAM at the tail end of a high clock phase without overclocking. The trade off is that I had to grab all 8 bits of data for color to make it to the next latch! So I moved the signals over to a FlashROM instead, and because PHI2 is slow enough to access it, I was able to remove many logic chips and replace it with a single programmable one!

Writing to the Video RAM is back to the 'Apple II' style, just as George does. PHI2 high is for the 6502, PHI2 low is for VGA.

The logic chip count is FAR less now, and I am able to manipulate the timing using an EEPROM programmer. I still have room to make other timing signals, so I might see about reducing timing logic even further, who knows!

Thank you George, and thank you everyone else. I'm going to print this thing very soon, because I'm tried of manipulating schematics and want to get to coding!

Chad

EDIT: I'm removing those schematics. The timing was *still* off. I won't post any more until I have it printed and working. Thanks!

Hello everyone!

It works!!!

Attached is just about every file I can think of. Schematics, assembly, pictures, and video.

320 x 240 x 4 colors (black, white, red, and cyan). 6502 is running at 3.14 MHz. 32K RAM, 32K ROM (banking possible), and 32K Video RAM shadowing the ROM.

As you can see, I had to do 'surgery' to it. In one place I was missing a connection entirely, and another was inverting something that should not have been inverted.

The oscilloscope was VITAL to this operation. Without it I would have been completely in the dark. And the EEPROM programmer made things efficient and fast. Oh, and these non-circular sockets are *crucial* to popping them in and out so often!

When I get cooler demos I'll show them, but for now, this is good enough.

So much learning in this project. Thank you, everyone, for your help, support, time, and patience with me.

Chad