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 117 sur 138
Auteur :  marcel [ 03 Mai 2018, 19:33 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
de toutes façons il ne doit pas y avoir des masses de modification avec les versions modifiées précédentes non?
Auteur :  dlfrsilver [ 03 Mai 2018, 19:54 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Lone a écrit :
Les deux dumps semblent ok pour moi (j'ai pas joué des heures non plus, hein...)


Ils le sont, le jeu n'est pas protégé.
Auteur :  dlfrsilver [ 03 Mai 2018, 19:57 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
marcel a écrit :
de toutes façons il ne doit pas y avoir des masses de modification avec les versions modifiées précédentes non?


Le souci c'est que je peux pas préservé un jeu modifié :/

C'est inespéré d'avoir un original non modifié, la majeure partie des joueurs d'Iron Lord, ont soit cheaté les disquettes, soit fait le jeu à la loyale, c'est à dire sauvé leur partie pour accéder au wargame. Y a pas d'autre moyen. Quand j'y pense, quelle connerie de pas avoir mis la sauvegarde en externe......
Auteur :  dlfrsilver [ 05 Mai 2018, 00:32 ]
Sujet du message :  Re: Annonce et bonne nouvelle :)
dlfrsilver a écrit :
Nouveau jour, nouveau batch, cette fois-ci de chez Moonbeam :

en IPF :
----------

- 4 stars Compilation

- Arkanoid Revenge of Doh

- Blood Valley (Gremlin)

- Codemasters Quattro Volume Five - Shootem ups

- Codemasters Quattro Volume Nine - Turbo Power

- Hit 14 (ubisoft) (contient la disquette TOP 10 qui est une autre compilation :mdr: )

- Hollywood Collection (Ocean)

- La Collection CPC (Ocean)

- Les Aventures de Pepito Au Mexique (Microids)

- Les Dieux de la mer (Patrice Martin) (encore un dump...)

- Les Hits N.2 (Loriciel)

- Les Petits Coloriages Malins - Volume 2 (Carraz)

- Mathématiques Succès 6ème

- Operation Wolf (Ocean) (revision 2) c'est une seconde révision d'Operation wolf !

- Prince de Perse (Broderbund France)

- Qin (Ere Informatique)

- Rick Dangerous 2 (Microstyle)

- Sram 2 (Ere Informatique)

- The Story So Far Volume 2 (Elite)

- Top Secret (Loriciels)

Modifiés :
------------

- Mortville Manor (revision alternative), modifiée en piste 41

- Oxphar (Ere Informatique), comme d'hab, encore un qui a sauvé sa partie sur la disquette....

- The World Greatest Epyx (U.S.Gold), comme d'hab, encore un qui a sauvé son score....

- Turbo Cup (Loriciels), comme d'hab, encore un qui a sauvé son score en piste 38.

Non supportés :
--------------------

- Arcade hits (loriciels), vu comme non dupliqué

- Geographie Marché commun (loriciels, vu comme non dupliqué

- Super Prof du CM1 à la 5ème (Nouveauté, plombé par KBI-10 WS)

- Les Chevaliers (U.S.Gold), pistes très longues, problème pour décoder le format (pistes hexagon), mais passage en DSK OK, donc non supporté.

- Sapiens (Loriciels), vu comme non dupliqué

- Special Action (Ocean), IPF partiel, la face A de la compilation utilise un format de piste speedlock non supporté, l'analyseur ne les reconnait qu'à 80%, mais passage en format DSK OK.

- The Cycles (Accolade), comme d'habitude, protection speedlock, mais vu comme non dupliqué car tracé sur une machine autre que TraceMoutain.

En utilitaire IPF :
---------------------

- Amcharge Version 2 (pas utile, mais pour le principe)

- La Solution #14878 (Calcumat, textomat, datamat, la suite complète)

- Textomat


Je mettrais les fichiers en ligne d'ici quelque temps, j'ai actuellement d'autres priorités à traiter.


J'ai complètement, mais alors complètement zappé l'upload de ce batch là en mars 2017 :?

Fichiers CTraw, DSK, et CDT en PJ :)
Auteur :  dlfrsilver [ 05 Mai 2018, 12:07 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
A l'attention de Lone & Megachur, concernant la protection du logiciel réussir. Bon, Breiztiger m'a envoyé les pistes pour analyse.

4 choses à noter :
---------------------

1) utilisation de la variation de densité : la taille de bitcell est pas loin de 4us (normalement 2us)

2) La piste de protection utilise un double trou d'index ! (c'est une piste bricolée comme la KBI-19)

3) elle ressemble à des pistes speedlock ou hexagon, mais avec un overlap comme pour les protections KBI-19 lol !

4) Elle ne contient rien, c'est que de la structure, y a pas de données dedans.

et enfin Le CTA supporte la protection qui est vu comme étant dupliquée :)

Pièce jointe :
Reussir Conjugaison_face _a_track38.0.raw.jpg


T38.0-S1 IIF-ISL Invalid ID Field: 6 in an Invalid Sector Length (ISL)
T38.0-S1 DCE DATA CRC Error
T38.0-S2 DCE DATA CRC Error

C'est exactement ce qu'on trouve sur les pistes speedlock et hexagon :)
Auteur :  Lone [ 05 Mai 2018, 15:54 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Hello,

En regardant la même piste, je ne vois pas les tout à fait les mêmes choses :)

- La taille d'une cellule est bien autours de 2us (le deuxième graph en partant du bas)
On ne dépasse pas les 2.05us (2050ns).

- Ne pas confondre avec les durées de transitions !
Petit rappel : sur la fenêtre étudiée (bitcell de 2us), on va regarder si l'on a une inversion de flux.
Si oui : un '0'
Si non, un '1'
Avec ça, on a nos données MFM.
On a donc des flux, pour une piste lisible, dont les valeurs sont 4, 6, 8 us (soit 2, 3, 4 cellules)
- 4 : 0 puis 1
- 6 : 0, 0, 1
- 8 : 0, 0, 0, 1

Avec ces trois valeurs, on ne viole pas les contraintes MFM (pas plus de 3 '0' à la suite, pour pas faire perdre les pédales à la PLL)
De même, on n'a pas de flux à '2' dans la mesure ou deux '1' qui se suivent n'est pas quelque chose qui est censé arriver en MFM.

Du coup, je suis un peu sceptique sur le fait que la variation de bitrate observée est voulue (les variations sont assez régulières tout de même).

Par contre j'aimerais bien savoir ce qui te fait dire que l'on a deux index ?? Si je ne me trompe pas, le trou d'index est unique pour la disquette (et non un par piste) ?


Pour la protection elle-même, c'est assez marrant : Ca consiste à lire une piste fictive de grande taille, qui oblige donc à relire le début de la disquette (sur une piste, qui fait 6ko max, lire 9ko va obliger à lire deux fois la même chose, au moins sur 3ko, en faisant le "tour" de la disquette).
Là, après le passage du trou d'index, elle va vérifier un octet. La taille de la piste étant ce qu'elle est, on ne va pas lire 'E5' comme au premier passage, mais cette valeur décalée du reste de la taille réelle entre le secteur lu et la fin de la piste, modulo 16.
(Exemple : Piste 38, soit 'x' le nombre de bit entre le début du second secteur et la fin de la piste.
Arrivée au trou d'index, on sera possiblement en plein milieu d'un octet (si x n'est pas un multiple de 16). Derrière, tout sera décalé !)

C'est difficile à copier : il faudrait avoir une taille de piste avec le même modulo 16 du nombre de bit entre le second secteur et la fin de la piste. On peut supposer qu'une copie sur 16 fonctionne avec des moyens traditionnels (ce qui n'est même pas avéré !)
D'ailleurs, difficile de dire comment la piste a été écrite : Vu que le soft à l'air artisanal, je soupçonne l'octet de test d'avoir été rajouté après lecture sur chaque disquette... (ya qu'a voir la réécriture avec des moyens modernes : Même avec un Kryoflkux, c'est difficile à réécrire correctement - Sauf pour breiztiger !)
Auteur :  breiztiger [ 05 Mai 2018, 17:47 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
houlà thomas tu me prêtes plus de compétences que je n'en ai je pense :mdr:

s'il est vrai que j'avais réussi a "copier" une disquette réussir, de mémoire les 4 opérations, c'est avec l'aide de samdisk pour la transformation

depuis beaucoup de choses ont change dans nos dumps et dans samdisk qui ne produit plus actuellement le même eDSK qu'a l'époque

la v4 de samdisk travaille différemment que la version 3 et est toujours en cours d'écriture (simon vient encore de corriger des choses sur les secteurs 6k …)

a suivre donc :biere:
Auteur :  dlfrsilver [ 06 Mai 2018, 02:23 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Lone a écrit :
Hello,

En regardant la même piste, je ne vois pas les tout à fait les mêmes choses :)

- La taille d'une cellule est bien autours de 2us (le deuxième graph en partant du bas)
On ne dépasse pas les 2.05us (2050ns).


Regarde la mention flux range : normalement on est sur une piste classique à 1,5x-1,6x us sur une piste normale, ici on est à 3,70.

La piste de Breitztiger fait 6ko tassé dans un espace de 3ko !

On ne le voit pas sur mon screen, mais le carré qui représente la piste est de couleur bleue. Quand la couleur est bleue, c'est qu'il y a utilisation de la variation de densité. Comme on utilise la variation ? Simple, au lieu de tracer en 2us, on trace à une valeur plus forte.

Citer :
- Ne pas confondre avec les durées de transitions !


Flux range en anglais ne veut pas dire durée de transition ! ça veut dire plage de fluctuation !

Citer :
Du coup, je suis un peu sceptique sur le fait que la variation de bitrate observée est voulue (les variations sont assez régulières tout de même).


Aufit permet de voir la variation de densité : quand les pistes sont en vert, elles sont normales, quand elles sont en bleu, y a variation de densité. Soit plus de données écrites dans un espace réduit.

Citer :
Par contre j'aimerais bien savoir ce qui te fait dire que l'on a deux index ?? Si je ne me trompe pas, le trou d'index est unique pour la disquette (et non un par piste) ?


Pièce jointe :
Reussir Conjugaison_face _a_track38.0.raw.jpg


Regarde les rectangles verticaux en rouge. C'est la première fois que je vois de ma vie sur une protection Amstrad CPC (et même Atari ST ou PC), une piste de protection, avec 2 zones de trou d'index !

Normalement, toutes les pistes qu'on a vu ici n'en ont qu'un seul ! Ici cette piste de protection a été crée en 2 passes, la première pour le petit secteur, et la seconde pour le reste de la piste.

C'est tellement pas courant que ça saute aux yeux !

Citer :
Pour la protection elle-même, c'est assez marrant : Ca consiste à lire une piste fictive de grande taille, qui oblige donc à relire le début de la disquette (sur une piste, qui fait 6ko max, lire 9ko va obliger à lire deux fois la même chose, au moins sur 3ko, en faisant le "tour" de la disquette).


Moi j'ai un souci avec la représentation faite par samdisk. Celle-ci est incorrecte. Le petit secteur suivant par sa zone gap est en 1er, et le secteur avec la grosse zone GAP est en second.

Hors, dans le DSK qu'on peut générer, le secteur avec la grosse zone GAP est en premier, et le secteur avec la zone GAP plus petite arrive après, c'est pas normal.

Citer :
Là, après le passage du trou d'index, elle va vérifier un octet. La taille de la piste étant ce qu'elle est, on ne va pas lire 'E5' comme au premier passage, mais cette valeur décalée du reste de la taille réelle entre le secteur lu et la fin de la piste, modulo 16.
(Exemple : Piste 38, soit 'x' le nombre de bit entre le début du second secteur et la fin de la piste.
Arrivée au trou d'index, on sera possiblement en plein milieu d'un octet (si x n'est pas un multiple de 16). Derrière, tout sera décalé !)

C'est difficile à copier : il faudrait avoir une taille de piste avec le même modulo 16 du nombre de bit entre le second secteur et la fin de la piste. On peut supposer qu'une copie sur 16 fonctionne avec des moyens traditionnels (ce qui n'est même pas avéré !)
D'ailleurs, difficile de dire comment la piste a été écrite : Vu que le soft à l'air artisanal, je soupçonne l'octet de test d'avoir été rajouté après lecture sur chaque disquette... (ya qu'a voir la réécriture avec des moyens modernes : Même avec un Kryoflkux, c'est difficile à réécrire correctement - Sauf pour breiztiger !)


Le kryoflux peut tout écrire, mais il faut que les données soient correctement implémentées.

en tout cas, chapeau au mec qui a pondu, mis au point cette cochonnerie, ça requiert du matériel capable de tracer avec précision une piste sur une durée donnée, d'une certaine taille, et de venir mettre à la suite une seconde piste en fait ahahah :D
Auteur :  dlfrsilver [ 06 Mai 2018, 03:11 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Ensuite, une vidéo intéressante d'un test d'un émulateur de drive pour CPC fait par Moudubou:



Il apparait que le DSK du jeu Batman the movie en pistes speedlock ne fonctionne pas, alors que le fichier HFE marche sans souci. Idem pour la protection KBI-19.....

la déduction est simple : c'est lié à la représentation des données, qui est non fonctionnelle sur une vraie machine.

Les pistes speedlock sont des pistes entières, composées d'un secteur de 512 octets suivi d'une grosse zone GAP de 5870 octets, et non des secteurs de 6k comme représenté dans les fichiers DSK.

Quelque chose me dit qu'utiliser pour les logiciels protégés le format HFE ou IPF éventuellement, ce serait pas un mal.
Auteur :  breiztiger [ 06 Mai 2018, 09:51 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
comme te le fait remarquer edouard,

cela montre juste que le firmware actuel ne sait pas lire les "grosses" pistes

il suffit de voir que disco te donne une piste non formatte sur la kbi 19 en dsk
Auteur :  dlfrsilver [ 06 Mai 2018, 13:55 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
breiztiger a écrit :
comme te le fait remarquer edouard,

cela montre juste que le firmware actuel ne sait pas lire les "grosses" pistes

il suffit de voir que disco te donne une piste non formatte sur la kbi 19 en dsk


Que le firmware ai besoin d'une mise au point supplémentaire je dis pas. Mais déjà, rien qu'un jeu comme zap'the'balls, qui a été écrit en secteur sur CPC, ne passe pas alors qu'il n'y a pas de bizarreries sur les pistes.

Concernant la KBI-19, elle ne peut pas être reproduite fidèlement dans le format DSK. J'en ai déjà parlé avec le créateur de Samdisk, on ne peut avoir en mode sectoriel qu'une approximation. L'autre point étant que tout ce qui manque au format DSK doit être traité par le firmware, ce qui rend les choses beaucoup plus compliquées.

Comme édouard l'a vu, en format HFE, qui respecte le format original, ça passe comme une lettre à la poste.
Auteur :  Megachur [ 06 Mai 2018, 17:57 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Hello,

Si vous parlez de flashcopy pour Gotek, j'ai été récemment en contact avec l'auteur pour qu'il implémente le format eDSK... Cependant, même s'il l'a déjà bcp amélioré, il ne gère pas encore toutes les bizarreries de ce format en vue Secteurs !
En HFE, ipf, ou CTRaw, on a pas du tout c'est problème car c'est une vue piste et keirf en connait quelque chose ;-) cf son repository sur github avec le dernier firmware qui améliore encore la prise en compte du format edSK : https://github.com/keirf!

Afin, de permettre à nos dumpers favoris et au meilleur d'entre eux, j'ai créé un petit utilitaire spécial contrôle de dump (et d'émulateur de fdc) pompeusement appelé : << Dlfrsilver Dump Tool Test Suite v1805 >>

cela fait un moment que je pensai à un tel outil, j'avais même fait un tout en assembleur, mais compliquer de faire toute l'interface en asm... du coup, interface en basic puis le reste en asm : j'en ai profiter pour récrire mon manager fdc pour qu'il traite toutes les commandes "read a track", scan, etc et voilà !

L'utilisation est simple : on saisit exactement les commandes fdc comme sur le loader et on peut comparer le disque original et la copie !!!

J'ai implémenté toutes les commandes du fdc, attention aux commandes format et write !!! c'est un utilitaire pour personne avertie qui savent ce qu'elles font -> protection écriture disquette originale obligatoire !!!
Il y a notamment la fonction "scan equal" qui est implémentée et qui est très pratique pour comparer un secteur lu en mémoire avec un autre sur un autre disquette (la copie) !

Bien sûr, on pourra s'en servir aussi pour rendre les émulateurs (partie fdc) bcp plus proche de la réalité, n'hésitez pas à me faire des retours par rapport au mien CPCEPower !

Exemple avec Sly Spy :

on lance run"fdctest et on mets le disque sly spy en A (si on le mets en B le premier argument des commandes FDC devront finir par 1 pour indiquer qu'on lit sur le second lecteur)
cf la doc fdc 765 ;) !

lecture du secteur effacé en piste 0 - secteur #c8 :

command 07 + entrée
param 00 + entrée

on va en piste 0

4c
00 00 00 c8 02 c8 2a ff

on lit le secteur effacé #c8

d pour le voir à l'écran
s pour sauvegarder les 512 bytes lus dans un fichier, exemple de nom b:sly00c8.bin pour le sauvegarder sur le disque b (vierge) qu'on avait mis au préalable !

on va en piste 1

0f
00 01

j'en profite pour rappeler que les commandes calibrate et seek n'ont pas de phase de résultat, mais que quand ces commandes sont exécutées, je lance un sense interrupt status afin d'afficher si elles se sont bien terminées...
résult= 20 01
on y est

4a
00

pour afficher les infos : 00 00 00 01 00 c1 06

on lit le secteur comme le loader original le secteur de taille 06
4c
00 01 00 c1 06 c1 2a ff

sur la question ensuite : on indique qu'on veut pas lire la taille du secteur indiqué : 06 (2^(7+6)) = 8192 octets
mais on indique 6304 ou &18a0 pour dire qu'on en veut moins !

en fait techniquement, je passe les bon args au fdc donc il va tout lire le secteur avec un taille de 8192 octets - c'est bien fdc, tu fais toujours ce qu'on te demande !!!
mais en affichage ou dans le fichier je prend bien en compte la taille indiquée !

Result=40 20 20 01 00 c1 06 00

d pour display (c'est un peu long)
ou
s pour save

et puis on change la disquette par le dump !

et on fait un control !

71
00 01 00 c1 06 c1 2a ff (c'est tout pareil)

et si on a un résultat en
--> allez, je vous laisse découvrir la réponse d'un vrai fdc sur le vrai hardware !!! :winner:

Enjoy en espérant que cela va vous être utile !

:biere:

Pièce jointe :
Dlfrsilver Dump Tool Test Suite v1805.dsk
Auteur :  dlfrsilver [ 06 Mai 2018, 19:36 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Salut :)

Oh lalala :mdr: excellente idée cet outil :magic:

Je suis flatté que tu ais mis mon pseudo, mais est-ce bien raisonnable :mdr: ?

De mon côté, je vais m'attaquer à l'encodage de la protection hexagon 18A0. Je vais prendre la définition présente pour l'hexagon 1800, et je vais la dupliquer pour définir le format Hexagon 18A0 dans le CTA.
Comme le format est pas trop compliqué, je devrais y arriver je pense :magic:

En tout cas, merci d'avoir rappelé qu'effectivement, le gros souci pour le FDC du CPC, c'est son incapacité à faire du write track..... Si on avait ça, on pourrait implémenter le mode piste dans le format DSK.

je testerais ton outil, voir ce qu'il donne :D
Auteur :  Lone [ 06 Mai 2018, 20:42 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
dlfrsilver a écrit :
Regarde la mention flux range : normalement on est sur une piste classique à 1,5x-1,6x us sur une piste normale, ici on est à 3,70.

La piste de Breitztiger fait 6ko tassé dans un espace de 3ko !

On ne le voit pas sur mon screen, mais le carré qui représente la piste est de couleur bleue. Quand la couleur est bleue, c'est qu'il y a utilisation de la variation de densité. Comme on utilise la variation ? Simple, au lieu de tracer en 2us, on trace à une valeur plus forte.
[...]
Aufit permet de voir la variation de densité : quand les pistes sont en vert, elles sont normales, quand elles sont en bleu, y a variation de densité. Soit plus de données écrites dans un espace réduit.


Hum, denis, on a pas la même interprétation des infos d'Aufit !

Pièce jointe :
aufit.jpg


"normal in blue" signifie plutôt "normal" ! En plus, c'est pas sur ce graph que l'on voit les durées de transitions.

Flux range ne peut pas être la taille d'un bitcell : 3.70 - 14.75.. Soit entre 185% et 700% la taille d'une cellule... On sort des tolérances du FDC là !

dlfrsilver a écrit :
Citer :
Par contre j'aimerais bien savoir ce qui te fait dire que l'on a deux index ?? Si je ne me trompe pas, le trou d'index est unique pour la disquette (et non un par piste) ?


Regarde les rectangles verticaux en rouge. C'est la première fois que je vois de ma vie sur une protection Amstrad CPC (et même Atari ST ou PC), une piste de protection, avec 2 zones de trou d'index !

Normalement, toutes les pistes qu'on a vu ici n'en ont qu'un seul ! Ici cette piste de protection a été crée en 2 passes, la première pour le petit secteur, et la seconde pour le reste de la piste.

C'est tellement pas courant que ça saute aux yeux !


Euh.... Denis... Les traits rouges indiquent les fameux pattern de début de secteur (un pour le header, un pour les datas)
Exemple : Bubble ghost :
Pièce jointe :
aufit_2.jpg

Là, on a pas neuf trous d'index ! Note également que les traits rouges correspondent bien aux début de header/data de chaque secteur
Si tu parles de la zones en bas, ça indique juste des secteurs avec CRC en erreur.

dlfrsilver a écrit :
Citer :
Pour la protection elle-même, c'est assez marrant : Ca consiste à lire une piste fictive de grande taille, qui oblige donc à relire le début de la disquette (sur une piste, qui fait 6ko max, lire 9ko va obliger à lire deux fois la même chose, au moins sur 3ko, en faisant le "tour" de la disquette).


Moi j'ai un souci avec la représentation faite par samdisk. Celle-ci est incorrecte. Le petit secteur suivant par sa zone gap est en 1er, et le secteur avec la grosse zone GAP est en second.

Hors, dans le DSK qu'on peut générer, le secteur avec la grosse zone GAP est en premier, et le secteur avec la zone GAP plus petite arrive après, c'est pas normal.


Le DSK n'est pas parfait. Il ne représente de toute façon que ce que le FDC va retourner en lecture piste (avec une info de positionnement potentiellement). En général, pour les grosses tailles, c'est d'ailleurs tronqué, la plupart du temps à ce qui est nécessaire au programme qui utilise la disquette.
Son gros intérêt est malgré tout, qu'il permet de retrouver les infos que l'on veut, voir de reconstituer une vrai piste, avec un manque de précision dans certain cas, mais la plupart du temps ce manque de précision n'est pas gênant (pour une utilisation basique, bien sûr )

dlfrsilver a écrit :
Le kryoflux peut tout écrire, mais il faut que les données soient correctement implémentées.

en tout cas, chapeau au mec qui a pondu, mis au point cette cochonnerie, ça requiert du matériel capable de tracer avec précision une piste sur une durée donnée, d'une certaine taille, et de venir mettre à la suite une seconde piste en fait ahahah :D


Impossible sur ces dumps : Lance le, ça sent le mec artisan du soft dans son patelin. Ca m'étonnerait qu'il soit équipé, ou même qu'il ait accès à un équipement de pointe... Surtout dans les années 80 !
Faudrait tenter de le retrouver d'ailleurs, j'aimerais bien avoir le fin mot de l'histoire...

Pour le kryoflux et l'écriture parfait de la piste, je ne demande qu'à te croire...
Auteur :  dlfrsilver [ 06 Mai 2018, 22:35 ]
Sujet du message :  Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Citer :
Hum, denis, on a pas la même interprétation des infos d'Aufit !


Oui on dirait. Mais j'insiste, "Flux range" en anglais ne veut pas dire durée de transitions, mais "plage de flux" ou "plage de débit" !

Les mots ont un sens !

Citer :
"normal in blue" signifie plutôt "normal" ! En plus, c'est pas sur ce graph que l'on voit les durées de transitions.

Flux range ne peut pas être la taille d'un bitcell : 3.70 - 14.75.. Soit entre 185% et 700% la taille d'une cellule... On sort des tolérances du FDC là !


Rahh putaaainnn je suis pas en train de te parler du bleu du tracé des pistes, mais de la couleurs des carrés des pistes plus haut !

En vert : Pistes normales, en orange : Piste avec données par dessus l'index et bleu : variation de densité !

pour la protection réussir, charge le dump ou la piste kryoflux lourde dans outil, puis clique sur DATA VIEW, puis sur TRACK en bas.

Tu vas voir ceci :

S:\Dump Philippe Depre.raw
Track 38.0 6220 bytes Length 199977 µs
START Bit=0 Byte=0 Time=0,00 ms
LENGTH Bit=112989 Byte=6220 Time=199977,64 µs

Tu vois la longueur en bits de la piste de protection ? 112989 ! soit environ 14123 octets MFM soit une piste décodée de 7ko !

Tu lis quoi juste après ? La piste fait 6220 octets. Donc on a 7ko de données tassées dans un espace permettant de contenir en gros 6ko de données. On fait varier la densité pour écrire plus données dans un même espace, ceci pour empêcher un lecteur normal de réécrire ces pistes.

Quand au carré bleu le voilà :

Pièce jointe :
Reussir Conjugaison_face _a_track38.0.raw.jpg


Citer :
Par contre j'aimerais bien savoir ce qui te fait dire que l'on a deux index ?? Si je ne me trompe pas, le trou d'index est unique pour la disquette (et non un par piste) ?


Effectivement, je me suis planté là dessus.

Citer :
Le DSK n'est pas parfait. Il ne représente de toute façon que ce que le FDC va retourner en lecture piste (avec une info de positionnement potentiellement). En général, pour les grosses tailles, c'est d'ailleurs tronqué, la plupart du temps à ce qui est nécessaire au programme qui utilise la disquette.
Son gros intérêt est malgré tout, qu'il permet de retrouver les infos que l'on veut, voir de reconstituer une vrai piste, avec un manque de précision dans certain cas, mais la plupart du temps ce manque de précision n'est pas gênant (pour une utilisation basique, bien sûr )


Oui mais ici, ça ne fonctionne pas. la protection du logiciel réussir fait déconner à plein tube les émulateurs, il y a nécessairement une raison !

Il faudrait déjà essayer de stocker correctement la piste dans le DSK, et voir ce que ça donne.

Citer :
Impossible sur ces dumps : Lance le, ça sent le mec artisan du soft dans son patelin. Ca m'étonnerait qu'il soit équipé, ou même qu'il ait accès à un équipement de pointe... Surtout dans les années 80 ! Faudrait tenter de le retrouver d'ailleurs, j'aimerais bien avoir le fin mot de l'histoire...


Le logiciel pète pas trois pattes à un canard, on est d'accord. Par contre, la piste de protection a été crée sur une machine de duplication. Un CPC est incapable de générer ce genre de piste qui ressemble salement comme je le disais dans le principe aux pistes speedlock et hexagon.

Citer :
Pour le kryoflux et l'écriture parfait de la piste, je ne demande qu'à te croire...


C'est le cas. En fait, pour dire les choses clairement, j'ai entendu de la part d'une personne qui a participé au financement de la carte kryoflux (à hauteur de 30000 euros si ma mémoire me fait pas défaut), qu'en fait, le contrôleur custom de la carte kryo basiquement, c'est Paula, le FDC de l'Amiga, mais sans aucune limite en écriture. Le FDC de l'Amiga était le plus puissant de toutes les machines de l'époque.... Avec tu peux sans aucun souci graver pour n'importe quelle plateforme tant que le format du disque est décrit.

La limite concernant le format IPF, c'est que pour faire un master sur disque 100% niquel, conforme et fonctionnel, le format à encoder doit être défini, pour que le contrôleur sache comment écrire.
Page 117 sur 138 Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/