Inscription : 12 Juin 2008, 20:29 Message(s) : 1715
Je lance ce sujet, histoire de faire le point sur un meilleur format que le eDSK.
Le principe de ce format, que je vais appelé tDSK, est une vision de la disquette en track, d'où le t.
Il permettrait dans un premier temps, de partir des eDSK existants et de les convertir en tDSK (ce que fait Sugarbox ou mon émulateur). Et bien sûr, à partir des dumps raw de générer les tDSK.
Sa structure serait assez simple, une vue globale de la piste, tel quel est lue par le FDC en vue 'octet' MFM ! Et une conversion au format bit/MFM serait très aisé (à valider par Lone pour Sugarbox).
Il prendra un peu plus de place que le format eDSK actuel, mais cela ne va pas rajouter des tonnes d'octets non plus, et même des eDSK qui ne gèrent pas correctement les secteurs seront presque de la même taille.
Cela permettrait notamment, de : - gérer correctement les secteurs entrelacés (protection KBI, ERE, etc.), plus d'utilisation des GAPs pour déduire comment est la 'vrai' piste ! (exemple : Mission En Rafale (UK, F) (1987) [Original].dsk ou Balade Outre-Rhin (F,G) (1986) (CPM) [Original].dsk) - mettre les vrais infos et CRCs présents sur la disquette, plus de valeur ST1 et ST2 et de déductions sur ce qu'étaient les infos de la piste ou du secteur sur la disquette ! il n'y aurait plus une vision globale pour tous les secteurs d'une piste du GAP par exemple, mais indépendante pour chaque secteur. - avoir les 'vrais' tailles des pistes, plus de somme des tailles des secteurs > à la taille de piste réelle avec plein de données redondantes entre les secteurs du eDSK (secteur de taille 8, incomplète secteur, etc.!
Les émulateurs existants qui ne gèrent l'émulation FDC qu'en secteurs, pourrait intégrer le contenu des secteurs facilement et déduire les valeurs ST1 et ST2 facilement en ignorant les informations supplémentaires... Dit autrement, la conversion tDSK vers eDSK devrait pouvoir se faire sans trop de code supplémentaire ... Mais ce serait mieux qu'ils utilisent les 'vrais infos' du tDSK en intégrant ce nouveau format !!!
Seul point d'ombre pour moi, la gestion des weaks secteur... Soit Lone a un algo fiable qui permettra de les gérer et dans ce cas, on aura juste un flag qui indique qu'un secteur et quelles données sont weak avec juste les datas du weak secteur lu la première fois !? ou alors comme le format eDSK, on stockera 3 pistes (ou 3 fois le secteur), à voir !?
global : Liste des index du début des tracks et leurs tailles.
vision macro du format par piste : TRK Liste des index du début des secteurs et leurs tailles (DATA et GAP).
pour chaque piste:
// Pre-index GAP after the first edge of the index hole // Gap 1 (post index gap)
pour chaque secteur de la piste :
// Sync // ID record // Gap 2 (ID gap) // Sync // Data // Gap 3 (data gap, also called format gap)
et pour chaque fin de piste : // Gap 4b et // the rest of the track with bytes until the index signal gets active.
Je m'explique par l'exemple :
L'approche du format eDSK, est une vision par secteur de la disquette :
exemple :
Size : 512 (Real : 512) 000000: 31 00 08 F3 01 8D 7F ED 49 01 10 7F ED 49 3E 54 1.......I....I>T 000010: ED 79 0E 00 ED 49 ED 79 0C 3E 4C ED 49 ED 79 3E .y...I.y.>L.I.y> 000020: 4A 0C ED 49 ED 79 0C 3E 4B ED 49 ED 79 21 00 C0 J..I.y.>K.I.y!.. 000030: 3E 01 16 04 CD 70 01 21 00 12 3E 05 16 0A CD 70 >....p.!..>....p 000040: 01 21 DB 65 3E 0B 16 10 CD 70 01 01 00 7F 3E 54 .!.e>....p....>T 000050: ED 49 0C ED 79 CB 61 28 F7 21 00 C0 3E 11 57 CD .I..y.a(.!..>.W. 000060: 70 01 21 00 C0 11 00 02 01 00 10 ED B0 C3 DB 65 p.!............e 000070: F3 3D 32 8A 02 7A 32 A9 02 22 A7 02 01 7E FA 3E .=2..z2.."...~.> 000080: 01 ED 79 FD 21 9D 02 DD 21 8D 02 CD 40 02 FD 21 ..y.!...!...@..! 000090: 9D 02 FD 7E 00 B7 20 EF 3A AA 02 B7 20 20 3C 32 ...~.. .:... <2 0000A0: AA 02 DD 21 9A 02 CD 40 02 FD 21 9D 02 DD 21 8B ...!...@..!...!. 0000B0: 02 CD 40 02 FD 21 9D 02 FD CB 00 6E 28 EF FD 21 ..@..!.....n(..! 0000C0: 9D 02 DD 21 87 02 DD 34 03 CD 40 02 FD 21 9D 02 ...!...4..@..!.. 0000D0: DD 21 8B 02 CD 40 02 FD 21 9D 02 FD CB 00 6E 28 .!...@..!.....n( 0000E0: EF DD 21 8D 02 CD 40 02 DD 21 87 02 FD 21 9D 02 ..!...@..!...!.. 0000F0: FD 7E 03 DD BE 03 20 D1 DD 21 90 02 FD 6E 03 FD .~.... ..!...n.. 000100: 66 04 DD 75 03 DD 74 04 FD 66 06 FD 7E 05 E6 F0 f..u..t..f..~... 000110: 3C DD 77 05 C6 07 DD 74 06 DD 77 07 FD 2A A7 02 <.w....t..w..*.. 000120: CD 40 02 2A A7 02 11 00 10 19 22 A7 02 DD 21 87 .@.*......"...!. 000130: 02 3A A9 02 DD BE 03 20 85 01 7E FA AF ED 79 C9 .:..... ..~...y. 000140: DD 46 00 DD 23 C5 DD 7E 00 DD 23 CD 6A 02 C1 10 .F..#..~..#.j... 000150: F4 01 7E FB 11 10 C0 ED 78 CB 67 C8 BA 38 F8 0C ..~.....x.g..8.. 000160: ED 78 FD 77 00 FD 23 0D 18 ED F5 F5 01 7E FB ED .x.w..#......~.. 000170: 78 87 30 FB 87 30 03 F1 F1 C9 F1 0C ED 79 0D 3E x.0..0.......y.> 000180: 05 3D 00 20 FC F1 C9 03 0F 00 00 01 08 02 4A 00 .=. ..........J. 000190: 09 46 00 00 00 00 00 49 2A FF 02 07 00 00 00 00 .F.....I*....... 0001A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0001B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0001C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0001D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0001E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0001F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000: 00 00 00 00 00 00 00 00 00 00 00 00 a1 a1 a1 fe 0010: 00 00 41 02 c7 a3 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 0020: 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 00 00 00 00 0030: 00 00 00 00 00 00 00 00 a1 a1 a1 fb DATA
0000: 31 00 08 f3 01 8d 7f ed 49 01 10 7f ed 49 3e 54 0010: ed 79 0e 00 ed 49 ed 79 0c 3e 4c ed 49 ed 79 3e 0020: 4a 0c ed 49 ed 79 0c 3e 4b ed 49 ed 79 21 00 c0 0030: 3e 01 16 04 cd 70 01 21 00 12 3e 05 16 0a cd 70 0040: 01 21 db 65 3e 0b 16 10 cd 70 01 01 00 7f 3e 54 0050: ed 49 0c ed 79 cb 61 28 f7 21 00 c0 3e 11 57 cd 0060: 70 01 21 00 c0 11 00 02 01 00 10 ed b0 c3 db 65 0070: f3 3d 32 8a 02 7a 32 a9 02 22 a7 02 01 7e fa 3e 0080: 01 ed 79 fd 21 9d 02 dd 21 8d 02 cd 40 02 fd 21 0090: 9d 02 fd 7e 00 b7 20 ef 3a aa 02 b7 20 20 3c 32 00A0: aa 02 dd 21 9a 02 cd 40 02 fd 21 9d 02 dd 21 8b 00B0: 02 cd 40 02 fd 21 9d 02 fd cb 00 6e 28 ef fd 21 00C0: 9d 02 dd 21 87 02 dd 34 03 cd 40 02 fd 21 9d 02 00D0: dd 21 8b 02 cd 40 02 fd 21 9d 02 fd cb 00 6e 28 00E0: ef dd 21 8d 02 cd 40 02 dd 21 87 02 fd 21 9d 02 00F0: fd 7e 03 dd be 03 20 d1 dd 21 90 02 fd 6e 03 fd 0100: 66 04 dd 75 03 dd 74 04 fd 66 06 fd 7e 05 e6 f0 0110: 3c dd 77 05 c6 07 dd 74 06 dd 77 07 fd 2a a7 02 0120: cd 40 02 2a a7 02 11 00 10 19 22 a7 02 dd 21 87 0130: 02 3a a9 02 dd be 03 20 85 01 7e fa af ed 79 c9 0140: dd 46 00 dd 23 c5 dd 7e 00 dd 23 cd 6a 02 c1 10 0150: f4 01 7e fb 11 10 c0 ed 78 cb 67 c8 ba 38 f8 0c 0160: ed 78 fd 77 00 fd 23 0d 18 ed f5 f5 01 7e fb ed 0170: 78 87 30 fb 87 30 03 f1 f1 c9 f1 0c ed 79 0d 3e 0180: 05 3d 00 20 fc f1 c9 03 0f 00 00 01 08 02 4a 00 0190: 09 46 00 00 00 00 00 49 2a ff 02 07 00 00 00 00 01A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CRC
0000: 3a 6a GAP3
0000: 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 0010: 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 0020: 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 0030: 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 0040: 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 0050: 4e 4e
Je vous soumets ces éléments afin que les spécialistes de l'émulation et du dump CPC puissent également 'valider' ce format !
A mettre en œuvre un nouveau format, je pense que ce serait trés intéressant d'y inclure une notion de meta data et, pourquoi pas, de chunk d'identification. Ceci amènerait une dimension très intéressante, en plus de la partie technique, et du coup bien plus riche que l'ensemble des formats existants.
Par exemple, une des plus grosse galère que j'ai eus lorsque j'ai fait Dream CPC sur Dreamcast était de faciliter, sans clavier, le lancement de jeux disquettes. Du coup, permettre de renseigner la commande à lancer pour lancer le jeu serait bien pratique pour les émulateurs.
De même, le multi-disk/Multiface pourrait être facilité, soit avec un CRC + incrément, soit carrément via la possibilité d'englober plusieurs faces dans un même fichier. ... mais je vais faire hurler certain puristes, restant moi même trés partagé sur ce point.
Pourquoi pas aussi inclure d'autres infos sur le dumper, la date du dump, l'outil de dump et/ou le site permettrait de cadrer le tag-age des images.
Des métadonnées pures telles que la couverture, l’éditeur, édition, etc ... façon Tag Mp3 dans un chunk facultatif serait aussi intéressantes je pense.
Enfin, un Guid unique crée lors du dump et/ou basé sur le CRC des données brutes du disque serait aussi intéressant pour suivre les doublons sans se baser sur l'ensemble du fichier (et ainsi permettre l'édition des meta-données sans perdre l'identification des doublons).
Une autre idée mais serait de rajouter des chunk facultatifs correspondants à des patchs non destructif de l'image disque pour permettre de créer des versions améliorés tout en conservant la donnée de base.
Voilà, ce ne sont que quelques idées et je veux bien, si ça vous intéresse, travailler sur une formalisation plus technique.
_________________ There is the theory of Möbius. A twist in the fabric of space where time becomes a loop
Voila un sujet intéressant ! Voici donc l'état de mes réflexions sur le sujet :
1/ Les secteurs faibles. Après avoir beaucoup travaillé sur le sujet, j'en suis venu à la conclusion suivante : Chaque bit peut avoir quatre états : - 1 - 0 - Aléatoire - Facultatif.
Avec ces quatre états, on arrive à décrire l'ensemble des cas rencontrés. Utiliser des révolutions multiples est un compromis acceptable (surtout en matière de simplicité d'utilisation), mais le point noir est l'impossibilité de recréer un support à partir de là (et, je suis bien placé pour en parler, la difficulté à passer de plusieurs révolutions à une seule avec informations de weak bits précise).
2/ Le format lui-même L'organisation en chunk est une excellente idée. La description des secteurs parait bien, pour la facilité d'intégration. Par contre, elle est un peu haut niveau pour la gestion de toutes les protections....
En y réfléchissant bien, il existe un format qui fait tout cela. Description des weak bits à l'unité, informations MFM et data, chunks... Et c'est ce fameux format IPF !
Son autre avantage est d'être universel : Un dump Amiga, ST, spectrum, etc peut être décrit dans ce format. Il commence à être documenté, et supporté (Caprice Forever en v0.25 le supporte nativement, il y a sinon la version de caprice "IPF", et Sugarbox)
Il n'y a en théorie aucune restriction sur les protections (pas de verrue à prévoir pour faire marcher tel ou tel dump).
Le seul point noir serait qu'il est un peu trop lié à la SPS, mais en tout cas, il me parait le candidat idéal pour une telle réflexion.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1715
dlfrsilver a écrit :
Un nouveau format DSK qui serait plus complet et plus pointu ? Moi je dis pourquoi pas !
par contre quel serait le hardware capable d'écrire ensuite ce format de fichier ?
un CPC pourrait écrire le standard qui peut être vu en format secteur. Pour tout ce qui au format piste (info GAPS, secteurs entrelacés, etc.), ce n'est pas très différent d'une vue IPF ou autre format plus élaboré, il faut le matériel adéquat pour le faire et pouvoir piloter un FDC capable de traiter l'information au format track.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1715
JMD a écrit :
Hello, Pourquoi pas aussi inclure d'autres infos sur le dumper, la date du dump, l'outil de dump et/ou le site permettrait de cadrer le tag-age des images.
Des métadonnées pures telles que la couverture, l’éditeur, édition, etc ... façon Tag Mp3 dans un chunk facultatif serait aussi intéressantes je pense.
Voilà, ce ne sont que quelques idées et je veux bien, si ça vous intéresse, travailler sur une formalisation plus technique.
ok pour le mettre en forme et avoir l’exhaustivité des infos possibles sur le dump, on peut s'inspirer du format cdt, qui est très complet sur ce sujet des informations dumps, etc.
pour les infos auteurs et pour les tags supplémentaires type couverture de la disquette, etc, effectivement on fait comme le MP3, on les mets à la fin du tDSK sous forme de TAG (ex : IMG, TXT, etc.)
ok pour que tu fasses une première formalisation technique et on compilera ici pour que cela soit public et partagé !
Inscription : 12 Juin 2008, 20:29 Message(s) : 1715
Lone a écrit :
Hello, En y réfléchissant bien, il existe un format qui fait tout cela. Description des weak bits à l'unité, informations MFM et data, chunks... Et c'est ce fameux format IPF !
Son autre avantage est d'être universel : Un dump Amiga, ST, spectrum, etc peut être décrit dans ce format. Il commence à être documenté, et supporté (Caprice Forever en v0.25 le supporte nativement, il y a sinon la version de caprice "IPF", et Sugarbox)
Il n'y a en théorie aucune restriction sur les protections (pas de verrue à prévoir pour faire marcher tel ou tel dump).
Le seul point noir serait qu'il est un peu trop lié à la SPS, mais en tout cas, il me parait le candidat idéal pour une telle réflexion.
si c'est pour copier le format IPF, effectivement, ce nouveau format tDSK ne serait pas une bonne idée... J'avais compris que les disks au format IPF ne seraient peut-être jamais distribués à un grand nombre...ce qui n'est pas le cas des formats RAWs...
Pour moi, il ne s'agit pas forcément là d'un format de préservation comme l'IPF mais plutôt d'une amélioration de l'eDSK dans un but d'émulation plus performante !
si c'est pour copier le format IPF, effectivement, ce nouveau format tDSK ne serait pas une bonne idée... J'avais compris que les disks au format IPF ne seraient peut-être jamais distribués à un grand nombre...ce qui n'est pas le cas des formats RAWs...
Pour moi, il ne s'agit pas forcément là d'un format de préservation comme l'IPF mais plutôt d'une amélioration de l'eDSK dans un but d'émulation plus performante !
En fait, en y réfléchissant bien, ce que l'on veut, c'est : - Un format qui permette de décrire données et plus. - Un format qui permette d'inclure les protections plus bas niveau que le niveau MFM (soit, les fuzzy bits) - Un format extensible.
IPF répond à tous ces critères, de manière assez élégante : On utilise le format MFM quand nécessaire (sync byte ou autre), on peut y caler des gaps "générique" simplement, etc.
Concernant la destination, qui peut le plus peut le moins. On peut bien l'utiliser pour ce que ça nous chante...
Du coup, sur les spec, il (semble) faire l'affaire. Son avantage, est qu'il sera plus facilement adoptable qu'un nouveau format attaché à aucun matériel (et à une petite poignée d'émulateur, et non les plus utilisés).
Ça ressemble plus ou moins à ce dont on avait déjà parlé il y a des mois. La doc de spec provisoire est toujours en page cachée sur le Quasar Net. Le format proposé n'était pas spécialement lié aux disquettes en particulier mais pouvait décrire n'importe quel support, en commençant par les D7 et les K7 (avec la possibilité de mettre toutes les D7/K7 d'un soft dans le même conteneur).
Mais comme plus personne ne bougeait là-dessus, moi je suis passé à autre chose.
Dans tous les cas, le format DSK est une calamité, ça serait une bonne chose de l'éradiquer.
Le format IPF semble sympa, et je ne désespère pas d'arriver à en ajouter le support dans ACE (pour le moment je suis dans une impasse).
@Offset : n'hésite pas à poser des questions sur l'IPF, il est possible qu'on ait des réponses ( je décode correctement le format en natif ).
Pour le format d'il y a quelques mois, j'ai toujours l'implementation dans sugarbox ( non activée ), même si, avec un peu plus de recul, je trouve dommage notre gestion des bits aléatoires ( les identifier comme tel paraît mieux que l'enregistrement de multiples révolutions)
@Offset : n'hésite pas à poser des questions sur l'IPF, il est possible qu'on ait des réponses ( je décode correctement le format en natif ).
Le problème c'est que je n'en suis même pas encore à jouer avec l'IPF. Je suis pour le moment bloqué sur le portage de leur lib 5.1 même si je n'ai jamais été aussi loin. Grâce au dernier SDK MorphOS et à gcc 5.3 j'arrive à la compiler (elle utilise du C++11 à la noix) et à tout linker dans une lib (en baserel avec init de libnix et tout et tout)... mais c'est là que ça s'arrête. Ça explose au premier « new » fait par leur lib.
Je hais le C++.
Lone a écrit :
Pour le format d'il y a quelques mois, j'ai toujours l'implementation dans sugarbox ( non activée ), même si, avec un peu plus de recul, je trouve dommage notre gestion des bits aléatoires ( les identifier comme tel paraît mieux que l'enregistrement de multiples révolutions)
Le format n'ayant jamais été rendu public, on peut le faire évoluer sans soucis et changer le contenu des chunks MBIT et OBIT. Je n'aime pas l'idée des multiples révolutions non plus.
Mon conseil : oublie le portage de la lib. Entre les histoires de licences pas claires et les difficultés que tu rencontres, il te sera plus facile de ré implémenter le décodage... La doc du dr coolzic est un excellent début pour cela.
Inscription : 21 Août 2008, 16:03 Message(s) : 342
Que de temps perdu depuis le temps (années) que l'on parle de la nécessité à créer un vrai format. Et maintenant, on va prendre un format qui existe déjà et 'copier' les bases... (pour pas dire tout) Ou comment ré-inventer la roue mais, avec un license 'plus libre'. C'est hachement moyen je trouve pour pas dire autre chose.
Et l'utilité dans tout ça ? vue que : - On aura pas de H/W spécifique pour ré-créer une disquette à partir de ce nouveau format. - Lone peu déjà crée des ipfs, je site, de qualité et réel, par rapport au Dsk.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1715
@Giants: comme je l'ai évoqué plus haut, il n'y a pas plus de hardware pour écrire en natif du ipf sur un amstrad CPC. Donc créer une évolution du eDSK, qui déjà lui même ne peut pas plus être écrit en natif sur amstrad CPC pour certaines protections (GAPS, etc.)... ça ne change rien au possibilité du H/W.
Je vais prendre un raccourci, mais si on a un hardware FDC qui sait écrire une piste, on pourra surement recréer un disk fonctionnel. L'IPF sera toujours supérieur car il est au niveau du master, mais il faudra alors un équipement pro pour écrire le disk !
La préservation, c'est faire un dump exact... c'est pour cela qu'à mon sens, conserver le dump raw est indispensable car les formats évolues (même l'IPF) et il faut des fois repartir du raw pour régénérer des formats d'émulation (ex quand on est passé du DSK au eDSK) ! Le reproduire sur une disquette 3 pouces, un jour, il n'y aura plus de disquette 3 pouces...même 3p 1/2... c'est très bien si c'est possible mais cela a une limite temporelle, en tout cas pour le plus grand nombre...
Par contre, côté émulation, on s'assure qu'on pourra toujours profiter de ces merveilles !
D'où l’intérêt de faire évoluer le format eDSK de la vue secteur à la vue piste (tEDSK).
Si je ne me trompe pas, les IPF peuvent être réécrits via le kryoflux. De toute façon, il faudrait convertir notre nouveau format en scp ou raw pour une réécriture ( ou IPF, à condition que l'écriture de l'Ipf ne repasse pas par le raw !)
De même, nous nous y trompons pas : l'Ipf s'arrête au mieux au niveau mfm ( à voir avec les IPF définitifs, mais tant qu'on n'en aura pas sous la main....). Donc le nouveau format aurait le même niveau d'information.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 2 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
!!!
