News for EDUC-8

The computer simulation is a mess. It gives every indication that signals are getting lost.

Current work is on the "Test Bench" which is a simulation of a logic analyser. This will enable the viewing of the state of connections on multiple boards (ie threads) simultaneously (if I can get it working).

Currently the user interface for the test bench is a big clumsy looking dialog box. Today I discovered that Qt provides good integration between its graphics scene and ordinary widgets. Hence I will be able to eventually create a nice looking interface that more resembles the actual box of electronics.

#EDUC8

EDUC-8
Making progress on two fronts, neither of which are the actual computer itself 😞

The problem seems to be interactions between EDUC-8's circuit boards. To diagnose this I need some more advanced tools than simple print statements.

Enter the Test Bench. This is a simulated Logic Analyser. Eventually it will look like a multi-channel oscilloscope with advanced triggering.

The user interface is mostly working, sufficient for my immediate needs. The settings can also be saved for future sessions, which should be a time saver.

The existing monitoring has been adapted to feed into the test bench (in addition to printing). This provides snapshots of the state of a list of connections, captured by the time slicer that does the simulation.

The batches of snapshots are split into events (a timestamp, and a Boolean value) and placed on to lists for each channel (one for the trigger, 12 to watch, and 8 for a monitored register).

Today's insight was a means of reading the data across all channels in a time sequence.
It's nice to finally understand how the thing you are building might actually work.

#EDUC8 #programming

The EDUC-8 roller coaster has fallen off the rails entirely.

After the success with the program counter and adder board I took the big step of adding the memory board. This has the 256 bytes of RAM, a memory address register and a memory buffer register.

If it was a real machine I would think someone had reconnected everything at random. Perhaps with the workings of an Enigma machine thrown in for good measure. To say its not working does not convey what I am seeing.

Things are now too complex for the simple monitoring I have been using. The boards each run in their own thread and there is lots of communication via common buses.

Of course I have taken the requisite steps to handle the inter-thread communications (but I won't be surprised if I missed something).

I am now working on trying to merge the monitoring of each board into a unified view.

#EDUC8

Well that was a frustrating few days.

EDUC-8 was failing to perform any operation that involved adding one. This includes the program counter, skip instructions and incrementing the accumulator.

My simulator has enough built-in debugging to be able to monitor the state of connections. Zeroing in on the obvious candidate - the adder and its carry flip-flop, the result was mostly confusion.

This was partly resoled once I realised that the adder was being used in the opposite polarity. However, a close examination of the circuit diagram indicated that it could not work. If you set the carry input to zero, and gate off one of the inputs, an adder is never going to produce a signal on the carry output.

After several previous errors in the circuit diagrams, I carefully checked it against the PCB print, but they agreed. Also double checked the workings of the flip-flop from alternate manufacturers, and my implementation. Nothing wrong there.

Mostly in frustration I changed the connection to the other output of the carry flip-flop. (This is just an edit to a data file.)

It all started working!

I tested all the instructions, apart from the ones involving memory, and they all performed correctly.

I must try to locate my original copy of the article for this circuit. I am wondering if I made any notes about this when I built it back in '75.

#EDUC8

I seem to have over-done this simulation for EDUC-8. Apparently I am also simulating dry joints.

The accumulator board was not working. I had left off its connection for the master clock signal on the mother board.

I can debug electronic hardware, and I can debug software. Debugging a software simulation of electronics is, however, much more "interesting".

#EDUC8

Another small milestone for EDUC-8.

All of the circuit diagrams have now been annotated. This involves giving each symbol its chip type (eg7400), an identifying number, and the pin numbers of the chip package.

The task mostly involves tracing out the connection paths on the PCB print out. However there was a few discrepancies where the published circuit diagram and the PCB differed. In those cases I overlayed the PNG of the circuit diagram with SVG corrections.

The next phase gives each connection an identifier and enters that and the associated chip identifiers and pin numbers into the JSON database. That will take a few days.

#EDUC8

Finally, the first two boards are behaving correctly.

The final two bugs were in the simulation of a counter and a flip-flop. The counter was just carelessness. It has an edge triggered clock and I forgot to update the previous value so it could correctly detect the change.

The flip-flop (7473) was not supposed to be edge triggered, but I had assumed that would not matter - it does.

I can now get back to the data entry for the rest of the simulated circuitry.

I might get a proper night's sleep without trying to figure out why its not working.

#EDUC8

The latest on EDUC-8.

The timing board was "wired up". (ie the simulated connections were set up). This should have resulted in much of the front panel working, but sadly this was not to be.

A few issues were fixed: a wrong chip, mis-connected switches; but it still behaves oddly.

I have implemented a simple mechanism for monitoring the state of connections. This helped a bit, but when the clock is enabled there is too much output to be useful.

So, the next bit of development is to create a simulated logic analyser to diagnose the simulated computer.

This is actually an opportunity more than a problem. The purpose of EDUC-8 is to inform about the internal workings of computers. Hence being able to follow the actions of gates and other chips seems like a useful addition to the design.

#EDUC8

Some progress on EDUC-8.

I finished entering the circuit connections data for the mother board and front panel. This then highlighted that I had not built anything to observe what was happening internally.

So a few days were spent adding some code so that I can specify the identifiers for some connections and have the results displayed on the terminal. The tricky bit was to devise a solution with the smallest impact on the processing speed. The solution is not perfect, but good enough to do some debugging.

Of course, entering 185 connections (specifying the identifier for each object it is connected to, and the corresponding pin numbers) did not go without a few goof ups.

Anyway, those issues were all quickly resolved. I am now starting work on the timing board. This generates a multitude of signals for the rest of the machine.

The main issue is likely to be one of speed. The clock speed has to be low enough for the signals to be propagated to their destinations before the next clock transition occurs. This is something that depends on the computer that the simulation is being run on.

#EDUC8