La nouvelle version comprend plus d'informations. Elle permet donc de soupçonner l'absence d'IAM (Index Addres Mark) : La version semble tourner autours du trou d'index, et retombe directement sur l'IDAM du secteur unique de la piste).
A priori, ça ne sert qu'à avoir plus de précision sur le dump... Mais sur un format DSK qui est déjà très incomplet, ajouter des infos supplémentaires qui ne servent à rien est effectivement assez wtf.
Comme souvent dans le domaine des GAPs et format DSK, ça dépend des cas, et ça dépend des philosophies : Plus d'info, c'est toujours bon, mais trop d'infos, c'est parfois contre productif sur la compatibilité. (Par contre, c'est un sujet à polémique sans fin )
- Operation Thunderbolt_A et B : Pas mal de soucis divers sur ce dump... Notamment dû a l'incorporation de la dernière révolution (pour Dogfight). J'ai donc corrigé quelques soucis sur piste a secteur unique, notamment sur les longueurs.
Sur les longueurs, c'est à dire ? Operation Thunderbolt est bon, j'ai eu aucun souci à faire un IPF du jeu.
En fait mon soucis était lié à la dernière révolution (incomplète dans le sens ou je considère une révolution d'un IAM à un autre (ou du premier IDAM au premier IDAM de la revolution suivante, si aucun IAM n'est présent).
Cela, plus le fait que plein de secteur ont des CRC incorrectes (tous a partir de la piste 1 du premier disk, plus le secteur c8 de la piste 0), ça m'a obligé à fiabiliser quelques algos.
Au sujet des IPFs : Félicitation pour ta promotion, mais j'avoue ne pas saisir la différence par rapport à avant : Ne donnais tu pas déjà les IPFs au contributeurs concernés ? Par ailleurs, si tu as des versions "finales" du format, présente-t-il des différences avec les dumps que l'on a pu voir jusqu'à présent ? (et si oui, peux tu nous les prêter à des fins de mise au point éventuelles ?)
EDIT : pour Maths College Vol.1, (j'ai oublié de répondre !) Il manque, sur le ctraw, la piste &27, tout simplement...
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Citer :
En fait mon soucis était lié à la dernière révolution (incomplète dans le sens ou je considère une révolution d'un IAM à un autre (ou du premier IDAM au premier IDAM de la revolution suivante, si aucun IAM n'est présent).
D'accord, donc c'est lié à ta gestion personnelle du format
Citer :
Cela, plus le fait que plein de secteur ont des CRC incorrectes (tous a partir de la piste 1 du premier disk, plus le secteur c8 de la piste 0), ça m'a obligé à fiabiliser quelques algos.
Alors ça je vais le répéter : Quasiment TOUT les jeux plombés par speedlock n'ont pas de CRC ! Ces derniers ne peuvent donc pas être calculés, puisqu'il y en a pas
C'est le cas d'Opération Thunderbolt, mais pas seulement, quasiment tout les jeux d'ocean avec piste de taille 6, c'est comme ça. C'est du MFM 6k no EDC (no error data checksum, soit pas de checksum pour les données).
Citer :
Au sujet des IPFs : Félicitation pour ta promotion, mais j'avoue ne pas saisir la différence par rapport à avant : Ne donnais tu pas déjà les IPFs au contributeurs concernés ?
Les IPFs que je crée sont temporaires, ils doivent être validés par le créateur du système, puis il les numérotera, et les incorporera dans la base.
Mais dernièrement, on m'a donné l'accès à l'intégralité du catalogue des IPFS pour Amiga, ST, CPC, Spectrum.
Je peux fournir n'importe quel jeu en IPF officiel numéroté présent dans notre base, à celui qui me fournira le dump du jeu demandé au format KF raw.
Citer :
Par ailleurs, si tu as des versions "finales" du format, présente-t-il des différences avec les dumps que l'on a pu voir jusqu'à présent ? (et si oui, peux tu nous les prêter à des fins de mise au point éventuelles ?)
Tu auras accès à un certain nombre d'entre eux quand je les aurais fourni à Loic (ceux qu'il a dumpé), et qu'il les aura fourni à Hermol et Kukulcan. Je n'ai pas le droit de fournir des IPFs officiels comme ça, je dois pouvoir justifier d'un point de vue légal que j'ai fourni le dump en contrepartie d'un dump complet dudit logiciel demandé.
Citer :
EDIT : pour Maths College Vol.1, (j'ai oublié de répondre !) Il manque, sur le ctraw, la piste &27, tout simplement...
j'ai testé le soft, il fonctionne parfaitement, quel est le souci rencontré ? tu as un plantage ou un truc du genre ?
_________________ SPS Community Expert (SPS CE) / SPS France
EDIT : pour Maths College Vol.1, (j'ai oublié de répondre !) Il manque, sur le ctraw, la piste &27, tout simplement...
j'ai testé le soft, il fonctionne parfaitement, quel est le souci rencontré ? tu as un plantage ou un truc du genre ?
J'ai un read fail : Un vieux read sector du type 00 27 00 C1 02 C1 2A FF (sur la piste &27 bien sur) Vu qu'il n'y a pas de piste &27 dans le CTRaw que tu nous as mis à dispo, ça ne fonctionne pas.
Comme d'hab, si tu pouvais nous zipper le kryoflux, on y verrait plus clair.
Note que le dsk fonctionne très bien (on constate d'ailleurs la présence de plusieurs révolution sur celle piste &27). C'est juste que le CTRaw ne contient juste pas cette fameuse piste (on a déjà eu le problème par le passé)
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Lone a écrit :
dlfrsilver a écrit :
Citer :
EDIT : pour Maths College Vol.1, (j'ai oublié de répondre !) Il manque, sur le ctraw, la piste &27, tout simplement...
j'ai testé le soft, il fonctionne parfaitement, quel est le souci rencontré ? tu as un plantage ou un truc du genre ?
J'ai un read fail : Un vieux read sector du type 00 27 00 C1 02 C1 2A FF (sur la piste &27 bien sur) Vu qu'il n'y a pas de piste &27 dans le CTRaw que tu nous as mis à dispo, ça ne fonctionne pas.
Comme d'hab, si tu pouvais nous zipper le kryoflux, on y verrait plus clair.
Note que le dsk fonctionne très bien (on constate d'ailleurs la présence de plusieurs révolution sur celle piste &27). C'est juste que le CTRaw ne contient juste pas cette fameuse piste (on a déjà eu le problème par le passé)
Tu as clairement un souci avec ton émulateur
Tape "I" pour ignore quand tu as le read fail, et tu verras que la piste 39 passe comme une lettre à la poste
J'ai regénéré un fichier CTraw, et le log indique bien que la piste 39 est incorporée dedans.
Donc à toi de reprendre la main sur ce problème C'est un problème lié à sugarbox
_________________ SPS Community Expert (SPS CE) / SPS France
EDIT : pour Maths College Vol.1, (j'ai oublié de répondre !) Il manque, sur le ctraw, la piste &27, tout simplement...
j'ai testé le soft, il fonctionne parfaitement, quel est le souci rencontré ? tu as un plantage ou un truc du genre ? Tu as clairement un souci avec ton émulateur
Tape "I" pour ignore quand tu as le read fail, et tu verras que la piste 39 passe comme une lettre à la poste
J'ai regénéré un fichier CTraw, et le log indique bien que la piste 39 est incorporée dedans.
Donc à toi de reprendre la main sur ce problème C'est un problème lié à sugarbox
En regardant en détail le contenu de cette fameuse piste 39, on retrouve ce que j'ai eu à un moment : Pas de données formatée. Aucune info de type IDAM, IAM ou autre n'est présente, et on a à tout instant des aberrations MFM. Bref, c'est une piste non formatée.
D'ailleurs, Caprice IPF ne l'aime pas, ce dump (il va même moins loin que sugarbox...)
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Lone a écrit :
dlfrsilver a écrit :
Lone a écrit :
EDIT : pour Maths College Vol.1, (j'ai oublié de répondre !) Il manque, sur le ctraw, la piste &27, tout simplement...
j'ai testé le soft, il fonctionne parfaitement, quel est le souci rencontré ? tu as un plantage ou un truc du genre ? Tu as clairement un souci avec ton émulateur
Tape "I" pour ignore quand tu as le read fail, et tu verras que la piste 39 passe comme une lettre à la poste
J'ai regénéré un fichier CTraw, et le log indique bien que la piste 39 est incorporée dedans.
Donc à toi de reprendre la main sur ce problème C'est un problème lié à sugarbox
En regardant en détail le contenu de cette fameuse piste 39, on retrouve ce que j'ai eu à un moment : Pas de données formatée. Aucune info de type IDAM, IAM ou autre n'est présente, et on a à tout instant des aberrations MFM. Bref, c'est une piste non formatée.
D'ailleurs, Caprice IPF ne l'aime pas, ce dump (il va même moins loin que sugarbox...)
ce logiciel utilise la protection KBI-10 weak sector. Si la piste n'était pas présente, il est clair que même en tapant "I", le jeu s'arrêterait de fonctionner, hors ce n'est pas le cas, le chargement se poursuit, et ça marche.
_________________ SPS Community Expert (SPS CE) / SPS France
ce logiciel utilise la protection KBI-10 weak sector. Si la piste n'était pas présente, il est clair que même en tapant "I", le jeu s'arrêterait de fonctionner, hors ce n'est pas le cas, le chargement se poursuit, et ça marche.
Denis, ton argument ne tient pas la route...
Le dsk que tu as généré est correct, et contient cette piste 39 (pas d'erreur de lecture) Le CTRaw, lui, ne la contient pas.
On peut argumenter que le ctraw fonctionne "quand même" (dans quelles limites ?) mais il ne correspond pas totalement au dsk (et donc aux kryoflux et IPF, je pense).
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Lone a écrit :
dlfrsilver a écrit :
ce logiciel utilise la protection KBI-10 weak sector. Si la piste n'était pas présente, il est clair que même en tapant "I", le jeu s'arrêterait de fonctionner, hors ce n'est pas le cas, le chargement se poursuit, et ça marche.
Denis, ton argument ne tient pas la route...
Le dsk que tu as généré est correct, et contient cette piste 39 (pas d'erreur de lecture) Le CTRaw, lui, ne la contient pas.
On peut argumenter que le ctraw fonctionne "quand même" (dans quelles limites ?) mais il ne correspond pas totalement au dsk (et donc aux kryoflux et IPF, je pense).
Je ne peux pas faire d'IPF de logiciels utilisant la KBI-10 weak sector CA. Maths college en fait partie.
Maintenant, j'ai envie de dire, bon, le CTraw a un souci ? Pas grave, le DSK fonctionne très bien
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
dlfrsilver a écrit :
Attends une seconde, c'est quoi pour toi la taille maximale d'une piste protégée sur un jeu CPC ?
J'ai traité une compil Ocean appelée Les Super stars de l'Arcade datée de 1992, les pistes font 6656 octets de long ! donc clairement si tu lockes ton émulateur en lui indique qu'une piste ne peut pas dépasser 6144 octets, tu l'as dans l'os !
Je crois que tu nous prends vraiment pour des amateurs... c'est quoi ce sous-entendu ???
--> Avec Lone, on essaye juste d'émuler le FDC de notre cher amstrad... le but étant juste de lui fournir un MFM correct à partir du fichier au format eDSK fourni !
--> et il est où ce fameux dump dont tu parles... je serai curieux de l'analyser et de essayer !?
pour rappel, un FDC ne fournira jamais des infos de début de piste à un Z80 (même curieux ) !!!
--> donc, quand je vois cela dans un dsk (qui ne sait pas gérer cette info de tout façon car il a une vue secteur), je me dis forcément qu'il y a peut-être un soucis de conversion au format EDSK par SAMDisk 150708 !!! la preuve que j'ai mise sur CrackDown aurait dû t'alerter !!! -> on se retrouve avec deux dumps convertis en format eDSK strictement identique sauf pour le deuxième où il y a ces informations en plus dans le secteur des dernières pistes !!! --> Donc j'affirme que Samdisk n'a pas fait le bon boulot de conversion en format eDSK ! ---> J'ai aucun doute que le format avant conversion en dsk était bien bon car lui a surement toutes les informations (pistes, secteurs, data, etc.) !!! ----> Est-ce que l'auteur de Samdisk pourrait donc revoir ce point où est-ce une mauvaise option lors de la conversion en dsk ??? Est-ce que tu as moyen de lui signaler cela ???
Citer :
Pour rappel, les pistes Speedlock et Hexagon fonctionnent sur le même principe, à savoir une bout de secteur de 512 octets déclarés, et une gigantesque zone GAP de 6ko. Samdisk intègre ces pistes sous forme de gros secteur.
--> c'est justement une zone GAP (ou plutôt GAPS dans notre jargon eDSK) !!! c'est juste qu'on demande au FDC de lire plus que la longueur du secteur... donc il lit tout jusqu'au début de piste dans ce cas !
Dans notre cas juste plein de zéros pour ces dsks !!! ...jusqu'à justement rencontré les zones gap (fin de secteur, fin de piste, début de piste...)
je me répète : pour rappel, un FDC ne fournira jamais des infos de début de piste à un Z80 (même curieux ) !!!
dlfrsilver a écrit :
J'ai bien mis les bons dans l'archive. C'est quoi ton problème en fait ? Ton émulateur plante sur ces jeux ?
Ces DSKs ont été généré à partir des IPFs, ils sont donc conformes, et à la bonne taille.
Donc je te pose la question Yoann, quel est le véritable problème que tu rencontres ?
Mon problème est qu'après analyse, le loader s'attend à avoir que des zéros et rencontre des 4e puis les infos de début de piste puisque déclaré dans la zone data du GROS secteur ! Si je les enlève dans le fichier .DSK, le loader est content...car il ne reçoit bien que des zéros en data !
--> DONC SI LE LOADER attendait ces infos supplémentaires, le code z80 du loader serait prévu pour les gérer et passer à la suite !!!! --> SI je mets le DSK sans ses infos, le loader passe sans problème --> donc ce n'est pas un soucis d'émulation du FDC ou autre !!!
donc je dis et j'affirme que ces infos n'ont rien à faire dans le dsk !!! de plus le format eDSK ne doit pas connaitre ces infos car c'est un format SECTEUR !!!
je vais pas refaire le débat, cf le thread sur le format tDSK qui se proposait d'avoir une vue PISTE pour éviter ce type de problème !!!
et au final, je ne remets pas en question que le dump est bien bon !!! Je pense que tu as tous les bons outils pour t'assurer de ça !
PAR CONTRE, mon but est de montrer que le passage en format eDSK du bon dump n'est pas bon, il ne respecte pas les spécificités de ce format qui est un format SECTEUR !!! Donc pas d'info piste dedans, car si on émule bien le format DSK, ce n'est pas conforme !!!
Ou sinon, on passe des heures entières à corriger ces problèmes pour en faire une vue bonne de la piste pour l'émulation ... cf le dsk d'une protection KBI avec secteurs entrelacés , le format eDSK ne sachant pas géré cette vue PISTE, il redonde pleins d'infos pour faire marcher cela en vue secteurs, horrible !!!!
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
Bon, au final, bcp de fichier DSK de cette fournée ont le problème d'info inutiles rajoutées à la fin des pistes...
Illustration avec le fichier dsk de SRAM2 au format eDSK :
En piste 4, on déclare un premier secteur &29 avec une longueur de &011a !!!
hors, il devrait avoir une longueur de &0100, typique des protections de ce type d'ERE.
suppression des 26 octets supplémentaires ! qui sont : DD4E4E4E4E4E4E4E4E4E4E4E4E4E000000000000000000000000
idem secteur suivant &29
on réaligne les données (zéro en fin de données data de la piste) pour que le Trackinfo suivant soit aligné en xx00 on corrige la longueur de la piste 1415 -> 1315 par rapport à cela !
et on obtient un fichier dsk 100% opérationnel sans info en trop et qui marche sur tous les émulateurs qui respectent la norme "eDSK" (Ex: Sugarbox) !!!
je mets les deux fichiers .dsk avant et après modif pour bien illustrer ce pb !
Idem pour Rambo III (UK) (1988) (UK retail version) [Original].dsk par exemple !!!
toutes les pistes qui ont un gros secteur, on des infos non 'data'.... cf par exemple la dernière piste avec la partie en gras qui correspond au début du même secteur :
Donc je soupçonne fortement à un pb avec la dernière version de SAMDisk qui ne sait pas gérer ces secteurs car il ne connait pas leur longueur !!! -> est-ce que vous avez possibilité de contacter l'auteur "Simon" et lui signaler ce problème ???
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Si tu vois que la longueur c'est 6400 octets, ou plus genre 6656 octets, c'est ce qui est présent sur les disquettes originales en taille.
Le FDC de l'Amstrad sait lire des pistes aussi longues que celles présentes sur un Atari ST, sur 41 pistes au lieu de 81. Samdisk ne fait que prendre l'existant en terme de données.
La limite de taille des pistes speedlock n'est pas 1800 (6144 octets de long), mais 6700 octets, j'ai jamais vu plus.
Ensuite, je vais t'expliquer pourquoi samdisk prend autant de données à la fois :
Samdisk cherche systématiquement le CRC des pistes qu'il lit. Hors le problème dans le cas que tu nous remontes, c'est qu'il n'y en a pas ! Il va donc lire l'intégralement des données de la pistes, y compris les informations du bout de la piste qui ne sont pas utilisées.
Ensuite, les DSKs que tu dénonces fonctionnent sur tout les émulateurs (sugarbox 0.26, Caprice Forever 0.26, CPCE, Caprice /support IPF, et j'en passe).
C'est donc un problème dans ton émulation, il faut que tu reprennes le problème en main. Même mon CPC 6128 lit les eDSKs de chips challenge et crackdown après réécriture, donc ton émulateur devrait arriver au même résultat.
Maintenant pour SRAM2, je suis d'accord, le bout de données en plus fait foirer la protection, je poste donc un DSK sans cochonneries en plus.
Par contre, pour les jeux à protection hexagon, y a rien à faire, les pistes font bien 6400 octets de long au total, dont environ 6215 octets utilisés par piste.
Le souci par rapport à ce que tu demandes, c'est qu'en modifiant par rapport à ce que tu dis, on va avoir des problèmes avec d'autres jeux qui rentrent pas dans le même cas de figure. Et ça c'est ouvrir la boite de pandore à tout un tas de conneries dans lesquelles j'ai pas envie de mettre le nez.
Dès fois il vaut mieux plus que pas assez
J'ai déjà kukulcan qui comprend pas et qui met en doute ce que je lui dis quand je lui affirme que les pistes speedlock n'ont pas de checksum, il met en doute ma parole, alors que je sais très bien ce que j'avance, raison pour laquelle samdisk se prend les pieds dans le tapis, puisqu'il cherche à calculer un checksum qui n'existe pas (y en a pas sur les pistes!), et samdisk gueule en indiquant qu'il y a un problème de checksum lol XD !
Mais voilà, comme samdisk est dépourvu d'un sniffeur digne de ce nom, il fait forcément des erreurs, car il y a un autre type de piste de taille 6, c'est la protection hexagon, qui elle utilise un checksum en fin de piste, donc si on touche quoi que ce soit, on risque de casser quelque chose quelque part.
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
dlfrsilver a écrit :
C'est donc un problème dans ton émulation, il faut que tu reprennes le problème en main. Même mon CPC 6128 lit les eDSKs de chips challenge et crackdown après réécriture, donc ton émulateur devrait arriver au même résultat.
c'est bien là qu'on se comprend pas bien...ce n'est pas un problème dans l'émulation du FDC mais dans l'interpretation du eDSK !!!
Sugarbox reconstruit toute la piste à partir des infos (Lone pourra nous le confirmer avec un algo de deux kilomètres de code ! Mon émulateur respecte la norme, il transforme juste les données en MFM (en rajoutant les synchros, etc), s'il y a plus de &1800 de données, elles sont lus par le FDC et fourni au code Z80 ! Comme le code du loader ne s'attend pas à ces données supplémentaires -> plantage normal de la protection ! pour les autres émulateurs, s'ils ont supprimés toutes les données après &1800 de données, c'est normal que ça marche pour eux (Caprice Forever 0.26, CPCE, Caprice /support IPF, et j'en passe).! Si le code est dispo je pourrai le confirmer ou les auteurs directement ??? il suffit de dumper ce qu'envoie le FDC au Z80 pour confirmation !
Et si quelqu'un a des doutes, qu'il fasse le test de la commande de lecteur des gros secteurs sur un 'vrai' cpc, il verra bien cela aussi !
--> Donc plutôt que de corriger mon code correct et respectueux du format eDSK et de ce qui est indiqué dans le .dsk, je préférerai qu'on corrige les eDSKs, c'est tout ! Cela me parait bcp plus correct d'un point de vu émulation !!!
Ou alors, cela veut dire que le FDC ne fournit que &1800 de données par secteur au plus même si on lui en demande plus (8ko), mais j'ai des doutes car ce n'est pas ce que tu dis !???
D'ailleurs, cela ne se voient pas sur certains loader qui stoppe la lecture des données quand ils ont lu tout ce qui les interessent... cas sur certaines protections GAPS ce qui fait que même quand il y a trop de data dans le secteur (souvent des 00 00 00), cela marche qd même, même avec un mauvais eDSK !
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 3 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