[zxspectrum] Re: Jonathan Cauldwell

  • From: Luca Bisti <lucbisti@xxxxxx>
  • To: zxspectrum@xxxxxxxxxxxxx
  • Date: Tue, 30 Aug 2011 22:45:14 +0200

Ciao Alessandro!

Il 30/08/2011 21.35, Alessandro ha scritto:
On Tue, 2011-08-30 at 20:12 +0200, Alessandro wrote:

Stavo pensando ad una soluzione di questo tipo, da proporre anche ad
Alessandro D.: modificare la ROM identificando il punto in cui viene
"restituito un byte" dalla lettura del nastro: la nuova routine
dovrebbe semplicemente leggere il byte da una porta I/O, presso la
quale un
Ancora meglio: avendo da piccolo :-) portato le routines di gestione del
nastro su un altro oggetto Z80, ricordavo vagamente l'esistenza di una
routine ben precisa, che andando a rivedere e' la favolosa LD-BYTES
all'indirizzo $556 della ROM.
Ti sei risposto da solo: nel caso di loader ROM, il cosiddetto flash loading è implementato dagli emulatori trappando proprio la routine LD-BYTES come dici tu, con l'unica accortezza di gestire bene le varie condizioni di uscita in quanto a stato dei flag e del contenuto dei registri. Ti posso dire che per motivi legati all'accuratezza dell'emulazione RealSpectrum intercettava la routine in po' più in profondita', esattamente all'indirizzo 0x56C (LD-START) e ritornava il controllo in un paio di punti possibili (0x56F oppure 0x5DB) a seconda dell'esito dell'operazione di lettura del blocco.

Piu' o meno con lo stesso criterio si puo' generalizzare il flash loading a qualsiasi loader, es. i turbo commerciali (Speedlock, Alcatraz, Bleepload, ecc) tramite TZX: quello che cambia sono gli indirizzi dei trap (ci vuole una routine che faccia l'autodetect del loader, al momento opportuno) e ovviamente le condizioni di ingresso e di uscita da rispettare.

Il passo ulteriore per generalizzare ancora di più, riducendo pero' notevolmente l'accelerazione ottenuta, è il cosiddetto fast loading (o edge loading, o altri "trademark" ancora). Quando un emulatore non riconosce alcun loader supportato, cerca tramite un algoritmo euristico una routine di edge-loading (tipo la LD-EDGE1 della ROM). L'algoritmo tipicamente va alla ricerca di alcuni pattern di istruzioni tipici degli edge loaders, es. combinazioni di XOR / AND ravvicinate con IN(0xFE) e viene triggerato periodicamente quando si rileva che la porta 254 viene campionata molto frequentemente, come accade appunto durante un caricamento da nastro. Se la detection da' esito positivo, la fase successiva consiste nel riconoscimento del tipo di edge-loader (sono molti meno dei loader esistenti, piu' o meno la tecnica è sempre la stessa) e nel suo trapping opportuno. In questo modo si riesce a passare alla routine custom un bit alla volta e il risultato è come se i dati fossero stati salvati a una velocità tendente a infinito (durata degli impulsi su nastro = zero), ma il tempo di caricamento non viene totalmente azzerato in quando la routine esegue comunque diverse istruzioni in loop molto stretti. Chiaramente una soluzione del genere è decisamente poco praticabile in hardware.

Vorrei essere stato chiaro ma non ci spero troppo :-)

Da una occhiata al sorgente, mi sembra che venga chiamata con il
puntatore alla ram in IX e nbytes in DE, col carry che indica se e' un
verify (reset) o un load (set) e A indica se e' un header o un
datablock.
Esatto.

Se noi sostituissimo quella routine con un qualcosa che legga
altrettanti bytes da un altro dispositivo, ad esempio una sd-card, dite
che funzionerebbe?
Non vedo perché no :-)
Occhio a gestire bene il controllo del flag e del checksum, rispettivamente il primo e l'ultimo byte del blocco TAP, il cui conteggio non è incluso nella lunghezza passata in DE.



Ovviamente non potrebbe mai funzionare con i 'turbo loader', ma non so
nemmeno se il formato .tap puo' concepirli.
No ci vuole il TZX. Tuttavia ci sono dei loader custom che caricano blocchi di dati salvati nel formato della ROM ma utilizzando una routine modificata che gira in RAM. Esempio: il loader con decompressore di Digisynth.

Luca

Other related posts: