Fare di NTSCità, virtù!

Ché quando cresci, con il senno di poi capisci molto ma molto meglio (forse... :P ) svariate situazioni delle quali probabilmente non eri nemmeno lontanamente consapevole, in gioventù.
Per esempio, quando eravamo bimbi, ci limitavamo a giocare con i nostri fidatissimi "Commodore 64" senza porci il problema della natura dell'"hardware" che avevamo per le mani.
Men che meno eravamo al corrente della sostanziale divisione che esisteva tra le nostre macchine europee ("PAL") e quelle contemporaneamente vendute nel comprensorio americano ("NTSC"). Della serie, anche se il "C64" era di fatto sempre lo stesso "computer" dappertutto, la necessità di collegarlo ad un sistema video ingegnerizzato in maniera diversa nei vari paesi dove veniva distribuito, finiva per creare delle incompatibilità tra le due versioni del medesimo calcolatore elettronico.
Per dire delle banalità: il "refresh rate" dello schermo delle due suddette macchine avveniva a velocità differenti (50 aggiornamenti al secondo per il sistema "PAL" contro i 60 dell'"NTSC"). Quindi, se un determinato programma adoperava la frequenza di aggiornamento dello schermo come "timer" per regolare determinati eventi "software", il codice ottimizzato per una macchina andava fuori sincrono se eseguito sull'altra e viceversa. ...E ancora, il "C64 PAL" computava 19656 cicli per ogni aggiornamento dello schermo (il 15% in più della controparte "NTSC", che si fermava a 17095). Quindi, se su una macchina "PAL", un "software" era ottimizzato per consumare tutte le risorse a sua disposizione tra un aggiornamento video e l'altro, lo stesso programma, in ambito "NTSC", non riusciva a starci dentro... Senza contare tutte le ulteriori problematiche di sincronizzazione che potevano insorgere se e quando il codice si aspettava di poter eseguire un preciso numero di istruzioni per "raster line", oppure nel caso in cui il programma voleva svolgere una particolare operazione quando la scansione video aveva superato la 263° linea (ché un sistema "PAL" ne scansionava 312, ma l'"NTSC" no! ...Si fermava proprio a 263!!! :D ).
Risultato: nei rutilanti anni ottanta, un titolo europeo per "C64" poteva essere radicalmente differente dal medesimo videogioco sviluppato per il mercato americano, ché se provavi ad importare ed esportare, avevi solo problemi, quando riuscivi a far funzionare qualcosa... :P

"Bionic Commando EU". "Commodore 64", 1988.

"Bionic Commando US". "Commodore 64", 1988.

In questo quadro, aggiungiamo un'ulteriore considerazione: i videogiochi concepiti per il mercato statunitense, solitamente facevano alquanto cagare erano affidati a sviluppatori molto meno competenti rispetto ai programmatori del vecchio continente, con risultati perlopiù sotto gli occhi di tutti.
Ora, vi pare che gli statunitensi, consci di questa situazione, se ne siano rimasti con le mani in mano, accontentandosi di giochicchiare con le loro conversioni dei poverissimi, mentre noi europei ci sollazzavamo con dei videogiochi di ben altra caratura?!
CERTO CHE NO!!! :D
...E fu così che in quegli stessi anni incominciò a prendere piede l'arte dell'"NTSC fixing"! Ovvero: gli "sceners ameerighani" scesero in campo e si interessarono direttamente al problema!
Con le loro abilità di "cracking", unite alla comprensione delle aree di memoria da far investigare al "software" per fargli capire se una determinata macchina era "PAL" oppure "NTSC", questi pionieri si inventarono dei sistemi di "fixing" delle "routines video" dei giochi in grado di renderli quasi sempre indipendenti dalla piattaforma utilizzata per la loro esecuzione! (Fatte salve le rare eccezioni che confermano le regole... ;) ).

Ché se non ho capito male, "Turrican" o te lo giochi "PAL", o te lo giochi "PAL"!
(Ché non si fixa nemmeno ad implorarlo in binario!!! :D ).

Morale: se domani, navigando il "CSDB", vi imbattete in una "release" contrassegnata con la "tag" "[NTSC/PAL]", sapete di cosa stiamo parlando! :)