Dave Plummer RAM Project Uses AI to Replace Scarce PDP-11 Memory

Dave Plummer built a custom 4MB memory card for his vintage computer with ChatGPT’s help, then reported fixing faults and booting Unix. The Dave Plummer RAM project targets an expensive restoration problem: replacing scarce memory for a PDP-11, Digital Equipment Corporation’s historic minicomputer family. It also puts AI-generated engineering advice through a useful test, connecting the resulting hardware to a real machine.

The former Microsoft engineer used EasyEDA, an electronic circuit design application, to develop the board. His approach combines existing memory chips with programmable control logic. “From scratch” describes the custom board and its behavior, rather than manufacturing new memory chips.

The central tension runs between generating a plausible design and satisfying an older computer’s exact interface requirements. Established alternatives such as QBone already help keep these machines running. Plummer’s project explores a dedicated replacement, with AI assisting development and physical testing determining whether the design works.

The Dave Plummer RAM Project Reached a Real Computer

Plummer moved beyond a circuit drawing to a physical memory card connected to vintage hardware.

Tom’s Hardware describes a board built around a Lattice MachXO2 programmable chip connected to four ISSI memory chips. Plummer tested the card alongside an M8190 processor board through Q-Bus, the shared electrical interface connecting compatible computer components. These details establish the project as a custom memory board, with both physical connections and control behavior to get right.

That distinction matters because memory serves a more demanding role than simply appearing in a machine’s configuration. The processor must retrieve the same information it previously stored. It must do so at the intended location, without damaging nearby information or answering requests intended for another component.

A board can pass an initial recognition check while still mishandling specific operations. Recognition establishes that some communication works. It leaves open whether every supported access behaves correctly across the intended memory range.

The project’s early faults therefore belong in the main story. They show the distance between getting a manufactured board to respond and making it dependable enough for software. That distance is where much of the engineering work lives.

The AI contribution also needs precise boundaries. ChatGPT participated in development, while EasyEDA supplied the circuit design environment. The available account does not provide a complete record assigning every design choice, correction, or verification step to either Plummer or the assistant.

Calling the result AI-assisted hardware design captures what the evidence supports. Calling it an independently designed AI computer component would require a much clearer account of who made the decisions. The distinction becomes especially important when debugging changes the original design.

“Making RAM” also has several possible meanings. RAM, or random-access memory, holds information that a processor can read and change while running. Designing a compatible board around purchased chips is a substantial undertaking, but it remains separate from semiconductor fabrication.

For restoration work, the board is the relevant unit. A memory chip alone cannot replace a missing expansion card. It needs suitable connections, control logic, and behavior that the original processor understands.

Plummer’s effort addresses that integration problem. Its significance comes from making contemporary components useful inside an older system. The amount of memory matters within that system’s limits, rather than as a comparison with current personal computers.

That makes the project easier to assess on its own terms. The question is whether the card provides dependable storage to its intended host. A successful answer would represent a practical restoration achievement without requiring claims about changing the wider memory industry.

Scarce Replacement Cards Put Restorers Under Pressure

The immediate pressure falls on people maintaining old computers, whose useful replacement options depend on compatibility and availability.

Plummer identified the expense and scarcity of vintage memory as his motivation. That creates a familiar restoration choice: locate an original component, adapt a modern substitute, or build a replacement. Each route imposes a different burden on the person keeping the machine alive.

An original card preserves more of the historical configuration. Its condition and availability still need assessment. A replacement trades some historical authenticity for the possibility of using components and manufacturing methods available today.

Neither choice removes the need for technical judgment. An old board needs inspection and testing. A newly designed board needs evidence that it behaves correctly in the intended machine.

The relevant comparison therefore extends beyond the acquisition of hardware. Restorers also spend time diagnosing faults, checking documentation, assembling systems, and maintaining whatever solution they choose. Those efforts remain real even when the builder treats the project as a hobby.

A custom replacement becomes more useful when another person can reproduce it without repeating the original investigation. That requires understandable design files, component information, assembly guidance, and a clear account of supported configurations. A working prototype begins that process rather than completing it.

Plummer’s interest in these systems predates the current board. In his PDP-11 restoration discussion with Lex Fridman, he described assembling machines from acquired parts and pursuing a highly equipped configuration. That background places the memory project within an existing restoration practice.

It also limits what readers should infer about accessibility. An experienced programmer can bring disciplined troubleshooting habits to unfamiliar electronics work. Familiarity with the host machine supplies additional context that a new hobbyist would still need to develop.

AI assistance is relevant because it offers another way to investigate unfamiliar details. A builder can ask questions, explore candidate approaches, and request explanations while developing the design. Whether that reduces total work depends on the quality of the answers and the effort needed to check them.

There is no controlled comparison here showing the same project completed with and without ChatGPT. Claims about measured productivity gains would therefore outrun the evidence. The observed result is a development effort that used AI and progressed to working-hardware claims.

For the restoration community, the more interesting possibility is a maintainable replacement design. If the work becomes reproducible, other owners gain an additional option. If it remains specific to the builder’s setup, its value stays closer to an individual experiment.

That difference determines who benefits. A successful personal build serves its owner immediately. A documented, independently reproduced board can serve people who lack the time or equipment to develop one themselves.

Programmable Logic Has to Speak the Original Bus Language

The difficult boundary is translating memory requests correctly, even when the underlying storage chips work exactly as intended.

An FPGA, or field-programmable gate array, is a chip whose digital logic can be configured after manufacturing. In this board, that logic acts as a memory controller, coordinating requests between the host computer and storage chips. The controller must preserve the host’s expectations at every supported operation.

Lattice describes its programmable logic family as suitable for bridging and system control. That makes the component’s role understandable: it connects interfaces whose details do not automatically match. Its capabilities alone say nothing about whether a particular configuration implements those details correctly.

The important distinction is between storage capacity and interface correctness. A card can contain enough physical memory while mapping requests to the wrong locations. It can also return correct values for some operations and mishandle others.

DEC’s Q-Bus transfer specifications distinguish word and byte transfers. A word is the processor’s grouped data unit; in this context, it contains two bytes. Correctly supporting those transfer types requires attention to how addresses and data relate.

A byte operation selects only part of a word. The controller must preserve information outside the requested portion when the operation requires that behavior. Otherwise, changing a small value can unintentionally alter neighboring data.

That is a general explanation of the interface requirement, rather than a confirmed diagnosis of Plummer’s exact implementation. An observed addressing fault can suggest where to investigate. Establishing its cause requires examining the actual logic and the signals produced during the failing operation.

This is where AI-generated explanations need careful handling. An answer can describe a broadly correct architectural principle while applying it incorrectly to a specific design. Terminology that sounds convincing does not establish that the right wires, addresses, and control conditions match.

The same issue appears when moving between abstraction levels. A schematic shows connections. Controller logic describes behavior. A physical test reveals what the assembled system actually does when those connections and behaviors interact.

Agreement at one level does not guarantee agreement at another. A design environment can help organize a project without certifying compatibility with every host operation. The original machine remains an essential participant in validation.

Programmable control logic gives the builder a useful correction path. When an error belongs to that logic, revising the configuration can change behavior without replacing the entire board. That flexibility depends on the physical design already supporting the required behavior.

A wiring error or unsuitable electrical interface presents a different problem. Code cannot repair every physical limitation. Responsible reporting therefore avoids describing any unexplained hardware fault as an easy software fix.

The strongest lesson from AI-assisted hardware design is about evidence at interfaces. Generated code and explanations are candidates for implementation. Their reliability becomes clearer when specific inputs produce the required outputs on the actual system.

For this project, the old bus protocol provides that external standard. It does not adapt to an assistant’s assumptions. The replacement must meet the machine’s established behavior closely enough for ordinary software to rely on it.

QBone Gives the Custom Board an Existing Alternative

A dedicated memory card enters a restoration community that already has modern ways to replace missing functions.

Jörg Hoppe’s QBone device emulation project connects Q-Bus machines with a modern Linux environment through a BeagleBone Black computer. Its documented capabilities include emulating failed subsystems and monitoring simulated memory. It provides a concrete reference for evaluating what a new replacement adds.

The approaches serve overlapping needs through different designs. A dedicated memory board concentrates on supplying memory through its own controller and storage. QBone provides a broader environment for representing devices and supporting diagnostic work.

That broader scope matters during restoration. A machine with several missing or failing components needs more than a memory replacement. A configurable platform can help investigate the system while providing functions that would otherwise require additional original hardware.

A specialized card has a different appeal. Its purpose can remain narrower, with fewer features for an owner to configure and maintain. Whether that produces a simpler overall experience depends on the finished implementation and documentation.

There is no verified performance comparison establishing that Plummer’s card is faster, more reliable, or easier to use than QBone. The available evidence supports describing alternative routes. Ranking them would require comparable tests under stated conditions.

The existence of an alternative also changes how to understand the project’s motivation. Building a new card need not mean every existing approach is inadequate. Learning, control over the design, and the satisfaction of constructing hardware can each justify the effort.

For an owner focused on restoring service, the decision starts with the machine’s needs. A narrowly scoped replacement is attractive when memory is the missing function. A broader emulation environment becomes relevant when several subsystems need attention.

Historical fidelity adds another dimension. Some restorers prioritize original components and their behavior. Others accept modern hardware that lets the original processor continue running useful software. Those goals lead to different choices without requiring either group to be wrong.

The custom PDP-11 memory board therefore belongs in a set of restoration options. It does not need to displace every alternative to be useful. A clear account of its intended role would help owners decide where it fits.

Support and longevity also deserve consideration. A board’s usefulness depends partly on whether future owners can obtain components, understand configuration choices, and diagnose failures. Those questions become more significant once the original builder steps away.

For Plummer, developing a dedicated replacement can produce direct knowledge of how his machine handles memory. For other owners, that knowledge becomes valuable through documentation and reproducibility. The engineering artifact and the explanation of it work together.

The comparison with QBone keeps the analysis grounded. The pressure is to deliver another credible restoration option. Claims about replacing mainstream memory products or competing with modern computers have no support in this project’s purpose.

Plummer Reports a Fix, but the Test Details Matter

The latest indexed posts describe progress beyond the initial fault, while leaving the validation dependent on the builder’s account.

An indexed mirror of Plummer’s RAM project updates records an initial addressing failure, an intermediate correction, and a later success claim. An October 30 entry says he changed the FPGA code, passed tests, and booted Unix into multi-user operation. The original posts were not directly accessible during verification, so this account relies on the indexed mirror.

That qualification matters because reporting should preserve both the update and its evidentiary limits. Leaving the project permanently described as broken would omit available information. Treating the later claim as independent certification would go beyond what the available material establishes.

Booting an operating system is a meaningful integration check. It exercises components together under software that expects the machine to behave consistently. It remains different from a published test record explaining which memory operations and locations were checked.

A detailed validation account would identify the hardware revision and controller configuration. It would also distinguish targeted diagnostics from ordinary software use. That would make it easier to understand what passed and what remains outside the tested conditions.

The wording of a test claim deserves similar care. Passing every test in a particular suite establishes something about that suite and configuration. Without the suite’s scope, readers cannot infer coverage of every supported operating condition.

This does not make the reported success unimportant. It sets the appropriate level of confidence. The evidence supports a builder reporting a functioning system after debugging, with broader compatibility and reproducibility still open.

The role of ChatGPT remains another unanswered question. The published account does not isolate whether an assistant introduced a faulty assumption, helped correct it, or contributed mainly elsewhere. Assigning responsibility would require the design history and relevant exchanges.

That uncertainty cuts both ways. The initial failure does not establish that AI caused the defect. The later success does not establish that AI independently solved it.

Engineering work often progresses through faulty assumptions, measurements, and corrections. AI changes how some candidate explanations and implementations arrive. It does not remove the need to determine which explanation matches the observed failure.

The Dave Plummer RAM project is therefore stronger evidence of an assisted development process than a benchmark of AI engineering ability. It shows an experienced builder pursuing unfamiliar work with an assistant available. It does not quantify how much expertise or effort the assistant replaced.

For developers and technical knowledge workers, that distinction has practical relevance. Generated material becomes more trustworthy when linked to specifications, revisions, and observations. Keeping that record makes it possible to revisit a decision after a test exposes a mistaken assumption.

A searchable engineering knowledge base supports that documentation task. In a hardware project, the useful record includes what was expected, what happened, and which revision changed the result.

Watch for Reproducibility, Broader Tests, and Sustained Use

The next evidence should show whether a successful personal build can become a dependable option for other PDP-11 owners.

The first signal is a reproducible release. That means enough information for another builder to identify the intended components, manufacture or assemble the board, and load the matching controller configuration. Such a release would move the project beyond a result demonstrated on its creator’s bench.

Revision matching would be particularly useful. Hardware files and controller code need a clear relationship so another builder knows which combination produced the reported result. An incomplete or ambiguous release would leave reproduction dependent on additional interpretation.

Independent assembly would strengthen the case further. Another owner reaching the same result would test whether the instructions capture assumptions that the original builder takes for granted. Failure to reproduce it would expose gaps worth correcting.

The second signal is broader validation with stated coverage. Readers should look for documented checks of supported reads, writes, addresses, and interactions with the host system. The purpose is to make the success claim inspectable.

Those checks would also help define compatibility. A result on a named configuration supports use in that configuration. Testing additional intended hosts would establish how far the claim can extend.

A useful report would explain failures alongside passes. Known limitations let owners judge whether the board suits their machine. Silence about untested configurations should remain an open question rather than an implied assurance.

The third signal is sustained use outside a short demonstration. Repeated operation, ordinary software workloads, and reports from other owners would reveal how the design behaves over time. Those observations would complement targeted tests.

Community feedback would matter most when it includes enough context to investigate. A report tied to a specific board revision and host configuration is more actionable than an unexplained success or failure. That information also gives future builders a clearer starting point.

None of these signals requires a commercial product launch. A carefully documented hobby design can make a meaningful contribution. Its value comes from helping another person keep a machine running with less uncertainty.

The Dave Plummer RAM project already offers a concrete case for examining AI’s role in engineering. The assistant helped during development; the reported result depended on building, debugging, and operating physical hardware. The remaining questions concern how completely that result has been tested and how readily others can repeat it.

Follow the design files, test descriptions, and independent builds as they appear. For anyone considering AI assistance on a technical project, preserve the same chain of evidence: the requirement, the proposed implementation, the observed behavior, and the correction. Plummer’s reported Unix boot gives this story a useful milestone. A reproducible board and transparent validation would give other restorers something they can evaluate for their own machines. When the next update arrives, ask a concrete question: does it make the working result easier for someone else to verify and reproduce?