Entombed è un gioco per Atari 2600 che nessuno sa come è stato programmato

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

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.

Assembly.

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

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.

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.

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).

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.

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

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.