Jump to content
Sign in to follow this  
ichigobankai

[aide] hack jeux Sega system C-2 (asm 68000)

Recommended Posts

Comme certains l'on vu, je me suis amusé à hacké la quasi totalité des jeux Sega System C-2, le system n'est pas extraordinaire (c'est pas du CPS2 & cie), mais au départ ayant vu un pcb bootleg avec Thunder Force AC je me suis penché dessus.

 

Me reste juste 2 jeux à hacker (ou plutot 1 seul, car 1 des 2 se joue au rotary stick)

Seul souci, ces 2 là ont un schéma de protection différent...youpi.

Et je me casse bien les dents dessus ^^

 

Le souci se pose au niveau des palettes de couleurs, 

tous les jeux ont la meme forme sauf ces 2 là :

• Ribbit

• Twin Squash

 

Evidemmen ce sont les 2 qui posent souci ;)

 

Extrait du driver de mame (segac2.ccp ou segac2.c sur google):

void segac2_state::recompute_palette_tables()
{
	int i;
	for (i = 0; i < 4; i++)
	{
		//base commune
                int bgpal = 0x000 + m_bg_palbase * 0x40 + i * 0x10;
		int sppal = 0x100 + m_sp_palbase * 0x40 + i * 0x10;

		if (!m_segac2_alt_palette_mode)
		{
                    //POUR TOUS LES JEUX SAUF Ribbit et Twin Squash
		    m_segac2_bg_pal_lookup[i] = 0x200 * m_palbank + bgpal;
		    m_segac2_sp_pal_lookup[i] = 0x200 * m_palbank + sppal;
		}
		else
		{
			
                    //POUR Ribbit et Twin Squash UNIQUEMENT
                     m_segac2_bg_pal_lookup[i] = 0x200 * m_palbank + ((bgpal << 1) & 0x180) + ((~bgpal >> 2) & 0x40) + (bgpal & 0x30);
		     m_segac2_sp_pal_lookup[i] = 0x200 * m_palbank + ((~sppal << 2) & 0x100) + ((sppal << 2) & 0x80) + ((~sppal >> 2) & 0x40) + ((sppal >> 2) & 0x20) + (sppal & 0x10);
		}
	}
}

Notes de CharlesMcDonald :

http://cgfm2.emuviews.com/txt/c2tech.txt

 

infos.

le code du jeu se situe dans les roms ic31 et ic32 (et contient aussi le début des gfx)

les autres sont la suite des gfx (ic33 et ic34) et le son (ic4)

 

appel du registre de protection : 0x800001

appel registre controle vidéo : 0x800201

 

je pense qu'il faudrait trouver l'algo de gestion de palette dans les roms (qui ne sont pas forcément identique) et les remplacer par une version plus "standard"...ou pas.

L'asm c'est pas franchement mon truc, donc je patauge un peu ^^

 

j'ai bricolé 2 scripts python pour interleaver les roms (car les roms sont séparées en données paires/impaires) et un autre pour faire dans l'autre sens.

J'ai également désassemblé ces roms avec 68KD, peut etre qu'avec IDA on peut avoir un meilleur résultat ...

 

fichiers python (2.7)

join_evenodd.py.zip

split_evenodd.py.zip

attention j'ai foutu en "dur" le nom des fichiers d'entrée/sortie, pensez à les modifier si besoin.

 

fichier bin généré (pour désassembler ensuite)

ribbit_interleaved.bin.zip

twin_interleaved.bin.zip

 

roms originales

ribbit.zip

twinsqua.zip

Share this post


Link to post
Share on other sites

oui ca j'ai bien vu/lu.

 

en fait chaque jeu à un altera différent, qui normalement "bloque" en cas de données non identique entre la table de protection et celle calculée par ce chip (avec effet divers*). Pour les autres jeux c'était facile à contourner, y'a juste a faire sauter l'état (ou les états) de comparaison en disant que c'est toujours valide...

 

l'idée serait de justement modifier ce qui est envoyé en amont à l'EPM5032 pour que ca arrive correctement (cad modifier le code du jeu pour que le départ/arrivée soit dans le bon sens / identique autre autres jeux.). 

le gros souci étant ca dépasse franchement mes compétences.

 

Car si je comprends bien, ils ont foutu un code de gestion de palettes "non standard" => l'altera a un code spécifique qui remet ca dans le bon sens => image en sortie avec palettes correctes

 

Tout le reste du jeu fonctionne (son etc)

 

*Liste des effets quand la protection se met en route sur les jeu :

Bloxeed			pas de protection
Borench 		pas de protection  ? (apparement)
Columns			plante au moment de jouer
Columns 2		plante au moment de jouer
Stack Columns		corruptions graphiques
Poto Poto		hang après lancement sur image de perso qui fait la moue ^^
Puyo Puyo		pas de sprites ? (a confirmer)
Puyo Puyo 2		jeu "lent" / pas de combos (pas d'envoi de boules sur l'autre coté)
Tant-R			ecran noir / hang au lancement
Ichidant-R		ecran noir / hang au lancement
Zankyou 		reboot au moment où les persos commencent à jouer
Ribbit 			mauvaise palettes (spr/bg) après la 1ere démo / ingame
TwinSquash		pas de décor ingame/sprite autre que ceux des joueurs+balles
Thunder Force		plante au moment de jouer

Share this post


Link to post
Share on other sites

J'ai oublié de préciser que sur Ribbit je suis certain qu'il y ait plusieurs algo pour les palettes :

 

voila le cycle quand on ne touche à rien :

 

(Départ) - 1

1er écran avec la grenouille + texte OK

title screen  / écran logo sega + libellules OK

OK

=> demo de jeu OK

=> hall of fame OK

 

retour au départ - 2

1er écran avec la grenouille + texte OK

écran logo sega + libellules OK

title screen OK

=> demo de jeu Palettes corrompues

=> hall of fame Palettes corrompues (sprites noirs / invisible)

 

retour au départ - 3

1er écran avec la grenouille + texte Palettes corrompues

écran logo sega + libellules Palettes corrompues

title screen Palettes corrompues

=> demo de jeu Palettes corrompues

=> hall of fame Palettes corrompues 

 

retour au départ - 4

1er écran avec la grenouille + texte Palettes corrompues

écran logo sega + libellules Palettes corrompues

title screen Palettes corrompues

=> demo de jeu Palettes corrompues

=> hall of fame Palettes corrompues 

 

retour au départ - 1

1er écran avec la grenouille + texte OK

...

 

* la corruption n'est pas la meme à chaque cycle

Share this post


Link to post
Share on other sites

J'ai mis Ribbit de coté, car j'arrive pas à trouver pour le moment.

 

Par contre pour Twin Squash, je pense que je tiens le bon bout.

J'ai localiser la routine d'affichage in game et commencé a faire qq modifs.

Sachant que seulement l'ingame pose souci sur ce jeu, tout le reste fonctionne.

 

original quand tout va bien...

post-5150-0-79384900-1454286870_thumb.png

 

Sur pcb (avec le mauvais chip de protection) et rom d'origine

post-5150-0-53531500-1454286869_thumb.png

 

version hackée en cours

post-5150-0-58530800-1454286872_thumb.png

c'est quasi jouable, on voit le décor et les briques, lol ^^

 

Share this post


Link to post
Share on other sites

C'est réglé pour Twin Squash !

Je me suis remis en milieu d'aprem dessus et repris mes notes...

 

au final juste quelques bytes à changer, mais fallait les trouver ces put*** de bytes.

En gros sur Twin Squash y'a aucune protection, juste des palettes pas chargées dans le bon ordre/bons endroits si le chip de protection n'est pas le bon (décalage d'offset)

 

post-5150-0-93454000-1454605646_thumb.png

*test sur ma version de mame "modifiée" avec chip de protection & cie en vrac

 

je testerai sur le hard tout à l'heure ;)

 

Edit.

Et voilà pour le proof sur le hard

(sur mon pcb Ichidant-R)

post-5150-0-22927900-1454609245_thumb.jpg

Share this post


Link to post
Share on other sites

Je pense que Ribbit devrait etre hacké d'ici peu ;)

 

J'ai trouvé des tables de pointeurs vers les palettes et dans ces tables il y a aussi les valeurs de décalage d'offset pour le chargement en vram ^^

(qui provoque une image noir, vu que les palette ne sont pas aux bons endroits)

 

Par contre j'ai cru voir un grand nombre de tables/valeurs, donc même si c'est bien ca (ce que j'espère vivement),

il faudra tout de même un petit moment pour faire toutes les modifs !

Share this post


Link to post
Share on other sites

J'ai réussi à modifier un screen de Ribbit, donc les tables trouvées sont bien les bonnes ;)

y'a 8 palettes et toutes n'ont pas le meme offset de décalage (sinon ce serait facile).

 

post-5150-0-03414400-1454679483_thumb.png

*test sur mon mame hacké où en temps normal on ne peut apercevoir que les grenouilles (le reste étant noir)

 

Souci c'est hard a appliquer sur la phase de jeu ingame car il y a des offsets de pré-calculés et que même à 0, ces offsets sont présents (et du coup certaines palettes ne sont pas aux bons endroits)

Et on ne peut pas mettre de valeur négative ou superieur en espérant que ca reboucle (j'ai testé)

 

Du coup, y'a pas 50 solutions : faut trouver & modifier ce qui met ces offsets.

J'ai trouvé la routine d'affichage des levels & cie mais un peu hard a décortiquer pour moi (bcp de branchements) et ca fait >300 lignes d'asm... youpi ^^

Share this post


Link to post
Share on other sites

Après une première analyse, pas de possibilité de généraliser la rom de ribbit comme ça a été fait pour les autres, en tout cas pas aussi facilement.

Je m'explique, les autres jeux vérifient simplement que le résultat renvoyé par le chip de protection correspond à ce qui est attendu, pour ribbit, et à priori twin squash d'après les sources de mame le résultat obtenu est utilisé entre autres pour organiser les palettes.

La seule solution "facile" que je vois est d'implémenter en assembleur 68k ce que fait le chip de protection. Heureusement l'algo est dans les sources de mame mais je ne touche pas ma bille en 68000 donc il faudrait trouver quelqu'un qui connait, et grosso modo insérer un call vers la sous-routine à la place de l'appel au lockchip.

Je continue à plancher là dessus demain.

Share this post


Link to post
Share on other sites

Merci Aki ;)

 

Twin squash était assez simple, juste un routine a modifier (soit quelques bytes une fois celle-ci localisée) car toute la logique de jeu était bonne et il n'y avait aucune protection autre que la partie jeu qui avait un décalage d'offset au niveau palette. Une bonne protection en carton.

 

Mais sur que Ribbit, lui, est d'un autre niveau...

Share this post


Link to post
Share on other sites
Sign in to follow this  

×
×
  • Create New...