<meta name="KEYWORDS" content="HACK Z APPLE, JPL, Cracking, Hacking, DISK II, DRIVES, DISQUETTES, Collection APPLE II, APPLE, Apple II, APPLE II Plus, 2+, Europlus, 2e, //e, enhanced, Platinium, Stealth, Cortland, GS, IIGS, WOZ, IIGS WOZ, ROM 0, ROM 1, ROM 4, IIc, IIc Plus,Apple III, LISA, MAC XL, DARK VADOR, ITT 2020, APPLE BF,APPLE REV0, REVISION 0, RFI, NON RFI">
<meta name="TITLE" content="Apple II standard">
<meta name="OWNER" content="HACKZAPPLE.COM">
<meta name="SUBJECT" content="Collection Apple II">
<TR> <TD COLSPAN="3" valign="TOP" > <img src="../THEMAS/M3/XDISK7C.PNG" BORDER=0></TD> </TR>
<TR> <TD COLSPAN="5" CLASS="PARAG1K">
Le test de protection de la disquette contre l'Θcriture est une opΘration OBLIGATOIRE avant d'Θcrire mais ce n'est pas
pour vΘrifier simplement qu'il y a ou non un notch, cela permet Θgalement deux choses importantes :<BR>
<IMG SRC="../THEMAS/DIVERS/BULLET.GIF"> d'une part cela fait un reset de QA<BR>
<IMG SRC="../THEMAS/DIVERS/BULLET.GIF"> d'autre part cela positionne le LSS α la sΘquence 0 ce qui est la seule mΘthode pour un programme 6502 de connaεtre la
position du LSS et de pouvoir gΘrer ensuite son timing en 32 cycles (dont l'explication suit)
<BR><BR>
Voici le tableau du code prΘsentΘ selon la mΘthode de Jim Sather et qui permet de bien comprendre comment cela
fonctionne.
<BR><BR>
<CENTER><IMG SRC="LSSW1.PNG"></CENTER>
<BR><BR>
Comme nous l'avons dΘjα expliquΘ le tableau PULSE et NO PULSE sont identiques car que le LSS reτoive ou non des PULSE,
il doit les ignorer puisqu'il s'agit d'Θcrire sur la disquette et que l'on va rΘorienter les champs magnΘtiques.
Concentrons nous donc sur le systΦme de l'un d'eux seulement car la navigation entre les colonnes selon la rΘception
ou non des PULSES n'a ici absolument aucun intΘrΩt.
<BR><BR>
Ce qui a un interΩt particulier c'est la faτon dont se passe le chargement du DATA REGISTER par rapport α l'Θtat du LSS
et donc comment ce dernier travaille avec les opΘrations SHIFT et LOAD
<BR><BR>
L'opΘration SHIFT consiste α Θcrire bit par bit, le nibble contenu dans DATA REGISTER, sur la disquette, on remarque
donc que le LSS procΘde simplement α des dΘcalages avec l'instruction SL0 faisant ainsi passer successivement tous
les bits b6 α b0 par position de b7 qui correspond α QA actif si le bit est α 1 et QA inactif si le bit est α 0.
Le DATA REGISTER prend donc un certain nombre de valeur jusqu'α contenir $00.
<BR><BR>
Vous n'Ωtes pas sans remarquer que d'une opΘration SL0 α l'autre il y a TOUJOURS et PRECISEMENT 8 sΘquences. Ce n'est pas
un hasard : nous avons vu que le LSS fonctionne α 2mhz, 8 sΘquences correspondent donc α 4 cycles CPU soit 4╡s...exactement
le dΘlai de la fenΩtre d'Θcriture d'un bit ce qui pour 8 bits fera donc 4*8=32 cycles !
<BR><BR>
Maintenant vous comprenez pourquoi le programme 6502 doit maintenir 32 cycles entre deux opΘrations de chargement : c'est
pour laisser le temps au LSS d'Θcrire le nibble correctement. Mais vous comprennez Θgalement que si vous ne
rechargez pas le DATA REGISTER dΦs les 32 cycles ΘcoulΘs, celui-ci contiendra des 0 qui seront alors "shiftΘs"
toutes les 8 sΘquences donc tous les 4╡s CAR ON RESTE DANS LA BOUCLE DE L'OPERATION SHIFT... c'est ainsi que sont
Θcrits les bits de synchronisation : en ayant une routine α 36 ou 40 cycles selon que l'on veut 1 ou 2 extra-bits
de synchronisation.
<BR><BR>
Pourquoi donc avoir Θcrit ce code en 16 sΘquences ? Certes pas pour vous ennuyer mais le changement de signal se fait
lors du passage de la sΘquence 7 α la sΘquence 8 ce qui permet donc d'Θcrire des 1 chaque fois que l'on passe de l'une
α l'autre. Par ailleurs en liaison avec la suite des sΘquences pour le chargement cela permet d'avoir un chargement du
DATA REGISTER aussi bien derriΦre un 1 que derriΦre un 0, ce qui est assez heureux !
<BR><BR>
Voici le code d'Θcriture reprΘsentΘ α nouveau sous la forme d'une machine α Θtat, ce qui permet de comprendre le
dΘroulement des sΘquences selon que le bit 7 QA soit α 1 ou α 0.
<BR><BR>
<CENTER><IMG SRC="LSS02A.PNG"></CENTER>
<BR><BR>
On notera :<BR>
<IMG SRC="../THEMAS/DIVERS/BULLET.GIF"> que l'opΘration LOAD boucle en infini si le bit 7 n'est pas α 1 et n'Θcrit RIEN
alors que normalement elle devrait bien passer par les sΘquences 7/8 pour Θcrire le MSB α 1!. <BR>
<IMG SRC="../THEMAS/DIVERS/BULLET.GIF"> que l'on peut parfaitement Θcrire les nibbles en chargeant le DATA REGISTER
lors des multiples d'Θcriture de 4 cycles CPU (8,16, 20, 24, 28, 32).
Il est clair que le DOS charge tous les 32 cycles... mais si vous deviez Θcrire un schΘma de protection bien
particuliΦre, vous y trouveriez un grand avantage car cela permet d'insΘrer des 0 de faτon extrΩmement fiable.
