introduction
L'une des histoires de protection de disquettes les plus connues vient de Dungeon Master . Ce jeu, sorti en décembre 1987, combinait le format de disque physique sophistiqué (bits flous) avec des contrôles de sécurité cachés intégrés au gameplay lui-même.
Je recommande de lire cet article , qui fournit un excellent aperçu des disquettes, suivi d'un aperçu très détaillé de la protection des bits flous Dungeon Master pour l'Atari ST. Il y a aussi cet excellent article qui entre plus en détail sur les histoires entourant la défense du maître du donjon. Il a une citation de l'un des auteurs de Dungeon Master:
« , , 40 . , ».
La raison de ce prix élevé était très probablement due à la précision de synchronisation requise pour créer de manière fiable des bits flous. À l'époque où la plupart des pays du monde mesuraient les performances en microsecondes, la précision requise était mesurée en nanosecondes.
Le BBC Micro avait un processeur 6502 à 2 MHz et a pris deux cycles d'horloge, soit 1 microseconde, pour exécuter ses instructions les plus simples. Y a-t-il un espoir qu'il sera possible d'écrire des bits flous sous de telles restrictions? Voyons jusqu'où nous pouvons aller. Ce travail sera appelé le «projet de la loutre mazoutée».
Pour vous donner une idée de l'air du temps, voici une image d'un duplicateur de disquettes de 3,5 ". C'est incroyable à quel point il est similaire à un photocopieur, sauf que vous insérez des disques dans le réceptacle au lieu de papier! On dirait qu'Advanced World Products pourrait même vous avoir vendu une telle machine .
Port personnalisé BBC Micro
BBC Micro était connu pour son excellente extensibilité, notamment via le soi-disant «port utilisateur». Ce port est contrôlé par l' adaptateur d'interface polyvalent 6522 fonctionnant à 1 MHz. Le port lui-même a 8 broches de données et 2 broches de contrôle. Ces contacts ont fourni un très haut degré de contrôle. Les broches de données peuvent être configurées individuellement en tant qu'entrées et sorties, et les niveaux de broches logiques peuvent être réglés sur haut ou bas.
Pourquoi le port utilisateur est-il important pour nous? Nous allons essayer de contrôler le lecteur de disque directement à travers lui. En supprimant le contrôleur de disquette de l'équation, nous pourrons peut-être nous en débarrasser et obtenir un contrôle plus direct sur le lecteur de disque et les flux de données transférés.
Port utilisateur vers lecteur de disque
L'image ci-dessus montre mon câble reliant le port utilisateur au lecteur de disque. Les connecteurs sont standard et les fils qui les relient ne sont que des cavaliers. Je m'efforce sincèrement de créer quelque chose qui pourrait être fait «à l'époque», donc je n'utilise pas d'électronique supplémentaire.
Le câble est disposé comme suit:
Le principal point à retenir de ce diagramme est que l'interface du lecteur de disque est probablement plus simple qu'on pourrait le penser. Nous pouvons contrôler le lecteur de disque et interroger son statut important sur seulement 8 broches. Tout est très simple. Disons que nous devons faire tourner le lecteur, puis il suffit de donner un signal bas à PB0 et PB1. Si vous voulez attendre que le disque tourne au début de la piste, alors vous devez interroger le niveau logique sur PB6 jusqu'à ce que nous voyions le niveau du signal changer de haut en bas. Pour un mouvement pas à pas, il suffit de régler le niveau logique «step in» opposé à «step out», puis d'effectuer une pulsation d'un signal bas sur le contact «step».
Jusqu'ici tout va bien, nous avons un contrôle de base sur le lecteur, mais nous n'avons encore rien enregistré.
Problèmes électriques
Une courte digression sur les problèmes électriques est impérative, car je les ai rencontrés. La connexion de paires aléatoires de composants peut les faire fonctionner, mais des ajustements sont parfois nécessaires. Voici la plage de tension initialement observée au niveau de la broche W / DATA du variateur:
Nous essayons d'écrire des impulsions sur un variateur avec une fréquence FM de 250 kHz.
La tension logique 1 est d'environ 3,4 V et la tension logique 0 est d'environ 1,5 V. C'est un problème sérieux! Les niveaux de tension TTL acceptables sont bien définis:
«Le signal d'entrée TTL est considéré comme« faible »s'il a une tension entre 0 V et 0,8 V par rapport à la broche de masse, et est« haut »lorsqu'il est compris entre 2 V et VCC (5 V). Si un signal de tension dans la plage de 0,8 V à 2,0 V est appliqué à l'entrée d'un élément TTL, alors l'élément ne donne pas de réponse spécifique, et par conséquent le signal est considéré comme "indéfini". "
Une tension logique 0 de 1,5 V est considérée comme "indéfinie" et ne provoquera aucune action. En effet, mon lecteur n'enregistrait rien avec ce signal.
Le problème a été résolu en retirant le câble du lecteur de disquette EOL du lecteur . Voici une photo de mon lecteur avec l'assemblage EOL souligné en rouge:
Cela résout bien le problème des niveaux de tension, après quoi tout fonctionne. Il semble que de nombreux ports du BBC Micro autres que le port de disque ne disposent pas de suffisamment de puissance pour piloter le câble EOL. Mais attendez - il y avait probablement une raison pour installer cette résistance? Oui. Le supprimer comporte deux astuces:
- Faites attention à la longueur des câbles. Sans résistance EOL, les longs câbles sont sujets à la distorsion du signal.
- Surveillez les niveaux de tension sur les fils non connectés. J'ai observé une tension de 1,32 V sur la broche de l'actionneur S / SEL (sélection latérale). Ce n'est pas normal car cette valeur se situe également dans la plage d'incertitude TTL. Où le lecteur écrira-t-il les données? Peut-être en haut, peut-être en bas. Ou peut-être aucun d'entre eux! Le problème a été résolu en connectant chaque câble significatif et en leur appliquant un signal haut ou bas.
Besoin d'augmenter la bande passante
Le problème que nous avons contourné jusqu'à présent: comment envoyer un signal à la broche W / DATA? C'est un contact "dur". Il a une bande passante élevée et des exigences de synchronisation précises. Arrêtons de rêver de bits flous avec une précision à la nanoseconde pendant une seconde et essayons d'écrire de simples impulsions FM sur le lecteur.
La plupart des disques pour BBC Micro sont en FM (alias DFM, alias simple densité) encodés à 250 kHz. L'enregistrement d'une piste FM est en fait assez simple. Il est nécessaire de vérifier si le lecteur tourne et si le volet d'enregistrement est ouvert. Après cela, toutes les 4 microsecondes, soit nous effectuons une pulsation W / DATA vers le bas, puis revenons au signal haut (bit 1), soit nous ne le faisons pas (bit 0). Le plus souvent, un bit sur deux doit être égal à 1 (bit de synchronisation pour maintenir la synchronisation et la synchronisation).
Contrôler W / DATA via un processeur est une tâche sans espoir. 4 microsecondes correspondent à 8 cycles d'horloge du processeur; ce n'est certainement pas suffisant pour charger un octet, le décaler, écrire 0, puis 1 aux niveaux logiques du port utilisateur. Un cycle simple prendra probablement plus de 12 microsecondes, ce qui est trop. Donc, pour écrire W / DATA assez rapidement, nous devrons utiliser les capacités de la puce 6522 VIA.
Registre à décalage 6522 VIA
Le candidat le plus évident pour notre tâche est un registre à décalage. Le registre à décalage est un registre à 8 bits. Dans le mode correspondant, le chargement du registre à décalage forcera la puce à transmettre séquentiellement 8 bits sur l'une des broches du port utilisateur. C'est génial - les bits sont traités en parallèle avec le processeur principal, de sorte que le processeur peut passer du temps en toute sécurité à créer un nouvel ensemble de bits pour commencer à se déplacer.
Malheureusement, je n'ai pas pu faire fonctionner ce circuit. Le seul mode de décalage qui a le potentiel de fonctionner raisonnablement rapidement est le «décalage d'horloge système». Les spécifications du Western Design Center 6522 ont un joli contour:
L'horloge du système VIA est de 1 MHz, donc l'horloge de décalage sera de 500 kHz et la résolution de bits de sortie est de 250 kHz. C'est juste assez. Cependant, je n'ai pas compris comment faire fonctionner l'horloge de travail en continu et en douceur. Même après avoir essayé une synchronisation précise pour recharger le registre à décalage, l'intervalle de broche de l'horloge à décalage ressemblait toujours à ceci:
Il s'avère que dans un mode de décalage simple assez rapide pour nos expériences, le rechargement du registre à décalage provoque un retard avant de continuer le décalage. Cela ne nous convient pas.
6522 Mode de sortie d'impulsion VIA
Une caractéristique peu connue du 6522 est son "mode de sortie d'impulsion". Il n'est pas décrit dans les spécifications de toutes les variantes 6522, mais voici une petite entrée à ce sujet dans la spécification de la technologie MOS :
Nous avons enfin trouvé une spécification qui décrit avec précision son comportement. Ce mode est très intéressant pour nous, car une opération d'écriture dans VIA promet de conduire à deux actions distinctes: un signal logique bas est appliqué à la broche de sortie, et après 1 horloge (1 microseconde) il revient à un signal haut sans effort de notre part. Grâce à cela, nous pouvons l' utiliser pour piloter le signal de sortie de 250 kHz. Les ressources du processeur sont très limitées - la boucle ne résoudra en aucun cas le problème, mais le bloc de code linéaire 6502 pourra faire face, par exemple:
\ &70 points to &FE60, aka. user 6522 VIA ORB register.
STA (&70),Y \ 8 cycles, pulse output
STA (&70),Y \ 8 cycles, pulse output
STA (&70),Y \ 8 cycles, pulse output
LDA (&70),Y \ 8 cycles, do not pulse output
STA (&70),Y \ 8 cycles, pulse output
...Ça va marcher. Le processeur a juste assez de puissance pour cela. 8 cycles d'horloge correspondent à 4 microsecondes, soit le temps le plus court entre les impulsions du disque.
Malheureusement, une telle opération est extrêmementutilise activement la mémoire. Chaque bit FM codé nécessite 2 octets de code de ligne 6502. Chaque bit de données significatif est de deux bits FM car tous les autres bits sont synchronisés. Une piste mesure 3125 octets, donc 3125 * 8 * 2 * 2 == 100 Ko de code de ligne sont nécessaires. Le BBC Micro a 32 Ko de RAM, nous n'avons donc pas de chance ici. Des (petits) secteurs uniques peuvent être écrits, y compris de nouveaux mécanismes puissants de protection de disque. Mais nous ne pourrons pas écrire de grands secteurs (1024 octets) ou des pistes complètes. Ces deux opérations sont nécessaires pour graver correctement un grand nombre de disques. De plus, la résolution de synchronisation est de 1 microseconde, ce qui n'est pas suffisant pour enregistrer de nombreuses protections et surfaces de disque plus complexes.
Nous pouvons être heureux d'avoir réussi à faire fonctionner au moins quelque chose, compte tenu de ces restrictions, mais cette solution ne nous convient pas tout à fait.
Aide d'un port de sortie non prometteur
Heureusement, je parle à des gens intelligents comme le collectif Bitshifters . (Allez voir leur dernière démo, Evil Influences !) Dans une conversation sur Slack, Tom Seddon (auteur de l'émulateur b2 ) a suggéré ... d'utiliser la sortie du port RVB (?)
Câble adaptateur vidéo-disque ... vous ne voyez pas cela sur Amazon tous les jours.
Au début, j'ai ri de cette idée, mais plus j'y pensais, plus elle me semblait probable. Le BBC Micro utilise la puce vidéo 6845 pour les minutages . Comme le 6522, c'est un processeur de mauvaise humeur , mais au moins ses fonctionnalités sont bien déchiffrées grâce à la démo de Bitshifters qui exploite impitoyablement le 6845. J'ai également fait du reverse engineering pour forcer l'émulateur jsbeebémuler correctement Hitachi 6845. Jetons un coup d'œil au travail de Oiled Otter dans cette vidéo, puis disons-nous ce que nous avons vu:
Tout fonctionne grâce à la configuration inhabituelle de la puce 6845. Le 6845 fonctionne à 1 MHz, et le cadencement des trames est réglé pour avoir une ligne raster à 32 microsecondes / 32 octets par «trame». Sur chaque sortie de trame, les registres de mémoire vidéo du 6845 sont écrasés pour récupérer les 32 octets suivants à partir d'un emplacement potentiellement différent. Autrement dit, toutes les 32 microsecondes, un modèle de sortie différent est sélectionné dans la table de modèles de sortie. Nous avons configuré les broches RVB pour transmettre 8 pixels par microseconde, soit 256 par modèle de sortie. Cela nous donne un grand nombre de modèles de sortie possibles. Mais comme nous enregistrons des morceaux de 32 microsecondes d'encodages de disques FM, seuls quelques modèles nous conviennent. En 32 microsecondes, nous pouvons adapter 8 impulsions / bits FM. 4 bits seront synchronisés et sont généralement tous 1.4 bits seront des bits de données et il n'y en a que 16 combinaisons.
Par exemple, si nous écrivons un quartet de données 0x5, la sortie de 32 microsecondes devrait ressembler à ceci:
Les données vidéo seront au format 00FFFFFFFFFFFFFF00FFFFFF00FFFFFF00FFFFFFFFFFFFFF00FFFFFF00FFFFFF. Les premier, deuxième, quatrième et cinquième 00 sont des bits de synchronisation. Entre les bits de synchronisation se trouve le modèle de bits de données 0101 ou 0x5.
Les contraintes de processeur et de mémoire sont bien équilibrées. En fin de compte, ce circuit est similaire à celui que nous essayerions avec le registre à décalage VIA si cela fonctionnait: un petit coprocesseur (puce vidéo) gère le transfert de l'ensemble de bits FM, et le processeur central est libre de charger et de fournir le modèle suivant. Les besoins en mémoire sont tout à fait raisonnables. Un tableau des fragments de sortie requis pendant 32 microsecondes, grâce à un mode d'adressage linéaire spécial, tient bien dans 1024 octets. La liste des index de recherche pour l'ensemble de la piste est d'environ 12 Ko, donc tout s'intègre parfaitement dans les 32 Ko de RAM de BBC Micro.
Caractéristiques de BBC Micro / 6845
Dernier caractère / colonne 6845
Bien sûr, pour que cela fonctionne, vous devez rencontrer des bizarreries "amusantes". La première est une fonctionnalité du 6845, qui le fait sortir du noir pour le dernier caractère de chaque ligne bitmap. C'est la malédiction des développeurs de démos, et maintenant il semble, les chercheurs de disques aussi. Voici une diapositive d'une récente conférence dans laquelle j'ai démontré ce problème:
Sur la gauche se trouve un effet de la démo, gâché par des barres verticales noires provoquées par le problème du "dernier caractère / colonne noir". Plusieurs 6845 lignes raster tiennent en une seule passe raster et, malheureusement, des bandes noires apparaissent involontairement. Avec le contrôle du disque, l'effet est bien pire: les barres noires sont remplacées par des impulsions indésirables, qui sont écrites sur le disque.
L'image de la solution est représentée à droite: l'onde transmise au disque est simplement inversée. Il est maintenant normal que la dernière colonne soit toujours noire (représentée avec un contour orange), car un zéro y est toujours requis. Strictement parlant, cela viole les exigences de synchronisation de certains lecteurs de disque pour émettre des signaux W / DATA faibles. Voici un diagramme de la synchronisation d'un lecteur de cette époque, Mitsubishi M4852 / M4853 :
Selon ce schéma, la logique 0 doit être maintenue jusqu'à 2100 ns. Avec une forme d'onde inversée, attendez 3000 ns ou plus. Cependant, les lecteurs que je possède ne concernent que la chute des impulsions de données, pas leur durée. Cela n’a rien d’étonnant. J'aurais pu faire quelques astuces pour éviter les bizarreries du 6845 et m'assurer que les durées sont conformes aux spécifications, mais cela s'est avéré inutile, alors je ne l'ai pas fait.
DRAM
corruption DRAM decay est un cauchemar. Cela se produit lorsque nous ne parvenons pas à mettre à jour la DRAM à temps. Citant l'article de Wikipédia sur la mise à jour de la mémoire :
"Ce processus est effectué automatiquement en arrière-plan par un circuit de mémoire électronique et est invisible pour l'utilisateur."
Cela est vrai pour les systèmes modernes, mais pas pour le BBC Micro. Sur BBC Micro, la mise à niveau DRAM est un effet secondaire du sous-système vidéo. Il exploite la propriété que les modes d'écran standard itèrent de manière itérative sur toutes les lignes DRAM en un court laps de temps. Vous avez probablement déjà deviné où cela va - notre mode vidéo spécial, utilisé pour produire des images à 32 microsecondes, n'est pas le mode d'écran standard. Il ne garantit pas qu'il contournera toutes les lignes DRAM, donc une corruption DRAM se produit! La corruption DRAM n'est pas une blague. En raison d'une corruption de DRAM imprévue, je perdais divers programmes et contenu de disque. Je vais vous montrer, pour rire, un programme BASIC qui corrompt la DRAM pour elle-même en une fraction de seconde:
Le plus triste à propos de la corruption DRAM est que si cela vous arrive, vous pouvez facilement perdre des données.
D'un autre côté, si vous prévoyez une corruption de DRAM, vous pouvez généralement la contourner facilement. Dans le cas de la loutre huilée, il existe divers cycles critiques où le 6845 est dans un état inhabituel. Pour enregistrer la mise à jour DRAM à chacun de ces cycles, un incrément manuel de récupération des données de la mémoire fonctionne.
Opportunités ouvertes
Maintenant que nous avons un système d'écriture sur disque qui fonctionne en contournant le contrôleur de disquette, que pouvons-nous en faire? Dans la vidéo ci-dessus, nous avons déjà démontré sa capacité à graver des disques encodés en FM au hasard.
Mais dans cette étude, nous avons eu beaucoup de chance. En raison des lacunes du registre à décalage VIA, nous avons dû chercher une solution avec des broches de sortie vidéo, et nous avons eu accès à une résolution beaucoup plus fine des timings sur la broche W / DATA . Nous utilisons le MODE4 d'un ordinateur BBC Micro utilisant une horloge pixel de 8 MHz. Cela signifie que vous pouvez générer des pixels noirs ou blancs toutes les 125 ns en commutant les impulsions d'écriture avec une résolution de 125 ns... Si nous voulions dépenser un peu plus de mémoire supplémentaire (que nous avons) sur des tables plus grandes, nous pourrions utiliser MODE0, qui utilise une horloge pixel de 16 MHz, qui fournit une résolution de 62,5 ns. Je me suis assuré que 125ns est assez bon pour toutes les protections de disque testées, mais c'est génial que nous ayons encore une marge de manœuvre.
Protection longue piste
Ma protection de disque préférée est la protection longue piste. Elle était populaire pendant l'Amiga... Je ne pense pas qu'il ait jamais été utilisé sur le BBC Micro. J'aime la protection longue piste car elle est très fondamentale: le contrôleur de disquette a beaucoup de tolérance pour les vitesses d'écriture variables (car les lecteurs de disque tournent à des vitesses différentes), mais il n'écrit qu'à une vitesse correcte.
Une protection plus complexe avec de longues pistes consiste à écrire deux secteurs sur une piste, dans laquelle l'un des secteurs est écrit à une vitesse plus élevée. Le contrôle de la protection contre la copie correspond au temps nécessaire pour lire ces deux secteurs. Un secteur écrit à une vitesse plus rapide devrait être lu beaucoup plus rapidement.
Oiled Otter peut-il enregistrer une telle piste? Oui, et assez facile. Compte tenu de la résolution de sortie de 125 ns, il est facile de créer plusieurs entrées de table de sortie similaires à la normale, mais avec 125 nanosecondes coupées chaque microseconde. Voici une vidéo sur la création d'une protection longue piste et la vérification des lectures de disque:
Protection avec des bits flous
Il est probablement grand temps pour nous de revenir là où nous avons commencé: la protection avec des bits flous. Oiled Otter peut-il créer des bits flous sur du matériel de 1981? Essayons. Voici une image des résultats d'une paire de lectures de secteur après qu'elle a été écrite par la commande FUZZ du système Oiled Otter.
L'instruction FUZZ écrit le quartet 0x8 et le bit de données est progressivement mis de côté par incréments de 125 ns. Ceci est similaire à la description de la façon dont les bits flous du Dungeon Master ont été enregistrés. Comme vous pouvez le voir sur la capture d'écran, les octets de données 0x88 commencent bientôt à être lus de manière incorrecte et non déterministe. Mais la variance n'est pas 100% aléatoire comme les bits faibles - la variance est de savoir si le bit 0x8 est écrit suffisamment tard pour avoir une chance d'être manqué. S'il est omis, nous pouvons toujours voir qu'il y a des schémas et une logique dans cette folie.
Les résultats ci-dessus sont une application des principes de bits flous aux données codées FM. Dans le codage FM, chaque bit de données est entrelacé avec un bit de synchronisation. Cela conduit au fait que parfois les bits d'horloge se faufilent dans le flux de données (voir les octets 0xFF dans la première exécution - ce sont très probablement des bits d'horloge). La défense de Dungeon Master utilise des bits flous en conjonction avec MFM. Cela conduit à une situation plus simple où les bits flous se déplacent entre deux codages valides de bits de données et ne touchent pas les bits de synchronisation! Bien sûr, Oiled Otter peut écrire MFM, GCR et tout autre encodage auquel vous pouvez penser. Ce ne sont que des protocoles différents d'une primitive fondamentale - la capacité de transférer une impulsion vers le variateur à tout moment avec une bonne résolution.
Pour l'évaluer correctement, nous donnerons la forme de bits flous sur le disque à partir d'un oscilloscope. Les maxima sont assez inégaux, et lorsque les deux impulsions sont très proches l'une de l'autre (1 microseconde environ, trop proches par tout encodage standard), la force d'inversion de magnétisation reconnue par le variateur commence même à diminuer.
Mission accomplie
Nous avons pu enregistrer des impulsions de disque avec une résolution de 125 ns. Ceci est parfaitement suffisant pour créer des protections de disque complexes, y compris de longues pistes, des bits faibles et des bits flous. Pas mal pour le matériel de 1981 avec la vitesse de commande la plus rapide de 1 microseconde!
Voir Ă©galement: