Non si sente nulla neanche per attimo all'accensione del C64?
Premesso che il motore viene alimentato dai 6V ricavati dalla linea 9V AC sul pin C-3, i 4,7V della linea +5V (pin B-2) sono ancora accettabili e per me il problema non è quello. Link pinout: https://www.c64-wiki.com/wiki/Cassette_Port
Prima cosa io controllerei lo switch del "sense" (quello che si chiude quando premi un qualsiasi tasto) che potrebbe essere rotto o solo ossidato.
Il problema potrebbe essere anche nel C64: bisognerebbe provare il tuo datassette con un altro C64 o un altro datassette (sicuro funzionante) con il tuo C64 e vedere dove rimane il difetto.

I datassette originali Commodore sono abbastanza robusti e affidabili, quelli che ho recuperato da cantine fredde e umide rimasti fermi per più di 30 anni sono ancora funzionanti.

Ho fatto anch'io alcune prove per capire se il listato proposto su CCC fosse realmente utilizzabile nella pratica sul Commodore 64.
Come prima prova l'ho messo in esecuzione sull'emulatore Denise che sul mio PC gira a circa il 3300% della velocità originale del 64.
Come "parametri" ho settatto il limite minimo proposto e come "massimo" esattamente il doppio di ogni valore. Non ho usato un criterio particolare per utilizzare questi valori ma sono andato a "sentimento".
Dopo 5 giorni di elaborazione continuata non ho ancora ottenuto alcun risultato: nessun pangramma e nemmeno un esito negativo.

Come secondo tentativo, giusto per capire se il codice potesse realmente funzionare, ho usato la AI Gemini di Google.
L'ho da prima istruita a comprendere cosa facesse il codice assembly necessario al funzionamento del prg basic e poi le ho chiesto di analizzare il funzionamento dei due codici in maniera combinata.
Il risultato è stato questo:

Ok, proviamo a incrociare l'analisi del codice assembly con il codice BASIC per dedurre il funzionamento e ipotizzare dei valori di input.

Ipotesi sul Funzionamento Generale:

Considerando le operazioni di lettura/scrittura nella pagina di memoria $C2xx, i salti condizionati, e le informazioni che abbiamo sul BASIC, ecco un'ipotesi più dettagliata:

Inizializzazione:

Il codice assembly legge i limiti inferiori e superiori (min/max occorrenze di lettere) che l'utente ha inserito tramite INPUT nel BASIC e che sono stati scritti nella pagina $C2xx (probabilmente $C2A0-$C2AF).

Inizializza una tabella (forse in $C2B0-$C2BF) con dei valori di partenza.

Ciclo Principale (Ricerca Pangramma):

Il codice assembly seleziona una combinazione di numeri dalla lista N$() (uno, due, tre, ... cinquanta).

Conta le occorrenze di ogni lettera (a, b, c, ... z) in questa combinazione.

Confronta queste occorrenze con i limiti min/max letti precedentemente dalla pagina $C2xx.

Se tutte le lettere rientrano nei limiti, e se sono presenti tutte le lettere (cioè, se è un pangramma), memorizza questa combinazione come un potenziale risultato.

Continua a provare altre combinazioni finché non trova una soluzione o esaurisce le possibilità.

Tabella di Salto (Gestione Risultati o Condizioni):

La tabella di salti (le istruzioni JMP dopo i BNE) potrebbe servire per gestire diverse situazioni:

Se una lettera è troppo rara nella combinazione corrente, salta a una routine per provare una combinazione diversa.

Se una lettera è troppo frequente, salta a una routine per provare una combinazione diversa.

Se tutte le lettere rientrano nei limiti ma non sono presenti tutte, salta a una routine per aggiungere altre parole alla combinazione.

Se trova un pangramma valido, salta a una routine per memorizzare i risultati.

Output dei Risultati:

Se trova un pangramma valido, il codice assembly scrive gli indici delle parole che compongono il pangramma nella memoria (probabilmente $C2C0-$C2CF).

Imposta un flag in memoria per indicare il successo della ricerca.

Ipotizziamo Valori di Input:

Dato che il programma cerca un pangramma con lettere da 'a' a 'v' e 'z', un input sensato sarebbe:

a (min 12, max 15): Un valore alto perché ci sono molte parole che non contengono la lettera 'a'.

b (min 1, max 2): Valori bassi, poiché 'b' non è frequentissima.

c (min 5, max 7): Anche qui, valori bassi.

d (min 5, max 7): Valori bassi.

e (min 11, max 14): Valore alto, 'e' è molto comune.

i (min 4, max 6): Valori medi.

n (min 11, max 14): Valore alto, 'n' è comune.

o (min 10, max 13): Valore alto, 'o' è comune.

q (min 4, max 5): Valore basso, 'q' è rara.

r (min 5, max 7): Valori medi.

s (min 5, max 7): Valori medi.

t (min 8, max 10): Valori medi/alti.

u (min 11, max 13): Valore alto, 'u' è abbastanza comune.

v (min 2, max 3): Valore basso, 'v' è rara.

Esempio di Interazione Utente (ipotetica):

Citazione

Codice: [Seleziona]

ESTREMO INFERIORE A (MIN. 12)? 12
ESTREMO SUPERIORE A? 15

ESTREMO INFERIORE B (MIN. 1)? 1
ESTREMO SUPERIORE B? 2

ESTREMO INFERIORE C (MIN. 5)? 5
ESTREMO SUPERIORE C? 7

... e così via ...

INIZIATA RICERCA PANGRAMMI
ATTENDERE PREGO!

QUESTO PANGRAMMA TROVATO CON IL
COMMODORE SESSANTAQUATTRO CONTIENE:
UNDICI A, UNA B, SEI C, CINQUE D,
DODICI E, UNA F, DUE G, UNA H,
CINQUE I, DUE L, CINQUE M, DODICI N,
DODICI O, DUE P, QUATTRO Q, CINQUE R,
SEI S, OTTO T, UNDICI U, DUE V,
E UNA Z.

Come questi input influenzano il codice assembly:

Gli input dell'utente vengono scritti nella pagina $C2xx, quindi le istruzioni LDA $C2xx nel codice assembly leggono direttamente questi valori.

I limiti min/max vengono usati per i confronti all'interno del ciclo di ricerca. Il codice assembly confronta il numero di occorrenze di ogni lettera con questi limiti e decide se accettare o rifiutare la combinazione corrente.

La scelta degli input influenza direttamente il tempo di esecuzione. Se i limiti sono troppo restrittivi, il codice potrebbe impiegare molto tempo per trovare una soluzione (o non trovarla affatto).

Prossimi Passi:

Debug con gli input ipotizzati: Prova a eseguire il programma nel VICE con questi input ipotizzati e usa il debugger per vedere come il codice assembly reagisce.

Identificare la tabella di salto: Cerca di capire quali condizioni attivano i diversi salti nella tabella di salto. Questo ti darà un'idea di come il codice gestisce le diverse situazioni.

Analizzare il codice intorno ai salti: Analizza il codice immediatamente prima e dopo le istruzioni BNE e JMP per capire cosa viene confrontato e cosa succede quando il salto viene eseguito o non eseguito.

Quindi sembra che il codice funzioni anche sulla macchina reale anche se io personalmente non sono ancora riuscito a verificarlo nella pratica.

I pangrammi, ah che nostalgia! ))

Sembra ieri (magari!) quando lessi per la prima volta dei pangrammi, proprio su CCC numero 33, e fui subito affascinato dall'idea...

In un pomeriggio o due mi misi all'opera e digitai pazientemente tutti i numeri del listato, li ricontrollai e diedi il RUN: avrei sicuramente trovato per primo la soluzione al pangramma italiano.

Un'ora, due ore, otto ore, ventiquattro ore... niente!

Avevo sbagliato qualcosa, un bug si era insinuato da qualche parte, le mie stime erano errate? Mah! Purtroppo non cavai un ragno dal buco, forse la ricerca avrebbe impiegato davvero troppo tempo o forse il pangramma proposto era matematicamente impossibile... senza un controesempio era difficile verificare qualunque ipotesi!

Poco male, qualcun altro ci riuscirà al posto mio e pubblicherà i suoi risultati in un prossimo numero di CCC... e invece niente!

La news di Ready64 mi ha riacceso la lampadina: con i teraflops a disposizione di chiunque non sarà più un problema tentare una ricerca, resta solo da scrivere il programma!

E qui casca l'asino, perché il lavoro, la famiglia, le cavallette e le inondazioni ci mettono del loro... Cosa fare?

Naturalmente, rivolgiamoci al fantastico mondo dell'open source e troviamo una risposta: la risposta si chiama "Seppy" (https://github.com/garydoranjr/seppy), un pratico programma in Python per la ricerca di pangrammi, ma in inglese!

Poco male, in pochi minuti aggiorno il programma a Python3, localizzo i testi in italiano e limito la ricerca alle lettere dell'alfabeto senza "jkwxy" per rientrare nelle condizioni proposte da Antonio Visconti nel suo articolo.

Avvio un po' trepidante il programma e, RULLO DI TAMBURI, dopo pochi minuti ecco qua la soluzione!

QUESTO PANGRAMMA TROVATO CON IL COMMODORE SESSANTAQUATTRO CONTIENE SEDICI A, UNA B, DODICI C, QUATTORDICI D, VENTIQUATTRO E, UNA F, DUE G, UNA H, VENTIDUE I, DUE L, CINQUE M, DICIANNOVE N, QUINDICI O, DUE P, SETTE Q, SETTE R, UNDICI S, VENTUNO T, DICIASSETTE U, SEI V, E UNA Z.

Finalmente!!!

Non sempre la ricerca va a termine, sembra che certe condizioni iniziali non portino ad una soluzione, ma certamente possiamo dire che

AL GIORNO D'OGGI NON E' PIU' COSI DIFFICILE TROVARE UN PANGRAMMA IN CUI CI SONO QUATTORDICI A, UNA B, QUATTORDICI C, DIECI D, VENTI E, TRE F, CINQUE G, UNA H, TRENTA I, TRE L, TRE M, DICIANNOVE N, TREDICI O, TRE P, SETTE Q, QUINDICI R, QUATTRO S, VENTI T, TREDICI U, CINQUE V, E UNA Z.

Saluti, e buona esplorazione dello spazio dei pangrammi!!!!

Purtroppo il video non è disponibile, comunque nella puntata del 29 gennaio '25, al gioco de "l'Eredità" 'Gli anni', viene citato il 1986 come anno in cui il Commodore 64 risulta essere il computer più venduto della storia.

Ed andiamo al periodo più complesso, dalla nascita del C64 fino a metà degli anni 90. Qui, inizialmente, si è cercato di raccogliere le indicazioni riportate da alcuni siti che fornivano date precise (gamesdb.launchbox-app.com / thegamesdb.net / everygamegoing.com). Il problema nacque subito in quanto non vi erano citate le fonti a cui si erano attenuti e, peggio ancora, per lo stesso titolo spesso vi era discordanza tra di loro. Un metodo subito scartato perché senza un minimo di accuratezza o riferimento accreditato si poteva cadere nella contestazione legittima di un qualsiasi utente. Si doveva dare corpo solido a qualsiasi data riportata. La soluzione venne ricercando tra le riviste del tempo, soprattutto quelle di origine del gioco e la fortuna volle che conobbi così il magazine ‘Video Game Update – Computer Entertainer’ che mensilmente, nelle sue pagine, riportava il mese di pubblicazione, aggiornato di volta in volta, fino alla definitiva pubblicazione accompagnata alle volte dalla recensione. Ma essendo di origine statunitense andava bene per i primi anni, poi la maggior parte dei giochi ebbe più seguito in Europa e non andava bene. Un’intensa ricerca di altri magazine ha permesso di unire vari periodi storici e di aggiungere così altri metodi di ricerca. Utilissime sono state delle pubblicità dove il publisher indicava la data specifica di uscita del proprio gioco e dei cataloghi come quelli dalla SSI che fornivano anche qui mesi e giorni specifici. La comparazione con queste informazioni ha permesso poi di individuare dei siti internet di catalogazione di giochi, MobyGames, più di tutti, che fornivano dati corrispondenti e pertanto attendibili. Quindi ogni mese o giorno inserito non è stato riportato da una singola fonte, ma la somma di vari attori che nel tempo avevo trascritto ed utilizzato come consultazione e approfondimento. Presi anche in considerazione CSDb, noto sito di distribuzione di giochi craccati, in quanto riporta giorni o mesi specifici di software sprotetto del periodo storico interessato, anche se ne ho tenuto conto come un database di verifica osservando le prime date di sprotezione indicate e il numero maggiore di versioni pirata in uno specifico mese. Due siti, “Lemon64” ma soprattutto “amr.abime.net” un sito dedicato all’Amiga, sono serviti per trovare le recensioni nei magazine più conosciuti e utilizzare questi dati per scremare quel giornale (o giornali) che prima di tutti aveva redatto la recensione, utile dato in quanto, dopo vari confronti, indice di uscita del gioco o nello stesso mese o in quello precedente. Sempre dalle riviste un’occhiata andava fatta alle preview anche qui fonte di preziosissime informazioni dove ho trovato mesi di riferimento alla pubblicazione o almeno testo di comparazione con la successiva recensione. Un grande aiuto è scaturito dalla scoperta in rete di siti con fonti attendibili e certificate anche se specifiche come “segaretro.org” dedicato ai titoli Sega di tutte le macchine da gioco esistenti e “kpolsson.com/c64” delle pagine con una cronologia di dati presi da riviste e magazine vari. Infine la scoperta di pagine web ufficiali come il sito governativo statunitense “publicrecords.copyright.gov” che riporta la data esatta di pubblicazione di quasi tutti i giochi Activision più qualche altro titolo e la pubblicazione di fax aziendali redatti da M.Tomczyk verso Bill Wade e Tramiel targati 1982 che indicano le prime uscite di giochi per il C64 e la MAX Machine Giapponese. Ultimissima operazione una ricerca generica su Google, Wikipedia e c64-wiki.com a caccia di qualche informazione utile nella speranza di essere baciati dalla fortuna.  :crystal:
Posto un esempio:
Out Run (versione europea) / 10 Dicembre 1987 / Dati estratti: Mese con più Crack (CSDb) a Dicembre 1987 (52 in totale). Prime recensioni Gennaio (Commodore User Jan89, Datormagazin n.1). Preview the Game Machine (inglese) n.1 pag 13 che riporta uscita Dicembre. Data esatta (10 Dic) estratta da una pubblicità a pagina 137 di C&VG jan 1988.

Fonti non indicate in precedenza: tcrf.net, mocagh.org, spectrumcomputing.co.uk, retrocollector.org e altri.

Magazine: New Computer Express, Home Computing Weekly Magazine, Zzap!64 inglese e italiano, Commodore User, Computer & Video Games (C&VG), the Game Machine (inglese), Datormagazin, ACE: Advanced Computer Entertainment, Joystick (francese) e altri.

---

 :logorrea: Giuliano "Phobos" Brunetti