Edicolac64 forum - il commodore 64 in italia
Comunicazioni da/con lo staff e con i dumper => Segnalazione giochi non funzionanti (ai dumper) e lista per eventuali FIX => Topic aperto da: koseidon72 - 15 Dicembre 2008, 19:49:05
-
Nel dettaglio:
I titoli dei giochi presenti sul sito sono in realta' le passwd e non i giochi veri e propri:
Qui di seguito riporto il nome dei giochi seguiti dalla passwd.
(La passwd non è necessaria per far funzionare il gioco se si decide di caricare il singolo programma
Valgono invece se si parte dal menù di ricerca automatica)
farwest = pistola
kung-fu = colpo
volpe del deserto = aereo
american football = meta
l'errante = schermo
invasion = luna
masters = laser
Il gioco Kung-Fu (diversamente da come è segnalato sul sito) non è funzionante.
-
Il gioco Kung-Fu (diversamente da come è segnalato sul sito) non è funzionante.
Hai provato a ripulirlo con Tapclean?
-
Si, ma senza nessun risultato
-
Ho mandato il tap a iAN CooG e me l'ha fixato, lo condivido:
http://www.megaupload.com/it/?d=L5MVSVME
-
Grande!
Ma come ha fatto?
Sarebbe interessante saperne di più sull'utilizzo e le opzioni di tapclean.
Ho provato con l'optimize di base e non andava.
-
Gliel'avevo chiesto già. Sto aspettando ancora una risposta.
-
Ecco, l'ho incontrato in chat su #ready64 e mi ha mandato una lunga spiegazione in mail. Copio integralmente il testo, non so cosa siano quelle scritte dopo il P.S. ma non è che abbia capito molto anche della spiegazione :superlol:
Il prg e' estraibile e perfettamente funzionante usando l'opzione -doprg.
Tutta la cassetta utilizza il Galadriel variante Poke/golden.
C'era solo un problema nel loader che sbagliava la SYS di inizio.
A fine caricamento infatti eseguiva una jmp $02AA, dove non c'e' niente, mentre
il programma caricava correttamente e ha una SYS2064 ($0810 in hex).
Basta dare
g 0810
dal vice monitor per sincerarsene, o alla peggio, resettare e dare sys2064,
anche se non mi fiderei: dopo il reset sicuramente qualche byte sara' perso.
Non ho idea se il nastro originale funzionasse o meno. Se fosse stato ok, allora
durante la conversione in tap qualcosa dev'essere andato storto e i 2 byte
nel loader che indicano la sys iniziale si sono trasformati da 08 10 in 02 AA,
ovvero in binario:
00001000 00010000 <- dovevano essere cosi'
00000010 10101010 <- ma su tap risultano cosi'
Per puro caso evidentemente gli unici byte errati di tutto il nastro sono
capitati proprio li'. Poteva andare peggio e capitare in mezzo al programma
stesso, rendendo quasi impossibile il recupero.
Con l'hexeditor ho ripristinato i 2 byte, di fatto riscrivendo i 16 byte
errati nel tap mettendo byte $1b al posto dei bit a 0 e $27 per i bit a 1.
PRIMA
offset valori hex binari:1b=0 27=1
0000C916: 1B 1B 1B 1B-1B 1B 27 1B-1B 1B 1B 1B-1B 1B 27 1B 0000001000000010 < pilot (tanti 2)
0000C926: 1B 1B 1B 1B-1B 1B 27 1B-1B 1B 1B 1B-1B 1B 27 1B 0000001000000010 <
0000C936: 1B 1B 1B 1B-1B 1B 27 1B-1B 1B 1B 1B-1B 1B 27 1B 0000001000000010 <
0000C946: 1B 1B 1B 1B-1B 1B 27 1B-1B 1B 1B 1B-1B 1B 27 1B 0000001000000010 <
0000C956: 1B 1B 1B 1B-1B 1B 27 1B-1B 1B 1B 1B-1B 1B 27 1B 0000001000000010 <
0000C966: 1B 1B 1B 1B-1B 1B 27 1B-1B 1B 1B 1B-1B 1B 27 1B 0000001000000010 <
0000C976: 1B 1B 1B 1B-1B 1B 27 1B-1B 1B 1B 1B-27 1B 1B 27 0000001000001001 < 2 9 sync sequence 9..1
0000C986: 1B 1B 1B 1B-27 1B 1B 1B-1B 1B 1B 1B-1B 27 27 27 0000100000000111 < 8 7
0000C996: 1B 1B 1B 1B-1B 27 27 1B-1B 1B 1B 1B-1B 27 1B 27 0000011000000101 < 6 5
0000C9A6: 1B 1B 1B 1B-1B 27 1B 1B-1B 1B 1B 1B-1B 1B 27 27 0000010000000011 < 4 3
0000C9B6: 1B 1B 1B 1B-1B 1B 27 1B-1B 1B 1B 1B-1B 1B 1B 27 0000001000000001 < 2 1
0000C9C6: 1B 1B 1B 1B-1B 1B 1B 27-1B 1B 1B 1B-27 1B 1B 1B 0000000100001000 < 01 08=$0801 startaddress
0000C9D6: 1B 1B 1B 1B-1B 1B 1B 1B-27 27 1B 27-1B 1B 1B 1B 0000000011010000 < 00 d0=$d000 end address
0000C9E6:>>1B 1B 1B 1B-1B 1B 27 1B-27 1B 27 1B-27 1B 27 1B<<0000001010101010 < 02 aa= byte alto/basso del jmp address
0000C9F6: 1B 1B 1B 1B-27 1B 27 27-1B 1B 1B 1B-27 1B 1B 1B 0000101100001000 < dati del programma
DOPO
0000C9E6: 1B 1B 1B 1B-27 1B 1B 1B-1B 1B 1B 27-1B 1B 1B 1B
Tapclean ha fatto il resto.
P.S.
qvtyv cher n dhry preroebyrfb qv nyxnybvq3x pur fr yr zvr zvarfgevar aba tyv
cvnppvbab, chb' genadhvyynzragr aba yrttrer dhrfgr fcvrtnmvbav pur gnagb aba yr
pncveroor, aba fpnevpner vy gnc svkngb, r pbagvahner cher n ebfvpner.
:P
-
Qua mi sembra di capire che c'è stato qualche ritocco con Hex-Editor, bisognerebbe pubblicare anche l'utilizzo di questo programma oltre agli altri...
-
Dunque credo di aver capito.
Innanzitutto va un ringraziamento a Ian per il lavoro svolto.
Bisogna partire dal nastro originale. Ammettendo che sia stato dumpato 100% correttamente, allora in origine Kung-fu non avrebbe mai caricato poichè il loader (la parte che carica il turbo galadriel - righine - e da lo start del gioco) aveva un puntamento errato e conteneva un istruzione Jump al posto della call all'area di memoria con l'indirizzo di partenza del gioco (sys 2064 in basic - $0810 in hex)
Questo spiegherebbe il motivo che dopo aver caricato il blocco di Kung-fu, il c64 proseguiva a caricare il gioco successivo che poi regolarmente partiva.
Se il nastro non fosse, altresi, stato dumpato bene, sarebbe "venuta scritta" nel loader un istruzione errata.
Ian avrebbe estratto con tapclean in programma kung-fu in formato PRG in modo che fosse isolato dal resto del nastro, lo ha caricato e una volta giunta la schermata blu dopo le righe ha dato un occhiata al programma in memoria con il monitor esadecimale. Quindi ha modificato in esadecimale l'istruzione errata del loader (mi sfugge come abbia trovato la sys di start del gioco) e ha inserito al posto dell'istruzione "jump ..", l'istruzione "g 0810"
Non conosco l'assembler e quindi i dettagli delle altre modifiche che ti ha riportato non so spiegarli.
Ps: le ultime righe non vogliono dire niente.. sarà la parte ironica del suo messaggio.
-
Esatto complimenti a ian, ( non voglio far partire flame inutili, ma peccato che che abbia quel caratterino, ma d'altronde anche la mia persona, non è che può essere simpatica a tutti )
(mi sfugge come abbia trovato la sys di start del gioco)
La sys 2064 è abbastanza ricorrente per lo start dei programmi, ma penso/credo che si possa leggere dal monitor di vice.
Ps: le ultime righe non vogliono dire niente.. sarà la parte ironica del suo messaggio.
E' un messaggio cifrato, tipo quelli che appaiono nelle ultime pagine di hacker journal : i cyberenigma, peccato che senza la chiave non si può leggere
-
Esatto complimenti a ian, ( non voglio far partire flame inutili, ma peccato che che abbia quel caratterino, ma d'altronde anche la mia persona, non è che può essere simpatica a tutti )
Eh lo so ma per come ci ha rivolto la parola l'anno scorso dovremmo stare attenti, anch'io avrei voluto chiedergli aiuto per un .wav che non riesco a convertire ma ho preferito rinunciarci sapendo come la pensa per le cassette da edicola...
-
Avete ragione te e Strong. Anche io ho constatato sulla mia pelle, però in fondo vi ha aiutato..
Basta non esagerare con le richieste d'aiuto e penso che un punto d'incontro si trova.
-
Avete ragione te e Strong. Anche io ho constatato sulla mia pelle, però in fondo vi ha aiutato..
Basta non esagerare con le richieste d'aiuto e penso che un punto d'incontro si trova.
Sono d'accordo con te pero se vedi la mail che mandò a Strongboy l'anno scorso, e se potessi vedere la mail che inviò a me, oppure come ha contrastato Il Notturno sul suo blog per Galax Gun...
-
STOP ! ! ! no flame . . . é colpa mia . . .
Discutiamo del topic thanks . . . :amici2:
-
A fine caricamento infatti eseguiva una jmp $02AA, dove non c'e' niente, mentre
il programma caricava correttamente e ha una SYS2064 ($0810 in hex).
Alcuni POKE usavano questo trucco, cosi' funzionavano se veniva caricata la presentazione all'inizio della cassetta e poi il gioco, e non funzionavano se veniva caricato il gioco direttamente. Tecnicamente, la presentazione iniziale riempiva le locazioni $2AA e seguenti. Almeno POKE 9 era cosi'
-
[quote author=Uranio link=topic=1248.msg6146#msg6146 date=1229457236]
qvtyv cher n dhry preroebyrfb qv nyxnybvq3x pur fr yr zvr zvarfgevar aba tyv
cvnppvbab, chb' genadhvyynzragr aba yrttrer dhrfgr fcvrtnmvbav pur gnagb aba yr
pncveroor, aba fpnevpner vy gnc svkngb, r pbagvahner cher n ebfvpner.
:P
[/quote]
Ciao a tutti,
quel messaggio incomprensibile scritto da Ian Coog è in realtà in Rot 13, la cui decodifica è la seguente: " digli pure a quel cerebroleso di alkaloid3k che se le mie minestrine non gli
piacciono, puo' tranquillamente non leggere queste spiegazioni che tanto non le
capirebbe, non scaricare il tap fixato, e continuare pure a rosicare."
Provare per credere: http://www.faqintosh.com/risorse/it/othutil/webapps/rot13/
-
Alcuni POKE usavano questo trucco, cosi' funzionavano se veniva caricata la presentazione all'inizio della cassetta e poi il gioco, e non funzionavano se veniva caricato il gioco direttamente. Tecnicamente, la presentazione iniziale riempiva le locazioni $2AA e seguenti. Almeno POKE 9 era cosi'
(non posso piu' fare edit...) Il mio sospetto era che il TAP iniziale non fixato funzionasse perfettamente, solo che nel caso di Kung Fu fosse indispensabile caricare prima la presentazione e poi Kung Fu. Chi ha il TAP originale puo' fare la prova.
In POKE 9, solo 2 giochi su 5 caricano direttamente. Gli altri caricano solo se e' stata caricata la presentazione iniziale prima. Molto probabilmente Kung Fu in POKE 10 e' lo stesso.
-
Il tuo sospetto si rivela infondato :P
Avevo già provato a caricare il gioco dal menu.
Si comportava allo stesso modo.
Ripeto o è un bug in origine della casa Fermont oppure un dump venuto male.
-
Il tuo sospetto si rivela infondato :P
Avevo già provato a caricare il gioco dal menu.
Si comportava allo stesso modo.
Non so quale TAP stavi usando. Ho scaricato la versione su Edicola 64 (quindi non fixata) e l'ho fatta partire su VICE.
Effettivamente, alla fine del caricamento l'esecuzione salta alla locazione $2AA. Solo che li', se era stato caricato il menu all'inizio, c'e'
02aa 4C 10 08 JMP $0810
L'esecuzione salta a $0810 (2064), che e' il corretto entry point, e tutto funziona.
Se il menu non era stato caricato, a $2AA non c'e' l'istruzione di salto, e il gioco non parte.
-
Non vorrei aver fatto confusione con i files fixati e non.
Avevo provato i giochi con il menù, ma forse non quello in specifico.
Cmq ecco svelato tutto l'arcano.
Mi chiedo come mai gli altri programmi partono anche se non caricati dal menu'.
E' davvero strano perchè a questo punto dovevano applicare questo procedimento a tutti i giochi presenti.
Non ha molto senso applicarla ad 1 soltanto...
Cmq grazie Fab per aver fatto questa ulteriore verifica!
-
Mi chiedo come mai gli altri programmi partono anche se non caricati dal menu'.
I cracker hanno applicato il trucchetto solo a 1 programma, non a tutti. Perche', lo sanno solo loro.
Il trucchetto consiste nel modificare il loader, cosicche', alla fine del caricamento, non salta all'inizio del programma, ma a una parte della memoria dove normalmente non c'e' nulla. Il menu riempe quella parte di memoria con un'istruzione di salto, che salta all'inizio del programma.
(in POKE 9 il trucchetto e' stato applicato a 3 programmi su 5)