For hardware pan to work, the image memory need to be bigger than the display so the starting address of the horizontal/vertical define the region of memory to be displayed. Changing the starting addresses pan the display over the memory. Returning to your design where image memory is smaller than the display where you actually need to blank out the unused portion of the display. I see you are using H512 for horizontal blanking and V256 for vertical blank, so the active region is located at upper left corner of the display. You may want to move the active region to the center of the display and one way of doing that is load the counter with negative value and blank the display; when it rolls over, the screen becomes active in the center of the display. You can do this both horizontally and vertically since you have loadable counters.
Bill

Bill, you're a genius. Seriously. And thank you.

I went out and walked a couple miles thinking this through. Here is what I can say:

Right now I'm trying to accommodate for either the '161 or the '163, interchangeable. I would simply use solder jumpers to change the exact sync values by a little bit.

If I were to pan, say (640 - 2 x 256) / 2 = 64 pixels horizontally, then my sync signals and "reset" signal will also need to be shifted by 64 pixels. But it's no longer a reset signal, it's a load signal, which is synchronous in BOTH the '161 and '163. Thus my idea of having the async counter as an option/backup is no longer possible. The only way to allow for either is to be able to set my preload value to either 0 or 64, and likewise be able to change my horizontal sync signals between 656/592, 752/688, and 800/736. Likewise, I will need to be able to adjust the 800 to 799, and the 736 to 735, etc. Because my '688 chips are only 8-bits wide, I would somehow have to have my counter values for 1,2,4,8,16,32, and 64 available to be changed, leaving me with only one bit for anything higher/lower, which would definitely require more logic gates, which only decreases my available time between clock cycles.

This argument extends to the vertical timing as well.

In a way, I'm saying having the option to use the '161 OR the '163 would no longer work (well it would work, but the because I wouldn't be using the reset there would be no difference between the two chips). My ability to try the async OR the sync counter idea would be off the table.

So here's my thoughts: I will keep this particular board design, without pan. And I will also make a second design that is ONLY synchronous but panned horizontally and vertically by 64 pixels, that's center screen horizontally and kinda sorta center vertically. In that second design I won't need the flip-flop as a clock divider, so I can use that as the second SR Latch, gaining me two NAND gates to help with my enable signals (might need to do some solder jumpers on my main board now too).

I wouldn't want to call this "feature creep", but it would be a non-essential. Still, that is such an excellent idea! And if I'm going to have 2 boards printed, what does it matter if I make a third board, it will only be $8 more on JLCPCB.

Thank you again Bill, I'll keep you updated.

Chad

Just an update:

Attached are two schematics. The first one is the async board using half-clock speed and not panned. The second is the sync board using full-clock speed and is panned.

Using the load feature of the counters makes for all types of possibilities! For example, I sent the horizontal counter to: 4096 - 2048 - 512 - 64 = 1472. That is 4096 counter rollover. 1024 and 2048 will alternate between high and low after the localized rollover, useful for glue logic. 512 is the amount of pixels to be displayed and so stays high while drawing, and 64 is the horizontal pan. This makes for interesting sync values of 80, 176, and 224 (if you ignore the 1024 and 2048 bits of course).

Thank you everyone!

Chad

Folks, I have a bit of followup regarding what we were saying upthread about cascading '163 counters. For comparison purposes, in the image below I've included Figure 1 and Figure 2 from TI, even though I already presented them in this post.

The vesion I've called Figure 3 is a lookahead scheme taken from a different TI datasheet. I don't know why this lookahead scheme doesn't match the one they recommended in Figure 2. Figure 2 is more recent, but neither version seems convincingly right. Figure 4 illustrates a suggestion of George's which we'll get to in a moment.

In case anyone's in doubt, I'm appending a peek into a single chip's internal logic. The highlighted path illustrates how each chip can form a single link in a chain. I'm sure that's what you mean, George, when you mentioned a ripple carry effect in this post...
I agree when you say...
-- Jeff

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

Thanks Jeff, that makes sense.

Figure 3 looks as bad as figure 1 to me - it would have a limited frequency based on chain length, which figure 2 doesn't suffer from as much.

In Figure 4 I think the first counter's ENP also needs to be held high, it's not going to work otherwise.


Yes, that is what I meant - it's much clearer with your diagram, as if you trace this path through all the chained ICs you get a very long serial chain of gates and their propagation delays will add up.

I think there still an issue with very long chains that I'm not sure how to solve though, which is that if the first counter ticks sixteen times before the carry has propagated through all the other counters then they could count wrongly (I think they'd actually count too low, but it's making my head spin trying to think it through!)

Well, yes... all of the TI diagrams (Fig 1, 2 and 3) have that common feature. Each version shows two inputs to the cascaded array, both labeled "H=Count, L=disable." (And that's how I drew Figure 4, too.) But I'm guessing that only in rare situations would someone need two such inputs. And when one is unused it'd get tied high.

It kinda makes my head spin, too, but you're making sense. It's an important point.

FWIW I'll share the following. (And really this is a different issue, though still pertinent.)

It's true as you said in a much earlier post that the low order counter is the only one that actually counts at the full frequency. The others have up to 16 ticks' worth of time to get the carry look-ahead signals stabilised. (That's assuming we use Fig 4, which has ENT of the 2nd counter tied high. Otherwise the others could end up with much less than 16 ticks.)

So, yes, up to 16 ticks' worth of time. And yet there's a key moment that requires very brisk response. Consider what happens as the low-order counter advances from $E to $F to 0.

Maybe I'm stating the obvious, but we mustn't be falsely reassured by the fact that the repetition rate for this event is fairly sedate -- 1/16th of the clock rate. We still need a brisk response. That $E, $F, 0 sequence strictly demands that the other counters be disabled, enabled, then disabled (respectively) on three successive clock edges. That needs to happen in a tidy fashion or there'll be trouble.

-- Jeff

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

The scenario I had in mind was more about the carry, e.g. imagine counting up from something like $00FFFFFFFFEF. The low order counter's RCO is active, so the higher order counters have ENP enabled, but only the second one (the E digit) has its ENT active. So only the bottom two counters tick up, and we get $00FFFFFFFFF0.

Now the bottom counter's RCO goes inactive, as it's no longer an F digit, so the higher order counters are disabled via ENP. Meanwhile, the second counter's RCO goes active, as it is an F now, enabling the third's ENT, and step by step this ripples through as these digits were already Fs.

The issue I see is that with a long chain, maybe it's possible to tick the clock another fifteen times before the ripple is complete; then the low order counter would get back to F again, enabling the higher order counters' ENPs, but if the carry hasn't propagated yet, they will not all actually count up on the next clock, and the resulting number will be too low (e.g. $00FF00000000 instead of $010000000000).

It might take a ridiculously long chain though for that to be a problem. I guess the solution would be to split the chain at some points and add your own carry look-ahead NAND gates external to the ICs, similar to those in the internal diagram you posted before.

I guess we've derailed this thread quite a bit, so sorry to sburrow for that, but it's an interesting discussion!

It is a VERY interesting discussion George! These theoretical questions are very important. Though I myself am not using 12 of these counters in a row, someone else might, and it's interesting to think of how they would react to fast clock speeds.

Jeff, according to your Figure 3 and Figure 4 diagrams, I'm basically using Figure 4. I'm tying those ENP and ENT lines on the first counter high always, thus the ENT of second counter as well, as per our original Figure 2 discussion. So in a way I'm following your Figure 4 as well!

I don't know why I (personally) would ever bring the first counter's ENP or ENT lines low, I don't have any use for disabling the counters in this particular application. But again, this is an interesting situation and I like the discussion a lot. I'm learning, so continue on or whatever it is, and I'll be soaking it all in.

Thank you both.

Chad

Chad's graphic design has inspired me to take another look at Apple II style of accessing video RAM where 6502 accesses the memory during clock high phase and VGA controller accesses the memory during clock low phase. I plan to do this at 12.6MHz or 1/2 of 25.175MHz.

In the process, I thought I also verify Chad's design by capturing his schematic in Altera's Quartus tool. Quartus has an extensive TTL library so 74161 and 74688 are in the library. Instead of using tri-statable 74245, I used a bus multiplexer to switch between addresses generated by the counters and 6502's address bus. Only the red input is hooked up so the display looks red. The RAM is not initialized so it display random dots. Chad, I think your design of 12/29 is working.
Bill

Edit, A quick description of the protype board: The CPLD is a 128 macrocell EPM7128 and the "dead bug" device is CY7C109, 128Kx8 RAM, 25nS. The design does not need 128 macrocells, but it needs more I/O pins than the smaller EPM7064S in PLCC44 can provide.

That's interesting Bill. Can you simulate propagation delays that way too? It's the main thing that's become difficult for me in my designs with the constraints I chose to work with (mostly, low-level through-hole parts and breadboards).

Personally I guess I've been through three iterations of video output designs, all using interleaved CPU and video access to RAM. The main distinction I'm making is how the counters and timing logic worked - I went from using upcounters and logic gates, much like Chad's, to using downcounters instead (74HC40103) which hugely reduced the amount of wiring, and then to using EEPROM for the timing signals as discussed earlier in this thread - which reduces the IC count a lot.

This kind of complexity reduction probably wouldn't matter as much on a PCB, but it helps a lot on a breadboard. Of my designs, the second was, I think, the cleanest. But the EEPROM one is simplest to build.

On an FPGA I'd expect the upcounter design to work best though as it consumes fewest complex resources like memory and flipflops - so in that respect i guess the one that works least well on a breadboard actually wins out on the FPGA?

The CPLD is faster than HC logic so for timing critical designs, it may not be a good emulation. At 25MHz clock, this VGA design is not particularly fast and the logic do not have too long of delay chain, so I felt it is a reasonable emulation. It does check the correctness of the logic so if the TTL-based design does not work, we can concentrate on PCB implementation, prop delay and system noise issues. Anything one can do to simplify and zero-in on the problem are helpful in debugging.

In CPLD the combinatorial logic is mostly free, so the designs are mostly constrained by the number of flip flops. A medium size CPLD like EPM7128 only has 128 flip flops, so I have to be stingy with flip flops. I generally design in schematic so I have a clear understanding of flip flop usage.
Bill

First off, thank you Bill for checking out my logic. That is a beautiful sight to see indeed! Just as a reminder/update: What Bill is showing is my "async" design, using the '161 asynchronous reset feature, just like Ben Eater. That used the exact 800 and 525 values for reset.

Tomorrow I send off some boards, one of which is that async design, and another is the "sync" design which uses the '161/'163 preset feature, and will pan horizontally and vertically to make the image a bit more centered on the screen. On that board I have solder-jumpers to change the 'reset' values a bit if need be. I expect 799 and 524 will be the winners there. This will be the closest to what my previous breadboard design looked like.

I will keep you updated whenever there is something to update. At this point, it's a waiting game.

Thank you everyone for your help and support on this project. I appreciate it greatly.

Chad

Update!

As with every project, some good news and some bad.

Good:

The monitor recognizes the signal perfectly, and displays something! This is the "sync" board, which I panned to the center of the screen. And it is working exactly as expected in that regard. Awesome!

Also to note, I am using H799 and V524 for reset values instead of H800 and V525, and it seem to work great. I'm doing this because it's the sync board, and it needs to reset on the next clock tick, not immediately/async. Just for future info.

Bad:

The RAM is being written to somehow. The screen stays static and stable for a bit, then it starts replacing pixels slowly, then faster, then it's all red. THEN it turns black all at once.

This not 'snow'. Not like a TV without signal. It's just kind of random?

I suspect this is because I don't have a computer plugged in to it to regulate the input lines. When I rake my finger on the RAM pins I get all kinds of changes. They stay for a bit (sometimes) and then they disappear eventually. I tried running a temporary line to keep /WE high, but that doesn't seem to work great (that's the red wire you see in the pic).

I'll be checking things with the scope now. BUT at least it's a panned image and is actually displaying stuff. Cool!

There's my update, thanks everyone! Would not have been possible without you!

Chad

EDIT:

Yep, when I tie /WE to a proper VCC, I can keep a stable image. When I release it, it's sporadic. Scope says /WE fluctuates some when disconnected, or at minimum it stays grounded which means it's constantly being written to (probably lots of zeros, thus the reason why it blacks out often).

Some things I've learned:

1) KiCad footprint for DSUB-15 connector was wrong, I had to bend pins to get it to fit!

2) I need more VCC and GND available on the board, especially GND so that I can easily plug in scope probes.

3) After soldering, don't rub your eyes! That was a chemical burn. [ My eye is fine btw. ]

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

I forget the basics sometimes