74hc163 counter question - Page 1
Forum section: electronics / projects

author: Dan Moos
author_rank: Frequent Contributor
timestamp: September 19, 2018, 06:46:26 am
content: Let's say I want to count to 80 12 times, then count from 80 to 160 12 times, and continue on in this pattern.I am using 74HC163 counters, and 74HC374 flip flops to attempt this. The data input pins on the flip flop chip are connected to the count output pins in the counters. The outputs on flip flop are connected to the parallel inputs of the counters.So initially, there is zero on flip flop outputs. I count 80 ticks, and an other circuit (horizontal sync pulse for VGA if you're curious), brings the PE pin on the counters low, and whatever is on the flip flop outputs is set at the counter inputs. This happens twelve times (another circuit handles that count), and after the twelfth time, the flip flop clock pin is pulsed. Thus, whatever the count was at that point becomes the new reset point. OE is hardwired low on the flip flops.Scope confirms everything I just wrote is happening. Logic analyzer shows that the count never changes when the counters PE pin goes low. Counters continue as if nothing happened. That is my problem.I'm mostly just asking if what I describe should work. I know there are errors in the specific point that the count "start point " gets updated (I believe I'm trying to load one count too early) but I'll leave that detail for later. I just want to know if my described method should do as I think. Basically, I want to know if my theory of operation is correct. If it is, then I know it's a build error.

author: Zero999
author_rank: Super Contributor
timestamp: September 19, 2018, 06:18:16 pm
content: I don't see why it shouldn't work.Is just quickly Googled VGA, so is the frequency 33.4kHz? Are you sure the signal level is suitable for triggering the counter?

author: Dan Moos
author_rank: Frequent Contributor
timestamp: September 19, 2018, 07:41:29 pm
content: Counter is counting. The PE signal is strong, and considerably wider than the count clock. Portions of this project are running great at a 25.175 MHz pixel clock. On a bread board!

author: sarahMCML
author_rank: Regular Contributor
timestamp: September 20, 2018, 01:20:21 am
content: Hi there,Should you not be using the /SPE input to parallel load the counters, rather than the PE input, which is a count enable input?Regards,Sarah.

author: Dan Moos
author_rank: Frequent Contributor
timestamp: September 20, 2018, 05:31:34 am
content: The Nexperia datasheet I'm using labels parallel load as /PE and clock enable as CE. I've got them right.I think I figured it out though. The clock pulses for every character I read from memory. My characters are 8 pixels wide, so I have another counter handling that. I only send characters during my horizontal draw period, so there is a gap in the clock pulses during horizontal refresh. As it happens, the signal I'm using to clock the flip flop chip occurs in that period. I only just now noticed on the datasheet that /PE has to be low during a rising clock edge to actually load the data. So that's the problem.I have an idea to clock the flip flops in a way that deals with this properly, so I'll report back when I have progress.If anyone's curious, what I'm building is a VGA controller for a homebrew 6502 computer I've built. The VGA is being done entirely with 7400 logic. Piles of counters, magnitude comparitors, latches, and gates. The only non 7400 logic chips in the build so far is my character ROM, and the dual ported RAM chip I'm using for video memory. I created a program for Windows for creating fonts and saving them in the format I require.Currently, if I just hardwire character addresses into the thing, I get characters in the screen, so. VGA timing, my display circuit, and my method of decoding characters for display all work. This thing is on a mess of breadboards.I'm now working on displaying contents from video memory. My characters are stored in ROM in groups of each pixel row, so the first 256 bytes holds the top rows of every character, the second row is in the next 256 bytes, and so on. My characters are 12 rows high, so I display each line of text 12 times, stepping through the rows in ROM to assemble the characters.The troublesome circuit steps through video memory. It has to read the same 80 characters (my horizontal character resolution) 12 times so the characters can be displayed a scan line at a time. Then it has to read the next 80, and do it again.So that's what I'm up to! I think I have the current issue solved in my head, but it will be a couple days before I can get at the bench.

author: sarahMCML
author_rank: Regular Contributor
timestamp: September 20, 2018, 12:07:44 pm
content: Hi again,You have it correct. I was going by the TI datasheet which uses different terms for the inputs.Interestingly, I built a very similar system to yours in around 1979 when I modified the video card of my "7768" MC6800 homebuilt computer. It had a 40 by 25 line display that had to fit into 8 (expensive for the time) 2102 1kx1 static rams. To make the hardware simpler, the designers had used software to map each line of 40 characters into different blocks of ram, which made screen updating hellishly slow.So as you are doing I replaced the counters, added some latches and extra glue logic and, voila, instant screen update!Luckily I'd built my machine on 8x8 inch veroboards so I managed to find enough room for the extra chips. A year or so later it got modded with with an MC6809 micro, either of which can be switched in from the front panel.I still have the machine, being reluctant to throw it away being my first. Unfortunately I no longer have the keyboard or massive psu that went with it, so I can't power it up, but I do still have all the documentation somewhere around.Best of luck with getting yours going.Sarah.