Dernière mise à jour: Jeudi 27/07/2006.
1) Présentation
Chip Select était un pirate informatique
très connu au
début des années 80.
Sa spécialité consistait à cracker des logiciels
commerciaux, c'est à dire à oter les protections qui
empêchaient de copier facilement ces programmes.
Il ne faut pas oublier qu'un logiciel non protégé
à l'époque se copiait à la vitesse grand V et un
éditeur ne verrouillant pas un de ses produits avait toutes les
chances de ne pas faire de chiffre d'affaire du tout...
Sa renommée était telle qu'il fut même cité
dans un livre consacré aux techniques de plombage à
l'usage des auteurs & éditeurs qui voulaient introduire sur
le marché une réalisation non duplicables. En effet dans
ce livre, les ennemis du copyright sont désignés car il
est normal de connaître les personnes susceptibles de causer du
tord au business.
Je parle du bouquin « Systèmes d'Exploitation et
Systèmes de Protection sur Apple II » de Jean-Pierre
Lagrange. Ce pirate est dépeint comme étant un
adversaire
coriace dont la technicité éprouvée constitue un
danger pour tous les logiciels originaux passant entre ses mains.
Je cite la page 388 : « Les actifs : j'aurais
dû dire l'actif car à part CHIP SELECT
(pardon au reste de
la bande A.B.C) je ne vois personne de digne
à mettre
actuellement ici. Si vous examinez attentivement ses crackings actuels,
vous reconnaîtrez qu'ils sont très bien faits (mieux qu'au
début et c'est normal) ».
Voila pour la présentation de notre homme dans ses oeuvres
obscures.
Mais il n'a pas fait que du cracking. Ou disons plutôt que ses
activités underground tournant autour du mécanisme du
lecteur de disquettes lui ont permis de bien maitriser cet aspect et
d'ouvrir son champ d'application à autre chose que la recherche
de routines de protection.
2) Le FBoot ProDOS
C'est ainsi qu'il mis en circulation un programme permettant de
démarrer très rapidement une disquette (au contenu
organisé au format ProDOS) en proposant une sélection des
programmes trouvés dans son catalogue (au niveau root).
Ce programme est appelé dans le jargon Apple II un
« Fast Boot ».
Comme à l'époque la plupart des utilisateurs n'avaient
pas de disque dur (je sais ça parait curieux aujourd'hui
où tout
le monde en est équipé avec des tonnes de giga octets)
mais uniquement des lecteurs de disquettes au format 5,25 pouces, il
était plus qu'intéressant d'avoir un outil permettant de
ne pas trop « subir » les temps d'attente au
démarrage d'une disquette. Le Fast Boot ProDOS en version 2.0A
est bien évidemment beaucoup plus rapide que le boot classique
de ce système d'exploitation.
Son software démarre une vieille version de ProDOS (la 1.1.1)
mais il est à mon avis intéressant d'avoir ce
témoignage d'un autre temps à disposition sous forme de
disque image pour émulateur (ne serait-ce que pour se souvenir
qu'il a été repompé ensuite par un éditeur
pour être utilisé dans des logiciels commerciaux (jeux) et
pour faire le lien avec l'interview de Tsunoo de
Troll & Co).
Je me suis donc lancé dans la création d'un .DSK avec les
outils classiques à disposition (ADT, DSK2FILE ou encore ASIMOV).
Mais horreur, en lançant le programme via les émulateurs
que j'utilise le plus fréquemment, à savoir Applewin et
Apple Oasis, le programme plante au tout
début sur le logo de
Chip Select (dont il affiche 2 lignes de travers
en tout et pour tout
avant de partir en vrille).
Arghhh ! ! ! !
Pourtant ma disquette d'origine est en parfaite santé. Elle n'a
aucun mauvais secteur, boote et passe très bien sur un vrai
Apple IIe.
Par ailleurs, le programme de création de disque image
utilisé (DSK2FILE) n'a signalé
aucune erreur. Il a donc
fait son boulot tout à fait normalement.
La première chose à faire quand ce type de
désagrément survient (outre le fait de maudire les
aléats de l'informatique et d'aller siffler une bière
pour se remettre du coup psychologique reçu), est de
procéder au schéma inverse.
J'entends par schéma inverse, reconstituer une disquette
physique à partir du disque image et controler qu'elle
fonctionne parfaitement comme son original.
J'ai donc procédé à cette opération et
à la fin j'ai rebooté ma disquette « toute
neuve » reconstituée pour voir comment se comportait
le bébé.
Autant dire que tout l'étage de mon immeuble m'a entendu gueuler
quand le programme s'est lamentablement planté exactement au
même endroit qu'avec Applewin!!
Si on récapitule ces informations :
- La disquette d'origine fonctionne impecc, elle passe niquel
chrome au Locksmith Fast Backup. Chip
Select n'a pas protégé son
programme car comme il le dit lui même, son objectif est qu'il se
répande le plus possible sans restriction aucune.
La disquette est donc au format 16 secteurs par piste.
- Mais le process disquette -> disque image -> disquette
altère le contenu des données. D'ailleurs, compte tenu du
fait que ça plante sous émulateur, on peut se contenter
de dire que le process disquette -> disque image seul est
responsable de l'anomalie !
Comment cela est-il possible, me direz-vous ?
Et bien je vais vous expliquer le pourquoi du comment un peu plus bas,
soyez un peu patient !
Dans l'immédiat, il y a une chose à faire : booter
l'outil SST (Saltine's Super
Transcopy) pour créer un disque
image spécial .NIB contenant plus finement les données de
la disquette 5" 1/4 d'origine.
D'ordinaire, ce programme est plutôt destiné aux softs
avec certaines particularités comme l'usage d'un numéro
de volume DOS 3.3 non standard dans les champs adresse ou une
quelconque protection légère à base de changement
de markers. Mais ici (et c'est d'ailleurs la rêgle quand un .DSK
merdoit avec un émulateur), ça ne mange pas de pain de
faire ce test (il faut juste avoir 2 drives disponibles sur le vrai
apple II et Ciderpress sur PC pour recoller les 2 bouts, cet outil
étant plus simple que d'utiliser SST
avec un émulateur
pour faire la même chose de l'autre côté).
Le résultat de l'opération, c'est que le programme
de fast boot fonctionne parfaitement avec les émulateurs quand
il a été transformé en .NIB!
Vous trouverez d'ailleurs sur cette page le fichier en
téléchargement pour avoir une version exacte du boulot de
CHIP SELECT.
C'est un point important car ceci veut dire qu'il y a quelque chose sur
la disquette d'origine en plus (sous forme de nibble) et/ou qu'un usage
particulier non standard est fait en douce provoquant le
disfonctionnement.
Si cela avait été un programme commercial, on aurait pu
avoir le réflexe de dire qu'il y avait un nibble count sous
roche (quoi que si une copie Locksmith Fast Backup
marche, ça ne
peut pas être ça!) mais pour un soft qui est
censé être free, c'est louche et il faut écarter
cette hypothèse.
Bon, on a fait le test du .NIB, mais on ne va pas s'arrêter en
aussi bon chemin...
3) Le problème du codage
Pour comprendre la nature du problème, il faut boot tracer sur
un vrai apple II le programme pour capter ce qu'il fait.
J'ai donc désassemblé le boot 1 du soft (c'était
suffisant pour piger le couac) et en ai fait un source complet que
vous trouverez à la fois en version output assemblée (et
commentée en détail) sur cette page ainsi qu'un disk
image avec toujours le source pour Merlin pro 2.48
(Dos).
Qu'est-ce que ça nous apprend d'avoir fait ça ?
Tout d'abord que Chip Select était parano
au possible !
En effet, il y a en tout et pour tout une dizaine d'octets
correspondant à du code intelligible (compréhensible
directement par le monitor) sur sa disquette dans le secteur 0 de la
piste 0. Le reste est codé pour écarter les fouineurs!!
Et qu'est-ce qu'il fait dans ces quelques octets?
Et bien il procède à un décodage du reste du boot1
via un EOR #$60 pour placer son code... dans le buffer clavier,
histoire qu'il disparaisse si l'utilisateur a la mauvaise idée
de vouloir interrompre l'exécution normale pour zieuter un peu
ce qui se passe dans la mémoire de la machine !
Ce boot 1, une fois analysé, nous informe de 3 points essentiels
(je vous laisse lire le source commenté en annexe qui est fort
instructif) :
- Le fast boot (=le boot 2) occupe la piste 1 en entier et est
chargé directement par le boot 1 puis est exécuté
par un JMP $B000.
- Il est délicat de modifier ce boot 1 car il
s'auto-utilise
lors du décodage des nibbles (Jean-Pierre
a écrit un court
complet sur les lecteurs de disquette disk II. Allez
donc y faire un tour, c'est très instructif.)
- Les datas du champ de données ne sont pas au format
6-2 ! Il était d'ailleurs facile de s'en apercevoir en
examinant cette piste 1 avec un éditeur de secteurs : on ne
voit que du jus de boudin et de toute évidence ce n'est pas un
simple codage EOR comme pour la planque du boot 1. Le codage est un
pseudo 4-4, c'est à dire que 2 nibbles sont utilisés pour
créer un octet en mémoire lors de la phase Disk ->
Ram. Je dis « pseudo » car ce n'est pas comme le
classique 4-4 où le 1er nibble est décalé sur la
gauche (au décodage) pour s'encastrer à la méthode
« dent de fourche » avec les informations du 2nd
nibble (chaque bit du quadruplet du demi octet à reconstituer
étant entouré de bits « 1 »
jetables) comme c'est le cas pour les informations contenues dans le
champ adresse (volume/track/sector/checksum). Bref ici, on utilise de
l'indexation sur l'espace $96-$FF du boot 1 pour reconstituer chaque
octet à grand coup de ORA avec les infos du T$00 S$00. Comme on
reste en 16 secteurs, cette méthode de 4-4 est plus gourmande en
occupation disque que le 6-2 et il n'y a que 171 octets (=$AB) de
données par secteur. L'avantage de cette méthode (outre
d'éloigner le fan club du Copy 2+ et
consors) est un gain de
vitesse car qui dit 4-4 dit pas besoin de denibblizing et donc pas de
routine de post-traitement couteux en temps machine pour la
reconstitution des bytes (= moins de rotations du drive avant de passer
au secteur suivant). Bien entendu c'est perceptible dans l'absolu
surtout pour un vrai Apple II (sur un émulateur, on ne voit
rien).
Voila pour le boot 1.
Maintenant voyons pourquoi ça coince quand on transforme cette
piste dans un .DSK. D'ailleurs on peut généraliser ce
problème à d'autres softs utilisant un principe similaire
(je pense à certains Froggy Software) ou
à plein d'autres
softs de l'underground ayant repris ce fast boot juste un peu
modifié ou dans sa version loader de softs DOS 3.3 (pack de
programmes de copies, etc...)
Pour cela un bref rappel du format standard ProDOS (l'outil
utilisé étant DSK2FILE version
ProDOS):
************************************** < DEBUT RAPPEL >
**************************************
Notre outil de création de disques image ne fait que lire la
disquette
physique, mais il est important de savoir aussi comment sont
écrites
normalement les informations sur celle-ci (quand elles sont
écrites en
standard par ProDOS). C'est pourquoi je parle d'abord de cela (à
part
l'algorithme, le procédé utilisé par la RWTS du
DOS 3.3 est identique).
ECRITURE SUR LA DISQUETTE
Le principe de la sauvegarde est de stocker sur la disquette la
mémoire de l'apple II par tranche de 256 octets, chaque tranche
étant appelée page (pour la ram) et secteur (pour la
disquette).
Les esprits critiques me rétorqueront que sous ProDOS
l'unité de stockage de base sur disk est le bloc de 512 octets.
Sachez qu'il ne s'agit que d'une surcouche pratique (diverses raisons
dont une plus grande rapidité) - car en tout état de
cause au niveau de la disquette, on a bien toujours la
séparation en 2 secteurs de 256 octets chacun (les marquages
physiques des secteurs ayant été mis en place une bonne
fois pour toute lors de la phase de formattage de la disquette).
En ram, l'unité de base est l'octet. Chaque case mémoire
est dans cette unité et peut prendre 256 valeurs possible ($00
à $FF).
1 octet en ram = 8 bits significatifs.
1 page de ram = 256 octets * 8 bits = 2048 bits significatifs.
Sur la disquette, l'unité de base est le nibble. Il s'agit
là aussi d'un octet (8 bits) mais avec des
particularités, à savoir que seuls 6 bits PEUVENT
être significatifs, c'est à dire utilisables pour
représenter quelque chose. Ceci est dû à des
contraintes physiques (lire la partie sur les nibbles dans le dossier
sur le Disk II).
Avec 6 bits, on ne peut avoir que 64 valeurs différentes et
celles acceptées ne sont pas séquentielles (elles
appartiennent à une liste de valeurs répondant à
des caractéristiques spécifiques liées aux
contraintes du drive).
1 secteur de disquette = 342 nibbles disponibles pour les
données (pour le format standard de 16 secteurs par piste). La
capacité de stockage dans un secteur est donc de 342 nibbles * 6
bits = 2052 bits significatifs MAXIMUM, le tout en utilisant un codage
optimum.
On peut donc faire tenir une page de ram dans un secteur de la
disquette mais en tout état de cause, il n'y a pas le rapport
1 : 1 entre l'unité de base de la mémoire (octet
ram) et l'unité de base de la disquette (nibble).
Puisque l'on ne peut pas stocker directement sur la disquette le
contenu d'une case mémoire, il faut se ramener à
l'unité la plus petite, à savoir le nibble. Il faut
transformer l'octet de la ram avec un codage pour le ramener à
ce qui est possible pour le drive. Quelque soit la technique
utilisée, le procédé travaille avec la plus petite
unité, à savoir le bit.
Il n'y a qu'un seul moyen pour faire rentrer la page de ram dans le
secteur, c'est la méthode de codage dite 6-2.
Les autres méthodes (4-4 et 5-3) prennent plus de place.
Ces 2 chiffres correspondent à la façon dont on
découpe un octet pour le faire rentrer dans plusieurs nibbles.
Pour la méthode 6-2, on traite les 256 octets de ram par
« lots » de 3 octets en même temps lors de
l'encodage (pré-nibblizing).
Pour chaque octet de ram du lot, on met un pack de 6 bits dans un
nibble et on met de côté le pack de 2 bits restant. Les 3
* 2 bits restant sont associés pour former un 4ème
nibble. On stocke 3 octets de ram dans 4 nibbles sur la disquette.
On final, les 342 nibbles du secteur sont formés de 4
parties :
86 nibbles composés de packs de 2 bits regroupés.
86+86+84 (=256) nibbles composés de packs de 6 bits.
En numérotant les nibbles, on a ceci :
partie\Numéro nibble
1 : $000, $001, $002, ..., $053, $054, $055. (86 nibbles,
packs de 2 bits regroupés)
2 : $056, $057, $058, ..., $0A9, $0AA, $0AB. (86 nibbles,
packs de 6 bits)
3 : $0AC, $0AD, $0AE, ..., $0FF, $100, $101. (86 nibbles,
packs de 6 bits)
4 : $102, $103, $104, ...,
$155.
(84 nibbles, packs de 6 bits)
La particularité que l'on ne trouve écrite nulle part (il
faut examiner un source du ProDOS pour le savoir), c'est que lors du
traitement de création des nibbles $054 et $055 (c'est à
dire les 2 derniers nibbles composés de regroupent de packs de 2
bits), ProDOS met
n'importe quoi (ce qu'il trouve) à la place des bits "libres"
(rappel: on peut stocker 2052 bits dans le secteur alors qu'on en a
besoin que de
2048 pour la page de ram).
En effet, lors de la phase de pré-nibblizing, il traite avec un
même indice les 3 buffers de travail de
86, 86 et 84 octets de ram. Il lit donc les 2 octets qui suivent le
dernier
buffer de travail de 84 octets.
LECTURE DE LA DISQUETTE
Pour l'opération de lecture d'un secteur, DSK2FILE
version ProDOS utilise le
Disk II Device Driver (DIIDD).
Le DIIDD lit les nibbles dans l'ordre.
D'abord la 1ère partie = les 86 nibbles de
complément (packs de 2 bits) qu'il stocke. -> =1ère
boucle de lecture.
Puis les 3 autres parties (il y a 1 boucle de lecture par partie).
Il effectue la phase de post-nibblizing juste après la
lecture de chaque nibble pour les parties 2, 3 et 4. (Le DIIDD traite
partie par partie avec un indice correspondant vraiment au nombre de
bytes à reconstituer: 86/86/84).
Pour chaque nibble des parties 2, 3 et 4, le DIIDD reconstitue l'octet
de ram
correspondant en reprenant les 2 bits qui manquent.
Exemple pour reformer quelques octets de ram :
1ère boucle (partie 1):
Lecture nibble $000 à $055.
2nde boucle (partie 2):
Lecture nibble $056 (6 bits) et complète avec le pack de 2 bits
du nibble $000 associé -> octet $00 de la page ram.
Lecture nibble $057 (6 bits) et complète avec le pack de 2 bits
du nibble $001 associé -> octet $01 de la page ram.
Lecture nibble $058 (6 bits) et complète avec le pack de 2 bits
du nibble $002 associé -> octet $02 de la page ram.
Lecture nibble $059 (6 bits) et complète avec le pack de 2 bits
du nibble $000 associé -> octet $03 de la page ram.
Lecture nibble $05A (6 bits) et complète avec le pack de 2 bits
du nibble $001 associé -> octet $04 de la page ram.
Lecture nibble $05B (6 bits) et complète avec le pack de 2 bits
du nibble $002 associé -> octet $05 de la page ram.
etc...
Lecture nibble $0AA (6 bits) et complète avec le pack de 2 bits
du nibble $054 associé -> octet $54 de la page ram.
Lecture nibble $0AB (6 bits) et complète avec le pack de 2 bits
du nibble $055 associé -> octet $55 de la page ram.
3ème boucle (partie 3):
Lecture nibble $0AC (6 bits) et complète avec le pack de 2 bits
du nibble $000 associé -> octet $56 de la page ram.
Lecture nibble $0AD (6 bits) et complète avec le pack de 2 bits
du nibble $001 associé -> octet $57 de la page ram.
Lecture nibble $0AE (6 bits) et complète avec le pack de 2 bits
du nibble $002 associé -> octet $58 de la page ram.
etc...
Lecture nibble $100 (6 bits) et complète avec le pack de 2 bits
du nibble $054 associé -> octet $AA de la page ram.
Lecture nibble $101 (6 bits) et complète avec le pack de 2 bits
du nibble $055 associé -> octet $AB de la page ram.
4ème boucle (partie 4):
Lecture nibble $102 (6 bits) et complète avec le pack de 2 bits
du nibble $000 associé -> octet $AC de la page ram.
Lecture nibble $103 (6 bits) et complète avec le pack de 2 bits
du nibble $001 associé -> octet $AD de la page ram.
Lecture nibble $104 (6 bits) et complète avec le pack de 2 bits
du nibble $002 associé -> octet $AE de la page ram.
etc...
Lecture nibble $154 (6 bits) et complète avec le pack de 2 bits
du nibble $052 associé -> octet $FE de la page ram.
Lecture nibble $155 (6 bits) et complète avec le pack de 2 bits
du nibble $053 associé -> octet $FF de la page ram.
Il est important de noter que
les packs de 2 bits merdiques des nibbles
$054 et $055 ne sont pas utilisés (un pack dans le $054 et un
pack dans le $055).
La phase de reconstruction des octets de ram avec des nibbles
codés en 6-2 est gourmande en temps.
A noter que j'ai simplifié à l'extrème mais c'est
l'idée générale pour vous faire comprendre le
principe. La routine qui fait ça s'occupe aussi du controle du
checksum, fait l'inversion des bits des packs de 2 bits, la translation
entre les valeurs possibles des nibbles et les octets.
En utilisant 6 bits significatifs, cette méthode est optimum,
mais rien ne nous empêche d'en utiliser moins.
Par exemple pour la méthode 4-4, chaque nibble sert à
stocker 4 bits d'un octet de la ram. Chaque case mémoire se
trouve donc répartie sur 2 nibbles consécutifs.
Les nibbles $000 et $001 permettent le stockage de l'octet $00 de ram.
Les nibbles $002 et $003 permettent le stockage de l'octet $01 de ram.
Etc...
Les nibbles $154 et $155 permettent le stockage de l'octet $AA
de ram.
Les autres octets de la page de ram ($AB à $FF) sont
stockés sur un autre secteur. Avec cette méthode, il faut
2048 / 4 = 512 nibbles soit presque 1,5 secteurs pour une page de ram.
La phase de reconstruction des octets en ram avec des nibbles
codés en 4-4 est rapide mais couteuse en place.
Voilà pour les rappels. Pour plus de détail, vous pouvez
vous référer par
exemple au livre Beneath Apple ProDOS de Don Worth et Pieter
Lechner (Quality Software), appendix C sur
le nibblizing.
************************************** < FIN RAPPEL >
**************************************
Maintenant voyons quelles sont les conséquences de cela sur le
Fast Boot de Chip Select.
Sur la piste 1, il a codé son fboot avec une méthode
pseudo 4-4, à raison de 2 nibbles pour reconstituer un octet.
Tous les nibbles jouent un role dans ce codage (c'est à dire que
même s'il n'y a que 4 bits significatifs, la valeur
complête du nibble est importante).
Le programme de création de disque image lui s'attend à
trouver un codage 6-2 et ignore donc allègrement certains bits
des nibbles $054 et $055.
De ce fait, lors du passage disquette -> ram, il y a au moins un 1
octet par secteur de massacré
lors de la reconstruction (perte de donnée définitive).
Il s'agit de l'octet $2A de chaque
série de $AB octets.
Dans le schéma suivant, j'ai présenté les 2
méthodes de codage 6-2 et 4-4 sur le même document. On
voit bien que pour la 1ère partie du codage 6-2, ce sont les 2
nibbles de fin ($054 et $055) qui vont causer le flingage des datas.
4) Compléments Fboot ProDOS
Avoir une version en .NIB qui marche c'est bien, mais moi
personnellement je ne suis pas fan de ce format. Je
préfère le classique .DSK ne contenant que les octets de
données avec les secteurs purgés de leur
« enveloppe » d'identification.
Aussi je me suis amusé à en faire une version bis
utilisant ce format.
A la place du boot 1 de la mort de feu Chip Select,
j'ai mis un
classique (et habituel maintenant pour ceux qui me lisent
régulièrement !) Accolad-Boot qui charge la piste 1
(tout en gardant la signature texte codée de Chip
Select). Le
Fboot lui-même est en clair -vrai codage 6-2- (il n'y a plus
aucun EOR dans le code) et il est donc hackable à
volonté au sector editor ;-)).
Sur un vrai Apple II, la différence de vitesse est minime au
boot (je dirais même imperceptible) car de toute façon le
vrai gain de vitesse, c'est le fboot lui-même (et pas le boot 1)
qui en est la cause (lorsqu'il charge le ProDOS, la
présentation, le programme sélectionné)...
J'avais commencé à l'époque à mettre le
Fast Boot ProDOS sous forme de source Merlin. C'est sur le disque image
de sources. Il s'assemble sans problème mais je n'ai pas fini la
partie des commentaires. Je ne désespère pas de m'y
atteler un de ces 4 quand j'aurai un peu de temps libre pour ça,
histoire de faire une adaptation pour un ProDOS 2.0.3 par
exemple !)
Mais je le mets dedans en l'état pour le moment...
5) Conclusion
POUR NE PAS PRENDRE DE RISQUE, TRANSFORMEZ VOS DISQUETTES PHYSIQUES EN
DISQUES IMAGE AU FORMAT .DSK, .DO, .PO AVEC LES LOGICIELS STANDARDS
CLASSIQUES DISPONIBLES SUR INTERNET QUE SI LES DONNEES DE VOS
DISQUETTES SONT STOCKEES DESSUS AVEC LE FORMAT 6-2. (Vous ne trouverez
jamais cette information dans les documentations des
émulateurs!!!!)
En effet les programmes standards de création de disques image
qui vont lire les nibbles de données sur votre disquette
physique s'attendent à les trouver codées en 6-2 (car ils
utilisent un DOS normal).
Si ce n'est pas le cas, vous vous exposez à une reconstruction
erronnées en mémoire des données -et par extension
sur le disque image aussi.
Si vous ne respectez pas cette règle, la plupart des octets
reconstruits par le programme de création de disques image
auront les bits mélangés (ce n'est pas génant car
l'émulateur remettra les nibbles en place) et le plus important,
c'est que
quelques uns seront définitivement altérés (perte
d'informations par rapport aux données originelles).
Si vous pensez avoir sauvegardé le contenu d'une disquette d'une
mort certaine (dû à l'age) en créant un disk image
.DSK et en vous disant que de toute façon si ça ne
marche pas avec un émulateur, il suffit (quand vous aurez le
temps) soit de modifier l'émulateur soit de changer le
programme émulé (routine de controle du drive), il y a
une certaine probabilité pour que vous ayez tout faux. Il y a le
risque que votre disk image proprement dit soit incorrect (des octets
différents de l'original) et dans ce cas de figure, votre
disquette est belle et bien perdue à jamais.
A BON ENTENDEUR!!!!
Pour le reste (4-4 ou 5-3), utilisez systématiquement des .NIB.
Ce n'est qu'avec ce format que vous pouvez être sûr que la
routine de gestion du drive de votre programme émulé
relira correctement les nibbles (sans omission).
Le fait d'écrire des variantes de ces programmes de
création de disques image avec une routine de lecture de la
disquette physique dotée d'un décodage adapté au
4-4 ou au 5-3 n'est pas suffisant car après, tout dépend
comment l'émulateur fait le lien entre des instructions de
lecture du drive du programme émulé (qui travaille au
niveau nibble) et les octets stockés dans le disque image...
S'il retransforme les octets du .DSK, .DO ou .PO en nibbles 6-2, vous
allez droit au crash. Avec un .NIB, les données du disque image
restent toujours sous forme de nibbles.
Il n'y a hélas pas de solution miracle pour savoir si les
données de votre disquette sont en 6-2 ou pas si vous n'en
êtes pas l'auteur (comme on l'a vu,
le fait que la disquette se duplique sans soucis avec Locksmith
Fast
Backup n'est en rien un indicateur; idem pour un traitement sans
erreur de votre programme de création de disks image).
Soit vous le savez car vous maîtrisez vos données, soit il
faut analyser la routine de lecture utilisée pour les
exploiter...
Bons désassemblages ! ! !
Quand vous avez un problème de disk image qui ne fonctionne pas
avec un émulateur, rechercher en 1er une explication avec votre
vrai apple II car si ça se trouve votre .DSK ne correspond pas
à 100% à votre disquette physique.
Moralité, faites du propre (6-2), ne soyez pas parano et ne
perdez pas
de place sur votre disquette avec ces conneries pour un gain de temps
misérable.
C'est quand même navrant de voir de chouettes outils finir
à la poubelle pour cause d'emploi de formats non standards. Pour
la petite histoire, j'ai encore de la récup à faire (donc
du temps perdu pour autre chose) pour l'outil d'identification /
capture / manipulation de sprites Anstrom 2.3
et ses OP PLUS,
signés 'El Mathos' (oui, le mec de Sergent Claude puis du FTA
sur GS mais lors de sa période IIe antérieure - on touche
à de l'historique là!!) le tout
distribué par Dany Sector. Le programme
en lui-même, c'est
du tout bon mais beuurrk il a collé un format
« grosse merde » non copiable au Locksmith
en
plus (uniquement au Disk Muncher - donc avec
des trailers à la
noix ou je ne sais quelle branlette intellectuelle matheusienne). Dire
que j'ai encore à me faire ch... pour un programme underground
qui était vendu 60 francs (allez je déconne, ça
m'amuse de fouiner dans ces vieilleries ;-). Rien que l'intro me
plait bien avec son magicien et son scroll informatif...)
Le pire, c'est qu'il avait fait des démos de son soft (il en
mentionne 2).
Je n'en ai qu'une seule : une animation de Rescue
Raiders avec des
sprites complètement refaits et bien délirants
(l'hélicoptère qui ressemble à une sorte de
saucisse sans ses pales, un véhicule terrestre transformé
en pac-mac, des parachutistes en forme de croix de cimetière,
...)
Et ces animations sont aussi
« plombées » !!! La rescue
Raiders
peut quand même s'exécuter sur émulateur en .NIB
mais pour le programme Anstrom 2.3, alors
là basta -ça
plante!
GRRRR ! y-a des bytes dans la gueule qui se perdent
hé hé hé...
6) Dernière minute:
Arghhhh de nouveau!!!
Quand on lance le Locksmith
depuis le .NIB ou
depuis le .DSK sous émulateur, cette version patchée par
Chip Select se plante! Pourtant ma version
Accolad-Boot fonctionne sur
un vrai IIe et j'ai essayé le process disquette -> .DSK ->
disquette.
Résultat: le Locksmith tourne impeccable.
Il
y a donc encore un
problème, mais là je mise plutôt sur une
incompatibilité car le plantage est différent selon qu'on
utilise Applewin ou Apple Oasis.
Encore un truc tordu planqué
quelque part :-((
Je remets la recherche de ce problème à plus tard. Mon
objectif était d'avoir ce Fboot dispo.
A noter que le Copy
II+ lui semble
tourner sans soucis et le BASIC.SYSTEM marche bien aussi.
Faire tourner des bit copiers sur émulateur n'a pas de sens
aussi pour les autres, je ne sais pas.
|
Fboot + ProDOS
|
Download FBoot ProDOS .NIB (gzipped)
|
|
Fboot + ProDOS
|
Download FBoot ProDOS .DSK (gzipped)
|
|
DOS 3.3
|
Download FBoot ProDOS sources (gzipped)
|
Disk : Fboot_Prodos_Chip_Select_Sources.dsk
"-" files are DELETED files | "*" files are LOCKED files
----------------------------------------------------------------------
A A$0000 (000000) L$0003 (000003) 002
HELLO
B A$0800 (002048) L$0100 (000256) 003
BOOT1.ORIGINAL
T A$0000 (000000) L$2400 (009216) 036
T.BOOT1.APRES.EOR
B A$0800 (002048) L$0100 (000256) 003
BOOT1.APRES.EOR
B A$8000 (032768) L$103E (004158) 018
READ.ME.ORIGINAL
B A$1000 (004096) L$0050 (000080) 002
READ.ME.DECODE
B A$8000 (032768) L$103E (004158) 018
READ.ME.HACK.BRUNABLE
B A$1000 (004096) L$1000 (004096) 018
BOOT2.ORIGINAL
B A$1000 (004096) L$1000 (004096) 018
BOOT2.APPLEWIN
B A$B000 (045056) L$1000 (004096) 018
BOOT2
T A$0000 (000000) L$3D00 (015616) 061
T.BOOT2
This catalog contains 11 files. 0 were DELETED.
----------------------------------------------------------------------
7) Sommaire Annexes
| Lien |
Contenu |
 |
Source Boot 1. |
|
Message de Chip Select avec
l'historique des Fast Boots. |
|
Doc du Fast Boot ProDOS. |
Source Boot 1.
:asm
1
2
ORG $0800
3
4 ********************************
5
*
*
6 * BOOT 1 FBOOT PRODOS
2.0 *
7 * CHIP
SELECT *
8 * Source by
Deckard *
9
*
*
10 ********************************
11
12 NB_SECT
EQU $00 ; nbr de
secteurs à charger
13
CPT
EQU $01 ;
compteur couple nibble datas
14 INDICE_WT EQU
$03 ; indice écriture
15 ADR_LOAD
EQU $26 ; et $27
: pointeur adresse implantation
16 SECTOR
EQU $3D ; secteur
à charger
17
18
IN
EQU $0200 ; buffer clavier!
19 BOOT2
EQU $B000 ; lancement fboot
20
21 HC08C
EQU $C08C ; remplit le latch
(indexation slot16)
22 HC0E0
EQU $C0E0 ; $C080,60 ->
motor phase 0 off
23 HC0E2
EQU $C0E2 ; $C082,60 ->
motor phase 1 off
24 HC0E3
EQU $C0E3 ; $C083,60 ->
motor phase 1 on
25 HC0E5
EQU $C0E5 ; $C085,60 ->
motor phase 2 on
26 HC0EC
EQU $C0EC ; $C08C,60 :
remplit le latch slot 6
27
HOME
EQU $FC58 ; efface
écran
28
WAIT
EQU $FCA8 ; tempo
29
30 *-------------------------------
31
32
BOOT1
; Y=0
0800: 01
33
DFB 1
; 1 secteur à charger
34
0801: B9 00 08 35
:1
LDA BOOT1,Y ; recopie le code du boot1
-> buffer clavier!
0804: 49 60
36
EOR #$60 ; après
déprotection EOR
0806: 99 00 02
37
STA IN,Y
0809: 88
38
DEY
080A: D0 F5
39
BNE :1 ;
recopie toute la page
080C: 4C 0F 02
40
JMP BOOT1_GO ; lance la suite sur le buffer
clavier
41
42 *-------------------------------
43
44 * Tout le programme qui suit est normalement codé
par
45 * un EOR #$60. Le programme est difficilement modifiable,
46 * mais en rusant on peut s'en sortir. En effet, comme
47 * protection mémoire, Chip Select a
utilisé le propre
48 * code du boot1 comme référence pour le
décodage des
49 * nibbles. Il y a ainsi 64 octets de ce boot 1 qui sont
50 * intouchables! Il s'agit des octets dont les indices
51 * dans cette page sont compris entre $96 et $FF (enfin
52 * pas tous mais une bonne partie).
53 * Au moindre de ces octets changé, le
décodage des nibbles
54 * sera inexact.
55 * Bien entendu les passages importants comme le
décodage des
56 * nibbles font parties de ces octets intouchables!!
57
58
ORG $020F ; on est dans le
buffer clavier normalement
59
; au moment de l'exec
60
BOOT1_GO
020F: EE F3 03
61
INC $03F3 ; reset provoque
reboot
0212: EE F0 03
62
INC $03F0 ; crash BRK
63
0215: E0 60
64
CPX #$60 ; doit booter
depuis slot 6
0217: D0 FE 65
H0817
BNE H0817 ; sinon, boucle
sans fin
66
0219: 20 A6 02
67
JSR H02A6 ; signature +
passage piste 1
68
021C: A9 00
69
LDA #0
021E: 85 03
70
STA INDICE_WT ; on commencera avec Y=0
0220: A9 B0
71
LDA #>BOOT2
0222: 85 27
72
STA ADR_LOAD+1
0224: A9 10
73
LDA #$10
0226: 85 00
74
STA NB_SECT ; nbr de secteurs à
charger
75
0228: A9 FF
76
LDA #$FF
022A: 85 3D
77
STA SECTOR ; secteur à
charger
78
; +1 -> commence par secteur 0
79
80 ********************************
81 * Traitement d'un secteur
82 ********************************
83
022C: E6 3D 84
H082C
INC SECTOR
022E: A9 AB
85
LDA #$AB ; repositionne
compteur couple nibbles
0230: 85 01
86
STA CPT
0232: C6 00
87
DEC NB_SECT ; un secteur de moins
à charger
0234: F0 6D
88
BEQ H08A3 ; si 0, le compte
est bon -> boot 2
89
90 *-------------------------------
91 * Recherche markers secteur
92 *-------------------------------
93
0236: A2 60
94
LDX #$60 ; slot*16
0238: 18 95
H0838
CLC
; c=0 -> on commence par la phase adresse
96
0239: 08 97
H0839
PHP
; mémorise phase
98
023A: BD 8C C0 99
H083A
LDA HC08C,X ; lecture nibble
023D: 10 FB
100
BPL H083A
101
023F: 49 D5 102
H083F
EOR #$D5 ; 1er marker
0241: D0 F7
103
BNE H083A
104
0243: BD 8C C0 105
H0843
LDA HC08C,X ; lecture nibble
0246: 10 FB
106
BPL H0843
107
0248: C9 AA
108
CMP #$AA ; 2nd marker
024A: D0 F3
109
BNE H083F
110
024C: EA
111
NOP
024D: BD 8C C0 112
H084D
LDA HC08C,X ; lecture nibble
0250: 10 FB
113
BPL H084D
114
0252: C9 96
115
CMP #$96 ; 3eme marker
(test marker adresse par défaut)
0254: F0 09
116
BEQ H085F ; ok marker D5AA96
found (champ adresses)
117
0256: 28
118
PLP
; récupère phase
0257: 90 DF
119
BCC H0838 ; si on
était en phase adresse et que le 3eme
120
; marker n'est pas le bon, on recommence la
121
; recherche à partir du 1er marker adresse
122
0259: 49 AD
123
EOR #$AD ; phase data
-> check dernier marker
025B: F0 25
124
BEQ H0882 ; ok marker D5AAAD
found (champ datas)
125
126
; bad!
025D: D0 D9
127
BNE H0838 ; recommence tout
depuis phase champ adresse
128
129 *-------------------------------
130 * Analyse champ adresse
131 *-------------------------------
132
133 * On a trouvé les markers adresse. On analyse la suite.
134 * D5AA96
135 * XX XX ->
volume
codage 4x4 (2 nibbles)
136 * XX XX ->
track
codage 4x4 (2 nibbles)
137 * XX XX -> secteur physique codage 4x4 (2 nibbles)
138 * XX XX ->
checksum codage 4x4 (2
nibbles)
139 * D5AAAD
140
025F: A0 03 141
H085F
LDY #$03 ; skip volume
et track
0261: 85 40 142
H0861
STA $40 ; sauve
dernier octet reconstruit lu
143
0263: BD 8C C0 144
H0863
LDA HC08C,X ; 1A1B1C1D
0266: 10 FB
145
BPL H0863
146
0268: 2A
147
ROL
; 1er nibble octet en 4x4
0269: 85 3C
148
STA $3C ; A1B1C1D1
149
026B: BD 8C C0 150
H086B
LDA HC08C,X ; 1E1F1G1H
026E: 10 FB
151
BPL H086B
152
0270: 25 3C
153
AND $3C ; 2nd
nibble octet en 4x4
154
; = AEBFCGDH (octet reconstruit)
0272: 88
155
DEY
0273: D0 EC
156
BNE H0861
157
; après lecture 2 nibbles du secteur
0275: 28
158
PLP
; dépile état (en retard) avant phase data
0276: C5 3D
159
CMP SECTOR ; est-ce le bon secteur?
0278: D0 BE 160
H0878
BNE H0838 ; non, passe
à un autre secteur
161
027A: A5 40
162
LDA $40 ; dernier
octet reconstitué=track
027C: C9 01
163
CMP #$01 ; le code du
fboot doit se trouver en piste 1
027E: D0 B8
164
BNE H0838 ; pas la piste 1
-> anormal, recommence!
165
0280: B0 B7
166
BCS H0839 ; toujours. Signale
passage à phase data (c=1)
167
168 *-------------------------------
169 * Analyse champ data
170 *-------------------------------
171
172 * Dans un secteur normal de datas, il y a $156 (=342) nibbles
173 * plus un checksum. Le codage est en 6x2 et au final, on
174 * récupère 256 octets.
175 * Ici on en utilise 2*$AB=$156, c'est à dire le meme
chiffre
176 * mais le codage est trafiqué (2 nibbles pour un octet
mais ce
177 * n'est pas du 4x4). L'objectif de Chip Select était
d'une part
178 * de faire une protection mémoire (son fast boot n'est
pas
179 * lisible directement avec un éditeur de secteurs)
mais aussi
180 * en terme de rapidité, on grignote quelques parcelles
de
181 * temps en s'épargnant un denibblizing 6x2
forcément plus lent.
182 * Par contre, il y a une perte de place sur la piste 1:
183 * on ne récupère que $AB (=171) octets par
secteur.
184 * En chargeant 16 secteurs, on récupère
16*171=2736=$AB0 octets.
185 * La mèmoire correspondante est: $B000-$BAAF
186
0282: A4 03 187
H0882
LDY INDICE_WT ; reprend indice où on l'avait
laissé
188
189 * Lecture de 2 * $AB nibbles
190
0284: AE EC C0 191
H0884
LDX HC0EC ; lecture 1er
nibble (=offset)
0287: 10 FB
192
BPL H0884
193
0289: BD 00 02
194
LDA IN,X ; transco avec
les octets du programme
028C: AE EC C0 195
H088C
LDX HC0EC ; lecture 2nd
nibble (=offset)
028F: 10 FB
196
BPL H088C
197
0291: 1D 00 02
198
ORA IN,X ; mixage octet
(toujours avec code programme)
0294: 91 26
199
STA (ADR_LOAD),Y ; sauvegarde octet
200
; //nibble $96 = $C8
0296: C8
201
INY
202
; //nibble $97 = $D0
0297: D0 02
203
BNE H089B ; pas encore fin de
page
204
; //nibble $9A = $27
0299: E6 27
205
INC ADR_LOAD+1 ; adr implantation high +1
206
207
; //nibble $9B = $C6
029B: C6 01 208
H089B
DEC CPT ;
compteur-1
209
; //nibble $9D = $D0
210
; //nibble $9E = $E5
029D: D0 E5
211
BNE H0884 ; pas encore 2*$AB
nibbles
212
; //nibble $9F = $84
029F: 84 03
213
STY INDICE_WT ; sauve indice Y pour reprise prochain
secteur
02A1: F0 89
214
BEQ H082C ; toujours
215
02A3: 4C 00 B0 216
H08A3
JMP BOOT2 ; lance boot 2
217
218 *-------------------------------
219 * Signature texte <ABC> + trck 1
220 *-------------------------------
221
222 * Déplacement tete de lecture sur la piste 1
223 * La tete était actuellement en piste 0.
224
225
; //nibble $A6 = $8D
226
; //nibble $A7 = $E0
02A6: 8D E0 C0 227
H02A6
STA $C0E0 ; phase 0 off (slot
6)
228
; //nibble $AB = $C0
02A9: 8D E3 C0
229
STA $C0E3 ; phase 1 on
230
; //nibble $AC = $A9
231
; //nibble $AD = $30
02AC: A9 30
232
LDA #$30 ; délai
233
; //nibble $AE = $20
234
; //nibble $AF = $A8
02AE: 20 A8 FC
235
JSR WAIT
236
; //nibble $B2 = $E2
237
; //nibble $B3 = $C0
02B1: 8D E2 C0
238
STA $C0E2 ; phase 1 off
239
; //nibble $B4 = $8D
240
; //nibble $B5 = $E5
241
; //nibble $B6 = $C0
02B4: 8D E5 C0
242
STA $C0E5 ; phase 2 on
243
244 * Signature codée <ABC> en inverse
245
246
; //nibble $B7 = $20
247
; //nibble $B9 = $FC
02B7: 20 58 FC
248
JSR HOME
249
; //nibble $BA = $A0
250
; //nibble $BB = $05
02BA: A0 05
251
LDY #$05 ; indice de 1
à 5
252
; //nibble $BC = $18
02BC: 18 253
H08BC
CLC
254
; //nibble $BD = $98
02BD: 98 255
H08BD
TYA
; utilise l'indice comme valeur d'ajout
256
; //nibble $BE = $79
257
; //nibble $BF = $DF
02BE: 79 DF 02
258
ADC H02E0-1,Y ; à la signature elle meme
02C1: 99 B9 05
259
STA $05B9,Y ; directement sur
l'écran 40 colonnes
02C4: 88
260
DEY
02C5: D0 F5
261
BNE H08BC
02C7: 60
262
RTS
263
264 *-------------------------------
265
02C8: 00 00 00
266
DS 3,0 ;
not used
267
02CB: 00 268
H02CB
HEX 00 ;
nibble $CB = $00
269
02CC: 00
270
HEX 00 ;
not used
271
02CD: 00 272
H02CD
HEX 00 ;
nibble $CD = $00
02CE: 00 273
H02CE
HEX 00 ;
nibble $CE = $00
02CF: 00 274
H02CF
HEX 00 ;
nibble $CF = $00
275
02D0: 00 00 00
276
DS 3,0 ;
not used
277
02D3: 00 278
H02D3
HEX 00 ;
nibble $D3 = $00
279
02D4: 00 00
280
DS 2,0 ;
not used
281
282 * Liste "pratique" de nibbles car ils représentent
283 * toutes les possibilités pour les 4 derniers bits
284 * de l'octet à reconstituer.
285
02D6: 00 286
H02D6
HEX 00 ;
nibble $D6
02D7: 01 287
H02D7
HEX 01 ;
nibble $D7
288
02D8: D8
289
HEX D8 ;
not used
290
02D9: 02 291
H02D9
HEX 02 ;
nibble $D9
02DA: 03 292
H02DA
HEX 03 ;
nibble $DA
02DB: 04 293
H02DB
HEX 04 ;
nibble $DB
02DC: 05 294
H02DC
HEX 05 ;
nibble $DC
02DD: 06 295
H02DD
HEX 06 ;
nibble $DD
02DE: 07 296
H02DE
HEX 07 ;
nibble $DE
02DF: 08 297
H02DF
HEX 08 ;
nibble $DF
298
299 *-------------------------------
300
02E0: 3B FF FF 301
H02E0
HEX 3BFFFFFF39 ; signature <ABC> codée
02E3: FF 39
302
303 *-------------------------------
304
02E5: 09 305
H02E5
HEX 09 ;
nibble $E5
02E6: 0A 306
H02E6
HEX 0A ;
nibble $E6
02E7: 0B 307
H02E7
HEX 0B ;
nibble $E7
308
02E8: 11
309
HEX 11 ;
not used
310
02E9: 0C 311
H02E9
HEX 0C ;
nibble $E9
02EA: 0D 312
H02EA
HEX 0D ;
nibble $EA
02EB: 0E 313
H02EB
HEX 0E ;
nibble $EB
02EC: 0F 314
H02EC
HEX 0F ;
nibble $EC
315
316 * Liste "pratique" de nibbles car ils représentent
317 * toutes les possibilités pour les 4 premiers bits
318 * de l'octet à reconstituer.
319
02ED: 00 320
H02ED
HEX 00 ;
nibble $ED
02EE: 10 321
H02EE
HEX 10 ;
nibble $EE
02EF: 20 322
H02EF
HEX 20 ;
nibble $EF
323
02F0: C4 D9
324
HEX C4D9 ; not used
325
02F2: 30 326
H02F2
HEX 30 ;
nibble $F2
02F3: 40 327
H02F3
HEX 40 ;
nibble $F3
02F4: 50 328
H02F4
HEX 50 ;
nibble $F4
02F5: 60 329
H02F5
HEX 60 ;
nibble $F5
02F6: 70 330
H02F6
HEX 70 ;
nibble $F6
02F7: 80 331
H02F7
HEX 80 ;
nibble $F7
332
02F8: F8
333
HEX F8 ;
not used
334
02F9: 90 335
H02F9
HEX 90 ;
nibble $F9
02FA: A0 336
H02FA
HEX A0 ;
nibble $FA
02FB: B0 337
H02FB
HEX B0 ;
nibble $FB
02FC: C0 338
H02FC
HEX C0 ;
nibble $FC
02FD: D0 339
H02FD
HEX D0 ;
nibble $FD
02FE: E0 340
H02FE
HEX E0 ;
nibble $FE
02FF: F0 341
H02FF
HEX F0 ;
nibble $FF
342
343
SAV BOOT1.APRES.EOR
Object saved as BOOT1.APRES.EOR,A$0800,L$0100
--End assembly, 256 bytes, Errors: 0
Symbol table - alphabetical order:
ADR_LOAD
=$26
BOOT1
=$0800 BOOT1_GO
=$020F
BOOT2 =$B000
CPT
=$01
H02A6 =$02A6
? H02CB
=$02CB ?
H02CD =$02CD
? H02CE
=$02CE ?
H02CF =$02CF
? H02D3
=$02D3 ?
H02D6 =$02D6
? H02D7
=$02D7 ?
H02D9 =$02D9
? H02DA
=$02DA ?
H02DB =$02DB
? H02DC
=$02DC ?
H02DD =$02DD
? H02DE
=$02DE ?
H02DF =$02DF
H02E0
=$02E0 ?
H02E5 =$02E5
? H02E6
=$02E6 ?
H02E7 =$02E7
? H02E9
=$02E9 ?
H02EA =$02EA
? H02EB
=$02EB ?
H02EC =$02EC
? H02ED
=$02ED ?
H02EE =$02EE
? H02EF
=$02EF ?
H02F2 =$02F2
? H02F3
=$02F3 ?
H02F4 =$02F4
? H02F5
=$02F5 ?
H02F6 =$02F6
? H02F7
=$02F7 ?
H02F9 =$02F9
? H02FA
=$02FA ?
H02FB =$02FB
? H02FC
=$02FC ?
H02FD =$02FD
? H02FE
=$02FE ?
H02FF =$02FF
H0817
=$0217
H082C
=$022C
H0838
=$0238
H0839 =$0239
H083A
=$023A
H083F
=$023F
H0843
=$0243
H084D =$024D
H085F
=$025F
H0861
=$0261
H0863
=$0263
H086B =$026B
? H0878
=$0278
H0882
=$0282
H0884
=$0284
H088C =$028C
H089B
=$029B
H08A3
=$02A3
H08BC =$02BC
? H08BD =$02BD
HC08C
=$C08C ?
HC0E0 =$C0E0
? HC0E2
=$C0E2 ?
HC0E3 =$C0E3
? HC0E5
=$C0E5
HC0EC
=$C0EC
HOME
=$FC58
IN =$0200
INDICE_WT
=$03
NB_SECT
=$00
SECTOR
=$3D
WAIT =$FCA8
Symbol table - numerical order:
NB_SECT
=$00
CPT
=$01
INDICE_WT
=$03
ADR_LOAD =$26
SECTOR
=$3D
IN
=$0200 BOOT1_GO
=$020F
H0817 =$0217
H082C
=$022C
H0838
=$0238
H0839
=$0239
H083A =$023A
H083F
=$023F
H0843
=$0243
H084D
=$024D
H085F =$025F
H0861
=$0261
H0863
=$0263
H086B =$026B
? H0878 =$0278
H0882
=$0282
H0884
=$0284
H088C
=$028C
H089B =$029B
H08A3
=$02A3
H02A6
=$02A6
H08BC =$02BC
? H08BD =$02BD
? H02CB
=$02CB ?
H02CD =$02CD
? H02CE
=$02CE ?
H02CF =$02CF
? H02D3
=$02D3 ?
H02D6 =$02D6
? H02D7
=$02D7 ?
H02D9 =$02D9
? H02DA
=$02DA ?
H02DB =$02DB
? H02DC
=$02DC ?
H02DD =$02DD
? H02DE
=$02DE ?
H02DF
=$02DF
H02E0 =$02E0
? H02E5 =$02E5
? H02E6
=$02E6 ?
H02E7 =$02E7
? H02E9
=$02E9 ?
H02EA =$02EA
? H02EB
=$02EB ?
H02EC =$02EC
? H02ED
=$02ED ?
H02EE =$02EE
? H02EF
=$02EF ?
H02F2 =$02F2
? H02F3
=$02F3 ?
H02F4 =$02F4
? H02F5
=$02F5 ?
H02F6 =$02F6
? H02F7
=$02F7 ?
H02F9 =$02F9
? H02FA
=$02FA ?
H02FB =$02FB
? H02FC
=$02FC ?
H02FD =$02FD
? H02FE
=$02FE ?
H02FF
=$02FF
BOOT1
=$0800
BOOT2 =$B000
HC08C
=$C08C ?
HC0E0 =$C0E0
? HC0E2
=$C0E2 ?
HC0E3 =$C0E3
? HC0E5
=$C0E5
HC0EC
=$C0EC
HOME
=$FC58
WAIT =$FCA8
Retour sommaire
Message Chip Select et historique des Fast Boots.
Le programme affichant le message s'appelle "-READ ME".
Il utilise des caractères interdits par ProDOS.
Paranoïa oblige, bien entendu les informations du programme ont
été modifiées directement dans le catalog ProDOS
(bloc 2) pour miner le travail de récupération ou
d'altération de son texte.
J'ai du shunter tout ça pour récupérer le message
au propre ;-)
Le texte de READ.ME est codé par un EOR évolutif à
partir d'une valeur qui n'est présente que lorsque le programme
est lancé depuis le menu du FBOOT (à savoir avec la
valeur $80 à l'adresse $05).
Après exécution le programme fait un CALL $0000 et
retourne ainsi dans la gestion du catalog du FBOOT de Chip Select.
le programme débute en $8000 et a une longueur de $103E.
Les datas du texte sont à partir de $8059.
En catalogue sur la disquette de source, il y a la version d'origine et
une version sans le codage avec le texte en clair.
Cette version peut être lancée directement avec la
commande BRUN.
J'ai aussi viré le bruitage, le défilement est plus
rapide et ininterrompu..
Le texte est prévu pour s'afficher sur un écran en mode
40 colonnes.
----------------------------------------
D'ABORD QUELQUES MESSAGES PERSONNELS
UN GRAND BONJOUR A
- CTHULHU,
- YOG-SOTHOTH,
- DAGON ...
ET TOUS LES AUTRES MEMBRES DU CMS
- DOM,CHRIS ... DE COPYART
- NUMERO 6
- LOT & TMM
- MISTER Z ET MERLIN
- ALDO RESET
- JPL ET MICMAC
SANS OUBLIER CE CHER SOFTMAN
- LE COCHONOU CRACK BAND
- TEUTON HEROIQUE
- THE COPIRATE
- CAPTAIN SHOCK
- CLING CLANG CLUNG
- EM FROM US-IMPORT
- BILL
- BERNARD, LAURENT,HERVE..
- SERGE, DENIS, MICHAEL
- PATRICK,
- BRUNO,JEAN,JEAN-FRANCOIS,FRANCK
- MARC,JD BUG,TBK,HUGO,CONCOMBRE..
- FRANCOISE, AGATHE, VERONIQUE
- SABINE, JACQUELINE,CATHY...
- LE GUIOCHON FAN CLUB
- ET BIEN SUR TOUS LES MEMBRES DE
-= A B C =-
*** ERIC IRQ ***
*** THE WILDMAN ***
UN GRAND BONJOUR A TOUS..
----------------------------------------
ET MAINTENANT LES CHOSES SERIEUSES !!
J'AI ENTENDU DIRE PAR UN DENOMME
GODFATHER QUE JE N'AURAI POINT FAIT DE
FAST-BOOT. SOIT, VU QU'IL DONNE
L'IMPRESSION D'AVOIR PRIS LE FILM EN
ROUTE VOICI POUR SA GOUVERNE UNE PETITE
RETROSPECTIVE DES FAST-BOOT
D'ABORD L'ORIGINE DE CETTE ROUTINE DE
CHARGEMENT RAPIDE :
ELLE VIENT EN GRANDE PARTIE DE PASCAL
ET A ETE RECUPEREE PAR ELECTRONIC ART
POUR SES JEUX .
DE MEME ON LA RETROUVE SOUS UNE FORME
DIFFERENTE DANS LE DRIVER DISK II PRODOS
JE N'AI RIEN INVENTE JE LE RECONNAIS
BIEN VOLONTIERS AYANT JUSTE MODIFIE
CETTE ROUTINE POUR LA FAIRE CONVENIR
A MES BESOINS.
(MAINTENANT ELLE NE RESSEMBLE PLUS
TELLEMENT A LA ROUTINE D'ORIGINE)
VU QUE L'ON PARLE DE FBOOT IL EST
INTERESSANT DE REMARQUER QUE LA
DENOMINATION FBOOT OU FAST-BOOT A ETE
TROUVEE PAR ERIC ET MOI EN ANALOGIE AU
SPEEDY BOOT DE MICMAC & THE SOFTMAN
(REGARDEZ LA PRESENTATION DES DEUX )
EN EFFET C'EST LA VUE DU SPEEDY BOOT QUI
NOUS A DONNE L'ENVIE DE FAIRE NOTRE
PROPRE COMPILATION DE COPIEURS A
CHARGEMENT RAPIDE. LE PREMIER ESSAI NE
FUT PAS TERRIBLE.UTILISANT LA RWTS IL
N'AVAIT DE FBOOT QUE LE NOM.
PUIS ERIC A MIS LA MAIN SUR LA ROUTINE
DE CHARGEMENT DE GO ONE ON ONE.
ROUTINE QUI MODIFIEE ET AMELIOREE
EST AU CENTRE DE TOUS MES FBOOTS, DE
CETTE REVELATION EST APPARU
COURANT 84 MON PREMIER FBOOT (TM)
LE COPY DISK BCB, CONJOINTEMENT AVEC
CELUI D'ERIC : COPYDISK DCA.
POUR EN REVENIR A LA PARTIE HISTORIQUE
LE PREMIER FAST-BOOT (A MA CONNAISSANCE)
EST LE SPEEDY-BOOT DE MICMAC AND THE
SOFTMAN EN 1983
ARRIVE DERRIERE LE 1ER FBOOT TEXTE DE
LUKE SKYWALKER (EN 84).
C'EST SEULEMENT EN 84 QUE MON 1ER FBOOT
APPARAIT
CE FBOOT TRES CARACTERISTIQUE AU NON
ARRET DU DRIVE A ETE LE PLUS POMPE
JE L'AI RETROUVE PRESQUE NON MODIFIE
(L'ARRET DU DRIVE EN PLUS...) SOUS
LA DENOMINATION TSUNOO FROM TROLL & CO
ZORRO FBOOT.....
DE MEME M JL LEBRETON LA OBLIGEAMMENT
UTILISE POUR CERTAINS DE SES JEUX ...
(MEME LES POMMES DE TERRE ....
LE MUR DE BERLIN...
LA FEMME QUI NE SUPPORTAIT)
EN LAISSANT MEME LA ROUTINE DE CHECKSUM
DE LA PAGE GRAPHIQUE
TOUJOURS VERS LA MEME EPOQUE
UN DENOMME FREDERIC MUTTER EN A PUBLIE
UN DUMP HEXA DANS HEBDOGICIEL SOUS LE
NOM DE FBOOT MAKER. A QUAND LA PERSONNE
LEUR ENVOYANT UN DUMP HEXA DU LOCKSMITH
M'ENFIN ? BON JE M'EGARE ...
QUELQUES MOIS PLUS TARD JE SORS UN
NOUVEAU FBOOT SOUS LE NOM DE COPY DISK
ABC.
85 - SORTIE DE L'HYPERQUICK LOADER DE
TROLL & CO LARGEMENT POMPE SUR LE
FBOOT DE LUKE SKYWALKER
VERS LA MEME EPOQUE LE SPEEDY
BOOT EST PUBLIE PAR P GUIOCHON SOUS LE
NOM DE GOLD-QQCHOSE DANS GOLDEN
ET UN POMPEUR UN...
D'AILLEURS EN PARLANT DE POMPEUR DANS
L'HYPER QUICK LOADER DU 17 JUIN 85
ON A DROIT AUX AVEUX COMPLETS DE TSUNOO
85 C'EST AUSSI LA SORTIE DE MON FBOOT
CONTENANT LE COPY II+ 5.0 ET UN DOS
COMME QUOI...
BON J'ARRIVE A LA FIN DE MON PETIT
RAPPEL AVEC MON DERNIER FBOOT EN DATE :
LE FBOOT 2.0
LE SEUL FBOOT PRODOS (POUR L'INSTANT)
UTILISANT DES FICHIERS PRODOS NORMAUX
ET FONCTIONNANT AVEC DEUX DRIVES
LE PIED QUOI !
MAINTENANT GODFATHER SI TU N'AS PAS
COMPRIS C'EST QUE TU ES REELLEMENT
BOUCHE.
SALUT A TOUS.
-------------- > CHIP SELECT A.B.C.
PS: LISEZ DONC LE FICHIER DOC..
AVANT DE RALER.!!
BAISEZ UNE MOUCHE POUR POURSUIVRE
Retour sommaire
Doc du Fast Boot ProDOS.
FBOOT 2.0 REVISION A
COPYRIGHT CHIP SELECT
------------------
! DOC PROVISOIRE !
------------------
]1 RAJOUT DE PROGRAMMES .
Pour ce faire utiliser tout simplement le
filer Prodos ou bien le
copy II+ 6.X;
Tous fichier binaire prodos est rajoutable au
Fboot et apparaitra
au catalogue s'il est verrouillé
]2 CREATION D'UNE DISQUETTE FBOOT .
- Copiez cette disquette avec le locksmith
(fast backup),
- Deletez le disk avec le copy 2+
- Editez le bloc 6 (Bit map) et marquez
occupé les blocs
0 à 15 ( deux premiers
octets à zéro )
- Modifiez la page de boot si
nécéssaire
- Installez les nouveaux fichiers avec un
filer.
]3 COMMANDES DU FBOOT .
^S : Son On/Off
^B : Sortie sous basic (sans le
basic.system)
ESC : Equivalent du quit prodos si
prodos est chargé
Fleches droite gauche
:
sélectionne le drive et lit son catalogue
Lettres entre crochets
: Run le
programme
]4 ORGANISATION PHYSIQUE .
Bloc 0 : Secteur de boot
Bloc 1
Bloc 2 : Catalogue ProDOS
à 4
Bloc 6 : Bit map
Bloc 7 : page texte de boot et
paramettres
Piste 1 : Image du Fboot ( Bloc 8 à 15 )
Description des blocs 1 et 7
Représente une page texte
Block 1 $400-$5FF
7 $600-$7FF
la premiere et la derniere ligne de cette page
sont affichées sur
le catalogue à leur place respective.
le reste de la page est affichée
à la place du catalogue suivant
les options.
Options
$478 : numéro de piste à
éviter $FF aucune piste
ex
$11 pour éviter le catalogue Dos.
$479 : $FF : Lors du boot lance le premier
programme verrouillé du
catalogue.
$00
ne le lance pas.
$47A : $00 ne lance rien.
code
de la touche du programme à charger au
boot
si ascii negatif run sinon load
$C1
run A
$41
load A.
$47B : $FF affiche la page texte se trouvant
Bloc 1 et 7, à la place du catalogue.
$00
ne l'affiche pas affiche le catalogue.
Nota
: le fait d'appuyer sur une fleche
réaffiche le catalogue.
$47C : $FF supprime les animations (et le
bruit)
$00
met les animations.
]5 AMELIORATIONS FUTURES .
- Reconnaissance et chargement correcte des
programmes basics.
- Acces au fboot à partir du basic via
l'ampersand.
- Acces aux sous-catalogues.
- Reconnaissance de l'Uni disk et de la
Ram-work.
- Mise en place d'une routine de sauvegarde
rapide.
- Mise en place dans le code Quit.
et pourquoi pas
- reconnaissance de la souris.
Bon fast Boot à tous .!!!!
CHIP SELECT
from the Association of Broadcasting Crackers 1986.
NOTA :
Si vous voulez charger automatiquement le prodos au boot il faut que
le fichier FBOOT.SYSTEM soit le premier fichier system de la disquette.
Signalez moi toutes bugs dans ma Bal sur HG (6115)
nom: chipselect
Petite remarque :
Utilisation commerciale INTERDITE sans mon
autorisation.
Ceci est particulierement valable pour M Lebreton & Co.
Retour sommaire
