CPC Rulez https://cpcrulez.fr/forum/ |
|
Recherche CTRaw de Dynasty Wars pour un test https://cpcrulez.fr/forum/viewtopic.php?f=8&t=6353 |
Page 1 sur 1 |
Auteur : | Megachur [ 22 Mai 2020, 16:07 ] |
Sujet du message : | Recherche CTRaw de Dynasty Wars pour un test |
Hello tout le monde, pour faire un test sur une piste de la disquette originale : Est-ce que quelqu'un aurait le dump original du jeu Dynasty Wars (ou d'une compilation) type CTRaw ? https://cpcrulez.fr/GamesTest/dynasty_wars.htm 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 commande lecture secteur incomplet : 46 00 01 00 01 06 01 2a ff taper 8192 + enter puis 'd' pour display et après plusieurs return, me dire ce qu'il y a en #3af0 et l'écran suivant (ou des photos ;-) de l'écran) ! Merci d'avance ! |
Auteur : | dlfrsilver [ 22 Mai 2020, 16:35 ] |
Sujet du message : | Re: Recherche CTRaw de Dynasty Wars pour un test |
Quel est le souci Megachur ? |
Auteur : | Megachur [ 24 Mai 2020, 10:20 ] |
Sujet du message : | Re: Recherche CTRaw de Dynasty Wars pour un test |
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 ! |
Auteur : | dlfrsilver [ 24 Mai 2020, 14:44 ] |
Sujet du message : | Re: Recherche CTRaw de Dynasty Wars pour un test |
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 : 00: 001611[0],.6K xor8 1800 block 00_00: 001611[0], 3, .Mark, byte: 4489 00_01: 001659[0]. 1..ID.byte: fe 00_02: 001675[0], 1, .Track, byte: 01 00_03: 001691[0], 1, .Side, byte: 00 00_04: 001707[0], 1, .Sector, byte f0: 01 00_05: 001723[0], 1, .Length, byte: 06 00_06: 001739[0], 1, .EDC. Crcl 6. short: fc5f 00_07: 001771[0], 34, .Gap, byte:... 00_08: 002315[0], 3, .Mark, byte: 4489 00_09: 002363[0], 1,.ID,byte: f8 00_10: 002379[0], 6144, .Data, byte f1:... 00_11: 000163[1], 1..EDC,Xor8,byte: 99 00_Gap: 000179[1 ], 1432, ~179 bytes 00_X Citer : --> 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. |
Page 1 sur 1 | Le fuseau horaire est UTC+1 heure |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |