Dogyuun e Vfive

decrittati abbastanza per sentire la musica e gli effetti sonori

Toaplan 2: cpu sonora

Recentemente AWJ ha implementato un core per la cpu nec v25/35; grazie a questo è stato emulato il sonoro in batsugun

Batsugun non usa la feature della cpu di codificare gli opcode tramite una tabella di conversione

Sfortunatamente  kbash, vfive, dogyuun e fixeight si.

Analizzando il codice pero’ si notano grandissime somiglianze con il codice di batsugun; questa ha permesso a me e a AWJ di decrittare la maggior parte delgli opcode. Il primo risultato ottenuto è che la tabella di conversione per kbash, vfie e dogyuun è identica. Inoltre il codice di batsugun e kbash è quasi al cento per cento identico. Inoltre che il codice di startup di dogyuun, vfive e fixeight è identico. Per questi ultimi 3 è stato necessario un maggior lavoro dato che molti opcode non hanno trovato corrispondenza con batsugun. Una volta decrittati questi opcode pero’ ho notato che il codice di starup per questi tre decritta e copia in ram il contenuto presente in rom. Sucessivamente passa il controllo a questo nuovo codice e di nuovo si iniziano a notare grandissime somiglianza fra tutti e 5 i giochi.

Riepilogando:

batsugun permette di decrittare kbash (codice quasi identico)

kbash permette di decrittare vfive e dogyuun (stessa tabella di conversione)

vfive e dogyuun permettono di decrittare fixeight (codice quasi identico ma tabella di conversione differente)

Una volta finito di decrittare si potrà provare a implementare il sonoro.

SSV

Dopo aver acquistato una PCB di twin eagle ii e chiesto a kold la disponibilità di farmi dei test, ho deciso di riprendere il mano questo driver. Haze mi aveva fatto presente che probabilmente mancava un qualche tipo di effetto grafico nella transizione dall’attract all’high score (il valore di un registro decresceva e ricresceva); effettivamente l’area visibile si modificava.

In questo modo ho iniziato a implementare alcuni registri del CRT.

Per ora sono riuscito a eliminare gli offset dall’inizializzazione dei driver dato che sono ricavabili dai registri: inoltre ho implementato l’inversione delle coordinate y per gli sprite (usate per esempio attivando il flipscreen).

Per ora non sono riuscito a capire come si determinano gli offset per le tilemap diverse dalla principale e come si determina il sistema con il quale si impostano le coordinate degli sprite.

Credo che servirà ancora qualche test per la PCB!

flytiger

Io e Kale abbiamo notato che la palette veniva scritta 2 volte quasi consecutivamente; dato che durante la prima copia un bit di un registro era a zero e durante la seconda copia lo stesso bit era a 1 abbiamo presunto che fosse una sortas di protezione; quindi scartati i valori del bit a 0 abbiamo ottenuto colori che sembrano corretti (valido per tutto il gioco compresi gli intro)

finalmente fixato? comunque qualche test sull’hw sarebbe opportuno farlo

grazie alla decrittazione di ulteriori opcode e grazie all’aiuto di haze nell’implementare i reel (grafica e scroll) si comincia a vedere qualcosa che somiglia al gioco originale; il comportamente del gioco comunque è errato dato che alcuni opcode non sono decrittati correttamente

per esempio puntando 1 i crediti salgono di 1 al posto di scendere di 1; che ci sia un add al posto di un sub?