Link alla notizia: https://gaming.hwupgrade.it/news/videogames/entombed-e-un-gioco-per-atari-2600-che-nessuno-sa-come-e-stato-programmato_90168.html

Esistono dei veri e propri "archeologi" digitali che studiano le tecniche di sviluppo dei vecchi giochi per le console Atari mirate a eludere gli stringenti limiti degli hardware di allora. Uno in particolare ha richiesto degli studi molto approfonditi...

Click sul link per visualizzare la notizia.

4kbytes si e no di codice da esaminare. Ammazza! Avrebbero messo in ginocchio anche denuvo questi qui.

"Lo ha creato mentre era ubriaco e il suo cervello in panne. Quando è tornato sobrio non si ricordava più come aveva fatto" ha detto Sidley alla BBC."

Vi sta pigliando per i fondelli, #sapevatelo
(e fa bene!)

"Lo ha creato mentre era ubriaco e il suo cervello in panne. Quando è tornato sobrio non si ricordava più come aveva fatto" ha detto Sidley alla BBC."

Vi sta pigliando per i fondelli, #sapevatelo
(e fa bene!)

giustissimo, altrimenti risalire al programmatore sarebbe stato semplicissimo, invece anche questa informazione è andata persa tra i fumi della perculata :ciapet:

Sono così tanti anni che nessuno fa ottimizzazione nello sviluppo che si è perfino persa conoscenza del concetto (per non parlare delle tecniche) e occorre studiarsi il software di 30 anni fa.

Il triste è che lo vedo anche con il software applicativo, non c'è la minima attenzione alle prestazioni. Esempio lampante: due select consecutive su due tabelle diverse invece di utilizzare una join per avere i due valori con una sola select.

Imbarazzante.

È quello che sostengo da anni,i vecchi programmatori erano più bravi e creativi di quelli moderni,dovevano scervellarsi per far funzionare bene un programma con pochi kb.
Con i tempi moderni e le potenze messe a disposizione,il programma risulta veloce anche se programmato con i piedi.

4kbytes si e no di codice da esaminare. Ammazza! Avrebbero messo in ginocchio anche denuvo questi qui.

:asd:

È quello che sostengo da anni,i vecchi programmatori erano più bravi e creativi di quelli moderni,dovevano scervellarsi per far funzionare bene un programma con pochi kb.
Con i tempi moderni e le potenze messe a disposizione,il programma risulta veloce anche se programmato con i piedi.

Quindi se non programmano in assembler sono degli sfigati? Se gli architetti non progettano una casa sistemando ogni singolo mattone invece di utilizzare un CAD apposito e' pure uno sfigato? E magari se sei un ingegnere elettronico se non metti tu ogni singolo transistor il circuito fa cagare... Ogni generazione utilizza i tool piu' avanzati di cui dispone, esattamente quale sarebbe il problema?

peccato che qui > https://en.wikipedia.org/wiki/Entombed_(Atari_2600) ci sia la spiegazione di come funziona il sistema di generazione del labirinto

Esattamente come dice l'articolo, la pagina wiki dice che viene utilizzata una look-up table, ma come hanno fatto a generarla e perche' funziona sempre ancora non e' chiaro. Esattamente cosa dice di diverso questa pagina?

poi la storia non ha alcun senso, anche scrivendo codice sotto stato di alterazione il sorgente resta, non è che si trasforma magicamente in compilato e non si puo' piu' leggerlo...

Per prima cosa, i sorgenti non sono disponibili, hanno analizzato direttamente il binario. In seconda battuta, i giochi si programmavano in assembler, quindi non e' che era molto diverso dal codice binario, a parte i commenti che potevano chiarire un po' di cose, ovviamente solamente se c'erano.

Se stai lavorando a un programma in C e vai a fare il debug di una parte direttamente in assembler ci sta, può capitare.

Interpretare da zero un programma non scritto da te e dissassemblato dal linguaggio macchina secondo me può essere ben più problematico.

l'assembler non è binario e nell'automazione industriale capita di controllare cosa ha combinato il compilatore C. Un firmwareista con buona competenza non ha grossi problemi a spiegarti come funziona l'algoritmo...

non è binario ma spesso cè una correlazione 1-1 tra codice assembler e codice binario tanto che si può passare da uno all'altro con un semplice libro dei vari opcode, ovviamente su cpu relativamente semplici, l'ho fatto mille volte su z80 e 8086 e se l'algoritmo non è più che semplice ti assicuro che non è facile capire cosa fa partedo solo dall'assembler, soprattutto se il codice viene ottimizzato da un buon compilatore tipo iar

Quindi se non programmano in assembler sono degli sfigati? Se gli architetti non progettano una casa sistemando ogni singolo mattone invece di utilizzare un CAD apposito e' pure uno sfigato? E magari se sei un ingegnere elettronico se non metti tu ogni singolo transistor il circuito fa cagare... Ogni generazione utilizza i tool piu' avanzati di cui dispone, esattamente quale sarebbe il problema?

Non ha colto assolutamente il succo del discorso. L'utente di prima ritengo intendesse dire che, 30-40 anni fa, erano OBBLIGATI a scervellarsi e OTTIMIZZARE le righe di codice per una serie di evidenti fattori quali le potentze in gioco e le memorie. Oggi, invece, si "crogiolano spesso sugli allori" in forza del fatto che tanto le CPU/GPU sono di una potenza "disumana" e che lo spazio abbonda. Tolte quelle due basi (ottimizzazione e linearità), va tutto a ramengo. Ciò non toglie che, anche oggi, saltino fuori ottimi giochi/software, ma spesso e volentieri essi non sono ottimizzati e lineari perchè..e qui torniamo al mio discorso iniziale. Il tutto è indipendente dal fatto di usare transistor o schede elettroniche oppure un CAD digitale in luogo del tecnigrafo: conta la mentalità e la voglia di ottimizzare risorse, codice e tutto il resto...
Come al solito, torniamo sempre al solito nodo: quando si era OBBLIGATI perchè o si faceva così o non si riusciva, era normale avere una certa logica di lavoro, oggi, avendo maggior libertà, non si attribuisce la giusta importanza a certe cose, vuoi per pigrizia, vuoi per comodità, vuoi perchè è tutto più veloce (nel senso che ciò che esce oggi, domani è già vecchio), vuoi perchè è tutto focalizzato al guadagno, ai soldi e c'è sempre qualcuno alla dirigenza che non ne capisce una mazza di ciò che sta dirigendo ed attribuisce ordini "ad minchiam".
Se io sono nostalgico? Assolutamente sì! E ritengo si lavorasse meglio un tempo (in tutti i settori), fermo restando che la tecnologia raggiunta oggi è un qualcosa di meraviglioso.

Per prima cosa, i sorgenti non sono disponibili, hanno analizzato direttamente il binario. In seconda battuta, i giochi si programmavano in assembler, quindi non e' che era molto diverso dal codice binario, a parte i commenti che potevano chiarire un po' di cose, ovviamente solamente se c'erano.

Assembly.

L'assembler non e' un linguaggio e' un compilatore.

Quindi se non programmano in assembler sono degli sfigati? Se gli architetti non progettano una casa sistemando ogni singolo mattone invece di utilizzare un CAD apposito e' pure uno sfigato? E magari se sei un ingegnere elettronico se non metti tu ogni singolo transistor il circuito fa cagare... Ogni generazione utilizza i tool piu' avanzati di cui dispone, esattamente quale sarebbe il problema?
Per fare un esempio in termini architettonici, è come se un architetto costruisse un palazzo di dieci piani ma con spazi abitabili pari a quelli di un bilocale, solo perché oggi costruire costa meno rispetto all'800.

peccato che qui > https://en.wikipedia.org/wiki/Entombed_(Atari_2600) ci sia la spiegazione di come funziona il sistema di generazione del labirinto

esatto... quindi genera la stringa "data" per la rappresentazione grafica linea per linea in tempo reale (o quasi, data la velocità dei processori dell'epoca). Chi ha avuto i primi rudimenti di programmazione passando per il Basic si ricorderà questa tecnica. Direi che il problema è prorpio qui. Chi scrive codice al giorno d'oggi non si preoccupa più di tanto di ottimizzare o a studiare tecniche di parcheoinformatica... tanto le risorse di calcolo che mettono a disposizione le macchine attuali possono agevolmente sopperire.
Mi stupisce di più che "ricercatori" blasonati si siano trovati in difficoltà, e questo la dice lunga. Nel trentennio dal '70 al '90 i pionieri della programmazione moderna hanno dovuto fare i conti con risorse macchina risicatissime rispetto le attuali (gettando le basi dei principali linguaggi di programmazione attuali). Oggi hanno vita comoda. Peraltro parlando di giochi, ma non solo, gli engine grafici tutt'ora in voga si basano e sviluppano su algoritmi che hanno avuto origine 20 o 30 anni fa... il chè è tutto un dire.

Quindi se non programmano in assembler sono degli sfigati? Se gli architetti non progettano una casa sistemando ogni singolo mattone invece di utilizzare un CAD apposito e' pure uno sfigato? E magari se sei un ingegnere elettronico se non metti tu ogni singolo transistor il circuito fa cagare... Ogni generazione utilizza i tool piu' avanzati di cui dispone, esattamente quale sarebbe il problema?

Programmano in assembly... assembler è il compilatore.
Non hai colto il ragionamento. Utilizzare i tools più avanzati è il mezzo, non il fine. Per progettare un palazzo utilizzi il CAD che è solo lo strumento, l'idea e l'ingegno sono esercizio dell'intelletto umano e sono loro a fare la differenza e portare il risultato all'eccellenza. Quello che succede aggigiorno è che spesso si trascura la "raffinazione" che solo l'ingegno umano, almeno per ora, può elaborare. la macchina è solo il mezzo... potentissimo, talmente potente che spinge l'uomo alla "pigrizia" se così vogliamo dire, accettando un risultato che troppo spesso non viene portato all'eccellenza. Poi si possono addurre un sacco di giustificazioni (rispetto di tempi, costi, specifiche, ecc, ecc...). In tal senso ci sono un sacco di esempi sotto gli occhi di tutti...

La questione non è che non si è capito come funziona il programma.

La questione è che il programma usa un metodo basato su una tabella che non è chiaro come sia stata pensata.

Quando ero giovane ho fatto dei programmi assembler su Sinclair ZX80 che ero riuscito a riparare ed espandere da solo vedendo gli schemi elettrici.

Poi è arrivato lo Spectrum con i suoi colori ed un basic semplice.
Per capire le potenzialità creai una copia del poker che andava di moda nei bar a quei tempi. Il problema era che le immagini delle carte occupavano troppo, così creai un metodo per disegnarle con i mattoncini della grafica del testo e allo stesso tempo creai un sistema di verifica del punteggio delle carte che avevi sullo schermo.
Il sistema capiva qual'era la tua mano con solo 6 righe di codice.

A distanza di quasi 40 anni ho ritrovato il codice (lo avevo scritto a mano su un blocco) e pur leggendolo, non riesco a capire completamente l'intuizione di allora che mi permise di creare quelle righe che con soli 4 confronti erano in grado di dirti cosa avevi in mano (dalla semplice coppia alla scala reale).

La questione non è che non si è capito come funziona il programma.

La questione è che il programma usa un metodo basato su una tabella che non è chiaro come sia stata pensata.

Ancora adesso in ambito embedded uso molto spesso le lookup table per rimpiazzare chiamate a funzioni o "foreste di if-then-else".

In questo caso è sufficiente analizzare come viene composto l'indice per selezionare di volta in volta un elemento della tabella.

In pratica, invece di fare una serie di confronti con successivi salti condizionali per decidere lo stato della prossima cella si compone un indice e si referenzia un valore precalcolato che corrisponde alla scelta finale che si raggiungerebbe facendo i confronti tra i valori che compongono l'indice.

Quello che probabilmente confonde i tipi che hanno analizzato il codice è che chi ha codificato la lookup table, aveva individuato i casi in cui certamente doveva esserci vuoto oppure muro, ma aveva poi lasciato "a scelta pseudo casuale" i casi in cui poteva andar bene sia vuoto che muro.

La questione non è che non si è capito come funziona il programma.

La questione è che il programma usa un metodo basato su una tabella che non è chiaro come sia stata pensata.

Quando ero giovane ho fatto dei programmi assembler su Sinclair ZX80 che ero riuscito a riparare ed espandere da solo vedendo gli schemi elettrici.

Poi è arrivato lo Spectrum con i suoi colori ed un basic semplice.
Per capire le potenzialità creai una copia del poker che andava di moda nei bar a quei tempi. Il problema era che le immagini delle carte occupavano troppo, così creai un metodo per disegnarle con i mattoncini della grafica del testo e allo stesso tempo creai un sistema di verifica del punteggio delle carte che avevi sullo schermo.
Il sistema capiva qual'era la tua mano con solo 6 righe di codice.

A distanza di quasi 40 anni ho ritrovato il codice (lo avevo scritto a mano su un blocco) e pur leggendolo, non riesco a capire completamente l'intuizione di allora che mi permise di creare quelle righe che con soli 4 confronti erano in grado di dirti cosa avevi in mano (dalla semplice coppia alla scala reale).

Come accade sempre
"Quando ho scritto quel codice, solo io e Dio sapevamo come funzionasse.
Oggi lo sa solo Dio" :D

La questione non è che non si è capito come funziona il programma.

La questione è che il programma usa un metodo basato su una tabella che non è chiaro come sia stata pensata.

Quando ero giovane ho fatto dei programmi assembler su Sinclair ZX80 che ero riuscito a riparare ed espandere da solo vedendo gli schemi elettrici.

Poi è arrivato lo Spectrum con i suoi colori ed un basic semplice.
Per capire le potenzialità creai una copia del poker che andava di moda nei bar a quei tempi. Il problema era che le immagini delle carte occupavano troppo, così creai un metodo per disegnarle con i mattoncini della grafica del testo e allo stesso tempo creai un sistema di verifica del punteggio delle carte che avevi sullo schermo.
Il sistema capiva qual'era la tua mano con solo 6 righe di codice.

A distanza di quasi 40 anni ho ritrovato il codice (lo avevo scritto a mano su un blocco) e pur leggendolo, non riesco a capire completamente l'intuizione di allora che mi permise di creare quelle righe che con soli 4 confronti erano in grado di dirti cosa avevi in mano (dalla semplice coppia alla scala reale).

Trovo questo genere di cose certamente impressionante ed e' capitato immagino a molti. Tempo fa mi appassionai di Arduino e creai un progetto partendo da zero, scrivendo il codice, leggendo datasheet per capire come poterlo realizzare, come funzionavano i componenti e direttamente su PCB pezzo per pezzo, traccia per traccia. Alla fine oggi farei "fatica" a ripercorrere tutti i ragionamenti fatti. A volte e' questione di motivazione e questioni di principio, a volte di convinzione in se stessi, si raggiungono capacita' per brevi periodi di tempo certamente superiori alla norma (del resto nella nostra normale quotidianita' intendo). Lo stesso vale nell'arte, nello sport, nel lavoro.
Questo dovrebbero capire taluni capi/e uffici nelle aziende che invece di creare nelle persone quelle condizioni per far si che questo genere di motivazione sia autogenerata (e almeno moralmente applaudita), non vedono quanto questo sarebbe produttivo.

Sono così tanti anni che nessuno fa ottimizzazione nello sviluppo che si è perfino persa conoscenza del concetto (per non parlare delle tecniche) e occorre studiarsi il software di 30 anni fa.

Il triste è che lo vedo anche con il software applicativo, non c'è la minima attenzione alle prestazioni. Esempio lampante: due select consecutive su due tabelle diverse invece di utilizzare una join per avere i due valori con una sola select.

Imbarazzante.
Già, ma c'è una scarsa cultura dell'ottimizzazione perché ormai abbiamo valanghe di risorse a disposizioni, e... le si usa.

Anche perché non ti puoi più permettere di scrivere codice assembly (o addirittura in linguaggio macchina, quando ho iniziato), perché la produttività è scandalosamente bassa.
È quello che sostengo da anni,i vecchi programmatori erano più bravi e creativi di quelli moderni,dovevano scervellarsi per far funzionare bene un programma con pochi kb.
Con i tempi moderni e le potenze messe a disposizione,il programma risulta veloce anche se programmato con i piedi.
No, non è una questione di bravura, ma di adattamento alle esigenze dell'epoca.

Quando hai poche risorse a disposizione o ti sbatti o sei fuori (Briatore dixit).

Adesso ne hai a vagonate, e quindi l'ottimizzazione è l'ultimo dei tuoi problemi, anche perché ci sono le scadenze impellenti e soffocanti.

Sono due epoche completamente diverse, insomma, e gli sviluppatori si sono semplicemente adattati.

"E' l'ambiente che fa l'uomo" (cit.)
Per prima cosa, i sorgenti non sono disponibili, hanno analizzato direttamente il binario.
I giochi all'epoca in questione si programmavano per lo più in linguaggio macchina e non in assembly. Quindi ti armavi di opcode table del processore (anche se alla fine la maggior parte li conoscevi a memoria), e ti facevi a mente i calcoli dell'offset per i salti "brevi".

Gli assembler, se c'erano, erano roba da elite.
In seconda battuta, i giochi si programmavano in assembler, quindi non e' che era molto diverso dal codice binario, a parte i commenti che potevano chiarire un po' di cose, ovviamente solamente se c'erano.
Non è certo la stessa cosa: i sorgenti assembly usavano label descrittive ed erano strapieni di commenti, anche un commento per riga per spiegare quello che si stava facendo.
l'assembler non è binario e nell'automazione industriale capita di controllare cosa ha combinato il compilatore C. Un firmwareista con buona competenza non ha grossi problemi a spiegarti come funziona l'algoritmo...
Un conto è controllare il tuo stesso codice (che anche se disassemblato rimane "riconoscibile"), e tutt'altra cosa prendere un binario sconosciuto, disassemblarlo, e cercare di capire cosa sta facendo il codice.
Se stai lavorando a un programma in C e vai a fare il debug di una parte direttamente in assembler ci sta, può capitare.

Interpretare da zero un programma non scritto da te e dissassemblato dal linguaggio macchina secondo me può essere ben più problematico.
*
non è binario ma spesso cè una correlazione 1-1 tra codice assembler e codice binario tanto che si può passare da uno all'altro con un semplice libro dei vari opcode, ovviamente su cpu relativamente semplici, l'ho fatto mille volte su z80 e 8086 e se l'algoritmo non è più che semplice ti assicuro che non è facile capire cosa fa partedo solo dall'assembler, soprattutto se il codice viene ottimizzato da un buon compilatore tipo iar
*
La questione non è che non si è capito come funziona il programma.

La questione è che il programma usa un metodo basato su una tabella che non è chiaro come sia stata pensata.

Quando ero giovane ho fatto dei programmi assembler su Sinclair ZX80 che ero riuscito a riparare ed espandere da solo vedendo gli schemi elettrici.

Poi è arrivato lo Spectrum con i suoi colori ed un basic semplice.
Per capire le potenzialità creai una copia del poker che andava di moda nei bar a quei tempi. Il problema era che le immagini delle carte occupavano troppo, così creai un metodo per disegnarle con i mattoncini della grafica del testo e allo stesso tempo creai un sistema di verifica del punteggio delle carte che avevi sullo schermo.
Il sistema capiva qual'era la tua mano con solo 6 righe di codice.

A distanza di quasi 40 anni ho ritrovato il codice (lo avevo scritto a mano su un blocco) e pur leggendolo, non riesco a capire completamente l'intuizione di allora che mi permise di creare quelle righe che con soli 4 confronti erano in grado di dirti cosa avevi in mano (dalla semplice coppia alla scala reale).
Io, invece, realizzai un disassemblatore / resourcer (si chiamavano così i programmi che generavano sorgenti assembly dal disassemblamento dei binari) proprio per il reverse engineering di quel gioco di poker in voga all'epoca (quello di CMC, col famoso "poker jollato" :D).
Era basato su processore 65C02 e coprocessore grafico Motorola (non ricordo la sigla al momento), e il committente mi aveva fornito pure un paio di schede madri (una con tutti i componenti dissaldati per ricostruire lo schema del PCB e capire dove andavano i segnali e cosa facevano). Realizzai anche un mio assemblatore basato su un mio linguaggio assembly di alto livello, per rendere più facile la scrittura di codice assembly.
Un lavoro immane, insomma, che oggi con Python avrei realizzato in meno di decimo del tempo...

E pure io ho problemi a rivedere il codice che avevo scritto, pur spesso commentato, per capire cosa diavolo facevano certe parti... :stordita:
Trovo questo genere di cose certamente impressionante ed e' capitato immagino a molti. Tempo fa mi appassionai di Arduino e creai un progetto partendo da zero, scrivendo il codice, leggendo datasheet per capire come poterlo realizzare, come funzionavano i componenti e direttamente su PCB pezzo per pezzo, traccia per traccia. Alla fine oggi farei "fatica" a ripercorrere tutti i ragionamenti fatti. A volte e' questione di motivazione e questioni di principio, a volte di convinzione in se stessi, si raggiungono capacita' per brevi periodi di tempo certamente superiori alla norma (del resto nella nostra normale quotidianita' intendo). Lo stesso vale nell'arte, nello sport, nel lavoro.
Questo dovrebbero capire taluni capi/e uffici nelle aziende che invece di creare nelle persone quelle condizioni per far si che questo genere di motivazione sia autogenerata (e almeno moralmente applaudita), non vedono quanto questo sarebbe produttivo.
Non è certo cosa facile: acquisire quella mentalità richiede parecchio tempo (e ovviamente una buona dose di creatività che non tutti possiedono).

Prendendo Arduino, qualche anno fa ho realizzato un progetto (inizialmente giusto per smanettare con qualcosa di nuovo. Poi è divenuto qualcosa di ben più serio) per il monitoraggio di certi dati, sfruttando la tecnologia LoRA / LoraWAN quale rete wireless a basso consumo per l'invio dei pacchetti.

Ebbene, usando la libreria standard di TheThingsNetwork (TTN) per LoRA il firmware occupava un sacco di spazio (usando uno schifoso Atmel AVR da due soldi con 28KB di Flash e appena 2,5KB di RAM), e non funzionava nemmeno bene. In particolare mi andava in blocco tutto con l'uso della funzionalità di adattamento automatico dello Spread Factor / Data Rate. Roba che mi ha fatto impazzire, e ho provato di tutto per farlo andare (compresi trucchetti sporchi. "Cose per cui il Dio della biomeccanica non mi farebbe entrare in paradiso").
Alla fine ho scaricato il manuale delle specifiche del chip LoRA (RN2483) e mi sono scritto da zero (in C) l'intero stack LoRa in un paio di settimane, implementando tutti comandi del chip, e creando una test suite di circa 200 test (se confronti i test del codice TTN sono semplicemente ridicoli: un paio che devi eseguire sulla scheda Arduino. Io ho ho scritto parzialmente un emulatore Arduino e i miei 200 test li eseguo da Visual Studio con le sue funzionalità di test).
Adesso funziona tutto alla perfezione (e il tutto vuol dire che dentro ci sta un parser ASCII per i sensori che usano questo formato, e uno SML/binario per gli altri. Più tutta la business logic necessaria, e una varietà di comandi per controllare lo stato della scheda), e tutto il firmware occupa circa l'80% dello spazio e dovrei avere anche più di 1KB di RAM libera.
Certo, c'è da dire che mi sono riscritto praticamente tutto (non uso nemmeno la classe String di Arduino né malloc/free varie, e mi sono scritto pure delle funzioni per il calcolo in fixed point), ma ne è valsa la pena.
D'altra parte son cose necessarie quando si lavora in ambito embedded: risparmiare anche un solo euro sui componenti può portare a risparmi (o guadagni, se sei tu a vendere le schede) notevoli, che compensano di gran lunga le settimane di lavoro di un programmatore.