6502.org

It is recognizably a piece of writing into which a lot of effort has been invested; brevity is hard, and brevity and clarity simultaneously are even harder.

I'm not going to try to convince you to do it differently; it's your work, to be presented as you see fit.

Another way of looking at it is that there's a lot you don't need to know or understand, so long as you follow usual practice.

An example might be decoupling capacitors: if you just put them in, one per DIP, they will probably save you some struggling. The whole theory of what they are doing for you, why you need that, and how they do it, is not necessary.

On the other hand, if you make up your own theory as to how to do power supply, you're putting yourself onto a detour, a long journey of learning by trial and error.

The main concern I keep coming back to is that a person needs to keep their enthusiasm and interest. Debugging is a necessary part of this hobby, but if you start off with idiosyncratic approaches, there's a risk that you'll build a series of not-working or unreliable machines, and that leads to the risk that you'll give up.

This is one reason why you will see, over and over, the same advice to start simple, to start by building a known-good design, and become your own designer at a slightly later stage.

I think this is a very valid concern but I seem to have done a poor job of explaining the approach I'd prefer to follow and why Garth's primer is not a good match for my approach. That doesn't mean it isn't an excellent resource or that I won't use it or try to understand sections of it; but it's unlikely to be my guide as I explore learning about the area.

So I'll try to do a better job of explaining how I prefer to learn things: it's fun to build things in tiny, tiny steps. Each time some baby step doesn't work it may require learning a thing all the way to the bottom, to understand it fully: but not every single thing needs to be learned up front.

Let me try with some examples: I'll start with yours, the need for decoupling capacitors. It's easy enough to discover that using three sizes of decoupling capacitors was standard practice at one time for each DIP and just start throwing on three capacitors at every chip - but this seems like a lot of work to do a thing one doesn't understand. If you build some simple circuits and put an oscilloscope on the pins to see what's going on and measure the difference between having long power leads to the chip vs having a small decoupling capacitor near by, it doesn't take long to measure what a huge difference the decoupling capacitor makes - nor to conclude that a single decoupling capacitor is sufficient. It's much more satisfying to learn it properly.

Still, I was able to build a "working" 6502 computer on breadboards with decoupling capacitors only on the power rails and not one per chip, validating the overall plan of what I'm building without needing to know about or understand about decoupling capacitors before I got started. That, ultimately, is what for me can help sustain my interest and perseverance: the ability to make progress without knowing everything in advance.

When the primer has as a prerequisite knowledge of all the 74-series chips that feels like a steep hill to climb when my actual circuits only need a few logic gates, mainly NAND gates, and perhaps a buffer. Do I really need to know about counters, synchronous counters, BCD decoders, BCD to seven-segment display chips, flip flops, 4 bit adders, shift registers, timers, and 64-bit memories? It seems to me simpler to focus on maybe the basic logic gates and buffers that I might want at first and learn about things like schmitt triggers and shift registers when I need them in my circuit (if ever).

When I say I don't understand AC circuits, it's because I don't understand how electrical force moves through space; I realize that changes in electric potential (voltage) create or collapse magnetic fields, and that moving magnetic fields induce current in neighbouring wires, but not why having a ground plane is sufficient to tame this problem while a twisted pair apparently is not. Learning how this works will wait until I have had a chance to verify that my build does not work at a frequency I care about, which several who know much more than I have assured me is the case; but once faced with a non-working computer at 1Mhz that works perfectly fine at a few khz, I'll have to dig in and understand it.

To attempt to summarize: what will keep me engaged is learning step by step what I need to know to add things to my system. The smaller these steps are the less likely that I will encounter a dead end that can't be understood and debugged. I thought it was pretty good progress to have a debug monitor that will show me the bus activity and disassembly of the running assembly in a week's time, and still feel interested in getting a serial interface going and attaching a keyboard and monitor all of which can be done without scaling the rather steep hill of how electrical force travels through space rather than through wires.

To me, setting aside time to learn everything in advance of building anything doesn't seem at all the right way to stay motivated and get things learned; learning enough to build a 6502 that can run at 20 Mhz seems unnecessary when there is so much fun to be had even at a few kilohertz.

What it says is, "common 74-family logic ICs and their functions," not "all the 74-series chips."  I'll edit it to clarify.  I would consider the "common ones" to be the 74xx00 quad 2-input NAND, the '04 hex inverter, the '02 quad 2-input NOR, the '74 flip-flop, and perhaps the '138  3-to-8-line decoder and '139 dual 2-to-4-line decoder, only six in all.  For most others, the rare times I use them, I usually go back to the data book and look up functions, pick an IC, go to its data sheet, and see if it'll do what I'm thinking.
I'm not sure where that idea came from.  The old standard practice, which is not really appropriate anymore for modern SMT PCBs but is fine for home-made wired-up stuff with DIPs, is that you put a small monolithic capacitor at each IC, with the shortest possible connection between its power pin and its ground pin, and then perhaps just a few bigger ones around the board, and only one bulk 100µF for example right where the power comes into the board.  If you look at even this absolutely huge board which is mostly memory, from 1985, you'll see the little yellow monolithic ceramic capacitors at the end of each IC, and only two small electrolytics, way up in the upper-left corner.  That's all.

You might need to slow down a little to catch more of the important details.  We wish you success.

Hi Osric
this is good - you know what kinds of things keep you interested. And I agree with the idea that different people approach things in different ways.

Garth's primer is a useful resource and represents a great deal of work. But personally I wouldn't suggest that a person should start by reading it all (still less, studying and retaining it all.) I would note that writing is hard, and teaching is hard, so pretty much every document which aims to help will inevitably be flawed, and yet at the same time still have value.

You will get different kinds of responses and advice here - no-one should take any of it as definitive. It's all input to the learning process, and anyone's comments always reflects their own personal take on what they think is needed at the time.

Please be encouraged!

What we didn't have in the 1960's was single digit rise and fall times either.

Personally, I like his idea of trial and error. I too, am someone who learns very well from re-inventing the wheel (as perceived by some).

To me this is the most important thing above all. Learning, making, and correcting mistakes is what it's all about.

Really, that's why we are all here. None of us are going to be the next Bill Gates, by playing with fifty year old based CPU's in reality.

If your goal in editing is to make it accurate to your intent, that edit sounds good.

There may also be a mismatch in what we consider to constitute "familiarity". I for one wouldn't consider myself familiar even with these common chips without answering mystery questions like why the pins on the NOR chip are backwards. Surely everyone who has touched this IC has wired it backwards the first time? Why, why, why are the pins backwards? I don't know, it bothers me every time I look at these ICs: but I have not yet needed to know why, and I won't be familiar with these chips until I do. I suppose it is at least a good lesson in always checking the datasheet unless you have the pinout committed to memory.That idea comes from Eric Bogatin in this video https://www.youtube.com/watch?v=y4REmZlE7Jg and his example boards are at about 30m into the video at https://www.youtube.com/watch?v=y4REmZlE7Jg&t=1800s

The problem here may be that I said "for each DIP" as that's how it looked to me in his explanation but the underlying point remains that this topic can wait to be understood when it is encountered, rather than considered a prerequisite to start building things.

It would not at all surprise me that this was true, as I'm generally a disorganized person. Yet in this case, I don't feel like my approach is so disorganized, and would welcome specific feedback on how to organize it (just as I've asked what you think an appropriate smaller scope next step would be, but not seen an answer). To recap, my approach is to build simple steps and test and understand each one in a modular way, with the intention of having circuits whose function I understand completely and a working artifact at each step. To that end, the sequence of steps I followed was:

1- build a debug monitor board out of an RP2040, using individual GPIOs to monitor Φ2, data bus, address bus, and RWB, with LEDs and pulldowns to show the state of the buses
2- add a static-core 6502 and respond to its reset sequence from the debug monitor to verify that I could single step to the reset vector load and run arbitrary assembled code in the processor
3- add a VIA and use it to control a small 2-line LCD display
4- add EEPROM and RAM to the system (I hesitated to add these together but since their pinouts were identical it didn't seem too big a risk to add two ICs at once)
5- build in-circuit programming of the EEPROM into the debug monitor, with the ability to dump and write sections of the EEPROM without removing it from the system
6- remove the debug monitor's ability to drive the bus in response to the CPU (I don't want the running system to rely on this module in the end)
7- post here about my lack of understanding of the datasheet's requirements for the BE/RDY pins because it wasn't clear to me whether I'd need or want to use RDY to implement the DMA I intend to use for the mono monitor display module
8- internalize and respond to your feedback about building a simpler next step rather than doing the monochrome display next

I hope I'm being open to feedback and would welcome an alternate plan that I could have followed or that I should proceed to follow to be more organized. I don't consider learning how to measure the effect of these capacitors and why they matter reinventing the wheel; I consider it my opportunity to get a grounding in theory. I had to re-learn how to operate my oscilloscope for this project, and that was fun. My goal isn't to discover personally how things work by trial and error, but to learn how things work as I encounter obstacles or things I don't understand, and when I crash my computer by attaching the scope that is likely to lead to a multi-day effort to understand why what I did was wrong and how to avoid it in the future. The point I seem to be failing to make is that I can learn about that when I encounter the obstacle; I do not need to understand it now, as I am not having that problem yet.
I think I have given off the impression that I am unwilling to learn the theory or study existing models to see how I might do things. What I'm trying to say is that I am willing to learn the theory - as deeply as I can - as I encounter things I don't understand. But since I like to understand things all the way to the bottom, learning everything that I might someday need to know is a recipe for never doing anything and spending all my remaining time on the planet learning stuff. That'd be fun, too, but I'd rather make some progress.

There is not, to me, a big difference between "working" and "stable"; the quotes around working are meant to denote the fact that it's not really tested/validated to be working, let alone stable for long term operation. I interpret the quotes around "stable" to mean "stable under only particular conditions"; so if you told me you had a "stable" circuit I would assume it might not work at 50C while it works perfectly well between 15C and 30C. If you said you had a working circuit (with no quotes) I would assume it was also stable within the parameters of its components but not take for granted that this was validated; while if you claimed to have a stable circuit (with no quotes) I would assume you're asserting that you've tested the circuit for long term performance at the edges of your specifications (and be surprised by that, as that's expensive and hard to do; but that's what it takes to say a thing is stable).I'm not trying to manufacture controversy. I took that list from the TTL cookbook, which seemed to me as good a list as any of "common 74-series ICs". I still don't think the reader needs to be familiar with these ICs to start building a 6502; I think being able to muddle through a datasheet for one of these ICs is sufficient.
Ground planes are literally in the fourth sentence of the primer's section on AC performance problems: "Solderless breadboards make for the longest connecting wires of any method (meaning most inductance), have extra capacitance between neighboring tie points, and there's no chance of getting anything even remotely resembling a ground plane."

When I read a sentence like that, I immediately wonder why twisted pair connections can't serve the same purpose as a ground plane for using solderless breadboards to prototype 6502 systems. It shines a light on my lack of knowledge of how this works.

There's no doubt in my mind that I will return to Garth's primer again and again as I encounter situations I don't understand. I'll consider it more of a bible or a reference to be referred to when I have driven myself into some dead end that doesn't make sense: those situations always signal a lack of real understanding of some element of what I'm trying to do. So it'll be a powerful tool, even if I don't use it as a "primer" but rather as a reference.

Thanks for the encouragement!

Thanks!

For me, this is a retirement project ... back when I went to university I didn't know if I wanted to do computer science or computer engineering. I am very glad I chose computer science, but now that I have the time to go back and play with hardware it's very fun to do so. It's also incredible to me how things which seemed so enormously complicated as a teenager seem so simple now - assembly language, for example - and of course it's fun to play with trivial programs on the bare metal rather than a huge stack of abstractions.

I probably shouldn't have used the words "twisted pair" to describe the approach. In my case, I have created exactly the problem described - long curving wires for both the data bus and the address bus, in order to enable building the components of my system out of separable and hopefully rearrangeable breadboards, as pictured in the attachment.

Therefore, based on everyone's feedback, I am expecting that when I test this setup at 1Mhz it will fail. I haven't yet had the time to do it but it seems like a simple test where I fill the RAM with a pattern and then check for its existence then fill with a different pattern ad infinitum will likely show a problem if I run the computer at a high enough clock.

Once I do that and it fails, I'm left with the task of understanding why it fails. It seems that the reason why it fails (?) may be that the sharp rising edges on the long wires of the address and/or data bus may induce currents in the neighbouring wires and cause issues. Assuming that I want to make the breadboard build I have work at these speeds, I'll have to come up with some solution.

You've already told me that softening the edges isn't going to work but in fact will make the problem worse; I don't know why that is, but will have to learn.

Meanwhile, the twisted pair alternative presumably also won't work but the idea is not to twist each signal wire with an adjacent one, but to pair each address and data line with a ground line going to the same destination. If all the signals and grounds are connected chip-to-chip in adjacent runs, I had thought that this would solve the problem. This too apparently will not work - I would have said it "resembles a ground plane" - and again is something I'll need to understand _why_ it won't work.