Category: Uncategorized

Background and Motivation

I’ve long been interested in Bret Victor’s Dynamicland and RealTalk work, but I’ve also found it frustrating that the system is entirely closed-source. He has explained his reasoning for this, but it does limit the ability to experiment with the ideas first hand.

The only publicly available system in a similar space that I could find was the Folk Computer project. Although I have a fondness for Tcl and Linux, I ultimately decided to build a more conventional Windows-based C# implementation instead.

Source code is available at https://github.com/ynformatics/TabulaLuma

To be clear, I have no inside knowledge of Bret Victor’s system. This project is based solely on interpretations of his published papers, talks, and demos. These are excellent by the way, and I recommend browsing through them to get a better idea of the thinking behind this work.

TL;DR;

• Set up and calibrate the hardware as described below
• Use the FrameCodeGenerator program to print out frames with program ids 0 and 1
• Program 0 is a code editor, it will show a whisker pointing up. Move program 1 over the end of the whisker. You can now edit the code for program 1. Press Ctrl + S to save.
• print out frames with program ids 2, 3 and 4. They should display something when placed on the table. Bring them in range of the code editor to see the code. This is decompiled from the assembly bytecode. You can edit and save the modified code which will generate an overriding .txt script file.

Core Concept

The central idea is to give physical objects programmable behaviour.

A canonical example is using sheets of paper tagged with fiducial markers. These markers allow the system to track each objects identity and position on a table. Programs can then be associated with individual pieces of paper, enabling text and graphics to be projected directly onto them using an overhead projector.

In effect, the physical paper becomes both an interface and a computational entity.

Reactive Programming Model

Programs in this system are written in a reactive style, built around three core concepts:

Claims

A Claim represents a statement of fact about the systems current state.

(page-1) has width 123.4

Claims describe what is.

Wishes

A Wish represents a desired state, something that should become true.

(page-1) is labelled "hello world!"

Wishes describe what should be.

Whens

A When defines the actions required to make a wish come true when certain conditions are met.

Conceptually:

When /page-id/ is labelled /label/, then draw the label on the corresponding page.

Whens form the bridge between declarative intent (wishes) and imperative behaviour (actions).

Implementing the Model in C#

Implementing this model in C#, a statically typed language, introduces some additional complexity. Dynamic languages such as Lua or Tcl are more naturally suited to this style, but it is still feasible in C# with careful design.

Claims and Wishes

Claims and wishes map cleanly to simple API calls:

Claim("(page-1) has width (223.4)");

Whens with Actions

A When statement associates a pattern with an action. The action receives a binding context that provides typed access to the matched variables.

When("/page-id/ is labelled /label/", b => {
    var id = b.Int("page-id");
    var label = b.String("label");

    var ill = new Illumination();
    ill.Text(label);

    Wish($"({id}) has illumination '{ill}'");
});

In this example:

• The pattern extracts the page identifier and label text

• The action constructs a visual representation

• A new wish asserts that the page should display that illumination

Note that any valid C# code can be used in the action block and the full .Net framework is available. Claims/Wishes/Whens can be nested as required.

Handling the Non-Matching Case

A When can also specify what should happen when it doesn’t match, using Otherwise:

When("(you) is calibrating", b =>
{
    // Executed while the condition matches
})
.Otherwise(() =>
{
    // Executed when the condition does not match
});

This allows a rule to explicitly manage both its active and inactive states.

Attaching Options with with

A When may include an options list using the with keyword followed by name/value pairs. These must appear at the end of the statement:

When("/p/ is labelled /label/ with name /value/", b =>
{
    // if b["name"] exists it will contain the provided value
});

The binding context exposes these values when the When is triggered by a Wish or Claim that supplies them.

Combining Conditions

A When can depend on multiple claims that must all be true (logical AND).

They can be expressed inline:

When("/p/ points /direction/, /p/ has width /width/, /p/ has height /height/", b =>
{
});

Or written in a more fluent, stepwise form using And:

When("/p/ points /direction/")
    .And("/p/ has width /width/")
    .And("/p/ has height /height/", b =>
{
});

Both forms express the same intent: the action only runs when all conditions are satisfied.

Memories, Remembering State Across Frames

In addition to Claim, the system provides a Remember statement. Like Claim, it injects a fact into the database, but it persists from the next frame onward:

Remember($"(you) has illumination '{ill}'");

Remember also supports optional temporal clauses:

Remember($"[for (2) seconds] calibration has illumination '{ill}'");

This allows transient state to be modelled declaratively, without explicit timers or lifecycle management in user code.

Fiducial Markers

The system originally used AprilTags, which worked reliably but proved to be slower than desired. Inspired by the coloured dot frames used in RealTalk, I wanted a lightweight alternative that visually framed the active area while remaining fast to detect.

To keep printing simple and compatible with black-only printers I designed a new fiducial format called Corner Frames.

Each frame is composed of four independent corner markers:

• Every corner contains:

  • Two outer solid strips for geometric detection

  • Two inner binary-coded strips for identification

• Each corner provides 15 bit positions:

  • 14 bits encode the identifier

  • 1 bit is reserved for parity checking

This yields:

• 2^14 possible codes per corner

• A frame consists of four sequential corner codes

• Because of this sequencing, only three corners are required to uniquely identify and locate a frame

• The system supports 2^12 – 1 = 4095 distinct frame IDs

This structure introduces redundancy while allowing robust recovery from partial occlusion.

Corner Detection Pipeline

Corner detection proceeds through a simple, fast image-processing pipeline:

1. Apply Otsu thresholding to binarize the image

2. Extract contours whose area lies within a configured range

3. Fit bounding boxes to each contour and reject those that are not:

   • Approximately square

   • Within the expected size range

4. Locate the coded strip within each candidate corner and decode it

5. Reject any corner whose parity check fails

At the end of this stage, the system has a set of validated, decoded corners.

Frame Reconstruction

Once individual corners are detected, the system searches for groups of sequential codes starting at a multiple of four:

• If four sequential corners are found, a complete frame is identified

• If three sequential corners are found, the system infers the position of the missing corner and reconstructs the frame

This allows frames to be recognized even when partially obscured or outside the cameras view.

When a frame is successfully assembled, its corner coordinates are passed back to the main program, where they become part of the world model and can participate in claims, wishes, and reactive rules.

Hardware Setup

Begin by mounting both a projector and a webcam so that they have a clear, unobstructed view of the table surface.

Both devices should operate at a minimum resolution of 1920 x 1080. The software is developed and tested at this resolution; higher resolutions should also work, but may require minor adjustments within the code.

The reference setup uses:

• Logitech C920 webcam

• WiMiUS P62 projector

Other hardware combinations are likely to work, provided they meet the resolution and mounting requirements.

Camera Calibration

Turn the projector off for this procedure.

1. 1. Use the Corner Frame Generator to print a set of Corner Frames and lay them out on the table surface.

   2. Launch the Tabula Luma application.

   3. Press Ctrl + K to start the camera calibration mode.

   4. Adjust the camera:

      • Use Shift + F / f to increase or decrease focus

      • Use Shift + E / e to increase or decrease exposure
        (Uppercase increases the value; lowercase decreases it.)

   5. Tune the minimum and maximum area detection parameters until the Corner Frames are outlined in red. It is OK to have a few spurious detections.

      • Use Shift + X / x to increase or decrease max area
      • Use Shift + N / n to increase or decrease min area

      • When a Corner Frame is successfully detected, a green square will appear around it.

      • Adjust lighting and calibration parameters to achieve the most stable and accurate detection possible.

   6. Once detection is reliable, press Ctrl + S to save the calibration values.

   7. Press Escape to exit the calibration program.

At this point, the camera is configured to reliably recognize the fiducial markers under your current lighting and table conditions.

Camera /Projector Calibration

Accurate calibration is essential for reliable table-surface tracking. Before starting, clear any objects from the tabletop to ensure the camera has an unobstructed view.

1. Display the Calibration Pattern

Make sure the projector is turned on and adjust it for best focus.

Press Ctrl + L to display the on-screen calibration pattern. The interface should show four blue squares, with a central blue dot.

Use the arrow keys to adjust the scale of the pattern. For optimal detection, expand the pattern so that the four squares are positioned as far apart as the display allows.

A small blue dot will be seen in the centre of the pattern when it has been successfully recognized. If the dot does not appear, try placing sheets of plain white paper beneath the squares. Since the detection algorithm relies on recognizing a specific blue hue, variations in lighting or table texture can interfere with detection.

Once the pattern is correctly recognized, press Ctrl + S to save the calibration.

2. Define Real-World Coordinates

After saving, the system needs the actual physical coordinates of the patterns outer corner points.

1. 1. 1. Choose a coordinate system, for example:

         • Origin at the top-left corner

         • X increases to the right

         • Y increases downward

      2. Measure the real-world coordinates (e.g., in millimetres) of each outer corner of the pattern.

      3. Open the configuration file located at:
         %LOCALAPPDATA%\TabulaLuma\config.txt

      4. Locate the "WorldPoints" section. This array defines the world-space coordinates of the four corner points, starting at the top-left and moving around clockwise.

      5. Replace the existing values with your measured coordinates and save the file.

Principles of Operation

At start up, the system loads its configuration from:

%LOCALAPPDATA%\TabulaLuma\config.txt

If no configuration file exists, a default one is created automatically. The camera subsystem is then initialized using these settings.

Program Discovery and Loading

The next phase loads all available programs. A program is any class that derives from ProgramBase and implements IProgram.

All assemblies in:

%LOCALAPPDATA%\TabulaLuma\shared

are scanned using reflection. Any types implementing IProgram are instantiated and loaded into memory. This includes both the main TabulaLuma.dll and any external assemblies placed in the directory, enabling a plugin-style architecture.

In addition to compiled assemblies, the system also supports scripted programs. Any .txt files in the same shared directory are treated as C# source:

• For each file, a new class derived from FunctionBase is generated

• The files contents become the body of the virtual RunImpl() method

• The filename (minus extension) becomes the ProgramId

If a duplicate ProgramId is encountered, the later definition overrides the earlier one. As scripted programs are loaded after built-in ones they will take priority in the event of a duplicate.

Frame Processing Pipeline

A background task is started to continuously capture images from the camera. Each frame is placed into a BlockingCollection, decoupling acquisition from processing.

The main thread then enters a loop, waiting for the next camera frame. For each frame:

1. 1. Clear the fact database

   2. Extract any CornerFrames from the image

   3. Run all resident programs asynchronously

   4. Run any programs associated with detected corner frames, passing the corner frame coordinates as arguments

   5. Inject system-wide Claims (for example, the current clock time)

   6. Wait for all program tasks to complete

   7. Draw any generated Illuminations into the display buffer

   8. Render the buffer to the projector

Each iteration represents a complete world update: perception, inference, program execution, and projection.

I have a Homecom wall mounted heater which I’d like to integrate into a home automation system. So we need to hack!

Remove 5 philips screws to release the back cover. Disconnect the ribbon cable and the switch spade terminals to separate the front and back covers. (The spade terminals in the unit are very tight and need a fair bit of force to remove)

Next remove the PCB. Again the spade terminals are very tight.

With the PCB removed we can take some pictures and reverse engineer the schematic.

The circuit uses an HS78L05 regulator to provide a 5V supply, but this is limited to about 100mA which is not enough for the ESP32 I intend to use. So I replaced it with a 5V buck convertor with a TO-220 form factor which plugs neatly into the PCB.

For the controller I used a Xiao ESP32C3 and wired it up using some 0.1″ Dupont connectors. Using the original ribbon cable would be neater but I had some ideas about reusing the original PCB.

Be careful, the ESP32 ground is tied to mains AC Live! I initially uploaded a sketch to the bare controller with basic OTA functions enabled. Once that was done I could then install the ESP32 in the unit and safely upload over the air as needed.

Firmware

Available here: https://github.com/ynformatics/WallHeater

I use MQTT for automation so the firmware exposes some MQTT topics as follows:

“homecom/heat”: accepts “LOW”, “HIGH” and “OFF” commands. “LOW” sets 1kW mode, “HIGH” 2kW mode. The fan is automatically turned on when heating is selected. “OFF” turns off the heaters and then the fan after a 30s cool down delay.

“homecom/cool”: accepts “ON” and “OFF” commands to turn the fan on or off. No heating.

“homecom/swing”: accepts “ON” and “OFF” commands to enable flap movement

“homecom/beep”: accepts a “BEEP” command

“homecom/status”: publishes status message every 5s

“homecom/debug”: publishes debug messages, including the WiFi address assigned at start up.

Part 2 – The display PCB

So the lure of the other PCB with its buttons and LEDs was too strong to resist. Here are the close up pictures:

And the reverse-engineered schematic showing the original microprocessor location before removal and the connections to the Xiao ESP32C3 module:

The original microprocessor is a “KW20K”. As well as sending control signals to the main PCB, it reads data from a TSOP17 IR remote receiver, an NTC temperature sensor and two push buttons. It also controls the display via driver IC labelled “ET1616”. I’m not interested in the remote or temperature sensor, just the display and buttons.

The buttons are easiest to understand. One shorts the data line to ground, the other via a 10k resistor. Combined with the 10k pull-up resistor on the PCB this gives either 0V or VCC/2 V on the data line. On the original PCB the pullup goes to +5V which needs re-routing to an ESP32 +3.3V pin. This is easily done by cutting the track as shown and running a jumper wire.

There was no information online about the ET1616, but I did find a datasheet (https://archive.org/details/gn-1616-datasheet) for a GN1616 in Chinese which appears to be the same part. It’s a 4 digit, seven segment driver with an SPI interface. Digits 3 and 4 drive the visible seven segments and digit 2 drives the individual LEDs. After a bit of Google translating and probing its SPI secrets were revealed and can be found in the source code here: https://github.com/ynformatics/WallHeater2

I de-soldered the original microprocessor and wired in the the Xiao module as shown in the schematic. We are using all available pins so I left out the buzzer signal as I don’t intend to use it. [Note: not tested but it could share pin D1 with the buttons. Switch D1 to output mode, send a tone then switch back to input mode]

I added some more MQTT topics for the new functionality:

“homecom/display/number”: accepts a number (0-99) for display. -1 will blank the display.

“homecom/display/leds”: accepts a comma separated list of LEDs (1-6) to turn on. 0 will turn off all LEDs.

“homecom/display/hex”: accepts a 4 byte number in hexadecimal notation. Byte 3 (MSB) is ignored, byte 2 sets the LEDs, byte 1 the tens digit segments, byte 0 the units digit segments;

“homecom/display/brightness”: accepts a number from 0-7. 0 = display off, 7 = full brightness.

“homecom/button”: publishes a “T” if the clock button is pressed, “F” if the “F” button is pressed

Here is a close up of the Xiao ESP32C3 in place with track mods shown.

And here is the PCB installed in the case:

This is based on an idea by youtuber bbrendon (https://www.youtube.com/watch?v=7pThAC41fd4). I’ve added some more details and pictures of the process.

Here is the original drawer fully opened. Only 37 cm of the total 52 cm depth extends outside the cabinet.

First remove the two screws securing the drawer to the sliders. Open the drawer and continue pulling until it is as far out as you want. I left a couple of centimetres inside the cabinet. The metal slides will retract from the front of the drawer as you pull.

Mark the position of the screw hole on the drawer side (make sure you use the hole where the screw was fixed originally. It has a raised lip)

Cut a slot in the drawer sides from the original screw hole to the marked position. I used a 5mm router bit for this but a jig saw could be used. Be careful when cutting as the “wood” is lined with a plastic coating which is liable to tear. Sand/file as needed to neaten up the slots.

Re-install the drawer on to the slides and replace the screw on each side. Don’t fully tighten the screw but add a small drop of Loctite or glue on the thread to stop it coming loose.

Here is a short video of the drawer in operation.

STL file downloaded from: https://www.thingiverse.com/thing:4853500

Printed on a Prusa i3 MK2 in PLA, 0.2 mm resolution, 25% honeycomb infill.

Some instructions and pictures of the conversion.

All done!

I needed to connect some more test equipment to my LAN. Currently this is done with individual Serial-to-Ethernet adapters in takeaway curry containers but this was getting ungainly and wasteful of internet ports.

Commercial 8-port RS232 to ethernet devices are available, but expensive, so time to DIY! I had a teensy 4.1 on hand and this looked like a good contender with in-built ethernet PHY, eight hardware serial ports and an Arduino compatible software stack (Teensyduino). It just needs an external Ethernet jack with magnetics (from PJRC) and eight RS232 DB9 connectors with MAX3232 level shifters (£1 each from from china).

The level shifters typically come with just TX and RX pins connected. They can be easily hacked to add CTS/RTS support. Just connect CTS (pin 7 on the DB9) to pin 8 of the MAX3232 and RTS (DB9 pin 8) to MAX3232 pin 7. Logic level CTS/RTS are then available on IC pins 9/10 respectively. Here are some pics of the mods I made:

For software we need 8 TCP listeners each listening to a different port at the same IP address. I had trouble getting the NativeEthernet library to reliably support 8 connections but the QNEthernet library worked fine.

The algorithm just loops around each TCP port, and if there are any incoming bytes available reads them and forwards them to the corresponding serial port. And vice versa.

There is also an embedded webserver that allows configuration of the networking and serial port parameters.

Here is the teensy being tested with each serial port looped back to itself. Grounding the green wire reboots the board in webserver mode where device settings can be configured.

Next a 3D printed case was designed in Fusion 360

Here is the bottom section with 4 serial ports installed. A few dabs of hot glue can be used if needed to keep things in place. If you only need 4 ports then the top can be fixed at this point.

Here showing the middle 3D printed layer in place with the top 4 serial ports. A small tactile switch to enable config mode has been glued in. At this point all RX/TX pairs are looped back for testing.

And finally the top is added and all three layers sandwiched with 53mm M3 machine screws.

Now off to rip out the takeaway containers and tidy up the wiring!

Teensy software available here

Fusion 360 CAD files here

A New Home Model 1585 was stuck in reverse. Can we fix it?

First step is to remove the front cover.

Pull off the knobs, remembering their position (there are some index holes if you forget)

The lump of metal indicated was the problem. It was not retracting when the reversing lever was released. Some cleaning and light oiling helped but the final solution was to slightly loosen the screw marked in red.

Reassemble and all was well

This Leitch studio clock is designed to work with a timecode signal for best accuracy. Timecode generators are expensive so I built one with an ESP32 dev board.

SMPTE/EBU description here and the bit format of timecode here

The timecode signal is a stream of digital data, 80 bits for each frame of data. In Europe there are 25 frames per sec (EBU) and in the US 30 (SMPTE). Each bit is encoded in Manchester style, with a signal inversion at the start of each bit period and a further inversion halfway though the bit if it’s a “1”.

Here is a snapshot of the generated EBU waveform representing 010000001111

For the software we just need an accurate source of time and accurate pulse generation.

Time is obtained from the internet NTP server using the ESP32 Arduino library to keep the ESP32 local time in sync with NTP and to handle GMT/DST issues.

A hardware timer is set to fire every 250uS (for EBU) to output start bit and mid bit transitions. When all 80 bits have been sent the frame counter is incremented. When all frames have been sent the whole data packet is updated with the current time and the process repeats.

Source code: https://github.com/ynformatics/SMPTE

Rather than using a separate enclosure I fixed the ESP32 module inside the case. A source of 5V power is available on the main PCB and there is a spare selector switch available for entering configuration mode. The timecode signal output is wired directly to the input of the clock. If needed this can be daisy chained to other clocks.

Here is a video of the modified clock powering up. There is a short delay while connecting to WiFi and getting the time. Once the timecode data starts, the clock registers all hands to the 12 o’clock position, moves them to the correct time and then maintains time in sync with the timecode data.

This sign is programmable via RS485 (the orange connector) but uses proprietary hardware and software so is ripe for reverse engineering. The 8 pin ribbon cable to the display board suggests a serial protocol and probing with an oscilloscope showed 0-5V digital signals. Time to attach a logic analyser.

Here is the overview on start-up:

This looks like some initialisation data and then regular data transmission every second. There is a 100Hz pulse train on pin8 (heartbeat from the display?) and a delayed pulse on pin6 about 15ms after each data transmission

Here is a zoomed-in trace for one of the data transmissions:

So definitely SPI style with a rising edge 2.4 MHz clock on pin5 and data on pin4. By default, the display powers on with the top-left led lit. The ’80’ byte in the first set of data suggests the data is being sent left-to-right, top-to-bottom, MSB first. The pixel data is gated by pin3 (active low). Each row of display data is preceded by a header, ‘3E’ for the first row and ‘BE’ for the second. Header data is gated by pin2 (Active High). Some further experiments showed that pin7 accepts an analog voltage to set the display brightness (0-5V).

In summary the function of the connector pins is:

1. GND
2. HEADER_SEL (Active high)
3. PIXEL_SEL (Active low)
4. DATA (Idle high)
5. CLK (Idle high, rising edge, 2.4MHz)
6. EOT (End of data transmission)
7. BRIGHTNESS (analog 0=on 3V = off)
8. HEARTBEAT? (100Hz pulses from the display)

Now we have enough info to create a prototype. I used a Wemos D1 Mini (ESP8266) which has hardware SPI and WiFi support. 5V power is available from the sign itself so no other hardware is needed. Here are the pin mappings:

Some code was written to implement the above protocol. It subscribes to the MQTT topics “hanoverled/display” (64 bytes of display data) and “hanoverled/brightness” (0-1023) and updates the display as these topics change.

Here is an extract of the code showing the main display routine. It accepts 64 bytes of data being the pixel values in left-to-right, top-to-bottom order. Not sure what the header values mean so just used the captured values 3E and BE. The ‘EOT’ pulse at the end of transmission is required otherwise the display does not update properly.

void UpdateDisplay(byte data[64])
{
   SPI.beginTransaction(SPISettings(2500000, MSBFIRST, SPI_MODE2));

   // meta data row 1
   digitalWrite(MS, HIGH);
   SPI.transfer(0x3E);
   digitalWrite(MS, LOW);

   // pixel data row 1
   for(int i = 0; i < 32; i++)
   {
      digitalWrite(DS, LOW);
      SPI.transfer(data[i]);
      digitalWrite(DS, HIGH);
   }

   // meta data row 2
   digitalWrite(MS, HIGH);
   SPI.transfer(0xBE);
   digitalWrite(MS, LOW);

   // pixel data row 2
   for(int i = 32; i < 64; i++)
   {
      digitalWrite(DS, LOW);
      SPI.transfer(data[i]);
      digitalWrite(DS, HIGH);
   }
   SPI.endTransaction();

   // pulse EOT line
   delay(15);
   digitalWrite(EOT, HIGH);
   digitalWrite(EOT, LOW);
}

To test the display a version of Conway’s game of life was written. Random start populations are generated, evolved and sent to the MQTT “hanoverled/display” topic. The program generates a new population if a game starts to repeat.

Here is a video of the sign in operation:

I bought this Sinclair calculator off eBay with the intention of repairing it. The power supply rails, LED display and driver chips were working fine. The keyboard had several keys that did not show any connectivity which could be fixed. But the main C-595 calculator chip was faulty and outputting random signals.

The C-595 is of course unobtainable these days, so could we replace it with a suitably programmed Arduino chip and bring it back to life?

First job was to fix the keyboard. Several keys were not functioning so this needed a tear down and clean.

The keyboard was held in place by plastic pegs which naturally snap off when disassembling! Some small holes were drilled in the plastic frame using a hand held 1mm CNC drill bit taking care not to go through to the other side. Small lengths of 1mm ABS rod were then glued into the holes and melted with a soldering iron to keep the keyboard layers tightly sandwiched together.

With the keyboard working we turn attention to the main calculator chip. The plan was to design a small PCB carrier for an ATMega328 chip that could plug in in place of the original chip.

A datasheet is available for the C-595 (local copy here) and after some reverse engineering we arrived at the following schematic:

The C595 runs with a positive earth, so we’d have to install the Arduino upside down. A bit of a brain ache but it should work. I wanted to use the existing driver ICs to minimise changes.

Removed the C595 IC and replaced with a socket. Removed the coil to disable 15V and 9V generation. Added a jumper wire to supply -3V battery power to an unused pin 10 on the socket.

The LED display is a 9 digit, seven segment common cathode device. To turn on a segment requires the segment line to be at 0V and the corresponding digit cathode at -3V. Allowing for the voltage inversion by the driver and the upside down Arduino, that corresponds to a HIGH for the segment and a HIGH for the digit.

To add to the fun the keyboard is multiplexed to the digit driver pins. An INPUT_PULLUP pin on the Arduino will pull to 0V, so we need to strobe the digit pins with -3V (LOW) to detect a change in state on the KP, KN and KO input pins.

We need 17 digital outputs and 3 digital inputs. To run at low voltage we use the internal oscillator which helpfully frees up pins PB6 and PB7 for use as GPIO.

The software was developed initially as a prototype running on an Arduino Nano. It runs in a loop with three main functions; update the display, read the keyboard and update the calculation when a key is pressed. Updating the display is slightly complicated by the fact that the circuit uses the same pins to enable display digits as well as drive the keyboard. We need to take care to blank the display while the keyboard is polled. For the calculator part of the software a simple state machine is used in conjunction with a custom decimal floating-point library. Firmware can be found in this github repo

Here is a picture of the prototype:

The case wouldn’t close properly using the prototype so a small PCB was designed around a bare bones ATMega238P to fit in the C595 socket. The ICSP and Tx/Rx pins were connected to exposed pads for testing purposes.

An Arduino Uno was used as a programmer to flash the firmware to the ATMega using these pin connections.

PCB    ->  Arduino Uno
PIN 15 (VCC) -> 5V
PIN 10 (GND) -> GND
PIN 7 (KO, MOSI) -> 11 (MOSI)
PIN 8 (KN, MISO) -> 12 (MISO)
J103 pin 5 (~RST) -> 10 
PIN 16 (D9, SCK) -> 13 (SCK)

To support the bare board, definitions were loaded from: https://mcudude.github.io/MiniCore/package_MCUdude_MiniCore_index.json

We use the factory defaults of 1MHz internal oscillator and BOD disabled so no need to change the fuses. Just set the drop down menu items correspondingly.

Here is a short video with a demo of the finished calculator and a quick look inside.

A simple GPIB to USB adapter using an Arduino Uno. Constructed following: http://egirland.blogspot.com/2014/03/arduino-uno-as-usb-to-gpib-controller.html

A 24-way connector (RS 239-1207) was used for the GBIP connector and wired to the Arduino with two lengths of cat 5 cable as follows:

cable 1 pin mapping
GBIP	Wire	Uno
1	wh/or	A0
2	or/wh	A1
3	wh/bl	A2
4	bl/wh	A3
13	wh/gr	A4
14	gr/wh	A5
GND	wh/br	GND
GND	br/wh	GND

cable 2 pin mapping
GBIP	Wire	Uno
5	wh/gr	12
6	gr/wh	11
7	wh/br	10
8	br/wh	9
9	bl/wh	8
11	wh/bl	7
15	or/wh	4
16	wh/or	5

A 3D printed case was designed in Fusion 360. CAD files available here.

The Uno was programmed with GPIB6.1.ino available from Emanuele’s website.