Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Citer :
en tout cas, le raw a bien ces infos !
Oui, je suis bien d'accord.
Citer :
soit l'outil d'analyse n'est pas bon et ne t'as pas donné la bonne information, soit cela vient de Samdisk !!!
L'outil d'analyse est parfaitement bon, la protection KBI-19 est une protection générique, y a rien de neuf sous le soleil à ce niveau.
Ensuite, pardon pardon, mais l'analyse c'est mon domaine. Tu n'as pas accès à l'outil d'analyse, donc tu ne peux pas émettre d'avis sur ce qu'il fait en bien ou pas.
Ca a beau être une intelligence artificielle, il n'en reste pas moins qu'elle a plus de nez que qui que ce soit, puisque c'est un miroir des connaissances du créateur du système IPF.
Si l'outil d'analyse ne garde pas ces informations inter-secteur, c'est que ce n'est pas utilisé comme protection.
Et si j'ai bien compris, tu parles des mots KBI présents entre les secteurs des pistes normales.
Citer :
Egalement, sous sugarbox, le .raw passe sans pb... le .dsk non et le dsk généré à partir du .raw par Sugarbox : passe sans pb lui !!
Pas d'accord. J'ai testé le dsk que j'ai généré avec sugarbox v0.26, caprice forever 0.28, CPCE, et la protection passe et se charge sans problème.
Quel est donc ton (vrai) problème ?
Citer :
je poste celui généré avec Sugabox v26...même s'il n'est sans doute pas parfait ! on y voit bien les infos 'KBI' dans les gap avant les datas des secteurs !!!
Comme je l'ai expliqué, quand une protection KBI utilise les GAP en protection supplémentaire, l'outil d'analyse le repère automatiquement.
Ici, ces infos ne sont pas gardées car ce sont les infos de marquage du duplicateur KBI.
Dans le même cas de figure, Kukulcan m'avait relancé quand au fait que les jeux Gremlin n'avaient pas les pistes duplicateurs dans les IPFs officiels.
Je lui avais expliqué qu'à mon avis, ces pistes (secteur sous samdisk), n'avaient aucune utilité. Le créateur du système m'a répondu que ces informations ne sont déjà pas lisible de base sur la machine cible, et qu'en plus les informations n'avait pas de rapport avec le contenu de la disquette, et elles ne sont pas utilisables.
C'est pour cette raison que les IPFs officiels ne contiennent pas ces pistes. Comme je l'ai indiqué pour Bubble Ghost, quand on fait un extract de l'eDSK via l'IPF, les infos GAP sont gardées.
Dans le même genre, Kukulcan m'a fait un retour sur le jeu Turbo Cup Version espagnole. Il me disait que la protection ne marchait pas.
Cette derniere fonctionne très bien, par contre l'utilisation du jeu sur un clavier français est interdit.
Je note que l'echec de la protection s'active si on lance Turbo Cup sous CPCE. Mais sous sugarbox et Caprice Forever ça marche bien
C'est pas tout à fait la même chose.....
_________________ SPS Community Expert (SPS CE) / SPS France
Curieux, j'ai le même symptôme que Megachur sur Crazy cars 2 : Ca ne passe pas avec le dsk du zip. (Le raw fonctionnant très bien, lui)
Sinon, petit retour sur les IPFs "Officiels" : Le format est (strictement) identique à celui que l'on connait (bonne nouvelle !), mais on a souvent les deux faces du même disk sur le même dump (il faut utiliser le fonction "flip" du menu disk sur Sugarbox - Mais cette fonction ne marche pas correctement sur la version 0.26 actuelle, je vous posterais une version qui corrige ça à l'occasion)
Par contre, plus surprenant, on n'a pas le "Creator ID" dans ces dumps ?
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Lone a écrit :
Curieux, j'ai le même symptôme que Megachur sur Crazy cars 2 : Ca ne passe pas avec le dsk du zip. (Le raw fonctionnant très bien, lui)
J'aimerais plutôt que "ça marche pas", un détail de ce qui se passe. De mon côté le DSK fonctionne sous sugarbox v0.26, caprice Forever 0.28, et CPCE.
Y a forcément une couille de votre côté. j'ai le jeu qui se charge, j'ai la page de présentation, la piste KBI-19 se charge, et ensuite j'accède au jeu, et je peux jouer normalement.
Donc : qu'est-ce qui se passe chez vous ?
Sinon, petit retour sur les IPFs "Officiels" : Le format est (strictement) identique à celui que l'on connait (bonne nouvelle !), mais on a souvent les deux faces du même disk sur le même dump (il faut utiliser le fonction "flip" du menu disk sur Sugarbox - Mais cette fonction ne marche pas correctement sur la version 0.26 actuelle, je vous posterais une version qui corrige ça à l'occasion)
Par contre, plus surprenant, on n'a pas le "Creator ID" dans ces dumps ?[/quote]
Oui les IPFs officiels sont double face quand un soft prend 2 faces.
Ces IPFs ont été finalisé par le créateur du système, donc c'est fort possible
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
dlfrsilver a écrit :
Lone a écrit :
Curieux, j'ai le même symptôme que Megachur sur Crazy cars 2 : Ca ne passe pas avec le dsk du zip. (Le raw fonctionnant très bien, lui)
J'aimerais plutôt que "ça marche pas", un détail de ce qui se passe. De mon côté le DSK fonctionne sous sugarbox v0.26, caprice Forever 0.28, et CPCE.
Y a forcément une couille de votre côté. j'ai le jeu qui se charge, j'ai la page de présentation, la piste KBI-19 se charge, et ensuite j'accède au jeu, et je peux jouer normalement.
Donc : qu'est-ce qui se passe chez vous ?
Sinon, petit retour sur les IPFs "Officiels" : Le format est (strictement) identique à celui que l'on connait (bonne nouvelle !), mais on a souvent les deux faces du même disk sur le même dump (il faut utiliser le fonction "flip" du menu disk sur Sugarbox - Mais cette fonction ne marche pas correctement sur la version 0.26 actuelle, je vous posterais une version qui corrige ça à l'occasion)
Par contre, plus surprenant, on n'a pas le "Creator ID" dans ces dumps ?
Oui les IPFs officiels sont double face quand un soft prend 2 faces.
Ces IPFs ont été finalisé par le créateur du système, donc c'est fort possible [/quote]
Quand à Turbo Cup Spanish, j'ai enfin la réponse, pour une raison que j'ignore, Samdisk ignore complètement la piste de protection et ne l'a pas inclut dans l'archive !
Et c'est pas le premier coup que ça arrive !
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1715
Lone a écrit :
Curieux, j'ai le même symptôme que Megachur sur Crazy cars 2 : Ca ne passe pas avec le dsk du zip. (Le raw fonctionnant très bien, lui)
@dlfrsilver: donc, on a toujours du mal à s'entendre... je ne dois pas être assez clair dans mes explications...
--> il manque des infos sur la piste KBI dans le DSK du zip (paquet que tu as posté le 20/08/2016 ici) pour que le dsk puisse fonctionner sur émulateur !!!
Je te remercie de régénérer ce dsk sinon il ne pourra jamais fonctionner sur un émulateur car le loader du jeu ne trouve pas les infos de protection comprise dans les entêtes de secteurs !!!
si tu trouves un émulateur qui fait passer ce dsk, je veux bien contacter l'auteur pour savoir comment il a fait ce miracle !
--> je te reposte ce fichier dsk au cas où tu n'utiliserais pas le bon (cf zip DSK du paquet du 20-08-2016.7z que tu as posté le 20/08/2016 ici)!
Citer :
et perso, je te signale cela car je pense que cela peut te faire progresser dans ton analyse du passage en mode fichier d'émulation secteurs eDSK... Laisser passer une piste KBI sans ses infos c'est soit un problème d'outils et dans ce cas tu es le surement le mieux placé pour le signaler à l'auteur de l'outil de conversion en eDSK, soit un problème d'analyse et de compréhension du fonctionnement de cette protection...et donc je penchais plutôt pour la première cause de faillite ...
Citer :
Quand à Turbo Cup Spanish, j'ai enfin la réponse, pour une raison que j'ignore, Samdisk ignore complètement la piste de protection et ne l'a pas inclut dans l'archive !
et donc, arrête de faire confiance 100% à SamDisk... c'est comme un émulateur, il n'est pas toujours parfait et laisse encore des tas d'infos inutiles/erronnées (voir problématique pour l'émulation eDSK)... comme les débuts d'entête de secteur (sync 12 x 0x00) dans les zones GAPS ou le début du premier secteur dans les datas du dernier secteur ou les débuts de pistes dans les datas du dernier secteur vus dans certains dsk générés avec la dernière version de SamDISK (Version 3.8.8, last updated 8th July 2015) !!
je crois que le summum a été atteins sur le dsk de "Les Aventures de Moktar (F) (1992) [Original].dsk" (paquet que tu as posté ici le 22/07/2016) :
dernier secteur de la piste 40 qui est weak : SamDISK a laissé le début de la piste dans les infos weak !!! à ma connaissance, y'a que Sugarbox qui est capable de la faire fonctionner celui là mais après une reconstruction de la piste en MFM grâce au travail fantastique de Lone !!!
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Megachur a écrit :
Lone a écrit :
Curieux, j'ai le même symptôme que Megachur sur Crazy cars 2 : Ca ne passe pas avec le dsk du zip. (Le raw fonctionnant très bien, lui)
@dlfrsilver: donc, on a toujours du mal à s'entendre... je ne dois pas être assez clair dans mes explications...
--> il manque des infos sur la piste KBI dans le DSK du zip (paquet que tu as posté le 20/08/2016 ici) pour que le dsk puisse fonctionner sur émulateur !!!
Je te remercie de régénérer ce dsk sinon il ne pourra jamais fonctionner sur un émulateur car le loader du jeu ne trouve pas les infos de protection comprise dans les entêtes de secteurs !!!
Le DSK que tu dis non fonctionnel marche chez moi sur sugarbox, caprice forever 0.28, et CPCE !
Je l'ai testé avant de le poster ! Donc j'aimerais que tu m'expliques, quand tu dis que ça marche pas, explique-moi en détail ce qui se passe chez toi.
Regarde le dump de Maxit sur cpc-p0wer, la protection KBI-19 n'utilise pas les zones GAP comme protection, et le DSK fonctionne correctement !
Tu as un problème, mais ailleurs.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1715
dlfrsilver a écrit :
Megachur a écrit :
Lone a écrit :
Curieux, j'ai le même symptôme que Megachur sur Crazy cars 2 : Ca ne passe pas avec le dsk du zip. (Le raw fonctionnant très bien, lui)
@dlfrsilver: donc, on a toujours du mal à s'entendre... je ne dois pas être assez clair dans mes explications...
--> il manque des infos sur la piste KBI dans le DSK du zip (paquet que tu as posté le 20/08/2016 ici) pour que le dsk puisse fonctionner sur émulateur !!!
Je te remercie de régénérer ce dsk sinon il ne pourra jamais fonctionner sur un émulateur car le loader du jeu ne trouve pas les infos de protection comprise dans les entêtes de secteurs !!!
Le DSK que tu dis non fonctionnel marche chez moi sur sugarbox, caprice forever 0.28, et CPCE !
Je l'ai testé avant de le poster ! Donc j'aimerais que tu m'expliques, quand tu dis que ça marche pas, explique-moi en détail ce qui se passe chez toi.
Regarde le dump de Maxit sur cpc-p0wer, la protection KBI-19 n'utilise pas les zones GAP comme protection, et le DSK fonctionne correctement !
Tu as un problème, mais ailleurs.
bah non, il marche pas du tout sur la dernière version de Sugarbox pour la même raison...il manque les infos KBI dans la sync de l'IDR...
concernant CPCE v195, il faudrait demander à l'auteur mais il a du rajouter qquechose pour que ça marche !? pour moi cela s'appelle de la bidouille !!!
en tout cas, le raw a bien ces infos et le dsk que je produis personnellement à partir du raw marche très bien (avec ces infos) alors que l'autre non !!!
pour caprice forever 0.28, je ne l'ai pas donc je ne peux pas savoir si cela marche !
de plus, le loader attend ces informations et relis à l'infini tant qu'il ne les trouve pas ! -> il suffit de regarder le code z80 du loader en mode débug pour voir cela aussi de tes yeux !
le dump de MaxIt contient bien ces infos (attention le sectordata de cpc-p0wer ne les affichent pas !!!), je te mets le dsk du site en pièces jointes pour que tu vois la différence avec le dsk que tu as généré ! un simple éditeur hexdecimal te permettra de voir la piste 40 correcte !
donc, j'ai rien à revoir et aucun pb à ce sujet !!!
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Ok, alors histoire d'iilustrer, j'ai refais les tests, et ce coup-ci ça fonctionne plus sous sugarbox !
Par contre sous Caprice Forever 0.28 et la dernière mouture d'Arnold on obtient ceci :
Donc tu m'expliques pourquoi si le loader a un besoin absolu de la mention KBI, et plante s'il ne le trouve pas
fonctionne sans aucun accro sur ces 2 émulateurs, et que donc ce dernier tant qu'il lit tout les secteurs de la piste KBI est content, passe le check et permet au jeu de tourner ?
Que CPCE ait une mauvaise émulation FDC, ça tout le monde le sait, c'est pas un secret. Mais les 2 autres sont bien meilleurs, et montrent clairement que ton explication ne tient pas la route.
Même s'ils étaient buggés tout les deux (ce qui est possible!) le loader devrait se bloquer car il ne trouve pas le marquage KBI entre les secteurs.
Car si le marquage KBI comme tu le dis si bien est vérifié, ça veut dire que dans le code c'est du conditionnel :
- Si marquage KBI = présent alors charger la protection et lancer le jeu
- Si marquage KBI = absent alors stopper le chargement, et bloquer le chargement sur secteur 01 piste 40
Par logique, si tu disais vrai, et si le code qui vérifie la protection fait bien ce que j'indique au dessus, alors quelque soit l'émulateur si la marque KBI est absente alors qu'elle est une condition absolue pour charger le jeu, l'eDSK devrait planter sur n'importe quel émulateur.
Sur ce type de condition, même si l'émulation FDC est avariée, l'absente de la donnée recherchée provoque un stop pur et simple, quelque soit l'émulateur.
C'est comme si on demandait par exemple de vérifier la présence d'un secteur sur une piste à un endroit donné. Même avec une émulation FDC pourrie comme celle de CPCE, si le secteur est pas présent, et si le chargement est conditionné à la présence du dit secteur, le chargement s'arrêtera quoiqu'il arrive.
Hors on constate que sous Caprice Forever 0.28 et Arnold ou encore CPCE, la protection est lue, ce qui veut dire qu'il n'y a pas dans le code de condition testant le marquage KBI intersecteur dont tu parles.
La lecture se poursuit, ça confirme donc que le test dont tu parles n'existes pas. Et ça explique pourquoi en l'occurence au moins 2 autres émulateurs poursuivent la lecture de la piste et passent le test de la protection.
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
_________________ SPS Community Expert (SPS CE) / SPS France
Je confirme ce que dit Megachur : Si l'émulation est correctement faite, ça ne peut pas fonctionner.
Je m'explique :
Voici un diff de la version correcte (CTRaw) et de la version dsk, apres modif pour ajustement des secteurs (j'avais un bug)
On observe donc : - La partie KO ne contient pas certaines données de GAP (et ça, on ne peut pas le déduire d'un dsk) - La numérotation de secteur n'est pas correcte (le secteur suivant le 01 est le 05, pas le 05 - même si ça na pas d'importance - c'est un fait d'autant plus avéré que le CRC est le même dans les deux dumps (issue de la même source de toute façon)) - La taille du GAP du dsk, forcée à 22 (pas d'info sur le sujet) n'est pas la bonne (21 sur le ctraw)
etc, etc...
Du coup, le CRC calculé (les émulateurs qui émulent le MFM calculent le CRC et ne renvoie pas juste "c'est tout bon" est faux. Du coup la protection ne passe pas.
Je peux bien t'expliquer pourquoi ça peut passer sur un autre émulateur plus ancien, mais ça n'aurait guère d'intérêt....
EDIT : Je viens de faire le test, c'est facile. En forcant le CRC a "toujours ok", la protection passe (au temps pour les infos du GAP !) Un emulateur qui dit toujours oui (ou qui retourne les valeurs de retour du dsk sans rien faire d'autre) passera donc ce dump... Mais pas grace au dump, plutot grace à une proteciton basée sur un crc....
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1715
@Lone : j'en déduis donc que les émulateurs cités plus haut ne sont pas bon en émulation FDC sur ce point... et donc en étant mauvais, ils font passer le 'mauvais' dsk...
si j'ai le temps, je ferrai bien un outil d'analyse (raw <-> dsk) comme tu l'as simulé avec les 2 fichiers .txt...cela permettrai d'aider dlfrsilver à la bonne analyse de la conversion en dsk !?
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Lone a écrit :
Hello,
Je confirme ce que dit Megachur : Si l'émulation est correctement faite, ça ne peut pas fonctionner.
Je m'explique :
Voici un diff de la version correcte (CTRaw) et de la version dsk, apres modif pour ajustement des secteurs (j'avais un bug)
On observe donc : - La partie KO ne contient pas certaines données de GAP (et ça, on ne peut pas le déduire d'un dsk) - La numérotation de secteur n'est pas correcte (le secteur suivant le 01 est le 05, pas le 05 - même si ça na pas d'importance - c'est un fait d'autant plus avéré que le CRC est le même dans les deux dumps (issue de la même source de toute façon)) - La taille du GAP du dsk, forcée à 22 (pas d'info sur le sujet) n'est pas la bonne (21 sur le ctraw)
etc, etc...
Merci pour cette explication très bien, donc ça veut dire dans ce cas que l'auteur d'Arnold et Fredouille pour Caprice Forever doivent rectifier le tir, que doivent-il implémenter ou corriger dans leur émulateur, quelle est la condition qui pose problème dans ce cas compte tenu de ce que demande le loader ?
Concernant la piste KBI-19, voici l'ordre des secteurs sur l'original :
Les tailles des zones GAP sont négatives (lol!), à cause je suppose des secteurs en overlap.
Seuls les secteurs 0, 7, 16, 8, 17, 9 ont une taille gap normale soit 15, 95, 95, 95, 94, 94.
Citer :
Du coup, le CRC calculé (les émulateurs qui émulent le MFM calculent le CRC et ne renvoie pas juste "c'est tout bon") est faux. Du coup la protection ne passe pas.
Je peux bien t'expliquer pourquoi ça peut passer sur un autre émulateur plus ancien, mais ça n'aurait guère d'intérêt....
Te casse pas la tête, ton explication est claire
Citer :
EDIT : Je viens de faire le test, c'est facile. En forcant le CRC a "toujours ok", la protection passe (au temps pour les infos du GAP !) Un emulateur qui dit toujours oui (ou qui retourne les valeurs de retour du dsk sans rien faire d'autre) passera donc ce dump... Mais pas grace au dump, plutot grace à une protection basée sur un crc....
Ok, qui peut me désassembler le loader KBI de ce jeu et me le commenter ?
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Megachur a écrit :
@Lone : j'en déduis donc que les émulateurs cités plus haut ne sont pas bon en émulation FDC sur ce point... et donc en étant mauvais, ils font passer le 'mauvais' dsk...
si j'ai le temps, je ferrai bien un outil d'analyse (raw <-> dsk) comme tu l'as simulé avec les 2 fichiers .txt...cela permettrai d'aider dlfrsilver à la bonne analyse de la conversion en dsk !?
Si seulement tout les émulateurs étaient raccord point de vue émulation FDC.....
On aurait pas ce genre de problème ! Genre ce qui est bon est faux, et ce qui est faux est bon.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Ah tiens tant que j'y suis avec Samdisk, j'ai kukulcan qui indique assez souvent que certains DSK posent problème pour lui, étant donné que Samdisk renvoie le message d'erreur en Anglais "Late Track".
Ce message Late Track signifie en fait "retard lecture de piste" ; ce message d'erreur n'est uniquement valable que SI le dump est fait directement à partir de Samdisk, et que suite au retard de la lecture de la piste, il manque 1 ou plusieurs secteurs.
Hors, quand on dumpe avec la carte kryoflux, on a un visuel des pistes lues, et on voit durant le dump si il manque des secteurs.
Si tout les secteurs sont là, il n'y a dans ce cas aucun problème, et de toute façon, lors de la conversion du format KFraw vers le format eDSK, samdisk signale si une ou des pistes ont un problème.
Ah et tant que j'y suis, je poste le DSK tiré de l'IPF avec l'option --gaps. A présent le DSK passe sous sugarbox, mais aussi tout les émulateurs.
Faudra que tu me dises Thomas, ce que je dois expliquer aux auteurs d'émulateurs pour que ces derniers corrigent leur ému en fonction
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
_________________ SPS Community Expert (SPS CE) / SPS France
On peut avoir des "late track" sur un dump fait avec le kryoflux en raw, le dump est alors à refaire, sûrement probleme de lecture de l'index sur la piste incriminée
Ensuite , samdisk ne fait que ce qu'on lui demande, si on omet l'option gap par exemple, mais bien d'autres existent, le dsk sera sûrement mauvais si celui ci est nécessaire pour la protection
Il ne faut pas confondre un boite à outil qui peut faire bien plus qu'une simple convention de format et un convertisseur automatique, ce que n'est certainement pas samdisk
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
breiztiger a écrit :
Juste en aparté
On peut avoir des "late track" sur un dump fait avec le kryoflux en raw, le dump est alors à refaire, sûrement probleme de lecture de l'index sur la piste incriminée.
Je ne suis certainement pas d'accord avec toi à ce sujet. Concernant la carte kryoflux et le logiciel qui va avec, ce genre de problème est automatiquement corrigé lors de la génération des IPFs.
Ensuite n'oublie pas qu'on utilise du matériel, qui même révisé à plus de 30 ans, les disquettes sont vieilles et très souvent en mauvais état.
Je le redis, ce message n'a pour but que de signaler à l'utilisateur qu'il y a eu un retard sur la lecture d'une piste, ceci pouvant provoquer l'absence de secteurs, et donc d'une piste incomplète.
Dans tout les cas que j'ai pu voir, les secteurs sont tous là, donc il ne faut pas tenir compte du message d'erreur.
je cite, tiré du site web de Simon Owen :
"Warning: late track start suggests missing first sector on cyl C head H"
(en français : Attention: retard sur le démarrage de la piste suggère que le premier secteur est manquant sur le Cylindre C tête H).
J'ai pas sorti ce que j'ai dit de mon chapeau, c'est clairement ce qui est écrit en anglais sur le site de Simon.
"The distance between the index pulse and the first sector is suspiciously large, which might indicate the first sector is missing. The PC is unable to access sectors beginning too close to the index hole.
soit en français : "La distance entre l'index pulse et le premier secteur est anormalement grande, ce qui PEUT indiquer que le premier secteur est manquant".
J'ai bien expliqué plus haut, que le premier secteur pouvait dans certain cas être absent pour cette raison, et qu'il fallait vérifier. Mais si tout les secteurs sont là, le message d'erreur n'a AUCUNE importance.
Le fichier eDSK résultat est tout à fait valide et fonctionnel, et si on le réécrit sur une disquette, ça fonctionnera sur un CPC.
Le format eDSK n'est pas un format Piste, mais un format secteur, donc tant que les secteurs sont là et dans le bon ordre, tout est ok.
"This is most commonly seen on TRS-80 disks formatted by early models and DOS versions, as well as BetaDisk disks formatted with some TR-DOS versions. It can also happen on disks with selectively positioned large sectors, such as some high capacity Linux XDF formats."
En français : Ceci est communément vu sur les disquettes formatées sur TRS-80 par les tout premiers modèles et les versions DOS, ainsi que les disquettes BetaDisk formatées avec des versions TR-DOS. Ca peut également se produire avec de gros secteurs spécifiquement positionnés, tel que certains formats Linux XDF de grand capacité.
J'ajouterais aussi que certaines pistes de protections peuvent aussi jouer la dessus.
Citer :
Ensuite , samdisk ne fait que ce qu'on lui demande, si on omet l'option gap par exemple, mais bien d'autres existent, le dsk sera sûrement mauvais, comme pour Crazy cars II
C'est vrai. Le problème est que les émulateurs sont tous inégaux, et la preuve ici dans le cas de Crazy Cars II, pour certains ça marche alors que ça devrait pas, y a encore des émulations de FDC incomplète, incorrectes et ou encore foireuses.
Ensuite, la tierce difficulté vient du fait que de mon côté, comme la protection KBI est une protection de type générique, l'intelligence artificielle de l'outil d'analyse la traite facilement, et pour cause : les disquettes Amstrad sont toutes gravées en mode Piste d'usine, alors que le CPC lui écrit en mode Secteur.
L'outil ne cherche pas à couper les cheveux en quatre, il vérifie simplement que les données sont correctes. si la protection KBI utilise la partie gaps de certains secteurs (comme sur Crazy Cars II ou Bubble Ghost), ces infos sont gardées.
Le problème avec samdisk, c'est que comme c'est une sorte de discology en ligne de commande avec un pilote bas-niveau, il y a de l'erreur possible. Comme on garde pas de base toutes les infos dans les DSKs, et comme les émulateurs sont pas parfait point de vue gestion des disques, ça multiplie les erreurs possibles.
Car je le redis aussi ici, tous les jeux utilisant la protections KBI-19 n'utilisent pas les zones GAP, de ce fait on ne peut pas généraliser leur inclusion, même si par facilité ça semble bien tentant je l'avoue
Citer :
Il ne faut pas confondre un boite à outil qui peut faire bien plus qu'une simple conversion de format et un convertisseur automatique, ce que n'est certainement pas samdisk
C'est juste. Effectivement, avec l'analyseur, étant en mode piste quoi qu'il arrive, et comme les protections sont renseignées, l'IA balaie le dump, décrit les pistes, ainsi que la ou les protections sans intervention humaine. J'ai juste à regarder si il y a des pistes pourries ou pas, si pas de pistes pourries, alors c'est bon.
Mais je dirais quand même que Samdisk n'est pas nécessairement et forcément non plus le coupable.
On aurait le format STX porté sur Amstrad CPC, on se ferait bien moins chier. Ce format est totalement compatible de base avec l'Amstrad même si on l'utilise sur ST (c'est le même FDC sur les 2 machines), et y a pas besoin de s'emmerder en ligne de commande. Les protections et les formats de pistes sont mieux décris qu'avec le format eDSK, et avec un bon logiciel de conversion, on pourrait même les regraver sur disquette dans bon nombre de cas.
_________________ SPS Community Expert (SPS CE) / SPS France
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 11 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum