False Starts, Change of direction?

A project log for Uno 14500

An MC14500B based single board computer with an old-school front panel for interactive programming

jnp-3rJNP-3R 02/18/2024 at 01:352 Comments

I've been busy working on the PCB and routing on the computer, but while I'm getting much quicker and better at it, I've ran myself into a corner.

As far as I got on the PCB before realizing things were a bit to tight
We're gonna need a bigger board...

This project is one of odd anachronistic design choices, pulling in design for aesthetics here, cost there, speed of construction in another place. The design so far is a single board computer with onboard front panel, simply because that seemed the most expedient and reminiscent of old kits and educational machines like the KIM-1, MicroProfessor, ELF, Superboard, and so on. I love the vintage look with simple boards and wide curved traces, and I really want the front panel to be organized and clear. That said I also want the board as small as possible to reduce cost. There's no sense paying $100 for bare boards, and I don't want the machine to become too large and unwieldy to use on a small desk.

This contrast has unfortunately not been working out well. Positioning the front panel on the main board, keeping output LEDs near their related input switches, and keeping the I/O connectors out of the way on the back of the board means a large number of signals have to traverse the whole length of the board, often twice, while also navigating tight areas between the processor section, LED drivers, and clock logic.

Is it possible to route the board? Yes, definitely, but it means giving up on trace spacing, and conceding to building a tight rat's nest. If aesthetics were the only concern we may be okay with that, but... Well, our nostalgia is for educational and exploratory systems, systems that are designed to be easy to follow along with and understand, and a tight mess severely limits that ability. We'd like to be able to show this thing off and maybe help teach something, you know?

So where do we go from here? Well, the board could be made larger, but I'm neither interested nor willing to risk finances on having to re-order something like that. That leaves us with a card bus / backplane system. I'd initially rejected this idea due to the cost and complexity of connectors and a chassis, but if we can use smaller boards we can take advantage of special pricing, and there's less wasted in case of a screw up or reorder. Plus, modularization makes further development easier and means we can get more out of what we've spent on the backplane and chassis.

My next step is going to be doing some research and measurement to see what kind of connectors or backplanes are available cheaply and seeing what it'll take to split the design up. Something with 60+ connectors and a small size would be ideal and allow for a straight through backplane, but we may need a smaller pin count to accommodate fan out on a fine pitch board. Currently PCIe x4 is near the top of the list due to its low price, small size, and availability, but we'd like to not have to "cheat" to route it. Let me know if you have any other suggestions.

Edit: Wait a second, the biggest trouble I'm having is coming from trying to accommodate the front panel and its wiring on one board while hiding or moving components from line of sight. Simply letting the chassis host the front panel would save a huge amount of space. A short bit of ribbon cable and freedom to place connectors wherever's convenient would help tremendously (though boards may still need stacked / modularized). To the enclosure catalogs!


Nicola Cimmino wrote 02/26/2024 at 18:18 point


You don't need to buffer each line before sending it to the LEDs. LEDs are rather efficient nowadays, have a try with 890 ohm (or dare even 1K) with the particular LEDs you are using and 5V on a breadboard. They should be plenty bright and, at < 5mA, will be fine to be driven by the logic ICs directly. That should reduce ICs count drastically and ease your routing problems.

Another, MC14500 specific thing, having RR mapped back to an input you can read is incredibly beneficial. There are many operations you can do that way, such as a NOT. Most importantly, you can force a 1 into RR by doing "ORC RR", which is useful at start to then enable unconditionally IEN/OEN.

Feel free to have a look at my if you are looking for inspiration.

  Are you sure? yes | no

JNP-3R wrote 02/26/2024 at 19:53 point

Oh hey! Thanks for taking a look! Your project is indeed one of the inspirations, though I admit I should probably take a deeper look at the schematics.

Thanks for the tip on the LEDs, that'll greatly simplify things and I'd honestly just copied over that feature from old schematics (when dim red was all you could get)

There also is a plan to support looping RR back to either scratch register 7 or input 0 (configurable by jumpers here, DIP switches in the next revision). That way the I/O map can be compatible with software for the PLC-14500 or the Minimal MC14500 system in the Handbook.

  Are you sure? yes | no