@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...
Megachur : Remettons les choses dans le contexte : Ces anciens émulateurs avaient des contraintes différentes des notres : Pas autant de CPU dispo, moins de connaissance sur des sujets qui ont été débattus depuis, et surtout, un seul format de dump, le dsk, à utiliser. A partir de là, leur implémentation tombe sous le sens, et on a un serpent qui se mort un peu la queue : Une implémentation fondé sur le dsk, et du coup, des dumps basés sur une implémentation du dsk (voir le problemes des dumps avec Overrun, il y a 3 ans a peu près : La plupart des ému ne géraient pas l'overrun, et du coup, les dumps GAP contenaient parfois juste le nombre d'octet à retourner par l'émulateur).
Bref, ne leur jetons pas la pierre (mais tâchons de rester critique !)
Citer :
Faudra que tu me dises Thomas, ce que je dois expliquer aux auteurs d'émulateurs pour que ces derniers corrigent leur ému en fonction
@Denis : Comme dit à Megachur, ne leur jetons pas la pierre (après tout, chaque émulateur à ses qualités, différentes à chaque fois !).
Cela dit, s'ils veulent améliorer leur émulateur côté disquette, je pense que le passage à un format MFM est plus ou moins nécessaire... Mais c'est un gros taf, surtout la conversion DSK vers MFM, qui, suivant les dumps, est parfois un vrai challenge (je reste à la dispo de tous si vous avez des questions sur ce sujet qui m'a confortablement occupé ces deux dernières années).
Sur le sujet des late tracks : Je pense à un dump que l'on a eu il y a peu ici même, ou le premier secteur commençait avant le trou d'index (ou bien le dernier secteur débordait sur le début de la piste... C'est une question de point de vue). A mon avis, ça ressemble à l'exemple typique d'un "late track"
Pour le format STX : Je le coderais un jour si j'ai la foi, mais j'avoue être réticent à coder un truc qui ne sera sans doute jamais utilisé... (faudrait déjà que je trouve une spec du format, j'imagine que les forums Atari ST doivent être un bon début !) L'IPF me parait, pour le coup, assez semblable, et plus utilisé (merci HXC, Kryoflux, et la sps ). Ne manque plus que les dumps soient enfin dispo sur cpcrulez et cpcpower !
La frontière est à mon avis floue en ce sens que une piste est constituée de secteur, cela ressemble à utiliser une lecture secteur sur le fdc ou bien un "read track"
On peut voir les deux suivant comment on "regarde"
Perso, je trouve qu'il y a meme souvent trop d'info dans un dsk, on pourrais simplifier certain dsk, je pense à implémenter cela dans mon editeur, par exemple couper à &1800 les tailles 6 sans crc...
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Citer :
Megachur : Remettons les choses dans le contexte : Ces anciens émulateurs avaient des contraintes différentes des notres : Pas autant de CPU dispo, moins de connaissance sur des sujets qui ont été débattus depuis, et surtout, un seul format de dump, le dsk, à utiliser. A partir de là, leur implémentation tombe sous le sens, et on a un serpent qui se mort un peu la queue : Une implémentation fondé sur le dsk, et du coup, des dumps basés sur une implémentation du dsk (voir le problemes des dumps avec Overrun, il y a 3 ans a peu près : La plupart des ému ne géraient pas l'overrun, et du coup, les dumps GAP contenaient parfois juste le nombre d'octet à retourner par l'émulateur).
Bref, ne leur jetons pas la pierre (mais tâchons de rester critique !)
Je suis d'accord avec toi. A cette époque, nous n'avions pas non plus les outils d'aujourd'hui, et les gens sur CPC croyaient que les disquettes c'était uniquement du sectoriel.
Forcément, ce que tu appelles l'overrun, l'Amstrad ne le voit pas, il ne voit que du secteur. Donc impossible de s'en rendre compte.
Avec Aufit, et le kryoflux, on voit enfin à quoi on a à faire, et ça change tout. Reste à mettre définitivement à jour les FDC dans les émulateurs, qu'on soit tous raccord.
Citer :
@Denis : Comme dit à Megachur, ne leur jetons pas la pierre (après tout, chaque émulateur à ses qualités, différentes à chaque fois !).
Cela dit, s'ils veulent améliorer leur émulateur côté disquette, je pense que le passage à un format MFM est plus ou moins nécessaire... Mais c'est un gros taf, surtout la conversion DSK vers MFM, qui, suivant les dumps, est parfois un vrai challenge (je reste à la dispo de tous si vous avez des questions sur ce sujet qui m'a confortablement occupé ces deux dernières années).
Il ne s'agit pas de jeter la pierre, mais d'aller vers un effort commun pour que tout les émulateurs soient raccord et au même niveau. Merde, quand je vois la qualité de l'ému FDC d'Hatari ou même Steem SSE, merde quoi, pourquoi sur CPC ça sent encore le baton merdeux ?
Citer :
Sur le sujet des late tracks : Je pense à un dump que l'on a eu il y a peu ici même, ou le premier secteur commençait avant le trou d'index (ou bien le dernier secteur débordait sur le début de la piste... C'est une question de point de vue). A mon avis, ça ressemble à l'exemple typique d'un "late track"
Tu fais allusion à The Hunchback d'Ocean. Ce jeu est un vrai problème, pour moi la protection n'est absolument pas supportée que ce soit côté IPF ou DSK. Il ne s'agit pas d'une protection donnant un late track. L'exemple n'est pas bon.
Citer :
Pour le format STX : Je le coderais un jour si j'ai la foi, mais j'avoue être réticent à coder un truc qui ne sera sans doute jamais utilisé... (faudrait déjà que je trouve une spec du format, j'imagine que les forums Atari ST doivent être un bon début !)
Demande à Steven Seagal ou à Nicolas Pomaredes (l'auteur d'Hatari), et explique-lui ton but.
Le format STX est sectoriel, MAIS, contient les timings des pistes, secteurs, et protections, ce que ne contient absolument pas le format eDSK. Le format STX peut par ailleurs contenir et gérer des protections qu'on est obligé de trafiquer dans le format eDSK.
Pense aussi à Aufit, Jean-Louis n'aurait qu'à faire un ajout mineur, et n'importe qui pourrait générer des fichiers STX, sans même parler du fait qu'on pourrait avoir des visuels des protections CPC, chose que le système de kukulcan ne permet pas par exemple.
Autre truc, Aufit donne exactement le type de protection utilisée sur une piste donnée, donc c'est que du bon !
Citer :
L'IPF me parait, pour le coup, assez semblable, et plus utilisé (merci HXC, Kryoflux, et la sps ). Ne manque plus que les dumps soient enfin dispo sur cpcrulez et cpcpower !
Le format IPF est plus complexe que le format STX. Les fichiers IPFs peuvent tous être réecrits sur disquettes. certains softs au format STX ne peuvent pas (mais ça ne concerne pas le CPC, exemple la protection copylock)
Oui mais complexe, et flexible, bien plus intéressant que le format eDSK!
Citer :
Comme d'habitude la vision piste ou secteur ...
Hé oui, car comme tu le sais, le FDC du CPC est en réalité une boite noire, un interpréteur de données.
Citer :
La frontière est à mon avis floue en ce sens que une piste est constituée de secteur, cela ressemble à utiliser une lecture secteur sur le fdc ou bien un "read track"
Hé bien non justement. Je t'invite à comparer ce que tu vois en secteur dans un eDSK, et un de tes dumps KF raw sous Aufit, tu vas rapidement t'apercevoir que les données telles qu'elles sont stockées réellement sur une disquette ne ressemble en rien à ce que tu as dans un fichier eDSK.
exemple : le jeu Space Racer UK que tu as surement dans les mains en IPF officiel, le dump original montre que le dernier secteur de la piste de protection est coupé en deux, la première partie est en fin de piste, et la deuxième partie est au dessus du trou d'index (le démarrage de la piste ou se trouve le premier secteur).
ça c'est impossible à reproduire dans le format eDSK. Tout les secteurs sont l'un à la suite des autres.
Citer :
On peut voir les deux suivant comment on "regarde"
La vue secteur est la vue interprétée par le FDC du CPC. Mais ce n'est pas la vue réelle. Les données étaient écrites en write track sur une traceuse industrielle en usine.
Citer :
Perso, je trouve qu'il y a meme souvent trop d'info dans un dsk, on pourrais simplifier certain dsk, je pense à implémenter cela dans mon editeur, par exemple couper à &1800 les tailles 6 sans crc...
Le souci c'est que certaines pistes font un peu plus que ça. exemple la compil Coin-op Hits. si tu coupes à &1800, tu vas couper &A1 de données, résultat la compil ne fonctionnera plus.
La longueur de sécurité pour moi, c'est &1900 de long par piste. Couper comme ça à ras, ça va forcément poser problème, on l'a vu par le passé, certaines compil ou jeu ne pouvaient pas être dumpés à cause de ça.
Maintenant, on est d'accord sur le fait que les pistes Speedlock n'ont pas de CRC. Par contre, les pistes hexagon elles, ont toutes un CRC, sans exception.
Donc prudence ! rien ne permet de distinguer les pistes speedlock des pistes hexagon (hormis le CRC). Idem, les pistes de Crazy Cars II. Elles sont stockées sous forme de secteur de taille 5, en réalité ces pistes ressemblent aux pistes speedlock !
_________________ SPS Community Expert (SPS CE) / SPS France
Pour le format STX : Je le coderais un jour si j'ai la foi, mais j'avoue être réticent à coder un truc qui ne sera sans doute jamais utilisé... (faudrait déjà que je trouve une spec du format, j'imagine que les forums Atari ST doivent être un bon début !)
À mon humble avis il est inutile de se pourrir la vie avec des formats obsolètes qui fonctionnent en sectoriel comme le STX ou même le DSK
Si on doit ajouter des weak/strong/random bit à un format, faisons-le sur un format brut de fonderie comme le HFE (on pourrait même faire évoluer logiciellement les simulateurs de floppy hardware au passage!)
Physiquement, dès lors qu'on a une image brute de la disquette, on n'a besoin de rien de plus non?
Par contre, niveau émulateur, il devient indispensable d'avoir une émulation FDC un peu plus aboutie, c'est certain, bien qu'il soit probablement inutile de s'embêter à aller jusqu'au codage FM/MFM vu que les données sont "parfaites", peu importe le codage, on n'utilise au final qu'un bit sur deux. Et surtout le FDC a au final une vision à l'octet de la disquette. Non?
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
marcel a écrit :
Par contre, niveau émulateur, il devient indispensable d'avoir une émulation FDC un peu plus aboutie, c'est certain, bien qu'il soit probablement inutile de s'embêter à aller jusqu'au codage FM/MFM vu que les données sont "parfaites", peu importe le codage, on n'utilise au final qu'un bit sur deux. Et surtout le FDC a au final une vision à l'octet de la disquette. Non?
Malheureusement, ce n'est pas si simple. La protection du type "Réussir" va lire tous les octets d'un secteur de taille 6. Et le nombre d'impulsions MFM contenus dans une piste n'est pas forcément pair.
Malheureusement, ce n'est pas si simple. La protection du type "Réussir" va lire tous les octets d'un secteur de taille 6. Et le nombre d'impulsions MFM contenus dans une piste n'est pas forcément pair.
Ok je vois le genre de protection. Ils arrivaient à les écrire à tous les coups ces disquettes? Ça demande une sacré précision pour un support magnétique physique à l'air libre!
Je suis assez d'accord avec breiztiger : Le format IPF me parait avoir toutes les caractéristiques voulues pour remplacer le DSK, ne manque que les outils pour l'écrire et le lire (et encore, ils apparaissent petit à petit)
Le format MFM parait indispensable également pour se simplifier la vie : Une fois implémenté, les protections ne sont plus un problème (aux bugs près). On est à un niveau inférieur, ce qui fait que tout marche toujours comme sur des roulettes. Se cantonner aux données brutes pose problème dès lors qu'on a des bits manquants (courant dans les GAP ou en fin de piste ), notamment lorsqu'on a des tailles 5 & 6 de secteurs.
Presque : lors de la recherche du secteur suivant à lire, le FDC va déjà chercher les fameux 12 octets à 0, pour se caler correctement sur les bits de data (en MFM, 0 = 10. 1 = bit de clock, 0 = data) Ensuite, des lors que c'est correct, il va détecter l'octet de synchro, qui lui permet de se caler pour lire un octet :
Voici les fameux A1 et C2, qui, en MFM, s'écrivent 0x4489 et 0x5224 : En décodant "a la MFM" ces octets, on remarque une erreur : 4489 = 01 00 01 00 10 00 10 01 ^^ => Incorrect ! Devrait être 10 !
Cette erreur, répétée trois fois, permet de garantir que l'on est pas sur une piste avec des données bêtement ressemblante (12 octets à 0, suivi de trois fois A1).
Le CRC, lui, sert uniquement de vérification de ce que l'on lit.
Aaaaaaaaaaaaahhh, ça c'est intéressant, ça veut dire que quand il écrit ses A1 ou C2, il fait volontairement l'erreur pour être sûr que c'est ça qu'il trouvera ensuite!
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Citer :
Malheureusement, ce n'est pas si simple. La protection du type "Réussir" va lire tous les octets d'un secteur de taille 6. Et le nombre d'impulsions MFM contenus dans une piste n'est pas forcément pair.
@fredouille : jusqu'ici je n'ai pas encore vu la gueule de cette protection telle qu'elle est écrite sur les disquettes originales. Il y a 99% de chances que cette piste de protection ait une tronche différente de celle que les eDSKs présentent, comme la plupart des protections que j'ai pu voir jusqu'ici.
Citer :
Presque : lors de la recherche du secteur suivant à lire, le FDC va déjà chercher les fameux 12 octets à 0, pour se caler correctement sur les bits de data (en MFM, 0 = 10. 1 = bit de clock, 0 = data) Ensuite, des lors que c'est correct, il va détecter l'octet de synchro, qui lui permet de se caler pour lire un octet :
Voici les fameux A1 et C2, qui, en MFM, s'écrivent 0x4489 et 0x5224 : En décodant "a la MFM" ces octets, on remarque une erreur : 4489 = 01 00 01 00 10 00 10 01 ^^ => Incorrect ! Devrait être 10 !
Cette erreur, répétée trois fois, permet de garantir que l'on est pas sur une piste avec des données bêtement ressemblante (12 octets à 0, suivi de trois fois A1).
Le CRC, lui, sert uniquement de vérification de ce que l'on lit.
Tu as décris le fonctionnement en mode secteur. Maintenant voici comme ça se passe en mode piste (read track) :
Comme les données d'une piste peuvent contenir les octets 00 à FF, on ne peut pas les écrire avec un FDC standard (ni $F5, $F7, $FF).
Le FDC du CPC et du ST ont un bug dans le read track, qui essaie de se synchroniser en permanence et certains octets peuvent activer la synchro ("dangereux!"), qui ira détruire les octets qui se trouvent après. Pour cette raison, un octet de la valeur $07 précède toujours n'importe quel octet qui pourrait resynchroniser le FDC.
C'est exactement le principe suivi par le jeu Maupiti Islands sur Atari ST.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Lone a écrit :
Je suis assez d'accord avec breiztiger : Le format IPF me parait avoir toutes les caractéristiques voulues pour remplacer le DSK, ne manque que les outils pour l'écrire et le lire (et encore, ils apparaissent petit à petit)
Sauf que le format est en fait un container, c'est ce que je t'expliquais plus haut. Il ne s'agit pas simplement de remplir l'espace de chaque piste dans le format, il faut décrire chaque format de protection, ceci parce que la carte kryoflux a besoin de ces informations au moment de l'écriture.
Sinon, ça revient à faire comme sur Amiga des ADFs étendus, fichiers dans lequels on stocke simplement ce qui a été lu.
Les données doivent être analysées avant d'être injectées dans le fichier final.
Le créateur du système ne laissera personne faire tout et n'importe quoi avec le format, qui lui appartient.
Citer :
Le format MFM parait indispensable également pour se simplifier la vie : Une fois implémenté, les protections ne sont plus un problème (aux bugs près).
Je reviens à ce que je te disais plus haut, n'importe quel idiot peut prendre les données et les mettre dans un container IPF. ça ne nécessite aucune connaissances, par contre y a aucun garde-fou contre les erreurs, et puis à l'écriture c'est tout sauf fiable.
Mais c'est pas de la préservation, c'est la solution de facilité.
Citer :
On est à un niveau inférieur, ce qui fait que tout marche toujours comme sur des roulettes. Se cantonner aux données brutes pose problème dès lors qu'on a des bits manquants (courant dans les GAP ou en fin de piste ), notamment lorsqu'on a des tailles 5 & 6 de secteurs.
Il n'y a pas de secteurs de taille 6 sur les disquettes originales. L'amstrad CPC fait du read track sur des pistes spéciales, ayant un bout de secteur en EDC d'une taille de 512 octets. Tout le reste est dans une gigantesque zone GAP. Mais comme on ne peut pas stocker (je suppose...) une telle piste sous sa forme réelle, samdisk stocke ces pistes sous forme de secteur de taille 6, ce qui est clairement différent.....
Y a qu'à regarder sous Aufit un jeu comme Strider, ou encore Ghouls'n'Ghosts par exemple, pour comprendre le truc.
_________________ SPS Community Expert (SPS CE) / SPS France
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 108 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
). Ne manque plus que les dumps soient enfin dispo sur cpcrulez et cpcpower !
