STeADIER's log - Page 1

Alors voilà, j'ouvre un topic pour STeADIER, un petit programme qui voudrait bien pouvoir utiliser des fichiers .ST et .MSA sur Falcon en faisant comme s'il s'agissait de vraies disquettes insérées dans le lecteur.

Pour ceux qui ont raté les premiers épisodes (les messages sont disséminés dans différents topics), il y a un petit résumé là : http://removers.free.fr/spip/article.php?id_article=88

Tiens, ça serait peut-être une bonne idée de regarder du côté d'ULS du groupe DBUG.

Voir http://www.atari-forum.com/viewforum.php?f=45&sid=f0733b2201488219dc57eaf5adc4beb0

Bon courage pour le développement de STeADIER !

Dommage que les sources soient perdues, mais j'espère qu'on verra une version qui fonctionnera aussi sur CT60

Gwile :
Sinon j'ai quand même regardé un peu STeADIER : avancé le désassemblage, trouvé encore 2 ou 3 bugs potentiels (à se demander comment ça réussissait à marcher), re-réflechi un peu à tout ça, potassé le 68040 User's Manual, chapitre PMMU, verset format des tables : pour le 040/060 ça pourrait être jouable pour du code non-STe n'accédant pas trop souvent aux registres vidéo (l'écrasante majorité des jeux ST quand même !).

Cool ça! moi j'ai (bien) bossé sur les docs du FDC!
Le résultat est une doc synthétique et complète du FDC : http://removers.free.fr/wikipendium/wakka.php?wiki=FDC. J'ai tenté d'éclaircir les points qui restent obscurs à la lecture du "Livre du Développeur" (la bible du ST), élargi le cadre de la documentation par rapport aux STmag n°71 et n°72. Croisé avec des listings hard (mais qui apportent peu d'info) et enrichi avec "Disquettes et Disque Dur" (dispo sur http://www.microstalgia.fr.st/), qui est (de loin) la doc la plus complète et la plus passionnante à lire!

J'ai regardé aussi les impacts des pages 4ko des PMMU 040/060 et je partage ton avis à 100%, c'est jouable

Gwile :
En plus sur 030 et 040/060 on devrait pouvoir faire un mode d'émulation "léger" qui ne fasse que gérer les images disques sans pousser l'émulation ST(e) plus loin, et qui puisse être compatible avec la Fast-RAM (voire le TT et autres machines avec cartes accélératrices 030) pour plus de confort...

Exact, si on arrive à mettre STeADIER en TT RAM, ça boostera davantage. Par contre, les jeux/démos qui attaquent le FDC en direct se heureront au fait que le pointeur DMA du FDC est sur 24 bits. Ces jeux/démos auront du mal à charger leurs données en TT RAM... En revanche, ceux/celles qui utilisent GEMDOS devrait pouvoir aller en TT RAM.

Gwile :
Si jamais je fais marcher ce truc sur 040/060, alors quelque pourra peut être un jour s'amuser à gérer les Hadès/Milan/Medusa voire ARanyM !

Plus de détails par courriel demain soir ou ce WE au pire !

Ok super, merci pour les news! J'attends avec impatience ton avancement sur le désassemblage et les bugs que tu as identifié!

frost :
Tiens, ça serait peut-être une bonne idée de regarder du côté d'ULS du groupe DBUG.

Voir http://www.atari-forum.com/viewforum.php?f=45&sid=f0733b2201488219dc57eaf5adc4beb0

Ok en effet ça ressemble, mais c'est pas exactement la même cible. Eux ils patchent le loader ajouté par les crackers (facile, c'est eux qui ont cracké les jeux ) pour se brancher sur leur loader qui est capable de restaurer l'état complet de la machine après le jeu ou la démo.

Leur méthode consiste à se pencher sur le pb au cas par cas pour chaque jeu, celle de STeADIER c'est de fournir une méthode plus générale pour "virtualiser" le lecteur de disquette pour le brancher sur un fichier image.

Vu les différences entre nos idées de départ, je crois que pour le moment on ne pourra pas s'inspirer de ce qu'ils ont fait. Une remarque quand même : on voit quand même que nous ne sommes pas des crackers! Sinon, on aurait eu la même idée qu'eux, qui finalement, n'est pas tellement compliquée!

Ok. En fait le principe d'ULS est largement calqué sur celui de WHLoad, un programme Amiga qui permet d'exécuter un paquet de jeux et de démos à partir d'une image disque et sur n'importe quelle machine (un 1200 burné au 060 par exemple).

En tout cas bon courage

Quelques news: j'ai bossé un peu sur STeADIER hier soir, et j'ai réussi à trouver un moyen de tracer les appels à la disquette faits par le système lors de la séquence de boot!

J'ai vu pas mal de choses, mais 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.

Sur ce point le livre du lecteur de disquette (http://microstalgia.fr.st) sera utile car il présente les statuts retournés par le FDC selon les situation ; il faudra d'ailleurs que je mette les FdcStatus à jour sur WikiPendium. Autre piste, tout ce boulot a déjà dû être fait par les émulateurs sur PC, et surement Aranym. Faudrait aller voir comment ils font...

@Gwile: j'ai plus de nouvelles! Tu reçois mes emails?

à bientôt pour de nouvelles aventures

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 ]

stabylo
:si on arrive à mettre STeADIER en TT RAM

Les images MSA seront aussi en TT RAM ? Parce qu'il serait peut-être bon de désactiver l'IDE pendant l'émulation... au cas où un jeu mal programmé taperait dans les mauvais registres du YM

C'était juste une remarque en passant
Bonne continuation !

Bah c'est plutot le registre ide qui est mal placé

après une autre nuit, suite des aventures

Seb m'a transmis la gestion du FDC de STonX et j'ai taillé dans gras de STeADIER pour se calquer sur l'émulation de STonX qui me semblait plus juste. Cependant, sans surprise, le boot bloque toujours

stabylo :
le système abandonne trop tôt, comme s'il décrétait que le lecteur était hors d'usage.

J'ai mis à contribution mon exemplaire de la bible du ST qui contient un désassemblage du BIOS du TOS 1.0. Hyper intéressant! Certaines parties n'ont pas beaucoup changé dans le TOS 4! (normal aussi, il n'y a pas 50 méthodes pour booter sur une disquette) Donc les commentaires de la Bible du ST sur le TOS 1.0 m'ont aidé à comprendre ce qui se passe dans le TOS 4.04 (j'aurais jamais cru ça quand j'ai acheté ce vieux bouquin autrefois!). J'ai donc pu identifier que la séquence de commandes FDC reçues par STeADIER pour être émulées provient de la routine hdv_boot du TOS (sur laquelle STeADIER place son principal hook pour effectuer ses initialisations).

En fait, c'est cette routine qui bloque ; elle ne retourne jamais la main à l'init de STeADIER. Cependant, pour toute la permière partie que j'ai tracée, tout se passe correctement (les inits arrivent convenablement sur la routine flopok). C'est sans doute par la suite que ça se corse, peut-être au moment où le secteur de boot est executé, mais je ne suis pas allé jusque là car c'est un gros morceau à tracer (et tracer la ROM c'est nettement plus délicat que la RAM )

stabylo :
Est-ce vraiment ce que fait le FDC en temps normal?

J'ai pu voir que oui, la méthode est correcte pour passer le bit 5 du GPIP à 0 (passage obligé car le TOS teste ce bit pour savoir si la commande est terminée, même s'il n'y a aucune interruption de lancée)

stabylo :
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.

Hypothèse erronnée, c'est plutôt le hdv_boot du TOS qui est en cause

stabylo :
Steadier ne vérifie pas l'état du bit Interrupt Enable du MFP

Pas de besoin en fin de compte. Le MFP est assez grand pour ne pas faire de bêtise ; quand une interruption est disabled, il ne va pas s'amuser à appeler la routine correspondante (trop fatigué moi)

Strider :
Les images MSA seront aussi en TT RAM ?

En fait, on est encore un peu loin de l'envisager... Quand on arrivera (enfin) à booter sur une disquette, ce sera déjà bien. Pour l'instant ça s'avère pas simple...

Strider :
Parce qu'il serait peut-être bon de désactiver l'IDE pendant l'émulation... au cas où un jeu mal programmé taperait dans les mauvais registres du YM

Oui, je garde ça en tête. Pour l'instant, le disque dur n'est pas dispo au boot.

a+ pour une suite à la saga

ça me fait vraiment plaisir de lire ce log, ça me rappelle la grande époque de la fameuse "disquette épistolaire"

continue comme ça mon petit Stabylo

yep, on avait inventé le blog avant l'heure

[Tel le BIOS moderne je sors de mon mode hibernation...]

Seb m'a transmis la gestion du FDC de STonX et j'ai taillé dans gras de STeADIER [...].

Je proteste STeADIER n'est pas gras, il faisait moins de 4 k à la naissance !

Les images MSA seront aussi en TT RAM ?

Ca ne pose pas de problème particulier, à partir du moment où la TT-RAM est accessible.
Ce n'est pas le cas actuellement. Le faire _directement_ réduirait la compatibilité, car l'adressage de la mémoire serait alors sur plus de 24 bits de large, au contraire d'un vrai ST.

Il faudrait désactiver la PMMU et bloquer temporairement toutes les interruptions pendant les routines internes de STeADIER qui accédent aux zones mémoires où se trouve les secteurs
de l'image disque, ainsi on pourrait s'en sortir je pense... Il faut quand meme faire attention de ne pas en faire trop d'un bloc (un secteur ça devrait aller) sinon ça va bloquer le "ST"
(qui est censé avoir un DMA qui bourre lui).

Ca me fait penser qu'il faudrait peut etre quand meme bloquer les interruptions tout du long car on se trouve deja dans un gestionnaire
d'exceptions (erreur de bus) et donc c'est pas terrible d'etre interrompu a l'intérieur (surtout par une autre vraie erreur de bus par exemple !!!).
L'idéal serait de faire un pseudo-DMA : une routine de recopie par blocs sous une interruption moins dangereuse et en tout cas plus susceptible d'etre interrompue elle-meme, comme la VBL...

Parce qu'il serait peut-être bon de désactiver l'IDE pendant l'émulation... au cas où un jeu mal programmé taperait dans les mauvais registres du YM

En fait il y a deux choses à faire :
- interdire tout accès à la page mémoire E/S des registres IDE (facile)
- masquer l'écriture des registres 14 et 15 et des bits 6 et 7 du registre 7 du PSG, comme tout bon player de soundchips devrait le faire (hein STrider ;P !).

Par contre je crois que le bit pour désactiver l'IDE fait aussi un RESET de l'IDE au passage... vaut peut-etre vraiment mieux ne pas le modifier !


Pour le FDC, il y a des furieux sur atari-forum.com qui en glosent en ce moment (plutot coté hard mais ils peuvent aider sur certains points je pense...).
Pour le démarrage sur disquette, il y a toujours la solution utilisée par B030 de URAn (cf. http://sting.atari.org/) qui est moins élégante
(il faut une disquette spéciale dans le lecteur de disquette) mais qui doit sans doute marcher (si on remplace le LONGBOOT.BIN par une version spéciale de STeADIER).

A peluche et bonne nuit !

Gwile: tout à fait exact concernant le bit our désactiver l'IDE.

un peu dans le même ordre d'idée que Steadier (et feu VMSA) mais niveau hard :
http://jeanfrancoisdelnero.free.fr/floppy_drive_emulator/index.html

est-ce que ça marchera sur Falcon ?