Après quelques semaines de durs labeurs, me revoilà de retour avec une nouvelle version de l'émulateur. Le plus gros du travail a porté sur l'amélioration de l'émulation du Floppy Disk Controler (FDC), mais il y a aussi des petits changements et des améliorations qui ne se remarquent pas forcément au premier abord.
Un gros boulot de fond a donc été fait sur l'émulation du FDC afin de pouvoir lire correctement, et sans patch particuliers je précise, les disquettes au formatages atypiques utilisées dans certaines protections. Le travail n'est pas terminé, j'ai encore des fichiers disquettes qui ne passent pas mais c'est bien mieux qu'avant. Cela m'a permis en outre d'optimiser et de nettoyer le code source qui en avait bien besoin.
Je remercie @Lone qui m'a bien aiguillé sur les pistes à prendre. Je confirme le bien fondé de transformer le format DSK en format "Disquette" qui permet, une fois la conversion maitrisée, de bien comprendre le fonctionnement des protections.
Par ailleurs, il y a une anecdote intéressante à raconter. J'ai longtemps été embêté par une protection bien tordue qui consistait à lire un secteur avec une taille déclarée bien supérieure à sa taille réelle. Lors de la lecture de ce secteur, ce sont en fait 3 secteurs tronqués qui sont lus consécutivement (avec des informations normalement non lisibles : ID Adress Mark, octets de synchro...) et en plein milieu de la partie DATA du 3eme secteur se trouvait comme par hasard le CRC adéquat, permettant de terminer la lecture de ce "secteur" sans erreur.
Afin de reproduire une émulation du FDC la plus fidèle possible, il me fallait donc pouvoir calculer à la volée le CRC pour pouvoir la comparer à la valeur lue. Plus facile à dire qu'à faire, j'ai passé pas mal de temps à chercher sur internet à décortiquer les Datasheets pour connaitre la formule utilisée ans le FDC NEc PD765A, sans grand succès.
A défaut, je me suis dis que je ne risquais pas grand chose à utiliser le même algorithme que celui utilisé en ROM du CPC pour calculer le CRC lors d'une lecture d'une cassette. J'essaie ... et ça ne matche pas, sans grande surprise. En désespoir de cause, je jette quand même un coup d’œil sur le code source de "SugarBox", l'émulateur de @Lone et ...quelle ne fut pas ma surprise de voir l'algorithme utilisé était bien semblable à celui que j'utilisais. En fait, mon erreur était de ne pas intégrer dans le calcul du CRC les champs "ID" qui précédent la partie "Data". La lecture de ce petit bout de code de @Lone m'a donc permis de gagner un temps précieux au final..et m'a permis de passer la protection avec succès, sans artifice
Il est surprenant de voir que le calcul du CRC utilisé en soft pour vérifier l'intégrité des données "cassette" est identique à celui utilisé en hard dans le FDC pour vérifier l'intégrité des données "disquette". ça devait être un standard à l'époque.
En épilogue, petite déception, le jeu en question est bien nul (HIGH EPIDEMY).. tous ces efforts pour ça
Outre le volet FDC, j'ai apportés des petites corrections par ci, par là : un bug de lecture du clavier corrigé (mauvaise émulation du AY), un problème aléatoire de rendu graphique lors du changement de taille de la fenêtre de l'émulateur.
Par ailleurs je me suis penché sur l'optimisation de mon code pour voir comment améliorer le rendu sur les vieux processeurs AMD notamment. Il n'y a pas trop de miracle à attendre de ce côté là mais à cette occasion, je me suis aperçu d'un comportement étrange des fonctions "TIMER" utilisés par les API Windows.
On peut programmer leur valeur en milliseconde, avec une valeur minimale de 1, (soit 1 ms). Jusqu'à présent je ne m'étais pas occupé de vérifier la fiabilité de leur chrono, je m'en servais juste pour appeler la routine de scan des touches claviers toutes les 10 ms. Suite à un comportement étrange dans l'émulation du joystick (saccades à l'écran), je me suis aperçu en fait que ces fonctions ne sont pas très fiable et qu'en pratique, les timers sous Windows ont une période minimale de 15-16ms et non pas 1 ms... Bref, j'ai abandonné les timers pour scanner l'état des touches du clavier..
Par contre, comme les timers font gagner beaucoup de ressources CPU, j'ai intégrer une option pour rafraichir l'écran (50 hz) via un appel à la routine via un timer. La régularité de l'affichage est moins précis mais ça fait gagner 10 à 15% de ressource CPU d'après mes essais. Pour les vieux processeurs, c'est mieux que rien. Cette option est désormais présente dans le menu de configuration.
Par ailleurs, côté amélioration, le plein écran est désormais disponible (touche F12), on peut changer de type de moniteur ou de CRTC sans reboot de l'émulateur, pour @ThomasR, une option a été ajoutée pour lire la face B d'un fichier DSK "double face"
et ..cerise sur le gâteau, l'émulateur tourne aussi sous Windows 11 aussi puisque j'ai fait la migration de mon PC ce mois-ci.
Cette nouvelle version toute chaude sortie du four (v0.465b) est disponible en téléchargement en première page ). Pour l'instant je laisse les versions précédentes, s'il y a des régressions qui apparaissent...Les administrateurs ne m'en voudront pas trop
N'hésitez pas à me faire des retours, c'est comme cela qu'il s'améliorera dans le temps