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) !



:biere: Merci d'avance :kiss: !

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 :mdr: :kissed: : ce que j'appelle l'émulation à minima mais pas de l'émulation précise :oops: !

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 :mdr: :kissed: : ce que j'appelle l'émulation à minima mais pas de l'émulation précise :oops: !


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/