Logicielsmoto.com

Bonjour à tous

Aujourd'hui c'est le flop complet

J'ai décidé de remettre en marche mon MO6, de griller 2 EPROM, et de tester.
Et rien ne marchait.
J'avais bidouiller ma carte mère il y a quelques années, et je me suis dit que c'était cette fameuse bidouille qui mettait le foutoirs.
J'ai donc remis la carte d'aplomb, mais la toujours rien
J'ai sortie le Gate array de son socle et je l'ai remis en me disant: problème de contact.
Mais la encore rien

Par pure hasard je retire IW02 qui contient le disque R3, et la oh miracle j'ai le prompt OS9

Donc deja OS9 démarre,

Comme j'ai mis dans la ROM la possibilité de télécharger les modules par XModem, je tente en appuyant sur le bouton du crayon optique, mais sur mon Mac, sur la liaison série je ne vois rien
Je démêle les fils, je change de contrôleur USB<->série mais rien
Je coupe le soft terminal je le relance et je vois mon contrôleur qui apparaît enfin dans la liste des liaisons possibles
Je relance le MO6, et ouf, je vois enfin les NAK du protocole XModem.
Je balance donc une ROM MO6, mais le MO6 ne démarre pas, et plante en beauté

Donc au final je ne peux pour l'instant que faire quelques commandes sur le MO6. Aucun drive R0/R1/R3 ne marche.
Mon driver de disque virtuel ne marche décidément pas sur le MO6.

Faut donc que je revois ma copie pour tout ce qui est gestion mémoire sur le MO6.

Comme quoi les émulateurs c'est bien, mais ce n'est jamais assez proche de la réalité.

J'ai du boulot sur la planche.

Jacques

Ca me rappelle que nous avions toujours eu un souci pour commuter les pages du Romdisk sur le MO6. En théorie, ça fonctionne, mais en pratique, ça plantait.

Il faut dire que la gestion des pages en RAM est un vrai casse-tête sur le gate-array TO8/MO6.

Bon courage.

Sur le papier en mode TO8 c'est assez simple: on configure le gare-array système pour définir le mode bank-directe: puis pour commuter on écrit le numéro de bank en $E7E5 ($A7E5 sur MO6?).

Attention les banks 0 à 1 sont réservées: La bank 0 est utilisée par la vidéo en $4000 ($0000 sur MO6). La bank 1 est utilisé pour la zone soit-disant non-commutable $6000-$9FFF (sans doute $2000-$5FFF sur MO6). Les banks 2 et au delà sont mappés en $A000-$DFFF sur TO8 (sans doute $6000-$9FFF sur MO6).

_________________
Good morning, that's a nice Tnetennba

Oui, tout cela est correct, mais ce n'est pas le problème qui se pose ici. Sur MO6 et MO5NR, on peut poser de la RAM dans la zone $B000-$EFFF (zone cartouche MEMO5) [peut-on le faire sur TO pour la zone $0000-$3FFF ?] et en plus, il y a l'émulation du mécanisme de l'extension 64K nanoréseau, dans la même zone. Tout cela se marche gaiement dessus avec la commutation des banques de ROM (moniteur, Basic 1.0, Basic 128) qui partagent aussi cette zone. Ca fait beaucoup pour un seul homme.

Cela dit, tes lumières sont bienvenues, car Jacques et moi-même épuisons doucement les pistes possibles. Nous commençons sérieusement à penser que le gate-array est buggé pour certaines configurations iconoclastes mais valides sur le papier.

Oui on peut mapper une RAM dans l'espace cartouche du TO ($0000-$3FFF) en pokant directement un registre du gate-array. Il y a un bit dans le gate-array système (A7E7/E7E6)pour inhiber ce mécanisme en cas de présence de cartouche nano-reseau. Extrait de la doc:

_________________
Good morning, that's a nice Tnetennba

Oui, pour le moment, nous sommes toujours d'accord …

ca ira plus vite en regardant le bout de code avec le contexte (dont le fait de savoir dans quel espace se situe le code (PC), la pile S, tout ca tout ca... (les vecteurs d'interruption aussi ca peut etre drole)).

_________________
http://www.alternative-system.com

On va te la faire courte : bout de code de quelques dizaines d'octets, interruptions bloquées, au milieu un clr >$A7CB ; on le commente, ca exécute (mais ne fait pas évidemment ce qu'il faut), on le met, ca crashe juste après le clr ... C'est bon ça, non ?

Je sais pas si ca a une importance, mais le CLR fait un cycle de lecture avant son écriture en $A7CB.

_________________
Good morning, that's a nice Tnetennba

question bete également mais sur une ROM custom le gate array a bien été positionné en mode MO ?
ici c'est donc une tentative de commutation de la ROM sur la page 0, j'imagine qu'on est déjà en espace ROM, il retrouve quoi exactement à l'adresse qui suit dans la nouvelle page?

_________________
http://www.alternative-system.com

Mode MO, oui, sans aucun doute. Le contexte c'est qu'on a un OS-9 qui tourne parfaitement, avec la gestion de la RAM, des modes graphiques etc. donc noyau multitâche préemptif, interruptions, blablabla. C'est vraiment uniquement l'émulation du mode Nanoréseau qui semble faire problème. On arrive à accéder la MEMO5 externe, mais pas à en commuter les pages en utilisant ce mécanisme.

Pour être très précis, il faut comprendre l'idée : le ROMDisk NG fonctionne comme l'extension 64K Nanoréseau, avec le registre $A7CB. Le MO6/MO5NR possède son propre mécanisme interne $A7CB pour émuler la commutation de page de l'extension 64K avec la RAM interne. Ce registre $A7CB n'est pas accessible en lecture, donc pas de conflit possible en lecture. En écriture, il faut simplement éviter d'activer le mécanisme interne, autrement dit il faut prendre garde à le masquer avant de travailler avec le ROMDisk.

Dans notre situation, le mode émulation nanoréseau est censé être masqué et pourtant quoi qu'on fasse avec $A7CB, ça plante. Alors que ça devrait être ignoré en interne. Si on arrive à déterminer ce que "plante" implique, par exemple une commutation de page non voulue, on pourra contourner le problème. Ce n'est pas le ROMDisk qui pose problème, car ça plante aussi si on met une autre cartouche ou rien.

Ce qui pour moi est très choquant, c'est qu'on dirait que la lecture de l'instruction qui suit le CLR pose problème, alors que le code exécuté se trouve dans une zone RAM théoriquement stable à ce moment-là.

J'ai suggéré à Jacques de jeter un oeil au moniteur du MO5NR qui contient forcément du code en rapport avec le registre $A7CB, si tu as envie de trouver les routines correspondantes, ça nous aiderait bien.

ps. un STA provoque le même effet qu'un CLR.

mmm oui mais si je crois ta doc si B2 est à 0 on ne commute pas et on reste sur le basic 1.0 (du moins c'est le fonctionnement que tu décrits pour l'extension RAM 64k, ta cartouche ROMDisk NG fonctionne peut etre autrement sur ce registre).
Egalement rien ne prouve que l'écriture en A7CB ne fait rien dans le gatearray meme si on est en mode externe. Les read et write dans l'espace cartouche ne devraient pas être mappés mais c'est tout, possible que le registre interne gate array soit positionné quand meme (ca ne sert sans doute à rien, mais le masquer explicitement va couter des portes dans le gate array).

_________________
http://www.alternative-system.com

Le Romdisk est a 100% identique dans son fonctionnement à l'extension 64K, du reste on peut l'utiliser comme tel sur un MO5 dans le NR, ca fonctionne parfaitement. Et comme dit, le problème se pose même si on ne met pas le romdisk. Le bit B2 ne sert pas a commuter les pages, il sert a annoncer la présence de la cartouche MEMO5 a l'unité centrale. C'est elle qui choisit ensuite, en fonction de sa configuration, de montrer le Basic, ou pas : Sur MO5 c'est forcément le cas, mais sur MO6, ca peut aussi être la RAM, ou le BASIC 128. Ce bit est géré correctement dans le driver qui plante.

Ne pas masquer l'accès au registre ne pose pas de problème électroniquement, car nous parlons d'écriture. La valeur sera dans ce cas écrite à la fois dans le registre interne et dans le registre du romdisk. Mais s'il y a un bit pour choisir entre mode NR et mode normal, je m'attends a ce qu'en mode normal, le mode nr (interne) n'ait pas d'effet, et vice-versa. C'est un peu le but non ? Sinon le programmeur peut choisir l'un ou l'autre mode sans distinction et le bit est inutile.

C'est pour cela que Jacques et moi sommes perplexes. J'envisage sérieusement de sortir l'analyseur logique. Et de désassembler la ROM NR. Car je n'exclue pas un bit non documenté.

C'est un problème passionnant, mais vraiment casse bonbon.

a mon avis il faut reprendre les choses comme à la conception.
L'extension RAM 64K est elle utile pour le MO6 => non car elle est émulée en interne.
Après que l'on puisse quand même s'arranger pour l'utiliser pourquoi pas mais on est déjà totalement en dehors du cahier des charges du MO6 et de son gate array.
Quand je parle de B2 c'est le B2 de A7CB qui, si ton PDF est exact permet de commuter dans l'extension 64K entre la RAM (la page définie en B0-B1) et la ROM interne BASIC du MO5. Le mode NR du MO6 va forcement émuler aussi ca en interne. Or si on écrit en A7CB alors qu'on n'est pas supposé le faire car pas en mode NR quel est le résultat? on peut eventuellement regarder si ca plante en mode basic128 normal du MO6 avec la rom d'origine.

_________________
http://www.alternative-system.com

Bonjour

Voila quelques précisions de ma part suite a une petite erreur de formulation (mais le problème n'est pas résolu)
Comme l'a dit Fool, je n'ai strictement rien dans mon port cartouche
J'ai mappé la page RAM n°3 dans l'espace cartouche et je bosse donc entre $B000 et $EFFF
Je transfert mon programme de test en $4000 (ou $6000 ca fait pareil)
La je transfert la zone $C000-$C0FF en RAM situé entre $6000-$9FFF (zone choisie par OS9
Apres le transfert je retourne a l'appelant et j'affiche le dump.

Si dans ma routine je ne touche pas au registre $A7CB, je n'ai aucun soucis
Si dans ma routine, je fais CLR >$A7CB, mon dump affiche n'importe quoi, mais des truc s'affichent (je disais que ça plantait car je n'avais pas l'affichage espéré), par contre après je ne peux plus rien faire.
Si dans me routine j'écris 1, ou 2, ou 3 en $A7CB, la j'ai vraiment un plantage, rien ne s'affiche à l'écran, et je n'ai plus la main.

Pourtant écrire 1, ou 2 ou 3, n'affecte pas le bit B2, donc il ne devrait pas y avoir de commutation de page (je précise que je n'ai strictement rien de connecté sur le port cartouche)

Et enfin autre précision: Quand je parle d'écran, d'affichage, ce n'est pas sur le moniteur du MO6.
Je travail au travers d'une liaison série a 19200 baud connecté sur l'extension RF 57932.
Comme je vais du téléchargement XModem sur la liaison série, j'utilise également cette liaison série en temps que terminal VT100 sous os9

Je pense que le gate array du MO6 n'est pas le meme que celui du MO5NR, et que certain registres (du genre mapper le registre $A7CB, et une fonctionnalité caché!