Coucou dlfrsilver !

Ça doit être poussé à l’extrême limite du contenu possible d'une piste ! Surement comme tu l'as indiqué du fait de l'avancée technologique des dernières traceuses industrielles sur le magnétisme des pistes des disquettes 3 pouces !

Je pense avoir identifié ce qui ne va pas...

Ici on a des pistes de 6421 et 6422 bytes en RAW et avec la reconstruction à partir du DSK, j'arrive à 6679 bytes et 6727 bytes !!!
ce qui est vraiment énorme !!!
mais c'est pas ça le pb !

Côte CPCEPower, il y a des erreurs de données pour moi sur le RAW... et ce même en réparant les secteurs entre eux, c'est dans les choux !
Le dsk fonctionne très bien.... donc ce n'est pas un pb d'émulation FDC mais bien une mauvaise correction des données RAWs : faut dire que je ne corrige que les secteurs entre eux, donc s'ils sont tous avec la même erreur -> bam boum !

2 solutions que je vois dans l'immédiat :
1) refaire un ou plusieurs autres RAWs si c'est possible ? on va peut-être tomber sur un dump 'propre' sans erreur ?!
2) m'envoyer l'ipf également pour que je compare avec quelques choses de propre... mais il me semblait que la sps ne savait pas faire encore des ipfs amstrad avec des weaks secteurs ou fuzzy bits ?

bref, pour faire passer le RAW, c'est pas gagné dans l'immédiat !!!

Bonsoir,

Ca bloque sur quel dump / jeu ?
J'ai essayé Black tiger, strider, gouls'n'ghosts, Dynasty wars, et Led Storm, et ils sont tous ok sur le ctraw (en tout cas, je lance les jeux)

Le tout, sur ma version "en cours".

Bon, je reprends l'analyse depuis le début en comparant les données de l'IPF par rapport au eDSK : avant de dire que c'est un pb autre ... !

la protection HEXAGON passe en piste 0 et oui de se côté tout me semble nickel, secteur standard, etc. le menu s'affiche super !

puis lecture des pistes du jeu, relecture plusieurs fois parce que c'est pas bon (pas confiant le loader ) et boum !


exemple : la piste 15 (&0e) se présente comme cela (vue IPF donc parfaite ) :



donc pas d'info de début de piste... bon ça c'est pas grave et c'est ce qui explique qu'on puisse mettre autant de données dans le secteur !

si je compare avec mon 'interprétation' de l'eDSK qui lui fonctionne :
je rajoute un synchro piste par défaut ce qui ne devrait pas y être mais comme on ne le sais pas avec le format eDSK : lacune de ce format qui n'a qu'une vue secteurs et pas piste (depuis le temps que je le dis ) !
le gap n'est donc pas le même entre le début de la piste et les infos de synchro et l'IDR du secteur 01
même info et même données à partir de là...
Sauf à la fin ou SAMDISK à rajouter :

clairement, SAMDISK s'attend à un gap à la fin... comme il trouve le début de la piste (gap avant les infos du secteurs) décalé d'un ou plusieurs bit .... c'est un peu n'importe quoi...

ceci étant posé, voici ce que le loader envoi au FDC et ce qu'il lit dans les données MFM



--> c'est pas beau ça : le même résultat côté FDC, donc le loader ne verra pas de différence de ce côté à mon avis !

alors une idée ?
donc c'est qu'on a pas lu les mêmes données -> j'en déduis que mon décodage des infos IPFs en amont doit être erroné quelque part !
--> le loader doit faire un checksum des données lus en + pour s'assurer qu'elles sont bonnes et ça passe pas !

à suivre avec l'analyse de Lone bien sûr en complément vu que SUGARBOX est bien meilleur pour l'analyse des données IPFs, et CTRAW (si si si !!!)

J'ai regardé vite fait.
Les faits :
- J'arrive à lire le DSK et le CTRAW, qui me donnent les bonnes infos.
- L'IPF ne marche pas par contre. Quand on regarde le détail, on a effectivement des incohérences entre les 3:

Piste 0xD , secteur 01 :
L'IPF me retourne un GAP beaucoup trop tot au lieux des infos voulues (présentes dans le CTRaw et le dsk).
Ca porte sur les 38 derniers octets grosso modo. Ca se situe immédiatement après le passage de l'index (sauf sur le dsk ou l'on n'a pas les moyens de le savoir

En gros, on a (dump correct) :
BA BA 44 BD BF 47 C0 C0 3E C3 C5 35 C6 A6 38 C9 B5 3B CC B2 32 CF AF 29 D2 AC 2C D5 C9 2F D8 C6 1D 5C 23 1F DF D0 20 E1
Là ou l'IPF à :
BA BA 4E 4E 4E 4E 4E 4E 4E 4E...

Pour avancer un peu :

Dans le dump de l'ipf, offset 0x17AC0, on a : 48 BE AC 2D AE AF 70 B1 B2 73 B4 B5 56 B7 B8 41 BA BA
Suivi d'une fin de bloc beaucoup trop tôt !

Il manque donc bel et bien les infos dans l'IPF, info présentes dans le DSK, ainsi que dans le CTRaw (pour lui, il est possible qu'il y ait une reconstruction à partir de plusieurs pistes)

Ma conclusion rapide : Je pense que l'IPF est généré un peu trop court sur cette fameuse piste 0x0D...

--> j'ai clairement une différence d'octet entre le eDSK et le CT-RAW à la toute fin de certaines pistes !

Lone : peux-tu me dire juste si tu fais un correctif de données sur cette fin piste en format CT_RAW ?
Cela pourrait expliquer pourquoi le CT_RAW ne passe pas de mon côté... Sugarbox powaaa comme d'hab !!!

dlfrsilver : pour valider si l'ipf est fonctionnel, test avec kryoflux sur le vrai hardware et un 6128 avec lecteur de 3p ?

Megachur : Mes traces sont en vrac, c'est donc compliqué de suivre.

Par contre, j'ai un comportement bizarre : Sur la fin, rien ne convient. En effet, j'ai un 30aine de bit détectés comme "weak". Par contre, ma piste générée est bonne à tous les coups. Bref, wtf ??

J'ai tenté la création d'IPF depuis Sugarbox, et le dump généré fonctionne plus ou moins (avec Caprice IPF, c'est oui, mais pas avec cpc-power-emu)

Je vous tiens au courant une fois que j'aurais réparé les trucs cassés

Le CTRaw, pour la piste 13, présente une taille (après mes algo de reconstruction) de 102746 bit MFM.
Si on divise ce total par 16, ça donne 6421 octets.
Une piste "standard", c'est 6250 octets (100 000 bits). On est donc 2% au dessus de la norme, ce qui est supporté largement par le hardware (de mémoire (à prendre avec des pincettes donc), les tolérances son de l'ordre de 5%).

Kris : Pour la reconstruction, ça va être coton (même si l'IPF généré par Sugarbox 0.29 est correct, ce qui ne semble pas puisque le ctraw ne semble pas se charger sur cette version d'après Denis (je n'ai pas vérifié)). En effet, cette fameuse piste 13 (et ça n'est pas la seule) déborde au dessus du trou d'index.

J'ai fait des tentatives avec MAxit dans le même genre : Pour avoir tenté le coup sur les dumps "réussir", on a pu constater que le dump fait à partir de l"image reconstituée merdouillait au niveau de ce trou d'index. Difficile, voir impossible avec le matériel actuel, d'avoir donc quelque chose d'assez précis. On pourra d'ailleurs corroborer cette intuition avec des dumps, si tu as le temps, de l'IPF qui a servi à la reconstruction, et du CTRaw (ou autre format bas niveau) issue du dump généré.