Logicielsmoto.com

Nous sommes le 28 Mar 2024, 12:08

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 36 messages ]  Aller à la page Précédente  1, 2, 3  Suivante
Auteur Message
MessagePosté: 28 Oct 2020, 16:42 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Normalement la routine du moniteur marche bien, indépendamment de la page visible. D'ailleurs si je mets un point d'arret en lecture/écriture sur $E7DD il n'y a aucun "hit" lors des PUTC: Le moniteur ne s'occupe pas de la page mappée à l'écran (c'est d'ailleurs marrant à faire en basic lors d'un affichage en 80 colonnes: poke &HE7DD,64 ==> on voit la page 0 du moniteur en haut de l'écran s'afficher et bouger pendant que le reste du basic ou du jeu basic (run) fonctionne. C'est aussi spédctaculaire de faire un DIR pendant ce temps, ou de charger des trucs sur le disk: on voit carrément le buffer disk se charger à l'écran)

Similairement en point d’arrêt en $E7DC ne montre aucun hit à part lors des commandes de changement de mode.

Bref: il n'y a pas de raison de devoir passer par le poke direct en $E7DC pour passer en BM16, sauf pour la facilité de mise en oeuvre.

Ben écoute, je ne sais pas, c'est peut-être un bug dans DC MOTO, mais voilà quoi, j'ai utilisé le "moniteur" comme tu dis et ça m'a donné l'affichage que tu as vu dans la vidéo, alors qu'avec l'attribution en E7DC ça m'a affiché le bon mode. J'ai juste changé ça dans le code ASM (la routine moniteur en écriture dans le régistre E7DC)

Il y a aussi le problème de la durée du timer qui ne fonctionne pas
Code:
 LDD #24499 Timer toutes les 1/5s
 STD TSB
 LDX #FNTIMR Routine d interruption
 STX TIMEPT
 LDA >STATUT
 ORA #$20
 STA >STATUT

J'ai changé la valeur de STB mais ça reste la même vitesse!


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 28 Oct 2020, 17:00 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Si le mode graphique ou la page affichée change c'est que quelqu'un touche $E7DC, ou $E7DD. Si aucun "hit" en écriture apparaît et que ca le fait sous DCMoto c'est un bug de l'émulateur. Mais moi je n'observe pas ce comportement avec mes tests. Tu as une diskette avec le "bug" que je puisse essayer de comprendre ce qu'il se passe ? (c'est toujours intéressant de comprendre quand un truc ne marche pas "comme prévu").

Pour le timer je sais pas trop. Chez moi ca a l'air de marcher. A ta sortie d'interruption tu sautes bien à la bonne routine en ROM ? autre truc important si toi ou le basic faisaient re-apparaitre le curseur auparavant masqué (avec des PUTC ou ATTRB qui influent le bit 2 de $6019), la rom reset le TIMER pour que le curseur clignote à la bonne fréquence.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 28 Oct 2020, 21:12 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Attention $E7E7 n'est qu'en écriture seule. Quand on le lit on obtient n'importe quoi. Pour bien l'utiliser il faut lire $6081, modifier les bits qu'on veut, puis écrire $E7E7 et écrire $6081 pour garder trace de ce qu'on a mis dans $E7E7. Note: je dis 6081 de mémoire, mais c'est peut-être un autre endroit.. Il faut surveiller avec le débuggeur comment le moniteur thomson met à jour $E7E7 (=> point d’arrêt en écriture) pour trouver là où il écrit la copie de sauvegarde.

Pour la commutation de RAM à la mode "TO8", il faut s'assurer de ne pas être en mode émulation TO7 (commutation via le PIA), sinon ca marche moins bien.

Autre truc à savoir: la palette est inversée en mode BM16: la couleur $0 (noir) se trouve à l'entrée 8 de la palette (gris), et inversement, le 1 en 9 etc (sur TO9 c'est même pire, il y a les entrées 6 et 14 qui sont inversées en plus... un vrai foutoir pas possible le mode BM16 sur TO9, ca se voit qu'ils essuyaient les plâtres des modes graphiques étendus sur cette machine.)


??? Moi j'ai fait une lecture de E7E7 avant de modifier le bit 4, comment ce registre peut-il être modifié entre une lecture et une MAJ ? C'est pas expliqué dans la doc technique d'utiliser 6081, de plus, ADNZ m'a orienté vers ce lien http://pulsdemos.com/vector02.html où ils parlent effectivement de $6081 (et il semble y avoir une erreur, puisqu'on lit en 6181 et on écrit en 6081 ?? (Il me semble que les entrées de moniteurs sont entre 6000 et 6100 exclu alors que vient faire 6181 ici ?), en plus dans la doc techniques, ils disent que 6081 sert pour le buffer clavier ? Là je ne pige plus rien, on a des informations incohérentes...

Ce qu'il serait bien est qu'il y ait un site internet qui référence tous ces trucs là, régistre, sous routines etc (ça ne semble pas exister) pour les TO8 etc... Vi que j'ai déjà plusieurs sites internet à mon actif dont un sur la gamme des logiciels ATari ST et TOS... Parce que numériser en format graphique bm des pages de bouquin c'est pas très pratique dans le fond.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 28 Oct 2020, 22:22 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
y'a des explications ici, je sais pas si tu connais ce site :

http://pulkomandy.tk/wiki/doku.php?id=d ... gate_array

check la fin de la page.

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 28 Oct 2020, 23:01 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Si si il est expliqué dans le "Manuel technique TO8/TO9/TO9+" que $E7E7 a bien 2 types d'accès: p116 ce qu'on récupère en lecture (des infos sur la phase de dessin de l'écran + divers), p110 ce qu'on a en écriture (sélection contrôleur disk, choix mode affichage, choix type de machine, standard vidéo, etc)

Quand on lit un truc ca n'est pas ce qu'on a écrit auparavant! C'est pour ca qu'il faut toujours maintenir une copie à jour en $6081 sur TO. L'info n'est pas diffusée sur papier mais se découvre en désassemblant les roms et autres programmes.

$6181 est une typo: Yoann, si tu nous lis? tu crois que tu pourrais mettre à jour.

Il y a des infos saisie en partie à la main (donc avec des typos aussi) >>ici<<.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 29 Oct 2020, 02:09 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Samuel Devulder a écrit:
Tu as une diskette avec le "bug" que je puisse essayer de comprendre ce qu'il se passe ? (c'est toujours intéressant de comprendre quand un truc ne marche pas "comme prévu").

J'ai bien reçu ton source, et je mets mes remarques ici, ca peut intéresser d'autres personnes.

Bon j'ai pas cherché à compiler, j'ai juste regardé le code et il y a cette partie que je ne comprends pas. Tu peux m'expliquer?
Code:
 LDB $6019     <== lecture status
 ANDB #251     <== effacement b2 (clignotement curseur)
 STB $6019     <== mise à jour status
 JSR PUTC      <== envoie de n'importe quoi dans PUTC
 LDB #<un code>
 ..trucs space que je pige pas sans doute un forçage du mode BM16 par poke..
 ..2e putc pour passer en BM16..

Il ne manquerait pas un LDB #27 avant le premier PUTC ? C'est sans doute pour ca que le programme ne passe pas en BM16.

La façon d'éviter le clignotement du curseur, m'interpelle. En effet j'ai toujours utilisé PUTC pour cela (LDB #$14 puis JSR PUTC ==> c'est plus court). Tu ne voulais pas plutôt effacer le bit 5 (rapport aux interruptions) et pas le bit 2 (curseur) ?

Par ailleurs j'ai constaté que quand la ROM force le b2 (que tu as effacé) à 1 (par exemple avec LDB #$11 puis JSR PUTC), elle reset le timer à sa valeur initiale.
Code:
F1DF 9619       LDA    <$19                4
F1E1 8A04       ORA    #$04                2
F1E3 9719       STA    <$19                4 <== mise de b2 status à 1
F1E5 CC30D3     LDD    #$30D3              3
F1E8 FDE7C6     STD    $E7C6               6 <== reset compteur timer
F1EB 8646       LDA    #$46                2
F1ED B7E7C5     STA    $E7C5               5 <== reprogrammation timer mode cyclique
F1F0 A662       LDA    $02,S               5
F1F2 84EF       ANDA   #$EF                2
F1F4 A762       STA    $02,S               5
F1F6 639F605A   COM    [$605A]            11 <== cligno curseur
Est-ce qu'il n'y aurait pas un lien entre les deux ? Probablement que oui vu que tu perds la valeur mise dans le timer. En fait en retour d'EXEC qui est à la fin du programme, le basic rends la main au prompt avec un bel OK accompagné d'un #$11 qui est.. une demande d'affichage du curseur.

Bim! le timer est réinitialisé à la fréquence standard à la sortie du programme basic. Je pense que ton problème de timer viens sans doute de cela. Si tu veux tester cette hypothèse, fais en sorte que ton MAIN ne retourne pas la main au basic, ou même encore plus simple: fais un DO:LOOP vide en fin de programme basic pour qu'il ne print pas le "OK" fatidique pour le timer et voir si ainsi la vitesse d'animation reste identique à celle que tu as choisie.

Ensuite:
Code:
 LDA >REGSY1 Activation Mode Page..
 ORA #16 ...pour Banques RAM
 STA >REGSY1
lit $E7E7 qui ne contient pas la même chose qu'en écriture (on dit qu'en fait il est en écriture seule). La bonne façon de faire est:
Code:
 LDA >$6081 Activation Mode Page..
 ORA #16 ...pour Banques RAM
 STA >REGSY1
 STA >$6081


Enfin à la fin de ton interruption tu fais:
Code:
 LDA >DPINIT
 TFR A,DP
 JMP KBIN Contient un RTS
ce qui est doublement curieux. D'une part tu mets dans le DP de retour d'interruption la valeur de DP à l'entrée de ton programme principal. Or quand l'interruption se produit le DP peut être différent de celui à l'entrée du MAIN (le moniteur l'utilise en interne), et donc tu écraserait celui qu'il y avait au moment où l'interruption est arrivée. Ca peut poser des bugs.... sauf que non en fait, car KBIN se termine par un RTI (et pas un RTS), qui a la propriété --IRQ oblige-- de restaurer tous les registres CPU, DP y compris. Donc pas besoin de remettre la valeur supposée qui en fait n'est pas la bonne. C'est une opération totalement inutile (et dangereuse car le DP au moment de l'interruption n'est pas forcément celui que tu avais dans le MAIN).

Voilà c'était un petit retour rapide (quoique plus maintenant: le message a beaucoup grossis par rapport à ce que je voulais faire) mais instructif.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 29 Oct 2020, 09:56 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 681
Localisation: Provence (France)
Après avoir lu vos discussions je rappelle ce que j'ai toujours dit : ne faites pas confiance à dcmoto pour valider un programme, surtout s'il fait des choses un peu subtiles. Il faut valider avec la vraie machine. Si le comportement est différent dans dcmoto, donnez-moi un tout petit programme montrant la différence et je corrigerai immédiatement l'émulateur.

Autre point : Je confirme que la bonne pratique est de dupliquer en $6081 tout ce qu'on écrit en $E7E7 pour en garder une trace. Sinon il n'y a aucun autre moyen de retrouver ce qu'on a écrit. Il faut absolument respecter cette règle, car le moniteur et beaucoup d'autres programmes vont lire $6081 pour connaître le contenu de $E7E7. Si vous avez modifié le registre sans mettre à jour $6081 ces programmes vont se planter. Exemple : Mission: Liftoff (mais ce n'est pas le seul).


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 29 Oct 2020, 11:10 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Daniel Coulom a écrit:
Après avoir lu vos discussions je rappelle ce que j'ai toujours dit : ne faites pas confiance à dcmoto pour valider un programme, surtout s'il fait des choses un peu subtiles. Il faut valider avec la vraie machine. Si le comportement est différent dans dcmoto, donnez-moi un tout petit programme montrant la différence et je corrigerai immédiatement l'émulateur.

Autre point : Je confirme que la bonne pratique est de dupliquer en $6081 tout ce qu'on écrit en $E7E7 pour en garder une trace. Sinon il n'y a aucun autre moyen de retrouver ce qu'on a écrit. Il faut absolument respecter cette règle, car le moniteur et beaucoup d'autres programmes vont lire $6081 pour connaître le contenu de $E7E7. Si vous avez modifié le registre sans mettre à jour $6081 ces programmes vont se planter. Exemple : Mission: Liftoff (mais ce n'est pas le seul).


Bonjour Daniel, et merci pour ceci.

Cependant moi je suis passé par la lecture de E7E7 pour activer le passage de RAM
Code:
 LDA >REGSY1 Registre $E7E7
 ORA #16 Pour passage banque...
 STA >REGSY1 ...via E7E5

Je fais ça et ça marche parfaitement par la suite pour passer le numéro de banque via b4-b0 de E7E5.
Et en plus, dans la doc technique il est écrit que 6081 contient le buffer clavier (par défaut). S'il y avait un manuel technique où les algo.

Je ne comprends pas comment cette méthode peut être mauvaise. Y-aurait-il des écriture dans ce registre E7E7 entre le LDA et le STA ?

Enfin bon mon problème actuel est que le changement de la durée du timer en E7C6 ne semble pas fonctionner (sur DC Moto)

Pour ce qui est du TO8, il est en panne depuis de nombreuses années, je ne peux donc pas le tester, je n'utilise que DC Moto.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 29 Oct 2020, 11:18 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
La partie moniteur de la doc vient essentiellement du TO9. Sur TO8 c'est différent (parfois on trouve des addendum comme dans le manuel de l'ASM, mais pas toujours). C'est pas parce que "ca marche" que c'est pas buggé. C'est juste une coïncidence. Si ca se trouve le jours où tu mets un disk externe ou débranche le light-pen "ca marche plus". Comme indiqué plus haut ce registre est en écriture. En lecture on a tout autre chose. Il n'y a pas d'écriture. Un registre d'IO n'est *pas* une mémoire. Ce qu'on y lit n'est pas forcément ce qu'on y a écrit. C'est le cas pour $E7E7. J'ai déjà écrit tout ca plus haut.

Sinon pour le timer et les autres trucs dont le BM16 j'ai expliqué au dessus. Je me demande si tu lis bien attentivement les infos qu'on te donne.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 29 Oct 2020, 11:43 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 681
Localisation: Provence (France)
La réponse de Neotenien montre qu'il n'a pas compris le fonctionnement du registre $E7E7. Pourtant nos explications sont claires : il est impossible de relire ce qui a été écrit en $E7E7. La lecture en $E7E7 donne des informations sur la position du spot dans l'écran et sa détection par le crayon optique. Ça n'a rien à voir avec la commutation de banques.

Pour les registres du moniteur il n'y a aucune documentation correcte et c'est normal : chaque ROM de chaque ordinateur les utilise différemment. Le même emplacement peut contenir des données différentes d'une machine à l'autre. De plus, pour une même machine, le contenu dépend du contexte, car plusieurs routines du moniteur peuvent utiliser la même zone pour stocker des informations différentes. Sans compter les autres programmes qui ont besoin de zones de travail et stockent des valeurs dans des registres temporairement inutilisés par le moniteur. C'est le cas en particulier du contrôleur SDDRIVE, mais ce n'est pas le seul.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 29 Oct 2020, 12:17 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Bon j'ai pas cherché à compiler, j'ai juste regardé le code et il y a cette partie que je ne comprends pas. Tu peux m'expliquer?
Code:
 LDB $6019     <== lecture status
 ANDB #251     <== effacement b2 (clignotement curseur)
 STB $6019     <== mise à jour status
 JSR PUTC      <== envoie de n'importe quoi dans PUTC
 LDB #<un code>
 ..trucs space que je pige pas sans doute un forçage du mode BM16 par poke..
 ..2e putc pour passer en BM16..

Il ne manquerait pas un LDB #27 avant le premier PUTC ? C'est sans doute pour ca que le programme ne passe pas en BM16.

En fait j'ai fait un rapide copier coller avant de te l'envoyer.
Originellement (avant de yester le mode page) j'avais mis:

Code:
MAIN LDB #$1B sequence d echappement
 JSR PUTC
 LDB #$5E Mode bm16c
 JSR PUTC

Pour passer en mode bm16, mais comme je l'ai déjà dit auparavant, ça ne marchait plus pour les écrans "mode page" étant dans les banque RAM 2 et 3! Et c'est pour ça que j'ai mis
Code:
 LDB #$7B Mode bm16c
 STB MODVID Stocke bm16

Pour le passage en mode bm16 pour TOUS les écran (bank 0 à 3)

Citation:
La façon d'éviter le clignotement du curseur, m'interpelle. En effet j'ai toujours utilisé PUTC pour cela (LDB #$14 puis JSR PUTC ==> c'est plus court). Tu ne voulais pas plutôt effacer le bit 5 (rapport aux interruptions) et pas le bit 2 (curseur) ?

Pendant l'animation du sprite, il n'y a pas de clignotement du curseur (normal puisque c'est détourné via ma routine). D'autres part, dans la procédure d'initialisation du timer, on fait déjà appel au STATUS (6019) avec un ORA "$20 (IRQ Timer validé) sauf qu'à cette instant, je me demande s'il n'était pas validé déjà avant et du coup... l'initialisation n'utilise pas les anciennes valeur ? Normalement non... Ok je vais essayer de faire un test en

Citation:
Par ailleurs j'ai constaté que quand la ROM force le b2 (que tu as effacé) à 1 (par exemple avec LDB #$11 puis JSR PUTC), elle reset le timer à sa valeur initiale.

Normal c'est ce que c'est sensé faire (manuel de 'lassembleur 2.0 pour les TO8, p14 de la partie ""moniteur")

Citation:
Est-ce qu'il n'y aurait pas un lien entre les deux ? Probablement que oui vu que tu perds la valeur mise dans le timer. En fait en retour d'EXEC qui est à la fin du programme, le basic rends la main au prompt avec un bel OK accompagné d'un #$11 qui est.. une demande d'affichage du curseur.

Euh ça ne rend la main au basic que quand toute l'animation est finie, et en plus de mon côté ça ne rend pas la main puisque les banque RAM 2 et 3 sont effacées... En fait, j'avais écrit un code précédent plus simple dans lequel le changement de valeur de timer fonctionnait. Il faut que je vois ce qui a changé entre les 2.

Citation:
Ensuite:
Code:
 LDA >REGSY1 Activation Mode Page..
 ORA #16 ...pour Banques RAM
 STA >REGSY1
lit $E7E7 qui ne contient pas la même chose qu'en écriture (on dit qu'en fait il est en écriture seule). La bonne façon de faire est:
Code:
 LDA >$6081 Activation Mode Page..
 ORA #16 ...pour Banques RAM
 STA >REGSY1
 STA >$6081


Ben de ce côté là; mon code fonctionne parfaitement. Je n'ai jamais vu un quelconque système informatique dans lequel ce qui est accessible en écriture ne peut être accessible en lecture (notamment les fs linux) J'ai répondu à Daniel de ce côté là. En plus 6081 est documenté comme étant un "buffer clavier". Bizarre non ?

Citation:

Enfin à la fin de ton interruption tu fais:
Code:
 LDA >DPINIT
 TFR A,DP
 JMP KBIN Contient un RTS
ce qui est doublement curieux. D'une part tu mets dans le DP de retour d'interruption la valeur de DP à l'entrée de ton programme principal. Or quand l'interruption se produit le DP peut être différent de celui à l'entrée du MAIN (le moniteur l'utilise en interne), et donc tu écraserait celui qu'il y avait au moment où l'interruption est arrivée. Ca peut poser des bugs.... sauf que non en fait, car KBIN se termine par un RTI (et pas un RTS), qui a la propriété --IRQ oblige-- de restaurer tous les registres CPU, DP y compris. Donc pas besoin de remettre la valeur supposée qui en fait n'est pas la bonne. C'est une opération totalement inutile (et dangereuse car le DP au moment de l'interruption n'est pas forcément celui que tu avais dans le MAIN).

Eh non en fait!! Et c'était sur ton conseil que j'avais fait ça d'ailleur!! Tu lm'avais conseillé de changer le DP non pas dans le prog principal mais dans la routine du timer... Ce que j'ai fait d'ailleurs (en début de routine je l'initialise à $72 pour coller au DPINIT de l'affichage du sprite). Et puisqu'en foin de routine je 'nai plus besoin que le DP soit à $72, je ne réinitialise avec la valeur qu'il avait avant l'appel à la routine timer avant le JMP, ça ne change rien à ce qui se passe après.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 29 Oct 2020, 12:50 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 681
Localisation: Provence (France)
Neotenien a écrit:
Ben de ce côté là; mon code fonctionne parfaitement. Je n'ai jamais vu un quelconque système informatique dans lequel ce qui est accessible en écriture ne peut être accessible en lecture (notamment les fs linux) J'ai répondu à Daniel de ce côté là. En plus 6081 est documenté comme étant un "buffer clavier". Bizarre non ?

Tu n'as toujours pas compris. Fais un effort, relis ce que __sam__ a écrit, relis ce que j'ai écrit sur le registre $E7E7 et les variables système, relis le manuel technique. Il est impossible de relire ce qui a été écrit en $E7E7. Les variables système sont utilisées différemment selon la ROM de l'ordinateur et pour une même ROM la même variable peut avoir plusieurs utilisations différentes.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 29 Oct 2020, 13:12 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
La partie moniteur de la doc vient essentiellement du TO9. Sur TO8 c'est différent (parfois on trouve des addendum comme dans le manuel de l'ASM, mais pas toujours). C'est pas parce que "ca marche" que c'est pas buggé. C'est juste une coïncidence. Si ca se trouve le jours où tu mets un disk externe ou débranche le light-pen "ca marche plus". Comme indiqué plus haut ce registre est en écriture. En lecture on a tout autre chose. Il n'y a pas d'écriture. Un registre d'IO n'est *pas* une mémoire. Ce qu'on y lit n'est pas forcément ce qu'on y a écrit. C'est le cas pour $E7E7. J'ai déjà écrit tout ca plus haut.

Sinon pour le timer et les autres trucs dont le BM16 j'ai expliqué au dessus. Je me demande si tu lis bien attentivement les infos qu'on te donne.


Ok admettons...

Daniel, pour ce qui est de E7E7, la lecture en crayon optique ne se fait QUE pour D0 de E7E4 à 1. Sinon apparemment il n'y a pas de lecture... Comme si les données de E7E7 étaient supprimé ? Et les ROM des différentes machines sont quasi les même à part des changement d'allocation mémoire avec le digit de poid fort entre les TO et MO (c'est d'ailleurs à ça que peuvent servir les equates d'une machine à l'autre)

Vous ne me donnez pas d'explication claire sur cet état de fait (comment un registre auquel on attribut une valeur peut-il changer ?), je réfléchis et je me dis que c'est sans doute dû à un code qui passe dessus au niveau d'un certain cycle d'horloge (quand ??) et efface son contenu tout en transférant les données utiles (dont le b5 de gestion de RAM données) ailleurs... Mais bon je ne vois pas comment E7E7 peut changer entre le moment où on écrit dessus et à la lecture suivante, si on ne fait appel à aucune procédure utilisateur qui le change... Ca signifie qu'il y a quelque chose qui se passe entre temps avec mais comment ? Il ne me semble pas qu'il y ait de procédures en parallèle qui tourne... Ca me parait vraiment étrange.

Mouai je comprend mieux maintenant pourquoi ya eu un arrêt du dév sur les TO8 avec des documentations "pas complètes"... On est loin du site de PHP.net sur toutes les fonctions existante sur le langage... Mais bon on n'est pas à la même période non plus.

Alors l'explication sur le fait que $6081 soit indiqué comme "buffer clavier" et qu'ici il serve à lire partiellement ce qui est en E7E7 ?

Eh si je lis tout ce que vous écrivez.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 29 Oct 2020, 13:34 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
holà, si je puis me permettre, y'a trop de problématiques en même temps là ...
je pense qu'il faut re-découper les différents soucis ...

c'est quoi la problématique ? le double buffering ? ou l'histoire de E7E7 ? ou le swap écran ?

1 - ne pas essayer de lire E7E7, (cherche pas pour quoi pour le moment)
au pire fait des trucs du genre TST $E7E7

2 - "Pour le passage en mode bm16 pour TOUS les écran (bank 0 à 3)"
- c'est peut être une façon de parler, mais pour infos tu passe pas les banks en mode 16 ou autre !!
- c'est juste le comportement de l'affichage qui agis d'une certaine façon.
- ps : meme si tu passe pas en mode bm16, et que avant ton exec passe en mode 80 col ( console,,,,1 )
ton programme dois bien s'executer, mais tu verra juste tes sprites comme ça.
Image

3 - attention que ça tourne pas à la castagne SVP, ;) , surtout qu'on capte pas le ton des messages écrit :tourne: :coucou: :bien:

4 - faut reprendre les problématiques 1 par 1 chronologiquement de ce que le programme est sensé faire.

5 - pour l'histoire de E7E7 ici c'est expliqué http://pulkomandy.tk/wiki/doku.php?id=d ... ate.arrays
c'est la machine qui utilise ce registre, bit par bit pour fonctionner, c'est à toi en fonction de t'est besoin de configurer l'état des bits auxquelles ta le droit de toucher !

Sûr pas evident de comprendre, je me suis bien cassé la tête pendant un certain temp pour comprendre, je pense que pour bien s'en sortir il faut bien comprendre comment l'ordi et ces différents chips sont utilisés par le TO8...

bon je sais pas si je me suis bien exprimé lol, c'est sûr que j'ai pas le vocabulaire aussi technique que Daniel ou Sam...

:jap:

_________________
Image


Dernière édition par adnz le 29 Oct 2020, 13:57, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 29 Oct 2020, 13:54 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Citation:
(comment un registre auquel on attribut une valeur peut-il changer ?)

C'est un registre matériel, pas une mémoire, en particulier pas un registre (interne) de processeur. Ce truc là t'expose des états internes du chip en lecture, et inversement lance des opérations via une écriture. Pleins de trucs matériels sont comme ca et retourne autre chose que ce qu'on a écrit. Regardes les "registres" palette: ils changent à chaque lecture, alors que tu n'a rien écris dedans, idem le registre d'un ACIA qui contient le caractère reçu par voie série alors qu'on a rien écrit dedans, idem le registre LATCH du timer qui contient la valeur qu'on à écrite sauf si on stoppe le timer auquel cas il présente la valeur présente du compteur, etc, etc. $E7E7 ne fait pas exception. C'est clairement indiqué "en écriture" pour la partie commutation des RAM, donc si ca marche quand tu lis, c'est du pur bol, peut-être même lié à l'implémentation (limité) de l'émulateur.

Sinon pour les docs: ils faut se méfier, beaucoup, en particulier celles écrites à la machine à écrire par une secrétaire (doc moniteur de l'assembleur typiquement) contient des erreurs de saisie dans les parties hyper spécialisées, qui ont été mal relues (trop spécialisées), et donc jamais corrigée. En cas de toute il faut trouver d'autres sources que cette doc (ou une doc qui en dérive), ou même mettre un point d'arrêt dans le code pour essayer de comprendre la logique des choses.

adnz: bien vu le coup du console,,,,1. Moi j'aime bien, les sprites y sont plus clairs et on peut faire des PUTC de débug qui sont bien visibles contrairement au BM16 dans lequel PUTC ne sait pas afficher les caractères (contrairement à Amstrad).

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 29 Oct 2020, 13:59, édité 2 fois.

Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 36 messages ]  Aller à la page Précédente  1, 2, 3  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 42 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com