Single 6522 for a few applications

[sburrow]

BigDumbDinosaur wrote:

A good width for the VCC and ground grid traces is 0.050"-0.060". Here, size will matter, as you absolutely don't want any possibility of voltage drop in the power distribution grid.

Turning back to signal traces, I wouldn't go any larger than 0.010" width and if your PCB drafting software will allow it, go smaller. Doing so will make routing easier.

These are great numbers, I will definitely be keeping these in mind. I often see some designs (even your own), that it is possible to run traces BETWEEN pins! That amazing to me, and of course super helpful if possible.

BigDumbDinosaur wrote:

What is typically done on two-layer PCBs is to run the VCC and ground traces on opposite sides of the board. In my designs, I go north-south on top and east-west on the bottom, as seen in the above illustration (which, incidentally, has an amusing layout error in it). Traces are also run at angles on both sides as necessary to shorten signal paths and dodge obstacles, such as mounting holes.

I had the VCC on the top and the GND on the bottom in my mind for a while now. Glad that that's confirmed! I do see the N-S and E-W lines. I will consider that as well.

BigDumbDinosaur wrote:

Where traces branch off the power distribution grid to individual chips you can use a trace width equal to or slightly smaller than the pad diameter to which it will connect. If the path has to change layers, use a via at least one size larger than the trace width.

Those are good rules to go by. Thank you.

So, during the past couple of months, I have used some PCB software (I'm using a Kicad suite on Linux), and have learned a lot just from my trying stuff out there. But often the issue I start with is "how big should I make these traces" or "how big are the vias supposed to be" or "how much gap should I put between traces", etc. BDD, thank you for this info, it has cleared up a lot. I appreciate the time you take to reply, nothing goes to waste.

Chad

[sburrow]

plasmo wrote:

Chad,
I think you are quite young and still have good eyes and nimble hands, so don't be afraid to hand wire your design. A hybrid of printed pc board for address/data buses and handwire for control logic is a reasonable approach.

Thank you for this info Bill! I appreciate that. I do think I have nimble-ish hands still, though eyes have never been great.

I like your design and think it's nifty. Those look like REALLY tiny wires, but then all the easier to fit more on the board.

Is that a Flash card for IDE? Might I ask, is that fairly easy to interface? My current thoughts are to use SPI interface with SD Cards, using a little adapter board. I'm more "at home" with parallel interfaces, in my mind I think they make more sense than serial [ remember I'm new ].

Bill, I want to say thank you for something else. Your last post a few pages back really helped me zoom out. Essentially you were telling me to just jump in and figure it out. Make mistakes, and that's ok. Your words:

plasmo wrote:

I would encourage you to go forward with prototyping and PC board fabrication. There are plenty of challenges ahead so dive in and bring the lesson-learned back to the design process in next iteration.

So thank you for that Bill. That's what I'm on the path of doing right now.

And to everyone, thank you for your helping me along, teaching me so many new things! I will still be asking small questions if that is ok. But I'm not going to be showing any more schematics for a while yet. I plan on having a PCB design complete before the next presentation. I know that it will not be exactly as any one person has suggested, not because I'm not listening to you, but because I have to make my own mistakes and I can't include/exclude every single thing mentioned so far.

Anyways, thanks everyone. You have been a great help, and I can tell you really like what you do. That's great to see.

Chad

[GARTHWILSON]

sburrow wrote:

I often see some designs (even your own), that it is possible to run traces BETWEEN pins! That amazing to me, and of course super helpful if possible.

Definitely. I use .030" holes for DIP pins, with .050" pads, leaving .050" of space between them. With .007" traces and spaces, you can run three traces between pads.

Going down to .006"/.006", which all board manufacturers can go down to before they start to charge extra, and narrowing the pads to .046" on the sides (where traces don't come into the pad), you can actually fit four traces between, like this:

When they drill the holes, they have to start slightly bigger than you specify, and then the plating inside the hole brings the diameter down to what you specified. Further, although the machinery is impressively accurate, it's not perfect, and the hole may not be perfectly centered. Yet further, there's usually a ±.002" or ±.003" tolerance on the drill size, which I assume comes partly from the bit making a slightly larger, more-ragged hole as it wears. For these reasons, I like to have the width of the ring around the hole to be no less than .010" (per side), particularly where a trace meets it, as having the trace just fall down into the hole, without meeting a pad, makes for a less reliable connection.

Again, .006"/.006" is no problem for any of the board manufacturers. A few have been able to go down to .002"/.002" even three decades ago! How they can make a trace that's hardly any wider than it is thick, and have a rectangular cross section, is beyond me! But if you want to pay, they can do it.

Keep in mind that vias take room also. When I worked at TEAC in 1982-83, there were a lot of boards that were single-sided and had a ton of jumpers. Today I think it would be more economical (and reliable, due to the plate-thrus) to add at least one layer and save the jumpers, and even make the board a lot smaller.

[sburrow]

GARTHWILSON wrote:

you can actually fit four traces between

Wow. Just wow. Well, I can see that my original designs on Kicad where WAY too big of traces.

Thank you, I'll be experimenting with this!

EDIT:

I've seen many board designs that have GND painted all over the board, and the data traces are cut out from that. As in, the board layer starts as all connected to ground, but then you notch out some room for traces, vias, and stuff. If you were to do this for GND on the bottom, and VCC on the top, would that be helpful to prevent voltage fluctuations? Wouldn't the predominant VCC and GND on opposite sides of the board act as a very big capacitor, kind of how 4-layer boards work?

Chad

[GARTHWILSON]

There's very little benefit to copper pours in digital work, and they certainly don't qualify as ground planes. There is a way to use them to supplement real planes; but if they're not done correctly, they can actually make things worse, according to experts in the field like Rick Hartley, Eric Bogatin, and Suzie Web whose lectures you can see on Altium's YouTube channel. If you had to stick with just two layers, you could just route everything (including power and ground), and then add extra ground and power traces everywhere possible, to make kind of a web of them.

[sburrow]

GARTHWILSON wrote:

There's very little benefit to copper pours in digital work, and they certainly don't qualify as ground planes. If you had to stick with just two layers, you could just route everything (including power and ground), and then add extra ground and power traces everywhere possible, to make kind of a web of them.

Ok, "copper pours" is the name for those things. Gotcha. Ok sounds good, thank you for that quick reply!

Chad

[BigDumbDinosaur]

sburrow wrote:

I've seen many board designs that have GND painted all over the board, and the data traces are cut out from that.

In my opinion, that is a totally pointless exercise. As Garth said, filled planes (aka "pours") are not a substitute for the inner power and ground layers of a four-layer board. About all filled planes do is add parasitic capacitance to circuits that run through them, which can lead to obscure problems.

I use filled planes only in DC and audio-frequency work, or at low-speed areas of my PCB as a means of soaking up some RFI. You do not want them anywhere near high-speed circuits.

[plasmo]

sburrow wrote:

I like your design and think it's nifty. Those look like REALLY tiny wires, but then all the easier to fit more on the board.

The wire is 30 gauge wirewrap wire which is easy to work with.

sburrow wrote:

Is that a Flash card for IDE? Might I ask, is that fairly easy to interface? My current thoughts are to use SPI interface with SD Cards, using a little adapter board. I'm more "at home" with parallel interfaces, in my mind I think they make more sense than serial [ remember I'm new ].

The disk-on-module uses the same 44-pin IDE interface as compact flash disk. The IDE interface is 16-bit parallel but can be programmed to 8-bit parallel interface. The parallel IDE interface is significantly easier to interface than SPI. There are no ROM on that prototype board, instead the CPLD (EPM7192S) can accommodate a small (64 bytes) ROM which is enough to load and run program from disk-on-module. This eliminates the need of a EPROM programmer. A development blog about that board is here.
Bill

[sburrow]

plasmo wrote:

The disk-on-module uses the same 44-pin IDE interface as compact flash disk. The IDE interface is 16-bit parallel but can be programmed to 8-bit parallel interface. The parallel IDE interface is significantly easier to interface than SPI.

Now THAT is something to think about. I looked at the link you sent, and there's some really neat stuff you've done with that!

Right now I'm considering the SPI interface for the 6522 VIA that Garth drew up on page 1 of this topic, as it technically is only using 4 pins, some of those overlapping others. But parallel interfaces are "cozy".

Thank you Bill, something I'll be thinking over.

Chad

[Michael]

Hi Chad:

May I recommend Quinn Dunki's 'Veronica 65C02 Computer' project on her 'Blondihacks' website? It was a fun, educational, and entertaining series of posts.

I also wanted to post an updated 74HC682 decoder concept drawing (below). I discovered that the '682 has internal pull-ups on the Q inputs so I had to revise my jumper scheme. Note that while the '682 is rather expensive compared to the '688, I received a handful from China for about $1.29 each (including shipping). If it works, I think the 2-chip 74HC682 decoder method might be a simple, clever, and elegant decoder solution for entry-level 65C02 SBC designs.

Take care. Have fun. Cheerful regards...

[sburrow]

Michael wrote:

May I recommend Quinn Dunki's 'Veronica 65C02 Computer' project on her 'Blondihacks' website? It was a fun, educational, and entertaining series of posts.

I saw a couple of posts on that last week, it was entertaining!

Michael wrote:

I also wanted to post an updated 74HC682 decoder concept drawing (below). I discovered that the '682 has internal pull-ups on the Q inputs so I had to revise my jumper scheme. Note that while the '682 is rather expensive compared to the '688, I received a handful from China for about $1.29 each (including shipping). If it works, I think the 2-chip 74HC682 decoder method might be a simple, clever, and elegant decoder solution for entry-level 65C02 SBC designs.

Michael, I gotta ask: How did/do you find out about these internal pull-ups? I have a datasheet for the 74HC688 and see nothing about that on there. I mean, nothing explicitly saying "these pins have internal pull-ups". Do I have a bad datasheet? Is this a common thing for 74' IC's that I have just passed over? Is there some other wording they use that I'm not familiar with? Would me adding some pull-up's *damage* something if it does or does not already have pull-ups internally?

Thank you. Just a surprise to me. Always learning!

Chad

[Michael]

Chad, the '688 doesn't have pull-ups on the Q inputs. On the other hand, the '682 datasheet does describe the internal pull-ups on its Q inputs. There's also a '684 which is the same as the '682 but without the internal pull-ups.

[sburrow]

Michael wrote:

Chad, the '688 doesn't have pull-ups on the Q inputs. The '682 datasheet describes the internal pull-ups on its Q inputs. There's also a '684 which is the same as the '682 but without the pull-ups.

Sure enough, when I pull up the '682 datasheet, it's right on the front page! Ok, so if they say they have pull-up's then they have pull-up's. If they don't say anything, they don't have anything.

Easy enough, thank you Michael. I will consider this. Right now I'm only using a 74HC688 and a 74HC00, and I have one spare NAND gate left over. So, 2 chips vs 2 chips. But I'll go back over it just to look it over more closely. Thank you again!

Chad

[sburrow]

I had a weird idea last night as I was laying in bed:

Could a Raspberry Pi / Arduino "talk" directly-ish to the 6502 using the GPIO lines?

Most schematics we have been discussing have some section of I/O. And usually not just 1 byte or something, sometimes there's some 256 byte page of I/O available, more or less depending on glue logic. You can stick at SCC2691 UART in that area, you can stick a 6522 VIA in that area, etc. So could you 'stick' a Raspberry Pi into one of those slots? Using say A0-A3 as the addressing lines, glue logic and other addresses as enable lines, and of course D0-D7 for data lines?

Here is my current memory map, it hasn't really changed for a while:

$0000 - $7FFF = RAM
$8000 - $807F = Expansion
$8080 - $808F = VIA (or UART if going that direction)
$8090 - $80FF = Unused
$8100 - $FFFF = ROM

I have the '688 finding the $8000 - $80FF zone. I then use A0-A3 as addressing lines to the VIA's RS pins. And then I just put A7 on the VIA's CS1 pin with this '688 on CS2.

The idea is then to use A4, A5, and A6 as additional 'enable' lines. This of course wastes a 'lot' of space, as you can see in my memory map. But I don't need a lot of extra glue logic chips to make it work.

If this is possible, then you could technically interface the 6502 through python, as long as the 'enable lines' are where they should be, right? I don't see the Raspberry Pi allowing for tri-state, could I just put a couple of '245s in between? Or perhaps I make all the pin's inputs until I'm ready to output something? It would probably be slow and clunky, but in theory, could that work?

Thank you everyone! Just a wild idea I'm tossing out there.

Chad

[BigEd]

You can indeed get a Raspberry Pi to act as a peripheral on the 6502 bus - but it's a massive technical challenge! The PiTubeDirect and Pi1MHz projects both do it.

The reason it's a technical challenge is that the Pi needs to respond to bus cycles within a few hundred nanoseconds. The usual operating systems aren't sufficiently fast and deterministic - and, as it turns out, the usual ARM machinery of the Pi when running carefully tuned code is only fast enough for a 1MHz bus, not for a 2MHz bus. For that, the more-deterministic GPU was needed.

Python is far too slow for this, I'm sure.

For a conventional 5V 6502 project there's also the question of level-shifting - the Pi runs at 3.3V.

With a suitable interface chip - a CPLD, perhaps, or an actual FIFO - it is possible. See the CPC-CPlink project for a (Z80-flavoured) example.