Et sinon, est-ce que quelqu'un aurait l'original et un cpc pour faire un test ?
Code :
voici la commande de lecture d'une piste à faire avec "Dlfrsilver Dump Tool Test Suite v180507" : [url]https://cpcrulez.fr/applications_disc-dlfrsilver_dump_tool_test_suite.htm[/url]
lancer cet utilitaire :
run"fdctest
insérer la disquette du jeu original dans le lecteur A 3p interne
command SEEK en piste 01: taper : 0f + enter puis 00 01 + enter
Inscription : 12 Juin 2008, 20:29 Message(s) : 1715
C'est plus pour de la connaissance...
Sur ce loader type HEXAGON et cette disquette, on a des pistes avec un seul secteur de taille 8 incomplet (donc de taille 6 en réel). A chaque piste, le loader lit ce seul secteur donc 8192 octets et teste 6144 (=#1800 en hexa) avec un checksum pour vérifier si c'est ok.
Quand on a un eDSK, on mets donc juste le contenu du secteur que le loader attend, donc une taille de data de 6144 octets...ou plus si on sait pas !
Par exemple, si je lis la totalité du secteur sur WinAPE ou un autre émulateur qui n'émule pas la disquette d'origine, après 6144 octets, j'obtiens des 00 ce qui n'est pas une image de la piste bien sûr car il n'y a même pas l'id du secteur !
Hors, normalement, on devrait avoir soit une zone gap (#4e) seule et ensuite la synchro + ID du secteur... soit le CRC des données du secteur taille 6 + une zone gap (#4e) + ensuite la synchro + ID du secteur... soit une zone gap (#4e) + la synchro + ID de la piste et ensuite la synchro + ID du secteur... soit ?
--> donc je suis curieux de savoir ce qu'on a exactement afin de l'émuler le plus fidèlement ! bien sûr avec un CTRaw ou un ipf, car pour l'eDSK, ces données gap + début piste + début secteur ne sont pas présentes réellement dans le fichier dsk...
De plus, si le loader calculait un checksum sur plus de 6144 octets, il prendrait aussi les octets après les données en compte ce qui ferrait qu'on aurait besoin de ces données en + dans l'eDSK (même si ce serait faut dans ce cas car ce n'est qu'un format 'secteur' et pas piste comme le CTRaw ou l'Ipf) ... Souvent en plus, la piste s'arrête au moment de l'INDEX sur un données MFM qui n'est pas complète et donc cela décale les données MFM du début de la piste dans ce cas de lecture de secteur incomplet...
Cela semble le cas d'autre loader, pas forcément HEXAGON, par exemple le loader de MOT de mémoire qui prend en compte dans son checksum toutes ces données (data secteur + données début de piste / secteur ID) !! Sauf que souvent, on mets ce qu'on peut dans l'eDSK, mais cela ne correspond pas vraiment à une vue 'secteur' mais plutôt ce que je dois donner au loader pour qu'il soit content : ce que j'appelle l'émulation à minima mais pas de l'émulation précise !
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Megachur a écrit :
C'est plus pour de la connaissance...
Sur ce loader type HEXAGON et cette disquette, on a des pistes avec un seul secteur de taille 8 incomplet (donc de taille 6 en réel). A chaque piste, le loader lit ce seul secteur donc 8192 octets et teste 6144 (=#1800 en hexa) avec un checksum pour vérifier si c'est ok.
Oui c'est tout à fait normal Jusque là, rien d'inédit.
Citer :
Quand on a un eDSK, on mets donc juste le contenu du secteur que le loader attend, donc une taille de data de 6144 octets...ou plus si on sait pas !
La par contre, il y a à dire :
1) le maximum pour un jeu CPC c'est 6400 octets par piste. 6144 octets, c'est raboté trop court, c'est ce qu'on avait dans les vieux dumps.
2) le plus important : le format eDSK ne stocke pas les pistes hexagon comme sur les disquettes originales. Sur une disquette originale, les pistes hexagon sont écrites en write track, avec un secteur incomplet de 512 octet en début de piste, plus juste après une énorme zone gap. Dans un fichier eDSK, les données sont stockées sous forme d'énorme secteur de 6K. C'est fonctionnel, mais on perd le format d'origine.
Citer :
Par exemple, si je lis la totalité du secteur sur WinAPE ou un autre émulateur qui n'émule pas la disquette d'origine, après 6144 octets, j'obtiens des 00 ce qui n'est pas une image de la piste bien sûr car il n'y a même pas l'id du secteur !
C'est anormal. Les jeux CPC surtout en hexagon vont au delà des 6144 octets. La protection hexagon existe en 2 versions : l'hexagon $1800 et l'hexagon $18A0.
Citer :
Hors, normalement, on devrait avoir soit une zone gap (#4e) seule et ensuite la synchro + ID du secteur... soit le CRC des données du secteur taille 6 + une zone gap (#4e) + ensuite la synchro + ID du secteur... soit une zone gap (#4e) + la synchro + ID de la piste et ensuite la synchro + ID du secteur... soit ?
Tiens voici à titre de comparaison la tête d'une piste hexagon de Strider II telle qu'encodée par l'analyseur CTA que j'utilise :
--> donc je suis curieux de savoir ce qu'on a exactement afin de l'émuler le plus fidèlement ! bien sûr avec un CTRaw ou un ipf, car pour l'eDSK, ces données gap + début piste + début secteur ne sont pas présentes réellement dans le fichier dsk...
Ma réponse juste au dessus. pour un eDSK tu dois t'assurer de lire 6400 octets pour être sur de rien rater.
Citer :
De plus, si le loader calculait un checksum sur plus de 6144 octets, il prendrait aussi les octets après les données en compte ce qui ferrait qu'on aurait besoin de ces données en + dans l'eDSK (même si ce serait faut dans ce cas car ce n'est qu'un format 'secteur' et pas piste comme le CTRaw ou l'Ipf) ... Souvent en plus, la piste s'arrête au moment de l'INDEX sur un données MFM qui n'est pas complète et donc cela décale les données MFM du début de la piste dans ce cas de lecture de secteur incomplet...
Le checksum des pistes hexagon est interne, et non externe......
Citer :
Cela semble le cas d'autre loader, pas forcément HEXAGON, par exemple le loader de MOT de mémoire qui prend en compte dans son checksum toutes ces données (data secteur + données début de piste / secteur ID) !! Sauf que souvent, on mets ce qu'on peut dans l'eDSK, mais cela ne correspond pas vraiment à une vue 'secteur' mais plutôt ce que je dois donner au loader pour qu'il soit content : ce que j'appelle l'émulation à minima mais pas de l'émulation précise !
C'est exactement ça. On donne au loader ce qu'il faut pour qu'il soit content, mais ça correspond pas à l'original.
_________________ SPS Community Expert (SPS CE) / SPS France
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 1 invité
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
Merci d'avance 
!
si on sait pas !
: ce que j'appelle l'émulation à minima mais pas de l'émulation précise 
!
Jusque là, rien d'inédit.