CPC Rulez
https://cpcrulez.fr/forum/

TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
https://cpcrulez.fr/forum/viewtopic.php?f=2&t=5279
Page 89 sur 138

Auteur :  Megachur [ 25 Juil 2016, 17:09 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Egalement les nouveaux dsk de :

Chip's Challenge (UK) (1990) [Original].dsk
Crack Down (UK) (1990) [Original].dsk
Sram 2 (F) (Face A) (1987) [Original].dsk
Sram 2 (F) (Face B) (1987) [Original].dsk

fonctionnent parfaitement ;-) !

si tu pouvais également corriger les autres comme cela, ce seraient super ! :biere: :kiss: :kiss: :kiss:

Encore une fois, tu peux les tester avec l'émulateur que je t'avais envoyé ;-) !

Auteur :  Lone [ 25 Juil 2016, 18:15 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Megachur a écrit :
Sugarbox reconstruit toute la piste à partir des infos (Lone pourra nous le confirmer ;-) avec un algo de deux kilomètres de code !


Je confirme !
Le code n'est pas simple, mais par contre, prend en compte toute les données disponibles pour reconstruire au mieux la piste (ce qui permet la reconstitution d'une piste HFE ou IPF)

Auteur :  dlfrsilver [ 25 Juil 2016, 20:48 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Megachur a écrit :
Egalement les nouveaux dsk de :

Chip's Challenge (UK) (1990) [Original].dsk
Crack Down (UK) (1990) [Original].dsk
Sram 2 (F) (Face A) (1987) [Original].dsk
Sram 2 (F) (Face B) (1987) [Original].dsk

fonctionnent parfaitement ;-) !

si tu pouvais également corriger les autres comme cela, ce seraient super ! :biere: :kiss: :kiss: :kiss:

Encore une fois, tu peux les tester avec l'émulateur que je t'avais envoyé ;-) !


Oui, donc c'est bel et bien Samdisk qui déconne, j'ai fait des test via caprice forever 0.26, c'est clair qu'il aime pas non plus le surplus de données....

Comme je l'ai dis à Kukulcan cet après-midi, j'ai peur, au vu du fonctionnement de samdisk, que l'auteur finisse par péter quelque chose vis à vis des
pistes de taille 6.

Samdisk n'a pas d'IA (enfin un sniffeur plus précisément), permettant de pouvoir nettement différencier la protection speedlock et hexagon.

Problème : si les deux se ressemblent, elles ne sont pas identiques. La protection Speedlock a dans la majorité des cas aucun checksum sur les pistes, et je pense que c'est surement la raison pour laquelle l'auteur de Samdisk pousse la lecture au maximum, ceci afin de chopper le CRC en bout de piste, mais comme y en a pas, ça doit faire déconner le bouzin.

La protection hexagon disk elle possède un CRC quoi qu'il arrive, et ça fait une sacré différence.....

ça va être coton pour que Samdisk puisse faire la différence.....

Citer :
Je confirme !
Le code n'est pas simple, mais par contre, prend en compte toute les données disponibles pour reconstruire au mieux la piste (ce qui permet la reconstitution d'une piste HFE ou IPF)


certes, ce qui permet d'éviter tout problème (normalement) en cas d'anerie comme celle présente sur Samdisk.

Auteur :  Megachur [ 26 Juil 2016, 06:17 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

La suite des tests des dsks m'a permis de trouver un bug dans l'émulation du FDC pour la commande READ ID (&0a)... Certains flags du ST1 (ST1_EN et ST1_ND n'étaient pas correctement remis à zéro lorsqu'on rencontrait un IDR correct avant la fin de piste après une lecture de secteur).
La protection de RUBI teste bien tous les Status rendu par le FDC (ST0, ST1 et ST2) et plante si pb !

Le dsk du jeu Puffys Saga (UK) (Face A) (1989) (CPM) [Original].dsk marche maintenant avec la modification :oops: :sweatingbullets: :oops: :JC_doubleup: :thankyou:

C'était une régression par rapport à un changement de code de plus d'un an !!! arghhh ! :mdr:

Auteur :  dlfrsilver [ 26 Juil 2016, 08:42 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Ah tu vois, j'ai toujours raison quelque part :mdr:

Indépendamment du souci avec Samdisk, y avait quand même bien une couille dans ton émulation FDC :)

Auteur :  Megachur [ 26 Juil 2016, 17:35 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

j'ai un autre retour à faire sur la protection KBI (pour exemple le dump de Monte Cristo (F) (128K) (Face A) (1989) (CPM) [Original] (GAPS).dsk, ici pour l'exemple c'est la KBI MASTER). :sweatingbullets: :sweatingbullets: :sweatingbullets:

si je le fais lire par Sugarbox (qui le converti en track MFM) et que je le reconvertie en eDSK avec Sugarbox, j'obtiens un eDSK bien différent... pour la dernière piste 40 =(&28) avec la protection KBI MASTER !!!

Le premier ne passe chez moi, car mon algo de reconversion du eDSK en format MFM ne gère pas ce cas (il gère les autres KBI et secteurs entrelacés par contre ;-)) !
Cependant le second passe sans pb et le jeu se charge...

C'est encore une fois une façon d'illustrer que l'émulation est bonne et que c'est plutôt l'analyse (et la transformation) des données eDSK qui est compliqué car assez éloignée d'une vue piste MFM !!!

Est-ce qu'on considère que le premier eDSK est bon ou est-ce le deuxième qui respecte aussi le format eDSK ? :pir8: :smack: :thankyou: :bravo: :tapla: :soshelp:

--> J'ai besoin d'une analyse d'un pro du dump et de la conversion eDSK sur ce coup !?

Auteur :  Lone [ 26 Juil 2016, 21:44 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Je regarde ça dès que j' accède à un PC.
Ne faites pas trop confiance à la génération d'edsk de sugarbox, j'ai pas vraiment mis les watts dessus ( d'autre font déjà ça si bien !)+

Auteur :  dlfrsilver [ 26 Juil 2016, 21:45 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Megachur a écrit :
j'ai un autre retour à faire sur la protection KBI (pour exemple le dump de Monte Cristo (F) (128K) (Face A) (1989) (CPM) [Original] (GAPS).dsk, ici pour l'exemple c'est la KBI MASTER). :sweatingbullets: :sweatingbullets: :sweatingbullets:

si je le fais lire par Sugarbox (qui le converti en track MFM) et que je le reconvertie en eDSK avec Sugarbox, j'obtiens un eDSK bien différent... pour la dernière piste 40 =(&28) avec la protection KBI MASTER !!!


Que tu dises que tu rencontres un problème, OK, par contre, ce que j'aimerais c'est que tu prennes le temps d'expliquer ce qui d'après toi coince.

Tu es le seul à connaitre ton code, donc de quoi il en retourne ?

Citer :
Le premier ne passe chez moi, car mon algo de reconversion du eDSK en format MFM ne gère pas ce cas (il gère les autres KBI et secteurs entrelacés par contre ;-)) !
Cependant le second passe sans pb et le jeu se charge...


ça me dit toujours pas quel est le problème.....

EDIT : OK, c'est bon, j'ai compris ce qui se passe. Le problème est côté émulateur, je m'explique :

Il existe 2 types de KBI-19 : celles avec zones GAP, et celles sans zones GAP (ça je peux le confirmer, car l'outil d'analyse sait déterminer avec justesse si le logiciel utilise l'un ou l'autre des versions de la KBI-19).

Pour le comte de Monte-Cristo, le DSK a été généré depuis l'IPF de la face A (dommage, la face B est modifiée), donc il est certain que c'est bien la KBI-19 avec zones gap pour ce logiciel.

Ton émulateur doit pouvoir le supporter. Le eDSK généré avec sugarbox ne ressemble à rien, les secteurs sont en overlap, et ne peuvent pas être plein.

Auteur :  Megachur [ 27 Juil 2016, 06:06 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

@dlfrsilver: ok, je me doutais de la réponse... :oops: je vais revoir donc mon algo pour prise en compte de ce type de secteur dsk !

En fait, cela convient à un emulateur qui renvoie bêtement les données du format dsk mais sans la vrai vue piste MFM... je le sais car c'était ma première approche quand j'ai commencé à coder l'émulation FDC... mais cela marche pas avec toutes les protections... ce qui explique par exemple que WINAPE (pour ne citer que lui) ne peut pas faire fonctionner certaines protections/loader qui ont besoin d'une vraie vue de la piste !

Merci pour l'aide :winner: :biere:

Le cas particulier de ce type de KBI MASTER ou RAFALE (Monte Cristo ou Rafale par exemple), c'est qu'il n'y a pas de zone GAP à proprement parler sur le premier secteur, elle est constitué du début du secteur suivant (info IDR) !
Concrètement, quand je reconstruis la piste MFM, on se retrouve avec les infos du secteur 01 après la zone du secteur 00 (mais qui comporte les infos IDR du premier secteur dans sa zone GAPS) mais avant celle que j'ai rajouté pour le secteur 01 en MFM (que mon algo devrait pouvoir remplacer avec les infos d'avant mais qu'il ne trouve pas car il considère que cela fait partie du secteur d'avant) !!!

Auteur :  dlfrsilver [ 27 Juil 2016, 07:37 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Megachur a écrit :
@dlfrsilver: ok, je me doutais de la réponse... :oops: je vais revoir donc mon algo pour prise en compte de ce type de secteur dsk !


ça semble évident non ? lol

Citer :
En fait, cela convient à un emulateur qui renvoie bêtement les données du format dsk mais sans la vrai vue piste MFM... je le sais car c'était ma première approche quand j'ai commencé à coder l'émulation FDC... mais cela marche pas avec toutes les protections... ce qui explique par exemple que WINAPE (pour ne citer que lui) ne peut pas faire fonctionner certaines protections/loader qui ont besoin d'une vraie vue de la piste !


En fait, ce que je peux dire, concernant la plus grande faiblesse du format DSK, c'est que comme on est à priori en train d'utiliser une émulation FDC sensée être "parfaite", à un moment ça finira par coincer avec le format eDSK. le format eDSK a été crée et mis au point à un moment ou l'émulation FDC était clairement mauvaise, et là plus on se rapproche de ce qui devrait être le réel de la vraie machine, plus ça va coincer. J'ai presque envie de dire qu'un format comme le format de disque pasti STX sera un étape obligatoire à un moment donné.

Citer :
Merci pour l'aide :winner: :biere:


De rien :)

Citer :
Le cas particulier de ce type de KBI MASTER ou RAFALE (Monte Cristo ou Rafale par exemple), c'est qu'il n'y a pas de zone GAP à proprement parler sur le premier secteur, elle est constitué du début du secteur suivant (info IDR) !


En fait, le type de la KBI-19 n'est pas lié au mot de sécurité situé en fin de piste. C'est complètement indépendant de ça.

Citer :
Concrètement, quand je reconstruis la piste MFM, on se retrouve avec les infos du secteur 01 après la zone du secteur 00 (mais qui comporte les infos IDR du premier secteur dans sa zone GAPS) mais avant celle que j'ai rajouté pour le secteur 01 en MFM (que mon algo devrait pouvoir remplacer avec les infos d'avant mais qu'il ne trouve pas car il considère que cela fait partie du secteur d'avant) !!!


Les informations GAP commencent quand il y en a juste après le premier secteur.

Auteur :  Megachur [ 27 Juil 2016, 07:39 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

c'est plus complexe que ce que je pensais... je vous mets un dsk 'officiel' d'une autre protection KBI MASTER... celui-là est différent est passe sans problème...

donc je comprends qu'il existe plusieurs façon de 'traduire' en dsk ces secteurs...

encore une fois, j'ai besoin de votre aide pour statuer savoir quels eDSK est correct !? :kiss:

Auteur :  dlfrsilver [ 27 Juil 2016, 07:55 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Megachur a écrit :
c'est plus complexe que ce que je pensais... je vous mets un dsk 'officiel' d'une autre protection KBI MASTER... celui-là est différent est passe sans problème...

donc je comprends qu'il existe plusieurs façon de 'traduire' en dsk ces secteurs...

encore une fois, j'ai besoin de votre aide pour statuer savoir quels eDSK est correct !? :kiss:


Je suis dans l'incapacité de pouvoir te répondre, c'est un dump qui date de 2011, époque ou on ne savait pas encore que les zones GAPs pouvaient exister pour cette protection.

Je vais voir avec Loic s'il peut récupérer cet original, que je passerais en eDSK via l'IPF (beaucoup plus simple, puisque c'est l'analyseur qui détermine via son IA si il y a zone GAP ou non).

En fait, la grosse difficulté avec samdisk, c'est qu'il est incapable de déterminer ou non si des zones GAP sont crasseuses ou bien partie prenante du système de protection contre la copie.

L'analyseur est vraiment génialissime de ce point de vue, il SAIT faire la différence entre plusieurs type de protection (pour illustrer, la ou samdisk met 2 secondes à tout casser pour pondre un eDSK, L'analyseur SPS peut mettre jusqu'à 5 bonnes minutes pour déterminer à quoi il a faire, car l'IA passe en revue toutes les protections contre celle présente dans le dump, jusqu'à temps que ça corresponde!).

En même temps, c'est un peu normal, samdisk est un outil pour amateur, un discology pour PC en ligne de commande avec un pilote bas niveau, là ou l'Analyseur SPS est un produit industriel, c'est pas du tout la même "ligue", samdisk est gratuit, l'autre logiciel coûte 7000 euros (ce qui s'explique).

Si tu veux faire un test avec un KBI-19 dotée de zone gap, bubble ghost est un candidat par exemple.

Auteur :  marcel [ 27 Juil 2016, 14:42 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

J'ai enfin fini de tout lire depuis le début!

Je voulais envoyer un MERCI aux contributeurs du topic pour leur travail de qualité.

À ce sujet, est-il possible de mettre un titre en rapport avec le contenu?

"Dump IPF/CDT" ?

Auteur :  Lone [ 28 Juil 2016, 14:53 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Petite aparté sur le batch du 22/07 :

Le seul dump posant problème :
- TheWayOfTheTiger+Gunfright+V!_LesvisiteursB.raw : Très étrange : Le dump parait mélangé.

Je m'explique : Les données de la piste 0 sont sur la face B par exemple (en forçant la face à "0", on arrive à lancer le jeu...)


EDIT : Pour Marcel : Quel courage, parce qu'il y a beaucoup de pages ( et beaucoup de polémiques !)

Auteur :  Lone [ 28 Juil 2016, 15:09 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Sur le sujet "Monte cristo", j'ai regardé les dumps : A priori, rien de vraiment nouveau (ou bien je suis passé à coté).

La protection lit le contenu de la piste 40 via des read sectors.

Le dump de Sugarbox est assez basic, et envoie le contenu des secteurs tel qu'il est lu. (la reconstruction est (relativement) facile en cherchant les sync+IDAM). Bref, ça répond parfaitement aux besoins de la protection. (du coup, je ne vois pas pourquoi, Denis, tu dis que c'est n'importe quoi ?)

Le dump de Samdisk donne des infos supplémentaires (ce qui se trouve après chaque secteur). Ca aide à la reconstruction, sans être nécessaire.
Avec les données d'offset, ça fait presque trop d'infos pour ne pas s’emmêler (d'autant plus que les offset infos ne sont pas des modèles de précision...)

A priori, il n'y a pas qu'une vérité en matière d'edsk : Plusieurs edsk différents peuvent donner des pistes MFM a peu près semblables (et correct du point de vue protection)

En vrac on retrouve :
- Les dumps avec offset info et données minimum de chaque secteur (on s'arrête des qu'on passe sur des données qui servent à la syncro du secteur suivant).
- Les dumps avec juste le contenu de chaque secteur (a priori, mais pas toujours, suffisant)
- La même chose, avec des offsets infos (permet de résoudre des ambiguités ou un manque d'info éventuel)
- Les dumps "large bande" avec des tas d'infos sur le supposé GAP en fin de secteur (qui correspondent souvent à des données dans des secteurs suivants)

etc...

Page 89 sur 138 Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/