Dump de la rom IO_CPU

gilles · Message par **gilles** » 02 juil. 2009 01:16

jester a écrit :Pour l'assembleur TMS7000 il y a:
TASM
et
AS

En espérant que le 7041 ne dispose pas d'instructions avec un microcode différent qui entraine un fonctionnement complètement différent: c'est le cas pour le 7020 embarqué dans l'EXL100 (et modifié pour l'occasion).

des ASM pas tout jeunes

mais à priori l'un ou l'autre devrait convenir (meme si aucun ne respecte le format TEXAS).
TASM fonctionne avec des tables, donc pas de probleme pour d'eventuelles instructions micro codées, ceci étant il s'agit ici d'assembler du code et non de désassembler donc cela ne devrait pas poser de probleme (si ce n'est lors du désassemblage ultérieur (mais on n'y est pas...))
AS étant le seul opensource, je propose de repartir plutôt de cet ASM là...

jester · Message par **jester** » 02 juil. 2009 13:18

Perso j'ai testé un peu Telemark cross ASeMbleur (TASM) et il produit du code binaire TMS7000 sans soucis et très vite. J'ai même modifié la table d'instructions pour matcher avec le TMS7020 d'exelvision (j'ai remplacé SWAP par LVDP par exemple).
Bien sur il ne génère pas du code objet "loadable" à partir d'exeldos... mais je ne pense pas que cela soit utile pour l'extraction de ROM. Du binaire doit vous suffir (c'est d'ailleurs le choix que j'ai fait pour les développements futurs, via un chargeur spécifique pour ExelDos).

Pas testé AS car TASM me convient bien... mais je suppose qu'il génère le même binaire.

Pas tout jeunes les ASM, mais ils s'exécutent sans problème en environnement Windows et fournissent tout le confort possible pour un microcontroleur de presque 30ans !
La seule vraie limitation est qu'aucun ne produit du code Linkable, et donc pas d'édition de liens. Mais la encore, ça ne vous sera pas utile pour cette tâche.

Bon courage.

gilles · Message par **gilles** » 02 juil. 2009 14:07

jester a écrit :Perso j'ai testé un peu Telemark cross ASeMbleur (TASM) et il produit du code binaire TMS7000 sans soucis et très vite. J'ai même modifié la table d'instructions pour matcher avec le TMS7020 d'exelvision (j'ai remplacé SWAP par LVDP par exemple).
Bien sur il ne génère pas du code objet "loadable" à partir d'exeldos... mais je ne pense pas que cela soit utile pour l'extraction de ROM. Du binaire doit vous suffir (c'est d'ailleurs le choix que j'ai fait pour les développements futurs, via un chargeur spécifique pour ExelDos).

Pas testé AS car TASM me convient bien... mais je suppose qu'il génère le même binaire.

Pas tout jeunes les ASM, mais ils s'exécutent sans problème en environnement Windows et fournissent tout le confort possible pour un microcontroleur de presque 30ans !
La seule vraie limitation est qu'aucun ne produit du code Linkable, et donc pas d'édition de liens. Mais la encore, ça ne vous sera pas utile pour cette tâche.

Bon courage.

Clairement TASM est plus simple mais est surtout un sharware limité à 30jours, il coute 40$, ce n'est pas énorme mais je pense que ca va faire pencher la balance vers AS.
J'ai un peu commencé à jouer avec ce matin, je ferai plus de tests ce soir... je pense également faire migrer le desassemblage de mon emu vers la syntaxe Motorola pour simplifier la reprise de code de la ROM originale.

Message par **Torlus** » 02 juil. 2009 15:33

gilles a écrit :Il me semble que les docs parlent rapidement des 7xx1 mais en indiquant que ces composants étaient incomplets et ont été remplacé par les 7xx2.
Le mode full-expansion est plus proche du mode microprocesseur.
Puisqu'il faudra implémenter le magnifique bus multiplexé des 7xxx pour accéder à la ROM externe, autant que la routine copie la ROM interne vers de la RAM externe en mode full expansion, non?

Oui effectivement on peut éventuellement passer du mode "Microprocessor" au mode "Full Expansion", vu que la ROM est "visible" dans ce mode. Ca simplifiera largement le code TMS7000 à écrire. Ensuite il suffira de bricoler de quoi dumper la RAM.

Message par **Torlus** » 04 juil. 2009 21:19

J'ai commencé à potasser le sujet, je vois bien ce que j'ai à préparer côté hardware.
Pour la partie software, jester, ou gilles, comme vous êtes bien plus familiers que moi avec la machine, est-ce que vous pourriez préparer quelque chose ? Sinon, merci de me le dire, que je commence à m'y plonger

gilles · Message par **gilles** » 05 juil. 2009 14:51

Torlus a écrit :J'ai commencé à potasser le sujet, je vois bien ce que j'ai à préparer côté hardware.
Pour la partie software, jester, ou gilles, comme vous êtes bien plus familiers que moi avec la machine, est-ce que vous pourriez préparer quelque chose ? Sinon, merci de me le dire, que je commence à m'y plonger

je vais préparer ca cette semaine
a priori sous AS (car la fonction DEPHASE sera tres utile)
et je pense dériver une version de mon emu pour effectuer les premiers tests

jester · Message par **jester** » 05 juil. 2009 17:21

De mon coté je n'ai pas le temps (ni l'envi) de me taper la doc (très longue) de AS... qui semble a priori assez difficile d'accès et beaucoup moins adapté au TMS7000.
Je pense aussi être un boulet car je ne suis pas sur d'avoir vraiment compris le contenu du programme machine: copier une partie de la ROM dans la RAM registres, puis capter le changement d'état et sortir l'échantillon de ROM sur un port/mémoire (?), puis capter un nouveau changement d'état et continuer l'extraction de la ROM ???

Il faudrait pas commencer par tester si le changement d'état d'un 7041 version exelvision supporte des changements d'état en maintenant l'état de ses registres ?

Message par **Fabrice Montupet** » 05 juil. 2009 20:58

S'il faut sacrifier pour l'occasion un EXL100, dites-le mois

Message par **Torlus** » 05 juil. 2009 21:19

Que ce soit avec TASM ou AS, c'est pas important. Meme si TASM n'est dispo que 30 jours, ça ira largement

Si tu préfères utiliser TASM, pas de souci, de toute façon le code final devrait énormément se ressembler

Le programme pourrait se résumer ainsi :
- Inits nécessaires, et copie de sa propre suite dans la RAM, débranchement vers celle-ci (c'est peut-être là que les différences entre assembleurs pourraient se faire sentir, ça dépend aussi des modes d'adressage, bref, je vous laisse regarder

).
- La suite se déroule donc en RAM. Le prog pourrait par exemple déclencher la bascule du mode "Microprocessor" au mode "Full Expansion" en allant lire une 1ere adresse mémoire paticulière.
- Le prog ensuite lit en boucle une 2eme adresse mémoire particulière, et teste si la valeur stockée à cette adresse vaut disons $55 (c'est la carte FPGA qui positionnera cette valeur à cette adresse quand la bascule sera faite). S'il y a un peu "d'instabilité" lors du changement de mode, cette astuce devrait être suffisante pour s'en sortir, du moins je l'espère.
- Ensuite le prog fait une copie mémoire de la zone de $F000 à $FFFF vers la zone de $2000 à $2FFF.
- (Optionnel) Il signale qu'il a terminé en lisant une 3eme adresse particulière et part en boucle d'attente infinie.

Je comprends ta remarque sur le changement d'état, mais comment veux-tu le tester ?

Ici avec cette routine on réalise à la fois ce test, et le dump si on a de la chance

Hormis cette inconnue, je vois une autre petite difficulté : soit on considère que le registre IOCNT0 reste inchangé durant le changement de mode, et tout va bien, on prépare la bascule en mode "Full Expansion" et le prog expliqué plus haut marche direct. Soit on prévoit qu'il soit réinitialisé pendant le changement de mode, et qu'on peut se retrouver en mode "Single Chip". Auquel cas, soit on utilise des I/O pour savoir si la bascule a été réalisée par la carte FPGA, soit (solution que je préconiserai) on se passe de ce signal, et on code juste une boucle d'attente (et on fait l'init de IOCNT0 avant de passer à la suite, bien entendu).

gilles · Message par **gilles** » 06 juil. 2009 10:25

Fabrice Montupet a écrit :S'il faut sacrifier pour l'occasion un EXL100, dites-le mois

sacrifier est un grand mot, tout juste lui emprunter son 7041 le temps du test (voire intercaller entre lui et sa carte mere un montage étrange pour l'isoler (l'avantage étant d'avoir directement les horloges correctes))

jester · Message par **jester** » 06 juil. 2009 10:40

Torlus a écrit :Que ce soit avec TASM ou AS, c'est pas important. Meme si TASM n'est dispo que 30 jours, ça ira largement

Il est juste déontologiquement limité à 30jours... rien d'autre.

Torlus a écrit : - Inits nécessaires, et copie de sa propre suite dans la RAM,débranchement vers celle-ci

Il faut donc que le 7041 boot sur ce programme ??
J'ai pas bien saisi son rôle et surtout comment booter sur ce programme... on suppose qu'on est en mode microprocesseur ?
Moi avoir pas bien compris ce point.

Torlus a écrit : - La suite se déroule donc en RAM. Le prog pourrait par exemple déclencher la bascule du mode "Microprocessor" au mode "Full Expansion" en allant lire une 1ere adresse mémoire paticulière.

Pour alerter ton FPGA qui gère le basculement...

Torlus a écrit : - Le prog ensuite lit en boucle une 2eme adresse mémoire particulière, et teste si la valeur stockée à cette adresse vaut disons $55 (c'est la carte FPGA qui positionnera cette valeur à cette adresse quand la bascule sera faite). S'il y a un peu "d'instabilité" lors du changement de mode, cette astuce devrait être suffisante pour s'en sortir, du moins je l'espère.

Ok, j'ai compris.

Torlus a écrit : - Ensuite le prog fait une copie mémoire de la zone de $F000 à $FFFF vers la zone de $2000 à $2FFF.

La ça va...

Torlus a écrit : - (Optionnel) Il signale qu'il a terminé en lisant une 3eme adresse particulière et part en boucle d'attente infinie.

à l'aide d'un LDA ou en scrutant un port (MOVP) ?

J'ai remarqué que dans la Doc technique du TMS7000, plusieurs figures se contredisaient: FIG3.5+FIG3.6 par rapport à la FIG3.10.
Ce n'est pas bon signe car dans le cas ou la 3.6 est bonne cela veut dire que le mode Full Expansion ne permet pas d'accéder aux adresse >0200-F000 ! (je suppose que le 7041 est identique au 70x2)
Pas clair tout ça

gilles · Message par **gilles** » 06 juil. 2009 10:42

Torlus a écrit :Que ce soit avec TASM ou AS, c'est pas important. Meme si TASM n'est dispo que 30 jours, ça ira largement Si tu préfères utiliser TASM, pas de souci, de toute façon le code final devrait énormément se ressembler
.

je regarde tout ca ce soir, mais normalement les sources AS et TASM devraient etre compatibles, les 2 utilisent la syntaxe motorola visiblement.

Message par **Torlus** » 06 juil. 2009 14:27

jester a écrit : à l'aide d'un LDA ou en scrutant un port (MOVP) ?

J'ai remarqué que dans la Doc technique du TMS7000, plusieurs figures se contredisaient: FIG3.5+FIG3.6 par rapport à la FIG3.10.
Ce n'est pas bon signe car dans le cas ou la 3.6 est bonne cela veut dire que le mode Full Expansion ne permet pas d'accéder aux adresse >0200-F000 ! (je suppose que le 7041 est identique au 70x2)
Pas clair tout ça

Je pensais avec un LDA.
Effectivement pas clair ces tableaux. Enfin ça me semble difficile que le mode "Full Expansion" ne puisse pas adresser de la mémoire externe, c'est précisément son but il me semble

Sinon on peut se la jouer parano et n'utiliser que les fonctionnalités du mode "Peripheral Extension".

jester · Message par **jester** » 06 juil. 2009 15:59

Ce que j'ai pas compris c'est le bootstrap pour faire en sorte que le 7041/2 ,passé en mode microprocesseur, exécute notre programme en RAM...
où se trouve la première instruction qu'il doit exécuter ?

Message par **Torlus** » 06 juil. 2009 18:09

Il va lire le "reset vector" en $FFFE-$FFFF (cf section 3.6).