Cette catégorie traite de développements récents destinés à nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!
***************************************
* Lecture touche clavier. Etrangement
* sur TO7 (MESS) il faut empecher les
* interruptions parce que durant
* l'interruption on perturbe l'algo
* de décodage clavier ce qui trash
* la pile. La suppression des inter.
* provoque un leger glitch son, aussi
* on desactive les interruptions pour
* les TO7 et TO770.
***************************************
getc pshs cc
ldb $FFF0
decb
bge *+4
orcc #$50
jsr GETC
puls cc,pc
Il faudrait savoir aussi si le figeage se produit sur la version FD aussi (j'ai testé les TO7 que sur émulateur à l"époque: DCMOTO et MESS).
Le figeage se produit des que tu veux éffacer la neige des l'appuis sur une touche, comme dit Daniel comme on est sur une conversion issue de l'émulateur , ça vient peut être de là , mais on voit le gros de la démo à part a c'est déja beaucoup mieux. Je ne suis pas équippé pour les disquettes je ne pourrais pas tester le .fd
Donc j'aurais dit "pendant" en réponse à ta question. Je te reconfirme précisément un peu plus tard.
Pour revenir au test de hny2013_to7.sd (issu du fichier hny2013_to7.fd), je constate sur la vraie machine le même comportement que dans l'émulateur dcmoto :
Le programme affiche un écran noir avec une bordure rouge.
Au bout de quelques dizaines de secondes la bordure devient noire puis réapparaît quelques secondes plus tard.
Le cycle recommence indéfiniment.
Le problème vient vraisemblablement de la fonction de chargement du fichier AUTO.BIN
Le contrôleur SDDRIVE a été programmé en prenant modèle sur le CD90-640, destiné aux disquettes 5"1/4. Il y a peut-être des différences avec un contrôleur pour disquette 3"1/2 pouvant expliquer l'anomalie. Ce n'est qu'une hypothèse parmi d'autres, il faudrait étudier le programme de chargement plus en détail. Ce programme, qui affiche PULS, a peut-être été écrit par Prehisto ? Il utilise entre autre les fonctions $E00D (chargement de la FAT), $E010 (ouverture d'un fichier), $E01F (mise a jour d'un cluster), rarement utilisées par les programmeurs débutants et peu testées avec SDDRIVE.
En fait c'est moi qui a tout fait à l'époque. Voici le code du bootldr (le truc qui charge AUTO.BIN et qui plante avec le tour "rouge"). Le truc qui se passe est qu'un appel à d7read retourne CC=1 ce qui signifie erreur pour le programme. Là où c'est compliqué à suivre est que le chargement utilise le principe des coroutine/continuation pour reprendre un calcul depuis un point précédent. Ca complique les choses, mais l'appel aux routines moniteur est sensiblement la même chose que le code >>ici<<
__sam__ a écrit : ↑31 janv. 2021 16:12
l'appel aux routines moniteur est sensiblement la même chose que le code >>ici<<
J'ai peut-être une explication : je vois dans la routine de chargement un LDB $6058. Je croyais que cet octet était inutilisé, et il me sert d'indicateur de sélection d'un fichier .sd. Il est initialisé à $55 quand le fichier .sd a été choisi dans l'écran de sélection SDDRIVE. C'est peut-être la cause de l'erreur ?
[EDIT]
Confirmation : bootldr.ass lit la densité en $6058. Avec une carte SD la densité n'a aucun sens, et le programme sddrive.sel s'en sert de zone de travail. Il faudrait supprimer ce test de densité et ça a des chances de fonctionner.
Effectivement c'est le flag de densité. Il est lu dans la routine transf pour savoir combien d'octet sont à copier (0 => 255, 255 => 128, autre => comportement inattendu.)
Si via le débuggeur je mets CLRB + NOP ($5F $12) au lieu de
En fait c'est SDDRIVE le fautif, il ne devrait pas écrire en $6058. Mais c'est difficile de l'éviter, car il est impossible de trouver quelques octets libres à la même adresse pour toutes les machines. J'ai aussi essayé d'utiliser l'adresse basse de la pile. Il y a peu de chance que la pile se remplisse entièrement, mais j'ai découvert que les ingénieurs Thomson avaient eu la même idée que moi pour stocker une variable de travail du MO6, ce qui plantait SDDRIVE.
C'est un problème de fond, pour lequel je n'ai pas de réponse satisfaisante. Il faudrait avoir quelques octets de RAM dans le contrôleur SDDRIVE, mais c'est malheureusement trop complexe à implanter. Sinon on pourrait mettre des variables dans un secteur inutilisé de la carte SD, mais la lecture et l'écriture prendraient trop de temps.
Le plus raisonnable est de ne pas toucher à la version .fd et de faire une version .sd spéciale pour SDDRIVE. Je m'en charge. Je l'ai déjà fait pour quelques programmes qui modifiaient $E7E7 pour sélectionner le contrôleur interne sans tenir compte de $6081. De mémoire il y avait Turbo Cup et un ou deux autres.
Laissez-moi un peu de temps et je diffuserai la version .sd de HNY2013.
Mais ce n'est pas encore gagné : le programme se fige dès qu'on appuie sur une touche, exactement comme dans la sauvegarde de l'émulateur dcmoto postée par __sam__. Et comme le bug ne se produit pas dans l'émulateur il n'est pas facile à trouver.
Si ca ne se reproduit pas dans l'émul, je ne vois pas comment attaquer ce 2nd problème. Ca doit être lié au code suivant qui n'a rien de spécial dans le fond (mais je me souviens avoir eu aussi des soucis pour "shadow of the thomson" autour du clavier sur TO9 quand les interruptions sont activées/désactivées (je ne me souviens plus des circonstances).... une histoire de pile trashée là aussi)
***************************************
* Lecture touche clavier. Etrangement
* sur TO7 (MESS) il faut empecher les
* interruptions parce que durant
* l'interruption on perturbe l'algo
* de décodage clavier ce qui trash
* la pile. La suppression des inter.
* provoque un leger glitch son, aussi
* on desactive les interruptions pour
* les TO7 et TO770.
***************************************
getc pshs cc
ldb $FFF0
decb
bge *+4
orcc #$50
jsr GETC
puls cc,pc
Pour les jours suivants je ne pourrais pas regarder ce problème. Disons qu'il n'y a qu'a attendre qu'un coup de vent balaie la neige accumulée (ca arrive au bout d'un moment.)
En enlevant le ORCC #$50 ça ne change rien. L'appui sur une touche fonctionne bien dans dcmoto et bloque la vraie machine.
C'est la routine de scrutation des touches en $E806 qui provoque le problème. Pourquoi sur la vraie machine et pas dans l'émulateur, c'est difficile à comprendre. Si on supprime l'appel à $E806 le problème disparaît, mais la touche appuyée n'est pas identifiée donc CTRL-C n'est pas détecté.
La bonne solution serait de tester directement la touche CTRL-C sans passer par la routine $E806. Cette routine est très longue, car elle scrute successivement toutes les touches avec des traitements anti-rebond pour chacune. Scruter une seule fois la touche CTRL et la touche C est beaucoup plus rapide.
Je n'ai pas changé le test d'appui sur une touche quelconque par la routine KTEST ($E809). J'ai seulement enlevé l'appel à la routine GETC ($E806) qui testait l'appui sur CTRL-C ($03). Dans la version modifiée, la suppression de la neige fonctionne comme dans la version originale, en appuyant sur une touche quelconque. Par contre l'abandon du programme par CTRL-C n'est plus possible.
Je ne vois vraiment pas pourquoi la routine GETC fonctionne bien dans l'émulateur (avec ou sans les interruptions), alors qu'elle bloque la vraie machine (avec ou sans les interruptions). Elle utilise la pile et pourrait la faire déborder, mais dans ce cas l'émulateur se bloquerait aussi. C'est un grand mystère qu'il va falloir élucider.
Ah OK c'est CTRL-C que tu as viré. Apres c'est tres bien comme ça , à moins de vouloir percer le mystere , mais on est déja loin du premier éssai écran noir et bordure rouge. C'est bien le plus important les touches pour balayer la neige que stopper le programme.