Introducing retrosim

Hello all. I have not been very active in the forum recently because I’ve been working on a new tool. It is a digital schematic editor and simulator which I hope users may prefer to hneeman/digital and logisim. It has the following features:

  • TTL components defined by YAML files (with programmed, built-in behaviors only for asynchronous logic only—this varies from part to part)
  • Subunit rendering for logic gate packages
  • Editor contains an autorouter that suggests a wiring path. After clicking, grab the wire with the mouse to add or move a bend point, like Fritzing.
  • Logical simulation only. There are no power connections, grounds, resistors, or capacitors in the editor or simulation. Built in logical components are available for pull-ups and pull-downs.
  • Bus tool snaps autorouted buses to “pin groups” defined on parts in their YAML files.
  • Four state logic, Provides full support in editor and simulator for 3-state buses (unlike hneeman/digital and logisim), including checks for bus conflicts in the slow simulator. Pull-ups (“weak 1s”) are supported
  • There are actually two simulators. A slow or “debug” simulator written in JavaScript that runs in editor and a simulation generator that writes a C program.
  • The generated C programs can read test vectors from standard input and can write .vcd files.
  • TTL component behaviors can be specified in Galasm embedded in YAML files.
  • 22V10s can be specified in-app and become first class components once defined.
  • ROMs and RAMs can be defined in-app with any bit width and capacity and become first class components as well.
  • Define and test subcomponents as schematics. Render them in a parent design as ICs or pin strips.
  • Support for files of test vectors

I am looking for people to try out this tool and give me feedback. In the age of Claude code, I should be able to respond to the feedback much more quickly than was possible traditionally. To try out this app you must pull the repo from GitHub and you must be able to compile the small, localhost-only Go language server. There is no binary distribution for any platform so this is the only way to use it.

I should add that this app was not “vibe coded”. It is the result of hundreds of small interactions with the AI tuning the various user interface and simulation features (see the file todo-list in the root of the repo if you doubt it). But the AI did write all the code, 100%. It’s a new age.

1 Like

Back in the 70’s we used to use text-based descriptions of circuit boards and code to automatically lay them out and produce wire lists etc. (e.g. https://gtoal.com/history.dcs.ed.ac.uk/archive/docs/CSRs/CSR-53-80-the-elementary-structural-description-language.pdf ) I had to design a small board last year and there were no systems like that around any more, with everything being GUI now. But it was still the best way to document the design so I invented a syntax in the old style to describe my board: https://gtoal.com/vectrex/joystick/netlist.txt - no compiler for it, just manual layout - but that’s the sort of system I’ld like to see. The same description that drove the layout and wire-wrap machine also drove the simulator. (imaginatively named ‘sim’ - this might be it from our archives… https://gtoal.com/history.dcs.ed.ac.uk/archive/os/apm_filestore/a/July89/ETHER/SIM )

The biggest problem with any of these systems of course was keeping the library of TTL chips up to date. Maybe now they’re mostly ‘retro’ that won’t be such an issue. Here’s part of the library for ESDL… https://gtoal.com/history.dcs.ed.ac.uk/archive/os/apm_filestore/a/July89/ESDL/CHIPLIB.SRC

1 Like

Thanks. I think the retro nature of TTL does make it easier to keep the list of parts up-to-date. But the biggest change is that there is a “skill” file for the AI that allows it to create part descriptions from data sheets. So when you need a new component you can just ask the AI to take care of it, assuming you have a subscription. The fly in this ointment is that a few component types require component specific code in the simulators. And example I hit recently was anything with hidden state like shift registers. This required a code change for the '165 and '595. If you do try out the simulator and you need any specific parts, just ask me and I will be responsive about adding them.

I do have a question for you. I too did a wire wrap based design a couple of years ago. But I found that wire wrap tools were hard to come by. The traditional manual tools were Chinese fakes that were poorly manufactured and didn’t work very well. And there were no powered guns for 30 gauge wire still available. I guess Gardner Denver gave up trying to make them long ago. What did you do for a wire wrap tooling?

I also use wire-wrap for my hobby computers; I don’t know about wire wrap guns, but the good manual tools are still available from Jonard Tools. You just have to exercise the usual caution when buying online to make sure not to get a badly machined counterfeit.

2 Likes

OK @gtoal I had Anthropic’s amazing Fable model read your “joystick” example document and generate a specification for the language you wrote. The language spec it produced is here. Then I had it write an exporter for NDL so you can now save any schematic in this format. An example of a functioning 163 counter is here. I saved some of the amazing discussion I had with the model here. It makes interesting reading. I assert that this model is basically a software development-specific superintelligence.

Ha! I’m please to see that my sketchy language was consistent enough for the AI to infer a full description from :slight_smile: And I appreciate your enthusiasm and willingness to offer help, although I don’t do enough circuit design to have enough justification to take you up on that, at least this year. (Most of my work is on the software side and my current project is writing a compiler, which is likely to keep me busy for some time). Re ESDL and wire-wrapping - the university did add an automatic wire-wrapping system after I’d graduated; but when I was there we worked from a printed netlist by hand, using a capacitive discharge spot welder on pre-tinned eurocards (we called it the ‘zap gun’). I assembled several dozen 6809 cards with it as my vacation job one summer. So I really have no idea what’s current (or even old) in wirewrapping, since even prototypes nowadays tend to go straight to PCB. I do have an interest in using my CNC to make PCB prototypes but that also is scheduled for the semi-distant future as I have more than enough projects in my queue to finish first.

Although the usb-to-analogue joystick project as documented in An open-source USB Joystick (and mouse) to Vectrex Controller converter used a breadboard, we did follow up with a PCB laid out by hand from that netlist doc by a friend in the Vectrex group.

It would be cool at some point to be able to specific a circuit and board parameters (board size, support/mounting holes, and edge connectors) textually and have tools to automatically lay it out and generate the PCB, but I think history has passed us by on that front.

Relevant to your project, there are a few other old tools around that still do useful related jobs; for example logic minimization: In Index of /src/booleans there’s “minimo” which is a fairly good logic minimization program written by one of my lecturers. (there’s also my own plamin which is a lot less intelligent that I hacked up while at UMIST where I was taking a 1yr course to pick up VLSI design, though it was mostly PLA and FPGA stuff we did rather than proper Mead & Conway style design). I see you have quite a bit of interest in GALs. I hadn’t come across them until just a few years ago when I was assembling a 6809 board that used one, so I had a bash at writing something to generate and simulate gal22v10 data - I didn’t finish it but at least I got far enough into it to get a fair idea of what the chips do (which wasn’t really explained too well in the docs I was reading!). Those GALs were already redundant tech by the time I came across them!

palwiz in that directory is Bruce Tomlin’s code that I later found, which already did what I was trying to do, and was probably the reason I abandoned my partially written program, since I’ld learned as much as I needed to from the effort and didn’t really need to finish the code for anything.

G

No worries at all about not using the app it’s completely up to you of course. I did have a discussion about logic minimization with the AI during development. Because the definition of what fits in a GAL depends on the logic minimization capabilities of the toolchain, and indeed this tool does not do any. Maybe I should integrate minimo!

The NDL exporter was a good exercise because my component descriptions now have enough metadata to allow for a future KiCAD exporter.

Thanks for the interesting discussion.

I tend to like a 22V10 for the simple reason it has clear for flip flops.
Are the GALS still simple in that you can blow the fuse logic by hand?
I also like when PAL’s first came out, development software was written in FORTRAN
and not tied to Windows or Linux.

.

1 Like

One of the reasons that I like 22V10s is that there is a completely open source tool chain. You can use Galasm to specify and Minipro to program them.

To answer your other question, they have not been any new GALs in decades. The world moved to larger CPLDs and then to FPGAs, almost all of which require proprietary tools to program and use.