CPC Rulez
https://cpcrulez.fr/forum/

TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
https://cpcrulez.fr/forum/viewtopic.php?f=2&t=5279
Page 2 sur 138

Auteur :  Lone [ 21 Juin 2014, 20:01 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Citer :
J'ai déjà crée avec succès des IPFs de jeux alléchants tel que le Manoir de Mortevielle, qui est protégé par une piste KBI-19 utilisant de la variation de densité, des secteurs en surcouche, ainsi que des zones GAP.


Je reviens la dessus pour m'être penché sérieusement sur les protections diverses et variées...
Comment se traduit cette variation de densité ? Autant les deux autres ( secteurs entrelacés et gap) me sont familières, autant celle la, je me demande ce que ça peut être.. ?

Auteur :  dlfrsilver [ 22 Juin 2014, 05:17 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Megachur a écrit :
dlfrsilver a écrit :
Denis
SPS France


Félicitations ! :biere:


Merci :)

@les forumeurs : J'ai déjà traduit la doc de démarrage rapide du Kryoflux, et je suis en train de traduire le manuel principal :)

Le travail de vulgarisation à commencé :)

Auteur :  dlfrsilver [ 22 Juin 2014, 05:23 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

remax a écrit :
dlfrsilver a écrit :
@ Remax : Eric Cantona Striker 2 en disquette ?


Oui

Citer :
question bête, c'est un jeu classique PC DOS avec des fichiers et un accès à une clé de protection sur disquette


Oui

Je soupconne éventuellement une protection physique (trou ou autre)

Citer :
Est-ce que tu es équipé pour pouvoir dumper tes jeux ou pas ?


J'ai un lecteur de D7, mais pas de Kryoflux (pas suffisament d'originaux rares pour que ca vaille le coup).


Le jeu utilise peut-etre la célèbre protection Rob Northern Computing ou RNC Copylock. Elle équipe bon nombre de jeu PC, tel que Jurassic Park, Lethal Weapon, Cool World ou encore Stormlord (j'ai vérifié, mon original est protégé le saligot, mais en plus cette dernière ne s'active pas au chargement du jeu, mais au moment de passer au niveau 2 si je me trompe pas "Please insert the original disk in drive" LOL.

Après ça peut-être aussi une protection clé disque comme celle de Joe and mac caveman ninja d'elite, qui va carrément "taper" dans le code du firmware du lecteur de disquette.

Il faudrait qu'on puisse s'arrange à ce moment là pour que je puisse dumper ta disquette :)

Auteur :  MacDeath26 [ 22 Juin 2014, 08:17 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Quid du système de protection de defender of the crown sur CPC ?

les dévelopeurs étaient venu nous en parler...

Auteur :  jbaudrand [ 22 Juin 2014, 18:10 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

oui d'ailleurs il y avait bien une version corrigée de defender of the crown de prévue?

Auteur :  MacDeath26 [ 22 Juin 2014, 18:46 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Comme pour Monkey island ?

:sweatingbullets:

Auteur :  jbaudrand [ 22 Juin 2014, 21:09 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

:nage:

Auteur :  dlfrsilver [ 22 Juin 2014, 22:54 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

MacDeath26 a écrit :
Quid du système de protection de defender of the crown sur CPC ?

les dévelopeurs étaient venu nous en parler...


Le système de protection de defender of the crown CPC c'est un format en secteur de taille 6. C'est pris en charge directement par l'outil de création d'IPF :)

Cette protection ne me causera aucun problème :)

Auteur :  dlfrsilver [ 24 Juin 2014, 01:41 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

dlfrsilver a écrit :
MacDeath26 a écrit :
Quid du système de protection de defender of the crown sur CPC ?

les dévelopeurs étaient venu nous en parler...


Le système de protection de defender of the crown CPC c'est un format en secteur de taille 6. C'est pris en charge directement par l'outil de création d'IPF :)

Cette protection ne me causera aucun problème :)


Je viens d'utiliser la nouvelle version de l'outil de création d'IPF, et le format de protection Hexagon Disk est référencé dedans......

En fait, le format n'a en soit rien à voir avec ce que le CPC nous lit :

Il s'avère que si une piste Hexagon comporte bien 1 bloc pour bon nombre de jeux de 6150 octets à plus 6305 octets grosso modo, une piste hexagon ne fait pas 8192 octets, mais 12386 !
On voit que la piste a été conçue de base sur une machine industrielle, car le CPC ne voit pas la taille réelle de la piste, mais bien celle que son FDC interprète.... En plus, tout comme la protection KBI, la zone GAP de fin de piste comporte si j'ai bien saisi les infos données par l'analyseur de flux une variation de densité (la vitesse d'écriture a été moins rapide sur cette zone là, y a plus d'octets en gros dans un espace plus réduit.

La protection Discsys est également supportée (Un petit clin d'oeil à Kukulcan :) ) dans l'outil elle est appelée Sector16 (vais voir avec le boss pour qu'il la renomme dans l'outil). Faudra que je lui envoie un screen de la composition de la piste (octets de synchro, CRCs, GAP, et bloc de donnée).

Il y a aussi la protection alkatraz, et les protections GAP ont l'air bien prise en charge :)

La protection KBI et CAAV19 sont elles aussi gérées, par contre les KBI-10 à secteurs faibles ne sont pas supportées, je vais le remonter :)

Le gros point noir en fait d'après mes tests et après consultations des infos techniques à disposition chez SPS, ce sont les zones GAP intersecteurs. La méthode utilisée pour différencier un jeu copié d'un jeu original non modifié est pour moi une abérration du style :

Je dumpe Gremlins 2 d'Erbe software en original de chez Elite version UK. Elite comme tout les éditeurs n'est pas du genre à dupliquer ses jeux à la main de façon artisanale, c'est pour ça que les éditeurs passent par des duplicateurs tel que KBI, CAAV, SITIS par exemple. Une trace industrielle est dotée d'un chargeur qui permet de traiter à la vitesse de la lumière 500 disquettes en une fournée, sachant qu'une traceuse écrit très vite sur la disquette, plus vite globalement qu'un ordinateur (indépendamment du nombre de tour par minutes). On comprend aisément que le gain de temps est sans commune mesure, quand on veut vendre à plusieurs milliers d'exemplaires des jeux, c'est la solution. Pour en revenir à Gremlins 2, l'outil me dit que la disquette est modifiée, ce qui est bien entendu faux puisque le jeu est protégé contre la copie. C'est donc que les zones GAP ne sont pas correctement reconnues par l'outil d'analyse, donc correction à faire.

Enfin voilà, j'en suis à une petite 30aine de jeux passés en IPF, je continue.

Auteur :  Megachur [ 24 Juin 2014, 06:05 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

dlfrsilver a écrit :
Enfin voilà, j'en suis à une petite 30aine de jeux passés en IPF, je continue.


Super que tu puisses enfin faire évoluer l'outil pour le dump de notre patrimoine cpc ! :winner:

Bon courage pour les dumps, car même si la passion est là, je pense que cela doit prendre du temps !!! :biere: :biere: :biere:

Auteur :  Lone [ 24 Juin 2014, 09:59 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Les jeux en IPF sont-ils disponible quelque part ? Peut-on les tester ?

Il existe bien une liste des dumps sur le site de la SPS, mais... Ca semble très vieux : Les dernières update datent de 2010, et surtout, aucun lien de téléchargement n'est présent.

J'avoue que mon souhait, c'est de confronter un peu mes algo et mon intégration de la librairie IPF avec du vrai matériel...


Sinon, toutes ces informations sur les protections m'intéressent au plus haut point : Vu que je tente de reproduire la piste MFM le plus exactement possible (relativement facile avec du kryoflux, un challenge de tous les instant avec le format DSK), je me suis concocté un moyen de "dumper" le flux de bit de la piste, pour pouvoir l'analyser visuellement (oui, tel Neo, je lis la matrice ..) ou en comparaison avec ce qu'on est sensé y trouver.

Concernant les pistes dont la taille parait délirante, c'est en fait une particularité de la lecture des secteurs :

Les secteurs de taille 6 peuvent être lu, et font en théorie 8192 octets. On lit donc 8192 octets... Ce qui nous fait lire, en réalité, 1,3 fois la piste (et donc, repasser par l'index, les infos de début de piste, les premiers secteurs...).

Ensuite, le tout est de savoir ce que la protection fait des données lues : En général, elles sont désynchronisée, et on lit donc des trucs qui n'ont pas forcément à voir avec ce à quoi on s'attend : Les octets lus le sont par paquet de 8 bits (16 bits MFM en fait), et si, en bout de piste, on n'a pas un nombre de bits qui est un multiple de 16, tout sera décalé.

J'ai été confronté à ce type de protection sur les educatifs "reussirs" (ex : http_//www.cpc-p0wer.com/index.php?page=detail&onglet=dumps&num=5546 )
La protection lit l'intégralité du secteur de taille 6, et ça ensuite comparer un des octets lu, le 8095e, avec une valeur qu'il est sensé trouver.
Ayant fait le tour complet de la piste, l'octet que l'on s'attend à voir est en fait "E5", mais shifté par le passage à l'index, la comparaison se fait avec "CB", ou "08" suivant les cas.

(Petite aparté pour ceux que ça intéressent :
Parlons binaire :
E5 = 1110 0101.
Le format MFM est ainsi codé :
- un '1' est toujours codé '01'
- Un '0' est codé '00' SAUF si le bit précédent est un '0' auquel cas il sera codé '10'
- La règle de base est la suivante : pas plus de 3 '0' à la suite. -> Pour les raisons, voir wikipedia / MFM

E5 en MFM = 01010100 10010001.

Ce qui nous donne, lorsque l'on "shifte" le tout :

Première colonne : valeur du décalage

0 0 1 0 1 0 1 0 0 1 0 0 1 0 0 0 1 = E5
1 1 0 1 0 1 0 0 1 0 0 1 0 0 0 1 0 = 10
2 0 1 0 1 0 0 1 0 0 1 0 0 0 1 0 1 = CB
3 1 0 1 0 0 1 0 0 1 0 0 0 1 0 1 0 = 20
4 0 1 0 0 1 0 0 1 0 0 0 1 0 1 0 1 = 97
5 1 0 0 1 0 0 1 0 0 0 1 0 1 0 1 0 = 40
6 0 0 1 0 0 1 0 0 0 1 0 1 0 1 0 1 = 2F
7 0 1 0 0 1 0 0 0 1 0 1 0 1 0 1 0 = 80

etc...
)

Auteur :  dlfrsilver [ 24 Juin 2014, 13:03 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Lone a écrit :
Les jeux en IPF sont-ils disponible quelque part ? Peut-on les tester ?

Il existe bien une liste des dumps sur le site de la SPS, mais... Ca semble très vieux : Les dernières update datent de 2010, et surtout, aucun lien de téléchargement n'est présent.

J'avoue que mon souhait, c'est de confronter un peu mes algo et mon intégration de la librairie IPF avec du vrai matériel...


Sinon, toutes ces informations sur les protections m'intéressent au plus haut point : Vu que je tente de reproduire la piste MFM le plus exactement possible (relativement facile avec du kryoflux, un challenge de tous les instant avec le format DSK), je me suis concocté un moyen de "dumper" le flux de bit de la piste, pour pouvoir l'analyser visuellement (oui, tel Neo, je lis la matrice ..) ou en comparaison avec ce qu'on est sensé y trouver.

Concernant les pistes dont la taille parait délirante, c'est en fait une particularité de la lecture des secteurs :

Les secteurs de taille 6 peuvent être lu, et font en théorie 8192 octets. On lit donc 8192 octets... Ce qui nous fait lire, en réalité, 1,3 fois la piste (et donc, repasser par l'index, les infos de début de piste, les premiers secteurs...).

Ensuite, le tout est de savoir ce que la protection fait des données lues : En général, elles sont désynchronisée, et on lit donc des trucs qui n'ont pas forcément à voir avec ce à quoi on s'attend : Les octets lus le sont par paquet de 8 bits (16 bits MFM en fait), et si, en bout de piste, on n'a pas un nombre de bits qui est un multiple de 16, tout sera décalé.

J'ai été confronté à ce type de protection sur les educatifs "reussirs" (ex : http://www.cpc-p0wer.com/index.php?page=detail&onglet=dumps&num=5546 )
La protection lit l'intégralité du secteur de taille 6, et ça ensuite comparer un des octets lu, le 8095e, avec une valeur qu'il est sensé trouver.
Ayant fait le tour complet de la piste, l'octet que l'on s'attend à voir est en fait "E5", mais shifté par le passage à l'index, la comparaison se fait avec "CB", ou "08" suivant les cas.

(Petite aparté pour ceux que ça intéressent :
Parlons binaire :
E5 = 1110 0101.
Le format MFM est ainsi codé :
- un '1' est toujours codé '01'
- Un '0' est codé '00' SAUF si le bit précédent est un '0' auquel cas il sera codé '10'
- La règle de base est la suivante : pas plus de 3 '0' à la suite. -> Pour les raisons, voir wikipedia / MFM

E5 en MFM = 01010100 10010001.

Ce qui nous donne, lorsque l'on "shifte" le tout :

Première colonne : valeur du décalage

0 0 1 0 1 0 1 0 0 1 0 0 1 0 0 0 1 = E5
1 1 0 1 0 1 0 0 1 0 0 1 0 0 0 1 0 = 10
2 0 1 0 1 0 0 1 0 0 1 0 0 0 1 0 1 = CB
3 1 0 1 0 0 1 0 0 1 0 0 0 1 0 1 0 = 20
4 0 1 0 0 1 0 0 1 0 0 0 1 0 1 0 1 = 97
5 1 0 0 1 0 0 1 0 0 0 1 0 1 0 1 0 = 40
6 0 0 1 0 0 1 0 0 0 1 0 1 0 1 0 1 = 2F
7 0 1 0 0 1 0 0 0 1 0 1 0 1 0 1 0 = 80

etc...
)


Je posterais les IPFS une fois officialisés (ceux que j'ai généré n'ont pas de signature électronique, j'attends que mon dongle m'arrive par la poste ce jeudi), donc pas de souci !

tu pourras t'entrainer à gogo :)

Sauf si comme pour la protection hexagon, le CPC ou du moins le FDC interprète la piste et la voit différemment de ce qu'elle est véritablement à l'origine, c'est à dire telle que la traceuse industrielle l'a écrite.
J'ai regardé sur CPC-p0wer, c'est une piste qui fait peut-être 11 ou 12ko et pas 8. Le CPC la voit sous forme de 2 secteurs, 1 de 8ko qui en "fait" 2, et le 2ème un de 512 octets mais dont la taille déclarée est de 3979 octets + une zone gap.

Tiens dans le même genre, j'ai fait un comparato entre Dark Century de Titus en DSK, la taille des secteurs, et mon dump au format RAW d'un original disquette version budget EDOS, là encore on voit bien que les jeux protégés au format DSK (basé sur l'interprétation des données par le FDC) et le format IPF (basé sur la lecture du flux magnétique gravé par traceuse industrielle, donc ce qui a été réellement écrit sur disquette) y a une sérieuse différence.

Exemple : je prends la piste 37 du dump de Maxit, 5376 octets affichés. La piste 37 écrite sur la disquette originale fait en réalité 11574 octets de long. Il y a pas mal d'exemples dans les jeux que j'ai passé en revue ou les tailles de pistes ne correspondent pas à ce que l'outil trouve.

Explication de ces différences : Ces pistes, tout du moins le master est crée soit sur un atari ST, soit sur un PC. Ces machines n'ont pas les limites de taille de piste du CPC. Sur ces machines 16 bits, il n'est pas rare de trouver des piste qui font entre 10 et 12ko.

De la même façon, on trouve sur atari ST des jeux dotés de pistes amiga : exemple Golden Axe. Simplement le FDC de l'atari ST voit les données différemment de la façon dont elles ont été écrite.

Auteur :  Lone [ 24 Juin 2014, 13:32 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Je me demande si tu ne devrais pas remettre en cause ton outil !

Le FDC fonctionne comme la plupart des supports magnétiques, en détectant les inversions de flux sur le support.
En gros, sur une fenêtre donnée, s'il y a une inversion de flux, on a un '1', sinon, on a un '0'.

Sachant qu'on est limité (pour ne pas se désynchroniser) a environ 3 '0' à la suite maximum.

La fenêtre en question, est grande de l'ordre de 2 micro secondes, avec une tolérance de l'ordre de 5% (peut être un peu plus, mais pas plus de 10%, en tout cas).

Pour un disque qui tourne à 300 RPM, on a donc : 200 ms par tour, soit 100 000 bits par tour de piste.
Vu qu'on a un enregistrement de type MFM, on a donc un bit de 'clock' pour un bit de data (pour rester dans la limite des 3 '0' consécutifs).

On a donc 50 000 bits de data. Soit.... 50000/8 = 6250 bytes. Plus ou moins 5%, vu la précision mécanique du truc. Donc, une piste de 6100 octets reste crédible, mais pas une de 11000 !
Sachant que les disks sont tout de même prévu pour passer sur la majorité des CPC, on ne pousse pas a l’extrême limite la densité des inversions de flux.

Du coup, pris de curiosité, j'ai regardé le dump de Dark century.
En fait, ça correspond à ce que je pensais : Si je le charge avec Sugarbox dernière mouture, il va me générer une piste de 6200 octets grosso modo (extrapolation oblige) : Il reconnait en effet dans le dernier secteur, le début de piste (on le reconnait aussi quand on sait ce qu'on cherche :

Si on regarde la fin de dump :

018810: 20 63 6F 6E 73 6F 6C 65 73 20 21 21 21 20 45 72 consoles !!! Er
018820: 69 63 2C 47 69 6C 20 26 20 45 72 69 63 20 44 4E ic,Gil & Eric DN
018830: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
018840: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
018850: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
018860: 4E 4E 02 05 21 21 21 21 21 21 21 21 21 21 21 21 NN..!!!!!!!!!!!!
018870: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 !!!!!!!!!!!!!!!!
018880: 21 21 21 21 FF FF FF FF FF FF FF FF FF FF FF FE !!!!............
018890: 28 28 28 03 21 21 21 21 21 21 21 21 21 21 21 21 (((.!!!!!!!!!!!!
0188A0: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 !!!!!!!!!!!!!!!!
0188B0: 21 21 FF FF FF FF FF FF FF FF FF FF FF 00 00 00 !!..............

Et que l'on regarde entre les lignes, on voit bien le GAP de fin de piste (4E), du bazard du a l'index (0205), un gap de debut (21, qui est en fait surement un 4E shifté), la très reconnaissable synchro (FF FF ... En effet, avec la magie du MFM, FF n'est autre qu'un 00 decalé : FF = 01 01 01 ... et 00 = 10 10 10 ....)
28 28 28 03 doit surement être l'IAM (C2C2C2FC), suivi du GAP (21 a nouveau), de la synchro (FF), puis l'enregistrement du dsk s'est arrêté, car sans doute la suite n'est-elle pas testée.

Cela dit, pour ma part, les fichiers de l'IPS et les CT raw sont une bénédiction : Reconstituer une piste MFM avec ces formats est trivial.. (contrairement au DSK !)
C'est bien pour ça, entre autre, que je suis très heureux que tu ais eu une telle promotion :)

(PS : Désolé pour les wall of text, mais faut pas me lancer sur ces sujets, non, il ne faut pas...)

Thomas

Auteur :  dlfrsilver [ 24 Juin 2014, 15:03 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Lone a écrit :
Je me demande si tu ne devrais pas remettre en cause ton outil !


L'outil a été conçu il y a 13 ans, par un ponte de chez Sony, qui maitrise à 500% son truc.

C'est un mec qui était payé y a 4 ans 540000 euros à l'année lol Et il a eu de la promo, il est ingénieur principal :)

Citer :
Le FDC fonctionne comme la plupart des supports magnétiques, en détectant les inversions de flux sur le support.


Le FDC est le contrôleur, une puce électronique, et le support magnétique c'est autre chose :)

En gros, sur une fenêtre donnée, s'il y a une inversion de flux, on a un '1', sinon, on a un '0'.

Sachant qu'on est limité (pour ne pas se désynchroniser) a environ 3 '0' à la suite maximum.

La fenêtre en question, est grande de l'ordre de 2 micro secondes, avec une tolérance de l'ordre de 5% (peut être un peu plus, mais pas plus de 10%, en tout cas).

Citer :
Pour un disque qui tourne à 300 RPM, on a donc : 200 ms par tour, soit 100 000 bits par tour de piste. Vu qu'on a un enregistrement de type MFM, on a donc un bit de 'clock' pour un bit de data (pour rester dans la limite des 3 '0' consécutifs).


Oui, ça c'est pour une piste standard. Dès qu'on sort de la, on a le droit à tout un tas de bizarreries :)

Et je suis d'accord avec toi en ce qui concerne la tolérance, c'est plus ou moins 10% sur les FDC PC compatibles comme ceux de l'amstrad CPC, du PC et du ST

Citer :
On a donc 50 000 bits de data. Soit.... 50000/8 = 6250 bytes. Plus ou moins 5%, vu la précision mécanique du truc. Donc, une piste de 6100 octets reste crédible, mais pas une de 11000 !


Comme je le disais plus haut, le FDC interprète ce qui est gravé sur la disquette 3 pouces, et ne voit pas la taille totale de la piste. Sachant que le principe est que l'amstrad CPC puisse vérifier la protection, mais en aucun cas voir le format tel quel. 6100 octets c'est crédible sur CPC, 11000 c'est la vraie et véritable taille
gravée sur la disquette par une machine unix depuis le master crée sur un PC ou un ST. Ces machines ne sont pas limitées en l'état à 6100 octets par pistes. Ah j'oubliais un détail : je ne parlais pas de 11ko de données par piste, je parle de structure !

Citer :
Sachant que les disks sont tout de même prévu pour passer sur la majorité des CPC, on ne pousse pas a l’extrême limite la densité des inversions de flux.


comme dit juste au dessus, la surcapacité n'excède pas 10% de plus sur les FDC UPD765 compatibles.
La compilation dotée de la plus grande longueur de données par piste (enfin y en a plusieurs).
La compil Coin-op hits d'USGOLD, et celle des 12 jeux fantastiques de Gremlin Graphics. On a eu débat à un moment à ce sujet, car la longueur maximum des pistes définies dans le format DSK à l'époque c'était 6100 octets. J'ai rencardé Simon Owen, le créateur de samdisk sur le sujet, et après vérification, il s'est aperçu que le chargeur de piste lisait 6305 ou 6405 octets par piste. Forcément, en ayant des pistes coupées, les jeux plantaient ou bien la protection faisait un reset.

Citer :
Du coup, pris de curiosité, j'ai regardé le dump de Dark century. En fait, ça correspond à ce que je pensais : Si je le charge avec Sugarbox dernière mouture, il va me générer une piste de 6200 octets grosso modo (extrapolation oblige) : Il reconnait en effet dans le dernier secteur, le début de piste (on le reconnait aussi quand on sait ce qu'on cherche :

Si on regarde la fin de dump :

018810: 20 63 6F 6E 73 6F 6C 65 73 20 21 21 21 20 45 72 consoles !!! Er
018820: 69 63 2C 47 69 6C 20 26 20 45 72 69 63 20 44 4E ic,Gil & Eric DN
018830: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
018840: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
018850: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
018860: 4E 4E 02 05 21 21 21 21 21 21 21 21 21 21 21 21 NN..!!!!!!!!!!!!
018870: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 !!!!!!!!!!!!!!!!
018880: 21 21 21 21 FF FF FF FF FF FF FF FF FF FF FF FE !!!!............
018890: 28 28 28 03 21 21 21 21 21 21 21 21 21 21 21 21 (((.!!!!!!!!!!!!
0188A0: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 !!!!!!!!!!!!!!!!
0188B0: 21 21 FF FF FF FF FF FF FF FF FF FF FF 00 00 00 !!..............

Et que l'on regarde entre les lignes, on voit bien le GAP de fin de piste (4E), du bazard du a l'index (0205), un gap de debut (21, qui est en fait surement un 4E shifté), la très reconnaissable synchro (FF FF ... En effet, avec la magie du MFM, FF n'est autre qu'un 00 decalé : FF = 01 01 01 ... et 00 = 10 10 10 ....)
28 28 28 03 doit surement être l'IAM (C2C2C2FC), suivi du GAP (21 a nouveau), de la synchro (FF), puis l'enregistrement du dsk s'est arrêté, car sans doute la suite n'est-elle pas testée.


Comme je le disais aussi plus haut, ce que tu vois ici, c'est la lecture sectoriel et FDC du CPC. Donc sur ce principe je suis d'accord, tu trouve 6200 octets grosso modo. Mais voilà, déjà Samdisk ne voit pas la variation de densité et de 1), de 2) comme je l'expliquais plus haut, les protections amstrad CPC ont été conçues, mises au point sur PC ou atari ST. Il y a des informations sur ces pistes que l'amstrad CPC ne voit pas (enfin que son FDC ne voit pas). Et c'est très clair de ce point de vue.

J'ai du mal aussi à me faire comprendre dans la communauté Atari ST, qui a du mal à comprendre qu'un programmeur ou un créateur de protection puisse utiliser une machine autre que la machine cible pour concevoir le dit système.

Des exemples j'en ai à la pelle : Dragon Flight de Thalion sur atari ST utilise des pistes Amiga, James pond sur Amiga utilise des pistes atari ST, Le nécromancien d'ubi sur amstrad CPC utilise une protection crée par Rubi sur un Atari ST via l'utilitaire UDISK, La protection Hexagon 1800 sur amstrad CPC utilise des pistes Amstrad PCW, Maupiti Islands sur atari ST utilise des pistes Amiga, Golden Axe aussi, Obitus de Psygnosis sur atari ST utilise aussi des pistes Amiga, Viaje al centro de la tierra de Topo soft utilise sur amiga 2 disquettes, une en format Amigados standard, la deuxième est bi-format (moitié Amiga MFM, moitié Atari ST + protection GAP), enfin voilà, la liste est super longue.

Citer :
Cela dit, pour ma part, les fichiers de l'IPF et les CT raw sont une bénédiction : Reconstituer une piste MFM avec ces formats est trivial.. (contrairement au DSK !) C'est bien pour ça, entre autre, que je suis très heureux que tu ais eu une telle promotion :)


En fait, en traitant les pistes de protections telles qu'elles sont vraiment écrites, oui c'est amusant ! Je m'étonne de voir que les tailles entre DSK et IPF ne correspondent pas, mais c'est normal en fait, puisque le format DSK c'est d'abord de la gestion de secteurs et de zone GAP, et non de la gestion de pistes.

La plupart des pistes de protection sur amstrad utilisent 2 patterns de mots de synchro : $5224 et $4489 répété 3 fois de suite, et d'ailleurs, $4489 est un mot de synchro qui vient du monde l'amiga, mais on le trouve aussi sur ST, sauf que $4489 est codé sur un ST $A1 donc 3 synchros de $4489 se voient $A1,$A1,$A1 si on regarde la piste avec un éditeur hexadécimal.

Citer :
(PS : Désolé pour les wall of text, mais faut pas me lancer sur ces sujets, non, il ne faut pas...)

Thomas


Pas de soucis, plus on s'en dit et mieux c'est :)

Auteur :  dlfrsilver [ 24 Juin 2014, 15:51 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)

Je viens de recevoir ce jour le dongle de sécurité qui permet l'utilisation du CTA.

Il m'a été prété, et je devrais le rendre si on me le demande.

Pour information, j'ai le prix exact du dongle et de l'utilisation de l'outil de création des IPF qui est de 7000 euros.

Ouch ça pique. Mais peu importe, le moment est venu de générer un max d'IPF officiel :)

Le boss m'envoie ce soir la dernière mouture du logiciel, et après c'est parti :)

Page 2 sur 138 Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/