Un processore RISC integrato, grafica pensata per il 3D e una famiglia di prodotti che avrebbe potuto andare dalla console alla scheda acceleratrice: Hombre fu uno dei futuri più ambiziosi immaginati da Commodore. I documenti superstiti raccontano un progetto incompiuto, ma pongono anche una domanda attuale: quanto di quell’architettura sarebbe ancora recuperabile, e che cosa servirebbe davvero per farla vivere su FPGA?
La storia di Amiga non termina soltanto con computer diventati oggetti da collezione. Termina anche con progetti che non hanno mai avuto il tempo di diventare macchine. Hombre appartiene a questa seconda categoria: non un modello raro da cercare su un’asta, ma un’architettura rimasta fra specifiche, presentazioni tecniche e lavoro di sviluppo.
Il suo interesse supera il consueto rimpianto per «l’Amiga che avrebbe potuto essere». Hombre metteva in discussione la continuità della piattaforma: conservare il rapporto stretto fra CPU, memoria e coprocessori, ma ripensarlo per grafica tridimensionale, processori RISC e prodotti differenti. Non era semplicemente AGA con più colori. Era il tentativo di cambiare il punto di partenza.
Per ricostruirlo bisogna però separare tre livelli: le intenzioni documentate, ciò che era stato effettivamente sviluppato e le possibilità che immaginiamo oggi. Confonderli trasforma facilmente un progetto promettente in un computer perfetto mai esistito.
Da AAA a Hombre: due risposte diverse al futuro di Amiga
All’inizio degli anni Novanta il problema non era soltanto aumentare risoluzioni e velocità. Il mercato dei giochi e della grafica stava chiedendo scene tridimensionali, superfici texturizzate, più memoria e strumenti di sviluppo capaci di astrarre l’hardware. Una piattaforma costruita attorno a soluzioni straordinarie per il 2D doveva trovare un modo per accompagnare quel cambiamento.
AAA, Advanced Amiga Architecture, cercava una strada evolutiva. Hombre guardava oltre quella continuità. Nella testimonianza pubblicata nel marzo 2026, Ed Hepler colloca l’avvio del progetto dopo il tape-out di AAA e l’arrivo dei primi prototipi. È una precisazione importante: la formula «Commodore cancellò AAA e iniziò Hombre» comprime una storia più articolata, nella quale lo sviluppo della nuova architettura nasceva anche dalla difficoltà di proseguire indefinitamente sulla precedente.
Hepler ricorda soprattutto il costo della compatibilità: conservare il comportamento dei registri, incluse le modalità non convenzionali sfruttate dai programmatori, complicava ogni evoluzione. La risposta di Hombre era integrare più funzioni, ridurre il costo delle implementazioni economiche e spostare l’accesso alle capacità hardware verso driver e interfacce software. Fonte: intervista a Ed Hepler, RetroTech & Café, 10 marzo 2026.
Una presentazione del 1994, non il lancio di un prodotto
Fra i materiali conservati c’è una presentazione per un incontro Philips/Commodore del 15 aprile 1994. Le slide riportano una revisione del 12 aprile e una creazione iniziale nell’ottobre 1993. Parlano di primi chip disponibili alla fine del 1994 e produzione nel 1995: obiettivi di pianificazione, non risultati raggiunti.
Il fallimento di Commodore, il 29 aprile 1994, arrivò dunque quando quel calendario aveva ancora davanti passaggi decisivi. Non abbiamo davanti una console pronta alla vendita e fermata all’ultimo minuto. Abbiamo il disegno di una piattaforma che richiedeva ancora implementazione, verifica, integrazione e software.
La presentazione elenca prodotti molto diversi: macchina da gioco su CD, set-top box, lettore MPEG, home computer, acceleratore grafico PCI, desktop o tower. Il valore commerciale cercato non era soltanto una console migliore, ma una base riutilizzabile. Il costo del chipset inferiore a 40 dollari era un obiettivo per la soluzione economica, non il prezzo di un computer completo. Fonte: presentazione Commodore/Hepler, pagine 1–3 e 13.
Nathaniel e Natalie: il sistema diviso in due chip
Le specifiche organizzano Hombre attorno a due componenti principali. Nathaniel è il chip CPU/rendering: coordina elaborazione, accessi alla memoria e funzioni multimediali. Natalie è il chip video: gestisce il percorso che porta i dati grafici allo schermo e le interfacce con il video esterno.
Questa divisione conserva un’idea familiare a chi conosce Amiga: la CPU non deve svolgere da sola ogni operazione. Cambiano però il processore integrato, i formati dei pixel e il lavoro affidato ai blocchi specializzati. L’obiettivo diventa produrre e visualizzare immagini tridimensionali senza trattare il chipset soltanto come un dispositivo che legge una bitmap già pronta.
| Componente | Funzioni previste | Perché conta |
|---|---|---|
| Nathaniel | Core RISC, blitter/rendering, DMA, Copper, audio, interfacce memoria e PCI. | Avvicina elaborazione e operazioni grafiche, con integrazione utile anche a una console economica. |
| Natalie | Buffer di linea, cursore, tabella colori, uscita RGB, ingresso video, genlock e conversione YUV/RGB. | Collega rendering, visualizzazione e trattamento del video. |
| Memoria e collegamenti | Configurazioni differenziate, con percorsi a 32 o 64 bit e possibilità di espansione. | Permettono di adattare l’architettura a prezzi e impieghi diversi. |
La tabella è una sintesi funzionale, non la descrizione di una scheda commercializzata. Le slide separano esplicitamente il chip di rendering da quello video e mostrano più configurazioni di sistema. Fonte: diagrammi Nathaniel/Natalie, pagine 11–12 della presentazione.
PA-RISC e «64 bit»: una distinzione essenziale
Hombre viene spesso riassunto come «l’Amiga a 64 bit». È una formula suggestiva, ma imprecisa se la si interpreta come descrizione della CPU. La presentazione parla di un’implementazione PA-RISC con pipeline intera a cinque stadi e datapath esteso a 64 bit, utilizzando anche coppie di registri. Larghezza dei percorsi di elaborazione, bus di memoria e architettura del processore non sono sinonimi.
Nella stessa intervista del 2026 Hepler precisa che il sistema su CD da lui disegnato non aveva un processore a 64 bit; per questo non ricorda di averlo chiamato CD64. Il nome compare nelle ricostruzioni storiche, ma va usato come denominazione tradizionalmente associata al progetto, non come prova tecnica. Anche identificare Hombre con un normale PA-7150 commerciale già pronto rischia di nascondere il punto centrale: Commodore progettava un core integrato e modificabile per le proprie esigenze. Fonte: testimonianza di Hepler. Riscontro: slide «PA-RISC Implementation», pagina 23.
Il vantaggio cercato era concreto: eseguire il codice di controllo e affiancargli operazioni specializzate per grafica, manipolazione delle coordinate e lavoro sui pixel. Questa integrazione spiega Hombre meglio di una gara fra etichette «32» e «64». Per chi volesse ricostruirlo oggi, sarebbe inoltre indispensabile distinguere l’insieme di istruzioni standard dalle estensioni effettivamente definite.
Dal blitter 2D a una macchina per superfici tridimensionali
Un blitter tradizionale sposta e combina porzioni di immagine. Il motore di Hombre estendeva questo lavoro verso il riempimento di superfici, l’interpolazione del colore e il campionamento delle texture. La documentazione descrive operazioni sui pixel e aritmetica a virgola fissa: un approccio comprensibile per hardware che doveva contenere costo e complessità.
Il texture mapping assegna una superficie visiva a una forma: mattoni su un muro, pannelli su una nave, terreno su un paesaggio. Lo shading Gouraud interpola i valori di colore o luminosità attraverso una superficie. Il Z-buffer riguarda invece la profondità: permette di stabilire quale frammento debba risultare visibile quando le geometrie si sovrappongono. Sono compiti diversi, spesso riuniti nelle descrizioni sintetiche di Hombre come se costituissero una sola funzione.
Il passaggio ai pixel chunky, nei quali i dati di un pixel sono organizzati insieme invece che distribuiti nei bitplane classici, avrebbe reso più diretto il rapporto con un renderer software. Non significa che memoria e banda cessassero di essere un problema: texture, colore, profondità e visualizzazione competono per accessi che devono essere pianificati.
Anche i formati di visualizzazione meritano cautela. Le slide riportano modalità a palette di 8 bit, HAM8, RGB a 16 bit e true color a 24 bit memorizzato in parole da 32 bit. Descrivono combinazioni di playfield differenti secondo la modalità: non semplicemente «quattro piani a 16 bit sempre disponibili». Un playfield è qui una superficie visualizzata e componibile, non un bitplane classico. Ritrovare alcuni concetti Amiga non equivale a ritrovarne l’intero comportamento compatibile. Riscontro: slide «Pixel Formats» e «Output Selection».
Le prestazioni ipotizzate nei materiali dell’epoca vanno lette come stime. Non dimostrano automaticamente un determinato frame rate in un gioco completo, né consentono di decretare una superiorità su PlayStation o Saturn. La documentazione tecnica descrive capacità progettate; l’efficacia commerciale avrebbe richiesto anche strumenti, librerie, sviluppatori e titoli. Fonte: descrizione del blitter e dei riempimenti texturizzati. Approfondimento: specifiche tecniche Hombre conservate su Internet Archive, parte 3.
Audio e video: non soltanto poligoni
La componente multimediale era altrettanto significativa. La presentazione descrive dodici canali audio di tipo AAA, a 16 bit e 44,1 kHz, insieme a ingressi e uscita seriali in formato CD. La cifra va riferita ai canali audio definiti in quella documentazione, senza confonderla con il numero complessivo delle sorgenti quando si aggiungono gli ingressi esterni.
Il percorso video includeva genlock, acquisizione e conversione YUV/RGB. Per un sistema destinato anche a multimedia, televisione e schede acceleratrici, queste funzioni non erano accessori: facevano parte del tentativo di usare la stessa tecnologia fuori dal solo mercato dei videogiochi. Anche qui è prudente descrivere un’architettura proposta, non un insieme di caratteristiche collaudate su un prodotto finale. Fonte: presentazione, sezioni Audio e Video Chip.
Che cosa sarebbe rimasto della compatibilità Amiga?
La compatibilità non è una domanda con una risposta unica. Eseguire istruzioni Motorola 68000 in emulazione è un problema; riprodurre i registri dei chipset Amiga, il loro timing e gli effetti ottenuti accedendo direttamente all’hardware è un altro; trasferire AmigaOS e le sue librerie su una piattaforma differente è un terzo.
Un programma ben mediato dalle API e un gioco che programma direttamente Copper e blitter non chiedono la stessa cosa a un sistema nuovo. Per questo la possibilità teorica di un emulatore 68k non equivale a poter inserire un disco Amiga e ottenere subito comportamento identico.
La direzione proposta da Hombre privilegiava un’architettura nuova. Driver, emulazione o un eventuale sottosistema compatibile avrebbero dovuto costruire il ponte verso il passato. Era una scelta potenzialmente liberatoria per il progetto hardware, ma impegnativa per una comunità che aveva investito in programmi, periferiche e conoscenze molto specifiche.
Windows NT, OpenGL e il software che mancava
Nel dossier di Hombre compaiono Windows NT, strumenti di sviluppo per PA-RISC e un percorso grafico associato a librerie 3D. Bisogna resistere alla tentazione di tradurli in un elenco di sistemi operativi già funzionanti. Una compatibilità desiderata non garantisce che siano pronti firmware, port, driver e ambiente completo.
OpenGL, soprattutto, è un’interfaccia per la grafica, non un sistema operativo. Una console può adottare uno strato di librerie molto più ridotto di quello necessario a un desktop. Un computer generalista richiede invece gestione delle risorse, periferiche, strumenti e applicazioni.
La separazione fra hardware nuovo e migrazione software riappare nelle parole di Dave Haynie sull’esperienza Power Amiga/PIOS del 1996: emulare programmi e avere un AmigaOS nativo non erano traguardi equivalenti. È un contesto successivo, non una prova dello stato di Hombre, ma chiarisce perché il software non possa essere considerato un dettaglio da aggiungere a macchina completata. Fonte: intervista a Dave Haynie, Amiga Blast, 1996.
Perché non possiamo sapere se avrebbe salvato Commodore
Hombre aveva una logica: integrazione, grafica 3D, prodotti diversificati, costo ridotto nella fascia bassa. Questo non basta per dimostrare che avrebbe salvato l’azienda. Un chipset ambizioso deve arrivare in tempo, essere fabbricato, sostenere un software convincente e trovare un pubblico. Deve inoltre convivere con la situazione finanziaria di chi lo produce.
La sua cancellazione impedisce proprio quel confronto con la realtà. Possiamo analizzare gli obiettivi e le scelte; non possiamo attribuirgli vendite, giochi o prestazioni che non furono misurate su un prodotto commercializzato. Il valore storico del progetto sta nel mostrare quale trasformazione alcuni progettisti ritenevano necessaria, non nel dimostrare una vittoria alternativa.
La domanda dei faldoni: esiste ancora ciò che manca?
Qui la storia diventa una domanda di ricerca. Ci chiediamo se in qualche faldone fisico, supporto di backup, archivio personale o deposito aziendale esistano ancora dettagli tecnici inediti sufficienti a riprendere Hombre e portarlo a termine su FPGA.
La documentazione pubblica non è vuota: Internet Archive conserva presentazioni e più parti delle specifiche. Ma una specifica, anche dettagliata, non coincide necessariamente con un’implementazione completa. Per capire quanto lavoro manchi servirebbe inventariare registri, istruzioni estese, priorità del bus, sequenze DMA, formati audio/video, eccezioni e interazioni fra i blocchi. E distinguere ciò che era definitivo da ciò che era ancora una proposta.
La raccolta contiene anche descrizioni tecniche e registri, non soltanto slide promozionali. È quindi più corretto chiedersi quali materiali manchino per rendere verificabile l’implementazione, anziché supporre che di Hombre resti solo un nome. La presenza di documentazione pubblica è un punto di partenza; la sua completezza rispetto a tutte le revisioni del progetto resta da dimostrare.
Materiali particolarmente preziosi sarebbero sorgenti HDL o equivalenti, descrizioni delle macchine a stati, netlist, modelli di simulazione, test vector, firmware, toolchain e codice delle librerie. Non possiamo affermare che tutto questo sia sopravvissuto. Né che un singolo archivio contenga il progetto completo. Possiamo affermare che una ricerca coordinata avrebbe un obiettivo preciso: trasformare documenti dispersi in un corpus verificabile, con provenienza e versioni.
Ricostruire Hombre su FPGA: che cosa significherebbe davvero?
Un FPGA permette di implementare logica digitale riconfigurabile. Non rende però automaticamente realizzabile qualsiasi architettura e non restituisce le parti mancanti di un progetto. Per Hombre occorrerebbe scegliere innanzitutto l’obiettivo: ricostruzione fedele delle specifiche superstiti, dimostratore funzionale di alcuni blocchi oppure macchina moderna ispirata alle stesse idee.
Sono tre risultati legittimi, ma non intercambiabili. Se si sostituisce il core RISC con una CPU differente o si affidano le operazioni 3D a una GPU moderna, si può ottenere un sistema interessante senza avere ricreato Hombre. Viceversa, una realizzazione fedele potrebbe preservare anche limiti e scelte non più ottimali.
Una strada ragionevole partirebbe da un modello software eseguibile dei blocchi documentati. Quel modello diventerebbe il riferimento per testare CPU ed estensioni, blitter, memoria, video e audio. Solo dopo si trasferirebbero progressivamente le funzioni in HDL, verificando sintesi, temporizzazioni, banda e comportamento ai confini. Un primo traguardo potrebbe essere una scena texturizzata riprodotta correttamente, non un nuovo computer pronto per ogni applicazione.
La modernità degli strumenti aiuta, ma non elimina le verifiche: un simulatore che funziona non garantisce che il circuito rispetti il timing sull’FPGA scelto. Anche diritti, licenze e disponibilità dei materiali vanno chiariti. Il possesso di un marchio non dimostra automaticamente il controllo di ogni sorgente, tecnologia o accordo del progetto storico.
Il ruolo dell’AI: accelerare il lavoro, non inventare la storia
L’intelligenza artificiale potrebbe essere utile sia nella definizione dell’hardware sia nello sviluppo del software. Il suo primo impiego sensato sarebbe archivistico: trascrivere scansioni, indicizzare documenti, confrontare revisioni e segnalare contraddizioni da sottoporre a un esperto. Non dovrebbe colmare silenziosamente un registro mancante con una soluzione plausibile.
Nel progetto hardware potrebbe assistere nella stesura di moduli HDL, testbench, proprietà di verifica e strumenti di confronto. Nel software potrebbe contribuire a emulatori di riferimento, assembler, driver, librerie grafiche e piccole demo. In entrambi i casi il valore dipenderebbe dai test: una proposta generata non costituisce né prova storica né prova di correttezza.
La disciplina decisiva sarebbe registrare la provenienza di ogni scelta: documentata nel progetto originale, ricostruita per inferenza oppure introdotta oggi. L’AI può accelerare il passaggio fra documento e implementazione; non può decidere da sola che cosa Hombre fosse realmente destinato a fare. La responsabilità resterebbe di progettisti capaci di leggere quelle fonti e validare il risultato.
Dave Haynie, la nuova Commodore e una possibilità da non confondere con un annuncio
La nuova Commodore International Corporation offre il Commodore 64 Ultimate e nella propria pagina ufficiale presenta Dave Haynie come Technical Advisor. La stessa pagina attribuisce al suo contributo anche interventi di integrazione audio/video sul C64U. La sua presenza è dunque documentata, non una semplice voce della comunità. Fonte: Team Commodore.
È un collegamento suggestivo: un protagonista dell’ingegneria Amiga torna a collaborare con un marchio che oggi propone hardware retro basato su tecnologie riconfigurabili. Ma sarebbe improprio trasformarlo automaticamente nel responsabile di un nuovo Hombre. Nelle fonti del progetto il riferimento centrale per il chipset è Ed Hepler; il lavoro sui sistemi, sulle schede e sul software coinvolge competenze differenti. Haynie è un interlocutore prezioso per ricostruire quel contesto, non una scorciatoia per attribuire a una persona l’intera architettura.
Un’eventuale indagine sugli archivi dovrebbe quindi coinvolgere anche gli altri progettisti e chi conserva documentazione tecnica e software. La disponibilità del C64 Ultimate dimostra che esiste oggi un mercato per nuove realizzazioni di piattaforme storiche; non dimostra che siano già disponibili risorse, diritti o un core FPGA di Hombre. Fonte sul prodotto e sull’azienda: sito ufficiale Commodore.
Nelle fonti consultate non emerge un annuncio verificato di una rinascita commerciale di Hombre. Quella che proponiamo è una domanda: la combinazione fra memorie dei progettisti, archivi superstiti, FPGA e strumenti AI potrebbe rendere finalmente esplorabile un futuro rimasto incompiuto?
Prima di finire il computer, ritrovare il progetto
La risposta più interessante non sarebbe annunciare subito un «Amiga mai nato». Sarebbe ritrovare, catalogare e rendere studiabile il lavoro rimasto sospeso. Capire quali parti siano abbastanza definite per una ricostruzione e quali richiedano decisioni moderne. Poi produrre dimostrazioni misurabili, accompagnate da codice e documentazione nei limiti consentiti.
Hombre non ha bisogno di diventare una leggenda infallibile per meritare attenzione. Ci mostra una Commodore che cercava un rapporto nuovo fra integrazione, grafica e software proprio quando il proprio tempo stava finendo. Se un giorno quel rapporto tornasse a funzionare su FPGA, il risultato più prezioso non sarebbe riscrivere il 1994: sarebbe riuscire, finalmente, a studiare una delle sue possibilità dall’interno.
Fonti, documentazione e immagini
- Internet Archive, raccolta Hombre: presentazioni Commodore e specifiche tecniche in più parti. Fonte primaria per architettura, configurazioni e funzioni previste; la raccolta non prova il completamento del chipset.
- Hombre Presentation, parte 1 e parte 2: materiali di Ed Hepler revisionati nell’aprile 1994.
- RetroTech & Café, intervista a Ed Hepler, 10 marzo 2026: testimonianza diretta utile a correggere cronologia, compatibilità e uso della definizione «64 bit».
- Amiga Blast/CUCUG, intervista a Dave Haynie, 1996: contesto successivo Power Amiga/PIOS e distinzione fra emulazione e porting del sistema operativo.
- Commodore, pagina ufficiale del team e sito ufficiale: ruolo attuale di Haynie e Commodore 64 Ultimate, verificati per questa bozza.
- Evan-Amos, fotografia Amiga CD32, Wikimedia Commons: immagine in pubblico dominio; la console fotografata non è un prototipo Hombre.
Nota sulle immagini: copertina e illustrazione della sezione FPGA sono state generate per Retromind con OpenAI GPT Image 2.5 Sunburst. Sono immagini concettuali, non fotografie d’epoca, schemi costruttivi o prove dell’esistenza di un prodotto. Le ipotesi su archivi inediti e ricostruzione FPGA/AI sono riflessioni progettuali dell’articolo, non notizie di un progetto annunciato.
