I have entered a rabbit hole with Abacuc. I have spent much of my free time on time in the past few days.

I run the Abacuc 6502 breadboard computer using a Raspberry Pi Model 2B. I also purchased a Raspberry Pi 5 to get some more speed. When the courier delivered the new Pi, I set it up as a perfect copy of the Pi 2.

I use PyCharm as my Python development environment. I can easily set up a remote SSH connection to the Pi, automatically sync my project files, and run the debugger from my Mac if needed. I wish I had these kinds of tools when coding was my job.

The Raspberry Pi 5 does not play very well with RPi.GPIO. You can use it without a problem by running your program as a privileged user. This is not something that I like. It’s a security problem that I should not care about, but I wanted a neat solution.

This is the reason why I switched from RPi.GPIO to gpiozero. No significant differences between them. I should make some tests about speed, but as I previously wrote, Abacuc will be a snail, and speed should be fine here.

I ported my code to gpiozero, and everything worked as expected. I had some issues with the gpiozero on the Rpi 2. From the repository, the installed version is version 1.6.something, while my code was written for gpiozero version 2.0. something. There is a little difficulty in moving to version 2.0 on RPi2, but I made it.

While porting my code to gpiozero, I read the gpiozero documentation and found something exciting.

You can use the library with a Python program on one computer and drive the GPIO pins of a remote computer over TCP/IP thanks to the services of pigpiod on the RPi.

Cool, I can run the code on my Mac without the need to have the code running on the RPi. There may be some speed issues, but that will not be a problem.

I can run the Abacuc code on my Mac. How do I drive the three MCP23017 using the RPi I2C bus? Well, there are I2C remote libraries as well!

This is even better than the plans I had. My original idea was to connect a terminal to Abacuc for input/output. It would have been a console application on my Mac talking to abacuc via TCP/IP. I considered using the original VT220 fonts on this terminal in a classic 40×80 screen resolution. This would have made the terminal really rétro.

I must give this a try!

P.S. I don’t write much about the usual things I talk about these days. Reality is I use coding as an escape from the trenches.

As I wrote in my last post, I am currently spending some time putting together a 6502 breadboard computer. I got the system up and running in a very basic configuration.

I have some debugging output from my Python code. Every time there is a transition of the clock from high to low, I output a debug line that contains the following information:

• Status of the RESB, SYNC, RWB, BE, SOB, IRQB, RDY, VPB, and NMIB microprocessor pins.
• A binary and hex dump of the addressbus address
• A binary and hex dump of the databus
• An indication if the microprocessor is trying to read or write based on the status of the RWB pin. (Redundant with what I do but I wanted a clear visual indication)

This gives a good idea of what is happening while executing code. Since I can lower the operating frequency to whatever value I want and single-step, I can look closely at what the microprocessor is doing. (Thank you again for the full static design of the W65C02)

If you read the W65C02 datasheet, you will learn that:

(SYNC) The OpCode fetch cycle of the microprocessor instruction is indicated with SYNC high. The SYNC output is provided to identify those cycles during which the microprocessor is fetching an OpCode. The SYNC line goes high during the clock cycle of an OpCode fetch and stays high for the entire cycle. If the RDY line is pulled low during the clock cycle in which SYNC went high, the processor will stop in its current state and will remain in the state until the RDY line goes high. In this manner, the SYNC signal can be used to control RDY to cause single instruction execution.

This is cool. I can check if the microprocessor fetches an OpCode and disassemble it on the fly, writing the disassembler output to my console.

A few days ago, I stumbled upon a GitHub repository from Bill Zissimopoulos, basically doing the same thing I was trying to do. The only difference was that he used an Arduino Mega instead of a Raspberry Pi. Looking at the Arduino code he wrote, I noticed he had the same idea about using the SYNC pin. The disassembler code was written in C, and I ported it to Python, spending an hour or so in the process.

It worked like a charm! Thank you, Bill, for your code.

What I wrote is quick and dirty, but it does the job.

Why?

After I finished with Geremia, I had to pick up another personal project to spend some time soldering and coding. I found out that mixing hardware and software is much more fun than just coding for me.

I am an old guy, and I grew up in the Commodore 64 and ZX Spectrum era of computing. My first computer was a Sinclair ZX 80, shining with its Z80 microprocessor at 3.25 Mhz, 1 Kb of RAM, and a connection to my home TV.

I had a lot of fun and have always been on the Spectrum side of computing.

It was about time to play with the other side of the coin, the 6502 microprocessor.

This is how Abacuc was born—a breadboard computer based on the 65C02 microprocessor. Why Abacuc? It’s a citation from a character that appeared in the “Brancaleone alle crociate” movie. Abacuc was a short man who carried inside a small chest while the armada was traveling to conquer the city of Aurocastro. As I always say, if you want to understand how Italy works, you should look carefully at a few movies. “Brancaleone alle crociate” is one of them. “Un borghese piccolo piccolo”, “Il marchese del Grillo” and “Amici miei” are the other movies.

First steps – Is it feasible?

I looked around for some documentation and reference design. The 6502 was designed by MOS Technology and launched in 1975. Sixteen bits address bits and eight bits data bits with a clock from 1 Mhz to 3 Mhz.

Building a computer with this microprocessor is challenging but not rocket science. Get the microprocessor, connect it to RAM and ROM, put a 6522 Versatile Interface Adapter in place, connect a keyboard and a display, and you are done. Ultimately, this is what Steve Jobs and Steve Wozniak did with the Apple 1. Nevertheless, this is definitely out of my capabilities in terms of electronics. I had to find a different way.

I researched and found that the 6502 microprocessor is still manufactured and sold. I checked online and found a modern version: Western Design Center W65C02. It is available in a 40-pin PDIP package that can easily fit on a breadboard. The most exciting thing was that this new version is a full static core, something the original MOS 6503 was not. This is definitely a big deal to me since I can stop the microprocessor clock at any time without losing the internal state. That’s absolutely cool. I can single-step machine code while running and look around internal data and status without compromising the operations of the microprocessor. It also supports a frequency of up to 14 Mhz.

This would be my next pet project.

I ordered the microprocessor for something less than ten dollars, and while waiting for the delivery, I started reading the Western Design Center W65C02 datasheet. It was a well-written document that gave me a clear idea of how to make it work.

The main issue remains. I don’t know enough about electronics to design a working circuit.

I was sitting in my studio, that sometimes turns into a lab. I was thinking about this when my eyes spotted an old Raspberry Pi Model 2B that I had just recovered from an aging Home Assistant experiment I did in the past before moving it to an Intel Nuc.

Wait! I am good at software, and the RPi has plenty of GPIO ports I can use. It has a decent amount of RAM and runs at 900 MHz.

I could use the RPi to simulate the hardware I could not design. I can read and write the address bus and the data bus, manage interrupts and non-maskable interrupts via software, simulate RAM and ROM, simulate hardware devices, and deal with all the other control signals of the W65C02 via software.

Using a 50-dollar device to run a 10-dollar machine is not the most convenient thing in the world, but it will be a lot of fun.

It could work! (Did you get the citation? Young Frankenstein, 1974)

First problem

I returned to the W65C02 datasheet to check how many GPIOs I needed.
Here’s the count:

• 16 bits for the Address Bus
• 8 bits for the Data Bus
• 1 bit for the PWM clock
• 8 bits for SOB, VPB, RDY, IRQB, NMIB, SYNC, RESB and BE
  Total: 33 bits. Unfortunately, the Raspberry Pi has only 26 GPIO pins.
  I had three MCP23017 16-bit I/O Expander breakout boards from a previous project. Using two of them, I could satisfy the project’s needs. The only problem is that the maximum speed of the MCP 23017 is 1.7 Mhz over the I2C interface. The Apple 1 was running at 1 MHz; there is no big issue here. I could also swap the 23017 with the 23S17, allowing a maximum speed of 10 MHz over the SPI interface.
  I must also consider the maximum speed of the I2C bus, plus the software overhead. Ok, this system is not going to be fast.

Wiring, finally.

The W650C02 has been delivered, and I can start putting some wires on the breadboard.
The first design I want to try is to wire the Address Bus, the Data Bus, the RWB pin, and the PHI2 clock.
The RDY, IRQB, NMIB, BE, SOB, and RESB will be forced high, connecting them to 3.3v from the RPi.
I also want some blinking LEDs to show me the content of the Address Bus and the Data Bus. I will use three 10 LEDs LED bars.
The result is a mess of wires, but it should work fine.

Software

Python is the language of choice. I could use the smbus2 library to interface with the microprocessor. C would be much faster, but speed will not be an absolute need for now.
Here’s the basic pseudo-code:

Init the GPIO pins
Init the MCP pins of MCP1 Bank A and Bank B
Init the MCP pins of MCP2 Bank A and Bank B

allocate 65536 bytes of memory and init it to 0x00
set location 0XFFFC to 0x00
set location 0XFFFD to 0x80
load program into memory at location 0x8000

reset W65C02

while true:
    read RWB pin
    read addressbus
    clock_rise
    if (RWB == 1) # Processor wants to READ
        read_data = memory[addressbus]
        write read_data to databus
    else # Processor wants to WRITE
        databus = read databus
        memory[addressbus] = databus
    clock_fall

This turned out in 200 lines of Python code.

Run

As you may have noticed from the pseudo-code, I am not using the RPi PWM clock. I wanted more control over what was happening.
Surprisingly, it worked after a few adjustments.
This is my first 6502 assembler program that I wrote to test Ababuc:

ROM_START     .equ $8000  

RESET_VECTOR  .equ $fffc  

        .org ROM_START   ; Origin address  

Start:  LDX #$00    ; Initialize X register to 0  
        STX $D000   ; Store the count at memory location 0x0D00  

Loop:   INX         ; Increment X register  
        STX $D000   ; Store the updated count  
        CPX #$01    ; Compare X to 0x01   
        BCC Loop    ; Branch back to Loop if X < 1  

        JMP Start   ; Start over  

        .org RESET_VECTOR
        .word $8000

I compiled it using the vasm6502_oldstyle assembler by running:
vasm6502_oldstyle -wdc02 -Fbin -dotdir count.s -L count.lst -o count.bin

If you run a “hexdump -C” on count.bin, this is what you get:

00000000  a2 00 8e 00 d0 e8 8e 00  d0 e0 01 90 f8 4c 00 80  |.............L..|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00007ff0  00 00 00 00 00 00 00 00  00 00 00 00 00 80        |..............|
00007ffe

The program to load into memory starting at 0x800 is then:
code = [0xa2, 0x00, 0x8e, 0x00, 0xd0, 0xe8, 0x8e, 0x00, 0xd0, 0xe0, 0x01, 0x90, 0xf8, 0x4c, 0x00, 0x80, 0x00]

Final considerations

It is not yet the case to post the Python code. It is rough and does not do all that is needed. I wanted proof of concept to check I was on the right path.
I will make the final design publicly available when it is finished.

For as long as I can remember, photography has been a deep-rooted passion of mine. The notion of capturing moments in time through the lens of a camera has always fascinated me. Back in the day, I even transformed my minuscule bathroom in my modest flat into a makeshift photo lab. I would spend hours there, meticulously developing black and white prints, experimenting with colors, and wrestling with chemicals to achieve the perfect image. Creating a truly dark environment in that cramped space was no easy feat, and the whole process was a labor of love. But now, with the advent of digital photography, things have become significantly more straightforward.

The thought of buying a camera had been on my mind for an eternity. Finally, I took the plunge. I acquired a second-hand Leica X2, a beautiful relic from Germany, which had first hit the market back in 2012. This compact wonder was equipped with a fixed 36mm F2.8 lens and a 16.2MP CMOS sensor, specs that might pale in comparison to the latest gadgets like the iPhone 15, boasting a whopping 48MP resolution. But to me, it was not about keeping up with the latest and greatest; it was about something deeper.

“Why a second-hand camera?” you might ask. Well, for one, I relished the idea of owning a piece of equipment that had a life before it landed in my hands. It felt like adopting a pet from a shelter, giving a forgotten treasure a new lease on life and sparing it from the fate of a landfill. It was my small contribution to the world of sustainability.

Secondly, affordability played a significant role in my choice. Leica had always held a special place in my heart, but its price tag had always remained elusive. While this second-hand camera wasn’t exactly a steal, it was a Leica, and that alone made it worth every penny.

And then, there was the thrill of the hunt. Scouring the internet for the best deal on used items, endlessly researching the perfect compromise between price, condition, and accessories – it was a game that I had missed dearly. Back when eBay was primarily a hub for second-hand goods, the hunt was even more exhilarating.

“But why not use your iPhone?” you might wonder. True, the iPhone boasts a nearly perfect camera, but it’s also part of a larger ecosystem filled with applications, notifications, messages, and emails. Distractions lurk around every corner, ready to pull you away from the pure act of photography. I craved a device that allowed me to focus solely on the art of image-making, to be fully present in the moment. For me, the ideal scenario meant switching off the phone entirely while capturing photographs.

Now, you might be wondering why I opted for a camera with a fixed 35mm lens. Well, I yearned for something small and lightweight, a camera that I could carry with me effortlessly in my backpack every day. My previous camera, a Canon EOS 7D Mark II, was a behemoth with a collection of lenses and filters, weighing as much as a refrigerator.

But more than that, I wanted a tool that would force me to think deeply about composition, framing, and the entire photographic process. If I needed to get closer to a subject, I wanted to physically move closer, not just rely on a zoom lens. I wanted to be fully engaged in the act of photography, to grapple with the limitations of the camera’s settings and behaviors. Point-and-shoot simply didn’t align with my artistic vision.

As I eagerly await the arrival of my Leica X2, which is currently making its way across Europe, I can’t help but wonder if this camera will truly work for me. Will it reignite my old passion for photography? Only time will tell, but one thing’s for certain: I’m itching to start using it and rediscover the world through its lens once again.

Let’s start from the beginning.
There will be some repetitions in this post. I have already written about Geremia, and this post summarizes the project itself.

The origins

I am an avid reader and love Marco Vichi as an author. The main character of Vichi’s books is a policeman named Franco Bordelli. In one of the novels, Bordelli receives a skull as a gift from the forensic pathologist he works with. The novel takes place in the 60s, and, at that time, it was not illegal to have a real human skull. Bordelli places the skull on one of the kitchen shelves, and in all subsequent novels, it is common to find him talking to the skull.
I found it an exciting idea, but I wanted to twist it. Let’s give some life back to the skull using modern technology.

Sourcing the skull

In 2023 it would be ridiculous to look for a real skull (I’m kidding if you ask yourself if I’m insane.) Amazon could help. I wanted an actual size skull with a moving jaw and enough space in the cranium to hold the electronics I was thinking of. It also had to be realistic. After some research, I bought an anatomic model of a skull (https://www.amazon.it/gp/product/B007S9ZES4/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1) When the skull arrived, it looked perfect. It looked real, had enough space for the electronic circuits, and had a movable jaw.

What should it do?

My idea was to build a notification device connected to my personal computer. The skull would play a choreography each time a notification should arrive. I was thinking about a basic choreography: open and close the jaw, blink two LEDs representing the eyes, and play a notification sentence with a creepy voice.

How could I accomplish that?

As soon as I started thinking about the idea, I realized an Arduino board would be perfect for this project. I could easily connect two LEDs to two ports of the Arduino board to drive the two LEDs, use another port to drive a servo motor and connect an MP3 player to play pre-recorded sentences.
I had an Arduino Leonardo and a servo motor I could try using.
I put together a breadboard circuit to test the basic idea.
In the first place, I wanted to test each segment of the choreography alone. Test the two LEDs, move to the test of the servo motor, and finally, test the MP3 player.
The first problems started to reach the surface:

• The skull jaw is tied to the cranium with a strong spring. When I tested the servo motor on the breadboard and simulated the spring tension, I quickly noticed that my servo motor was not enough. I had to buy another servo motor with high torque to be sure to be able to move the skull jaw. (https://www.amazon.it/gp/product/B09KZ8VTNB/ref=ppx_yo_dt_b_asin_title_o05_s01?ie=UTF8&psc=1)
• The new servo motor introduced a new problem. When the servo motor moved with a load attached to simulate the spring tension, the Arduino board randomly resets itself for no apparent reason. I understood that in electronics, there is never “no apparent reason.” The Arduino board was resetting because the servo motor was drawing too much current from the board that I was powering through the USB port. A quick search on the Arduino board instructed me to use an external power supply with a voltage regulator to transform voltage from 12V DC to 5V DC. Please note that I did not know electronics at all, apart from some basic notions from the past. I just copied a circuit from the internet and tested it on another breadboard with a multimeter.
• The Arduino board I used was not powerful enough to stream content from my PC, so I used an MP3 player instead. I found an extremely cheap MP3 player from China. The first component I received was refusing to work, and I could not understand why. I wired it as the manufacturer explained and used some Arduino test code from the manufacturer. No way, it always refused to work. I searched for the answer to the problem on Google and found out that there are non-working clones of these cheap devices, and I just got one of those. I bought an original DFPlayer Mini, and all the problems went away. (https://wiki.dfrobot.com/DFPlayer_Mini_SKU_DFR0299)
  The picture below will show the very first working breadboard.
  On the back, you will notice an oscilloscope. During these months, I got intrigued with electronics and hardware hacking. I borrowed the oscilloscope from a friend who was not using it anymore for another project, but that’s another story.

Building the Arduino shield

I planned to build an Arduino shield to snap on top of the Arduino Leonardo. The
The shield had to have LED connectors, the servo motor, and the MP3 player speakers. Again, this was the first time I had built something like this. I did not know how to solder, and I did not know anything about board routing. I bought some Arduino proto shield empty boards (https://www.amazon.it/gp/product/B093ZB5M1B/ref=ppx_yo_dt_b_asin_title_o02_s01?ie=UTF8&psc=1) and started the design. I confess I used Affinity Designer to draw the circuits. I know every electronic engineer out there will already be laughing loud.
I also gave a try to Kicad, but I failed miserably. The only thing I was able to accomplish was to draw the schematic of the circuit. Again, something I never did before. It may not be correct.
Ok, I will make you laugh again at me. Here is a picture of the schematic:

The idea was to draw the schematic on Kicad, design a proto-shield PCB and then get it printed by a service like PCBway or similar. Too much complicated for my brain. I confess I gave up on day two.
It took me four different iterations to get a working proto shield, but I was extremely satisfied when I saw that everything was working as expected.
Below is a picture of the proto-shield with all the devices connected and ready for testing:

The software

This was something I felt much more comfortable with.
The idea was simple. One application running on my PC polling services for potential notifications and communication with Geremia over a serial port connection. A simple machine state to take care of everything.
These were the basic requirements:

• I wanted to use Python as a programming language. Perfect for a quick and dirty project.
• Finally, I wanted a self-contained application that should not run from the command line. I did not wish to have a terminal window on my desktop. The perfect place would be an application sitting in the taskbar. The rumps Python library was up to the task (https://rumps.readthedocs.io/en/latest/). It also offers the option to create a standalone application, which I wanted.
  The software on Arduino was a different story. As you may know, Arduino is not multi-tasking or multi-thread. This was a huge problem to deal with because I wanted all of the choreography parts to play at the same time.
  We do not have multi-tasking or multi-threading, but we can simulate it. The protothreads Arduino library solved the problem (http://dunkels.com/adam/pt/).
  The Arduino application is made of a few threads:
• One thread will monitor the serial port and respond to commands from the PC.
• The servo motor thread will make the servo motor move when needed.
• The left LED and right LED threads will make the LEDs blink.
• The MP3 player thread will make the board play a sound when there is a notification.
• The DFPlayer thread will monitor the MP3 Player status to change the status to idle when an MP3 file has finished playing.
  In principle, it looked easy, but it needed a lot of tweaks since the protothreads library imposes many limitations.
  It took more time than expected.
  The final result is acceptable even if you have to pay the price regarding fluidity in the choreography.

Assembling

I had the proto-shield and the software ready. It was about time for the brain implant to Geremia.
The first issue is insufficient space for the new servo motor to fit in Geremia’s cranium. The original servo motor I planned to use was much smaller than the new one.
The only option I found was to place the servo moto on the base holding Geremia. Sounds good, but I need to find a way to keep it in place and ensure the servo motor torque will not move when there is action. I designed it and printed it on my FLSun Q5 3d printer. I never modeled anything in 3d. I installed Fusion 360 on my PC to do it. It is free for personal use.
I looked at a few tutorials on YouTube, and finally, I could print the servo motor base and holder. I was surprised by the power of technology. I could create something from scratch and have it on my desk in minutes with a few cheap things. Unbelievable.
Here are a few pictures of what I designed and a picture of the finished item.

I spent the following thirty minutes assembling everything in Geremia:

Final result

Here is a video of Geremia playing a notification for new mail.

What’s missing?

• I still need to fine-tune the software on Arduino and my PC.
• I need to place a heat sink on the LM7805 voltage regulator since running the servo motor tends to become quite hot.
• Hide the servo mounting base and bracket.

Final considerations

I started the project thinking it would be simple, but that was different. I had to solve various problems along the journey, which sometimes was difficult.
The great thing is that I have learned a lot during the process.
Finally, I made it, which is a great thing.

Yesterday I was looking at the Apple WWDC event, where they unveiled the Vision Pro.

During the event, I was thinking:

• There is not a single flat surface on the Vision Pro hardware. Everything is curved. I went to sleep with a prayer for the hardware engineers that will have to make the Vision Pro production ready. Best of luck, guys. As a side note, Apple will be unable to produce the headset at a very high volume.
• Apple said that they applied for more than 5000 patents for the Vision Pro. That’s an incredibly high amount. Only those companies with the economic power of Apple could sustain such an effort. We can count them on the fingers of one hand.
• Tim Cook, and his colleagues, never used the term Metaverse.
• The narration of the house where the Vision Pro was pictured left me bittersweet—big houses, high-quality interior design, extreme minimalism, and tidiness. I am looking around at my home right now, and it does look like what Apple was suggesting as the Vision Pro environment.
• 3.499 US dollars is costly.
• No sign of potential interaction between users wearing the Vision Pro. They showed how you would look like a human while interacting with other humans without the Vision Pro, but no idea of how it will behave when two people wear the hardware in the same room.
• Tim Cook said: “One more thing!”
• No mention of AI. Yeah, he talked about machine learning, but not in the context of interaction with a chat. 
• We must wait at least six months to see the device in stores. I hope they will try to eliminate the ugly external battery, even if it will be tough.
• I feel like it is like a technology showcase.
• Thinking about what they showed us, Apple imagine us using the device: on a chair, in front of a flat surface, on a plane seat, and while lying in bed.

While working in Geremia, the talking skull, I needed to find a simple MP3 player that I could drive from the Arduino Leonardo board. An MP3 player was the simplest solution. A device that is easy to operate via a virtual serial port and not expensive.

After some research, I ordered a couple of DFPlayer Mini for 3.07 US dollars each.

Truth said I destroyed both of them in the first two iterations of the Arduino Proto Shield. No big deal, they are not expensive. Since I wanted to progress in the project, I needed a few more devices as soon as possible. I looked on Amazon and found an offer to buy five for 8.4 US dollars. That price would make 1.68 US dollars for each unit. 

The courier delivered the package; I installed the unit on my proto shield and started playing with the software. You can use many libraries for this MP3 player with Arduino, and the logic is straightforward.

The device is very cheap, and it has limitations. You will have to name the files on the microSD card carefully, ensure there will be no other files apart from MP3 files, and (!!!!) load the files on the card in the same order of their naming.

After half an hour of tinkering, I could play MP3 files on the microSD card.

From a software standpoint, I needed to ensure that the finite-state machine on Arduino was keeping the state BUSY until the specific MP3 file had finished playing. I wrote another proto-thread to monitor the state of the BUSY pin on the DFPlayer Mini. The pin will be low if the player is busy doing something and high if the player is idle.

No way, it was not working at all. Erratic behavior every single time. I checked the wiring, the soldering, and the power levels, but I had yet to find a way to get through. I also connected the device to a logic analyzer to look at the behavior of that pin. I could not find a solution. I searched the net to see if someone else had the same problems and found a solution.

Someone wrote that there are DFPlayer Mini clones with many issues, some of which were similar to those I was experiencing on my device.

Now, wait! A clone for a five-dollar device?

Yes, that’s the case.

After downloading and installing a DFPlayer mini analyzer sketch for Arduino, I had confirmation that the device I was using was a clone. Many of the functionalities that an original device should have were not working on my device.

I had bought cheap clones of a cheap device.

Lesson learned: there will always be a clone hunting you.

Over the weekend, I made some significant progress with Geremia, my talking skull project. I was able to finish the print and assembly of the servo motor mounting bracket, and to my surprise, it worked perfectly. I attached the bracket to the back of the skull and used a short string to connect the servo arm to the jaw. The movement was smooth and responsive, even with the short lever.

One minor issue I need to address is finding a reliable way to make this connection in the final assembly. However, I’m confident that this is a problem I can solve quickly.

After finishing up with the hardware, I returned to the software side of the project. I have been working with two finite-state machines, with one running on the Arduino Leonardo and the other on my MacBook. The PC software is written in Python and communicates with the Arduino board via a serial connection.

The PC software monitors Geremia’s health at specific intervals and checks for new events to be notified via the talking skull. When there is a new notification, the software sends the notification over the serial port to Geremia, which then takes the appropriate action. This includes flashing the two LEDs, moving the skull jaw, and playing an MP3 file specific to the notification type.

The challenge with this setup is that everything needs to run in parallel to make the action appear natural. Unfortunately, Arduino does not support multitasking or multithreading, given the limited hardware resources available. However, there is a solution available – I imported the protothreads library, which simulates multithreading via software.

Modifying my source code to incorporate protothreads was not a significant challenge, although there are a few things to be careful about. For example, you cannot declare local variables in protothreads, so you need to use global variables or static variables inside the proto-thread. Additionally, it’s essential to avoid synchronous functions inside the proto-thread, like using the delay() function. Instead, you need to use PT_SLEEP(), which is part of protothreads.

I have five proto-threads in my application, which include one for the left LED, one for the right LED, one for the servo motor, one for the MP3 player, and one for the serial communication. It’s exciting to see how Geremia’s brain has evolved to be multitasking, even though it wasn’t originally designed to be.

I still need to perform some more testing on the finite-state machines to ensure everything is working as expected. Nonetheless, I’m thrilled with the progress I’ve made so far and can’t wait to see what else I can accomplish with Geremia.

While I was working at the proto-shield development for Geremia, I found myself getting more and more interested in electronics. At the very same time, I found intriguing the intersection between hardware and security.

It was about time to give it a try. 

While trying to sort out the clutter in my drawers, I found an extremely old Netgear WNCE3001 WiFi repeater. It is more than five years old and no longer helpful. What about trying to tear it apart and play with it?

I took it to my desk and started to remove the plastics. That was easy since I had an iFixit kit. I ended up with the motherboard, and a quick inspection revealed that an RTL8196C-GR Realtek microprocessor powered the device and that a nice MX25L3206E CMOS flash was on the other side of the motherboard.

A deeper inspection of the motherboard revealed six pins without any text on the motherboard. Those may have been a JTAG or UART connection.

I picked up my multimeter, powered up the device, and measured the voltage from those pins. I quickly found the ground pin and noticed a varying voltage from another pin. That started to look like a serial interface.

A few months ago, I picked up a second oscilloscope for a little bit more than a hundred bucks and connected one probe to those two pins. After a few seconds of looking at the screen, it was obvious that it was a serial connection.

A few calculations from the scope measurements and I found out it was a 38400 bps serial connection. I connected those two pins to a USB TTL-UART converter and fired up a serial terminal on my Mac. I could quickly look at the boot sequence on my PC screen. A few minutes later, I found the RX pin on the device, and I have a working serial connection between the repeater and my pc.

It was interesting to notice that the boot sequence ended with my terminal in a working shell with root privileges.

I now have a root shell on a Linux box.

I looked around the file system and closely at the boot sequence. In a few minutes, I found my WPA2 key in plain text. 

Even if I knew nothing about hardware hacking and electronics, that was extremely easy to find.

I also wanted to explore the CMOS Flash, trying to dump its content. I had a Buspirate lying around and used it to dump the firmware. The SPI protocol is relatively easy to understand, but, in this case, you don’t need to know it since the Flashrom utility deals with it for you.

I could not read the flash chip while it was on the motherboard. I had to desolder it. No big deal; I would trash the device at the end of the experiment.

After the memory dump, I used binwalk to extract the files from the dump file.

No more exciting things to do with this device.

I could not define this device as the most secure one out there.

Maybe the next time I could try to get one of those cheap security cameras and look at what’s in there.

During the last weekend, I made some steps towards the realization of my talking skull, Geremia.

I completed the client ad server application that will drive the skull. A straightforward state machine that will poll different resources on the Internet and that will notify the Arduino board sitting in the skull to perform actions related to the notification (i.e., blink the LEDs that play the role of eyes, play an MP3 file to simulate speech and activate the servo motor to make the skull jaw move.) The server and the client are connected over a simple RS232 interface.

That was a couple of hours of coding.

It was about time to figure out how to install all of this stuff into the skull. There is enough space to host the Arduino board and the proto shield I assembled. Unfortunately, I could not fit the servo motor, no matter what I tried. There needs to be more space, and giving the servo motor a stable installation would be challenging. I used a DM996 servo motor because the spring holding the jaw is pretty strong, and I needed something with high torque. This is also why I had to implement a voltage regulator circuit on the proto shield while dealing with the Arduino 12 Volt external power supply, but this is another story. 

My first thought was to abandon the moving jaw feature of Geremia. Thinking about it, I realized that it was the coolest feature of the skull, and I didn’t want to drop it simply because I could not find a viable solution. This is when you feel sad because you can’t resort to your father, that was a remarkable mechanical engineer. We could have had some great fun working on this. Again, this is another story.

I started thinking about a possible solution. After some time, I found that the only solution was to host the servo outside the skull, anchored to the skull base.

I grabbed my Remarkable and started drawing, not like a mechanical engineer but more or less like a first grader. After some time, I thought I had a solution. The servo motor would be visible behind the skull, but I can cover it with something. Geremia would look very cool with a fancy scarf.

I have my design ready, but how can I build it? I found that Fusion 360 is free for personal use. I have never used any 3D modeling software in my entire life. I downloaded it and installed it on my Mac. I grabbed a caliper I bought in China decades ago and started to make measurements on the servo motor and the skull base. I added the relevant quotes to my terrible drawing and was ready to model it on Fusion 360. It was mostly made of boxes with four holes to anchor the servo motor.

I viewed a couple of tutorials on YouTube on how to use Fusion 360, and a couple of hours later, I had my design ready.

I saved the file and opened it with Ultimaker Cura to print it on my FLSun Q5 3D printer. I adjusted a few parameters to strengthen the object and launched the print. Sunday morning, the print was finished. I need a few screws and nuts, and I will be able to assemble them with the servo.

While I was having lunch, I was thinking about what I did, and I was surprised. It is incredible what you can do with technology today. Knowledge is available to everyone with an internet connection. Twenty-four hours before, I didn’t know anything about 3D design, and now I have something I designed sitting on my desk. 

This is highly fascinating, at least to me.

I have been very quiet in the last few months—too many things on my desk and too little time to manage them.

Nevertheless, I have made some progress on Geremia, my talking skull.

I have finally assembled a working Arduino Proto Shield to be placed on top of an Arduino Leonardo.

It has not been an easy journey. As I could have imagined, electronics is complex, at least for me. I had to learn many things before putting my hands on the soldering iron.

To name a few, voltage regulators, SPI protocol, power, and ground rails.

I have spent much of my free time learning and am happy with my achievements. Connecting my proto shield to the Arduino Leonardo, uploading my test sketch, and seeing the lights turn on, the servo motor spinning, and MiniDF Player play mp3 files have been an emotion.

From my point of view, software is much easier than hardware. I made at least five tries while building the proto-shield. I understood that trace routing is a fine art in electronics. 

It has been fascinating, though. So fascinating that I ended up with hardware hacking as yet another personal project. I have been messing around with an extremely old wireless repeater. With a few bucks, I bought the necessary hardware and started playing. Extremely fun. Finding the UART and JTAG connection and connecting those to my PC with microprobes was quite fun.

Getting a root prompt from an embedded device is fascinating. I also found out how much insecure these devices are. In a few minutes, and without breaking the device, I got my WiFi WPA2 password.

That said, I have to move to the next step for Geremia. Writing the software. This will be fun, and I feel very comfortable with this. A mix of Arduino code and Python to make Geremia and my PC talk over a serial port.

Hopefully, it will not take a lot of time.

The final step is going to be complicated. Placing the two boards, the eyes, and the speaker, in the skull will be easy. Hosting the servo motor and efficiently connecting it to the jaw will be different. I will design something in Fusion 360 and 3d print it on my FLSun Q5 3D printer.

Anyway, as with everything else, electronics is hard if you don’t know anything about it.

I have always been a great fan of Marco Vichi’s novels. The main character, commissario Bordelli, is intriguing. In one of the last novels, Dr. Diotivede, a pathologist, gives a human skull to Bordelli as a Christmas gift. The skull is then named Geremia and lives in commissario Bordelli’s kitchen. Ok, a little bit weird, I agree.

I could not resist doing the same, so I headed to Amazon and treated myself to a full-sized skull to keep on my desk as a headphone holder. Same name, Geremia.

A couple of weeks ago, I looked at Geremia and said to him, “Hey, you look dead. We should do something about that.”

Since we are in 2023, adding a couple of LEDs for his eyes, an mp3 player to make him speak, and a servo motor to make his jaw move according to the audio file played would be easy. I played a bit with Arduino in the past, which would be the perfect choice for this kind of project. I reached into my drawers and took out everything I already had. I used circuit.io to design the electronic circuit and wrote a state machine on Arduino Sketchin to make Geremia talk with my PC over a serial port. The idea is to use Geremia for notifications.

And then it started. The circuit worked perfectly on the simulator, but I was missing a voltage regulator, a few capacitors and resistors, a good servo powerful enough to move the jaw, and a prototyping board… It started. I have spent too much money on Amazon in the past few weeks to gather all the needed pieces. Now the prototype is sitting on my desk, working.

I will transfer the prototype to an Arduino Proto Board in the next few days. But, wait, I do not have a soldering station… buy one… Well, you get the point; I could not stop.

In the meantime, I browsed YouTube to get some knowledge of electronics. I found a guy who built a 4 bit computer completely on breadboards. I already know which is going to be my next personal project. For the time being, I am having fun reading “Digital Computer Electronics,” which talks just about that.

It is quite funny, but the reality is that it is incredible to realize that social media is not free anymore.

Twitter wants eight bucks a month to let me use MFA and other features that will give me the famous “blue check.”

Facebook and Instagram want twelve bucks a month to give me the “blue check” and more visibility for my posts.

So, at the end of the day, they want all of my personal data and my money as well.

The Internet is becoming a wild place.

I found myself in the position of writing a small command line Python tool for one of my colleagues. Something pretty simple. Get a contacts list from a Google Sheet and create Lead objects on Salesforce. 

Easy stuff. It should not require more than a couple of hours, testing included.

I decide to take a test with this.

I would not write a single line of code.

I describe every single function in the application as a comment and let GitHub CoPilot do the coding for me.

Well, It took twenty minutes to have the application up and running—a few tweaks here and there, mostly on prompts and error messages.

The exciting thing is that those functions are written using my programming style. Honestly, I would have written those functions in the same way. It must be said that GitHub CoPilot has access to all of my private repositories, most of them coded with Python, so it is pretty easy to guess my (not so pythonic) programming style.

I was browsing our Slack channel this morning. I entered one of those and found a reference to useGalileo.ai. 

The basic idea of this service is to write a sentence that describes the UI design you need, and it will provide you with a complete UI design that you can edit later in Figma. 

I guess that out of the box, you could think: “The designer job is going to die!”

Read the previous sentence carefully. There is a verb: think. 

That’s the key.

The most important responsibility of a designer is to think, not to build a nice-looking UI design. That’s the last part of any project, like 10% of the total work. It is pure execution. Be careful; I am not talking about the design language you will use in your UI design. I am talking about asset production.

If there is something that, in a more or less smart way, can cut off production time, that’s welcome. I would be keen to pay for it. 

The reality is that the designer’s work is being able to write that sentence. And that’s where the talent resides. And the money too 😉