La gestione dei file di dati si sta rivelando più complessa del previsto.
Il fatto è che questo genere di file (che come sappiamo non vengono caricati
usando la LOAD,bensì con una OPEN) devono risiedere interamente nel buffer
di cassetta (locazioni $33c-$3fb);ergo,i file dati più lunghi di 192 bytes
risultano "spezzati" in chunk (ciascuno lungo 192 bytes) e caricati in più
colpi.
Ora,nel caso si trovi a che fare con un file di dati,per quanto detto un pò
di post addietro il manager potrebbe gestire la situazione in questo modo
1.Se non ci sono errori nei dati del chunk passa al chunk
successivo,altrimenti
- se hai l'ordine di recuperarne la copia,vai in 2
- altrimenti,passa al chunk successivo
2.Non appena ricevi un impulso lungo,vai in 3
3.Se hai trovato una copia del chunk passa al chunk successivo,
altrimenti
- se hai l'ordine di abortire la ricerca,termina
- altrimenti,torna in 3
Questo processo andrebbe iterato fino a che non si incontra l'ultimo
chunk (che contiene un byte $0) o la fine del file (nel qual caso
l'entry viene scartata perchè incompleta).
Le difficoltà maggiori stanno nell'analisi e gestione di ogni
singolo chunk,in quanto per una successiva visualizzazione occorre
compattare tutti i chunk (nel caso siano più d'uno) e distinguere per
ciascuno di essi l'originale dalla copia (nel caso in cui l'utente
abbia spuntato l'opzione corrispondente).
Inoltre,dato che il codice per la gestione dei suddetti file sembra
destinato a "esplodere",a questo punto non so davvero se sia meglio
tenerlo in un'unica funzione (che si occupa di recuperare i chunk di
dati sia per i file programma che per i file di dati) oppure definirne
un'altra prevista appositamente per questo scopo.Boohh...
Ogni consiglio in proposito è ben accetto
Saluti
