Ide64 Fixing

[marcom_to]

 Scusate, vorrei chiedere se qualcuno di voi ha dato un'occhiata al documento http://www.ide64.org/ide_fix.html . Teoricamente, sostituendo le chiamate che fanno accesso al drive 1541 tramite il bus IEC, e' possibile rendere il caricamento di un gioco multi-disco (aleno quelli che non utilizzano tecniche di fast loading) indipendente dal drive stesso. Non che mi interessi ide64, ma in ottica di utilizzo sulla mmc64/mmc replay. So che ci sono giochi gia' (patch)ati ma vorrei capirci qualcosa di piu' per conto mio. Sarebbe bello fare un fixing di qualche gioco e poterlo convertire in DFI. Penso che il discorso valga anche per i programmi patchati per i drive CMD.  Non sono un esperto di assembler, piuttosto sono un programmatore ad oggetti, quindi non ve la prendete se nelle mie affermazioni ho sbagliato qualcosa. Mi sto approciando all'assembler solo adesso anche se lo utilizzavo gia' in ambito z80.

Argomento analogo, ma per la DTV e' presente sul sito http://picobay.com/dtv_wiki/index.php?titl...mes_for_the_DTV .

A proposito, in ambito di cross-disassembling e cross-assembling voi che strumenti utilizzate? Sto imparando ad utilizzare il monitor di Vice, ma vorrei poter disassemblare e riassemblare per giocare un poco con l'assembly.

Marco
 

[iAN CooG]

 Quanta carne al fuoco, non sapevo da che parte iniziare.
Qualche ide64fix l'ho fatto anche io, si tratta solo di seguire alla lettera cio' che c'e' scritto nella documentazione da te linkata.
Ad esempio questo e' tutto quello che e' necessario per far funzionare M.U.L.E.

Codice: [Seleziona]

;patch for MULE -=[iAN CooG/HokutoForce]=-
;link to MULE.2 and crunch it with jmpaddr=$9000
;
*=$9000
patchloc =$6604
patchloc2=$6546
startgame=$4000

     lda #<patch
     ldx #>patch
     sta patchloc
     stx patchloc+1
     lda $BA
     sta patch+1
     lda #$2c
     sta patchloc2; jsr $fd15 not allowed on IDE64
     jmp startgame

patch
    ldx #$00
    jmp $ffba

Si salva l'ultimo drive usato (il gioco carica altrimenti solo da drive e annulla una chiamata a $fd15 che ripristinerebbe i vettori a $0300, causando di fatto la perdita delle funzioni di caricamento redirette alle routine dell'ide64.

Per quanto riguarda dreamload, ti conviene seguire retrohackers
http://retrohackers.org/forum/viewtopic.php?f=6&t=34

Riguardo agli strumenti, occorre un disassembler (64copy, 65xxdis, dxa, IDApro...) un assembler (dasm, acme, kickassembler, ca65, xa..), un hexeditor (64copy, starcommander, hiew, biew), vice monitor per fare patch al volo e debuggare passo passo, senza dimenticare il fattore determinante: centinaia di ore da perdere studiando e provando.
 

[marcom_to]

 Grazie iAN CooG,
sul tuo sito ho trovato gli strumenti giusti per il disassembling/assembling,  riferendomi al tutorial sul  ripping e ricostruzione di spy vs spy da cassetta. Sei stato di grande aiuto. Come dici tu  ci vanno centinaia di ore da perdere studiando e provando e non di meno tanta passione.

Grazie e a presto,

Marco

[iAN CooG]

 Qualche progresso? Ho visto che TNT/BF su Lemon64 ti ha anche dato un link per il tool ide64fix  

[marcom_to]

 Ciao iAN CooG,

grazie per l'interesse. Al momento sto provando il tool indicatomi da tnt/beyond force. Se a qualcuno interessa http://www.ide64.org/down.html (a fondo pagina). Tuttavia mi e' difficile trovare una qualche relazione tra gli indirizzi relativi alle chiamate non consentite e il disassemblato del programma stesso. Ovviamente il programma viene caricato in memoria ed interpreato per cui ho sottomano anche il monitor di Vice. Ora sto lavorando sul disassemblato di Journey to the center of the earth http://www.gb64.com/game.php?id=3970&d=18&h=0 . Non che sia proprio un bel gioco ma questo non usa fast loader o decruncher, per cui potrebbe essere un buon punto di partenza. C'e' solo un loader, tutto il resto sono immagini o testi che via via vengono caricati a seconda del proseguire del gioco. Ho visto che alcuni giochi a caricamento singolo da disco hanno in pancia la classica routine di caricamento LOAD, preceduta da  SETLFS e SETNAM. In questo caso il registro x si occupa di settare il device a 8 (LDX #$08) . Il fixing piu' semplice consiste nel dire al c64 di utilizzare l'ultimo dispositivo usato (informazione che trovo all'indirizzo $BA in pagina 0) e quindi sostituire LDX #$08 con LDX $BA. Da codice macchina l'op code a due byte A2 08 lo sostituisco con A6 BA.
Ovviamente le cose si complicano quando viene fatto il RESTOR. Mi sono accorto che alcuni fixing non sono fatti a dovere. Ad esempio nel fix di last ninja II dopo il caricamento del primo livello, al caricare del secondo, lo schermo si corrompe e appaiono pezzi di grafica e simboli incomprensibili. Se il c64 non trova il dispositivo su cui scrivere, di default scrive sul dispositivo video, quindi ora mi spiego il suddetto difetto.

L'argomento del fixing mi interessa e penso che ci dedichero' del tempo, quando posso, per approfondire alcuni concetti. Non essendo un esperto, tutti i consogli sono apprezzati. Anche se non scrivo molto sui forum seguo sempre tutto con interesse.

Marco


 

[iAN CooG]

 Il trucco per il RESTOR consiste nel salvarti come prima cosa i vettori da qualche parte e poi ripristinarli, sostituendo la jsr $fd15 con una tua routine che li riprende dal buffer che ti sei salvato precedentemente.
Ti posto qua di seguito le patch necessarie per "The Match", manageriale di calcio, a cui ho sistemato anche la RESTOR.

Codice: [Seleziona]

   * = $801
    .word eobas
    .word 7102
    .byte $9e
    .asc  "2064"
    .byte 0
eobas
    * = $810
newRESTOR = $0f80
vectorbuf = $0fc0

    lda #$2c   ; no messages about datassette play/record
    sta $1643
    sta $16A8

    lda $ba    ; current drive #
    sta $1649+1
    sta $164b+1
    sta $1651+1
    sta $166B+1
    sta $16B0+1

   ; buffer for current vectors
    ldx #<vectorbuf
    ldy #>vectorbuf
    sec
    jsr $fd1a

    lda #<newRESTOR
    ldx #>newRESTOR
    sta $104C+1; replace jsr $FF8A for ide64 compatibility
    stx $104C+2

   ;relocate the new RESTOR
    ldy #(eptrt-ptrt-1)
re  lda ptrt,y
    sta newRESTOR,y
    dey
    bpl re

    jmp $7c3f; start game
;-------------------------
ptrt
    ldx #<vectorbuf
    ldy #>vectorbuf
    clc
    jmp $fd1a
eptrt


[marcom_to]

 Ciao iAN CooG,

grazie per il consiglio, vedo che ne sai quanto basta! Vedro' di riuscire ad utilizzare quanto mi hai spiegato. Sempre per rimanere in tema con la programmazione del C=64 e del fixing, volevo chiederti se riesci a darmi una mano in questo senso (parlo con te ma mi rivolgo a chiunque sia interessato)

Dopo aver disassemblato Arrow of death http://www.gb64.com/game.php?id=423&d=18&h=0 , ho visto che il programma esegue una JSR all'indirizzo JSR $FFD8. Questo quando immetto il comando SAVE nel parser dell'avvenura grafica. Volendo intercettare la SAVE (che viene fatta solo su tape) e volendola re-indirizzare su disco ho pensato:

al posto di  JSR $FFD8 un salto alla mia JSR .SaveToDisk

e poi

Codice: [Seleziona]


.SaveToDisk LDA #08             ;filename length
                       LDX #<fname
                       LDY #>fname
                       JSR $FFBD    ; call SETNAM
                       LDA #$00
                       LDX $BA      ; last used device number
                       BNE .skip
                       LDX #$08     ; default to device 8
.skip                  LDY #$00
                       JSR $FFBA    ; call SETLFS

                       LDA #<file_start
                       STA $C1
                       LDA #>file_start
                       STA $C2

                       LDX #<file_end
                       LDY #>file_end
                       LDA #$C1     ; start address located in $C1/$C2
                       JSR $FFD8    ; call SAVE
                       RTS
        
file_start = $2000   ; example addresses
file_end   = $4000
fname  !tx "filename"
Nel momento in cui premo return dopo il comando SAVE torno al basic con un bel SYNTAX ERROR. Ho provato la routine di salvataggio da sola ma ottengo sempre errore. Per la routine ho preso spunto dal c64 programmer's reference guide e dal sito c64 codebase http://codebase64.org/doku.php?id=base:saving_a_file .

A proposito, per ricompilare il codice assembly utilizzo acme, in dettaglio:

Codice: [Seleziona]

acme -o myfile.prg -f cbm --cpu 6510Buona serata a tutti  
Marco

[iAN CooG]

 Sembra corretto, cosi' a occhio, ma c'e' un problema: a che indirizzo hai assemblato questa routine? Sicuro che non sovrascrivi qualcosa? Hai provato a settare un breakpoint in vice e tracciare passo passo quel che succede?
Poi, hai sostituito la JSR $ffd8 con una jsr save, ma poi quando ritorni lo stack e' ancora a posto? I vettori di save ($0328/0332) sono corretti prima della chiamata?
Ci sono troppi fattori da considerare, prova a rendere disponibile il tuo crack da qualche parte e proviamo a debuggarlo.

Edit: non e' detto che $ba contenga l'ultimo drive usato, una volta che il gioco e' partito puo' aver fatto cio' che voleva della zeropage, quindi si e' perso il valore in esso contenuto, e quindi la tua routine salverebbe sempre sul drive 8 o qualunque cosa contenga $ba se >= 8.
E' sempre bene salvarsi questo valore PRIMA di far partire il gioco, patchando la tua routine di save e poi dando la jmp che fa partire il gioco. Ovviamente tutto questo va verificato debuggando, metti tu un valore in $ba prima di partire, e dopo averlo giocato per un po' prova a rivedere cosa contiene, se viene mantenuto il valore sei in una botte di ferro, altrimenti devi procedere come detto prima e come illustrato dai 2 patch postati.

[marcom_to]

 Ciao iAN CooG,

facendo un po' di tracing sono riuscito a capire che nel gioco, prima della save viene speficato il range di memoria da salvare su disco. Ho modificato il codice che salva su disco e l'ho provato da solo giusto per vedere se va:

Codice: [Seleziona]

             *= $0900
              
.SaveToDisk   LDA #fname_end-fname
           LDX #<fname
           LDY #>fname
           JSR $FFBD    ; call SETNAM
           LDA #$01  ; logical file number
           LDX #$08     ; device number 8
           BNE .skip
           LDX #$08     ; default to device 8
.skip      LDY #$00
           JSR $FFBA    ; call SETLFS
          
           LDA #<file_start
           STA $4E
           LDA #>file_start
           STA $4F
          
           LDX #<file_end
           LDY #>file_end
           LDA #$4E     ; start address located in $4E/$4F
           JSR $FFD8    ; call SAVE
           BCS .error   ; if carry set, a load error has happened
           RTS
.error
       ; Akkumulator contains BASIC error code
       ;... error handling ...
        RTS

file_start = $0341
file_end   = $4203        
fname:  !TX "JUST A FILENAME"
fname_end:
Questo funziona, difatti mi salva su disco (provato su Vice) il file "JUST A FILENAME" dopo aver inserito SYS2304 da basic. Disassemblandolo questo comincia da $0341 e finisce a $4202. In seguito quindi ho sostituito la JSR $FFD8 nel gioco con la mia JSR .SaveToDisk. Ho verificato che i vettori di save $0328/0332 rimangono inalterati dopo la chiamata alla save. Tuttavia il gioco torna al basic dopo il salto alla subroutine senza salvare nulla. Questa routine l'ho messa al fondo del programma esistente con il codice riportato sopra, senza includere la riga  *= $0900.

Purtroppo non posso postare un link ai sorgenti perche' non ho uno spazio web.

Provero' a capirci qualcosa di piu'. Ma mi  viene il dubbio: visto che il gioco chiede di premere REC & PLAY su cassetta e poi RETURN per salvare, non vorrei che il programma ritornasse errore perche in una sua subroutine verifica che tali tasti non sono stati premuti prima di pigiare il testo RETURN.

Ciao a tutti,
Marco

[iAN CooG]

 

Questa routine l'ho messa al fondo del programma esistente

Non puoi mettere a casaccio dove capita, devi esaminare la memoria capendo dove avanza spazio. Il gioco occupa, in partenza, gli indirizzi $4000-$cfff (e secondo me a $b500 in poi c'e' solo sporcizia)
riempi di NOP o quel che vuoi tu la memoria, carica il gioco e vedi cosa rimane libero di tanto in tanto, ad esempio a $0b00 non viene mai alterato il contenuto. Possiamo mettere li' il nostro codice aggiuntivo.

Una patch veloce al gioco puo' essere fatta cosi'

Codice: [Seleziona]

   *=$0b00
  ; qua c'e' memoria non utilizzata
new_ffbd
    lda #fname_end-fname
    ldx #<fname
    ldy #>fname
    jmp $FFBD

new_save
    lda #$01
    tay
    ldx $ba
    jsr $ffba
    lda #fname_end-aname
    ldx #<aname
    ldy #>aname
    jmp $FFBD

aname:  byte "@0:"
fname:  byte "JUST A FILENAME"
fname_end:

    *=$4000
    incprg 4000; gioco dumpato da $4000 a $cfff

    *=$4970
    ldx $ba; al posto di ldx #$01

    *=$4979
    jmp new_ffbd

    *=$5DB8
    jsr new_save

cosi' funziona, testato con vice + ide64 su device #12 e 1581 su device 10.

PS:
file_start = $0341
hai invertito hi/lo, e' $4103, ma in ogni caso non serve che rifai tutta la routine di save, in fin dei conti mancava solo il settaggio del filename, il resto e' gia' tutto li'.

[iAN CooG]

 Essendo un gioco in 2 parti, e fatte con lo stesso motore, si possono patchare allo stesso modo.
Ho preparato 2 versioni del gioco, una tenendo i 2 files separati, l'altra con il tocco di classe in piu' dell'onefiling.

hxxp://iancoog.altervista.org/HF/ArrowOfDeath_v2.rar
hxxp://iancoog.altervista.org/HF/ArrowOfDeath_v3_onefiled.rar

sorgenti inclusi e qualche commento per chi vuole imparare.

[marcom_to]

 Ciao iAN CooG e ciao a tutti ovviamente.

Ho verificato che riassemblando con la mia routine andavo a sovrascrivere al fondo del programma (anche perche' il disassemblato usa delle sue label e dei vettori di stringa diversi dal sorgente originale occupando in memoria uno spazio diverso, una volta caricato il gioco).

Volendo scovare uno spazio libero sicuro ho fatto un dump della memoria del c64 dopo un hard reset e poi un dump con il gioco caricato e giocato in parte. Fancedo il diff dei due dump mi accorgo che all'indirizzo $c040 non viene mai scritto nulla. Per cui prima di fare il salto alla mia subroutine setto *= $c040

Ora riesco a salvare il gioco. Giustamente come da tuo codice il nome del file salvato deve comprendere la chiocciola, perche' il file puo' esere scritto e sovrascritto. Poi ho intercettato la routine di load per caricare il gioco salvato:

Codice: [Seleziona]

.LoadToDisk
        LDA #fname_end-fname
        LDX #<fname
        LDY #>fname
        JSR $FFBD   ; call SETNAM
        LDA #$01
        LDX #$08     ; last used device number
        BNE .skip
        LDX #$08    ; default to device 8
.skip  LDY #$00    ; $00 means: load to new address
        JSR $FFBA   ; call SETLFS

        LDX #<load_address
        LDY #>load_address
        LDA #$00    ; $00 means: load to memory (not verify)
        JSR $FFD5   ; call LOAD
        BCS .error  ; if carry set, a load error has happened
        RTS
.error
      ; Akkumulator contains BASIC error code

      ; most likely errors:
      ; A = $05 (DEVICE NOT PRESENT)
      ; A = $04 (FILE NOT FOUND)
      ; A = $1D (LOAD ERROR)
      ; A = $00 (BREAK, RUN/STOP has been pressed during loading)

      ;... error handling ...
        RTS

load_address = $0341
fname2  !TX "@JUST A FILENAME"
fname_end:
Ho provato il gioco andando in diverse locazioni e raccogliendo oggetti e il tutto sembra funzionare quando salvo e carico.

E qui, sempre in vena di volere imparare cose nuove pensavo:

Prima di salvare o caricare vorrei sostituire i messaggi di Press play/Press rec&play on tape than hit return con messaggi piu' appropiati:

In pratica la mia idea era quella di patchare l'area di memoria che contiene i messaggi e di sovrascriverla prima delle operazione di load/save.

Ho visto che per la save, ad esempio il messaggio e' contenuto nelle locazioni da 46a7 46c9 e quindi volevo fare cosi':

Codice: [Seleziona]

.subst  ; sostituisce da 46a7 46c9
    ; da PRESS RECORD & PLAY THEN HIT RETURN
    ; a PRESS RETURN  TO SAVE ON DISK DRIVE
      LDY #0
      BEQ .in
.loop    STA $46a7,Y
      INY
.in     LDA mymsg,Y
      BNE .loop
     RTS
mymsg:                     !TX  "PRESS RETURN  TO SAVE ON DISK DRIVE "
il messaggio lo sostituisce ma inserisce anche dei caratteri sporchi.

Cmq per ora sono soddisfatto, anche perche' mi occupo della cosa solo da alcuni giorni durante il mio tempo libero.

Grazie iAN CooG per l'interesse in merito. Ovviamente scarico  il fixing dal tuo sito per studiarlo.


Marco

[iAN CooG]

 La routine di scrittura del gioco funziona cosi':

Codice: [Seleziona]

5DB0  20 49 48  JSR $4849
5DB3  A7 46    ;word $46a7
5DB5  20 EC 51  JSR $51EC

la jsr $4849 preleva dallo stack l'indirizzo di ritorno, lo incrementa e prende il puntatore alla stringa da stampare (in questo caso a $5db3, stringa puntata: $46a7) ne stampa tutti i caratteri fino al primo $0d (return).

Codice: [Seleziona]

4849  BA        TSX
484A  E8        INX
484B  BD 00 01  LDA $0100,X
484E  85 26     STA $26
4850  E8        INX
4851  BD 00 01  LDA $0100,X
4854  85 27     STA $27
4856  20 85 48  JSR $4885
4859  A0 00     LDY #$00
485B  B1 26     LDA ($26),Y
485D  85 28     STA $28
485F  C8        INY
4860  B1 26     LDA ($26),Y
4862  85 29     STA $29
4864  A0 00     LDY #$00
4866  B1 28     LDA ($28),Y
4868  C8        INY
4869  C9 00     CMP #$00
486B  F0 07     BEQ $4874

486D  20 74 47  JSR $4774
4870  C9 0D     CMP #$0D
4872  D0 F2     BNE $4866


Al ritorno lo stack punta esattamente al byte in $5db4, quindi la rts fa proseguire a $5db5, dove viene attesa la pressione del Return. Io ho noppato le chiamate e riempito di $0d le scritte, ormai inutili per una versione disco, lasciando solo delle scritte parziali per segnalare eventuali errori di I/O.
 

[marcom_to]

 Ciao iAN CooG,

Ora ho risolto. Il nuovo messaggio sovrascriveva il carattere return a fine messaggio. Quindi ho aggiunto il return mancante che fa da separatore e visto che faccio il branch not zero gli aggiungo anche il byte mancante.  

Ho risolto cosi' ad esempio per la save:

Codice: [Seleziona]

.subst    
; replace from 46a7 46c9
; message PRESS RECORD & PLAY THEN HIT RETURN
; to msg  PRESS RETURN TO SAVE ON DISK DRIVE!
  LDY #0
  TYA ; Also force accumulator to 0
  BEQ .in
.loop
  STA $46a7,Y
  INY
.in
  LDA newmsg,Y
  BNE .loop
  RTS

newmsg:   !TX  "PRESS RETURN TO SAVE ON DISK DRIVE!"
  !byte 13
  !byte 0
Ora c'e' tutto, la load, la save e messaggi cambiati. Ho anche sostituito il device da 8 a $BA.

Il tuo fixing e' raffinato. Intelligente la possibilita' di fare un salvataggio a seconda che si tratti della prima parte o della seconda parte del gioco. Mi piace molto!

Marco