hop, quelques news, histoire de papotter un peu technique
stabylo :
il va falloir encore approfondir pour voir comment le système exploite le Status Register du FDC. C'est le point faible de STeADIER qui renseigne encore trop peu ce registre.
En m'appuyant sur
le livre du lecteur de disquette, je pense avoir amélioré la qualité des
statuts du
FDC émulé par STeADIER, mais ça n'a malheureusement pas corrigé le problème du blocage du système quand on boote sur la disquette émulée. Bon, au moins la mauvaise gestion des status est une hypothèse de moins à investiguer.
La séquence d'appels FDC faits au boot n'est plus la même qu'avant (ça tournait en boucle sur des commandes qui plaçaient la tête au début du disque, semble-t-il comme si le système essayait d'accéder au lecteur sans disquette). Maintenant, le système fait quelques essais pour placer la tête au début du disque (c'est marrant, il utilise pratiquement toutes les variantes de commandes FDC qui permettent d'arrive à ce résultat
), ça essaye de lire le premier secteur, ça essaye encore de placer la tête au début, pluis plus rien.
C'est justement le "plus rien" qui m'inquiète : le système abandonne trop tôt, comme s'il décrétait que le lecteur était hors d'usage
. Pour l'instant je m'interroge sur le fait que STeADIER simule la levée d'une interruption (avec la commande
Force Interrupt) après chaque commande FDC émulée. Est-ce vraiment ce que fait le FDC en temps normal? Je m'interroge car la routine d'interruption semble exécuter des
Restore, comme si elle se considérait en situation d'erreur d'accès disquette.
stabylo :
tout ce boulot a déjà dû être fait par les émulateurs sur PC, et surement Aranym. Faudrait aller voir comment ils font...
Ca reste à investiquer, et ça devrait être très instructif. J'ai aussi d'autres idées
: faire un STeADIER transparent qui ne fait que prendre en note tous les appels FDC faits par le système au boot (et qui laisse les accès se faire sur la vraie disquette), et détourner l'interruption FDC pour en logger également les appels. Ca permettrait de répondre à mes questions.
Aussi, j'ai regardé le code de l'interruption FDC, mais elle est en RAM donc je soupçonne qu'il s'agit d'une réécriture par NVDI. Booter sans NVDI et tracer l'interruption du TOS d'origine (elle doit être plus simple) devrait également être instructif.
PS: Ca y est j'ai une idée!
Steadier ne vérifie pas l'état du bit Interrupt Enable du MFP avant de forcer l'interruption FDC correspondante. Il est très probable qu'au boot, cette interruption soit inhibée et qu'il faille donc faire attention à ce bit. (et ça expliquerait pourquoi le vecteur d'interruption FDC placé par NVDI n'est pas réinitialisé!
)
[a+ pour de nouvelles aventures au pays du FDC
]