Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
JMD a écrit :
Hello,
Pas certain que ça vous serve à quelque chose mais j'ai dumpé en eDsk avec Samdisk 3.0 mon original 5.1 de Discology. Winape trouve un secteur avec une taille anormale, c'est peut être un bug sur mon disque ou la protection.
Voici ce que me donne Caprice concernant la disquette de la version 2.0 de discology. L'organisation est, comment dire, plutôt farfelue !!
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
Lorsque je lance l'exploration du disque, discology lance une multitude de commandes "Read ID" puis plante.
Dans le code de Caprice, à chaque Read ID, le pointeur de secteur saute au prochain secteur. J'ai bien essayé de retirer ce saut, Discology plante toujours mais différemment.
Quel est l'intérêt d'effectuer une tripotée de Read ID à la suite ?
Je cherche dans le Datasheet du FDC pour vérifier l'état des flags dans les status retournés et voir si Discology n'en attend pas un en particulier qui ne serait pas positionné.
J'ai examiné le code, et j'en ai déduis les choses suivantes :
- Discology effectue des Read ID et mesure le temps total écoulé, ceci afin de détecter à quel moment il aura lu la piste entière, pour récupérer l'intégralité des secteurs de la piste.
- Caprice ainsi que mon émulateur n'émulent pas le temps d'accès à chaque octets de la piste (contrairement à winape, à condition de décocher "fast disc emulation"), voilà pourquoi ils font "planter" discology, qui emagazine trops de secteurs ID et finit par écraser son propre code...
La solution est biensur d'émuler ces temps. L'idéal étant d'émuler une disquette, avec la rotation et les temps d'accès à chaque octets des secteurs.
Je vais essayer d'intégrer ça dans mon ému et je publierai ici les résultats
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
Normalement, il suffit d'ajouter une tempo entre la réception des commandes et la disponibilité du résultat. Je vais tenter quelque chose de mon côté aussi.
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
J'ai ajouté une tempo pendant laquelle la lecture de du "main status" retourne FDC executing et FDC Busy.
Maintenant, quel est la durée d'une lecture d'un secteur ?
Avec 50ms, l'exploration du disque se plante comme s'il n'y avait aucun délai. Avec 150ms, l'exploration freeze. Avec 250 ms, je commence à voir les barres noires, mal placées, puis l'émulateur se plante à nouveau.
En fait c'est un peu plus compliqué que ça, vu que ça dépend de la taille du secteur. Pour bien faire, il faut aussi prendre en compte tous les autres octets de la piste (les différents gaps, octets de synchro, crc...) Sachant qu'en MFM la fréquence des bits transférés depuis/vers la disquette est de 500Khz, soit 2µs, cela fait donc 16µs par octets.32µs par octets car un bit en MFM nécessite deux impulsions. Sachant encore que le lecteur tourne à 300tr/min, soit 200ms pour faire un tour complet, on peut donc en déduire que l'on peut lire au maximum 200000/16 = 12500 200000/32 = 6250 octets sur une piste (pour une rotation complète). Bref y a du boulot quand même. Dès que j'ai le temps de coder tout ça je posterai ici.
[Edit]J'ai corrigé vu que j'avais oublié qu'en MFM il faut 16 bits pour encoder un octet[/edit]
Un petit schéma pour résumer tous les octets se trouvant sur une piste :
- GAP 4a : 80 octets à #4E - Sync : 12 octets à #00
Ces 92 premiers octets se retrouvent lorsque le disque est en face du "trou" d'index, soit au tout début de la piste.
- IAM : 3 octets à #C2 + 1 octet à #FC - GAP 1 : 50 octets à #4E
Puis, pour chaque secteurs : - Sync : 12 octets à #00 - IDAM : 3 octets à #A1 + 1 octet à #FE - C (identification secteur 'C' = 1 octet) - H (identification secteur 'H' = 1 octet) - R (identification secteur 'R' = 1 octet) - N (identification secteur 'N' = 1 octet) - Crc (1 octet) - GAP 2 (22 octets à #4E) - Sync : 12 octets à #00 - DATA AM : 3 octets à #A1 + 1 octet à #FB ou #F8 - Les n données du secteurs (512 octets pour un secteur 'standard') - Crc (1 octet) - GAP #3 (x octets, dépend du formatage)
Pour finir, en fin de piste, on a le GAP 4B, qui sert à "remplir" le reste de la piste, pour arriver au total de 6250 octets.
Avec le schéma classique de l'amsdos, 9 secteurs de 512 octets et GAP3=#4E (78), on voit que l'on a, pour une piste :
80+12+4+50 octets en début de piste = 146 (12+4+4+1+22+12+4+512+1+78)*9 = (60+512+78)*9 = 5850 reste pour le GAP 4B (fin de piste) = 6250-5850-146 = 254 octets
Avec un Gap#3 à #24 (36), on arrive à mettre 10 secteurs par piste, en effet : toujours nos 146 octets en début de piste, on a maintenant 608 octets par secteurs, soit 6080 octets pour 10 secteurs reste : 6250-6080-146 = 24 octets
J'espère avoir été clair dans mes explications, et ne pas m'être trompés dans mes calculs
Ces informations étant très intéressantes et pas toujours facile à trouver, je me suis dit qu'il serait intéressant que je les enregistre également sur mon site.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
Demoniak a écrit :
J'espère avoir été clair dans mes explications, et ne pas m'être trompés dans mes calculs.
Ces valeurs me sont parlantes. Maintenant, la taille des secteurs est imposée. Je ne crois pas qu'il soit possible d'utiliser 608 octets ... Tu seras limité à 512. (avec des gaps plus gros donc) Dans le cas d'un formatage sur 40 pistes, tu auras donc 10*512*40 = 200Ko. (205Ko pour 41) Sachant qu'il ne faut même pas espérer avoir 11 pistes en grappillant sur la taille des gaps.
C'est clair que l'émulation du FDC est le parent pauvre du CPC. Et encore, on a la chance que le lecteur tourne à vitesse constante !
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
Bien sur, il sera en ligne sur cpc-p0wer.
Mais en regardant le datasheet du FDC ce matin, il me semble avoir vu ces infos, à la fin du document, en présentant les différents formats des disquettes de l'époque. Le datasheet est dispo dans la section "Téléchargement" de cpc-p0wer.
Perso j'utilise Discology version 6.0+ de XOR qui tourne parfaitement bien sous WinAPE mais pas sous Caprice.
Je dispose de deux versions qui fonctionnent mais comme tout cela remonte à quelques années je ne me souviens plus quelles sont les différences entre ces deux versions. Bref, à toutes fins utiles je vous ai mis les deux versions dans le fichier RAR ci-joint.
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
Merci, je vais voir ce que cela donne sur mon Caprice.
Mais je reste d'accord avec Demoniak, Discology à l'air de lire de façon physique la disquette. Il faut donc simuler tous les temps d'accès, de lecture... Je continue d'éplucher le datasheet du FDC, et la littérature associée.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 35 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
Connexion
Inscription
FAQ
