Demandes d'évolution de FASTDSK

Date création: 29/04/2009.
Dernière mise à jour: 04/05/2009.

Cette page fait suite aux derniers échanges que j'ai eu avec mon ami Thierry (aka Thry2).
Elle regroupe toutes les demandes d'évolution ou les bogues constatés depuis la première version (voire même avant pour certaines fonctions qui n'avaient pas pu être implémentées à temps).

Je prendrais en charge ces évolutions dès la fin du projet VFAT Explorer.
Il n'y a pas vraiment d'ordre de priorité si ce n'est pas nécessité du bon fonctionnement sur IIGS et la possibilité d'interrompre le process en cours de route.



*** DEBUT ***

1) Mode "Infinite Read"

Demandeur: Deckard
Détail du changement:

Il arrive des fois que sur une disquette "instable" un secteur est lu correctement (=checksum valide) qu'à la dernière tentative. Dans ce cas là, vous êtes content.
Mais cela veut dire qu'il doit aussi arriver des fois où FASTDSK abandonne alors que le secteur à problème aurait pu être enfin lu à la tentative suivante.
S'il s'agit pour vous d'une disquette importante, il est clair que vous souhaitez absolument que FASTDSK lise autant de fois que nécessaire, l'objectif le plus important ici n'étant pas la rapidité mais l'absolue nécessité de récupérer toutes les données.

Il faut donc introduire un nouveau paramètre dans la configuration qui s'appellera "INFINITE READ MODE" (par defaut cette option sera à "N").
En activant ce paramètre (valeur à "Y"), FASTDSK relira en boucle la piste jusqu'à ce que le résultat soit okay.
Il ne sera possible de mettre cette valeur à "Y" que si le paramètre "USE CHECKSUM" est à "Y" (pour rester cohérent...)

Un secteur définitivement mort, cela arrive malheureusement. Et si la malchance s'abat sur vous, FASTDSK ne doit pas resté bloqué sur cette piste. Vous aurez donc la possibilité de forcer le passage à la piste suivante en appuyant sur la touche RETURN. En pressant cette touche, vous demandez à FASTDSK de ne pas insister et il ne gardera de la piste que ce qu'il a pu lire. Il passera alors à la piste suivante s'il y en a encore à traiter.
 

2) Option "Quarter Track"

Demandeur: Deckard
Détail du changement:

Même avec l'option "INFINITE READ MODE", la récupération des données peut échouer si la disquette est dans un sale état.
Plutôt que de la jeter tout de suite à la poubelle, il y a encore une possibilité, qui même si elle ne garantie pas le résultat mérite tout de même d'être essayée.
Comme le signalait déja JPL dans cette log de 2004, il est possible de tirer profit des caractéristiques de la tête de lecture/écriture du drive.
Par exemple imaginons que sur une disquette la piste $05 ne puisse pas être lue correctement, il faut savoir que quand elle a été écrite, l'information a aussi été enregistrée sur + ou - 0,25 piste. L'idée est donc d'aller voir soit sur la piste $04.75 soit sur la piste $05.25 s'il y a quelque chose à prendre.

Il faut rajouter une nouvelle option dans le paramétrage: "USE QUARTER TRACK" avec les valeurs possibles "N" (non), "-" (quart de piste précédent) ou "+" (quart de piste suivant).
L'idée est donc au début du process de faire ce décalage et de lire le restant de la disquette avec un pas normal de 1.

Pour "N", on lira normalement $00, $01, $02, $03, .., $21, $22
Pour "-", on lira: $00, $00.75, $01.75, $02.75, ..., $20.75, $21.75
Pour "+", on lira: $00.25, $01.25, $02.25, $03.25, ..., $21.25, $22 (ou $22.25)

Pour vous rafraîchir la mémoire sur les 1/4 de pistes, ci-joint un article de la revue Computist:

Quarter Track
 Quarter Track
 Quarter Track


3) Interruption du processus pendant son exécution

Demandeur: Thry2
Détail du changement:

Lorsqu’une disquette en cours de traitement est en mauvais état, le drive n'arrive pas à la lire correctement et l'écran se remplit de caractères '*' signalant les problèmes. Avec les relectures successives, le traitement complet prend du temps et il n'est pas prévu de pouvoir l'interrompre. L'utilisateur est donc obligé d'attente que la face complète soit traitée.
L'idée est de pouvoir interrompre à tout moment le processus quand l'utilisateur le souhaite (par exemple s'il estime que la disquette est trop pourrie pour en tirer quoi que ce soit, si l'utilisateur ne veut pas créer un .DSK s'il y a ne serait ce qu'un secteur en erreur, ...)

Le modification consiste à prendre en compte la touche ESC pendant le traitement et à remettre la situation initiale, ce qui n'est pas toujours à faire de la même façon. En effet, en fonction du paramétrage, de la machine (128k ou 256k), du moment où l'interruption est demandée, il peut être nécessaire de:

- supprimer la partie du .DSK déja créée.
- décrémenter le numéro du disk ou de la face si l'option "USE STD NAME" est activée.

En plus cette interruption n'écrirait rien dans la log (si l'option "TRACE LOG" est à "Y") et à la création suivante, il se serait pas nécessaire de faire le contrôle sur la disponibilité de l'espace disque cible.

Pour ce faire, il faut que le programme tienne à jour une valeur (un octet) qui donnera le statut atteint à chaque phase et en cas de ESC le programme annulera les étapes précédentes pour revenir au point de départ.


4) Information du numéro de volume

Demandeur: Deckard
Détail du changement:

Le champ adresse de chaque secteur contient une information de volume qui a été fixé au moment du formattage.
Ce numéro est normalement toujours le même pour une face donnée et il peut être utilisé par un soft multi-faces pour identifier quelle est la face courante dans un drive.
Afin qu'une trace de cette information soit conservée, il faut l'enregistrer dans le fichier de log.
Comme cela quand on passe ses .DSK sur un PC ou un MAC, on peut facilement les transformer en .NIB avec dsk2nib si le volume n'est pas standard.


5) Bogues sur Apple IIGS

Demandeur: Thry2
Détail du changement:

Dans la documentation, il est indiqué que FASTDSK fonctionne avec les machines 8 bits.
Mais sur un GS, il y a plusieurs problèmes révélés par Thry2 après des tests réalisés sur le GS rom 03 (donné par JPL) complété des éléments suivants: Ram 6Mo / RamFAST 3.01e + Disque Dur / Zip 10MHz / DuoDisk.

Les constats:

- Seulement 128K reconnu, donc la lecture ne se fait pas en une seule passe.
- Les .DSK créés ne fonctionnent pas sur Applewin!

Note de Deckard: je n'ai pas de GS sous la main actuellement mais j'ai fait des tests avec KEGS32 (pleine vitesse et 1Mhz) et j'ai comparé les .DSK produits avec l'original.
Même chose avec Sweet16 sur Mac.

A chaque fois le Fast Compare de Sam indique que pour chaque secteur du .DSK les octets de la fin du secteur (d'un indice variable - souvent $AC/$B3/$B4 - à $FF) ne correspondent pas!

Thry2 a aussi fait de nouveaux tests en parallèle sur des vrais GS avec des configs variables (modes FAST/NORMAL, ROM 01/03, Ram carte mère/GS Ram Plus 6 mb, accélération Zip GSX/sans) avec les faces 1 de Muryden 1 et Max A Gaz Greatest Hits. Le constat est le même. Avec en plus selon les configs des différences entre les .DSK générés toujours au niveau de quelques octets en fin de secteurs pour les pistes $00 à $0F (c'est à dire la 1ère passe sur GS) et la plupart du temps uniquement pour le 1er disk traité à chaque config (face "Front").


Il est très curieux que le programme fonctionne sur IIe mais pas sur GS.

J'ai fait quelques recherches sur internet et ai trouvé une page qui se rapproche du problème.
Il s'agit d'un numéro de la série des newsletters Apple Assembly Line écrite par Bob Sander-Cederlof.
La référence du numéro en question est: volume 7 issue 10.
L'article s'intitule "Another ProDOS-8 Bug in the IIgs" et parle d'une altération des octets de chaque fin de page d'un fichier écrit par ProDOS depuis l'application S-C Macro Assembler (S-C Software Corporation).

Quelques extraits:

... The code at fault is the (ProDOS) subroutine which transfers bytes of data from the caller's data buffer into the file buffer...
... It turns out ProDOS was only indirectly at fault. Both the old and the new versions of ProDOS-8 show the same failure, but it is due to the 65816 processor rather than any changes to the ProDOS code...
... Both versions of ProDOS worked correctly on the //e, and both failed on the IIgs...

Pour en avoir le coeur net, j'ai fait le test d'interrompre FASTDSK par reset après la lecture de quelques pistes et ai regardé en mémoire le contenu des pages chargées.
DAMNED!!!!
Les données en mémoire ne sont pas bonnes, ce qui écarte le cas de Bob où c'est au moment de l'écriture que les données sont altérées!
Pourtant  FASTDSK ne signale pas d'erreur de checksum, ce qui devrait être le cas s'il y avait un problème de timing dans la routine critique (du point de vue des cycles) RDSECDTA.S (par exemple pour le traitement du "top third buffer" qui produit les octets de $AC à $FF): le checksum final de chaque secteur est correct sur toutes les pistes!! 

Peut-être que le problème est dû à l'usage de la page 0 que le programme utilise pour de nombreuses informations.
Il me faut faire d'autres tests pour cibler le problème. Si déjà je savais s'il y a un débugger embarqué dans les émulateurs GS comme c'est le cas pour l'émulo 8 bits Applewin, ça me permettrait d'aller plus vite dans mes recherches en comparant le process sur un émulateur 8 bits et un 16 bits.
Tiens au fait, je me rappelle que la routine de lecture a été reprise dans ADT Pro. Il faudrait que je regarde si ça passe sur GS et le cas échéant comparer pour voir ce qui a été modifié...

A SUIVRE...

Mise à jour du 04/05/2009: bon j'ai trouvé. Il s'agit d'un disfonctionnement dû au processeur 65816 qui agit différemment du 6502/65c02 en cas de débordement de bank mémoire (et ce même en mode émulation). La routine RDSECDTA.S utilise un buffer NBUF2 en page 0 (de $AA à $FF) et pour le top third buffer (morceau du secteur lu), il y a une instruction LDX $FFFE,Y (correspondant à NBUF2-$AC) avec Y[$AC,$FF].
Sur IIe, la lecture correspondante se fait en page 0 de la mémoire principale (bank 0) et sur IIGS, en page 0 de la mémoire auxliaire (bank 1).
La solution a consisté à remplacer l'instruction par un LDX $FE,Y.
A noter par ailleurs que Merlin 8 n'est pas cool. Il a une option spéciale pour forcer l'adressage absolu (en mettant un caractère ":" après l'opcode) car en théorie c'est l'adressage en page zéro qui est par défaut. Seulement dans mon source, il refuse de faire un adressage en page zéro quand il évalue NBUF2-$AC...
Le programme est corrigé avec les indications de David Empson et j'attends les ultimes tests de Thry2 pour diffusion.


6) Problématique de la gestion du clavier

Demandeur: Thry2
Détail du changement:

FASTDSK fait un clear keyboard avant chaque saisie de touche et c'est génant quand on cherche à anticiper la prochaine touche à enfoncer.
Par exemple, quand le programme vérifie la taille dispo sur le volume stockant les .DSK, il met un certain un temps. Si l'utilisateur appuie sur "espace" pendant qu’il vérifie la taille dispo de façon à ce que la création du .DSK se lance de suite après sa vérif, ca n’est pas pris en compte. Il faut retaper et c’est une perte de temps !!!! (C’est la meme chose pour le lancement du processus ou en fin de processus)...
Avec Locksmith FDB et 2 drives : l'utilisateur lance la copie en appuyant 2 fois sur espace: le programme lit l’original ; une fois la lecture de l’original achevée, il lance la copie, l'utilisateur en profite pour changer l’original par la disquette suivante puis il ré appuie sur espace; ce qui fait qu’une fois que le copieur a finit d’écrire la copie, il relance la lecture de l’original et ainsi de suite : il n’y a pas de temps mort !!!

Note de Deckard: il y a effectivement la séquence LDA #0,  STA $C000 et BIT STROBE en début de routine WAITKEY.S, ce qui annule la saisie.
Il ne faudrait pas que FASTDSK le fasse pendant ce cycle de process. Uniquement pour le reste.


7) Modification de la table de translation

Demandeur: JPL et Deckard
Détail du changement:

JPL a rencontré un problème en effectant un changement de markers mais je n'ai pas plus de détail.
Parallèlement à cela, certains softs ont des protections basées sur la modification de la table de translation des nibbles valides (64 nibbles de $96 à $FF) en octets contenant 6 bits significatifs (format XXXXXX00). Ce qui fait qu'avec une table normale, les informations ne sont pas décodées comme il faudrait et les octets restitués n'ont aucun sens.

Il faut donc ajouter un paramétrage donnant accès à cette liste de translation pour modifier l'ordre à sa guise.

Il y a un cours de dépombage de Godfather qui parle de cela: le numéro 17.


8) Saisie manuelle du nom d'un .DSK

Demandeur: Thry2 & Deckard
Détail du changement:

Lorsque le nom du .DSK cible doit être saisi manuellement (en mode "USE STD NAME" = 'N'), l'extension .DSK doit être rajoutée automatiquement.
Ce n'est pas à l'utilisateur de saisir ce suffixe.
La taille de saisie du nom doit de ce fait être limitée à 11 caractères (au lien de 15 actuellement).

Par défaut, il faut préafficher le nom précédemment utilisé (s'il y en a un). Ceci est utile quand par exemple on est en train de créer des .DSK pour un soft qui tient sur plus d'une face. Il suffit juste de rajouter de quoi identifier la face en question.

En complément au point précédent, à n'importe quel moment lors de la saisie du nom, en tapent CTRL-X, le nom en cours est ré-initialisé. Par exemple si le soft qui fait plusieurs faces a été passé, le pré-affichage est toujours actif et comme on veut passer au soft suivant qui n'a rien à voir, avec cette touche on nettoie vite fait le masque de saisie.


9) Identification des faces

Demandeur: Thry2
Détail du changement:

La méthode la plus rapide pour la création de .DSK est d'utiliser l'option "USE STD NAME" (valeur = "Y").
On génère ainsi une série d'images disques avec des noms formattés.
Pour bien faire les choses, quand on passe ces .DSK sur une machine moderne (PC ou MAC), il faut modifier le nom afin d'y intégrer le contenu réel.
Par exemple si FASTDSK a généré une image DG00132F.DSK pour le jeu Sammy Lightfoot, l'idéal est de le renommer DG00132F_Sammy_Lightfoot.DSK sur sa bécane récente pour avoir à la fois la référence et le contenu (afin de faciliter les recherches par la suite avec spotlight par exemple).

Pour générer les noms formattés, FASTDSK utilise actuellement les lettres 'F' (pour Front) et 'B' (pour Back) afin d'identifier les 2 faces d'une disquette.
Or quand on transfert tous les .DSK créés sur l'Apple II vers un PC ou un MAC, l'OS moderne les trie la plupart du temps sur le nom en ordre croissant.
Ce qui fait que les faces back se retrouve avant les faces front (le caractère 'B' se trouvant avant le caractère 'F'), ce qui n'est pas pratique.
Afin d'avoir un tri plus propre, les lettres à utiliser sont 'A' (face 1) et 'B' (face 2).


10) Précision sur la ligne de statut des pistes

Demandeur: Thry2
Détail du changement:

L'affichage de l'évolution de la création du .DSK ressemble beaucoup au Locksmith Fast Disk Backup (FDB).
A quelques détails d'affichage près, notamment sur la ligne de statut des pistes.
Avec FDB, la statut de track indique "," ou ";" quand il a fallu lire plusieurs fois un ou plusieurs secteurs d'une piste.
Mais la doc de la version 6.0 (pour FDB et pour l'option Verify) ne donne pas de précision sur les règles de gestion: si c'est à partir du nombre de lectures, du nombre de secteurs, etc...
Il serait intéressant d'avoir des statuts intermédaires entre "." et "*" dans FASTDSK pour les utilisateurs qui ne regardent que la synthèse des pistes ou qui ne considèrent un .DSK comme bon que si tout a été lu du 1er coup.

Note de Deckard: ce qu'il faut savoir, c'est que le checksum d'une manière générale ne garantie pas un 100% d'exactitude. Il arrive que 2 erreurs combinées donnent au final un checksum bon. Par exemple si tu passes 2 fois 1 disquette un peu foireuse mais pour laquelle la copie a été donnée comme bonne (après x essais), si tu les compares avec Fast Compare de Sam, tu peux avoir des écarts. Par exemple des $80 sur un secteur d'un .DSK et des $00 dans le même secteur de l'autre .DSK.


11) Précision du détail d'une erreur sur secteur

Demandeur: Deckard
Détail du changement:

Dans la routine de traitement d'un secteur, plusieurs anomalies peuvent survenir mais pour une erreur "fatale", FASTDSK se contente d'indiquer une erreur générique avec la lettre "*".
Afin de se rapprocher de Locksmith FDB, il faudrait donner le détail suivant:
- erreur champ addresse: mettre "A" au lieu de "*".
- erreur champ data: mettre "D" au lieu de "*".


12) Bogue numéro de drive

Demandeur: Thry2
Détail du changement:

Dans la configuration, il est possible de choisir le drive 2 pour le slot 6.
Mais au moment où on veut créer un .DSK, quand on appuie sur la touche "G" (Go), le programme demande d'insérer la disquette dans le drive 1 (message "INSERT DISK IN S6 D1".
A part ce bogue d'affichage, le drive 2 est bien pris en compte et c'est avec lui que se fait la lecture.
C'est juste un problème d'affichage.


13) Reset du fichier de configuration

Demandeur: Thry2
Détail du changement:

Cette nouvelle option doit permettre de remettre les valeurs par défaut.

 
14) Génération du fichier de configuration

Demandeur: Thry2
Détail du changement:

Quand le fichier de configuration FASTDSK.CONF est absent, le lanceur system doit en créer un avec les valeurs par défaut plutôt que de s'arrêter.


15) Cohérence de l'option "USE STD NAME"

Demandeur: Thry2
Détail du changement:

Quand l'utilisateur choisit "N" pour cette option, il ne faut plus que soit accessible le détail du format du nom (dans les zones dessous).
La flèche "DOWN" (bas) doit alors passer directement au champ de saisie "TRACE LOG".


16) Cohérence de touche

Demandeur: Thry2
Détail du changement:

Plutôt que d'utiliser la touche "G" (Go) pour lancer le process depuis le menu principal, utilisation de la touche espace.
Il suffira de faire 2 fois "espace" pour créer un .DSK.


17) Affichage CTRL-F en décimal

Demandeur: Thry2
Détail du changement:

L'option d'affichage du nombre de blocks libres restant sur le volume accueillant les .DSK est en hexa (message de la forme: FREE=$XXXX/$YYYY).
Ces valeurs seraient plus lisibles en mode décimal.


18) Documentation sur la disquette

Demandeur: Thry2
Détail du changement:

Comme il y a de la place sur la disquette (ou le .DSK), pourquoi ne pas inclure la doc française dessus (celle du site) au format .txt, comme le fait par exemple le soft Shrinkit ?


19) ré-écriture du programme avec des Overlays

Demandeur: Deckard
Détail du changement:

Toutes les modifications et ajouts demandés vont grossir la taille du binaire.
Et je ne pense pas que tout tienne en mémoire principale.
Il faut donc retailler le programme et faire des modules indépendants (Overlays) qui seront chargés depuis la mémoire auxiliaire (selon les besoins) dans la même zone de mémoire principale. Par exemple la partie permettant de modifier la configuration n'est pas indispensable au process proprement dit et ne sera "monter" en ram princ que si l'utilisateur appuie sur la touche "C" (changement de configuration).

*** FIN ***