OK, I've finished a circuit for the front panel display using the display that I have, and it's got a lot of lines on the page. It looks like I'll need a PCB even if I go with seperate display drivers and individual 7-segment displays. That would eliminate a lot of the logic, and would require less ICs, so I'll design that first, and then I'll probably work off that one. That might be doable on a breadboard or few, but I may be better off just hanging a bunch of discrete LEDs on buffers.

When looking at this circuitry, I would say that tapping into the address and data bus
this way would take a lot of odd wiring, plus 6*7400 and 4*7430 or such.

Using 74151 multiplexers there probably would make the wiring look worse...

Another idea would be using something like 3*74244 feeding a 4 Bit bus
that goes to the hexadecimal to 7segment decoder of the display.

BTW: what does your hexadecimal to 7segment decoder look like ?

I don't have a multiplexer. This was just planning. I think I'll go back to my original plan of using raw binary through a DIL bar display, that'll make the wiring so much simpler.

In other news, I got the parcel from Mouser yesterday afternoon, containing a 65C02, the RAM, the EEPROM, the reset IC and the oscillator, as well as an anti-static mat.
I wired EA onto the data pins(tying both high and low), and connected a few LEDs to the 4 highest-order address lines via transistors.
I'd noticed that the end of the breadboard that the 'C02 was on was a bit flaky, as the LEDs would change when I pushed on the bottom of the board at the end with the 'C02, so I moved it to the other end of the board, rewiring the whole lot.
All was going well, until about 20 minutes ago, when something released smoke . I think it was the oscillator can, as the 'C02 is still working, now that I've corrected my wiring (again). I had the BE pin floating, instead of tied high. I'm lucky I didn't blow that up as well. I've checked the primer, and there's a clock there that's a resistor and a capacitor, so I'll use that.

The oscillator is probably cactus, but: Is there a way to test whether or not it's working, without an oscilloscope? It's a 1MHz oscillator can.

Sorry to hear about the smoke. (I think it's safe to say we've all been there. )

As for the oscillator, there are various symptoms that a defective unit might exhibit, so it's hard to do a thorough test. Using the DC voltage range on your Digital Multi-Meter you can try measuring what's on the oscillator output when the oscillator is powered up (and enabled, if it has an enable input). If the output measures as roughly 0V, or roughly 5V, then for sure the oscillator (or your measuring technique) is defective. OTOH a voltage partway between 0 and 5 is a hopeful sign, but not conclusive proof that all is well.

Some DMM's feature a frequency-measuring function which may be helpful, but not all DMM's can measure as high as 1 MHz. If you get a 1 MHz reading then the oscillator's probably OK, but if not then it may actually be the meter that's to blame.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Ok, so it turns out that I'd mixed up a transistor and the reset circuit(they're both in a TO-92 package), and I blew up the transistor.

I've now gotten a set of four lights that flash quite quickly. Although they don't always do it, for some strange reason. I'll have to get another breadboard or two to finish this, as this one's nearly full.

Sorry to hear that, but as Jeff noted, most of us have had that experience at least once. I've had a a few good bangs over the years, especially when I accidentally hooked up an electrolytic backwards in a tube amp's power supply.


This is where a logic probe would be useful (hint, hint ). However and again as Jeff noted, your DVM can give you some clue on it. It's even possible that the AC range might produce a reading of some sort.

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

I'm thinking that the better approach as far as the display goes is to simply dump the raw binary through to some LED bargraph displays. It's simpler on the wiring, and that's the hard bit on a breadboard. That said, I will probably put at least the front panel on a PCB, when I can be bothered to lay out the design in KiCAD(trace routing is a pain in the bum, as I don't know how to make the autorouter go, if it even has one).
I'll have to investigate the current-carrying properties of 74HCT vs 74HC, and see if either can carry 15-20 mA for the LEDs.

If the parts are available in 74AC you'll get around 24mA drive.

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

74HCT and 74HC differ markedly regarding the voltage levels their inputs recognize, but I think you'll find 74HCT and 74HC outputs are the same re the voltage and current available.

True. Modern LED's don't need that much, though. It should be easy to find some that are acceptably bright with, say, 5 mA or less.

BDD's suggestion about a logic probe is a good one, btw.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I was thinking there are ICs to do the 4-bit hex to 7-segment decoding for you, but I don't seem to be finding one right now.


I've laid out dozens of very dense boards for my work, and I never recommend using an autorouter unless you're on a tight schedule and the board has lots of room. Autorouters never do well compared to capable humans.


74HC or HCT is specified to be able to pull both up and down with at least 4mA and still keep valid logic levels. 4mA is plenty for these LEDs. 15-20mA with modern LEDs may be uncomfortably bright, and may not be the best for long life of bargraph-type LEDs. (Check the data sheet.) 74HC can do quite a lot more current than that if keeping valid logic levels is not important, like if they drive only the LEDs and not logic inputs too. See the applications note at http://www.fairchildsemi.com/an/AN/AN-313.pdf . 74AC can do many times as much as 74HC.

_________________
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?

It's easy to find a decoder/driver IC that'll display 0-9 on a 7-segment display, but 0-F is a different story -- such chips are unfortunately very uncommon.

A byte-wide, 32-location TTL PROM from Jameco such as 74S188 or 74S288 (aka 82S23 or 82S123) can readily do the job as long as it's a common-anode display you're using. But programming the segment patterns is a show-stopper unless you have a PROM blaster.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Something like this (not sure about availability)?

http://socrates.berkeley.edu/~phylabs/b ... DM9368.pdf

Mike B.

I was going to use a 7-segment display I have, but it's multiplexed, and that calls for a lot of wiring for this application, unless there's an IC that's designed to take two bytes and handles the rest. I could use 6 non-multiplexing 4-bit to 7-seg ICs and 6 individual displays, and that might give the lowest chip count I can get.
What I am thinking of now is three 10-segment bargraphs(with 4 of the address and 2 of the data going unused), either driven directly by buffers, or by transistors being fed by those buffers. In either case, the buffers just sit on the bus and listen. If I use transistors, I can drive the LEDs at pretty much any power level I want, but then, a 20mA LED is pretty bright, and it only needs to be readable. Using transistors will also raise the component count a fair bit.

I did find a multiplexed 4-bit to 7-seg hex IC (the ICM7228), but feeding it a nibble at a time will be the problem(Or maybe not, if I get my head around multiplexers). There's the MC14495 or the DM9368(Thanks, Barry) for non-multiplexed decoding, if I have to go there.

Thanks Mike - that led me to a CMOS equivalent, "MC14495 Hexadecimal-to-Seven Segment Driver" at
http://www.futurlec.com/Motorola/MC14495P1pr.shtml

I very much like the idea of having a module with 8 bits of input and 2 digits of output, three of which could serve as the basis of a bus monitor - but it's so very much more convenient if the decoding can be done by an off the shelf part.

(Edit - oops, I see the very next message already mentions this part!)

I could probably put that together in KiCAD... It'd be another module for the 6502.org collection, anyway. I'll have a go, although I might never finish it, knowing me.

EDIT: Ok, there's no schematic file for the MC14495, but that's no surprise. It'll just show up as a socket.