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.



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.



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

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:



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

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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

Chad

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

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


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

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

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...

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



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

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.

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

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

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.