Single 6522 for a few applications

[sburrow]

Plasmo, thank you, that is very encouraging. I appreciate that.

Floobydust, you have taught me a lot already! And I will look over this schematic many times. Thank you very much for that, I appreciate it.

I have news from the physical side of things (not just schematics): Lessons learned from trying to implement a LCD on a breadboard!

1) Potentiometers don't come preset with whatever you wanted them to be at (go figure). Lots of ohmmeter testing there.
2) Pull up resistors have a very particular configuration, don't vary it.
3) Apparently a capacitor will debounce a SPST somewhat. At least enough for a breadboard.
4) 16x2 LCD's are a quick way to get something exciting, with little effort.
5) Soldering tiny pins that are close together is troublesome, but a non-perfect job seemed to work today.
6) Some DIP switches and tactile buttons are trash. At least the ones I have. Literally popping off the board, into the air, if I don't hold them down at all times. Time to upgrade my basic parts!

Thank you everyone, I appreciate you.

Chad

[Michael]

sburrow wrote:

Michael, I am *sure* that's my ROM select arrangement. Surely that's what I was thinking in my mind at least.

I believe you have an unnecessary gate in front of the ROM select gate which is inverting the P=Q signal to the ROM select gate. The way you have it the IO and ROM would be enabled at $8000..$80FF and nothing would be enabled in the $8100..$FFFF address space.

It's easier for me to study the logic if you depict the 74HC00 gates instead of the package. Updated drawing below...

Good luck. Have fun.

[sburrow]

Michael, I think you are right. I'm thinking it through now, and I do believe you are correct.

Thank you for that, I appreciate your patience with me. And yes, logic not package next time.

Chad

[Michael]

If I may... I'm not sure if it would be an advantage or not but adding a jumper block and pull-downs to the 74HC688 'Q' inputs would allow you to set or change the I/O page in the address space. In the example below a 74HC139 is used for the 'glue' logic, half of it being used to provide clock qualified /RD and /WR signals, the other half used to insert the I/O page into RAM or ROM space. Basically just another two chip decoder + glue logic solution for 32K RAM and 32K ROM but with jumper configurable I/O page address.

[sburrow]

Mike, that is a great layout. And you didn't even use a 74'00?! Amazing. I will study this in depth going forward. I really appreciate it.

Chad

[Dr Jefyll]

Chad, your approach (above) with the clock switch isn't the best. It'll work in full speed and it'll work in single step but when you switch between the two the machine will be apt to crash due to the CPU clock input momentarily floating and/or receiving mangled clock pulses.

Circuits exist to glitchlessly switch between clock sources, but they're not quite trivial. I'd suggest you omit the single step feature or choose an approach that uses the CPU RDY input (rather than manipulating the clock itself).

The manual for the Apple 1 has a single-step circuit using just a single 7474. It's somewhat obscure (to me, at least), so I redrew it in a way I find clearer. Also, with the CMOS 'HC74 in mind, I added some pullup resistors and Vcc connections which aren't strictly necessary with the TTL part.

"Single Instruction" mode allows the CPU to advance 2 or more cycles at a time, stopping when SYNC goes high (indicating the next opcode is being fetched). "Single Cycle" mode is slower and more detailed, stopping on every cycle. (Exception: During write cycles, NMOS CPU's cannot be stopped using RDY.)

-- Jeff

[sburrow]

Dr Jefyll wrote:

It'll work in full speed and it'll work in single step but when you switch between the two the machine will be apt to crash due to the CPU clock input momentarily floating and/or receiving mangled clock pulses.

Thank you Jeff! Hm, go figure. I am finding more and more that "slap a switch on it" or "just put a capacitor on it" isn't good enough. These little details completely escape me, until you mention them. So thank you.

I had seen Woz's schematic for it, but yes, yours is better for sure.

So you mentioned to maybe ditch it altogether? I see that most if not all of y'all do not use it. But then again, y'all know what's going on and have been doing it for a while. The point of me having this feature at all would be to debug somehow. If it's worth an extra chip and more complexity, I'm willing to keep it. If it's not worth it in the end, then I'm willing to ditch it.

Either way, thank you Jeff, I will remember this for sure.

Chad

[Dr Jefyll]

sburrow wrote:

The point of me having this feature at all would be to debug somehow. If it's worth an extra chip and more complexity, I'm willing to keep it.

"Worth it" will depend. Yes it's helpful for debug but other debug techniques can take its place.

Being able to freeze the CPU means you can very slowly (at human speed) poke around and measure logic levels one by one by using a logic probe, or even a multimeter. That's pretty powerful if you don't have an oscilloscope... but if you do then in many cases the 'scope will be preferable to single stepping. And something that's more powerful yet is a logic analyzer, but at this level it's possible to get carried away with fancy tools; they can be a distraction from using your eyes and your brain to be on the lookout for simple mistakes.

If you do include the single step, you may wanna also include some LED's on the buses, because it's a whole lot easier to just look at 8 LED's and say, "Oh - that's hex 34," or whatever, rather than doing 8 successive pokes with the logic probe. Ideally you'd have 8 LED's for the data bus and 16 for the address, but last time I did this I omitted the LED's for A8-A15. Speaking of LED's, you'd wanna include R/W and probably SYNC.

Also nice if the LED current-limiting resistors are in an array; also nice if the array is socketed so you can unplug and replace the entire array if the resistance you initially chose turns out not to be the best.

-- Jeff

[sburrow]

Dr Jefyll wrote:

Ideally you'd have 8 LED's for the data bus and 16 for the address, but last time I did this I omitted the LED's for A8-A15.

Jeff, thank you. I was thinking of doing this, but it got shot down for some reason or another. I personally think it's super helpful, but I'm new to this whole thing, so maybe I'm just weird. I do think it would be most beneficial in a single-step mode for sure.

You are right, I don't have a 'scope, I only have a little multimeter. Just buying equipment for a project is expensive unto itself! Let alone the actual project cost.

Because I'm starting from zero, there is a lot of up-front cost. I'm finding that out quickly.

Thank you again Jeff.

Chad

[BigEd]

sburrow wrote:

Dr Jefyll wrote:

Ideally you'd have 8 LED's for the data bus and 16 for the address, but last time I did this I omitted the LED's for A8-A15.

Jeff, thank you. I was thinking of doing this, but it got shot down for some reason or another. I personally think it's super helpful, but I'm new to this whole thing, so maybe I'm just weird. I do think it would be most beneficial in a single-step mode for sure.

That was KM:

Quote:

having LEDs on the databus is of little value, same for a speaker on an address line. Adding single step... is this really thought thru?

It's another good lesson I think - everyone here has a different experience and different opinions. Many of the pieces of advice you get will be based on opinion or on a judgement call. You have to navigate that as best you can. At some point you need to try some things out, you need to build something and you will need to debug what you've built. If your design is right, you just need to build it correctly. If the design is flawed, you'll have to revisit it.

Eventually, you get to the point of running code, and you'll find you need to debug the code too.

There's no substitute for being careful at every step: checking what you've done, thinking through what it means. If something is puzzling you, make notes, and make one change at a time. Start simple.

Don't be tempted to just throw ideas out here to see what the feedback is - that's not very efficient. You'll do much better if you first review your ideas and try them out.

When you're building a system and debugging it, what you're really doing is building a mental model of it, so you understand what it's doing and why. If you're finding it hard going, that might be because it's not simple enough.

(I'm not sure if I've ever single-stepped - it's possible I have, on a trainer board. What I certainly have done is written out code on paper and single-stepped it by hand. That needs very little equipment! It's a very valuable thing to do.)

[BigDumbDinosaur]

sburrow wrote:

You are right, I don't have a 'scope, I only have a little multimeter. Just buying equipment for a project is expensive unto itself! Let alone the actual project cost.

Because I'm starting from zero, there is a lot of up-front cost. I'm finding that out quickly.

I see everyone is offering suggestions on what test gear you might need to debug your hardware when you get it built. I might as well add to the confusion.

I'll start by stating the obvious. Computer circuits are fundamentally very simple in operation. Things are either on or off, yes or no, 1 or 0, etc. This binary simplicity means there are two types of faults that usually pop up in new designs: logic errors and timing violations (very rarely, a defective part will cause trouble). The former are actually fairly easy to diagnose, even with basic test gear; the latter, not so much. Fortunately, at low clock speeds, logic errors are far more likely to give you grief than timing violations. As has often been noted around here, you can get away with murder at 1 MHz.

When I say "logic errors," I group into that category errors due to improper circuit design and errors caused by improper circuit construction. The best way to debug the former is to do logic proofs on your design. These are nothing more than color-coded markups of copies of your schematic, such as the following:

Example Logic Proof

The above is the glue logic for my POC V1.3 unit. Red lines are parts of the circuit that should be at logic 1 (~5 volts) for the address $00C000 and the green lines are signals that should be at logic 0. Incidentally, note that I drew AND, OR, etc., gates as traditional logic symbols, not black boxes with connections—the latter tell you nothing about the circuit's logic progression. I reserve the black box notation for devices with complex functions, such as the 74AC138 decoder.

Using a technique such as the above and assuming you understand how the components of your design function, you will be able to see exactly how your circuit should behave with any given address on the bus. Hence if there is a logic error in the design you should be able to uncover it. If you do that for all the key address situations you expect in your system, e.g., RAM selection, ROM selection, etc., you will likely find all logic errors. I recommend you give it a try before wiring up your system and being disappointed when nothing good happens.

The other source of logic errors is mistakes in construction. These are much more likely in a wired unit than one built on a PCB, assuming the PCB layout is correct (there are ways to positively verify the layout against the original schematic). You avoid construction errors by being meticulous as you work and by developing a procedure that helps you keep track of which connections have to be made and where. You also double- and triple-check that you've inserted parts into the unit the right way. It's no fun having to open the windows to ventilate the room after the unit has belched out some smoke due to a backward chip, mis-inserted electrolytic capacitor, etc.

Despite best efforts, things won't always work as planned and some troubleshooting will be necessary. Troubleshooting a new design is not easy as troubleshooting one that was working and subsequently went kaput. Nevertheless, just about all of us here that have scratch-built systems have managed to get DOA new designs running (my very first POC unit was DOA due to a missing trace on the PCB). It's a matter of understanding how it should work—the above logic proof technique can help—and using a systematic troubleshooting method that includes first checking the obvious things.

Going back to my earlier statement that computer circuits are fundamentally simple in nature, the one tool that takes advantage of that characteristic is a logic probe. A logic probe is an inexpensive device and sufficient to diagnose most DOA situations. Even though I have a scope and a logic analyzer, I continue to first reach for the logic probe when I need to know what a circuit is doing...or not doing. A logic probe will quickly tell you if a circuit is high (red), low (green) or pulsing. With some experience, you will even be able to tell if a pulsing circuit is spending more time being high than low or vice versa. If I were allowed to have only one piece of test gear to work with my POC units it would be a logic probe.

A multimeter is useful for looking for specific voltage levels. However, most are too slow to be useful with active digital circuits. I've got two multimeters, but mostly use them for analog work.

Mention has been made of an oscilloscope and logic analyzer. If you continue to pursue the homebrew computer construction hobby you will eventually want to get a good scope. While a logic probe can tell you a circuit's state, it can't tell you if signal timing is rational or if operating conditions are suitable. This diagnostic limitation will become important when you decide you want to ramp up the clock rate. A scope will be invaluable when it comes to diagnosing timing issues and/or poor signal quality, things that become important when designing for high clock rates.

A logic analyzer should be considered a luxury item best reserved for when you get to where you are trying to get your latest creation running at 30 MHz and you need to watch many things at the same time. Although I have worked with digital electronics for some 50 years, I never used a logic analyzer in any of my professional activities, and it is only in the last year that I finally decided to get one (the money was burning a hole in my pocket ). I've used it to analyze the behavior of my POC V1.2 and V1.3 units, both of which run at pretty high clock rates, mainly to see just how the 65C816 behaves going real fast. Also, it was handy in determining why POC V1.3 wouldn't boot at 20 MHz, but was fine at 16 MHz. However, I've yet to use it to debug a piece of DOA hardware.

As for single-stepping, with the 65C02 you can do that with a stoppable clock source or by using the MPU's RDY input. The trick in using either one is in stopping and starting the MPU in a way that won't glitch anything and cause a crash. Circuits for doing both are all over the place—and there are arguments in favor of both methods. I have a crude clock single-stepper that I made to debug a problem in my POC V1.2 unit, which was my first and only use of it in debugging any POC unit. I did that in conjunction with my logic probe and it only took about 10 clock cycles to identify the problem. Your mileage will vary, of course.

[BigDumbDinosaur]

BigEd wrote:

There's no substitute for being careful at every step: checking what you've done, thinking through what it means. If something is puzzling you, make notes, and make one change at a time. Start simple.

Amen to that.

I'll add to Ed's advice that if you get stumped and need help resolving a problem once you get your unit built, organize your thoughts and marshal the results of your troubleshooting attempts before you post asking for help. Most everyone here is willing to help but can't do so if you aren't concise and clear.

Quote:

Don't be tempted to just throw ideas out here to see what the feedback is - that's not very efficient. You'll do much better if you first review your ideas and try them out.

That's also good advice. Come up with a plan, determine to the best of your ability that it is a workable plan, and then execute it. At some point, you need to stop designing and start building.

[sburrow]

Ed and BDD, thank you both.

That is very good advice, I like the red/green lines.

I can now see that you are also right about tossing things together and then asking y'all if it looks good. In a subtle way, I started relying on y'all to solve my problems, instead of myself. It creeps on you.

Logic probe sounds like a good idea. And is cheap. That's on my list. Thank you.

And yes, eventually finish planning, and start building.

I've been learning a whole lot. Thank you all so very much. I'm working (very slowly) through a (simple) design, that I am sure I can pull off, and will keep you posted.

Chad

[floobydust]

BigEd wrote:

sburrow wrote:

Dr Jefyll wrote:

Ideally you'd have 8 LED's for the data bus and 16 for the address, but last time I did this I omitted the LED's for A8-A15.

Jeff, thank you. I was thinking of doing this, but it got shot down for some reason or another. I personally think it's super helpful, but I'm new to this whole thing, so maybe I'm just weird. I do think it would be most beneficial in a single-step mode for sure.

That was KM:

Quote:

having LEDs on the databus is of little value, same for a speaker on an address line. Adding single step... is this really thought thru?

It's another good lesson I think - everyone here has a different experience and different opinions. Many of the pieces of advice you get will be based on opinion or on a judgement call. You have to navigate that as best you can. At some point you need to try some things out, you need to build something and you will need to debug what you've built. If your design is right, you just need to build it correctly. If the design is flawed, you'll have to revisit it.

Eventually, you get to the point of running code, and you'll find you need to debug the code too.

There's no substitute for being careful at every step: checking what you've done, thinking through what it means. If something is puzzling you, make notes, and make one change at a time. Start simple.

Don't be tempted to just throw ideas out here to see what the feedback is - that's not very efficient. You'll do much better if you first review your ideas and try them out.

When you're building a system and debugging it, what you're really doing is building a mental model of it, so you understand what it's doing and why. If you're finding it hard going, that might be because it's not simple enough.

(I'm not sure if I've ever single-stepped - it's possible I have, on a trainer board. What I certainly have done is written out code on paper and single-stepped it by hand. That needs very little equipment! It's a very valuable thing to do.)

Yup, that was me.... not being a fan of adding LEDs and such. The basic goal (which apparently keeps changing) is/was to build something simple first. I think at one point, the thought was to build something with a single UART and get it working. I also thought it was going to be on a breadboard, so again, keeping it simple and minimal makes sense. Adding all of the extras will just make it difficult to debug, especially if one has no former experience in making something like this. So, I'll still keep my opinion as is... simple and minimal is better for a first project.

[sburrow]

floobydust wrote:

So, I'll still keep my opinion as is... simple and minimal is better for a first project.

I completely agree. I am doing just that. And thank you for your continued support and help. I don't plan on showing y'all anything until I'm super super sure about it. No more "hey look at this". I would like to run it by y'all just before I print a board, and that's it.

Other than that, is it ok if I ask smaller questions along the way? Like here is a question floobydust: Why 3.3K pull-up resistors? Why not 4.7K? Why not 5K? Why not 1K? Yes I could do the math, but the math seems screwy at times. I was working on a little LCD breadboard project a day or two ago, and I used 1K pull-up resistors and it worked great. I've seen different values all over the internet. Some folks even use 10K, for whatever reason. The idea is straightforward enough: Put in a resistor where enough voltage gets through that it still triggers a high-logic state, but when grounded the resistor keeps enough voltage back that it stays in a low-logic state.

Just a smaller question. Most folks on the internet seem to answer: "That's just what I've always done."

Anyways, thank you again for everything, sorry that my small question might be silly. No need to reply if it's too silly.

Chad