• Please review our updated Terms and Rules here

PC-Retro Design Files ( IBM 5150 Clone )

Zoomed in:

1764263405067.png

I need to optimize the SVG a bit, tie in some CSS classes, labels, alt-text for accessibility, and all that, but eventually I will release the SVG for anyone to use. I presume that's okay with you? It's not like someone can take this back to gerber form.
 
Here's an example of one of the educational diagrams we can create by isolating some of the traces of interest.

This visualizes the address lines coming from the 8088 and going to the address latches, and the ALE signal from the 8288 that triggers the latching

address_latching_01.png
 
@mmruzek Actually stumbled on your kits the other day and thought how cool it would be to peek at the design files, then subsequently stumbled across this thread. What luck! Thanks for sharing these with us 😍
 
Just stumbled across this thread, quite surprised to see activity this recent! I'm slowly building up the parts to take on building one of these, but struggling to find sources for Capacitors 5, 8, and 9 (the axial ones). I'm not sure what material they're made of and I'm unfortunately not quite yet familiar enough with electronics to know what would be a suitable replacement; can anybody point me in the right direction? Thanks!
 
Just stumbled across this thread, quite surprised to see activity this recent! I'm slowly building up the parts to take on building one of these, but struggling to find sources for Capacitors 5, 8, and 9 (the axial ones). I'm not sure what material they're made of and I'm unfortunately not quite yet familiar enough with electronics to know what would be a suitable replacement; can anybody point me in the right direction? Thanks!

Whatever they were made of you probably don't want that.

For a modern replacement, i'd suggest a metallized polypropylene film capacitor.

For C5 & C9 this should do
and for C8

You can search for "0.047 uF Axial Film Capacitors" or "0.01 uF Axial Film Capacitors" if you'd like to look at other options. They also come in yellow! Just make sure they're at least 50VDC but just about every modern one there will greatly exceed that rating.
 
Whatever they were made of you probably don't want that.

For a modern replacement, i'd suggest a metallized polypropylene film capacitor.

For C5 & C9 this should do
and for C8

You can search for "0.047 uF Axial Film Capacitors" or "0.01 uF Axial Film Capacitors" if you'd like to look at other options. They also come in yellow! Just make sure they're at least 50VDC but just about every modern one there will greatly exceed that rating.
Super helpful, thank you!
 
For a modern replacement, i'd suggest a metallized polypropylene film capacitor.
You can search for "0.047 uF Axial Film Capacitors" or "0.01 uF Axial Film Capacitors" if you'd like to look at other options. They also come in yellow! Just make sure they're at least 50VDC but just about every modern one there will greatly exceed that rating.

Super helpful, thank you!

Are there any people out there interested in going through the entire parts list to determine what's still available and what replacements are available for what's no longer able to be found?

This would help bring this project back alive.
 
Are there any people out there interested in going through the entire parts list to determine what's still available and what replacements are available for what's no longer able to be found?

This would help bring this project back alive.
You can find everything, as long as you are willing to do some dumpster diving on ebay or aliexpress.

The two parts that will cause the most trouble are probably the TD1 delay line and the BIOS ROM. For TD1, this board uses a DIP8 part instead of a DIP14 part like the original IBM board. The DIP14 part is somewhat cheaper and easier to find. It's probably worth the effort to modify the board layout to support both footprints. Modifying the board to use a small microcontroller in lieu of a delay line might also make sense - something like a PIC16F145x could possibly work. There is a PROM that fits the 5150 board, the MCM68766. You will need to find someone to program it, or build a programmer to do it yourself (there is an open source Arduino shield). Alternatively, modify the ROM footprints to use the 27 series PROMs, or use an adapter to do so.

Some of the peripheral chips (8255, 8259, 8237, 8253) can still be bought new off Digikey or Mouser, but they are stupidly expensive; use ebay for these. The 8088, 8288 and 8284 are also best found on ebay. If you absolutely have to be sure you aren't buying garbage, all of these parts can be found on Quest Components(when searching on their website, you must enter the part number exactly, D8255, P82C55, etc.).

If you are using composite CGA, the trim capacitor can be difficult to find, but you can otherwise use a fixed 22pF cap.
 
Thanks for posting your work with this 5150 board. Between myself and Claude I've been writing a PC emulator which emulates the actual traces ICs and even passives fully in software.
 
Thanks to your BRD and svg I've been able to construct an entire, real time emulator (simulator?) with the traces and all the circuits emulated exactly as they are on a real motherboard. It does boot to DOS but I've been a little distracted by the visualization of the actual live, realtime board traces. On my 285K it does acheive realtime performance, emulating at right at 4.77Mhz. Will post the source soon!

This isn't just PCem or DOSBox, I'm emulating the CPU, yes, but also every IC on the board: the 8288 bus controller, the 74S373 address latches, the 74S138 decoders, the 8237A DMA controller, the 8259A PIC, the 8253 PIT, the DRAM mux chain, all of it.

Thanks again!

1774434763896.png
 
That's pretty insane. The idea occurred to me, but I never would have thought it would run at realtime speed.
How did you map the net list to the SVG? They have no direct relation, the traces aren't even contiguous...
I can actually see that a lot of trace segments are missing probably for that reason. I was only really concerned with the visual appearance, so it didn't bother me that the traces were not connected. I converted directly from the Gerber files. If it helps, perhaps an export directly from KiCad would be better connected.
 
Last edited:
How did you map the net list to the SVG?
In the above image I didn't. I exported to the top layer of the svg "Sockets + Chips + Expansion-Slots + Misc-Components + Functional-Labels + Silkscreen" which left a transparent layer below to the traces, sourced from the BRD. The traces themselves are composited as an SDF rendering which is sourced from the active state of the pins.

I have to apologize, I'm a software engineer by trade so a lot of the standard EE terminology escapes me. :-P

The actual traces you're seeing in the above image are sourced from the BRD, which is also what is used to execute the damn thing.

I was able to get it going as fast as I have due to making everything single threaded and producing a directed acyclic graph for that specific cycle of operation. It's in C++ and optimizing execution amounted to expressing the logic components as tersely or as obvious-to-the-compiler what could be optimized out. A similar approach was taken for a gate-level emulation of the GameBoy, though I only just found about this last night.


The colors do mean something, with HiZ greying out the interconnects. Below is an image before emulation has started. One can of course step by cycle and by instruction.

1774457956777.png
 
Thanks, that picture paints a clearer picture. So my SVG is just a pretty layer on top of the actual simulation. You'd still need to map pads to chip pins somehow right?
Are you modelling propagation delays through the 74 series logic? When I put together a digital logic simulation of the 5150's DMA and ready state circuitry, there was quite a bit of fiddly bits getting it to work properly. Without modelling the delay line you can have momentary states where multiple bus drivers are active.

I'm familiar with the various gate-level chip emulators, but they typically run at more seconds-per-frame than frames-per-second.

Do you have a logic analyzer-style view where you can select specific pins or traces to sample?
 
I should just post the source. :-) Most (> 95%?) has been AI powered. I'm one of the ol' DOSBox and Munt devs so I'm very familiar with emulation. The AI converted your traces to an SDF with a single prompt but right now it's struggling with wiring up the keyboard. Half of it is because I'm ready to just skip circuitry and just get the keyboard going already. Half of it is because the dipswitches alias with the keyboard which is just funny.

For the TD1 I just made it internal to the 74s00, e.g.

C++:
#include "ic/ic_74s00_u81.h"
#include <spdlog/spdlog.h>

namespace bench {

IC_74S00_U81::IC_74S00_U81() : CallbackComponent("74S00") { set_description("Quad 2-In NAND"); }

void IC_74S00_U81::install(Socket& socket) {
    auto connect_pin = [&](int p) -> Pin {
        Signal* s = socket.pin_signal(p);
        if (s) s->connect(this);
        return s ? s->pin() : Pin{};
    };
    auto pin = [&](int p) -> Pin {
        Signal* s = socket.pin_signal(p);
        return s ? s->pin() : Pin{};
    };

    // Gate 1: pins 1,2 -> 3
    gates_[0].a = connect_pin(1);
    gates_[0].b = connect_pin(2);   // RAS (input)
    gates_[0].y = pin(3);

    // Gate 2: pins 4,5 -> 6
    gates_[1].a = connect_pin(4);
    gates_[1].b = connect_pin(5);
    gates_[1].y = pin(6);           // RAS (output)

    // Gate 3: pins 9,10 -> 8   (~CAS output)
    // Physical pin inputs ignored -- gate 3 uses virtual TD1 (delayed RAS).
    gates_[2].a = connect_pin(9);
    gates_[2].b = connect_pin(10);
    gates_[2].y = pin(8);

    // Gate 4: pins 12,13 -> 11
    gates_[3].a = connect_pin(12);
    gates_[3].b = connect_pin(13);
    gates_[3].y = pin(11);

    // VCC
    Signal* vcc = socket.pin_signal(14);
    if (vcc) vcc->connect(this);

    // Pin directions
    for (auto& g : gates_) {
        declare_input(g.a);
        declare_input(g.b);
        declare_output(g.y);
    }
}

void IC_74S00_U81::connect_addr_sel(Signal& addr_sel) {
    addr_sel_pin_ = addr_sel.pin();
    declare_output(addr_sel_pin_);
}

void IC_74S00_U81::on_power_on() {
    td1_pending_ = Level::HiZ;
    if (addr_sel_pin_.idx != 0) addr_sel_pin_.drive(Level::HiZ);
    for (auto& g : gates_) {
        bool both = g.a.level() == Level::High && g.b.level() == Level::High;
        g.y.drive(both ? Level::Low : Level::High);
    }
}

void IC_74S00_U81::on_power_off() {
    td1_pending_ = Level::HiZ;
    if (addr_sel_pin_.idx != 0) addr_sel_pin_.release();
    for (auto& g : gates_)
        g.y.release();
}

void IC_74S00_U81::on_cycle(Fiber /*caller*/) {
    // Gate 2 first (drives RAS)
    {
        auto& g = gates_[1];
        Level a = g.a.level(), b = g.b.level();
        bool both = a == Level::High && b == Level::High;
        Level y = both ? Level::Low : Level::High;
        g.y.drive(y);
    }

    // Gate 3: virtual TD1 -- use delayed RAS, not pin inputs.
    // Skip the update when gate 2 inputs are HiZ -- that indicates a
    // spurious re-evaluation from a bidir release-and-re-drive glitch,
    // not a real memory command.  Advancing td1_pending_ in that case
    // would collapse the row/column split into a single eval.
    {
        Level ras_now = gates_[1].y.level();
        Level g2a = gates_[1].a.level();
        Level g2b = gates_[1].b.level();
        if (g2a != Level::HiZ && g2b != Level::HiZ) {
            if (addr_sel_pin_.idx != 0)
                addr_sel_pin_.drive(td1_pending_);
            Level out = (td1_pending_ == Level::High) ? Level::Low : Level::High;
            gates_[2].y.drive(out);
            td1_pending_ = ras_now;
        }
    }

    // Gates 1 and 4
    for (int i : {0, 3}) {
        auto& g = gates_[i];
        bool both = g.a.level() == Level::High && g.b.level() == Level::High;
        g.y.drive(both ? Level::Low : Level::High);
    }
}

} // namespace bench

I decided to go with a full cycle implementation so propogation delays are a quantum not measurable by my simulation. The TD1 is ~ 100ns and each cycle is roughly 200ns. So internal to the circuit it goes. This is the only exception I made in this regard for the simulation.
 
Right, well, that's admittedly a bit of a disappointment. Apologies; I will make no further comment on the matter.
It shouldn't be a disappointment. I've written emultors before by hand (again, see DOSBox and Munt, among others.) The AI here just happens to be able to type 100 times faster than I can. The DAG, the optimization to getting it running at native 4.77 Mhz speed, is all human. The slog (type this boilerplate here for the nth time) is delegated to AI. Waving aside the actual hype train for a moment, it's a tool. I wrote in two weeks what before would have taken months or more.
 
Back
Top