mastergb1 a écrit :
Bon voila j'ai un probleme avec la fonction off!
Bpon voila c'est sur mon kirby.
D'apres ce que les beta testeurs disent la fonction off plante sur leur calc(moa personnellement apres 200 tentative j'ai rien eu)
Pourtant je desactive la genlib et je fais juste un off!
Je vois pas d'ou ca vient!
Donc si kelk1 pouvait m'aider pour ca:c'ets la derniere chose a corriger avant la sortie.
Ils utilisent probablement
h220xTSR 1.10 ou antérieure, qui détruit des registres (d0-d2/d7/a0-a1 pour la version 1.03, d7 seulement pour 1.04-1.10) dans le trap #4. C'est corrigé dans la version 1.11 (sur mon site, et intégrée dans
PreOs 0.62). Il y a aussi de très anciennes versions de
Fast Keyboard qui détruisaient des registres dans le trap #4, mais je ne pense pas qu'elles soient encore en circulation.
Un workaround possible pour
Kirby, extrait des sources de
Backgammon (même si je conseille à tout le monde de mettre à jour
h220xTSR parce que le problème peut aussi se révéler à d'autres endroits):
/* The trap 4 is not supposed to destroy ANY registers, but there are several
buggy TSRs floating around which destroy some registers (notably - ahem,
sorry :-/ - old versions of h220xTSR - the bug is fixed in v.1.11), so I am
defining ALL registers as clobbered as a precaution */
#define calc_off() asm("trap #4":::"d0","d1","d2","d3","d4","d5","d6","d7","a0","a1","a2","a3","a4","a5","a6")
XDanger a écrit :
[OFFTOPIC]
> ordivore
> le rom_call off ne fais que trap #4 si je me souviens bien
Oui, mais il vaut mieux appeler off() car dans ce cas, la trap 4 est appelée depuis la Flash, ce qui n'est pas le cas si tu appelles trap #4 directement. Et il me semble que JM ou Kevin ou un autre avai(en)t dit qu'il pouvait y avoir des problèmes, notamment avec la trap #B, si on appelait trap #4 directement.
Non, ça n'a aucune importance.
ExtendeD a écrit :
Pour le problème de ralentissement après un off:
il faut faire après l'appel un *(char*)0600003 = 0xFF (st.b $600003 en asm).
Dites le vous, peu de monde le sait et tous les programmes ayant une fonction off ont le bug.
Plutôt
*(volatile char*)0x600003 = 0xFF;.
Ou, plus court:
poke_IO(0x600003,0xFF);, ça revient exactement au même.
jackiechan a écrit :
C'est quoi, ce port et comment il fonctionne ?
J'ai regardé la doc "j89hw.txt", mais je n'ai pas trop compris de quoi il s'agissait...
Il dit que c'est le "bus waitstates", mais je ne vois pas trop ce que c'est.
Ce port définit des ralentissements du processeur pour attendre la RAM (c'est ce que veut dire "bus waitstates").
Et comment AMS modifie ce port et pourquoi ?
Le matériel de la TI-89/92+/V200 n'a pas besoin de ces ralentissements normalement, sauf (il paraît) en cas de piles très faibles. Le trap #4 en met donc pour être sûr, mais le testeur de piles de l'AI5 remettra la bonne valeur (0xFF) très vite normalement. Mais si l'AI5 est désactivée ou redirigée, il faut le faire soi-même.
