VGA and Dual Port RAM

[sburrow]

Hello everyone!

Over the past couple weeks, I've been learning more about VGA signal generation. I found Ben Eater's "Worst Video Card" series on youtube, and thought that was a neat idea.

Attached is a mostly complete schematic. The basic principle is to follow Ben Eater by using counters and logic to generate sync signals, as well as pixel location. Instead of sharing 32K RAM and halting the 6502, I was thinking of using this 1K x 8 Dual Port RAM along with a shift register to get monochrome 128x64 blocks (each block being 4x4 pixels in this case). This device would mostly plug-and-play into an existing 6502/62256/28C256/6522 configuration, acting as 'shadow RAM' on some part of the memory map.

Now, I know this is definitely not high definition or something. I'm thinking of this as a mimic of those 128x64 LCD's. In other words, if I can display enough information on one of those, this should likewise be 'good enough' for some basic information. Plus, it's a design challenge.

I am not going to use FPGA's or CPLD's as of now. I know that would greatly reduce the chip count, but I currently have no way of programming those, and they are currently out of my league.

Thoughts? Suggestions? Something you see to improve the experience some?

Thanks everyone!

Chad

[CountChocula]

Welcome! Fellow newbie here.

I don't think that reducing the IC count needs to be a goal unless you're short on space or are building something for production purposes. IMO, using discrete logic as a starting point is a great way to really think a problem through while you're trying to learn how things work.

Did you try wiring this up to see how it works? I've also been working on a VGA card lately, so eager to learn how others have approached the problem.

[sburrow]

CountChocula wrote:

Did you try wiring this up to see how it works? I've also been working on a VGA card lately, so eager to learn how others have approached the problem.

I'm working on a printed board right now. But I think I will try to create a timing simulator in C++ or something. There's so much going on here, I don't think I could even draw it on paper and make sense of it!

I'd love to see your work too, do you happen to have it on a topic here yet? I have been back and forth on this issue for a long time, trying different schemes in my mind. In the end, I had to give up something, and I decided to give up screen resolution and color, in favor of the ease of use provided by the Dual Port RAM.

Sounds good about chip count. I'm working on a 10cm x 10cm board and so far I've fit everything on there without any squeezing yet. I have high hopes it'll fit!

Thank you.

Chad

[drogon]

sburrow wrote:

Hello everyone!

Over the past couple weeks, I've been learning more about VGA signal generation. I found Ben Eater's "Worst Video Card" series on youtube, and thought that was a neat idea.

As well as Ben Eaters thing, George Foot has an interesting take on it here - I think it's worth a watch:

https://www.youtube.com/playlist?list=P ... wWM2hrOM3b

Hope it works out well!

-Gordon

[sburrow]

drogon wrote:

As well as Ben Eaters thing, George Foot has an interesting take on it here - I think it's worth a watch:

https://www.youtube.com/playlist?list=P ... wWM2hrOM3b

-Gordon

I watched his first video on it, I *loved* the idea of using ROM for signal generation. So much so that I tried many times to fit that square peg into a round hole, and it wasn't working in the end. The 40ns from the 25.175 MHz clock is not much time to work with. I watched a few minutes of his second video where I think he changed it to RAM instead, which would help his access time a lot.

I'll see about watching the other videos he has on it now. Thank you Gordon!

Chad

[sburrow]

This morning I made a simulation program in C++, it is attached in case your interested [don't judge, I'm a seat-of-the-pants kindof programmer]. Glad I did it, because...

I found my shift register logic was very slightly off. I had to invert two signals, so I put that in the schematic (the changes are located where the "title" portion is). I attached that as well.

I'm nearly done with laying out my printed board, need to do the netlist stuff which is a very good way to double check as well.

So I have a semi-related question: Sometimes when I see folks making a VGA addition to their computer, they also put PS/2 Keyboard support on it. I mean, I want to use a keyboard also, but because the keyboard would be talking to a 6522 that is NOT on this board, it would simply be placed on this board for physical space reasons. Is there any other reason why keyboard connections should be placed on a VGA board?

Lastly, because this board will be connected to my original 6502 board, and it's power supply, would I need another big polarized capacitor where the power supply comes in to this new board? Of course I have decoupling capacitors at every IC.

Thanks everyone!

Chad

[gfoot]

sburrow wrote:

I watched his first video on it, I *loved* the idea of using ROM for signal generation. So much so that I tried many times to fit that square peg into a round hole, and it wasn't working in the end. The 40ns from the 25.175 MHz clock is not much time to work with. I watched a few minutes of his second video where I think he changed it to RAM instead, which would help his access time a lot.

Hey Chad,

Either way, the ROM/RAM is only accessed at 6.3MHz - the sync pulses are coarse and wide enough that that works fine. I'm still using that frequency of memory access in much later videos, even when the display resolution is a full 640x480 - I'm just packing four pixels into each byte, and later on using multiple RAM ICs together, read simultaneously, to effectively get more bits per byte.

I looked into dual port RAM when I was starting out on video circuits, but the options seemed quite limited, and as I was familiar with how the BBC micro shared its RAM, I was interested in making something similar.

[sburrow]

gfoot wrote:

Hey Chad,

Either way, the ROM/RAM is only accessed at 6.3MHz - the sync pulses are coarse and wide enough that that works fine. I'm still using that frequency of memory access in much later videos, even when the display resolution is a full 640x480 - I'm just packing four pixels into each byte, and later on using multiple RAM ICs together, read simultaneously, to effectively get more bits per byte.

I looked into dual port RAM when I was starting out on video circuits, but the options seemed quite limited, and as I was familiar with how the BBC micro shared its RAM, I was interested in making something similar.

The man himself!

Yes, I can see the sync signals effectively being put into ROM and having no issue. I guess I'm one of those guys who wants to use every bit possible, so I find *just* using a ROM for sync signals a little bit of a waste. Like you said, you also use it for pixel data, but I was trying different schemes for that and coming up short on access times.

I watched one video of yours, somewhere in the middle, and I was following you until you said "lets use a GAL". Not that that's bad, but I just don't have that capability yet. I'll level-up one day I suppose.

I'll go and watch some more of those videos soon. Thank you!

Chad

[CountChocula]

sburrow wrote:

CountChocula wrote:

Did you try wiring this up to see how it works? I've also been working on a VGA card lately, so eager to learn how others have approached the problem.

I'm working on a printed board right now. But I think I will try to create a timing simulator in C++ or something. There's so much going on here, I don't think I could even draw it on paper and make sense of it!

I'd love to see your work too, do you happen to have it on a topic here yet? I have been back and forth on this issue for a long time, trying different schemes in my mind. In the end, I had to give up something, and I decided to give up screen resolution and color, in favor of the ease of use provided by the Dual Port RAM.

Not yet, I have a brief discussion on some of the initial challenges that I faced, but so far I have only wired together the sync signal generator and video RAM access on the card side; I was going to work on the computer-side access next.

I'm doing this experimentally, so I don't yet have a schema, but I'm going to post something as soon as I do (though, fair warning, I'm using GALs )

sburrow wrote:

Sounds good about chip count. I'm working on a 10cm x 10cm board and so far I've fit everything on there without any squeezing yet. I have high hopes it'll fit!

Cool… good luck!

[sburrow]

Just an update:

My timing logic was still wrong. I didn't look well enough at my simulation results. Read to the end! Attached is the latest schematic and code, in case you are interested. (I'm doing this more so for the sake of whoever will be reading this in the future.)

I'm going to have to re-do my printed board layout, so that will take more time. But I was able to fit 15 smaller chips and the large Dual Port RAM all on 10cm x 10cm with plenty of room to spare. So it should all fit!

Thanks.

Chad

[gfoot]

I had a look at the schematic. Be careful with the 4040 counters - 25MHz is really borderline for them according to the datasheet, and they are also ripple counters, which can cause a lot of pain. The propagation delay from the clock pulse to bit N, during carries, is quoted as (16+8*N) ns at room temperature. In the meantime during large carries you may see low bits toggle to zero before high bits toggle to 1. You may be providing the next clock pulse before the previous one has rippled through.

You may find for example that in a carry from 511 to 512 on your vertical counter there is a small window where V256 and V512 are both low. This could trigger a short spike on the NAND gate that they feed into - that's the sort of thing you need to be careful about with ripple counters.

This is why I used a mixture of counter types in my "simplest VGA" project - a high speed synchronous counter close to the clock, where the frequencies are high, and lower speed but wider counters after that to get a lot of counter bits without needing tons of ICs.

Edit: I missed this from earlier:

sburrow wrote:

So I have a semi-related question: Sometimes when I see folks making a VGA addition to their computer, they also put PS/2 Keyboard support on it. I mean, I want to use a keyboard also, but because the keyboard would be talking to a 6522 that is NOT on this board, it would simply be placed on this board for physical space reasons. Is there any other reason why keyboard connections should be placed on a VGA board?

I believe the best advice would be to put the 6522 on the main board and the PS/2 interface elsewhere if it doesn't also fit. Generally avoid running your main CPU buses off the main board. But that said, most of the things I do myself are on breadboards, so literally everything is equivalent to being off the main board!

sburrow wrote:

Lastly, because this board will be connected to my original 6502 board, and it's power supply, would I need another big polarized capacitor where the power supply comes in to this new board? Of course I have decoupling capacitors at every IC.

I'd add bulk decoupling anywhere power enters a board, especially if it came down long wires. The purpose is to mitigate inductance in the supply wires, so that for example when the board needs a sudden burst of power, the capacitor can provide it while the wires take time to catch up. If the new board is physically close to the old one, e.g. directly connected to it, then more bulk decoupling is less important as far as I know.

[sburrow]

gfoot wrote:

I had a look at the schematic. Be careful with the 4040 counters - 25MHz is really borderline for them according to the datasheet, and they are also ripple counters, which can cause a lot of pain. The propagation delay from the clock pulse to bit N, during carries, is quoted as (16+8*N) ns at room temperature. In the meantime during large carries you may see low bits toggle to zero before high bits toggle to 1. You may be providing the next clock pulse before the previous one has rippled through.

You may find for example that in a carry from 511 to 512 on your vertical counter there is a small window where V256 and V512 are both low. This could trigger a short spike on the NAND gate that they feed into - that's the sort of thing you need to be careful about with ripple counters.

This is why I used a mixture of counter types in my "simplest VGA" project - a high speed synchronous counter close to the clock, where the frequencies are high, and lower speed but wider counters after that to get a lot of counter bits without needing tons of ICs.

Thank you George, that was a great reply.

First to the ones I didn't quote here:

Ok, I'll put the PS/2 keyboard where the 6522 is. Good idea.

I'm planning on "plugging" this into my 6502 board. They will both be 10cm x 10cm boards, and I will connect them with a big male-female pin connection, probably a 2x20. There will be no wires. I might include the capacitor anyways, but we'll see how space requirements start working.

Now for the counters:

WOW. I did not know that! That makes a LOT of sense. Thank you for saving my project. I was always wondering why Ben Eater was using little 4-bit counters, now that makes a lot more sense.

My simulation only tells me *logically* what should happen, but reality is rarely so neat and clean. This sync counter idea is a very good way to keep it from triggering signals I'm not wanting. So I just went to the 74HC163 datasheet and I see the max frequency and propagation time is similar to the 74HC4040. Just like last time, I have a narrow window to work, BUT with the synchronous counter it should now work as expected.

Thank you so very much for this George. Again, you just saved my project.

So the easy choice is the 74HC163, but I also found a 74HC4520 which would save some chips, but it has an async reset which I'm now leery of. Any ideas would be helpful, because replacing my 4x 74HC4040 with like 12x 74HC163 will be REALLY hard to fit on that little board.

Have a most wonderful day.

Chad

[gfoot]

I use 74ACT163 to initially divide by 4, it wasn't a considered choice though, just what I happened to buy a load of once because it was fast. Then I use 74HC590s after that, which are slower but provide 8 bits, and have tristate outputs which are useful as I don't use dual port RAM. The outputs of the 74ACT163 are used to synchronise the memory access with the CPU but all the address bits come from the 74HC590s.

For my sprite circuit I just used loads of 74ACT163s, because I could chain them in an interesting way and needed them to be presettable.

Asynchronous reset isn't a show-stopper, but I do prefer the tidiness of everything being synchronous.

Debug Innovations has great notes on this kind of thing here: http://debuginnovations.com/TTL_Terminal/home.html

[sburrow]

gfoot wrote:

I use 74ACT163 to initially divide by 4, it wasn't a considered choice though, just what I happened to buy a load of once because it was fast. Then I use 74HC590s after that, which are slower but provide 8 bits, and have tristate outputs which are useful as I don't use dual port RAM. The outputs of the 74ACT163 are used to synchronise the memory access with the CPU but all the address bits come from the 74HC590s.

Hm, interesting. I might just get a couple of those 74AC163's or 74ACT163's to test with that initial counter, in case the 74HC163 doesn't pan out. Wouldn't hurt to try.

I took a look at that link, lots of good details there. My setup here is *much* more basic, at least in premise. When I eventually jump to the next level I will have to look through this a lot more.

Thank you again!

Chad

[sburrow]

Alright, I got a question. Not sure if I should put this on a separate topic or not, though it is a small question:

https://assets.nexperia.com/documents/d ... HCT163.pdf

I'm looking to chain/ripple multiple 74HC163's together. If figured just connect chip #1 TC to chip #2 CP, while keeping CET high. Is this wrong?

This datasheet (and all others I've found) is saying that TC goes high when we are at a count of 15. That is, TC upticks on 15.

Here is what I'm wondering:

So I have chip #1 CP is connected to the oscillator. Tick tick tick, and then chip #1 count is 15. At that very same moment TC goes high.

If I had chip #1 TC connected to chip #2 CP, that would mean that chip #1 is sitting at 15, and chip #2 is sitting at 1, when I really want it at 0. Once chip #1 goes back to 0, THEN I want chip #2 to be at 1.

Thus if I were chaining/rippling these two chips, I would have a count that looks like:

0/0
1/0
2/0
...
14/0
15/1
0/1
1/1
2/1
...

If I were using these a single hex value, it would read like:
00
01
02
...
0E
1F
10
11
12
...

Am I correct in what's going on here? The bigger question: How do I chain these '163 chips together? Do I have to use CET in a way I'm misunderstanding?

Arg, I should have went with the '193 counters, I've used those before. Anyways, thanks everyone.

Chad

EDIT:

I think I found something useful while searching the internet for '163 examples. Attached is a picture. Weird setup in my opinion. I guess I'm just used to '193.