Lone a écrit :
Je me suis mal exprimé: le ctraw correspond au dsk de cpcpower, et pas au dsk de Denis ( qui me provoque aussi un plantage).
J'ai très exactement le même symptôme que megachur ( et au visu hexadécimal du dsk comme aux traces de lecture, J'ai la même analyse : piste trop longue)
J'ai très exactement le même symptôme que megachur ( et au visu hexadécimal du dsk comme aux traces de lecture, J'ai la même analyse : piste trop longue)
y a deux problèmes donc :
1) le eDSK sur cpc-p0wer a été généré y a un bail de ça, en 2014. c'est moi qui l'ai refactoré avec une version assez ancienne de samdisk.
2) le CTraw provient de mon nouveau dump au propre, d'une disquette que j'ai acheté et reçu le 30 avril, que j'ai dumpé sans souci, et que Samdisk v4.0 m'a converti en eDSK, tout en m'indiquant que les pistes speedlock n'avaient pas de checksum, ce qui vrai.
3) l'IPF fonctionne parfaitement bien, je n'ai de souci qu'avec l'ému de Mégachur, et Caprice Forever.
4) Concernant l'analyse de Megachur au sujet du loader, voici une petite explication de ma part :
Citer :
next
Piste 1 secteur #c1 :
hl = #c000 = address to store data loaded
de = #1800 = length of data to read
next
Piste 2 secteur #c1
#d800
#1800
--> le screen d'intro apparait en &c000 !!!
Piste 1 secteur #c1 :
hl = #c000 = address to store data loaded
de = #1800 = length of data to read
next
Piste 2 secteur #c1
#d800
#1800
--> le screen d'intro apparait en &c000 !!!
Ok, le screen fait 2x$1800 soit 2 pistes. l'écran fait 12ko en gros, il est compressé (écran CPC = 17ko)
Citer :
next
Piste 3 secteur #c1
#f000
#1000
on en lit moins cette fois !!!
même piste
Piste 3 secteur #c1
#1400
#0800
on en lit encore moins cette fois !!!
Piste 3 secteur #c1
#f000
#1000
on en lit moins cette fois !!!
même piste
Piste 3 secteur #c1
#1400
#0800
on en lit encore moins cette fois !!!
explication ici : en fait, il faut comprendre que les pistes speedlock ou hexagon, c'est comme utiliser dans le principe la méthode de lecture et de stockage d'une cassette, mais adaptée aux disquette.
Les données peuvent commencer et finir à l'intérieur d'une même piste ! Ceci à la base, est fait pour empêcher l'utilisation des données en sectoriel, et forcer le cracker à changer ou altérer le loader speedlock.
La piste 3 est coupée donc en 2 : un bout de données d'une taille de $1000 et l'autre de $0800. ça nous fait $1800 dans tout les cas. Maintenant, avec un chouille de décalage, forcément, ça peut déconner.
Citer :
Piste 4 secteur #c1
#1C00
#1800
ouf, on reprend la cadence !
Piste 5 secteur #c1
#3400
#1800
Piste 6 secteur #c1
#4c00
#1800
Piste 7 secteur #c1
#6400
#1800
Piste 8 secteur #c1
#7c00
#1600
un peu moins...mais c'est fini pour la face A !
#1C00
#1800
ouf, on reprend la cadence !
Piste 5 secteur #c1
#3400
#1800
Piste 6 secteur #c1
#4c00
#1800
Piste 7 secteur #c1
#6400
#1800
Piste 8 secteur #c1
#7c00
#1600
un peu moins...mais c'est fini pour la face A !
ça veut simplement dire que le programme principal s'étend sur les pistes 4 à 8, soit :
4x1800 + 1x1600 = $7600 soit 30208 octets.
Les données sont compressées en tout cas. Ou le programme est compressé plus fort en version K7.
Donc quel est le souci ? Pourquoi piste trop longue ? chaque piste contient 6224 octets de "données utiles", pourquoi les émulateurs vont au fossé ?
Si je peux me permettre, Samdisk ne peut pas déterminer pour chaque piste speedlock ou hexagon la longueur exacte des données par piste.
Ici, c'est $1800 soit 6144 octets de données utiles, sur un autre jeu, ce sera un peu plus. Samdisk n'a pas d'IA et puis choisir en ligne de commande la variante, mais sur quel base ?
Le problème aussi, c'est que les protections speedlock et hexagon tout en étant crées par deux boites différentes, sont pareilles physiquement. C'est exactement le même mécanisme. Sauf que la protection hexagon existe en 2 variantes, et que même pour les speedlocks, on a aussi des pistes de 6K generiques.
Enfin en bref, techniquement, je vois pas pourquoi ça merde.
