Pas de souci, je te contacte dès que j'ai fini de trier les 1go de données que j'ai traité

_________________
SPS Community Expert (SPS CE) / SPS France

Voici donc les fichiers RAW provenant de ce dernier batch

Une ou deux choses à noter :

- Corsaires version UK a un problème de palette sur l'écran titre. C'est "normal" les programmeurs d'opérasoft ont
oublié de changer la palette de l'écran (ils ont utilisé celle du jeu MOT.....).

- La protection du jeu ne passe pas sous sugarbox (Je laisse à Thomas le soin de découvrir et corriger le problème).
C'est d'ailleurs valable aussi pour la version DSK, que j'ai corrigé, et qui a la bonne palette.

- Il y a un jeu que je n'ai pas encore inclus, c'est Batman Caped Crusader. En effet, ce jeu a une erreur de mastering,
l'opérateur chargé de la duplication du jeu a fait n'importe quoi sur les dernière pistes du jeu, celles-ci sont dédoublées,
(j'ai vérifié avec le DSK qu'on a déjà que ce soit sur CPC-rulez ou cpc-p0wer, il a le même problème.)
et à charge pour moi de voir si le jeu utilise ces pistes (j'ai au moins testé le lancement des deux parties du jeu, aucune
ne fait appel à ces pistes, mais comme ça serait bête de les enlever si le jeu avait un écran de fin, je vais vérifier.

- Captain Blood a été dumpé en 2 versions différentes, la version d'Ere informatique Exxos classique, et la version Ere
international.

Une des deux version ne se lance pas sous sugarbox que ce soit en DSK ou en IPF. Par contre le fichier RAW fonctionne (lol).

Voilà pour la petite récap, j'ai aussi dumpé quelques jeux en K7, mais rien de bien folichon (Ramblas, un jeu merdique espagnol,
un speccy port appelé Prof Read qui tient sur 3 K7 (dont 1 audio), la cassette de Wolfman de CRL, Et la K7 audio de Mewilo,
qui contient des chansons cwéyoles de Malavoi, "Sidonie", "Apartheid", "Case à Lucie", "Gens Moin".

_________________
SPS Community Expert (SPS CE) / SPS France

Pour Batman the caped Crusader, deux choses confirmées :

1) les deux parties du jeu sont indépendantes, et donc les pistes 26 à 30 dans la disquette originale sont dites 'garbage'
à savoir inutiles et ne contiennent que du déchet, ce qui m'a été confirmé par César.

2) Le système de piste utilisé fait réagir de manière incorrecte Samdisk 3.8.8 ; en effet, si samdisk sait convertir du stream
vers un fichier DSK, il est proprement incapable de faire la différence entre des pistes protégées speedlock avec CRC et
celles qui n'en possèdent pas. Il essaie de calculer dans le vide des CRCs qui n'existent pas sur la disquette originale.
J'ai passé le fichier RAW à nouveau dans l'outil de génération d'IPF, et celui m'indique que les pistes 5 à 25 sont toutes
sans exception sans CRC.

le menu du jeu est sur la piste 05, la partie 1 de la piste 6 à la piste 15, et la partie 2 de la piste 16 à la piste 25.
les pistes 26 à 30 contiennent des pistes speedlock sans données relatives au jeu (ahem ça sent la disquette recyclée...)

ça se présente sous la forme suivante :

Track 05 MFM/.6K no Edc 1801
Track 06 MFM/.6K no Edc 1805
Track 07 MFM/.6K no Edc 1802
Track 08 MFM/.6K no Edc 1804
Track 09 MFM/.6K no Edc 1800
Track 10 MFM/.6K no Edc 1807

etc, etc.....

No Edc signifie ici : 'No (E)rror (D)ata (C)hecksum' ou 'Absence de Checksum contre les erreurs de données'

Samdisk se fait rouler dans la farine, parce que la piste est constituée comme ceci :

3x syncmark 4489
ID : fe
Track : exemple 18 (en hexa, soit la piste 24)
Side : 00
Sector : 23 (valeur utilisée par toutes les pistes du jeu)
Length : taille secteur dans la piste : 06
EDC : codé en CRC16, pour la piste 18 '740B'
GAP : 34 octets de gap
3x syncmark 4489
ID : f8
Data : 6147 octets de données sur la piste (ce sont des pistes longues)
GAP : environ 469 octets de long

En fait, les astuces pour mettre le CPC aux fraises sont multiples :

1) ce sont en fait non pas 1 piste mais 2 pistes mises l'une après l'autre. La première est vue comme un secteur quasi vide, suivi de 34 octets de GAP, et juste après 3 marques de synchro suivies de 5738 octets de données.

2) Le CPC s'arrêtera sur la première fausse piste. La deuxième piste il ne pourra y accèder qu'en lecture.

Problème pour Samdisk, ce dernier ne perçoit que le CRC de la 1ère piste "quasi-vide". Les données du jeu et qui constituent le gros de la piste, c'est à dire la deuxième, se trouvent dans l'énorme zone GAP qui elle n'a pas de CRC.

3) la séparation se fait également par le biais des mots de synchro, que le CPC ne voit pas et ne gère pas.

Il est à noter que même la piste 0 du jeu qui contient 9 secteurs est une piste longue, d'une taille de 6441 octets. La plupart des autres pistes font 6450 octets de long en moyenne, ce qui veut dire qu'on a faire à des pistes longues, ce qui pourrait expliquer aussi l'absence de CRC.

Ce système de piste existe sur Amstrad mais aussi sur Amiga. Le but est que seul le développeur a connaissance des bons checksums, et pas la personne qui a le disk en main. Cela signifie aussi que seule la personne gravant les données sur la disquette originale est en possession des données 100% bonnes, car le loader de pistes fait un chargement brut de données sans vérifier quoi que ce soit. Bon ou pas bon, il charge quand même.

Ceci implique que la disquette dumpée doit être en bon état, sinon on peut avoir des données pourries à un endroit pas directement visible dans le jeu.

L'opérateur qui s'occupe de la duplication peut aussi ne pas implémenter de checksum si les pistes sont longues (c'est le cas ici).

Ca serait bien d'en parler à Simon pour Samdisk, qui veut bien s'en occuper ?

_________________
SPS Community Expert (SPS CE) / SPS France

Salut Denis, merci pour ces dumps.

Pour Corsarios, je vais regarder.
Peux-tu me faire passer l'ipf ou le dsk de blood qui ne passe pas que je regarde pourquoi ?

Pour Batman, le raw m'intéresse également, par pure curiosité : ton analyse me semble "juste" décrire une classique protection avec secteur de taille 6, sans doute entrelacés (le second secteur débute "dans" le premier secteur - permettant la mesure du gap si l'on utilise un read track)

Quelques investigations sur "Corsarios" : J'ai remarqué une différence entre le RAW et le dsk sur la piste &0D : Un 18 s'est transformé en "01". Du coup, ça fout le bouzin par la suite.

Le dsk, lui, a du mal avec la piste &28 (secteur 08, le fameux secteur de taille 8...). Je soupçonne juste une mauvaise gestion de ce dsk un peu particulier...

Pour en être sur, j'ai chargé le dsk jusqu'au menu, échangé les disks, mis le RAW, et lancé le jeu - Là, ça fonctionne.

Je pense donc qu'il faut revoir ce dump... Et revoir ma gestion du dsk de Corsarrios (mais vu que j'ai une trace qui fonctionne, je suis confiant )

Ah enfin quelqu'un qui dit merci ! A la bonne heure

Oui je te PM l'IPF de Blood et le DSK également.

Ce n'est pas vraiment une protection classique. C'est juste que Samdisk a toujours stocké partiellement le contenu des pistes speedlock ou hexagon, c'est à dire pas la piste telle qu'elle est, mais juste le secteur de taille 6, donc une certaine quantité d'information sont invisible dans les DSK.

Il n'y a pas d'entrelacement dans les pistes speedlock/hexagon avec secteur de taille 6.

Tu as "2 pistes" l'une à la suite de l'autre. La première est un fake avec un header trafiqué comme expliqué plus haut et qui commence par 3 marques de synchro $4489, l'ID, un CRC bidon qui met samdisk aux fraises, 34 octets de GAP, et à nouveau 3 marques de synchro $4489, suivie de nouveau par la taille du secteur, puis les données avec 512 octets de visibles et déclarés, puis les 5730 octets de données et des bananes qui sont dans l'énorme zone GAP non déclarée et ne possédant pas de CRC.

Rien à voir avec la protection KBI-19 qui elle est effectivement composée de secteurs entrelacés avec overlap.

L'outil de génération d'IPF le signale bien d'ailleurs quand je teste un fichier CTraw pour générer un IPF : la piste a le sigle OH. Je ne sais
pas à quoi correspond le H, mais le O signifie 'Overlay'.

Les pistes de batman caped crusader ne sont pas dans ce cas. L'outil me signale que j'ai à faire à des pistes longues, d'une taille médiane
de 6445 octets (soit une surcapacité de 10% de stockage, ce qui est tout à fait raisonnable), avec 6147 octets de data dont seul 512 octets sont visibles par l'amstrad si on tente la copie.

L'astuce comme on le sait c'est que l'amstrad est incapable de copier tout ce qui est dans la zone GAP d'une piste. Très fute-fute de la part de David looker, le créateur du système speedlock

En plus comme sur les 6147 octets de données de la piste seuls les 512 premiers octets sont déclarés, ça donne un BAD CRC ahaha

Tiens pour vous montrer physiquement la chose je poste un screenshot tiré d'aufit, l'excellentissime outil de DR Coolzic :

Par ailleurs son outil renvoie un message assez complet (voir en PJ de mon message)

exemple sur la piste 6 (qui est exactement comme toutes les autres pistes du jeu) :

"T06.0-S35 IIF-ISL Invalid ID Field: 6 in an Invalid Sector Length (ISL)
T06.0-S35 DCE DATA CRC Error"

Le premier message en anglais indique que la taille de secteur déclarée (Invalid ID field) dans la piste est illégale/invalide, un secteur de taille 6 est une longueur de secteur invalide, que le seul secteur visible fait 512 octets (taille 2) c'est donc un ISL.

Pourquoi ? Comme je l'ai expliqué dans le paragraphe juste avant, le créateur du système speedlock a déclaré dans la piste un secteur de taille 6, alors qu'il n'y a qu'un secteur de taille 2 (512 octets) de réellement visible. C'est le principe de l' IIF-ISL. Automatiquement, quand il y a une protection de type IIF-ISL, la protection DCE (ou No EDC dans l'outil de génération d'IPF) ou erreur de données CRC.

Ceci parce que seul 512 octets ont été rendus visible sur les 6147 octets de data total que compte la piste. Comme le CRC ne concerne que ces 512 octets et non les 6147 octets de la piste, on obtient un BAD CRC/DCE.

_________________
SPS Community Expert (SPS CE) / SPS France

Le RAW que j'ai généré est une chose, mais j'ai pas encore mis à disposition le fichier DSK. J'ai testé avec sugarbox (dernière mouture) aussi bien le RAW que le DSK, et la protection ne passe pas chez moi.

Je vais t'envoyer le DSK que tu puisses regarder.



Alors explication : physiquement, la protection opera soft est constituée de 9 secteurs. 8 secteur de 256 octets, jusque là tout va bien.
C'est le secteur 9 qui pose souci. Comme pour les pistes speedlock, c'est effectivement un secteur de taille 8, avec seulement 128 octets visibles et déclarés, alors qu'en réalité il y a toutes les infos capitales contenues dans l'énorme zone GAP qui suit ce petit secteur, ce qui nous donne ici aussi un BAD CRC.



Le stockage actuel de la protection Operasoft est aussi conforme que possible compte tenu du format DSK. Ce que je vois quand je charge le dump stream de Corsaires dans Aufit correspond à ce que Samdisk me mouline en DSK.

Je t'envoie sur ta boite mail les IPFs demandés pour correctif

_________________
SPS Community Expert (SPS CE) / SPS France

@lone : je t'ai envoyé les softs en IPF sur ta boite à savoir les deux Captain Blood, y en a un marche et l'autre pas, sans raison apparente.

Salamander lui plante sur le secteur Weak (lu 2 fois, et reset). Tu as le RAW dans l'archive qui fonctionne sous Sugarbox

PS : je viens de tester avec l'implémentation spécial IPF de SPS sur Caprice 32, et l'IPF fonctionne, donc le souci est côté sugarbox

Idem pour Captain Blood, ça passe en IPF pour les deux versions sous Caprice 32.

_________________
SPS Community Expert (SPS CE) / SPS France

@dlfrsilver :
Ton dump "Corsarios (UK) (1989) (CPM) [Original].dsk", arrives-tu à le faire marcher quelque part ?

En adaptant mes algo je fais passer le dump de cpc-p0wer, très très proche de ton ct-raw (un bon bourrin de dsk qui envoie un tour et demi de piste dans son dernier secteur - mais reconnaissons que ça fait le job.)

Pour celui-ci, tout comme les IPF qui ne fonctionnent pas, je soupçonne un bug de la lib : Je récupère directement le bitstream qu'elle m'envoie, sans rien bricoler - Et ce que je récupère diffère d'un autre dump, pourtant semblable.
Et je sais par ailleurs que j'utilise des fonctionnalités que je suis un peu seul à employer... Et donc sans doute pas trop testées (ou pas trop au point)

Si j'ai vraiment le courage, j'irais mettre le nez dedans, mais vu la fréquence du bug, j'ai pas trop envie...

bon, le principal pour moi c'est que j'ai pu vérifier que les IPFs et ou jeux à problèmes fonctionnent sous Caprice32

Je te laisse tout le temps que tu veux pour mettre le nez dans les entrailles de Sugarbox

_________________
SPS Community Expert (SPS CE) / SPS France

Je te remercie de nous faire profiter de tes dumps et toutes le infos de préservations que tu postes ici !!!

J'attire juste ton attention sur le fait que c'est pas parce qu'un dsk / ipf fonctionne sur un émulateur que ça en fait un bon dump !

Je te donne un exemple simple, j'ai trouvé pas mal de dsks qui n'étaient pas corrects... mais qui passaient sans problème avec Sugarbox...parce que Lone a implémenté un moteur d'interprétation des dsks (un superbe travail de titan ) pour corriger pleins de problèmes sur les <<mauvais>> dumps dsks avec par exemple, des mauvaises tailles de secteurs, de gap, etc...
En corrigeant les dsks erronés, ceux-ci fonctionnent maintenant sur les autres émulateurs (ceux qui ne font que traduire les infos du dsks sans réinterprétation des éléments).

Je connais également des émulateurs qui ont en 'dur' les schémas de protections et qui interprètent le contenu des dsks en fonction pendant l'émulation ! C'est pas très beau donc je ne citerai pas de nom d'émul , mais ça fonctionne pour l'utilisateur final !

Pour finir, Sugarbox transforme tous les formats dans un seul -> FM ou MFM, celui qui est inscrit sur la disquette originale... Quand on dit que ça marche pas sur Sugarbox, il y a donc, pour moi, deux sources d'erreurs :
- la première cela vient du dsk qui a des infos erronés
- la deuxième cela vient de la traduction/interprétation du dsk en MFM qui est erronée

Concernant mon émulation, c'est la même chose puisque j'ai codé la même approche que Lone.

Donc le résultat est que le dsk Corsarios (UK) (1988) (CPM) [Original].dsk de cpc-p0wer passe sans pb avec un secteur 08 de la piste 40 avec une longueur de 8192 (au lieu de 32768) -> secteur incomplete
sur le nouveau dsk que tu nous présentes :
le secteur 08 de la piste 40 avec une longueur de &05eb=1515 (au lieu de 32768) -> secteur incomplet avec ST1=20 et ST2=20 (mauvais CRC data)

la commande que le programme envoi au FDC =46-00 28 00 08 08 08 35 ff cpu.pc=0172

donc le programme lit le secteur avec une longueur souhaité de N=8= 32768

Comme le programme ne trouve pas assez de donnée (attendu 8192) il continue à lire le secteur 08 sur le piste suivante...

Je me suis donc amuser à faire la chose suivante : correction du dsk avec une longueur du secteur 08 à &2000=8192 et j'ai fait un simple copier/coller de l'autre dsks du secteur 07 et du 08 pour le contenu... et ça marche sans problème le programme lit les 2 secteurs puis continu le chargement...

en fait la protection consiste à regarder qu'on retrouve le contenu du secteur 07 dans le secteur 08 (à plusieurs endroit visiblement mais j'ai pas trop eu le temps de regarder en détail !?).

d'ailleurs sans bidouiller, en test et pour montrer que le loader est le même (au contenu du secteur 07 et 08 de la piste 40) , il suffit de mettre ton dernier dump de Corsarios, au moment du choix de la phase (ou du chargement du secteur 08 piste 41 en mode débug), on change de dsk (on mets celui de cpc-p0wer qui marche) une fois le chargement du secteur 08 et 07, on laisse le dsks (ou on remets ton dump) et on charge le jeu sans problème...

--> je préconise donc un redump du secteur 08 piste 40 avec une longueur de 8192 et régénération du dsk !

De rien, c'est fait pour !



si la lib de chez SPS fait tourner le jeu (comprendre : la lib crée par SPS comporte un FDC u365 100% parfait, donc aucun risque que les logiciels viennent à déconner), alors si j'écris le jeu sur une disquette, il est garanti que le logiciel tournera sur un vrai CPC.

Pourquoi ? Parce que les protections utilisées sur CPC sont reconnues automatiquement par l'outil de génération d'IPF. Les seuls cas ou ça ne marche pas, ce sont les jeux avec protection discsys, avec protection GAP particulière, ou encore les jeu avec KBI à secteur weak. Si je génère un IPF dans ce cas là, c'est certain, il ne fonctionnera pas sur un vrai CPC ni même un émulateur.

Ceci tu as raison en fait pour Corsarios. Ce deuxième original que m'a envoyé Loic est une anomalie de toute façon. Tu ne l'as pas vu, mais j'ai corrigé la palette de l'écran titre, qui était incorrecte sur le dump original. César a vérifié, et figure toi que les programmeurs du jeu ont utilisé la palette de l'écran du jeu MOT du même éditeur, au lieu de la bonne palette qu'on a sur le dump déjà présent sur CPC-rulez et cpc-p0wer.



En fait, comme il y a un BAD CRC, il relance la lecture plusieurs fois D'ou la nécessité des 32768 en longueur.



Vu, je constate comme toi que le contenu de la piste 40 de ce nouveau dump n'est pas conforme, donc je benne !



En fait, j'ai déjà fait 2 dumps successifs du jeu, et je retrouve toujours la même taille incorrecte, ce qui veut dire que cet original n'a jamais fonctionné en plus d'être claqué !

_________________
SPS Community Expert (SPS CE) / SPS France

Le RAW de corsarios ne pose pas de problème sur la piste 40, pour moi : C'est la piste 04 qui pose soucis (sur un read sector portant sur plusieurs secteurs).
Derrière, la piste &0D pose problème, mais ça peut être lié à la lecture foireuse de la piste 04 (qui sait !)

La piste 40 est un classique : On declare une taille 6 ( ou 7, ou 8), ce qui fait que le read sector va retourner 16 ko de data, donc le contenu réel, passer l'index, et relire la piste du début (plusieurs fois pour une taille 8 - rappel, la taille d'une piste physique, c'est 6k grosso modo).
La synchro est bien sure au fraise dès le trou d'index, et ne va pas s'améliorer avec les différents GAPs
On aura a chaque fois, une chance sur 16 d'être correctement synchronisé (si c'est des gaps aléatoires, bien sur)
Forcément, derrière, avoir un crc correct est plus que compliqué !

Pour l'IPF, le problème peut venir de la lib : Je n'utilise pas leur émulation FDC (vu que j'ai la mienne ), mais suis obligé de passer par là vu le format non documenté - Même si, avec les sources, je vais sans doute finir par faire du retro engineering pour la recoder et pouvoir la maintenir à mon gré.

Oui effectivement, j'ai vu ça. Mais ça ne pose pas de souci, car il y a 5 revolutions différentes de la piste.

Mais le fichier RAW comme le flux stream ne sont pas bons, car la disquette est mauvaise

Le fichier RAW ne fonctionne pas, pas plus que la version en stream sous sugarbox. Le test de la protection échoue à chaque fois et pour cause.

Désolé du dérangement pour ce jeu.



Il n'y a pas d'IPF de Corsarios :

1) les disquettes des espagnols sont vues comme étant non dupliquées, je ne peux pas créer d'IPF à partir de ces dernières, l'outil me l'interdit.

2) La protection Operasoft n'est pas prise en charge par l'outil que j'ai actuellement pour créer des IPFs.

Donc pour le moment, et en attendant qu'on me fournisse la dernière version, ce sera RAW ou DSK

_________________
SPS Community Expert (SPS CE) / SPS France

Ne t'excuse pas, personne n'est 100% parfait
Et de toute façon, tous ces dumps font avancer la cause !