The General Instruments AY-3-8910 was a quite popular Programmable Sound Generator (PSG) that saw itself used in a wide variety of systems, including Apple II soundcards such as the Mockingboard and various arcade systems. In addition to the Yamaha variants (e.g. YM2149), two cut-down were created by GI: these being the AY-3-8912 and the AY-3-8913, which should have been differentiated only by the number of GPIO banks broken out in the IC package (one or zero, respectively). However, research by [fenarinarsa] and others have shown that the AY-3-8913 variant has some actual hardware issues as a PSG.

With only 24 pins, the AY-3-8913 is significantly easier to integrate than the 40-pin AY-3-8910, at the cost of the (rarely used) GPIO functionality, but as it turns out with a few gotchas in terms of timing and register access. Although the Mockingboard originally used the AY-3-8910, latter revisions would use two AY-3-8913 instead, including the MS revision that was the Mac version of the Mindscape Music Board for IBM PCs.

The first hint that something was off with the AY-3-8913 came when [fenarinarsa] was experimenting with effect composition on an Apple II and noticed very poor sound quality, as demonstrated in an example comparison video (also embedded below). The issue was very pronounced in bass envelopes, with an oscilloscope capture showing a very distorted output compared to a YM2149. As for why this was not noticed decades ago can likely be explained by that the current chiptune scene is pushing the hardware in very different ways than back then.

As for potential solutions, the [French Touch] project has created an adapter to allow an AY-3-8910 (or YM2149) to be used in place of an AY-3-8913.

Top image: Revision D PCB of Mockingboard with GI AY-3-8913 PSGs.

youtube.com/embed/_qslugOY2Dw?…

hackaday.com/2025/04/15/someth…

If we asked you to name Alexander Graham Bell’s greatest invention, you would doubtless say “the telephone”; it’s probably the only one of his many, many inventions most people could bring to mind. If you asked Bell himself, though, he would tell you his greatest invention was the photophone, and if the prolific [Nick Bild] doesn’t agree he’s at least intrigued enough to produce a replica of this 1880-vintage wireless telephone. Yes, 1880. As in, only four years after the telephone was patented.

It obviously did not catch on, and is not the sort of thing that comes to mind when we think “wireless telephone”. In contrast to the RF of the 20th century version, as you might guess from the name the photophone used light– sunlight, to be specific. In the original design, the transmitter was totally passive– a tube with a mirror on one end, mounted to vibrate when someone spoke into the open end of the tube. That was it, aside from the necessary optics to focus sunlight onto said mirror. [Nick Bild] skips this and uses a laser as a handily coherent light source, which was obviously not an option in 1880. As [Nick] points out, if it was, Bell certainly would have made use of it.
The photophone receiver, 1880 edition. Speaker not pictured.
The receiver is only slightly more complex, in that it does have electronic components– a selenium cell in the original, and in [Nick’s] case a modern photoresistor in series with a 10,000 ohm resistor. There’s also an optical difference, with [Nick] opting for a lens to focus the laser light on his photoresistor instead of the parabolic mirror of the original. In both cases vibration of the mirror at the transmitter disrupts line-of-sight with the receiver, creating an AM signal that is easily converted back into sound with an electromagnetic speaker.

The photophone never caught on, for obvious reasons — traditional copper-wire telephones worked beyond line of sight and on cloudy days–but we’re greatful to [Nick] for dredging up the history and for letting us know about it via the tip line. See his video about this project below.

The name [Nick Bild] might look familiar to regular readers. We’ve highlighted a few of his projects on Hackaday before.

youtube.com/embed/XQ86fkRRS5M?…

hackaday.com/2025/04/15/replic…

[Geoffrey Litt] shows that getting an effective digital assistant that’s tailored to one’s own needs just needs a little DIY, and thanks to the kinds of tools that are available today, it doesn’t even have to be particularly complex. Meet Stevens, the AI assistant who provides the family with useful daily briefs. The back end? Little more than one SQLite table and a few cron jobs.
A sample of Stevens’ notebook entries, both events and things to simply remember.
Every day, Stevens sends a daily brief via Telegram that includes calendar events, appointments, weather notes, reminders, and even a fun fact for the day. Stevens isn’t just send-only, either. Users can add new entries or ask questions about items through Telegram.

It’s rudimentary, but [Geoffrey] already finds it far more useful than Siri. This is unsurprising, as it has been astutely observed that big tech’s digital assistants are designed to serve their makers rather than their users. Besides, it’s also fun to have the freedom to give an assistant its own personality, something existing offerings sorely lack.

Architecture-wise, the assistant has a notebook (the single SQLite table) that gets populated with entries. These entries come from things like reading family members’ Google calendars, pulling data from a public weather API, processing delivery notices from the post office, and Telegram conversations. With a notebook of such entries (along with a date the entry is expected to be relevant), generating a daily brief is simple. After all, LLMs (Large Language Models) are amazingly good at handling and formatting natural language. That’s something even a locally-installed LLM can do with ease.

[Geoffrey] says that even this simple architecture is super useful, and it’s not even a particularly complex system. He encourages anyone who’s interested to check out his project, and see for themselves how useful even a minimally-informed assistant can be when it’s designed with ones’ own needs in mind.

hackaday.com/2025/04/15/diy-ai…

Nella maggior parte dei lavori nell’ambito di Machine Learning, non si fa ricerca per migliorare l’architettura di un modello o per progettare una nuova loss function. Nella maggior parte dei casi si deve utilizzare ciò che già esiste e adattarlo al proprio caso d’uso.

È quindi molto importante ottimizzare il progetto in termini di architettura del software e di implementazione in generale. Tutto parte da qui: si vuole un codice ottimale, che sia pulito, riutilizzabile e che funzioni il più velocemente possibile. Threading è una libreria nativa di Python che non viene utilizzata così spesso come dovrebbe.

Riguardo i Thread

I thread sono un modo per un processo di dividersi in due o più attività in esecuzione simultanea (o pseudo-simultanea). Un thread è contenuto all’interno di un processo e thread diversi dello stesso processo condividono le stesse risorse.

In questo articolo non si parlo di multiprocessing, ma la libreria per il multiprocessing di Python funziona in modo molto simile a quella per il multithreading.

In generale:

• Il multithreading è ottimo per i compiti legati all’I/O, come la chiamata di un’API all’interno di un ciclo for

• Il multiprocessing è usato per i compiti legati alla CPU, come la trasformazione di più dati tabellari in una volta sola

Quindi, se vogliamo eseguire più cose contemporaneamente, possiamo farlo usando i thread. La libreria Python per sfruttare i thread si chiama threading.

Cominciamo in modo semplice. Voglio che due thread Python stampino qualcosa contemporaneamente. Scriviamo due funzioni che contengono un ciclo for per stampare alcune parole.

def print_hello():
for x in range(1_000):
print("hello")

def print_world():
for x in range(1_000):
print("world")

Ora, se li eseguo uno dopo l’altro, vedrò nel mio terminale 1.000 volte la parola “hello” seguita da 1.000 “world”.

Utilizziamo invece i thread. Definiamo due thread e assegniamo a ciascuno di essi le funzioni definite in precedenza. Poi avviamo i thread. Dovreste vedere la stampa di “hello” e “world” alternarsi sul vostro terminale.

Se prima di continuare l’esecuzione del codice si vuole aspettare che i thread finiscano, è possibile farlo utilizzando: join().

import threding

thread_1 = threding.Thread(target = print_hello)
thread_2 = threding.Thread(target = print_world)

thread_1.start()
thread_2.start()

# wait for the threads to finish before continuing running the code
thread_1.join()
thread_2.join()

print("do other stuff")

Lock delle risorse dei thread

A volte può accadere che due o più thread modifichino la stessa risorsa, ad esempio una variabile contenente un numero.

Un thread ha un ciclo for che aggiunge sempre uno alla variabile e l’altro sottrae uno. Se eseguiamo questi thread insieme, la variabile avrà “sempre” il valore di zero (più o meno). Ma noi vogliamo ottenere un comportamento diverso. Il primo thread che prenderà possesso di questa variabile deve aggiungere o sottrarre 1 fino a raggiungere un certo limite. Poi rilascerà la variabile e l’altro thread sarà libero di prenderne possesso e di eseguire le sue operazioni.

import threading
import time

x = 0
lock = threading.Lock()

def add_one():
global x, lock # use global to work with globa vars
lock.acquire()
while x -10:
x = x -1
print(x)
time.sleep(1)
print("reached minimum")
lock.release()

Nel codice sopra riportato, abbiamo due funzioni. Ciascuna sarà eseguita da un thread. Una volta avviata, la funzione bloccherà la variabile lock, in modo che il secondo thread non possa accedervi finché il primo non ha finito.

thread_1 = threading.Thread(target = add_one)
thread_2 = threading.Thread(target = subtract_one)

thread_1.start()
thread_2.start()

Lock usando un semaforo

Possiamo ottenere un risultato simile a quello ottenuto sopra utilizzando i semafori. Supponiamo di voler far accedere a una funzione un numero totale di thread contemporaneamente. Ciò significa che non tutti i thread avranno accesso a questa funzione, ma solo 5, per esempio. Gli altri thread dovranno aspettare che alcuni di questi 5 finiscano i loro calcoli per avere accesso alla funzione ed eseguire lo script. Possiamo ottenere questo comportamento utilizzando un semaforo e impostando il suo valore a 5. Per avviare un thread con un argomento, possiamo usare args nell’oggetto Thread.

import time
import threading

semaphore = threading.BoudnedSemaphore(value=5)

def func(thread_number):
print(f"{thread_number} is trying to access the resource")
semaphore.acquire()

print(f"{thread_number} granted access to the resource")
time.sleep(12) #fake some computation

print(f"{thread_number} is releasing resource")
semaphore.release()

if __name__ == "__main__":
for thread_number in range(10):
t = threading.Thread(target = func, args = (thread_number,)
t.start()
time.sleep(1)

Eventi

Gli eventi sono semplici meccanismi di segnalazione usati per coordinare i thread. Si può pensare a un evento come a un flag che si può selezionare o deselezionare, e gli altri thread possono aspettare che venga selezionato prima di continuare il loro lavoro.

Ad esempio, nel seguente esempio, il thread_1 che vuole eseguire la funzione “func” deve attendere che l’utente inserisca “sì” e scateni l’evento per poter terminare l’intera funzione.

import threading

event = threading.Event()

def func():
print("This event function is waiting to be triggered")
event.wait()
print("event is triggered, performing action now")

thread_1 = threading.Thread(target = func)
thread_1.start()

x = input("Do you want to trigger the event? \n")
if x == "yes":
event.set()
else
print("you chose not to trigger the event")

Daemon Thread

Si tratta semplicemente di thread che vengono eseguiti in background. Lo script principale termina anche se questo thread in background è ancora in esecuzione. Ad esempio, si può usare un thread demone per leggere continuamente da un file che viene aggiornato nel tempo.

Scriviamo uno script in cui un thread demone legge continuamente da un file e aggiorna una variabile stringa e un altro thread stampa su console il contenuto di tale variabile.

import threading
import time

path = "myfile.txt"
text = ""

def read_from_file():
global path, text
while True:
with open(path, "r") as f:
text = f.read()
time.sleep(4)

def print_loop():
for x in range(30):
print(text)
time.sleep(1)

thread_1 = threading.Thread(target = read_from_file, daemon = True)
thread_2 = threading.Thread(target = print_loop)

thread_1.start()
thread_2.start()

Queues (code)

Una coda è un insieme di elementi che obbedisce al principio first-in/first-out (FIFO). È un metodo per gestire strutture di dati in cui il primo elemento viene elaborato per primo e l’elemento più recente per ultimo.

Possiamo anche cambiare l’ordine di priorità con cui processiamo gli elementi della collezione. LIFO, ad esempio, sta per Last-in/First-out. Oppure, in generale, possiamo avere una coda di priorità in cui possiamo scegliere manualmente l’ordine.

Se più thread vogliono lavorare su un elenco di elementi, ad esempio un elenco di numeri, potrebbe verificarsi il problema che due thread eseguano calcoli sullo stesso elemento. Vogliamo evitare questo problema. Perciò possiamo avere una coda condivisa tra i thread e, quando un thread esegue il calcolo su un elemento, questo elemento viene rimosso dalla coda. Vediamo un esempio.

import queue

q = queue.Queue() # it can also be a LifoQueue or PriorityQueue
number_list = [10, 20, 30, 40, 50, 60, 70, 80]

for number in number_list:
q.put(number)

print(q.get()) # -> 10
print(1.het()) # -> 20

Un esempio di thread in un progetto di Machine Learning

Supponiamo di lavorare a un progetto che richiede una pipeline di streaming e preelaborazione dei dati. Questo accade in molti progetti con dispositivi IoT o qualsiasi tipo di sensore. Un thread demone in background può recuperare e preelaborare continuamente i dati mentre il thread principale si concentra sull’inferenza.

Per esempio, in un caso semplice in cui devo sviluppare un sistema di classificazione delle immagini in tempo reale utilizzando il feed della mia telecamera. Imposterei il mio codice con 2 thread:

• Recuperare le immagini dal feed della telecamera in tempo reale.
• Passare le immagini a un modello di AI per l’inferenza.

import threading
import time
import queue
import random

# Sfake image classifier
def classify_image(image):
time.sleep(0.5) # fake the model inference time
return f"Classified {image}"

def camera_feed(image_queue, stop_event):
while not stop_event.is_set():
# Simulate capturing an image
image = f"Image_{random.randint(1, 100)}"
print(f"[Camera] Captured {image}")
image_queue.put(image)
time.sleep(1) # Simulate time between captures

def main_inference_loop(image_queue, stop_event):
while not stop_event.is_set() or not image_queue.empty():
try:
image = image_queue.get(timeout=1) # Fetch image from the queue
result = classify_image(image)
print(f"[Model] {result}")
except queue.Empty:
continue

if __name__ == "__main__":
image_queue = queue.Queue()
stop_event = threading.Event()

camera_thread = threading.Thread(target=camera_feed, args=(image_queue, stop_event), daemon=True)
camera_thread.start()

try:
main_inference_loop(image_queue, stop_event)
except KeyboardInterrupt:
print("Shutting down...")
stop_event.set() # Signal the camera thread to stop
finally:
camera_thread.join() # Ensure the camera thread terminates properly
print("All threads terminated.")

In questo semplice esempio, abbiamo:

• Un thread demone: L’input della telecamera viene eseguito in background, in modo da non bloccare l’uscita del programma al completamento del thread principale.

• Evento per il coordinamento: Questo evento stop_event consente al thread principale di segnalare al thread demone di terminare.

• Coda per la comunicazione: image_queue assicura una comunicazione sicura tra i thread.

Conclusioni

In questo tutorial vi ho mostrato come utilizzare la libreria di threading in Python, affrontando concetti fondamentali come lock, semafori ed eventi, oltre a casi d’uso più avanzati come i thread daemon e le code.

Vorrei sottolineare che il threading non è solo skill tecnica, ma piuttosto una mentalità che consente di scrivere codice pulito, efficiente e riutilizzabile. Quando si gestiscono chiamate API, si elaborano flussi di dati di sensori o si costruisce un’applicazione di AI in tempo reale, il threading consente di costruire sistemi robusti, reattivi e pronti a scalare.

L'articolo Machine Learning: il Segreto è il Modello, ma anche il Codice! proviene da il blog della sicurezza informatica.

[Chris Cecil] had a problem. He had a Manncorp/Autotronik MC384V2 pick and place, and needed more feeders. The company was reluctant to support an older machine and wanted over $32,000 to supply [Chris] with more feeders. He contemplated the expenditure… but then came across another project which gave him pause. Could he make Siemens feeders work with his machine?

It’s one of those “standing on the shoulders of giants” stories, with [Chris] building on the work from [Bilsef] and the OpenPNP project. He came across SchultzController, which could be used to work with Siemens Siplace feeders for pick-and-place machines. They were never supposed to work with his Manncorp machine, but it seemed possible to knit them together in some kind of unholy production-focused marriage. [Chris] explains how he hooked up the Manncorp hardware to a Smoothieboard and then Bilsef’s controller boards to get everything working, along with all the nitty gritty details on the software hacks required to get everything playing nice.

For an investment of just $2,500, [Chris] has been able to massively expand the number of feeders on his machine. Now, he’s got his pick and place building more Smoothieboards faster than ever, with less manual work on his part.

We feature a lot of one-off projects and home production methods, but it’s nice to also get a look at methods of more serious production in bigger numbers, too. It’s a topic we follow with interest. Video after the break.

youtube.com/embed/TQo33HRDTA8?…

[Editor’s note: Siemens is the parent company of Supplyframe, which is Hackaday’s parent company. This has nothing to do with this story.]

hackaday.com/2025/04/15/making…

dalla pagina di Roberto Vallepiano
(grazie a Tano D'Amico)

facebook.com/share/p/1AZRzkFwZ…

Mancavano pochi minuti alla mezzanotte quando la prima manganellata si abbatté sulla spalla sinistra di Mark Covell, il giornalista inglese che stava dormendo alla Scuola Diaz assieme ad altri 92 mediattivisti di diverse parti del mondo.
Covell urlò in italiano che era un giornalista, ma in pochi secondi si trovò circondato dagli agenti dei reparti antisommossa che lo tempestarono di colpi dei Tonfa, i manganelli "spaccaossa" inaugurati proprio in occasione del G8 di Genova.
Riuscì a restare in piedi solo per pochi secondi, poi una bastonata sulle ginocchia gli spappolò una rotula e lo fece crollare sul selciato.
Mentre giaceva faccia a terra nel buio, contuso e spaventato, un'orda di 346 Poliziotti stava dando il via a quella che venne presto ribattezzata la "Macelleria Messicana".
Proprio in quel momento un agente gli saltò addosso e gli diede un calcio al petto con tanta violenza da incurvargli tutta la parte sinistra della gabbia toracica, rompendogli una mezza dozzina di costole. Le schegge gli lacerarono la pleura del polmone sinistro.
Mentre i battaglioni punitivi della Polizia iniziavano il massacro della Diaz, alcuni agenti cominciarono a colpire Covell con gli anfibi, passandoselo da uno all'altro, come se fosse un pallone da calcio.
Mentre avveniva ciò Mark Covell, che è alto 1,73 e pesa 50 chili, sentiva gli agenti ridere.
Una nuova scarica di calci gli ruppe la mano sinistra con cui tentava di proteggersi e gli danneggiò in maniera irreversibile la spina dorsale.
Rimase qualche minuto inebetito a terra in una pozza di sangue. Poi due poliziotti tornarono indietro e si fermarono accanto al giornalista inglese ormai semi-incosciente, uno lo colpì alla testa con il manganello e il secondo lo prese a calci sulla bocca, frantumandogli i denti. Mark Covell svenne.
Rimase sospeso tra la vita e la morte, in coma, per 15 lunghissime ore.
Arrivò in sala operatoria in condizioni disperate: trauma cranico con emorragia venosa, mano sinistra e 8 costole fratturate, perforazione del polmone, trauma emitorace, spalla e omero, oltre alla perdita di 16 denti.
Mark Covell è un sopravvissuto. Uno dei tanti sopravvissuti alla mattanza genovese nei giorni del G8, a quella che perfino Amnesty International denunciò come "La più grave violazione dei diritti umani in Europa dopo la 2° Guerra Mondiale".

E anche se la Corte di Strasburgo ha condannato l'Italia per tortura e trattamenti disumani e degradanti, nessuno o quasi ha pagato.
La verità è stata insabbiata e i responsabili della Premiata Macelleria Messicana sono stati tutti coperti trasversalmente dai governi di Destra e di Centrosinistra e addirittura promossi.

Ma noi siamo ancora qui. Oggi come ieri.
Fianco a fianco con Mark Covell e tutti gli altri.
Per sputargli in faccia la verità e ricordargli che la memoria è un ingranaggio collettivo.