It begins! (Wren Prototype build log)

[allisonlastname]

I'm still waiting for a few more parts (namely ZIF sockets and oscillators) but I have chips on the board and wires going between them. I'll probably add another breadboard for the power supply and clock, but I'm waiting for parts to arrive so I can move my flash programmer (just barely visible in the top of the frame) to some stripboard, which will free up a breadboard.

The power/ground network seems good but I don't have any experience with this so I could be doing it wrong (power and ground are red and black wires respectively, but blue where they're being used to pull a pin in a particular direction). The address bus is yellow, control lines (both those to/from chips and intermediate logic lines) are blue, and the data bus will be green when I start wiring it up.

The flash chip will be in a ZIF socket in the "final" build, but as I mentioned earlier that hasn't arrived yet.

If you have any questions or pointers please let me know.

[No True Scotsman]

I'll also be using a couple of SST39SF010s in my '816 system.

If a crystal oscillator is holding up your project, Garth was telling me just yesterday about a VCO clock circuit he uses in prototyping. It consists of a 74HC14, trim pot, and a few capacitors. Looks like an easy build if you're in a hurry.

[Paganini]

Looks like you're off to a good start!

I would suggest doing *all* the power connections before doing any of the bus wiring. Especially with the "flying wires" method, all the aerial wires will make it cumbersome to aim your smaller jumper wires later on.

ZIF sockets don't typically play well with breadboards, but (depending on what type of socket it is) you might be able to mount it in a machine pin socket as a kind of "socket carrier." This works really well with the nice (but expensive!) Aries sockets, but less well with the more common 3M type ones (those big blue/green ones).

[No True Scotsman]

Paganini wrote:

ZIF sockets don't typically play well with breadboards....

Yep. The pins on the seasick green ones are way too short.

[drogon]

The wiring starts to get hairy after a while - so quietly forget the 6522 - unless it's a vital part of your bootstrap...

My Ruby system on day 1:

I bought some "jumper jerky" from Pimoroni (I think) for some of the bus connections, but it actually proved to be harder to use and one end or the other of an 8-bit bus would pop-out, but that board did work and it produced video too (although that was done by the ATmega separate to the 65C02).

Hard to see what's there but top-right is the ATmega with 16Mhz can oscillator, middle is 32KB of RAM (reflected over both 32KB regions) Left is the 65C02 and the GAL under it. (doing the write qualify and other stuff to handle 2 x 32KB RAM chips)

On day 2, I moved to stripboard which made it far more robust and worked solidly up to 16Mhz. I mounted 2 x 32KB RAM chips one on-top of the other but brought out the /CS pin on the top one to a separate output on the GAL. Output was a simple 8-bit latch and single bit input - I didn't use the 65C22 until the PCB version.

I was in-circuit programming the ATmega (which holds the 6502 boot code) so didn't bother with ZIF sockets, but I think I might not bother with one for a breadboard - put in some link pins to make it trivial to locate it when you put it back in again... I experimented with a few different schemes for the GAL which is why it's at the bottom of the board to make it easy out/in.

Wren... Small bird - loud noise!

Hope it goes well..

-Gordon

[allisonlastname]

No True Scotsman wrote:

It consists of a 74HC14, trim pot, and a few capacitors.

The issue there is I don't have any 74HC14s. My spares bin consists of some 74HC00s and some 555s (which might work but I'd rather just wait for the can to arrive).

Paganini wrote:

I would suggest doing *all* the power connections before doing any of the bus wiring. Especially with the "flying wires" method, all the aerial wires will make it cumbersome to aim your smaller jumper wires later on.

I got the rest of them in fine. Good eyes and young fingers probably help :)

Quote:

ZIF sockets don't typically play well with breadboards, but (depending on what type of socket it is) you might be able to mount it in a machine pin socket as a kind of "socket carrier." This works really well with the nice (but expensive!) Aries sockets, but less well with the more common 3M type ones (those big blue/green ones).

I got 2 of the Aries ones, and the datasheet says the pins are 2.67mm. I checked with some 22AWG wire with ~3mm of conductor exposed, and that stayed in the breadboard well enough to pick it up, so hopefully it works nicely.

drogon wrote:

Wren... Small bird - loud noise!

I name a lot of projects after birds, not least because there's a lot of birds. I find it hard to work on something unless it has a name in my head, so picking a random bird works pretty well.

[gfoot]

Great start! I'd say the power and ground is enough. For my recent breadboard prototype I didn't wire the power in a grid, only the ground, and I did that by connecting from IC's ground pins to the opposite rail, rather than having separate wires. The rationale was that the ground pins of the ICs are speecifically what I want electrons to be able to get to/from easily for ground returns with minimal trips through connection points.

Rather than using ZIF sockets, I make little straps out of paper and selotape and put one around each ROM IC, so that I can more easily pull them out:

Home-made chip puller

My wife is very good at sewing, and I originally asked her to make these things for me out of ribbon, but she laughed and told me to just use paper instead, so here we are!

It sounds silly but I find this method works very well, and I've never damaged an EEPROM pin despite what must be hundreds or thousands of removals and insertions. It should be fairly obvious how to make it, but I made a how-to video here: https://youtu.be/TGueNvmNNCM

[No True Scotsman]

If I were gonna use a ZIF socket, the EEPROM is definitely where I'd use it after watching Ben Eater pull and re-insert one dozens of times.

[allisonlastname]

gfoot wrote:

Rather than using ZIF sockets, I make little straps out of paper and selotape and put one around each ROM IC, so that I can more easily pull them out:

Oh that's very clever, thanks.

[No True Scotsman]

No True Scotsman wrote:

Garth was telling me just yesterday about a VCO clock circuit he uses in prototyping.

I've just been reminded that this is properly called a VFO (variable frequency oscillator), not a VCO (voltage-controlled oscillator). Apologies for the mistake.

[allisonlastname]

What is it with ICs having all 8 data pins (mostly) contiguous, and then the lower order address pins contiguous, and then the high order address pins all over the place? The 6502 doesn't do it but the 39SF010 and the 62256 both do.

[No True Scotsman]

allisonlastname wrote:

What is it with ICs having all 8 data pins (mostly) contiguous, and then the lower order address pins contiguous, and then the high order address pins all over the place? The 6502 doesn't do it but the 39SF010 and the 62256 both do.

Someone attempted to explain the rationale behind that to me once, but either I didn't get it or they didn't explain it well. If I remember correctly, it makes the circuit board layout easier under some circumstances. Those circumstances must involve mutli-layer boards because they sure as heck don't apply to single-sided boards.

[drogon]

allisonlastname wrote:

What is it with ICs having all 8 data pins (mostly) contiguous, and then the lower order address pins contiguous, and then the high order address pins all over the place? The 6502 doesn't do it but the 39SF010 and the 62256 both do.

Remember that you don't need to connect D0 on the 6502 to D0 on the RAM chip - you can connect them in any order. It only matters if you have some other device that also needs to read/write the RAM, then you may have to unscramble the wires to that device, or (what I do in my Ruby board) arrange the other device to un-scramble in software). You do need to connect peripherals up in the right order though - so for your 6522, then D0 <-> D0, D1 <-> D1 and so on.

And if you connect the EEPROM up in a scrambled manner, you'll need to scramble the bits as it's written...

-Gordon

[John West]

allisonlastname wrote:

What is it with ICs having all 8 data pins (mostly) contiguous, and then the lower order address pins contiguous, and then the high order address pins all over the place? The 6502 doesn't do it but the 39SF010 and the 62256 both do.

It makes some sense when you look at the history of the pinouts. Start with a 1K x 8 chip like the 2708: this comes in a 24 pin package, with the data pins nicely in order around the bottom, and the address pins nicely in order around the top:

Code: Select all

A7    VCC
A6    A8
A5    A9
A4    VEE
A3    /CE
A2    VDD
A1    PGM
A0    D7
D0    D6
D1    D5
D2    D4
GND   D3

Then you move on to the 2K x 8 2716. This needs one more address pin, but no longer needs the -5V supply. So A10 takes the place of VDD. (It also only needs high voltage during programming, so VEE becomes VPP)

Now it's the 4K x 8 2732. We need another address pin, so there's a bit more shuffling among the other pins to make room for A11 where VPP used to be. The pinout now looks like this:

Code: Select all

A7    VCC
A6    A8
A5    A9
A4    A11
A3    /OE / VPP
A2    A10
A1    /CE
A0    D7
D0    D6
D1    D5
D2    D4
GND   D3

Density increases, we get more capacity, but we've run out of pins. So we add some more at the top and the 2764 pinout looks like this:

Code: Select all

VPP   VCC
A12   /PGM
A7    NC
A6    A8
A5    A9
A4    A11
A3    /OE
A2    A10
A1    /CE
A0    D7
D0    D6
D1    D5
D2    D4
GND   D3

There's lots more room, so the doubled up /OE and VPP have moved to different pins, /PGM is back, and there's even an unused pin. Guess what happens with the 27128? That's right, that unused pin becomes A13.

Next comes the 27256, and we've run out of pins again. PGM goes, and A14 takes its place. For the 27512, VPP moves back to sharing with /OE, and A15 takes over pin 1.

It's a pattern that we see all too often in computing. The final design makes no sense in itself, but only as the end-product of a series of short-term decisions. With each chip, the new functions are squeezed in wherever they will fit, with no concern for what's going to happen on the next one.

[No True Scotsman]

John West wrote:

With each chip, the new functions are squeezed in wherever they will fit, with no concern for what's going to happen on the next one.

In other words, they were making it up as they went along?