Logicielsmoto.com

Ah là là, où avais-je la tête?! Yoann, tu m'avais donné la réponse dès le début, un peu plus haut!

Donc, le seul moyen d'utiliser linéairement la RAM vidéo au même titre que les pages RAM 2 et 3, c'est de détourner les adresses "espace cartouche" et de s'en servir comme d'une fenêtre sur les autres espaces RAM... Ca va, je commence à comprendre l'intérêt de ce subterfuge (ça m'échappait, au début...).
谢谢，哪我都明白了。。。Je repars donc le coeur en fête.
A.
[/quote]

Mais de rien, et content que tu comprennes le mecanisme

Oula.. C'est des jurons Buggols ou Morlock ca ?

Cf l'arche du capitain blood que j'ai decouvert sur mon to9 et dont je m'emerveillais des graphismes bien avant les version amiga & atari auxquels je n'ai jammais accroche: j'avais ete trop epate par la version TO. Raahhh lovely.

Question prog: les routines 3D ismoetrique de sortileges aussi m'epatent. C'est dingue. Ca ma l'air rapide et je ne vois pas comment dessiner les scenes 3D rapidement sans tout redissiner d'arriere en avant et donc un truc lent a la base surtout qu'on ne peut faire de commut d'ecran comme sur TO8. Si qqn connait des routines de 3D isometrique, j'suis prenneur (car j'aimmais bien aussi sortileges).

sam (Moi grand, Toi petit! Moi detruire planette izwall).
___
PS: pff j'suis un peu decu du cross compilo gcc pour 6809 !!

J'ai code des routines C en format flottant 16 bits (1bit signe, 6 bits exposant, 9bit mantisse) pour tester si la precision etait ok avant de tout passer en ASM. Or le code asm produit par gcc est faux: des deviennent: ce qui est archi faux! J'ai aussi eu droit lors d'un a un ainsi que le fait que lorque e=0, le m>>=e effectuait quand meme un decalage de 1 bit. Je soupconne des gros pbs dans la description sur la facon d'implementer les operations logiques sur 16bits et leur impact sur les flags de CC.

QQn connait il aussi des compilos C 6809e qui buggent mois ?

Je n'ai jamais essaye ce compiler C++ ppur 6809. Et puis, c'est pas chouette de bosser en assembleur directement ?

Sinon, j'ai fait quelques recherches (2 minutes et 10 secondes, pas plus) et ca ne semble pas courrir les rues.

Ben pas toujours. L'asm c'est cool quand on sait ce qu'on veut faire. On ne se preoccupe alors que d'optimiser.

Or la pour les routines de montagnes et surtout pour la projection en perspective il faut que je fasse des essais nombreux pour: 1) debugger les codes (qui sont pas toujours simples, surtout quand on veut jouer au plus malin en voulant optimiser, mais en introduisant surtout des bugs) 2) voir si la precision des format numeriques est suffisante.

Ainsi apres avoir teste des nombre en format point-fixe 8.8 je me suis rendu compte que ca n'allait pas: il y a des debordements dans l'algo. Du coup j'essaye en flottant 16bits.. Si j'avais fait cela en ASM j'aurai laisse tombe rapidement car revenir sur les algos pour les transformer de 8.8 a 10.6 ou en virgule flottante en ASM revient a tout re-ecrire. La en C on ne re-ecrit qu'une partie. Pour la mise au point c'est pratique. Apres on peut faire de l'ASM en sachant ou l'on va. L'autre avantage c'est que les environnement de dev et de mise au point sont plus cool sur les machines modernes que sur les TOs :/



oui ou alors ils sont incomplets ou hackes pour telle ou telle plateforme.

sam.

Le C reste un langage interprété et comme tout langage interprété, il y a systématiquement compilation. Le bug dans ce procéssus, soit, ce n'est pas trés optimisé (beaucoup d'op. inutiles) soit c'est n'importe quoi (donc reprendre le prog en asm pour le débugger sans compter les réadressages).

Perso. L'asm reste plus judicieux.


Tiens, à ce propos... Y a t-il un vecteur d'erreurs sur Thomson?

Interprété = non compilé
Un langage compilé génère des objets en langage machine, qui sont ensuite exécutés.
Un langage interprété ne génère pas d'objets, il exécute les instructions au fur et à mesure de son interprétation.

Exemples
- Le Basic Thomson est interprété, pas compilé (mais il existe aussi des Basics compilés)
- Le C est un langage compilé (il existe peut-être des interpréteurs, mais je ne les connais pas).

Lorsqu'Eric Botcazou a commencé l'écriture d'une bibliothèque Thomson pour le C, il a choisi GCC comme compilateur 6809. Il en existe d'autres (voir http://koti.mbnet.fi/~atjs/mc6809/), mais ils sont très confidentiels, et probablement pas meilleurs.

Daniel

Tu fais une erreur le C est compile Et comme je l'ai dit il permet de tester un algo pour se faire une idee de sa pertinence.

Pour moi tester un algo ce n'est pas tester une implementation de l'algo, mais voir ce qu'il donne, s'il repond a cote du pb pose ou s'il fait bien ce qu'on attend de lui. Tester une implementation de l'algo est plus de la nature optimisation, phase a laquelle je ne suis pas encore arrivee.

A la louche, le C est 2 a 3 fois plus lent que ce qu'on ferait en ASM la main, a comparer avec le basic qui contient un facteur 100 facile. Cependant en C on va 100 fois plus vite pour coder qu'en ASM (je te dis pas la tronche asm de mon code de transfos 3D!) et comme le C est plus proche de la machine que le basic, je dirais qu'il permet en outre de se faire une idee de la facon d'implementer l'asm optimise a la fin (ce que ne permet pas vraiment le basic).

Le truc d'utiliser le C pour prototyper c'est pour ne pas perdre du temps a paufiner au cycle pres des routines qui ne serviront pas parce que l'algo est faux ou insuffisant (comme le cas des fixedpoint 8.8 pour les montagnes fractales).

Bon evidemment, ca c'est quand on code un algo inconnu. Si c'est algo connu sans pbs, alors la oui, asm directos. C'est ce que gcc permet d'ailleurs: mixer du C et de l'asm. Ainsi au debut du prototypes en C, tu debug l'algo, tu vois comment il marche, puis tu vois les routines a optimiser et celles la tu les passes en ASM selon la celebre formule 80-20 (on passe 80% du temps dans 20% du code et c'est dans ces 20% que le gain ASM se fait le plus sensible).




Vecteur d'erreur ? Ben il y a les redirections SWI si c'est ce dont tu parles .. sinon je ne vois pas bien a quoi correspond les "vecteurs d'erreurs". Quelles erreurs ? Celles du basic, celles de l'extramon ? Je comprends pas.

sam.

Je pensais que le C est un langage interprété.

En fait, dans mon idée, pour exécuter un programme en C, il fallait passer par l'interprétation de ce dernier.


Un vecteur d'erreurs est une adresse situé dans les tampons, modifiable, qui permet de rediriger le programme en cas de problème dans l'exécution d'une routine.

En fait cela évite les bugs indésirables.

Tu veux sans doute parler des vecteurs Traps comme sur 68000, cad des addresses ou l'on indique au CPU ou aller en cas d'exception (division par zero, pbs d'acces long sur uen adresse impaire, bus-error, interruption pendant l'excution du traitement d'une interruption en mode superviseur etc) ou en cas d'interruption externe (IRQ, TIMER)..

Ben sur le 6809 il n'y a pas d'exception au sens 68000 (pas de mode superviseur, pas de fpu, pas de div par zero pas de pb de parite d'addresses).

Il y a juste les vecteurs pour les interruptions externes IRQ, FIRQ et TIMER qui sautent en ROM puis apres quelques traitement redirige le flux vers une addresse contenue dans les registres IRQPT ou TIMERPT de la page 0 du moniteur. A ces interruptions hardware externes on peut ajouter les interruptions logicielles SWI qui est reserve selon les machines a l'appel de routines moniteur sur MO ou le retour de prog asm dans la cartoche assembleur des TO. SWI2 et SWI3 sont eux laisses libre a l'utilisateur (mais jammais utilises a ma connaissance car ils sautent a des addresses fixes en RAM sans redirection possible pour le SWI3 au moins).

J'espere que ca repond a ta question.

sam.

Dites les copains, le registre "système 1" ($E7E7), il est accessible en lecture ou pas? Page 114 du manuel technique, voici ce qu'il est dit, et je ne sais pas trop comment le comprendre:

"Excepté le registre 'système 1', les registres de traitement, étudiés en écriture, sont lisibles en entier ou partiellement, à des adresses différentes ou semblables."(condition signalée: D0 = 0 à $E7E4)

Ca semblerait plutôt vouloir dire qu'il n'est pas lisible (même pas partiellement à aucune adresse)...

Ce qui m'intéresse, c'est de passer son bit D4 (gestion RAM données) à 1, pour autoriser l'écriture en $E7E5 (registre RAM données). Ca, ça ne donne rien on dirait :



Ce registre $E7E7 gère beaucoup de choses (controleur, nanoréseau/cartouche, standard d'affichage, ESPACE DONNEES, type d'ordinateur TO(9)/MO, type RAM)

Si $E7E7 est en écriture seule: je m'hasarderais bien a y écrire, par exemple, un 01011100 (au vu de la config de mon ordi):

... mais ça nous mettrait dedans si par exemple : le controleur utilisé était externe / l'ordinateur était un TO9 / je me plantais dans le type de RAM.

D'ailleurs, ce registre 'système 1' me paraît louche: le standard d'affichage (624/524 lignes) et le type d'ordinateur (TO(9)/MO) ne sont-ils pas fixés en fonction de la machine?

Arnaud

A ma connaissance, le registre $E7E7 est utilé pour se synchroniser sur la VBL ou la HBL.

[edit] J'avais oublié. Préhisto avait donnée une solution pour l'overscreen ou l'on se sert du bit 5 du registre $E7E7 en écriture. Pour le reste, je découvre.

E7E7 en lecture :
- bit 0 = copie bit 0 de E7E4
- bit 1 = interruption crayon optique
- bits 2-4 à zéro
- bit 5 = position horizontale du spot (0 = hors fenêtre, 1 = dans fenêtre)
- bit 6 = position verticale latchée (0 = hors fenêtre, 1 = dans fenêtre)
- bit 7 = position verticale instantanée (0 = hors fenêtre, 1 = dans fenêtre)

E7E7 en écriture :
- bits 0-1 = type de RAM
- bits 2-3 = type d'ordinateur
- bit 4 = type de commutation banques (0 par PIA, 1 par E7E5)
- bit 5 = trame (0 = 625 lignes, 1 = 525 lignes)
- bit 6 = reservé
- bit 7 = sélection contrôleur disquette ou QDD (0 = interne, 1 = externe)

Il ne faut donc jamais lire E7E7 et réécrire ce qu'on a lu
Il n'est pas possible à ma connaissance de retrouver ce qu'on a écrit dans E7E7 si on l'a oublié

Daniel

Jusque là non, mais maintenant j'ai bien peur de l'être

Merci Daniel pour cette réponse très détaillée sur le cas $E7E7. Je m'attendais un peu à ce genre de révélations... Mais alors pour mettre ce pauvre D4 à 1, ça risque de faire du grabuge: de quoi faire croire à un TO8 indigène qu'il est un TO9 amnésique en voyage à l'étranger...

Mon objectif est tout simplement d'écrire des valeurs (ie: couleurs) dans la "RAM données" affichée à l'écran. J'ai beau dire à la machine "Tiens, prends-ça dans les dents entre $A000 et $DFFF!", elle n'a pas l'air de s'intéresser terriblement à ce que je lui raconte: rien ne s'affiche!

J'ai toujours cette supposée page 3, avec ses sortes de zébrures bicolores de haut en bas: c'est d'un goût. Et mes valeurs 8 bits balancées à partir de $A000 ne parviennent pas à faire la moindre tache...

Voici globalement les étapes de ma routine:


Est-ce que je grille une étape?

Merci!
Arnaud

D'après la routine de hardreset du TO8, $E7E7 est initialisé à $54 (ou $D4 pour un contrôleur de disquette externe). La valeur d'initialisation de $E7E7 est aussi copiée en $6081, mais je ne sais pas si on peut s'y fier.

Si on utilise le contrôleur interne, on peut écrire $54 en $E7E7 pour positionner le bit D4, sans aucun risque de planter le système.

Daniel