Hello everyone!

Revision 2 of the Acolyte 6502 Computer is now complete! Previous topic on the Rev1 board is found here:

viewtopic.php?f=4&t=7096

So for the past few weeks I have been working on revising the board, making small changes, adjusting color settings, and eventually adding audio-out and Genesis controller support. Attached are some pictures, commented code, and schematics. All extra info can be found here:

https://github.com/stevenchadburrow/Acolyte6502Computer

But I have a small story, and I'm sure you have had this happen to you to:

I soldered everything yesterday, and didn't want to even turn it on because I knew I'd be fiddling with it all night. Well, I turned it on anyways, and the screen was flickering. HUH? So I scrubbed the bottom with a toothbrush and the flickering went down, some. I was sure it was crud somewhere, so I went over my soldering again and again, and removed hairs and anything else I could find, yet it still flickered. I then pressed my finger on the expansion pin-holes and the flickering stopped! I touched in other places and it stopped, or got worse. WHAT? Surely I messed up a connection, or JLCPCB bit me again. The scope didn't help because if I scoped a problematic pin, the flicker would stop and the scope would read fine. UGH! What could it be? I whittled it down to my primary counter, a 74HC161. So I replaced it with another one, and the flicker entirely disappeared! YAY! This chip was *brand new* from Mouser, so what could have happened, I don't know. Glad I had replacements to test.

Other than that, nearly everything else worked as expected. I only had a very few small changes in the code I had been designing for this board. The software side is great, I have focused on using the keyboard Function keys to navigate. Some programs include a RPN Calculator, Music Composer, Assembler/Disassembler, Memory Dump, Data Movement/Transfer GUI, and a simple Snake game. I have had my 3 year old daughter test the system, and she has found many bugs along the way! Always have a young child test your 6502 computer, LOL!

Genesis controller is not yet working, but I'll be working on that later. I seem to have messed up my understanding on how it works, and basically I should have included 6x pull-up resistors on the board. I think I can navigate it in software, but that'll be for later. Other than that, all other things are working: EEPROM, SD card, PS/2 Keyboard, Audio Data In, Audio Sound Out, and of course VGA graphics.

Thank you all for the help and support along the way. I really couldn't do it without you. And, a very very special thanks to Garth, for his continual patience with me

Thanks everyone, have a wonderful day!

Chad

Nice!

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Yes, YAY! Congrats on your success, Chad.

As for that chip, did you try swapping the old one back in again? I wouldn't be surprised if the problem re-appears, but I also wouldn't be surprised if it doesn't.

You may already be aware, but I'll remind everyone that bad connections are an extremely common cause of trouble in electrical and electronic circuits. Solder joints are one example, but switches, potentiometers and connectors can be a point of bad connection, too. And it's not at all uncommon for the "bad" connection to fix itself after being disturbed.

An IC socket (and the IC pins) together work as a form of connector, and it's possible that removing the old chip and inserting another -- or reinserting the same original chip -- is the all the disturbance that's necessary to displace the problem. Maybe there was a bit of dirt or flux that landed in the wrong place? I'm purely guessing as to the exact mechanism, but experience has taught me to be wary of hasty conclusions (such as "must've been a bad chip").

-- Jeff

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

Thank you Jeff, I appreciate it. So I did just recover that old one from the trash, and replaced the good one with the bad one, and indeed the flicker came back. I put the good one back in, and the flicker went away. I probably couldn't even take a picture of the flicker, because it only happens in very particular circumstances and fairly minor. Last night I was showing it to my wife, and she couldn't tell until I pointed it out in a very specific spot on the screen. Of course I could tell immediately because I'm *looking* for issues like that. So, does the chip "work"? Yes, it functions. Does it work well? No, something is wrong with it, and I cannot tell what exactly.

So then, is this a "bad chip"? That is actually a good question. If I had 100 of these chips, and tested all 100 of them, would I get 99 of them without flicker? Or would I get 50 of them without flicker? Am I pushing margins and I just got lucky with this particular chip? Or in the end, is this just a bad chip? All good questions to ponder on. I will say that my "Half-A-Pi" and "AcolyteRev1" boards both used the exact same setup with this particular chip, and both of those worked immediately without any flicker. So we currently have 3 out of 4 chips work and as expected, and 1 out of 4 'works', but not as expected.

I'll hang on to this chip, for curiosity sake. But my curiosity isn't so great that I'm not going to move on to the next goal

Thank you again Jeff, good analysis.

Chad

This too is a good bit of analysis!

-- Jeff

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

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

How could I check this little chip? I know it "functions" but does not function well according to my needs. It could be a number of issues. I could try it in one of my older board revisions, but I will probably get the same issue because it's the same board layout. Anybody want to test it with some fancy equipment for me? Say the word and I'll send it your way.

On other news: I just finished the Genesis controller support, I updated the github page's "AcolyteRev2.zip" file accordingly with the additional code. I use a shift register to gather all of the button states and then send them to the VIA one by one. The SNES controller works in a similar manner, but already has the shift register included inside the controller.

The Snake game can use the D-pad, and although I tested the buttons to see if it works, I have no use for them in that game. I only support 3-button Genesis controller mode right now, but it will function with a 6-button controller plugged in (that is what I'm testing it with anyways). I also was able to detect if the controller is plugged in or not, so you are not reading phantom signals.

Well guys, that's all I have for now! I have been wanting to make a serious game on this thing for a while, and now that I have color graphics, a controller, and audio-out, it is totally possible to make it look, feel, and sound good. I'm thinking Tetris... or Oregon Trail

Besides that, I am planning on making a users manual for this thing. Something classy. And hopefully you will eventually see me posting tutorial videos about this board on Youtube. Who knows!

Thanks again everyone, I appreciate the help and support very much.

Chad

You could try varying the temperature. CMOS chips tend to slow down as things get hotter, so you could either...

• heat up the "good" chip to see if it gets flaky, or
• cool down the "bad" chip to see if it cleans up its act and pulls itself together

Ideally you want to heat/cool just the one chip, without affecting the surrounding parts. Freeze mist is one good option for cooling. For heat, I'd consider applying the tip of a soldering iron, with a bead of molten solder on it to ensure you have at least a few square mm of contact area. (You'll find it's actually quite hard to raise the temperature by much.)

One other test option is to try a variety of 'HC161 chips, ideally from different lot numbers or better yet from different manufacturers. If you find even one other specimen that's unhappy at room temperature then there's a good chance your design is marginal, timing-wise.

ETA: you could also try dropping the supply voltage for the entire board to 4.5V or even lower. If it remains stable (using the new chip) then that argues against the "marginal design" theory.

-- Jeff

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

First, let's look at the datasheet for a second. Maybe you can help interpret this for me:

https://assets.nexperia.com/documents/d ... 4HC161.pdf

Specifically the attached picture.

So I'm running this at 25.175 MHz. The first values are Min/Typ/Max so I'm well within that 27/48 range there. BUT then there is the -40C to +125C stuff, which doesn't make sense to me because that's from Antarctica to the middle of an Aggie bonfire. And I DON'T meet that range. At 25 MHz I'm above the 21 and 18 mark. Now, it is getting pretty warm here in Texas, but I didn't stick this in the oven or something. Before I start laying my soldering iron on good chips, can you explain what I'm looking at?

Here's another thing: I am literally just copying George's (gfoot) circuit. And he and many others have used these '161s/'163s at 25.175 MHz. Jeff, you in particular showed me how to use this chip on a previous build where I was using it at exactly the same speed. Looking at the schematic, FOUR other chips are directly pulling from that same oscillator, and another EIGHT chips are using it's inverse. None of those guys have issues it seems, only this one sad '161.

I could try to find a variety of '161s, and I honestly am considering it. I want this to be a solid build, I want to prove this build. To myself, and to you.

I'll start with sticking this bad chip in the freezer and seeing if that helps. That at least that is safe enough to test.

Thank you Jeff, good discussion, I appreciate the insight.

Chad

EDIT: I saw your 'ETA', I can also try that. I... don't know HOW to do that right now, but I can attempt it Thank you, good idea.

A hilarious preliminary test: I stuck it in the freezer for a bit, not super long, but I then raced it to the board and turned it on. And basically the whole screen was ALL messed up and flickering. And then, slowly, it started becoming clearer and clearer, like it was warming up. Then I pressed my finger on it, to warm it up more, and it steadily got better and better. Then I switched fingers and it continued to get better until it was only flickering at the far left edge a bit. It wasn't a pressure thing, it was a heat thing. So, was it supposed to be BETTER when it was cold?

It's back in the freezer again, and I'll try it again later. Just an update.

Chad

Last post on this issue:

I found an LM1117-3V3 in storage, and I set it up with the recommend configuration:

https://www.ti.com/lit/ds/symlink/lm1117.pdf

I tested it with a multimeter, 3.3V right on. I connected it to the board, and... I got VGA to display! It is my initial RAM display, just a load of junk colors, as if I didn't have a processor or ROM plugged in. But no flicker! Nothing at all I could see. So, though it doesn't *run* at 3.3V, it does *display* at 3.3V. [ Don't know why in particular it wouldn't run the processor at 3V3, but I wasn't expecting it anyways. ]

I am VERY surprised about this. I honestly thought nothing would happen. But to see the 16-color junk on the screen, without flicker or change, means this is case closed. I'm done worrying about the darn chip, I probably damaged it with static electricity or something, who knows. Still, a good reason to use sockets, and not just solder the darn thing to the board permanently.

Thank you Jeff, I hope this proves my board to you.

Chad

Chad,
Late to the discussion but I have a different view of your HC161 problem. The problem is not HC161 too slow but HC161 too fast is the problem!

Your original description of flickering going away when touching with your hand or scope probe suggested adding capacitance (your hand or scope probe) slowed down the signal thus reduced system noise (reflection or cross talk). Cold temperature speeds up HC device thus increases system noise; low voltage slows down HC devices thus decreases system noise. It all fit. You have a system noise problem most likely reflection.

Part of a new design qualification is sweeping the supply voltage and place the new product in temperature chamber, hot and cold while running diagnostics. It is an effective way to check for system noise and performance margin. Hobbyists do not have temperature chamber but adjustable power supply, small heat gun and cooling spray are useful tools to have.

BTW, not surprise at all your board working at 3.3V.

Bill

LOL! You're welcome! But honestly I was at a loss to reply to this, simply because my knowledge of your project is so superficial. I'm glad Bill spoke up with a more insightful take on the matter!

-- Jeff

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

Bill, thank you so much for this analysis! I read it last night and have been thinking about it. And I have now (re)learned what this "reflection noise" is. I also went to some websites trying to find ways to reduce it. And I am coming up empty. I mean, I see a lot of articles and stuff about it. Here is a good one:

https://hackaday.com/2018/09/28/inducta ... the-fugly/

I'm a math teacher. But even I'm confused here. I keep seeing so many formulas for calculating trace inductance and whatnot, great, but I have no clue what it would even mean. Obviously I can study this topic for the next few years, sure, but as a math teacher, I don't just tell my students to "read the book". In fact, I hate when teachers say that (a serious pet-peeve of mine). The point of the teacher is to explain in a way that reaches that particular student, without a book.

So I guess I'm asking for a "practical" explanation, rule-of-thumb, not of what this noise is, but how to reduce it. Attached is my board layout with VCC and GND traces, and the board layout with all traces. I put decoupling capacitors everywhere (as BDD says, they are like money, can never have enough). I made the VCC/GND planes with the grid. The chips are pretty close together. Some signals lines are longer than others, sure, but not everything can be right up against the next. I've seen suggestions to add pull-up/down resistors to signal lines to reduce noise, but that is also dependent on the amount of inductance and whatnot, and that would be a HUGE road to start going down.

I'm not a professional, and I probably won't ever be capable of making 'professional grade' work like Garth, Bill, Jeff, BDD, and others are capable of. But I could at least take some suggestions to heart when printing the next revision. Thoughts?

[ BTW, my wife is tired of my antics on this particular discussion. She says, "It was a bad chip, toss it, move on!" Something to be said there? ]

Thank you everyone, I appreciate your insights, analysis, thoughts, and time. I truly do. (If I didn't, I would have moved on long ago.)

Chad

Chad,
Signal Integrity (measurements of signal quality) is a difficult subject. There are tools that can take in the Gerber photoplots and bill of materials plus additional parameters and generate a list of signal integrity warnings but these tools are very expensive (at least 15 years ago). In absence of such tools and in the days before such tools were available, there are some rules that work (most of the times).

Filter cap and bypass cap are important but less so for multi-layer PCB with power and ground planes. Looking at your board design I see you've done an excellent job of forming power and ground grids on 2-layer PCB. That checks the box on good power & ground distribution.

Logic transition speed is the biggest problem affecting signal integrity. Transition speed is the transit time from 10% to 90% of final voltages. In most logic families falling edge is faster than rising edge so most signal integrity attention is focus on the falling edge. Termination is generally recommended if round trip propagation time is greater than the transition time. That boils down to the rule of 3 inch per nanosecond where "inch" refers to the circuit trace length and "nanosecond" is the logic transition time. So if your logic's transition time is 3nS then don't worry about signal length shorter than 9". Different components have different transition time; W65C02 is particularly troublesome because it is very very fast.

Signal integrity of data and address lines are not generally important because they are stable at the assertion and negation of controls. Control signals need to be as short as possible. Clock should be terminated because it goes everywhere and tend to be quite long.

Cross talk is difficult to analyze but it can happen especially when data and addresses are all switching from all (or mostly) high to all (or mostly) low. Failures due to specific data patterns are particulary difficult to troubleshoot.

Looking at your board with signal integrity mindset, I see good power & ground grids and fairly densely packed logic to reduce trace lengths, good. I see you are using fairly slow logic and RAM/ROM, good. W65C02 is fast, not so good and overall board size is quite large, also not so good.

It may be a good idea to serially terminate the clocks with 75ohm located as close to the clock source as possible. 74HC161 is your clock generator so I'll examine the traces coming out of 74HC161 carefully. The circuit of AND H1/H2/H4 to generate ~LATCH worries me...

Don't toss your "bad" HC161. It is the proverbial "canary in a coal mine". It warns you of the cliff ahead and tell you what operating condition may drive you into the cliff and what improvement you can make to back away from the cliff.
Bill