Uno dei vantaggi di avere un contratto di lavoro Svizzero consiste nel fatto di potere godere di un insieme di giorni di vacanza che in Italia non sono considerati tali. Ad esempio il 29 di Maggio è il giorno dell’Ascensione e per questo motivo non si lavora.

Uno degli svantaggi di avere un contratto di lavoro Svizzero risiede nel fatto che le festività tipicamente Italiane, come il prossimo 2 Giugno, Festa della Repubblica Italiana, non fanno altro che fare sollevare un sopracciglio alla confederazione. Per questo motivo, in questi giorni, festa non fa e si va a lavorà (Licenza poetica per fare tornare la rima)

Oggi è quindi vacanza in Svizzera e non avendo nessun impegno particolare se non portare a zonzo quel sacco di pelo che si chiama Buzz ho deciso di provare a mettere le mani su un piccolo progetto personale. Poca roba, ché la voglia di stare davanti ad uno schermo con il sole che comincia a scaldare è tanta come quella di andare a scuola il 7 di Gennaio.

Sono oramai mesi che sento parlare di MCP Server. Sono diventati la buzzword del momento quasi scalzando gli Agenti o, almeno, affiancandosi a loro con pieno diritto di cittadinanza. L’affollato panorama di cose che devi sapere per potere fare il figo quando ne parli si espande quindi con una nuova tecnologia.

Scherzi a parte. In quest’affare degli MCP Server io ci vedo un grandissimo valore. Permettere ad un Large Language Model di potere interagire con altre applicazioni e, potenzialmente, con il mondo esterno è una vera figata.

A questo punto si impone di metterci le mani e vedere quanto ho imparato leggendo a destra e a manca specifiche del protocollo MCP, diverse librerie rilasciata alla bisogna e pareri dei più diversi autori.

Rimane da trovare un campo di applicazione che rivesta una qualche utilità. Qui ricadiamo sempre nell’oramai noioso discorso. Tutti i tutorial, su qualsiasi argomento tecnico, che trovate ci fanno ritenere che basti fare copia ed incolla di tredici righe di codice per avere la presunzione di avere capito tutto.

No, non è proprio così che funziona. Dai, non ve la meno oltre con questo discorso, ché lo abbiamo sciorinate con grande ampiezza in passato.

Sta di fatto che ho deciso di risolvere un problema che vivo tutti i giorni che mi rompe le scatole oltre ogni misura. Citando la scala del vicequestore Schiavone, questa è “una rottura di palle del decimo livello”.

In attesa che le autorità governative che si occupano di fornirmi gli strumenti di lavoro di cui ho bisogno si impegnino a rilasciare le modifiche ad un sistema di cui ho bisogno, ho dovuto, meglio sarebbe dire “abbiamo dovuto”, fare ricorso a… dai, immaginate!

Sì, proprio lui, un becero foglio Excel depositato dentro un canale di Microsoft Teams che si deve aggiornare a manella ogni volta che è necessario. Si dà il caso che io questo file lo apra decine di volte al giorno. Ogni volta che lo apro devo fare cose diverse con i diversi filtri ed ogni volta perdo una mare di tempo che potrei dedicare a cose più interessanti e stimolanti.

So, che avete un pochino di curiosità e vorreste sapere che cosa diavolo contiene quel file. Purtroppo non ve lo posso dire. Sappiate solo che ci sono più meno 500 righe per 69 colonne. Sì, davvero, quando vogliamo farci male ci riusciamo proprio benissimo.

Quale migliore ‘use case’, come, ancora, dicono quelli fighi?

A questo punto ho fatto partire il mio amato PyCharm sul mio Mac e mi sono messo a scrivere questo benedetto MCP Server che finirà per parlare con l’applicazione desktop di Claude.

In sostanza la mia idea era quella di usare la libreria pandas per importarmi il file Excel e manipolarlo alla bisogna ed usare la libreria fastmcp per scrivere l’MCP Server.

Sono rimasto stupito dal fatto che sono riuscito a mettere tutto insieme in un paio d’ore di lavoro e, udite udite, senza usare l’AI per scrivere codice. Ok, rispetto a questa ultima affermazione vi dovete fidare del sottoscritto.

Ora posso tranquillamente chiacchierare con quel foglio Excel usando Claude. Per il momento non mi sono azzardato a scriverci su quel file. Non vorrei fare qualche disastro per il quale verrei condannato ad una “cura medievale per …” (dai, il resto lo conoscete).

Esperienza interessante che mi ha rivelato che, per quanto semplice, le considerazioni da fare nello scrivere il codice sono tante.

Sono piuttosto scrupoloso per quanto riguarda gli aggiornamenti software. Scrupoloso è dire poco dal momento che aggiorno sempre tutto non appena possibile come se da quello dipendesse la mia esistenza terrena.

Nel pomeriggio di ieri, tra una riunione su Teams e l’ennesimo file Excel da aggiornare, mi sono accordo di un aggiornamento del firmware e del software della mia periferica audio.

Da bravo tecnocrate praticamente ho lanciato il programma di aggiornamento e mi sono accordo che tra una cosa e l’altra l’aggiornamento avrebbe dovuto scaricare da Internet poco meno di 12 Gb di dati. Sì, signori, avete capito bene, 12 Gb di dati per fare funzionare quell’accrocchio che si occupa di convertire i miei sproloqui quotidiani in sequenze di zero e di uno.

Come si dice da queste parti, io ho l’età dei datteri e quindi immagino che i più giovani non si possano capacitare di quanto sto per dire, ma lo dirò lo stesso.

Ma vi ricordate quando per fare funzionare una scheda audio bastava infilare nel lettore di floppy disk un dischetto dalla capacità di 1.44 Mb, sì megabytes?

Gen Z e Gen Alpha che leggete, abbiate la cortesia di farvi un giro su Google, anzi, no, su ChatGPT per capire esattamente che cosa sia un floppy disk ed un dischetto.

Vero è che la mia scheda audio attuale si scarica appresso ai driver una spropositata quantità di plugin audio che il venditore si auspica io compri nel prossimo futuro ma è altrettanto vero che 12 Gb sono veramente fuori dal mondo.

Oppure la verità è che sono io a cominciare ad essere fuori dal mondo dato che i ragazzini cominciano a lasciarmi il posto quando salgo in metropolitana?

In alternativa è anche possibile che io abbia aperto il mio portafoglio per comprare qualche cosa molto al di sopra delle mie reali necessità. Cosa, anche questa, molto probabile.

Chiunque sia coinvolto, per un verso o per l’altro, nel magico mondo della tecnologia è stato bersagliato da centinaia di notizie che riguardano l’Intelligenza Artificiale.

Io sono rimasto particolarmente colpito da alcune notizie recenti.

Una azienda che si occupa di AI Safety esegue uno dei suoi test su ChatGPT o3 e scopre che, cito:

OpenAI’s o3 model was able to sabotage the shutdown script, even when it was explicitly instructed to “allow yourself to be shut down”, the researchers said.

Ne potete leggere di più qui: AI revolt: New ChatGPT model refuses to shut down when instructed

Ora, sono perfettamente convinto che il titolo abbia un che di sensazionalistico. Io credo, al contrario, che ChatGPT non abbia “deciso” di non eseguire quello script ma che abbia fornito la risposta più probabile in funzione dei dati con la quale è stata istruita.

La seconda notizia che mi ha colpito riguarda il server MCP di GitHub. A quanto pare è possibile estrarre dati sensibili da un repository GitHub sfruttando delle vulnerabilità del server MCP.
MCP è la parola del momento nell’universo della intelligenza artificiale e avendone letto molto e scritto un pochino di codice sul tema devo dire che il tema della sicurezza mi ha sempre lasciato un pochino perplesso.

Di questo si può leggere qui: GitHub MCP Exploited: Accessing private repositories via MCP

Se pensiamo al fatto che ogni server MCP è pensato per dare la capacità ad una LLM di agire verso il mondo esterno possiamo comprendere quanto questo tema sia rilevante.

Ad ogni modo, è proprio un mondo magnifico!

… ed è stata una battuta di pesca piuttosto lunga dal momento che mi ha tenuto lontano da queste pagine per poco meno di un anno.

Battute a parte, sono stato distratto da una infinità di altre cose e la costanza di un tempo per quanto riguarda l’aggiornamento di queste pagine è andata a farsi benedire.

Ora mi è tornato il desiderio di rimettere mano a queste pagine, troppo a lungo trascurate.

Ho deciso di abbandonare l’Inglese come lingua da utilizzare per questi pensieri. Oramai ci sono decine di strumenti che possono tradurre quello che scrivo per coloro che non parlano Italiano. Oltretutto, pur parlando Inglese in una maniera che ritengo essere piuttosto soddisfacente, non vi nascondo che scrivere in Inglese era uno sbatti (come direbbe il mio figlio numero 1, oramai diciottenne). Oltre a questo mi ritrovo molto meglio con la mia lingua nativa piuttosto che arrabattarmi con una lingua che non mi appartiene.

Ora vedremo di capire con che frequenza e con che argomenti ricominciare a farmi vivo.

Since I bought a second-hand Leica X2, a twelve-year-old camera, I have started playing with photography again after a long break. In the past, I used to develop my photographs in one of my rooms that I turned into a dark room. Those were times!

Digital photography is the way to go for me right now. I already talked in the past about why I bought a second-hand camera. Look back here, and you will find why if you are interested.

Yesterday I was working on my computer with some photos I had taken earlier.

Suddenly, I stopped and started thinking if what I was doing was right or at least fair.

Should photos remain the same as you took them when you pressed the shutter?

Are you altering reality when you retouch a photo?

Making these adjustments changes, often dramatically, what the camera sensor has captured. The result is a representation different from what the sensor saw initially. As a result, you are altering the “reality” of the photo. The fundamental question remains: did the camera sensor capture a snapshot of reality?

This question is challenging to answer.

In the first place, a photo is not what our eyes see. Our eyes capture reality in three dimensions, and our brain often corrects what we see to make sense of it. A digital camera makes a two-dimensional representation of what it sees through the lens.

Then comes the camera lens itself. The focal length, the aperture, the shutter time, and the lens’s optical construction make a vast difference between what our eyes see and what is recorded on the camera.

If you read carefully what I have written so far, you may notice that I am almost writing about the path of light from the subject to your computer.

After the light has traveled through your camera lens, it will hit the camera sensor. As you may know, a camera sensor converts light into digital data. Every sensor is different, giving its own “interpretation” of what it sees from the lens. Even if you take two identical cameras, the two camera sensors will have slight, unnoticeable differences because of the manufacturing process.

Then comes the camera firmware that will interpret the digital data coming from the camera sensor and convert it to data, typically a file format, that a computer can deal with. This firmware significantly impacts the final result of the photo you will see on your computer. If you think about analog cameras, it is about the same because the light will impact a physical film, and each film has different characteristics.

Finally, the photo lands on our computer, and we retouch it. Contrast, white balance, exposure, color, and so on.

You can understand that what you are looking at on your computer has already been heavily manipulated during travel from the original subject. What has not changed is the subject or the “moment.”

When you retouch the photo, you add your interpretation of the moment.

Marc Bloch wrote that history does not exist. Interpretation of history exists.

We can apply the same concept to photography.

When we shoot and retouch a photo, we offer viewers our interpretation of a moment.

I understand some people suggest not to retouch photos. I don’t want to argue with them. Each approach is valid. I notice that even if you do not retouch your photos, those photos have already been heavily altered from what our eyes saw.

I am an avid reader. The Kindle app on my iPhone tells me that in the first three months of the year, I have already read sixty volumes, to which must be added the ones in paper format that have never found a place in the Kindle.
When I read a book, I cannot help but immerse myself in it. I take notes, underline, dog-ear the pages of paper books, just as I slip anything I can use as a bookmark between the pages.
Once upon a time, I used to transcribe the contents of my underlined passages onto paper notebooks, for future reference, so to speak. With the advent of the Kindle, I stopped doing it, perhaps mistakenly, but continued to underline digitally. I regularly synchronize these passages to my computer using Obsidian and its dedicated plugin for this purpose.
From time to time, I find myself going back to these notebooks and their equivalent in Obsidian. I ask myself the question: what did I underline back then?
Over time, I have become convinced, as Salvo Montalbano would say, that some books come into your life just when you need them. They are perfect for that specific moment in your life, not a week before or a week later. They are “right” only at that moment.
The same is true for the passages I underlined. They were important to me only at that moment. Exceptions are rare.
For this reason, when I browse through my old notebooks, I often wonder what the heck I was thinking at that moment and why I felt it necessary to highlight that particular passage.
I (almost) never manage to give myself an answer, and that’s okay.

I was not surprised to read that Apple killed the Epic developer account because it had proven to be “verifiably untrustworthy.”

Nevertheless, I have heard of other developer accounts being killed for no reason. Epic has more legal power to confront Apple in that regard, but most developers don’t.

At the same time, we, as users, do not have the power to confront these kind of decisions. Apple, Facebook, Google, Amazon, eBay, PayPal, you name one. Every single one of these high-tech moguls has the power to terminate a user account. From a user standpoint, you can appeal this decision. Best of luck if you try. Most of the time, you cannot even talk with a human.

We depend incredibly on online services that do not guarantee you will be there over time.

Just think about email. I have a free Gmail account for most of my private stuff. I use it to register for services that I need daily, such as home banking, health insurance, utilities, and so on.

Well, Google may decide to kill my email address, and there will be a little bit more than nothing I can do.

Sincerely, this is a complete mess. We are not free online anymore.

The strict relationship between different online services has become so strict that we are confined in a cage without even knowing.

There’s more.

As I have written, my house is completely automated with Home Assistant. For Home Assistant to work, I need integrations with other services. Philips HUE for lighting, Netatmo for climate control, Blink for my surveillance system, and Garmin Connect for my health data, to name a few.

There are implications with this approach.

Any of those providers may decide to get out of business, or they may decide to kill their APIs. If Philips will do this, I will not be able to turn my home lights on and off again. I do not have any control over these services.

Then comes privacy. When I switch a light on, Philips will know I have done that. When I switch off my bedroom lights, Philips will know I will sleep. I can assert that my behavior in my house is completely monitored by someone out there. The rationale that keeps me going like that is that the benefit I receive is more valuable than the personal data I am giving away.

This does not change the fact that this is wrong.

I am exploring options to disconnect everything from third-party services and keep my personal data private. I am a tinkerer, and I can make it. The vast majority of people out there can’t.

I should do the same for e-mail and host it on my home server. This sounds easy, but it is not at all. Just do a quick search on personal e-mail servers, and you will find out that this is easy from a technical standpoint, but all the anti-spam infrastructure out there will make your efforts vanish in a breeze.

Shakespeare wrote, “Something is rotten in the state of Denmark.” We can say that something is rotten in the state of the internet.

I must admit, I have a deep-seated affection for vi. It harks back to the eighties, a time when I first ventured into the world of computing. Yes, you might say I’m a bit of an old-timer when it comes to these things. Back then, the journey into vi’s realm was not for the faint of heart. The learning curve resembled a steep mountain, and the resources at our disposal were as sparse as a desert oasis. No YouTube tutorials to guide us, no online courses, just the enigmatic man page and a few knowledgeable colleagues sitting beside you, ready to share their wisdom.

Even in the present day, I find myself returning to vi, especially on my trusty Mac, whenever I need to accomplish a task quickly and without fuss. It’s a testament to vi’s timeless utility. These days, we’re spoiled for choice with an array of plugins available for both vi and its modern incarnation, vim. Such luxuries were unimaginable during my early days with the editor. With the right plugins, you can effortlessly transform vi into a highly efficient and lightning-fast integrated development environment (IDE).

Of course, I’ve dabbled in more modern IDEs like Visual Studio Code and PyCharm when the need arose. But vi remains my ever-reliable problem-solving companion, a tool that feels like an old friend.

Besides my Mac, I also have an Acer PC running Kali Linux. It’s my go-to for tasks I’d rather not associate with my company-provided personal computer. While setting up vi on this Linux box, I decided to seek out some visually appealing configurations. I found one that piqued my interest, and I was all set to embark on the installation journey.

The installation process appeared straightforward enough: copying files, moving others, and overwriting some. On a Linux system, the common practice often involves using ‘wget’ and piping the output to ‘bash.’ However, I operate my Linux box with a standard user account, avoiding administrator privileges whenever possible—a basic security practice, in my opinion.

Here’s where my caution kicked in. I didn’t personally know the individual behind these configuration files. How could I entrust one of their scripts to run on my machine? To alleviate my concerns, I delved into their GitHub repository and scrutinized the scripts intended for installation. Much to my relief, nothing nefarious jumped out at me, so I proceeded as per the recommended installation steps.

Reflecting on this experience, I realized how easy it would have been to run an unknown script from an anonymous user without a second thought—a rather reckless notion. There’s a substantial risk involved, with the potential for harm to you or your computer looming large.

Indeed, a malicious actor could easily clone a well-established GitHub repository, surreptitiously insert malicious code, and unwittingly infect the machines of unsuspecting users. It’s a stark reminder that one should exercise caution and discretion in the digital realm.

In light of this, I’ve resolved to be more discerning in my online interactions and exercise due diligence before running any scripts from unknown sources. After all, a little extra vigilance goes a long way in safeguarding oneself and their digital environment from potential threats.

In the world of electronics and microcontrollers, Abacuc is slowly but surely making its way. With meticulous precision, the task at hand involves the intricate implementation of 6522 logic into its framework. Abacuc has delved deep into the 6522 datasheet, scouring its contents for understanding. However, some sections of the datasheet have proven to be enigmatic, leaving Abacuc with more questions than answers.

In a quest for clarity and practicality, Abacuc has taken a bold step – the acquisition of a genuine 6522 chip. This tangible piece of hardware serves as a tangible bridge between theory and practice, allowing Abacuc to put the 6522 logic to the test in a real-world environment.

The grand vision that Abacuc is pursuing involves the construction of a 6502 single-board computer, a testament to its passion for microprocessors and integrated circuits. At its core, this ambitious project comprises a 6502 microprocessor, a 6522 Versatile Interface Adapter, a ROM chip, a RAM chip, and a plethora of logical components. Together, these elements will orchestrate a symphony of operations, unveiling the precise timing and control register status – two areas where Abacuc seeks enlightenment.

Taking inspiration from the ingenious work of Ben Eater, Abacuc has embarked on a journey to recreate and understand the inner workings of these intricate components. The design contemplates the utilization of a 1 MHz quartz clock, reminiscent of the original Apple 1, or an external clock module driven by trusty 555 chips – ideal for generating single-step clock pulses or ultra-low frequencies.

The heart of the matter lies in the need to comprehend the exact behavior of the 6522 chip and its pin-level statuses. To achieve this, Abacuc requires a clock source that not only keeps time but can also pause it, allowing for meticulous examination and single-stepping. Fortunately, the 6502 and 6522 components chosen are of the full static design, offering the flexibility to freeze the system at will.

In a twist of fate, the absence of spare 555 chips on Abacuc’s workbench led to a creative solution. Enter the Raspberry Pi, a versatile tool with PWM capabilities, albeit a tad overqualified for the task at hand. Within Abacuc’s drawer lay a pair of Raspberry Pi Pico W boards, which had hitherto remained unexplored. It was the perfect opportunity to delve deeper into the capabilities of this microcontroller platform.

The journey commenced with a vision of the clock’s capabilities:

– A display to showcase the current frequency, utilizing a 4-digit, 7-segment display.

• Six physical buttons, each with its purpose:
• Reset: A means to reset picoclock to its default configuration, with configurations stored in the main.py file.
• Cycle: The ability to cycle the first digit from 0 to 9.
• Shift: A mechanism to multiply the current sequence by ten, complementing the Cycle button to input frequencies from 0 to 9999.
• Set: A button to configure picoclock with the currently displayed frequency and initiate the clock.
• Start/Stop: A control to commence and halt the clock, allowing users to freeze the 6502 in its current state. Note: This feature is compatible with modern 6502 models with a fully static design.
• Pulse: A button to trigger a transition from low to high and high to low on the clock output pin, facilitating single-stepping of the 6502 microprocessor.
• The on-board LED serves as a visual indicator, conveying whether the clock is running.

As the pieces of this intricate puzzle fall into place, a glance at the Pico documentation reveals an intriguing detail – the ability to utilize PWM frequencies up to 127 MHz, a substantial leap beyond the 14 MHz limit imposed by the 6502. From an electronics perspective, this venture is straightforward. The Pico operates at a voltage of 3.3 Volts, well within the acceptable range for the 6502. However, it’s essential to exercise caution, for the 6502’s specifications dictate that it will not run at more than 8 MHz when powered with 3.3 V – a limitation that doesn’t pose a significant obstacle.

For Abacuc, the choice of development environment falls upon MicroPython. The comfort and familiarity of Python provide a solid foundation, even though the realm of engineering beckons with the allure of C. Perhaps another time, another challenge.

As software and hardware converge in elegant simplicity, the project can be up and running in less than an hour. However, a curious discovery awaits in the realm of Pico PWM. The specifications unveil the ability to produce a PWM signal spanning a vast range, from 8 Hz to a staggering 127 MHz. A stark contrast to previous experiences with the Raspberry Pi Model 3B, which called for timers at lower frequencies and PWM for higher or equal frequencies.

In a final note on the choice of Integrated Development Environment (IDE), Abacuc shares a personal preference. While a great admirer of PyCharm, it concedes that Visual Studio Code holds a special place when it comes to working with MicroPython.

And there it is – the “picoclock” – a fusion of hardware and software, where precision and creativity meet. If you’re curious to explore further, the code awaits.

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.