<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">
<FONT COLOR=RED> <B>MAIS COMMENT CA MARCHE ?</B></FONT>
<HR color="RED">
<BR>
La lecture des bits sur la disquette se fait par groupe de 8. Immanquablement il y aura donc un moment ou certains de ces 0 se trouveront en tΩte de groupe
et ils seront ignorΘs (car le bit 7 doit OBLIGATOIREMENT Ωtre α 1), ce qui permet ainsi de rΘaliser de synchroniser la
lecture sur les valeurs ad hoc <FONT COLOR="RED">par "dΘrapage" de la lecture.</FONT> L'explication technique de ce "dΘrapage"
est donnΘe dans la rubrique<A HREF="DISKIITECH07B.HTM">"FONCTIONNEMENT DU LOGIC STATE SEQUENCER EN MODE READ"</A>
<BR><BR>
Le DATA REGISTER qui contient le nibble en cours de lecture n'a pas la bonne valeur immΘdiatement, la lecture est rapide mais
cela ne relΦve pas de la magie non plus : C'est la raison mΩme de l'instruction BPL que l'on trouve dans toutes les routines de lecture, cette instruction permet
ainsi d'Ωtre s√r que le nibble lu et prΘsent dans le registre de lecture commence bien par un 1.
<BR><BR>
En Θcrivant un nombre suffisant de ces nibbles de synchronisation, les valeurs cherchΘes pourront Ωtre retrouvΘes
et ce sont les routines de lecture qui vont devoir dΘterminer ce qu'il faut trouver... de lα ces merveilleux systΦmes
de protection qui Θcrivent des valeurs non standard pour empΩcher la copie. Voici donc la sΘquence normale de dΘtection des
<TR> <TD COLSPAN="5" CLASS="PARAG1"> Ci dessous on reprΘesente ce flux de nibbles dΘcomposΘs en bits.
Comme dit plus haut les nibbles de synchronisation sont Θcrits en 40 cycles c'est pourquoi ils ont toujours
les 2 zΘros (les extrabits) derriΦre les 8 bits reprΘsentant leur propre valeur qui, pour
d'Θvidentes raisons de simplification sont $FF soit 11111111. <BR><BR>Mais attention certaines protections, pour Θviter
que les programmes de copie "intelligents" (bitcopiers) trouvent le dΘbut de piste par dΘtection de ces $FF,
mettent d'autres valeurs Θcrites en 32 cycles, donc sans ces deux extrabits et lα le calcul de synchronisation devient
un tantinet moins simple.
<BR><BR>
<FONT COLOR=RED> Nota important : </FONT> DΦs que la synchronisation est obtenue, ELLE EST CONSERVEE JUSQU'A LA FIN
DE LA LECTURE de l'objet lu (entΩte d'adresse ou secteur). ELLE N'EST PERDUE QU'EN CAS D'ERREUR DE MAGNETISATION !!!
donc si votre disquette est abεmΘe.... o∙ si vous Ωtes sur une zone de recouvrement
(voir la rubrique <A HREF="DISKIITECH03.HTM">"format d'une disquette"</A>)
<BR><BR> <HR color="RED">
<FONT COLOR=RED> <B>EXPLICATION DETAILLEE DE LA SYNCHRONISATION PAR L'EXEMPLE</B></FONT>
<HR color="RED">
Il n'y a que 10 possibilitΘs pour commencer la lecture
Ci dessous vous avez donc le mΩme flux representΘ 10 fois, et sous chaque flux on montre ce qui se passe au niveau
de la lecture selon le premier bit lu par la tete de lecture. La ligne 1 c'est le cas ou la tete tombe immediatement sur le premier bit d'un octet de synchronisation,
il va sans dire que la synchronisation est immediate.
<BR><BR>
<IMG SRC="../THEMAS/DIVERS/BULLET.GIF"><B>les Θtoiles (*) sous les bits indiquent que le mode lecture n'a encore
pas commencΘ.</B> <BR> <BR>
<FONT COLOR="#40FF40">
Quand la lecture commence effectivement, elle se fait :<BR>
<IMG SRC="../THEMAS/DIVERS/BULLET2.GIF">soit par acceptation ("a" = acceptΘ) <BR>
<IMG SRC="../THEMAS/DIVERS/BULLET2.GIF">soit par ignorance ("I" = IgnorΘ) du bit rencontrΘ.
</FONT> <BR><BR>
<IMG SRC="../THEMAS/DIVERS/BULLET.GIF">En rouge et magenta (les 'a') ce sont les 8 bits lus pour constituer un nibble,
<BR><BR>
<IMG SRC="../THEMAS/DIVERS/BULLET.GIF">En jaune les extrabits qui peuvent Ωtre soit acceptΘs dans un nibble (a), soit ignorΘs
α la lecture (I) quand ils sont en tΩte de nibble (qui doit toujours commencer par un 1 pour Ωtre valide, on ne le dira jamais assez)
<BR><BR>
<IMG SRC="../THEMAS/DIVERS/BULLET.GIF">En vert gras le premier nibble synchronisΘ, les suivants sont obligatoirement synchronisΘs<BR>
<BR>Les cas 9 et 10 sont les cas particuliers ou la tΩte tombe directement sur l'un ou l'autre des extrabits, ce qui revient quasiment au mΩme
<TR> <TD COLSPAN ="5" CLASS="PARAG1"> * * * <FONT COLOR=RED> a a a a a a a a </FONT> <FONT COLOR=MAGENTA> a a a a a a a a </FONT> <FONT COLOR=YELLOW> I</FONT> Maintenant c'est SynchronisΘ</TD></TR>
<TR> <TD COLSPAN ="5" CLASS="PARAG1"> * * * * <FONT COLOR=RED> a a a a a a a a </FONT> <FONT COLOR=MAGENTA> a a a a a a a a </FONT> Maintenant c'est SynchronisΘ</TD></TR>
<TR> <TD COLSPAN ="5" CLASS="PARAG1"> * * * * * <FONT COLOR=RED> a a a a a a a a </FONT> <FONT COLOR=MAGENTA>a a a a a a a a </FONT> <FONT COLOR=RED>a a a a a a a a </FONT> <FONT COLOR=YELLOW> I </FONT> Maintenant c'est SynchronisΘ</TD></TR>
<TR> <TD COLSPAN ="5" CLASS="PARAG1"> * * * * * * <FONT COLOR=RED> a a a a a a a a </FONT> <FONT COLOR=MAGENTA> a a a a a a a a </FONT> <FONT COLOR=RED> a a a a a a a a </FONT> Maintenant c'est SynchronisΘ</TD></TR>
<TR> <TD COLSPAN ="5" HEIGHT="10" CLASS="PARAG4"> <img src="../THEMAS/M3/BIT.PNG"> Les nibbles valides lus sont les suivants :
</TD></TR>
<TR> <TD ></TD> <TD COLSPAN ="4" CLASS="PARAG4">
le 1er <FONT COLOR="RED"> 1100.1111 =$CF</FONT> <BR>
le 2Φme <FONT COLOR="MAGENTA"> 1111 0011 =$F3 </FONT>,<BR>
le 3Φme <FONT COLOR="RED"> 1111 1100 =$FC </FONT>,<BR>
le 4Φme <FONT COLOR="#40FF40"> 1111 1111 =$FF </FONT>et nous sommes synchronisΘs
<TR> <TD COLSPAN ="5" CLASS="PARAG1"> * * * * * * * <FONT COLOR=RED> a a a a a a a a </FONT> <FONT COLOR=MAGENTA> a a a a a a a a</FONT> <FONT COLOR=RED> a a a a a a a a </FONT> <FONT COLOR=MAGENTA> a a a a a a a a </FONT> <FONT COLOR=YELLOW> I </FONT> Maintenant c'est SynchronisΘ</TD></TR>
<TR> <TD COLSPAN ="5" CLASS="PARAG1"> * * * * * * * * *<FONT COLOR=YELLOW> I </FONT> Maintenant c'est SynchronisΘ</TD></TR>
<TR> <TD COLSPAN ="5" HEIGHT="10" ></TD></TR>
<TR> <TD COLSPAN ="5" CLASS="PARAG1"> Vous comprennez maintenant pourquoi <FONT COLOR=RED><B>il faut au minimum 4 $FF de synchronisation (cf. cas 8)</B></FONT>
avant d'Θcrire un marker d'entΩte, que ce soit du champ adresse ou du champ de donnΘes.(si l'on exclut le cas particulier des schΘmas de protection qui peuvent en mettre plus avec moins d'extrabits.) <BR><BR>
<FONT COLOR=RED> Vous allez sans doute vous dire "oui mais si la lecture commence ailleurs que sur
les octets de synchronisation ? </FONT> <BR>
Comme dirait le cerveau de Baker Street "ElΘmentaire mon cher Watson, on ne peut pas se synchroniser tant que l'on ne passe pas sur
ces fameux nibbles de synchronisation! Les marqueurs d'adresse ont d'ailleurs des valeurs dont la combinaison NE PEUT PAS
se retrouver dans les donnΘes enregistrΘes dans chaque secteur, ce qui Θvite des tentatives de lecture quasi-infinies" !<BR><BR>
</TD></TR>
<TR> <TD COLSPAN ="2" CLASS="PARAG1">Ce α quoi ce mΩme cerveau fΘcond ajouterait "mais c'est d'ailleurs une astuce utilisΘe par certains schΘmas de
protection que de modifier ces octets de synchronisation et le nombre d'extrabits..."</TD>
