Ready64 Forum
Commodore 64 => Segnalazione News => Topic aperto da: iAN CooG - 08 Ottobre 2005, 23:27:39
-
Sistemati alcuni bachi, tra cui anche un problema di CIA timing (Athena e BigFoot Adventure ora funzionano) e l'emulazione della rs232 (cosi' gli utenti QLink saranno contenti). Aggiunte le emulazioni di alcune espansioni come la +60K, tanto amata nell'est europa.
Ma ecco l'annuncio:
Version 1.17 of VICE, the Versatile Commodore Emulator, has been
released.
VICE emulates the Commodore C64, C128, VIC20, PET 8-bit computers,
PLUS4 and the CBM-II (aka C610) and is completely written in C/C++; it
runs on Unix, Win32, MS-DOS, RiscOS, OS/2, BeOS and QNX systems.
VICE is *free* software released under the GNU General Public License,
and as such it comes with full source code.
Most important changes since the last version include:
* Changes in VICE 1.17
======================
** General
----------
- Compiling for QNX 6.x works now (binary package is available).
- Binary packages for Solaris machines are available.
** C64 changes
--------------
- Added full GeoRAM memory expansion support with sizes from 64KB to
4MB.
- Added full RamCart memory expansion support.
- Added full +60K memory expansion support.
- Correct REU values after reset.
** C128 changes
---------------
- Added full GeoRAM memory expansion support with sizes from 64KB to
4MB.
- Added RamCart memory expansion support without the read-only option.
- Fixed some C64 mode bugs.
- Correct REU values after reset.
** Unix changes
---------------
- New dutch translation.
- Language support has been extended to include commandline-options.
- BSD platform problems with using the sounduss and soundsun driver
have been fixed.
- Problems compiling with older versions of libpng have been fixed.
- Problems with MAXPATHLEN and PATH_MAX when compiling have been
fixed.
- New ALSA sound driver.
- Fixed some compile errors if GCC4 is used.
- Added support for more analog joysticks.
** MS-Windows changes
---------------------
- Added international language support (experimental, disabled for
now).
- The Wine Resource Compiler is now required to compile using gcc for
proper international language support.
- Added support for recent ffmpeg libraries.
- Fixed some directory lister bug.
** MS-DOS changes
-----------------
- Added ethernet support using the wattcp stack and libpcap library.
** Miscellaneous changes
------------------------
- Compiling without C++ or ReSID works now.
- Added support for more 3rd party basic extenders to petcat.
- Userport RS232 emulation should work as expected now.
The VICE 1.17 source archive is available at:
ftp://ftp.zimmers.net/pub/cbm/crossplatfo...ice-1.17.tar.gz (http://ftp://ftp.zimmers.net/pub/cbm/crossplatform/emulators/VICE/vice-1.17.tar.gz)
The VICE 1.17 MSDOS binary archive is available at:
ftp://ftp.zimmers.net/pub/cbm/crossplatfo...ICE/vice117.zip (http://ftp://ftp.zimmers.net/pub/cbm/crossplatform/emulators/VICE/vice117.zip)
The VICE 1.17 WIN32 binary archive is available at:
ftp://ftp.zimmers.net/pub/cbm/crossplatfo...inVICE-1.17.zip (http://ftp://ftp.zimmers.net/pub/cbm/crossplatform/emulators/VICE/WinVICE-1.17.zip)
The VICE 1.17 RiscOS binary archive is available at:
ftp://ftp.zimmers.net/pub/cbm/crossplatfo...-riscos1_17.zip (http://ftp://ftp.zimmers.net/pub/cbm/crossplatform/emulators/VICE/vice-riscos1_17.zip)
The VICE 1.17 BeOS binary archive is available at:
ftp://ftp.zimmers.net/pub/cbm/crossplatfo...CE-1.17.x86.zip (http://ftp://ftp.zimmers.net/pub/cbm/crossplatform/emulators/VICE/BeVICE-1.17.x86.zip)
The VICE 1.17 QNX 6.X binary archive is available at:
ftp://ftp.zimmers.net/pub/cbm/crossplatfo...-x86-public.qpr (http://ftp://ftp.zimmers.net/pub/cbm/crossplatform/emulators/VICE/VICE-1.17-x86-public.qpr)
For more information check out the VICE home page at:
http://www.viceteam.org/ (http://www.viceteam.org/)
MfG Andreas
-
Hanno corretto il problema di riconoscimento del loader delle Alga Soft? Perché se così non fosse forse è il caso di ricordarglielo visto che non l'hanno neanche messo nella KB (e glielo dissi ormai più di un anno fa).
-
Non credo che abbiano nemmeno dato importanza alla cosa. In fin dei conti le cassette si caricano no? E' solo un problema di riconoscimento dell'header dei programmi all'interno del fileselector, che purtroppo riconosce solo header standard.
E quelle dell'algasfot non lo sono sicuramente.
-
Non credo che abbiano nemmeno dato importanza alla cosa. In fin dei conti le cassette si caricano no? E' solo un problema di riconoscimento dell'header dei programmi all'interno del fileselector, che purtroppo riconosce solo header standard.
E quelle dell'algasfot non lo sono sicuramente.
Se intendi l'header vero e proprio, certo che è standard, altrimenti non si potrebbero neanche caricare con un banale LOAD :D (oppure, alla niubbo-style, shift+run/stop :D)
Per quanto riguarda l'importanza, tempo fa ho avuto un lungo scambio di mail con Andreas Boose (capo del VICE) e Markus Brenner (membro del VICE Team e autore di MTAP e PTAP), e con un CC al mio amico Carmine "TSM" (l'autore del programma STAP e JTAP).
Mi sembra (ma qui non sono sicuro xke vado a memoria e quelle mail non le ho più) che nella discussione c'era pure Fabrizio Gennari (autore di WAV2PRG).
Insomma, quelle mail erano tra i "capi" del formato .tap, quelli che l'hanno usato meglio nei loro programmi. Io stesso credo (forse erroneamente) di conoscere almeno un po' tale formato dopo i numerosi dump che ho fatto di cassette di ogni tipo (di cui ti assicuro solo una parte finora è stata resa disponibile on-line).
Sia Andreas che Markus mi avevano garantito che ci avrebbero guardato e avrebbero cercato di risolvere il problema.
Non sto dicendo che dovevano risolverlo con questa release (non ho nessuna fretta e come dici tu stesso è un bug "minore", ma ciò comunque non toglie che sia e rimanga un bug), ma m'aspettavo quantomeno l'avviso nella lista della KB.
E' probabile che se ne siano dimenticati di inserirlo nella lista (lista che del resto temo venga aggiornata assai poco); assai meno probabile che si siano dimenticati quantomeno di fare dei tentativi. Magari li hanno fatti e ci hanno rinunciato. Era più che altro una mia curiosità, per sapere dopo un anno se c'erano stati progressi :)
-
Se intendi l'header vero e proprio, certo che è standard
Sara'. A me non sembra, altrimenti vice li troverebbe anche nel fileselector. Forse sono talmente malridotti che andrebbero ridumpati, non so.
STAP
Con questo si puo' ovviare parzialmente, ho provato un tap algasoft e me l'ha splittato senza problemi. Poi con un breakpoint nel loader
.C:02f1 20 59 A6 JSR $A659
e si puo' salvare la memoria prima del run.
** Monitor 263 038
(C:$02f1) m ae af
>C:00ae 28 ac
(C:$00b0) > 01 38
(C:$00b0) s "game.prg" 0 0801 ac28
E si puo' buttare il tap intermedio a questo punto.
ma m'aspettavo quantomeno l'avviso nella lista della KB.
Molti fix e bugs non sono segnalati ne' nella KB ne nella NEWS allegata all'emulatore purtroppo, l'ho notato anche io.
-
Se intendi l'header vero e proprio, certo che è standard
Sara'. A me non sembra, altrimenti vice li troverebbe anche nel fileselector.
Ma il VICE non dovrebbe andare a cercare la parte che va dal LOAD al FOUND? E quella DEVE essere per forza standard, altrimenti come si farebbero a caricare?
Forse sono talmente malridotti che andrebbero ridumpati, non so.
Tendo ad escluderlo. Funzionano perfettamente, quantomeno la maggioranza dei file. Può capitare che uno o due giochi non vadano, ma il più delle volte non andavano neanche all'epoca. Potrebbe essere dovuto ad un problema all'origine o alla cassetta in mio possesso (quantomeno per i dump che ho fatto io). Ma il fatto che la stragrande maggioranza dei giochi carichi correttamente sia con CCS64 sia con VICE mi fa escludere categoricamente un problema nel dump o anche nei supporti (che erano di scarsa qualità, non lo metto in dubbio, ma che a distanza di una ventina d'anni funzionano ancora egregiamente, anche perché sono sempre stati trattati con i dovuti riguardi).
Nota: la maggioranza dei dump che trovi in rete proviene da cassette originariamente di proprietà di Archmage/Gamemaster) che mi ha regalato a patto che gliele dumpassi. Quasi tutte le MIE (nel senso che sono quelle che comprai all'epoca) AlgaSoft sono purtroppo non più in mio possesso. Una parte riuscii a recuperarla e di quella ci sono dei dump, non ancora resi pubblici.
STAP
Con questo si puo' ovviare parzialmente, ho provato un tap algasoft e me l'ha splittato senza problemi.
Dipende da quale hai provato. Io mi riferisco soprattutto al caricamento "con la bandiera italiana". Prova i numeri dal 10 in poi.
Gli altri vengono digeriti anche più facilmente. Se ci è riuscito, è la conferma che Carmine ha seguito il mio consiglio di considerare la parte dal LOAD al FOUND e di lasciare perdere tutto quello che viene dopo finché non trovasse un altro blocco dal LOAD al FOUND. Non so se mi spiego. Comunque una versione che ho io di STAP non funzionava bene con le Alga Soft "con la bandiera". E' possibile che la versione che avevo provato fosse precedente alla tua, però.
ma m'aspettavo quantomeno l'avviso nella lista della KB.
Molti fix e bugs non sono segnalati ne' nella KB ne nella NEWS allegata all'emulatore purtroppo, l'ho notato anche io.
Ok, m'aspettavo una cosa del genere. Allora non vuol dire che non ci stiano lavorando o che non se ne ricordano, semplicemente la KB non è aggiornata. :)
PS Comunque Markus Brenner sembra svanito nel nulla, Hiryu sta cercando inutilmente di contattarlo per spiegargli della mia Captain Miky II che non è riuscito ancora a dumpare (ce l'ha ancora lui).
-
Ho ricompilato WinVice con MSVC7.1, togliendo un po' di fuffa (traduzioni in varie lingue, occupavano circa 500kb) e il richiamo ai compressori esterni come unzip.exe, gzip.exe etc (rovinavano glia Archivi) e contrariamente da quanto detto da Spiro/ViceTeam, anche con la libPNG e Zlib (i gzip sono quindi supportati internamente, ma senza ricomprimere il d64)
http://iancoog.altervista.org/winvice117_m...P4_Zlib_png.rar (http://iancoog.altervista.org/winvice117_msvc71_P4_Zlib_png.rar)
- removed translated resources. Don't see any need of them.
- added a typecast in c64\georam.c just to clear an unnecessary warning
- added defines HAVE_ZLIB and HAVE_PNG in \src\ARCH\WIN32\MSVC\CONFIG.H
and libpng 1.2.3 + zlib 1.2.1 libs in MSVC project files.
Now native PNG screenshot and .gz expansion works even on MVSC.
Still wondering why they should be a problem...
- removed spawning of external decompressors (unzip, lha etc) because most of
the times the decompressed randomname would be recompressed inside the
archive.
example: alt-8, cursor over testme.d64.gz containing testme.d64, enter,
decompressed to c:\temp\sxyz0122.; use it just to load"$",8 etc,;
alt-x to exit vice, testme.d64.gz contains now sxyz0122. instead of
the original name, with current date instead of original d64 date.
This is just not acceptable and definately a bug.
I don't care opening gz/ziped d64 but only plain ones.
- ffmpeg 0.4.9-pre1 dlls not found. On the Vice site they still provide the
older 0.4.8 dlls, which are NOT usable with these sources.
I don't care rebuilding ffmpeg dlls myself. Never used and not my problem.
-
Grazie Ian,
ne approfitto subito e lo scarico. ;)
Ciao! :ciauz:
-
Siccome quelli di Viceteam non si decidono ad aggiornare le dll (sul sito ci sono ancora le 0.4.8 che non vanno piu' con la 1.17 di Winvice) ci ho pensato io a ricompilarle.
http://iancoog.altervista.org/ffmpeg-0.4.9-pre1.Win32Dll.rar (http://iancoog.altervista.org/ffmpeg-0.4.9-pre1.Win32Dll.rar)
-
Se intendi l'header vero e proprio, certo che è standard
Sara'. A me non sembra, altrimenti vice li troverebbe anche nel fileselector. Forse sono talmente malridotti che andrebbero ridumpati, non so.
Da uno sguardo superficiale (non ho visto i .TAP in questione) direi che iAN CooG ha ragione in parte, e Massi Cadenti ha ragione in un'altra parte. Lo header deve essere standard per forza, sennò i giochi non andrebbero con LOAD. Però il file selector di VICE ha un riconoscimento molto severo, che tende a non riconoscere gli header se non sono perfetti o quasi, pure se il loader del "kernal" del C64 li carica.
Hai provato a ripulire i file con Final TAP (anche lui abbastanza severo, spesso si rifiuta di ripulire molti file per imperfezioni non gravi)?
-
Hai provato a ripulire i file con Final TAP (anche lui abbastanza severo, spesso si rifiuta di ripulire molti file per imperfezioni non gravi)?
No. Purtroppo in questa settimana il tempo è stato poco, nel week-end cerco di darci un'occhiata facendo dei tentativi più approfonditi:
1) con STAP e poi JTAP e vedendo se il risultato viene riconosciuto dal VICE (ma ne dubito)
2) con FinalTAP (anche qui ho i miei dubbi se è severo come dici)
Ma a questo punto la domanda è: perché VICE non usa una riscrittura pari pari delle routine standard del kernel del C64 per riconoscere i file all'interno di un TAP? :doh:
Non capisco... E' questione di velocità o cosa? :huh:
PS Se non altro comunque ha un contagiri degno di tale nome (piccola critica al CCS64 :D )
[edit: forse ho capito: non è che lo fa per non avere dei falsi positivi? Ricordo che in molti caricamenti turbo, se non posizionavi bene il nastro, oltre al classico "READY." come se ci fosse un run/stop + restore, poteva apparire anche un "finto" FOUND pieno di caratteri pseudocasuali e spesso colorati (leggasi monnezza). Provare a caricare questo programma significava avere un out of memory immediato o un blocco del sistema, più tante altre cosette più o meno simpatiche. Forse VICE usa delle routine proprie per evitare questo? A questo punto dico si potrebbe ovviare in vari modi, ci vorrebbe qualcosa di analogo a Star Commander che funzioni con i TAP... sarebbe utile anche un "Go to XXX" dove XXX è il numero dei giri, tipo in certe cassette da 90 o 120 (!) minuti...]
-
Ma a questo punto la domanda è: perché VICE non usa una riscrittura pari pari delle routine standard del kernel del C64 per riconoscere i file all'interno di un TAP? :doh:
Non capisco la tua domanda, ma in ogni caso credo che non resti che martellare il viceteam di tap e richieste di implementazione.
-
PS Se non altro comunque ha un contagiri degno di tale nome (piccola critica al CCS64 )
In effetti pare incredibile che il CCS64 (almeno fino alle versioni 2.x) abbia una lacuna così grossa.
-
in ogni caso credo che non resti che martellare il viceteam di tap e richieste di implementazione.
Siccome quelli di Viceteam non si decidono ad aggiornare le dll (sul sito ci sono ancora le 0.4.8 che non vanno piu' con la 1.17 di Winvice) ci ho pensato io a ricompilarle.
http://iancoog.altervista.org/ffmpeg-0.4.9-pre1.Win32Dll.rar (http://iancoog.altervista.org/ffmpeg-0.4.9-pre1.Win32Dll.rar)
[/QUOTE]Ho ricompilato WinVice con MSVC7.1, togliendo un po' di fuffa (traduzioni in varie lingue, occupavano circa 500kb) e il richiamo ai compressori esterni come unzip.exe, gzip.exe etc (rovinavano glia Archivi) e contrariamente da quanto detto da Spiro/ViceTeam, anche con la libPNG e Zlib (i gzip sono quindi supportati internamente, ma senza ricomprimere il d64)
Ciao Ian,
perchè non gli invii (o gli comunichi) le tue modifiche. In questo modo potremmo trovarcele direttamente sulla prossima versione del Vice e credo che al Team di sviluppo del Vice farebbe piacere trovarsi il lavoro già fatto.
Continua cosi.
Alla prossima!
:ciauz:
-
Ciao Ian,
perchè non gli invii (o gli comunichi) le tue modifiche.
Non ho nessun problema a farlo, infatti non e' la prima volta che prima di postare qua le mie modifiche io le abbia gia' rese note su comp.emulators.cbm, visto che il viceteam risponde anche li'.
Chiunque puo' e deve farlo, senza delegare le proprie domande agli altri, primo perche' non vi mangia nessuno e secondo, nei forum italiani e' difficile che vengano a curiosare per vedere se c'e' qualcuno che ha delle proposte di miglioria, se possibile, con sorgenti gia' modificati.
Se poi le proposte/modifiche non vengono accettate (ad es. l'eliminazione delle risorse tradotte e della decompressione degli archivi tramite exe esterni, sono solo un mio "capriccio" personale, ormai la strada che seguiranno sara' quella), tanto peggio, ma non si sa mai.
-
Massi Cadenti,hai provato a ridumpare le cassette incriminate?Come ha detto iAN CooG,è possibile che VICE non riconosca l'header del programma se la conversione non è perfetta.
P.S.:hai usato mtap per la conversione?
-
La faccenda mi ha incuriosito,così ho provato a dare un'occhiata al processo di caricamento di alcuni .TAP che avevo lasciato nel mio HD.
-Boulder Dash
LM MSSMSMMSSMSMSMMS|SM LM SMSMSMMSSMSMSMMS|MS LM MSMSMSSMSMSMSMMS|MS LM
-1985
LM MSSMSMMSSMSMSMMMS|SM LM SMSMSMMMSSMMSMMSMMMS|MS LM MSMMSMSSMSMSMSMMS|MS LM
-Algasoft
A ) header non riconosciuta
LM MSSMSMMSSMSSSMMS|SM LM SMSMSMMSSMSMSMSS|MS LM MSMSMSSMSMSSSMMS|SS LS
B ) header riconosciuta
LM MSSMSMMSSMSMSMMS|SS LS SMSMSMMSSMSMSMMS|MS LM MSMSMSSMSMSMSMMS|SS LS
Dal diagramma risulta che la sequenza di impulsi di Boulder Dash e 1985 (la cui testata viene riconosciuta dal file-selector di VICE) è corretta,infatti la testata si apre con una coppia di impulsi lungo/medio (LM),seguiti da coppie di impulsi corto/medio (SM) e medio/corto (MS),che rappresentano rispettivamente bit 0 e 1; ogni byte è intervallato dalla consueta sequenza impulso lungo/medio (LM),come descritto anche nella specifica del kernel loader di Markus Brenner.
Ripetendo il processo con le cassette Algasoft,ho notato che molti impulsi sono a cavallo della soglia medio/corto,per cui si hanno coppie di impulsi corto/corto (SS) che non ci dovrebbero essere (ne ho trovate 3-4 ma ho analizzato solo i primi tre byte della sequenza di sincronizzazione);infatti,questi non corrispondono nè a un bit 0 nè a un bit 1 (almeno stando alle specifiche del kernel loader).
Nel secondo caso (in cui la testata del gioco sulla cassetta è riconosciuta) questi errori riguardano il bit di controllo (quelli rappresentati dalla coppia dopo il |),o al più le coppie di impulsi che separano tra loro i vari byte (una coppia di impulsi lungo/corto invece che lungo/medio),mentre nel primo caso (in cui la testata del gioco non è riconosciuta) riguardano anche i byte veri e propri della sequenza di sincronizzazione ($89,$88...$81).
E' probabile (e dico "probabile" perchè non ho visto il sorgente del file-selector) che siano proprio questi bit "fuori soglia" nella syncro-sequence ad impedire al file-selector di VICE di riconoscere la canonica serie $89...$81,e quindi l'header del programma, mentre le routine del kernal usano un qualche altro criterio che le rende più "tolleranti" agli errori.
-
E' probabile (e dico "probabile" perchè non ho visto il sorgente del file-selector) che siano proprio questi bit "fuori soglia" nella syncro-sequence ad impedire al file-selector di VICE di riconoscere la canonica serie $89...$81,e quindi l'header del programma, mentre le routine del kernal usano un qualche altro criterio che le rende più "tolleranti" agli errori.
Ottima analisi. Bene, direi che il mistero almeno e' svelato. Non risolto ma almeno si sa che non sono del tutto standard.
-
almeno si sa che non sono del tutto standard.
Peraltro,come si vede in "1985" si possono addirittura presentare delle triplette di impulsi corto/medio/medio (SMM) o medio/medio/corto (MMS) che vengono rispettivamente interpretate come fossero coppie di impulsi corto/medio (SM) e medio/corto (MS).
Cmq,secondo me è un problema di dump;tutti quegli impulsi di 2-3 cicli sotto soglia mi lasciano perplesso.
-
Massi Cadenti,hai provato a ridumpare le cassette incriminate?
All'epoca più e più volte perché non mi facevo capace del problema. Tieni conto che in quel periodo ho dumpato un sacco di cassette tra cui anche molte Formula64 che trovi sul sito di Edicola64, che vanno perfettamente e vengono riconosciute.
Oggi il PC che usavo per la conversione è fuori uso, e il PC di ora non posso usarlo perché dovrei usare un altro cavo e non ne ho diversi da quello.
P.S.:hai usato mtap per la conversione?
Ovviamente sì.
MTAP in DOS 6.22 puro (niente finestra) + cavo collegato a parallela e soundblaster (per i +5V) che dall'altra parte ha porta drive e piattina per il 1530/C2N. Su quest'ultima è attaccato un duplicatore di quelli che si usavano all'epoca per copiare le cassette, con due registratori attaccati: in "PLAY" alternativamente un C2N "taiwanese" (insomma quelli identici all'originale ma senza la scritta Commodore) oppure un 1531 (nero e con adattatore da C16 a C64) originale Commodore; in "REC" un registratore sfasciato ma che ha l'altoparlante interno, che mi serve per monitorare la pulizia del segnale.
Il registratore in "PLAY" è costantemente controllato a livello di azimuth (ne ho appunto due con due allineature diverse proprio perché ho cassette che richiedono allineature diverse).
Sono stati verificati e tarati su un C128 col programma "Oscilloscopio" e quello che ho usato per le Alga Soft è stato tarato proprio usando una Alga Soft (ovviamente funziona anche su altre cassette, tanto è vero che è quello che uso solitamente per i dump, tranne quando il dump non va perché tipo l'avevo registrato IO con allineature fuori standard all'epoca, ma non è questo caso).
Il PC usato è (era) un P233MMX con doppio boot Windows 98/DOS 6.22, e il cavo un semplice X1541 (niente diodi o altro) modificato con la porta tape e con l'attacco alla porta joystick della soundblaster (è uno dei motivi per cui non potrei ridumparlo oggi con quel cavo).
Cmq,secondo me è un problema di dump;tutti quegli impulsi di 2-3 cicli sotto soglia mi lasciano perplesso.
Ribadisco di escluderlo categoricamente, sia perché all'epoca feci la prova con lo stesso registratore collegato al mio C128 sia perché il caricamento avviene. E' molto più probabile che il problema sia all'origine, e cioè del povero Gargiulo ;)
Se (come credo) il caricamento che il VICE riconosce NON E' quello della "bandiera italiana", e quello che non riconosce è quello della "bandiera italiana", continuo a dire che il problema non è nel dump.
Forse col tempo (in fondo son passati dai 14 ai 21 anni) le cassette si saranno rovinate, è possibilissimo, ma continuo a dire che secondo me è un problema all'origine (SIA dell'header -non lo nego dopo un'analisi così approfondita e ineccepibile- SIA, però, anche del parse del VICE, che *comunque* ha il difetto di funzionare in maniera diversa dal kernel standard).
L'header doveva essere creato da qualche programma ad hoc (probabilmente un banale disk to tape autoprodotto, diverso dal "solito" disk to tape che penso abbiamo tutti usato almeno una volta) che andava a creare quello e la "schermata di caricamento".
Se proprio non potete credere che non sia un problema di dump, posso portare qualche Alga Soft a Hiryu (ammesso che non ne abbia lui) e farla dumpare a lui. Ma sono sicuro che il risultato sarebbe lo stesso.
Quindi, a meno che MTAP non dia i numeri (e non lo credo perché il file funziona come la cassetta originale, l'unico problema è il parse appunto), credo che ci si debba concentrare sul perché VICE non fa il parse, o perché il kernel normale carica... e cercare di mettere d'accordo i due, perché lo trovo strano :)
PS Rileggendo forse il mio messaggio può apparire polemico, non è assolutamente mia intenzione e se ho offeso qualcuno mi scuso in anticipo.
-
Caro Massi Cadenti,hai ragionissimo tu:non si tratta di un errore di dump,e adesso spiego il perchè.
Esaminando la cassetta AlgaSoft N.16 (lato A) col WAV-PRG di Fabrizio Gennari (fab),mi sono accorto di una cosa strana:il programma trova nel .TAP un mucchio di impulsi anomali nell'header (appunto delle coppie corto-corto di cui parlavo in precedenza,che nei byte di dati dell'header non dovrebbero esserci).
L'header del nastro viene registrata in duplice copia;la prima copia contiene
- la sequenza di sincro ($89...$81)
- i byte di dati e la somma di controllo
la seconda copia contiene
- la sequenza di sincro ($09...$01)
- i byte di dati e la somma di controllo
Le due copie dell'header sono identiche,a meno del MSB nella sequenza di sincro.
Nella cassetta esaminata,invece,la prima copia dell'header include un mucchio di coppie di impulsi SS (che di solito separano le due copie dell'header):questo spiega il perchè dello strano comportamento del WAV-PRG.
Non solo:la seconda copia dell'header inizia subito con i dati (senza sequenza di sincro $09...$01);forse il VICE opera un confronto tra le parti dati delle due copie dell'header.
Se l'esito del confronto è negativo perchè le due parti dati "non combaciano",ecco spiegata anche la defaillance del fs dell'emulatore.
Comunque per ora ho esaminato solo i primi due programmi del .TAP.
Rimando ai prossimi giorni per eventuali news:intanto vedrò di parlarne con Fabrizio Gennari (e magari anche col ViceTeam).
Ciao
-
Intanto grazie ad Alberto, che mi ha fornito un file TAP da analizzare.
Apparentemente, i file in questione hanno uno "header chunk" monco: la lunghezza dovrebbe essere 192 byte+1 byte di checksum, ma in questo caso sono 179 byte+ 1 byte di checksum. Evidentemente, il loader nel kernal del C64 accetta lo stesso questi file, perché la checksum è corretta, ma non seguono lo standard, ed è per questo che il file selector di VICE non li riconosce (e neanche WAV-PRG).
In pratica i programmatori di questi crack hanno usato un trucco un po' sporco, che sfrutta un bug nel loader originale del C64: uno header non standard, ma che viene accettato per qualche strano motivo. Mi pare che anche in alcuni programmi CRL ci fossero "header chunk" di questo tipo.
Una teoria è: ogni byte inizia con LM, ed è seguito da 9 bit, che sono SM o MS (il nono è il controllo di parità). Dopo l'ultimo byte, c'è LS. Evidentemente, il kernal loader, appena vede LS, considera finito il caricamento anche se il numero di byte caricati è inferiore a quello atteso.
Final TAP riconosce questi header: evidentemente Subchrist era già a conoscenza di questo trucco, perciò il suo programma riconosce correttamente uno "header chunk" di 179 byte.
-
Ciao Fabrizio
(Ehp...ti ho mandato la mail di risposta senza aver prima letto il forum,non pensavo che fossi così tempestivo :D ).
Evidentemente, il kernal loader, appena vede LS, considera finito il caricamento anche se il numero di byte caricati è inferiore a quello atteso.
A ulteriore conferma di questa ipotesi c'e' il fatto che VICE riempie il buffer solo fino a $03f0 (escluso) invece che fino a $03fb (incluso).
In serata invio al ViceTeam un bel "bug report",chissà che non provvedano già nella 1.18.
Grazie per la conferma
Bye
-
Ragazzi, non ho parole :hail:
-
una bella notizia ,
bravi per l'ottimo lavoro svolto
-
Ragazzi, non ho parole
una bella notizia ,bravi per l'ottimo lavoro svolto
Eh eh,aspettiamo prima di cantare vittoria...
Cmq,ho inviato a Boose e soci il formato dettagliato dell'header + il .TAP annesso e spiegato la (pressochè certa) causa del bug;questo dovrebbe aumentare le probabilità che intervengano rapidamente (e compensare il mio inglese maccheronico :D ).
E se non si svegliano,mi sa tanto che farò un bel viaggetto nei sorgenti del VICE. :)
Ciao
-
Cmq,ho inviato a Boose e soci il formato dettagliato dell'header + il .TAP annesso e spiegato la (pressochè certa) causa del bug;questo dovrebbe aumentare le probabilità che intervengano rapidamente (e compensare il mio inglese maccheronico :D ).
E dire che glielo avevo segnalato già 2 anni fa, ma ovviamente senza le scoperte tecniche che nel tempo sono uscite fuori ;)
-
A proposito di scoperte...
L'annoso problema di Vice che mostrava poche linee (271 in PAL, 226 in NTSC) era risolvibile con pochissime modifiche.
http://iancoog.altervista.org/WinVice117_X...heightmaxed.rar (http://iancoog.altervista.org/WinVice117_X64X128_heightmaxed.rar)
600kb, solo x64.exe, x128.exe e il sorgente con le #define modificate.
In modalita' PAL ora si vedono persino troppe righe, in modalita' NTSC purtroppo ho potuto allargare solo di 4 linee altrimenti non partiva nemmeno. CCS 2.0 per la modalita' NTSC rimane ancora indispensabile.