Derniers sujets
Qui est en ligne ?
Il y a en tout 2 utilisateurs en ligne :: 0 Enregistré, 0 Invisible et 2 Invités Aucun
Le record du nombre d'utilisateurs en ligne est de 29 le Mer 25 Fév 2015 - 14:01
Connexion
Statistiques
Nous avons 241 membres enregistrésL'utilisateur enregistré le plus récent est ben_frog
Nos membres ont posté un total de 8921 messages dans 811 sujets
Apprendre l'Assembleur ORIC
+6
]0[v]
Dbug
Symoon
kenneth
drpsy
maximus
10 participants
Forum Oric :: Forums :: Forum Public :: Assembleur
Page 2 sur 2
Page 2 sur 2 • 1, 2
Re: Apprendre l'Assembleur ORIC
@Dbug : Merci! pour mappé le .bss sur la zone ça c'est ok jusque là je savais faire par contre on ne peux pas accéder logiciellement à cette overlay, non? Sinon comment fais-t-on car c'est très utile...
Pour les macros le caractère "\" c'est exactement la même utilisation qu'en C et en bash donc ok je vois Il faut obligatoirement spécifier un contexte en utilisant (. & .)?
Ou se trouve le dépôt SVN?
Pour les macros le caractère "\" c'est exactement la même utilisation qu'en C et en bash donc ok je vois Il faut obligatoirement spécifier un contexte en utilisant (. & .)?
Ou se trouve le dépôt SVN?
]0[v]- Messages : 60
Date d'inscription : 25/07/2019
Re: Apprendre l'Assembleur ORIC
Le lien est en bas a gauche sur la page http://www.defence-force.org
On a pas besoin de .( et .), mais quand je met des labels locaux, ca évite les conflits de noms.
Pour la ram overlay, c'est uniquement utilisable si on a un lecteur de disquette connecté, c'est juste un bit a changer en page 3 au niveau des registres du contrôleur de disquette pour sélectionner entre ROM Basic, EPROM du lecteur de disquette (pour le boot) et RAM overlay.
C'est la principale raison pour faire des logiciels sur disquette: 16 Ko gratis, même si on se sert pas du lecteur après avoir fini le chargement
Sur Microdisk il suffit de faire ca:
lda #%11111101
sta $314
par contre, bien penser que c'est instantané, et que si on fait pas gaffe ca va planter à la première tentative de lancer une interrupt ou un appel en ROM.
Premier truc a faire avant de passer en mode overlay est de désactiver les IRQ (avec SEI), ensuite une fois que la ram overlay est active, changer FFFE/FFFF pour pointer sur une routine d'interruption, et seulement alors remettre les IRQ en marche.
Y'a un exemple de code qui fait ca dans ma vieille démo Buggy Boy:
http://miniserve.defence-force.org/svn/public/oric/demos/buggy_boy/LcpIntro/vbl.s
On a pas besoin de .( et .), mais quand je met des labels locaux, ca évite les conflits de noms.
Pour la ram overlay, c'est uniquement utilisable si on a un lecteur de disquette connecté, c'est juste un bit a changer en page 3 au niveau des registres du contrôleur de disquette pour sélectionner entre ROM Basic, EPROM du lecteur de disquette (pour le boot) et RAM overlay.
C'est la principale raison pour faire des logiciels sur disquette: 16 Ko gratis, même si on se sert pas du lecteur après avoir fini le chargement
Sur Microdisk il suffit de faire ca:
lda #%11111101
sta $314
par contre, bien penser que c'est instantané, et que si on fait pas gaffe ca va planter à la première tentative de lancer une interrupt ou un appel en ROM.
Premier truc a faire avant de passer en mode overlay est de désactiver les IRQ (avec SEI), ensuite une fois que la ram overlay est active, changer FFFE/FFFF pour pointer sur une routine d'interruption, et seulement alors remettre les IRQ en marche.
Y'a un exemple de code qui fait ca dans ma vieille démo Buggy Boy:
http://miniserve.defence-force.org/svn/public/oric/demos/buggy_boy/LcpIntro/vbl.s
_________________
Dbug- Messages : 248
Date d'inscription : 06/01/2013
Re: Apprendre l'Assembleur ORIC
@]0[v] Pour le nombre de $16, un Oric réel en écrit effectivement 259 suivi par un $24.
Pour la lecture, il faut qu'il en repère 4 consécutifs, ensuite il boucle en attendant de trouver un $24
Pour un émulateur, la limite minimale est généralement de 4 octets puisque c'est le minimum nécessaire à la ROM BASIC.
Il me semble qu'il y a eu un format avec un seulement 3 octets $16 mais je ne suis pas sûr.
Donc, si c'est pour faire un fichier .tap destiné à un émulateur, 4 octets suffisent.
Pour un Oric réel, cela va probablement dépendre de la qualité de la bande, de l'enregistrement, du lecteur,..
Symoon, qui est le spécialiste K7 sur le forum, pourra te fournir beaucoup plus d'informations que moi sur ce que peut accepter un Oric réel (il le pousse dans ses derniers retranchements, voire au delà!)
Pour la lecture, il faut qu'il en repère 4 consécutifs, ensuite il boucle en attendant de trouver un $24
Pour un émulateur, la limite minimale est généralement de 4 octets puisque c'est le minimum nécessaire à la ROM BASIC.
Il me semble qu'il y a eu un format avec un seulement 3 octets $16 mais je ne suis pas sûr.
Donc, si c'est pour faire un fichier .tap destiné à un émulateur, 4 octets suffisent.
Pour un Oric réel, cela va probablement dépendre de la qualité de la bande, de l'enregistrement, du lecteur,..
Symoon, qui est le spécialiste K7 sur le forum, pourra te fournir beaucoup plus d'informations que moi sur ce que peut accepter un Oric réel (il le pousse dans ses derniers retranchements, voire au delà!)
assinie- Messages : 271
Date d'inscription : 09/02/2014
Re: Apprendre l'Assembleur ORIC
Etalage de culture :p
Alors, pourquoi on trouve des fichiers TAP avec un nombre de $16 qui varie ? C'est historique !
Contexte: les premiers émulateurs ont été créés au milieu des années 90. On comptait encore ses octets à l'époque, où les disques durs faisaient 400Mo. Donc on cherchait à réduire la taille des fichiers.
Le premier émulateur pour PC, Euphoric, demandait trois $16. En effet il lisait directement les octets sur le disque dur, il n'y avait donc pas besoin de synchro au niveau bit au début, donc trois suffisaient pour la ROM.
En revanche, Amoric, l'émulateur pour Amiga, lui acceptait un seul $16 (j'ignore pourquoi/comment), on trouvait donc des .TAP avec un seul $16. Pour la petite histoire Euphoric, par souci de compatibilité avec le peu de fichiers TAP existant à l'époque, a été modifé pour accepter un seul $16. Cette norme est tombée en désuétude depuis.
Et puis, cela a fini par poser des problèmes: certains programmes Oric contenaient la séquence $16$24 alors qu'il ne s'agissait pas de synchro, les émulateurs se trompaient dans des TAP multipart, bref ce n'était pas idéal.
Alors Euphoric est passé à quatre $16 (et par la même occasion offre la possibilité de chargement non plus par octets, mais par bits, utile pour certaines protections), tandis que parallèlement c'était je crois déjà le standard d'Oricutron apparu entretemps.
Mais Oricutron semble tolérer aussi trois $16.
Quant à Euphoric, pour raisons de compatibilité ascendante, si le TAP commence par trois $16, il reste sur son ancien fonctionnement (chargement par octets et recherche de $16$24 pour un début de programme), tandis que s'il commence par quatre $16, il cherchera ensuite au moins $16$16$16$16$24 pour un début de programme. Cela a posé quelques problèmes, car les outils de génération de TAP n'ont pas tous évolué, et mettent encore souvent seulement trois $16. Or il est arrivé que certains auteurs aient un TAP multipart dont la première partie commençait par quatre $16 (un loader codé sur Oricutron par exemple) puis la deuxième par trois seulement (une image convertie par un outil, par exemple) ce qui fait que la deuxième partie n'était pas chargée sur Euphoric: il manquait le quatrième $16 !
Je dis tout ça de mémoire, je peux donc me tromper un peu. Maintenant que je vous ai bien paumés avec les émulateurs, parlons ROM.
La ROM commence par shifter le contenu de ce qu'elle lit, jusqu'à obtenir un $16. Elle peut donc à cette occasion consommer deux $16: un premier dont la lecture a commencé en plein milieu, et un second qui sera lu en entier et validé.
Ensuite comme le dit Assinie, elle réclame trois $16 consécutifs, puis un $24 (qui peut être bien après, on pourrait même avoir n'importe quoi entre deux !), pour enfin démarrer la lecture de l'en-tête du programme.
On peut donc estimer qu'avec une lecture parfaite d'émulateur, quatre $16 suffisent, mais que dans la réalité de l'Oric, il vaut mieux tabler sur cinq, au strict minimum.
Pour Novalight, censé utiliser un lecteur digital nickel, j'en mets 30. C'est arbitraire, je pourrais sans doute en mettre moins, mais bon, ca marche bien ainsi.
Je ne sais pas si j'ai été clair, ou utile avec mes histoires
A noter que lors de nos dernières discussions sur le sujet, Fabrice (auteur d'Euphoric et d'outils de conversion K7) regrettait un peu de ne pas avoir d'emblée conservé tous les $16. Comme il le disait, cela nous aurait évité des problèmes
Alors, pourquoi on trouve des fichiers TAP avec un nombre de $16 qui varie ? C'est historique !
Contexte: les premiers émulateurs ont été créés au milieu des années 90. On comptait encore ses octets à l'époque, où les disques durs faisaient 400Mo. Donc on cherchait à réduire la taille des fichiers.
Le premier émulateur pour PC, Euphoric, demandait trois $16. En effet il lisait directement les octets sur le disque dur, il n'y avait donc pas besoin de synchro au niveau bit au début, donc trois suffisaient pour la ROM.
En revanche, Amoric, l'émulateur pour Amiga, lui acceptait un seul $16 (j'ignore pourquoi/comment), on trouvait donc des .TAP avec un seul $16. Pour la petite histoire Euphoric, par souci de compatibilité avec le peu de fichiers TAP existant à l'époque, a été modifé pour accepter un seul $16. Cette norme est tombée en désuétude depuis.
Et puis, cela a fini par poser des problèmes: certains programmes Oric contenaient la séquence $16$24 alors qu'il ne s'agissait pas de synchro, les émulateurs se trompaient dans des TAP multipart, bref ce n'était pas idéal.
Alors Euphoric est passé à quatre $16 (et par la même occasion offre la possibilité de chargement non plus par octets, mais par bits, utile pour certaines protections), tandis que parallèlement c'était je crois déjà le standard d'Oricutron apparu entretemps.
Mais Oricutron semble tolérer aussi trois $16.
Quant à Euphoric, pour raisons de compatibilité ascendante, si le TAP commence par trois $16, il reste sur son ancien fonctionnement (chargement par octets et recherche de $16$24 pour un début de programme), tandis que s'il commence par quatre $16, il cherchera ensuite au moins $16$16$16$16$24 pour un début de programme. Cela a posé quelques problèmes, car les outils de génération de TAP n'ont pas tous évolué, et mettent encore souvent seulement trois $16. Or il est arrivé que certains auteurs aient un TAP multipart dont la première partie commençait par quatre $16 (un loader codé sur Oricutron par exemple) puis la deuxième par trois seulement (une image convertie par un outil, par exemple) ce qui fait que la deuxième partie n'était pas chargée sur Euphoric: il manquait le quatrième $16 !
Je dis tout ça de mémoire, je peux donc me tromper un peu. Maintenant que je vous ai bien paumés avec les émulateurs, parlons ROM.
La ROM commence par shifter le contenu de ce qu'elle lit, jusqu'à obtenir un $16. Elle peut donc à cette occasion consommer deux $16: un premier dont la lecture a commencé en plein milieu, et un second qui sera lu en entier et validé.
Ensuite comme le dit Assinie, elle réclame trois $16 consécutifs, puis un $24 (qui peut être bien après, on pourrait même avoir n'importe quoi entre deux !), pour enfin démarrer la lecture de l'en-tête du programme.
On peut donc estimer qu'avec une lecture parfaite d'émulateur, quatre $16 suffisent, mais que dans la réalité de l'Oric, il vaut mieux tabler sur cinq, au strict minimum.
Pour Novalight, censé utiliser un lecteur digital nickel, j'en mets 30. C'est arbitraire, je pourrais sans doute en mettre moins, mais bon, ca marche bien ainsi.
Je ne sais pas si j'ai été clair, ou utile avec mes histoires
A noter que lors de nos dernières discussions sur le sujet, Fabrice (auteur d'Euphoric et d'outils de conversion K7) regrettait un peu de ne pas avoir d'emblée conservé tous les $16. Comme il le disait, cela nous aurait évité des problèmes
Dernière édition par Symoon le Jeu 8 Aoû 2019 - 21:50, édité 1 fois
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Apprendre l'Assembleur ORIC
PS: à noter que les $16 ont aussi une fonction annexe: ils permettent une pause entre deux parties d'un programme. Ca laisse le temps à l'Oric d'exécuter la première partie alors que la bande continue à défiler. Réduire le nombre de $16, dans le cas où la bande défile, risquerait de voir passer la séquence d'intro alors que l'Oric n'en est pas encore au CLOAD. Autrement dit il faudrait augmenter la durée du silence entre les parties, donc réduire les $16 dans ce cas ne sert à rien ;-)
Sur les émulateurs, qui arrêtent la lecture et la reprennent en parfaite synchro avec l'exécution du programme, le problème ne se pose pas. Moralité: toujours garder à l'esprit les conditions d'utilisation de la "vraie machine" !
Et pour finir, concernant les fichiers TAP, je pense qu'il reste une écrasante majorité de fichiers avec seulement trois $16, qui a été la norme pendant de nombreuses années qui ont vu beaucoup de transferts de K7 - sans parler des outils qui sont restés à trois aujourd'hui.
Sur les émulateurs, qui arrêtent la lecture et la reprennent en parfaite synchro avec l'exécution du programme, le problème ne se pose pas. Moralité: toujours garder à l'esprit les conditions d'utilisation de la "vraie machine" !
Et pour finir, concernant les fichiers TAP, je pense qu'il reste une écrasante majorité de fichiers avec seulement trois $16, qui a été la norme pendant de nombreuses années qui ont vu beaucoup de transferts de K7 - sans parler des outils qui sont restés à trois aujourd'hui.
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Apprendre l'Assembleur ORIC
Dans la doc j'avais déjà vu que (. & .) dans XA permettait d'éviter les conflits de nom et c'est vraiment très pratique
Donc si l'on souhaite sans lecteur de DSK utiliser une interface il faut avoir charger un "OS" dans cette même RAM overlay si l'on veut désactiver la principale sinon il n'y a plus de possibilité d’interpréter aucunes commandes, non?
Sachant qu'il y a 16K ça ne laisse pas trop de place pour une utilisation tierce, non?
Et je vais regarder ta demo, maintenant
Donc si l'on souhaite sans lecteur de DSK utiliser une interface il faut avoir charger un "OS" dans cette même RAM overlay si l'on veut désactiver la principale sinon il n'y a plus de possibilité d’interpréter aucunes commandes, non?
Sachant qu'il y a 16K ça ne laisse pas trop de place pour une utilisation tierce, non?
Et je vais regarder ta demo, maintenant
]0[v]- Messages : 60
Date d'inscription : 25/07/2019
Re: Apprendre l'Assembleur ORIC
Merci pour vos explications détaillées, maintenant je comprends d'où sort ce 4x$16
Donc si je résume bien, lorsqu'on souhaite développer un programme d'abord sur l'émulateur (par faciliter) et ensuite le tester en réel le mieux étant d'écrire direct dans le code son propre "header" avec une amorce la plus longue possible (259) afin de pouvoir assurer un fonctionnement avec un vieux lecteur K7.
C'est noter!
Donc si je résume bien, lorsqu'on souhaite développer un programme d'abord sur l'émulateur (par faciliter) et ensuite le tester en réel le mieux étant d'écrire direct dans le code son propre "header" avec une amorce la plus longue possible (259) afin de pouvoir assurer un fonctionnement avec un vieux lecteur K7.
C'est noter!
]0[v]- Messages : 60
Date d'inscription : 25/07/2019
Re: Apprendre l'Assembleur ORIC
Non, si tu n'as pas de lecteur de contrôleur de disquette branché, la ram overlay n'est simplement pas accessible du tout: Les orics ont tous 64K de ram, mais les composants électroniques permettant d'accéder au 16k du haut ne sont pas présents.\" a écrit:0[v]"]Donc si l'on souhaite sans lecteur de DSK utiliser une interface il faut avoir charger un "OS" dans cette même RAM overlay si l'on veut désactiver la principale sinon il n'y a plus de possibilité d’interpréter aucunes commandes, non?
Sachant qu'il y a 16K ça ne laisse pas trop de place pour une utilisation tierce, non?
Et oui, c'est soit la ROM soit la RAM overlay, mais ce que fait le DOS c'est d'avoir un peu de code en page 4 (donc de #400 a #4FF) pour exécuter soit en ROM soit en RAM selon que l'on appelle une fonction du BASIC ou du DOS.
16K en plus, c'est gigantesque :p
C'est suffisant pour faire tenir deux buffers écrans supplémentaires, ou bien tout ce qu'il faut pour faire tenir une musique, ou bien des sprites, ou bien du code optimisé pour faire des copies écran, etc...
Mais bon, raisonnablement parlant, c'est pour ceux qui font de l'assembleur, du moins pour ceux qui n'on pas besoin de la ROM (la ROM est compacte, mais lente)
_________________
Dbug- Messages : 248
Date d'inscription : 06/01/2013
Re: Apprendre l'Assembleur ORIC
\" a écrit:0[v]"]Donc si je résume bien, lorsqu'on souhaite développer un programme d'abord sur l'émulateur (par faciliter) et ensuite le tester en réel le mieux étant d'écrire direct dans le code son propre "header" avec une amorce la plus longue possible (259) afin de pouvoir assurer un fonctionnement avec un vieux lecteur K7.
Presque
Ce qu'il faut retenir, c'est que le mieux pour les émulateurs est d'utiliser au moins quatre $16.
Ensuite si tu veux revenir à une vraie K7, eh bien le seul outil que je connaisse qui convertisse un .TAP en .WAV standard (TAP2WAV) restore de lui-même les $16 façon Oric (peut-être pas pile 259, mais genre 256 quoi !)
Mais tu peux aussi partir sur 259 et ne plus te poser de questions
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Apprendre l'Assembleur ORIC
@Symoon : ok merci, je viens de vérifier dans le repo. '
il semble que le nom du binaire soit tapTool maintenant?... et qu'il utilise 128 octets à $16 donc suffisamment pour a priori effectuer une bonne synchro.
Je vais donc compiler une version pour un*x-like et voir ce que cela donne.
En esperant que cela permette de rendre plus robuste tout ce processus. Car avec l'oric l'utilisation d'un support K7 est vraiment catastrophique comparer à un canon X07 ou un T100.
C'est pas grave c'est ça qui fait tout son charme
svn - Revision 1526: /public/pc/tools/osdk/main
'il semble que le nom du binaire soit tapTool maintenant?... et qu'il utilise 128 octets à $16 donc suffisamment pour a priori effectuer une bonne synchro.
Je vais donc compiler une version pour un*x-like et voir ce que cela donne.
En esperant que cela permette de rendre plus robuste tout ce processus. Car avec l'oric l'utilisation d'un support K7 est vraiment catastrophique comparer à un canon X07 ou un T100.
C'est pas grave c'est ça qui fait tout son charme
]0[v]- Messages : 60
Date d'inscription : 25/07/2019
Re: Apprendre l'Assembleur ORIC
@Dbug : d'accord c'est donc bien ce que j'avais compris et oui c'est vrai 16KB pour ces machines c'est énorme!
J'imagine que dans les sources d'oricutron/euphoric on doit trouver le code qui est placé en page 4, je vais regarder ça.
Cela veut donc dire que l'on peut se fabriquer une interface qui, par mimétisme avec un lecteur de DSK, placera au démarrage le code de ce "mini-interpreteur" en page 4 et pourra donc beneficier de 16K et plus dans l'interface si l'on utilise une sorte de MMU, non?
J'imagine que dans les sources d'oricutron/euphoric on doit trouver le code qui est placé en page 4, je vais regarder ça.
Cela veut donc dire que l'on peut se fabriquer une interface qui, par mimétisme avec un lecteur de DSK, placera au démarrage le code de ce "mini-interpreteur" en page 4 et pourra donc beneficier de 16K et plus dans l'interface si l'on utilise une sorte de MMU, non?
]0[v]- Messages : 60
Date d'inscription : 25/07/2019
Re: Apprendre l'Assembleur ORIC
Le code en page 4 est installé par le DOS lu depuis la disquette.
C'est juste en page 4 parce que c'était pratique, mais ca pourrait être n'importe ou.
Pour activer la mémoire overlay il suffit juste de quelque composants, il y avait même un montage dans un vieux numéro de Théoric.
C'est juste en page 4 parce que c'était pratique, mais ca pourrait être n'importe ou.
Pour activer la mémoire overlay il suffit juste de quelque composants, il y avait même un montage dans un vieux numéro de Théoric.
_________________
Dbug- Messages : 248
Date d'inscription : 06/01/2013
Re: Apprendre l'Assembleur ORIC
J'ai fait un petit schéma, et la seule difficulté était de générer le signal /MAP en avance de phase de 80 à 100ns par rapport à Ø2 (l'oric a nu page 24). Je vais essayer de câbler ça ce w.d si j'ai du temps de libre
Pour le code du "loader" installé en page 4 je vais essayer de trouver les sources et je m'en servirais pour les adaptés à mon besoin (vieux plan memoire de 64KB RAM statique dont je me servirais comme "SSD"
Je vais poursuivre eventuellement ce post dans un autre topic car plus trop adapté maintenant...
Pour le code du "loader" installé en page 4 je vais essayer de trouver les sources et je m'en servirais pour les adaptés à mon besoin (vieux plan memoire de 64KB RAM statique dont je me servirais comme "SSD"
Je vais poursuivre eventuellement ce post dans un autre topic car plus trop adapté maintenant...
]0[v]- Messages : 60
Date d'inscription : 25/07/2019
Re: Apprendre l'Assembleur ORIC
j'utilise XA (oui je sais ca65 est super bien aussi ) mais je pense que le problème est indépendant de l'assembleur lui même c'etait juste pour établir le contexte...
Donc je souhaite créer une sorte de driver pour un périphérique. Actuellement j'ecris mon code en assembleur, je build via un script bash maison puis j'obtiens un fichier basic autogénéré qui contient le loader avec ses datas en hexa ensuite je rajoute la partie de code qui utilise les fonctions en assembleur pour contrôler mon périphérique.
Le truc c'est que j'utilise des segments:
.zero pour certaines variables (mode d'adressage rapide)
.bss pour des tableaux contenant des chaines de caracteres rentrees par l'utilisateur
et finalement
.text pour la partie code
XA va générer un fichier objet au format o65 découpé en 3 parties header, code, les variables pour chaque segments
Le truc c'est comment j'accede en BASIC aux variables que j'ai définies dans mon fichier .asm (.s)? dans le .bss?
Ce que je pense c'est qu'il faut extraire du fichier o65 la partie du segment .text afin de coder ces datas seulement car sinon le reste ne veut rien dire bien sûr, et pour le reste tenir compte dans le programme basic des adresses utilisées pour les diférentes variables, j'ai bon?!
Je sais pas si c'est vraiement clair...
Donc je souhaite créer une sorte de driver pour un périphérique. Actuellement j'ecris mon code en assembleur, je build via un script bash maison puis j'obtiens un fichier basic autogénéré qui contient le loader avec ses datas en hexa ensuite je rajoute la partie de code qui utilise les fonctions en assembleur pour contrôler mon périphérique.
Le truc c'est que j'utilise des segments:
.zero pour certaines variables (mode d'adressage rapide)
.bss pour des tableaux contenant des chaines de caracteres rentrees par l'utilisateur
et finalement
.text pour la partie code
XA va générer un fichier objet au format o65 découpé en 3 parties header, code, les variables pour chaque segments
Le truc c'est comment j'accede en BASIC aux variables que j'ai définies dans mon fichier .asm (.s)? dans le .bss?
Ce que je pense c'est qu'il faut extraire du fichier o65 la partie du segment .text afin de coder ces datas seulement car sinon le reste ne veut rien dire bien sûr, et pour le reste tenir compte dans le programme basic des adresses utilisées pour les diférentes variables, j'ai bon?!
Je sais pas si c'est vraiement clair...
]0[v]- Messages : 60
Date d'inscription : 25/07/2019
Re: Apprendre l'Assembleur ORIC
Avec xa, à moins d'utiliser l'option -R, le fichier obtenu contient directement le programme assembléet exécutable.
Si tu veux récupérer les adresses des différentes variables, il faut que tu ajoutes l'option -l suivie par un nom de fichier qui contiendra tous les labels avec leur adresse.
Chaque ligne de ce fichier commence par le label suivi par son adresse.
Exemple (les valeurs des variables sont sans importance et ne seront pas dans le programme final puisque les segments .zero et .bss ne sont pas initialisés):
fichier des labels test.labels obtenu apèrs assemblage avec xa -l test.labels test.s:
Le segement text commence en $1000 par défaut et le segment bss en $4000.
Si tu veux récupérer les adresses des différentes variables, il faut que tu ajoutes l'option -l suivie par un nom de fichier qui contiendra tous les labels avec leur adresse.
Chaque ligne de ce fichier commence par le label suivi par son adresse.
Exemple (les valeurs des variables sont sans importance et ne seront pas dans le programme final puisque les segments .zero et .bss ne sont pas initialisés):
- Code:
.zero
z0:
.word $0000
.text
_main:
lda #$67
sta z0
lda b1
sta b0
rts
.bss
b0:
.word $0000
b1:
.byte $00
fichier des labels test.labels obtenu apèrs assemblage avec xa -l test.labels test.s:
- Code:
z0, 0x0004, 0, 0x0005
_main, 0x1000, 0, 0x0000
b1, 0x4002, 0, 0x0004
b0, 0x4000, 0, 0x0004
Le segement text commence en $1000 par défaut et le segment bss en $4000.
assinie- Messages : 271
Date d'inscription : 09/02/2014
Re: Apprendre l'Assembleur ORIC
@assinie, oui alors je génére déjà ce fichier que dont je nomme l'extension .map et les labels de mes fonctions commence toutes avec un 'f' ce qui fait que je peux aussi générer la table d'appel des fonctions de la lib en modifiant le fichier asm et en le recompilant à nouveau en version intégrant la table d'appel.
Bien que l'expression de mon problème ne soit pas très clair je pense que tu as d'ores et déjà répondu à ma question comme dans mon cas il ne s'agit pas d'un programme qui doit tourner seul mais pour lequel je dois récuperer le code hexa pour l'incorporer à mon programme basic. En revanche je viens de penser qu'au lieu d'incorporer le code de la lib à mon programme applicatif je pourrais simplement charger la lib en 1° et ensuite charger mon programme basic, ça serait quand même bcp plus simple que de faire tout ça!!! comme quoi...
Bien que l'expression de mon problème ne soit pas très clair je pense que tu as d'ores et déjà répondu à ma question comme dans mon cas il ne s'agit pas d'un programme qui doit tourner seul mais pour lequel je dois récuperer le code hexa pour l'incorporer à mon programme basic. En revanche je viens de penser qu'au lieu d'incorporer le code de la lib à mon programme applicatif je pourrais simplement charger la lib en 1° et ensuite charger mon programme basic, ça serait quand même bcp plus simple que de faire tout ça!!! comme quoi...
]0[v]- Messages : 60
Date d'inscription : 25/07/2019
Re: Apprendre l'Assembleur ORIC
Je pensais que tu cherchais comment récupérer ces infos, mais j'avoue que je n'ai pas bien compris ce que tu veux faire.
Tu peux mettre des labels directement dans la table et pas seulement des adresses:
Si c'est une librairie utilisée par un autre programme, il suffit que le programme connaisse l'adresse de la table, dans ce cas, le plus simple est de la mettre à une adresse fixe ou de mettre son adresse à un emplacement fixe et connu (au début de la librairie par exemple), ou de passer par une fonction d'appel située à une adresse connue à laquelle tu passes un n° de fonction en paramètre et/ou les arguments dont elle a besoin.
Sinon, il y a aussi l'éditeur de liens
Je ne comprends pas non plus, si le but est d'avoir une table contenant des adresses, tu n'es pas obligé de le faire en 2 fois en modifiant toi-même la table.je peux aussi générer la table d'appel des fonctions de la lib en modifiant le fichier asm et en le recompilant à nouveau en version intégrant la table d'appel.
Tu peux mettre des labels directement dans la table et pas seulement des adresses:
- Code:
.text
fn1:
lda #$00
sta v1
rts
fn2:
...
fn3:
....
table_fn:
.word fn1, fn2, fn3
table_var:
.word v1, v2
.bss
v1:
*=*+1
v2:
*=*+1
Si c'est une librairie utilisée par un autre programme, il suffit que le programme connaisse l'adresse de la table, dans ce cas, le plus simple est de la mettre à une adresse fixe ou de mettre son adresse à un emplacement fixe et connu (au début de la librairie par exemple), ou de passer par une fonction d'appel située à une adresse connue à laquelle tu passes un n° de fonction en paramètre et/ou les arguments dont elle a besoin.
Sinon, il y a aussi l'éditeur de liens
assinie- Messages : 271
Date d'inscription : 09/02/2014
Re: Apprendre l'Assembleur ORIC
Je me disais bien aussi que c'etait pas clair
La table est générée automatiquement sans que j'ai à me soucié de faire les calculs à la main donc ça c'est ok, c'etait juste la manière dont je pouvais intégrer ça avec cette saleté de basic et j'ai trouvé, un peu grâce à toi
J'ecris donc ma lib en asm et j'en tire un .tap puis .wav je charge ça et ensuite je charge l'application qui utilise les fonction de cette lib dont je connais l'adresse d'implantation.
Merci pour ton aide assinie
La table est générée automatiquement sans que j'ai à me soucié de faire les calculs à la main donc ça c'est ok, c'etait juste la manière dont je pouvais intégrer ça avec cette saleté de basic et j'ai trouvé, un peu grâce à toi
J'ecris donc ma lib en asm et j'en tire un .tap puis .wav je charge ça et ensuite je charge l'application qui utilise les fonction de cette lib dont je connais l'adresse d'implantation.
Merci pour ton aide assinie
]0[v]- Messages : 60
Date d'inscription : 25/07/2019
Page 2 sur 2 • 1, 2
Sujets similaires
» BLA BLA ORIC.ORG
» The Oric-1 is 30
» Des jeux SDL c'est possible
» Oric Explorer v2.0
» Boitier Oric HD
» The Oric-1 is 30
» Des jeux SDL c'est possible
» Oric Explorer v2.0
» Boitier Oric HD
Forum Oric :: Forums :: Forum Public :: Assembleur
Page 2 sur 2
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum
|
|
Jeu 21 Mar 2024 - 8:51 par Dom50
» carte mère Oric (re)tracée
Mar 5 Mar 2024 - 18:54 par kenneth
» Meurtre à Grande Vitesse
Dim 25 Fév 2024 - 5:09 par Iurius
» ORIC-1 sur LE BON COIN
Ven 23 Fév 2024 - 23:01 par Mcar
» ORIC ATMOS sur LE BON COIN
Dim 4 Fév 2024 - 12:06 par kiwilevrai
» Problème d'affichage des couleurs avec un Oric Atmos
Sam 27 Jan 2024 - 1:26 par pierbail
» Bienvenue dans le Forum des Oriciens
Mar 9 Jan 2024 - 12:33 par Dom50
» Rencontre avec Laurant Weill, co-fondateur de Loriciel, et mon garçon de 12 ans
Ven 29 Déc 2023 - 14:13 par Arcade-des-Monts
» Bonnes fêtes
Mar 26 Déc 2023 - 10:21 par Dom50
» Murders in Venice / Meutres à Venise
Sam 18 Nov 2023 - 22:44 par retroric
» Un clavier PS/2 pour tester un ORIC
Dim 27 Aoû 2023 - 9:49 par Voyageur
» Disquette 3" Sedoric
Mar 1 Aoû 2023 - 14:22 par AtomeX
» faire un 6502 avec des phototransistor
Dim 16 Juil 2023 - 17:26 par Voyageur
» Oricutron linux et DSK
Jeu 29 Juin 2023 - 18:34 par Voyageur
» No Problem !
Dim 25 Juin 2023 - 17:53 par Voyageur