This isn't the best approach because it means CP (clock pulse) doesn't happen at the same instant for all chips in the chain. As a result, the changes on the ABCD parallel outputs of one chip will be skewed, timing-wise, compared to the parallel outputs of the other chips -- and such a skew may be problematic.

So, to avoid the timing skew you'll want all the clock inputs connected together. But even with a common clock there's still a simple way and a preferred way to manage the other connections.

For some reason the newer '163 datasheets I've seen don't discuss the proper way to cascade chips. But here's an old (LS series) '163 datasheet that does address the subject. See the section, "Typical Application Data" on page 21.

-- Jeff

Here's the pertinent diagram. The method shown in Fig 2 is preferred, because the Fig 1 version increasingly limits the maximum frequency as more chips are added.

EDIT: please also see expanded diagram (four Figures rather than two) which I later posted here.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Hm! Yep that's perfect. Thanks Jeff. I'll make the adjustments now.

Chad

The way I visualize these different configurations, to understand the differences between them, is to think of the operation as a hexadecimal count operation rather than a binary count, with each '163 responsible for a separate hex digit of the count value. The different configurations are different ways to send tick or enable inputs to each counter in order to get them to increment at the right time, especially concerning how carrying works from one counter to the next.

So your first configuration was more or less a ripple carry situation again, just between hex digits rather than between binary digits. You'd send a clock pulse to the low-order counter, to increment the "units" hex digit, and if it was F, then you'd also (but slightly later) send a clock pulse to the "sixteens" hex digit. And if that one was an F as well, then it in turn would send a clock pulse to the next digit in line, and so on, with the carry rippling down the chain. It suffers the same kind of propagation delay issues as the 4040, but in a less extreme way.

The top example in the LS datasheet is also a ripple configuration, but it has a degree of look-ahead - between clock pulses, each "F" in the hex number is already sending an enable input to the next counter in line, so that when the next clock pulse arrives they will all update together. So far so good -and the actual count operation is synchronous, happening on all the digits simultaneously in parallel - but now it takes some time after the count output is updated for the new carry look-aheads to propagate, and it's this propagation time that limits the maximum frequency you should use.

In more detail, the first IC in the chain will update its RCO (as labelled in the diagram - I think it's called TC in newer datasheets) based on whether its new value is an "F". This passes to the "ENT" pin of the next counter in line, permitting it to tick next time, and also permitting it to output its own RCO state. So if that next one is also "F", it passes that along, and you have the same kind of ripple carry effect, but almost behind the scenes - as the output count was already updated synchronously. The constraint here is that you must not send the next clock pulse into the counter array until this RCO/ENT ripple has passed through the whole chain, otherwise later counters will tick or not tick incorrectly; and this is where the maximum frequency comes from.

The only change in the bottom (preferred) example is to make a special case for the lowest-order hex digit. The higher-order digits still perform the count and ripple carry look-ahead in the same way, with the same timings, but their ENP is only enabled if the lowest-order digit is currently "F". This means that you no longer need to wait for the ripple to propagate before sending the next clock pulse - it's safe because ENP will have gone inactive and they won't respond to it anyway. You could theoretically send 14 more clock pulses before needing to wait for the ripple to have completed, which I guess is plenty in practice. So the frequency constraint shown in the datasheet just accounts for enough delay for the first counter's RCO to be fully received by all the later counters simultaneously.

Additionally, the first counter's ENP is connected to the second counter's ENT. I'm not sure why they do this, as trying to enable/disable counting for the whole chain by changing the state of this input would lead to another ripple effect. It feels like you should just connect this high all the time, and use the first counter's ENT instead to enable/disable the whole array, which will again have a constant response time regardless of how many counters are chained.

That was a incredibly detailed response. Thank you for that. I will actually be reading that at least 2 more times before I'm satisfied.

In the meantime, I don't have these chips on me at the moment, and oscilloscopes are not my strong suit. I have the datasheet, and I have your feelings on this. You told me you were using some of these '163 chips, but did you not cascade them for any reason?

I exactly agree with you by the way! I'm looking back and forth on Figure 1 and Figure 2, and I'm not seeing a big difference in the end. I was planning on always setting Chip #1 ENP and ENT high, thus Chip #2 ENT also high. Chip #2+ ENP is set to Chip #1 RCO. And then I daisy-chain the Chip #n RCO to Chip #n+1 ENT. This is the configuration on Figure 2.

Funny side note, Ben Eater uses Figure 1 on his schematics:

https://eater.net/vga

Though, he is using only 10 MHz, while here I'm forced into a 25.175 MHz oscillator (unless you can find me a 12.5875 MHz oscillator somewhere!).

Lastly, going from Horizontal Counters to Vertical Counters. Ben Eater uses the 'horizontal reset' logic as the actual clock pulse for the vertical counters. That has always been in my mind as the way to do it, even now with these 4-bit counters. There will be ripple at some point I guess. Perhaps I'm just trying to minimize it.

Thank you George, I'll be reading this over again, and again!

Chad

EDIT:

I re-read it all over again. Its making more sense the second time around, though I'm still a tiny bit puzzled why Figure 2 is somehow better than Figure 1. I will read it one more time (at least), but it makes much more sense now. Thank you again.

While I'm editing, I have made these Figure 2 changes to my printed board, and it's nearly done. I plan on re-constructing my 6502 board so that it can plug directly into this board, so that might take a bit of time. I'm likewise going to solder my existing 6502 printed board to make sure that what I have made will work as assumed. Wouldn't want to go printing another board if I haven't even tested the first one! Time time time.

Thanks!

Haha, sorry for the length - it didn't seem so long when I wrote it!


I didn't cascade them in my "simplest VGA" project, because I was trying to minimize the chip count. The schematic for one revision of it is here for reference: https://github.com/gfoot/simplevga6502 In this circuit the '163 is in the top left next to the oscillator, and its outputs are used to drive three chained '590s. The 590s provide 8 output bits per IC, though it looks like the last one there is barely used.

I've used them cascaded at 25.175MHz in my VGA sprites circuit though, which worked very well. I don't recall which technique I used, but it also wouldn't matter much for that as I only chained three of them in a row.


Debug Innovations' notes discuss this sort of thing - and they actually use 4040s for the vertical counting, and note that this is OK because at the start of the scanline the display is blanked. So long as you're aware of the potential issues and have guarded against them, I think it's fine - you just need to be confident it's not going to cause spurious vsysc/hsync/blanking issues. Sending bogus addresses to a RAM IC during periods when its output is not even going to the screen isn't such an issue (unless, like me, you're using it to drive the sync signals!)


It is a little complex to think through but to summarize the basic reason is that the ripple down the carry look-ahead chain is not on the critical path. The low order counter is the only one that actually counts at the full frequency - the later ones are only enabled (by the first one's RCO output) once every 16 ticks anyway - when the overall hex value of the counters ends in "F". So they have up to 16 ticks' worth of time to get the carry look-ahead signals stabilised, and unless you're chaining about 16 counters in a row, that's going to be enough.

Thank you for this George. And thanks of the link to your github page. I see you included your tutorial on the SD card reading/writing, and I will definitely be making use of that soon.

It's making more sense now, I read that last bit of the previous message a third time. Like you said, we are making the exception for the first counter, all the rest are 'rippled' like Figure 1.

I'll be continuing to work on the printed boards, and will keep you updated, or ask more questions Thank you again!

And, thank you again Jeff, for initiating this Figure 2 discussion. You likewise have just saved my project.

Chad

Just an update here.

Attached are some pictures of my PCB design. The PDF is white background, the PNG is black background. Two 4-layer 10cm x 10cm boards shoved together with some pin headers/sockets.

Address Map:
$0000 - $7FFF = 32K SRAM
$8000 - $83FF = 1K Dual Port SRAM and ROM [ write to RAM, read from ROM ]
$8400 - $FDFF = 30.5K ROM
$FE00 - $FE7F = unused, poss I/O exp
$FE80 - $FE8F = I/O through VIA
$FE90 - $FEFF = unused
$FF00 - $FFFF = 256 bytes ROM

VIA Pins:
LCD
PA0-PA3 = 4-bit data output
PA4 = data/command
PA5 = enable

Buttons
PA0-PA2 = strobe to buttons (using '138)
PA6 = return from buttons

PS/2 Keyboard
CA1 = clock
PA7 = data

SPI SD card
CA2 = enable
PA0 = clock
PA1 = MOSI
PA7 = MISO

Buzzer
PA4 = pulse generator

I don't have an updated schematic, but this is essentially my previous 6502 printed board but re-arranged for this particular configuration.

The one thing I don't love about it is that I'm using ribbon cables to connect the "EXP" pin headers between the two boards. I wanted to leave all PB lines free so that I can create a "user port", but I couldn't run the traces from the front to the back because it was just too clogged already. Oh well, minor stuff I guess.

Thanks everyone. I'll be checking this over about a hundred times before I decide to have it printed. I'll keep you updated as I go along!

Chad

Often I find that 'feature creep' seeps into my projects. And here too of course. Yet...

Last night I was thinking of a recent topic by CountChocula, where he is doing something similar to what I am. He had a very simple issue with a latch, and all it needed was a pull-down resistor. That was it, and that issue was only involving 2 chips. My plan is to use around 30 chips! What if I forgot a pull-down resistor somewhere as well?

I need to simplify this operation, yet still have it capable. Too many logic gates going on, something could go wrong.

Attached is a very different schematic. It doesn't reduce chip count, but it's almost all counters and an SRAM and EEPROM. I'm going with George's idea to use the 28C258 EEPROM for sync signals. Then I'm using some counters to run through a 32K 62256 SRAM for pixel data. This will now be 256 colors, 256x128 resolution. The trade off is I need to latch in data into the SRAM at specific times. I'm thinking of doing this (skilfully) with the 6522 VIA.

When the 8-Bit Guy was picking out his graphics card for his Commander X16 board, he showed the particular operation he wanted. And I'll be replicating that style with this. Latch, auto-increment the address, latch, auto-increment the address. And at any time you can set the high and low addresses to whatever you want.

Again, though this might *seem* just as complicated, it's basically a lot of 4-bit counters all lined up.

Still, I need to actually just DO something, instead of all this planning. Soon enough! If you have insight or ideas, I'm willing to hear them. Otherwise, this is just an update to the topic for posterity sake.

Thanks everyone!

Chad

EDIT:

Just bought some of these parts from Mouser. Will hook them up to a breadboard and see what happens! Will keep you updated.

Today was the day I was going to make the VGA signal work with the EEPROM. Just 5x counters, 1x EEPROM, and 1x latch.

And it failed, of course.

I pulled out the scope, and that thing is nearly useless. I finally figured out how to work the "trigger" mode (by accident), and I do have the sync signals generating. But I'm getting a ton of interference, probably the wrong probes. The monitor is trying really hard to recognize the signal, it tells me so.

It seems my reset is wanting to enable like half-way through the drawing of the screen for some reason. My addresses are all ok. It could be my ROM programmer, since it's basically my previous breadboard design, who knows.

The counters are definitely working. That much I can say.

Without adequate testing and programming equipment, I don't know if I'll be going forward with the EEPROM signal generator now. My original design had the NAND gate version like Ben Eater. I have to switch out my breadboards anyways, so I might re-try it all tomorrow with a fresh start.

That's the update! One failure at a time We've all been there. I'll keep y'all updated.

Chad

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Chad,
A schematic of your breadboard design would be helpful toward understanding your problem. I assume it is the upper left corner of your Dec 22, 2021 post. I don't know how the latch fit in, however. If you are using 28C256 for EPROM, it is too slow for 25MHz pixel clock.

Your scope is the best tool for troubleshooting. You need to hook it up to the calibrating output (lower right corner of your scope) and verify you can see a square 1KHz 5V waveform. I believe it has auto-compensating feature to compensate your probes.

I have seen a pair of P2200 probes on Amazon for $29 which is incredibly cheap price, probably a knock-off of the original probe. It may not be full-spec, but your scope (TDS1002) is 60MHz bandwidth so if the knock-off P2200 is not full spec, it should work well enough with your TDS1002.
Bill

Thank you BDD, yes indeed!

And thank you Bill. I'm going to need to add that to my next list for sure. This is unbearable. And yes, the upper left corner stuff on the schematic, latch was just to hold the signal while EEPROM was in high Z state. I will look into that compensator as well.

So, I switched out my breadboards. One wasn't big enough, and the other was wasting a lot of room. So I fired it back up this evening, and I got... slightly different results.

The monitor just blacked out on me. It was not trying to put me in 1280x1200 mode, which might be better??? The menu isn't working on this particular monitor (any of my monitors in fact, at any time), and so I cannot tell if it's detecting a good signal or not. No color of course, who knows. It wanted to go to sleep mode a couple of times.

Something definitely up with the reset signal from the EEPROM. It's actually programmed correctly, I was able to get that from the scope. It literally matched up exactly to the timing I expected. BUT, maybe it's just the scope, maybe it's the probes, but I'm getting a TON of interference. Probably more than the first breadboard. I wiggle a cable here and there and things change. Not good. The scope is acting like I have an analog TV channel from 200 miles away, barely coming in with a ton of static (ah the good ol' days before digital started just shutting down the signal entirely...)

So that reset signal is jumpy on the scope. It has a square wave behind the static, but if any of that static is getting to the counters, it's resetting. When I connect the reset properly, some of the counters aren't even firing. When I just hold it high (no reset at all), I can see everything on the ROM and (besides the static) everything looks great. Sync signals, reset, whatever, it's all there and at the right time.

I'm now blaming the breadboard. Ben Eater makes it looks so easy! Pfft. Garth warned me about breadboards!

I don't know what the next step will be exactly. I might try the NAND gate idea, I might solder this to a perfboard. The new probes would help detect stuff.

Anyways, one step at a time, thanks y'all, have a good evening.

Chad

In my circuit it was important that the latch was edge-triggered (flip flop), and it is triggered at the right moment, after the counters have stabilised and the EEPROM has had time to fetch the data. The point is to snapshot the output so that you can advance the counters again to start fetching the data for the next block.

It'd be interesting for sure to know how exactly you've included a latch into your previous circuit, and what type it is exactly. A photo of the oscilloscope could be useful too!

My guess about the noise is that it could be switching noise due to lack of decoupling capacitors, or transient states from the EEPROM during counting if you're not using an edge triggered latch.

It's a 74HC373, so NOT edge triggered. Hm, will be thinking about that George, thank you. I added that latch because I saw it on your video btw, you said it was very important, and of course I see why! I just didn't know what kind of latch. The edge triggered is probably the way to finish this up, once the reset works properly that is (I'm not using the latch for that). I didn't add any capacitors yet, though good ol' Ben didn't have any either.

Update: I talked with my wife, and I just purchased the $30 probes on Amazon. Thank you for that suggestion Bill. It'll be good for the long run for sure.

So that will be a week until they arrive. In the meantime I should probably do, oh I don't know, my job

Thanks everyone.

Chad

Chad,
First I would hook the scope probe to the 1KHz calibration output to make sure the scope can display a clean 1KHz square wave. You had said the scope may be water damaged, I'd check the scope's function first before investing too much money in it. You can also look at the 25.175MHz oscillator output with the scope.
Bill