bugs

#NB : Ne pas effacer les bugs corrigés de la page. Indiquer simplement la date de correction.

Table des matières

#B0 [Editor/Fred] Tout s'imprime sur la même ligne.

From Gotcha38:
"""
J'essaie d'imprimer le code depuis Orgams et tout s’imprime sur la même ligne.
J'ai essayé avec 2 imprimantes et j'ai le même résultat. Depuis le Basic, ça marche bien, j'ai des retours à la ligne.
"""

NB Madram: il doit simplement manquer l'envoi CR/LF (chr$ 10 et 13).
Edit: Il y avait déjà le 0x0D mais il manquait le 0x0A. (comme j'ai testé sur sur l'émulation d'imprimante winape et que j'éditais le fichier avec un notepad++ qui ajoutait de lui même le 0x0A ; c'est passé inaperçu)
Merci à ceux qui possède une vrai imprimante de vérifier que tout fonctionne correctement (Gotcha38 ?). Merci

#AF [Assembler Internal] (benign) fix_error_lines corrupts error type when source pnt is wrong.

Since #AE is fixed, this doesn't show up anymore is real-life use.

Copains: #15 et #2E

XXX #AE [Assembler] Label overflow leads to 'syntax error' with wrong line number.

Fixed in ass1i 11/11/2017. Source pnt wasn't restored in time.

To reproduce:

ld a,12345*12345

Copains: #15 et #2E

#AD [Assembler] Unknown label for 'IF' in macro invocation: assembler assert failure

(obviously absent in Codigo public version)

To reproduce:

    MACRO FINALIZE x,u
    IF u
    END
    END M

         FINALIZE 0,unknown

Then, CONTROL-1 raises breakpoint @ &f02e.

#AC [Editor/Madram] CTRL-ENTER doesn't work for macro.

It should move from invocation to definition.

#AB [Trace/Visu] Wrong line number inside macro expension

If code being traced is generated from a macro expension, the detected line (source position) is wrong.
It should point to the macro definition (or at least to the macro invocation).

#AA [Codec] Export+Import != Identify for nullary macros.

To distinguish a macro with no parameters from a label, you can either use:

:MA_MACRO
MA_MACRO()

Recognized as a macro invocation, it is properly indented, but without any other distinctive sign:
         MA_MACRO

So, if exported and re-imported, it will be seen as a mere label again:

MA_MACRO
  • Solution 1: Leave parenthesis to resolve ambiguity : MA_MACRO()
  • Solution 2: Check if MA_MACRO is defined as a macro. Complicated, imply that an entered line depends on what is defined/included before. Not very robust, also. This is the behavior chosen by winape/rams
    • this is consistent: interpretation doesn't depend on indentation/whitespace
    • this is inconsistent: same formatting can be used for label definition
    • this is easier for them since the interpretation is done at assembly-time, whereas Orgams does it at editing-time.
  • Solution 3 (preferred): Interpret 'space+label' as a macro invocation (a slight change from current behavior). E.g.:
label   ; seen as label
 label  ; seen as macro invocation
 label inc a ; seen as label + opcode

NB: it might also happen with 1 parameter :

:MA_MACRO color1   ; text entered
          MA_MACRO color1 ; correct interpretation
; the previous line exported and re-imported will be interpreted like that:
MA_MACRO color1    ; label + macro invocation with 0 parameter.

#A9 [Assembler] Overlapping output should raise error.

If the same zone is written twice by a given source (due to multiple ORG directives), the coder should be notified, à la rasm.
Same rational than #A8.

#A8 [Assembler] Two ENT directives should raise error.

If more than one ENT directive is met (not counting disabled ones in conditional blocs), an error should be raised.

Rational: everything must be done to help coders detecting potential issues, copy/paste errors, etc…

Copain du bug #A1

#A7 |Editor/Fred] Join shouldn't re-interpret line

Actuellement, quand on recolle deux lignes (DEL en position X=1), la ligne reconstruite se voit systématiquement insérée dans le source, avant même d'être validée (*). Ce n'est pas satisfaisant, pour deux raisons :

  • A cause du bug #A6, c'est assez lent, car faute de séparateur (":"), la ligne reconstruite est rarement valide.
  • La position du curseur n'est plus forcément cohérente. Pour reproduire :
ld (hl),
7

Puis on recolle les lignes (curseur en '7' puis DEL) : le curseur se retrouve avant l'instruction re-interprétée ld (hl),7.
En fait, on peut laisser le org_set_line. Le problème (1) demeure, mais il doit être de toute façon résolu par #A6.
En revanche, il ne faut pas relancer un org_get_line, mais laisser le buffer tel quel.

(*) Je crois que j'avais demandé ce comportement pour assurer qu'il y avait assez de mémoire pour la ligne créée avant d'effacer la ligne suivante. Mais OSEF, le cas est suffisamment rare (je ne l'ai jamais atteint, la table de labels est typiquement remplie avant).

#A6 [Editor/Parser] Parsing too slow

With recent features and all smart interpretations, entering a line may be sluggish, especially in case of syntax error.

XXX #A5 [Monogams] Comparaison doesn't report first mismatch

  • Fixed 3/8/2017 monO3. The perils of using 0000 as Null, when it's also a valid address.

To reproduce (with &bb00 not being zeroed)

>x0,&bb00

We get &0008 blahblah instead of &0000 bluhbluh

#A4 [Trace] When entering trace screen, navigation history shouldn't be reset.

The '->' / '<-' history shouldn't be lost.
Rational:

  • when returning to trace after Monogams/Editor/BASIC switch, we should be in the same state.

XXX #A3 [Trace] Shaded opcode shouldn't reflect current state

Fix 30/7/2017 In mono1.

Since shaded opcodes represent the history of what has been executed so far, they shouldn't the very last memory state.
That's already the case the all the lines but the last (*) (since these ones are simply scrolled, whereas the last line must be re-displayed shaded).

To reproduce:

      xor a
   BRK
      t  ld (t),a

After 's', we should still see ld (&9001),a

Related: todo #8B

(*) Wrong when the whole screen is refreshed (after 'N' or even coming back from help screen). So we must keep a history anyway.

XXX #A2 [Editeur/Fred] Problème affichage marqueurs bloc.

Fixed in ED-BD/ED-BE 09/2017 at Drill's.

Resucée du bug #86. Ca plantouille encore dans certains cas.

  • déborde sur écran
  • si on sélectionne un bloc de 2 lignes et qu'on efface la première, le bloc disparaît.
  • si on sélectionne un bloc de n lignes et qu'on efface une ligne à l'intérieur du bloc, le marqueur de fin de bloc ne remonte pas (il est bien modifié en interne, c'est bien un problème d'affichage).

Je propose de supprimer le code 'remplissage fenêtre', exemple d'optimisation prématurée.

Notons qu'il y a deux types de rafraîchissement à prendre en compte:

  1. Quand les lignes elle-mêmes bougent (passage à une autre page, insertion de ligne, suppression de ligne). Dans ce premier cas, il faut systématiquement rafraîchir la gouttière bloc (ON ou OFF) avec la ligne en cours d'affichage. C'est beaucoup plus propre.
  2. Quand on modifie la portée du bloc (COPY-S, COPY-E, COPY-Z). Dans ce cas, il n'y a que la gouttière à rafraîchir. Mais on peut le faire d'une façon très rustique, en itérant sur chaque ligne.

Les deux cas se contentent d'une routine très simple :

refreshBlocMarker
;In: DE: source line (1 à 65535)
;     L: screen line (1 à 23)
;Out: Set marker if DE is inside bloc, clear it otherwise
  [...]

;elle même utilisant une routine encore plus simple
isInBloc
;In: DE: source line (1 à 65535)
;Out: Carry if DE is inside bloc, NC otherwise.

Avantage collatéral: si on décide de changer l'aspect graphique du marqueur bloc, il n'y a plus qu'une seule routine à modifier !

Dernier point: insérer/effacer une ligne avant ou pendant ou bloc est censé déclencher les deux types de rafraîchissements (puisque les lignes et les marqueurs bougent). Mais le premier suffira, ce qui simplifie encore le code.

Morale: enlever du code corrige beaucoup de bugs d'un coup !

#A1 [Assembler] Entry point must default to ORG address

When we omit ENT directive, CTRL-2 (or CTRL-1 + J) jumps at &9000, whatever the ORG address is. That's plain wrong.
Not only Targhan got bitten by this

XXX #A0 [Trace/Madram] RES n,(hl) updates A instead of (hl)

Fixed 24/07/2017. TRQ. Actually both A and (HL) were modified. Idem for SET.

Reproduced in step by step mode.

#9F [Editor/Fred] 'Label table full' error not shown anymore.

Happens with lots of longs labels (like the assembler itself with 700+ labels).

Actually it is shown, but overwritten by status line.
TODO: in case of error when entering a line, display it and do not refresh status line.

XXX #9E [Trace] Buffer overflow when source line too long.

Solved in monMW (25/7) by using buffer at &4000. NB: not tested for lines >255 chars, though.

Source lines may overrun 73 chars (when from imported files). In such lines are displayed while debugging, some internals variables are overwritten, leading to display bugs, or worse.

#9D [Main/Madram] Crash when returning to Basic.

  • Resucée #53 ?
  • Only at first Orgams invocation ? Happened whitout even assembling anything (but loading a source).

XXX #9C [Monitor/Madram] [internal] Too-much copied from zone 00-3F when dumping this area.

08/6/17: Fixed in mirror7

  • Not present in public release
  • Not really noticeable in working versions.

#9B [Editor/Orgams] Mnemonic treated as label

Singe word mnemonics (like ‘di`) without space are treated as label. That’s a wrong behavior:

  • inconsistent with other mnemonics.
  • could lead to hard to spot bugs when importing non-formatted sources.
  • nobody should use mnemonics as labels anyway.

Other Exemple:

call org7   ; interpreted as:
call   ORG 7   ; too smart for your own good.

XXX #9A [Editeur/Fred] Cursor lost after reset

corrigé dans ED-BD le 12/09/2017

If we reset while cursor is positioned at status line (e.g. when entering a filename), the cursor behaves erratically at subsequent Orgams invocation.

NB: the proper way to fix that is to tackle TODO #6A and/or TODO #4F, so that POS_CURSOR variable isn't used anymore for status line edition.

XXX #99 [Monogams/Madram] Corruption mémoire !!

Corrigé le 12/01/2017 dans Mirror6. La corruption se produisait avant chaque assemblage, car la mémoire 'utilisateur' n'était pas proprement copiée.

Nb: bug non présent dans version publique.

Quand on passe de la trace au moniteur, on se retrouve avec des buffers Orgams en 8800, 88A0 …
Argll…

#98 [Editeur/Madram] Message d'erreur incongru pour première ligne.

Pour reproduire, source vide (CONTROL-N ou |orgams), saisir "toto" + RETURN.
Un "Cannot open file" s'affiche dans la ligne de status.

Raison :

  • L'éditeur change la ligne 1 (setLine), qui n'existe pas encore.
  • Le setLine renvoie un flag d'erreur, avec un code d'erreur bidon.

La curiosité, c'est que ce cas de figure est géré de longue date (setLine utilisable en lieu et place d'insertLine pour la post-dernière ligne), il y a même un test unitaire dédié qui ne rencontre aucun problème.
Alors, pourquoi ?

XXX #97 [Trace/Madram] CPD, CPIR, CPDR mal émulés.

25/11 : Corrigé. Erreur copié-collé pour CPD, erreur PE vs PO pour CPIR/CPDR.

Détecté par Candy ! Les instructions ne se comportent pas du tout comme attendu.

#96 [Editeur/Fred] Problème dans la recherche de label CTRL+L

Il est fréquent qu'un label antérieur à la ligne courante du pointeur ne soit pas trouvé. Exemple : CTRL+. pour aller à la fin du source, puis CTRL+L, entrer un label du début du source : sans effet, alors que le label est bien là. Arrivez-vous à reproduire ?

NdMadram: Bug connu et systématique si et seulement si on est sur la dernière ligne. Dans tous les autres cas, le label doit être trouvé (bug non reproductible chez moi).

XXX #95 [Editeur/Fred] Fin de ligne non effacé avec CTRL-P.

Cela se produit quand on colle une ligne plus courte que celle en bas d'écran (ligne 23).

#94 [Assembleur] Code assemblé écrasé par gestion Jump.

On peut assembler en zone firmware &AC00-&BFFF. Mais ce code sera écrasé par l'utilisation de la pile lors de l'exécution.
Actions :

  • Permettre de reloger la pile avant même l'exécution (mnémonique STACK …)
  • A défaut, prévenir du conflit.

#93 [Assembleur] Code assemblé écrasé par breakpoint.

Lors de l'assemblage, Orgams ré-installe le breakpoint (routine en &BE00 et raccourci en &30).
Mais quand on assemble en &30 ou en &be00, ceci devrait être désactivé.

#92 [Editeur/Madram] Export bloc corrompu

Dans certains cas rares, l'export écrit de la merdasse.

NDMadraM: il se trouve que l'export écrivait exactement ce qu'il fallait. Seulement, une malencontreuse coïncidence faisait que les données "ASCII" enregistrées étaient vues comme un header par l'amsdos (checksum tombant juste par hasard), d'où une interprétation erronée.

A voir : ajouter un header pour lever ambiguité. Pb potentiels :

  • est-ce compatible avec mode 'ascii'
  • quid des fichiers > 64k ?

XXX #91 [Assembleur] FILL -1,0 provoque plantage

Corrigé le 5/8/16 dans assz2.o : On lève erreur si valeur négative.

Détecté par Hicks !
Double problème : les valeurs négatives n'étaient pas écartées, et bug #63.

#90 [Orgams/Madram] |O,"file" ne marche pas quand HIMEM en &4000-&7FFF

Il faut faire une copie trans-bank.

XXX #8F [Editeur/Fred] Dernier numéro de ligne non effacé.

Pour reproduire :

  • Charger dumprom
  • Scroller de sorte que la ligne 54 soit la dernière affichée
  • Remonter en ligne 36
  • CONTROL-BAS
  • -> Le '54' est toujours là.

Fred: Je l'avais déjà corrigé ça y a un moment…Un merge foireux ? C'est en réalité un bug qui date de la toute première version. Un cas particulier.

XXX #8E [Editeur/Fred] Problème correction marqueurs bloc.

Si on copie un bloc juste sous lui, la taille double à tort.
E.g. : sélection bloc lignes 1 à 2, copie en 3 : le bloc s'arrête maintenant à 4, alors qu'il ne devrait pas bouger.
De façon générale, insérer une ligne en N ne devrait toucher aucun marqueur < N.
Cf TODO #18.

XXX #8D [Assembleur] Répétitions avec label inconnu ne renvoie pas d'erreur.

Corrigé le 5/8/16 dans assz2.o: l'erreur est levée phase 1 (de façon interne, le nombre de répétitions est alors forcé à 0, pour éviter de continuer l'assemblage avec un nombre arbritaire).

Pour reproduire :

   mouff ** BYTE &AA

Cela répète &AA un nombre arbitraire de fois quand mouff n'est pas défini.
Comme ça peut être très long (~20secondes), on a l'impression que l'assemblage plante.

XXX #8C [Editeur/Fred] Problème affichage lors jointure lignes.

Quand on joint deux lignes (DEL en colonne 1), toutes les lignes suivantes sont décalées, il est donc normal de les ré-afficher.
Mais bizarrement, on observe aussi qu'une ligne précédente est rafraîchie, laissant une impression étrange.
Dans certains cas, la barre de status se voient d'ailleurs écrasée.

Pour reproduire, charger dumprom.o (il doit être sur une des dernières betas).
Aller en ligne 26, col 1. DEL (on joint 25 & 26) : la ligne 24 clignote !
Si la première ligne de l'écran est la ligne 25 du source, c'est la barre de statut qui prend un coup.

Autre petite bizarrerie : la ligne concaténée 25+26 est affichée en 26 avant d'être placée à sa destination finale. Ca n'a aucune raison d'être !

XXX #8B [Editeur/Fred] Problème affichage marqueurs bloc.

Quelquefois la colonne de marquage bloc déborde.
Notamment quand on change un marqueur début ou fin à cheval sur un multiple de 256 (sûrement un problème de INC E à la place de INC DE ou truc dans le genre).
Tu pourrais en profiter pour faire le correctif suivant :

  • N'utiliser l'affichage de fenêtre pour afficher/enlever les marqueurs uniquement lors de COPY-S, COPY-E, COPY-Z.
  • Dans tous les autres cas (scrolling, refresh, insertion/délétion ligne…) afficher le marqueur à la volée, ligne par ligne.

Raisons :

  • Le code serait alors plus simple (il suffit de tester si le numéro courant est compris entre début et fin).
  • Aussi rapide.
  • Plus harmonieux visuellement (pas de décalage).
  • Cela facilitera les prochaines évolutions concernant l'affichage.

#8A [Orgams] 'BRK' plante avant première invocation Orgams.

Si on saute en &30 ou &BE00 avant la première utilisation d'Orgams, ça crashe.

#89 [Orgams] Buffer clavier non nettoyé pour sauvegarde binaire

Le 'B' saisi pour accéder à la sauvegarde du binaire se retrouve en tant que nom de fichier.

XXX #88 [Editeur/Madram] Recherche 'org' ne donne rien quand précédé d'un espace.

Corrigé 26/05/2016 dans ED-AVN. Les opcodes/directives en début de ligne (sans label avant) étaient écartées dans ce cas de figure.

Rechercher ' org' (avec un espace) permet de filtrer les labels qui contiennent org (borg, bjorg, korg, …)
Mais ça filtre aussi 'ORG' lui-même.

XXX #87 [Parser] LD H,IXH plante

Résolu 18 Avr 2016 (parseI) : "LD H,H" doit être échappé (car l'opcode correspondant &64 sert comme pseudo-instruction). Ce n'était pas fait après un préfix &DD ou &FD.

Alors que ld l,ixh est bien transformé en ld ixl,ixh (comportement attendu)

XXX #86 [Editeur/Fred] Réaffichage indésiré quand delete block.

Depuis quelques temps, j'observe que lors de la suppression d'un bloc (COPY-DEL), il y a un réaffichage pour chaque ligne supprimé.
C'est pertubant, et ça rend la suppression plus longue que souhaité.
Pour reproduire :

CTRL-O : dumprom
CTRL-0
COPY-S
CTRL-.
COPY-E
; on a donc sélectionné tout le fichier, et on retrouve avec la ligne 75 en haut d'écran;
COPY-DEL  + confirm
; on voit les lignes défiler en haut d'écran
; BUG bonus : en se retrouve ensuite en ligne 65535 !! Cas particulier quand on efface tout.

#85 [AsT] Erreur pour lecteur Hxc/Gotek

Pour une raison que j'ignore, la dernière rom plante la rom hxc et le programme Disc.

Edit : Pour une compréhension optimale : HxC Floppy Emulator Manager V3 de NoRecess plante quand la dernière version d'Orgams est installée. Il est donc impossible de mounter les fichiers HxC, un peu merdique quand même…

__ ND Madram __

  • Par dernière ROM tu veux dire dernière version de la ROM ?
  • Tu parles de la rom de NoRecess ? Quelle version ?
  • Comment ce manifeste le plantage ?
  • Quel est ce programme Disc ?

Merci !

#84 [Trace/AsT] Erreur valeur de la pile

Erreur de valeur de sp
Pour reproduire :
on entre le code suivant :

org &1000
di
LD Sp,&2000
ei
ret ; -> on trace le code puis Reset (commande d#1000 pour désassembler puis s pour tracer pas à pas)

Ensuite après le reset lancer OrgAms avec ùo ou ùorgams puis entrer le code suivant

org &1000
di
LD (pile+1),sp
pile ld sp,0
ei
ret -> on trace le code puis Reset (commande d#1000 pour désassembler puis s pour tracer pas à pas)

A ce moment là, sp prends la valeur de l'ancienne pile avant le Reset, mais pas la bonne valeur. Orgams conserve la valeur donnée à un registre avant un reset et ne réinitialise pas cette valeur.

Edit : J'ai remarqué en regardant de plus près que les valeurs de registres au départ sont toutes à zéro (hl, de, bc, sp…)
Il suffit à mon avis d'attribuer les bonnes valeurs de départ à ces registres, valeurs qui devront être celles à l'allumage du cpc.

__ ND Madram __
Bien vu, il faudrait remettre la pile à une valeur saine, pour être cohérent avec ce qui est fait lors d'un CONTROL-2.
Il faudrait faire cela à chaque assemblage, pour la même raison. (Le faire lors d'un |O ou |M empêcherait de basculer au basic et de rependre ensuite une session de débuggage). Cousin éloigné : bug #6F

XXX #83 [Editeur] Dernier numéro ligne non effacé.

Dans un source de moins d'un écran, un del à la dernière ligne et en début de ligne ne supprime pas le dernier numéro de ligne.

#82 [Monogams] Wrong system mode for CAT.

Spotted by AST :

MODE 1:|ORGAMS
CONTROL-C

L'affichage se base sur le mode 1.
TODO : If MC_SET_MODE (BD1C) is not enough, call BC0E in common RSX init.

XXX #81 [Editor] Grandes lignes tronquées.

Quand on joint 2 lignes (avec DEL), la ligne résultante peut dépasser 72 caractères. Si on presse RETURN pour re-séparer les lignes, la deuxième se voit alors tronquée.

XXX #80 [Editor] Conflict between "modified lines" vs "CONTROL-ENTER history"

Corrigé le 26/10/2015. ed-apm : la copie des "modified lines" débordait.

Modifier une ligne dans une nouvelle zone corrompt la dernière adresse mémorisée par CONTROL-ENTER.
Pour reproduire : lancer NRT !

#7F [Trace/Madram] Get_line_from_pc for source visu still not fast enough.

Surtout quand la recherche échoue.

XXX #7E [Orgams] Stack goes down.

Corrigé 12/9/2015. Ch1f + Monjo : don't use rsx |o to goto ed.

Stack goes lower and lower at each assemble+jump or Editor/Monitor switch.
It could explain bug #68

To reproduce :

Select work bank (e.g. b&FF).
m&7cde  show the current SP
ESC + ESC  (variante : enter RET and press CONTROL-F2 some times)
m show SP has fallen.

XXX #7D [Orgams] Sauvegarde binaire fausse la zone #9800-#BFFF

Corrigé 10/09/2015 CH1F, TRN. (Il fallait lire dans la zone "backup").

Un cousin du bug #62

Pour reproduire :

 org &9780
 256 ** BYTE #

Puis CONTROL-F1 + B.
Sur les &100 octets, seuls les premiers &80 seront correctes

XXX #7C [Editeur] 22 lignes = 23 lignes

Si le source ne contient que 22 lignes à l'enregistrement alors il est affiché 23 lignes (au chargement) à gauche alors que le nombre total de ligne, lui, est correcte.

XXX #7B [Assembleur] -1 and &ff00 renvoie 0.

Résolu 08 Jan 2016 (AssY). Egalement ok pour OR and XOR.

Cela devrait renvoyer &ff00 : le signe n'est pas propagé sur 16 bits.

XXX #7A [Monogams/Madram] Firmware invisible en première instance.

Résolu 13 Aug 2016 (Ch1h+Mirror). On backup le firmware lors des RSX, et plus seulement avant chaque assemblage.

Quand rien n'a été assemblé, un dump en 0 ou zone firmware (en fait #9800-#BFFF) ne montre pas l'état actuel de la RAM.

XXX #79 [Assembleur] Signe perdu dans -1/[1/1] ou -1 mod [4 mod 5]

Résolu 26/08/2015 dans ASSW. Quel boulet, je stockais le signe dans une variable évidement écrasée par la dernière sous-expression. Tout ça parce que la sauvegarde en pile était moins pratique !

Les expressions du style x/[y/z] ou x mod [y mod z] renvoient le signe de la dernière sous-expression plutôt que celui de l'expression complète. Argl.

XXX #78 [Trace/Hicks] Marqueur $ de fin de ligne résiduel.

Ce marqueur n'est pas proprement effacé lors d'un scroll.

XXX #77 [Assembleur] Adresses (First PC et First Obj) incorrectes.

Résolu 12/08/15 dans ASSV
(bug non public, uniquement présent dans Cogido beta).

Cousin du bug #74.

Le problème se produisait avec code généré "à rebours" :

 org #9000
 byte 0,0
 org #8000
 byte 0,0

On doit obtenir First=#8000

XXX [Editeur/Fréd] Marqueurs bloc non corrigés après import.

Pour reproduire : sélectionner un bloc (eg lignes 10 à 13), importer un morceau de code avant la ligne 10.
Les marqueurs seront toujours en lignes 10 et 13, alors qu'ils devraient être décalés du nombre de lignes du code importé (renvoyé dans HL).

XXX #76 [Orgams] Répétition bloc foireuse quand source mord sur 2 banks.

Résolu dans ASSU 8/8/2015

Remonté par AST sur une certaine version de ImpDraw.
Impossible à reproduire simplement : le source doit dépasser 12k.
Le problème apparaît quand le bout de source correspondant au bloc est à cheval sur 2 bank :

  • lors du rembobinage, on reconnecte la bank contenant le début du bloc. Or, le buffer avec les bons opcodes déjà généré est dans la bank précédente (temporellement), celle contenant la fin du bloc.

XXX #75 [Orgams] Détection mémoire non robuste

Résolu dans Ch1E 21/8/2015 (on en profite pour s'installer en bank FF.

Actuellement, la détection est non intrusive (n'écrit pas en mémoire). Il s'agit donc un test "probabiliste" : on s'attend à ce que le contenu des banks soit distinct pour détecter si #C4/C5/C6/C7 diffèrent de #CC/CD/CE/CF, puis de #D4/D5/D6/D7 etc…

Ainsi, si les banks sont à 00 (future commande 'clear' du moniteur, et par défaut sur Winape), on obtient l’imbroglio suivant :
le test échoue dans un premier temps, et "installe" Orgams en #C7, comme peut en attester le message d'accueil. Puis, les banks étant utilisées, le test va plus loin, et détecte plus de mémoire ! La bank de base se retrouve en #DF.

Cette double instanciation explique les bugs estampillés Winape remontés par AST :

  • ùorgams n'efface pas le source comme il devrait
  • après reset, ùo lance l'éditeur avec un source qui semble effacé, mais on le récupère après ESC*2.
  • MEMORY FULL quand on charge un source

XXX #74 [Assembleur] Adresses (First/Exec/Last & binary save) incorrectes.

EDIT : correction supplémentaire le 12/08/15 (
Corrigé le 15/07/15 (ASSU, et CH1B)
(NB: C'est un bug Codigo, non présent dans précédente version publique)

Pour reproduire :

 ORG &4000
 FILL 3,&C9

XXX #73 [Trace/Hicks] Visu : Ligne non effacée après scroll.

Pour reproduire :

 BRK
   XOR A
riri
  RET

Après CONTROL-F2, flèche bas ou 'S' laisse un RET en double.

XXX #72 [Editeur/Madram] Recherche 44 pointe les 4.

Résolu 11 Jan 2016 (Ed-ATM).

CTRL-F + 44 : Le recherche s'arrête sur les occurrences de 4 finaux (eg LD A,14).
Elle est décidément moisie cette fonction de recherche !
Ca doit être une autre manifestation du bug #50 : une fois la fin de ligne atteinte je ne dois pas vérifier que le motif de recherche est bien épuisé.

XXX #71 [Parser] 'ld b,(ix)' corrompt le source.

Résolu 18 Avr 2016 (ASSz et DISAp). Expression de longueur 0 (abscence d'expression) correctement gérée.

Avec possible plantage. Nous voilà beaux.

XXX #70 [Trace/Hicks] Nettoyage incomplet après retour trace rapide. (From AST)

Après retour trace rapide (T/Space), il faudrait rafraîchir l'écran.
Pour reproduire :

   BRK
     DJNZ $
     XOR A

Après quelques 'S', on se place sur XOR A puis on presse 'espace' : les tirets sont toujours là.

Plus flagrant :

   BRK
      LD A,2:CALL #BC0E
      XOR A

Celui-là pose aussi problème si on passe le 'CALL' avec 'N'.

XXX #6F [Trace/Madram] Rom basse sélectionnée par défaut.

Résolu dans CH1E 21/08/2015 : RAM basse et haute sélectionné par défaut.

Lors d'un BRK, la ROM basse est souvent connectée à tort, ce qui se révèle perturbant.

Dans l'idéal, il faudrait auto-détecter la connexion ROM.
En attendant, choisir par défaut RAM basse et RAM haute, car c'est ce qui correspondant à la connexion lors de l'exécution du source (CTRL-F2).

#6E [Trace/Madram] Remontée navigation (flèche HAUT) est trop lente.

Cela est dû au get_line qui rame quand code parcouru à rebours.

XXX #6D [Trace/Hicks] Le get_line pour source visu est appelé en double.

Corrigé le 20/7/2016 dans MonMM pour la release codigo.

Je n'ai pas sous les yeux le nom exact de la routine. Le double appel est superflu, et ralentit la trace.

XXX #6C [Trace/Hicks] Première colonne mangée dans source visu.

Résolu dans MONJ.

XXX #6B [Assembleur] CRITIQUE Orgams ne sait pas diviser !

22-05-2015 : Corrigé dans ASSS.O (problème quand MSB diviseur = 1)

Eg : 15*&c0/&c0 ne redonne pas 15 (la multiplication est ok).

Pour mesurer l'étendue du désastre :

   256 ** BYTE #*&C0/&C0

XXX #6A [Editeur/Madram] org &100 mal interprété

22-05-2015 : Corrigé dans PARSEG.O (pseudo-mnémoniques maintenant interprétées avant OR & co).

Vu comme or g AND 100

XXX #69 [Editeur/Madram] TAB ne reprend pas le bon label (CTRL-*)

18/08/2016 Corrigé (ED-AZN + ORG1E).

    jr lab1
    jr oups
lab1
oups

Avec la séquence suivante :
  • CTRL-f0 (goto line 1)
  • CTRL-* (line 3)
  • Flèche haut (line 2)
  • TAB devrait ramener en line 1 (poursuite de la recherche sur lab1 en repartant de line 3 + 1).

Or, on se retrouve en ligne 4.

Il faudrait que la routine CTRL-* soit splitée en 2 : renvoie de l'id label de la ligne courante, puis recherche de cet id à partir d'une ligne arbitraire. Seule la deuxime partie serait rappelée.

XXX #68 [Editeur/Madram] Sauvegarde peut crasher.

Fermé le 12/06/2016 : je ne rencontre plus le problème, qui a dû être résolu en même temps que #7E.

Je n'arrive pas à reproduire systématiquement, m'est arrivé avec un source de 40k, sans erreur disque notable (eg : disc full).
Circonstance aggravante : le crash corrompt la bank de base. Les labels peuvent être touchées, mais il ne sont pas encore vérifiés par checksum.

XXX #67 [Assembler] Problème dans répétitions blocs.

Jamais réussi à reproduire, mais c'est certainement un avatar du bug #76.

Observé sur la release publique BBH par Candy :

  8 ** [
    LD A,(DE)
    OR A
    JR NZ,$+4
    ...
  ]

aboutissait à un doublement du LD A,(DE) pour chaque itération.
Problème : je n'arrive pas à reproduire. Le source enregistré puis rechargé produit le bon code.

#66 [Trace/Madram] Commande N perd la trace ?

La commande N est censée tracer rapidement un 'CALL pouet', et rendre la main au retour.
Mais la trace peut être perdue quand 'pouet' manipule trop la pile.
(Trouver un exemple !)

XXX #65 [Assembler] Double equ equals inconsistency.

Fixed 15/08/2017. ass15. + allow forward ref.

Pour reproduire :

nb = 6000000
nb = 70000

On obtient "Label inconsistency. Bug in Orgams"

  • C'est moins parlant que "Double definition".
  • C'est un paradoxe : ce n'est pas un bug. Du coup le message est buggué.

XXX #64 [Monogams/Madram] Activation du pavé numérique quand appel direct |m

Corrigé dans MONJO + ED-ANQ 03/09/2015

TODO : exposer SysConf de l'éditeur, et l'appeler dans le moniteur (dans la partie init 'firmware').

XXX #63 [Assembleur/Madram] Permettre assemblage en zone firmware.

03/09/2016 : Résolu dans Mirror4 (gestion propre du mirroir 00-3F. Sous-problèmes déportés en bug #93 & #94
03/02/2015 : BUG quasiment résolu, modulo :

  • Crash si assemblage dans la zone 00-3F
  • On peut écrire de A000 à FFFF, mais comme on utilise la pile (~#BFD6) pour installer la routine de jump, le code fraîchement assemblé à cet endroit sera corrompu sans sommation.

Ca ressemble à un TODO, mais classé comme bug car pour l'instant ça crash si on essaie.

XXX #62 [Orgams/MadraM] Retour basic trop abrasif.

Corrigé 10/09/2015. MONJO+TRN. (Il fallait piocher dans backup les octets 9800 à HIMEM).

La commande 'Basic' restore le système telle qu'avant exécution de la routine.
Le problème, c'est qu'on restore trop !

Pour reproduire :

 org #a000:ent $
 ld hl,t:ld (hl),#ff:ret

Après exécution, le moniteur montre le #FF attendu, mais ce dernier disparait au retour BASIC.

XXX #61 [Orgams/MadraM] Bug Export destructeur.

Corrigé 28/02/2015 dans CH17. Synchronisation avec ED-ABM pour BUF_LINE.
—-

Ce n'est pas systématique, mais on peut perdre le source après un export !
[NB : bug non présent dans version publique]

Pour reproduire :

  • Charger ED-ABN
  • Sélectionner de cleanName (inclus) à EXIT_LS (non inclus)
  • CTRL-E + B
  • Changer nom de fichier.
  • L'export s'effectue bien (vérifié a posteriori), mais au retour, la ligne statut est dans les choux, le curseur itoo.

XXX #60 [Editeur/MadraM] Recherche 'add (iy' infructueuse

Résolu 11 Jan 2016 (Ed-ATM). Mauvaise gestion séparateurs.

XXX #5F [Assembleur] ' RES robert,(iy+6)' provoque failure.

Corrigé 28/02/2015. L'erreur n'était pas traitée en tant qu'erreur d'assemblage.

A priori quand 'robert' n'est pas défini.

XXX #5E [Editeur/Frédéric] Portions de lignes ajoutées.

Corrigé le 02/03/2015 dans ED-AG.

Clairement dû au positionnement libre !
Pour reproduire :

  • ;abcdefg + RETURN
  • RETURN (crée ligne vide)
  • CTRL-f0
  • On se place sur la lettre d (par exemple)
  • Flèche bas
  • RETURN
  • "defg" est inséré.

La logique du RETURN étant de "splitter une ligne", il était normale de recopier la fin du buffer.
Mais là, on est sorti du buffer ! Il ne faut donc pas copier les résidus.

#5D [Assembleur] Cohérence 'IF' non vérifiée.

Pour reproduire :

  • IF 0 ; tout seul
  • A l'assemblage, aucune erreur indiquée.

XXX #5C [Editeur/Frédéric] Mauvaise correction de marqueurs blocs

Corrigé le 02/03/2015 dans ED-AG.

Pour reproduire : créer bloc lignes 2 à 5. Effacer ligne 2. Le début remonte en 1 au lieu de rester en 2.

XXX #5B [Editeur/Frédéric] DEL ne marche plus avec CONTROL-I

Corrigé 28/02/2015 dans ED-ABN. La cause : DEL_LS vérifiait si SRC_NAME[0] était nul afin d'en déduire que le champ était vide, et donc invalider DEL. Or le champ ne correspondait pas forcément au buffer SCR_NAME ! Ainsi :

  • Si le champ est vide mais que SRC_NAME est rempli (cas avant new) : DEL tout le temps actif !
  • Si le champ est rempli mais que SCR_NAME est vide (cas après new) : DEL inactif !

Solution : il y a un invariant : C contient la longueur du champ. Il suffit de tester s'il vaut 0 pour savoir si le champ est vide. La routine devient ainsi générique (ne dépend pas d'un buffer particulier).

—-

  • après un new del ne supprime plus rien.
  • avant un new efface tout même la question.

XXX #5A [Assembleur] Unexpected end of bloc

Corrigé 28/02/2015 dans ASSO. Oubli de reconnecter bk_base.

Pour reproduire : un "]" isolé dans source vierge.
Provoquer une "assertion failure" plutôt qu'une erreur propre avec numéro de ligne.

XXX #59 [Editeur/Frédéric] Numéro ligne 1 disparaît.

Dans source vierge : CONTROL-O + ESC, et le "1" disparaît.
Dans l'idéal, la correction devrait se faire non pas en traitant ce cas particulier (ajout de code…), mais en vérifiant la logique d'affichage.

XXX #58 [Assembleur] Problème de nom de label

[Madram] Ce n'est pas un bug, c'est une feature. Redite du bug #11.

Nommer un label add_space passe sans problème mais… un djnz add_label se transforme en DJNZ ADD _space.

XXX #57 [Monogams] Commande R ne restitue pas ROM

Corrigé 24/02/2015 dans MonHP. Erreur de copié-coller.

La "dernière" ROM (#1F) reste connectée.

XXX #56 [Editeur/Frédéric] Ligne statut détruit tout.

Corrigé 24/02/2015 dans ED-AB. Comment ?

Introduit dans ED-AA (donc absent de la version publique, ouf !)
Pour reproduire :

  • Charger 'lines.o
  • Flèche bas pour scroller.
  • Des lignes du source s'effacent !

En outre, ça clignote d'avantage, comme si le refresh statut prenait plus de temps (bon ça ne serait pas grave, car à court terme la ligne statut n'aura plus besoin d'être rafraîchie lors d'un scroll).

XXX #55 [Orgams/Madram] CTRL-1 + J may crash.

24/02/2015 Corrigé dans CH16. L'adresse de saut était détruite par 'Rasterize' !

Pour reproduire:

  • Charger monho
  • CTRL-1
  • J

XXX #54 [Assembleur/Madram] Erreur dans bloc = crash.

23/02/2015 Corrigé dans ASSN. Erreur fail_assert vs assert_fail, plus overlap error_array dû à calcul manuel des adresses variables

Pour reproduire :

8 ** [
mer dum
]

bug A : Chez moi, ASSERTION FAILURE.
bug B : Chez Hicks (autre contexte) : crash.

XXX #53 [Monogams/Madram] Retour BASIC peut crasher.

Corrigé 24/04/2015. ED-ABM + CH16. BUF_LINE écrasait les variables de 'CH' (sauvegarde de SP), notamment lors d'un CTRL-N. Encore un problème de chevauchement, argl.

Dans certains cas, ça merdouille. Mais je n'ai pas encore trouvé quels cas !

XXX #52 [Editeur] Mauvais refresh Ligne status.

Quand un cherche une chaine non existante, on se retrouve avec "SORGAMS" en ligne de status.

XXX #51 [Editeur] Ligne non rechargée après CTRL-F + ESC.

Corrigé 20/02/2015 dans edYN. Même problème que #4B (et potentiellement, toutes commandes qui demandait une chaine). Je ré-utilisais BUF_LINE cavalièrement. Correctif : buffer dédié.

XXX #50 [Editeur/Madram] Recherche renvoie sur ligne vide.

Résolu 11 Jan 2016 (Ed-ATM).

Entrer call toto entre 2 lignes vides.
Une recherche de toto aboutit à la 2ème ligne (normal), puis à la troisième !

XXX #4F [Trace/Madram] Sortie trace rapide ne donne pas vraie adresse.

Corrigé 18/02/2015 dans MONFR.

Pour reproduire :

      BRK
tt        LD a,".":call #BB5A:jr tt

* CTRL-2
* Se placer après la boucle (eg #9009)
* T
* Q (ou ESC)
* Le PC est forcé à #9009, alors qu'il devrait être à l'adresse courante lors de l'interruption.

XXX #4E [Editeur/Frédéric] Saisie désactivée dans champ.

Pour reproduire :

  • CONTROL-O
  • Saisir caractères pour remplir totalement le champ
  • En effacer quelques-uns avec DEL
  • On ne peut plus en saisir de nouveaux

#4D [Trace/Madram] CONTROL-ENTER ne fonctionne pas pour RSTs

(ça ne fonctionne que pour les arguments 16 bits)

XXX #4C [Trace/Madram] Get_pc_backward incohérent.

20/02/2015 :Amélioré dans DISAM : en cas d'échec, on choisit une adresse plus proche.
Ce n'était pas vraiment un bug : quelquefois, aucune adresse source ne permet d'atteindre l'adresse destination. L'exemple de l'adresse 4 n'est pas pertinent : en effet, les octets en #FFxx ne constituent pas un contexte.

Pour reproduire :

  • Au reset, |tr,4

La fin de la partie grisée ne colle pas avec l'adresse 4.

XXX #4B [Editeur/Frédéric] Import : la ligne en cours n'est pas validée.

Corrigé 18/02/2015 EDYM. BUF_LINE est utilisé cavalièrement, et non re-remplit au retour.

Pour reproduire:

  • On tape un label (sans Return)
  • CTRL-I
  • ESC

Le label n'est pas validé, le curseur revient à gauche.

Bizarrement, ça ne le fait pas quand on entre une instruction plutôt qu'un label, et ça ne le fait pas non plus quand avec CTRL-O.

XXX #4A [Trace/Hicks] Partie grisée doit utiliser fonte grisée !

Quand on exécute une instruction (S), le grisage est fait par masquage. On doit plutôt utiliser la fonte grisée, qui donne un bien meilleur rendu. Cela implique d'avoir stocké le texte (ou les opcodes) avant de lancer la trace.

XXX #49 [Editeur/Madram] SOURCE CORRUPTION !

15/02/15 Corrigé dans IOD. Des variables se chevauchaient, et on écrasait vo_max_chunks utilisé pour inférer le numéro du nouveau chunk à introduire (vo_max_chunks - vo_free_chunks).

Critique mais pas grave. Introduit le 10.
Des variables se chevauchent.

XXX #48 [Editeur/Frédéric] Champ saisie décalé.

Pour reproduire :

  • CONTROL-O, "toto", ESC
  • CONTROL-O, "a", puis plusieurs fois DEL : on écrase le "Open: "

XXX #47 [Editeur/Frédéric] Bloc se déplace seul !

Pour reproduire (version ROM) :

  • On sélectionne un bloque (e.g lignes 4 à 6)
  • On passe au moniteur et on revient (ou alors : on reset et on revient par |o)
  • Les marqueurs de blocs sont décrémentés (lignes 3 à 5), et le bloc disparaît à l'affichage.

#46 [Codec/Madram] Compteur label incrémenté même en cas d'échec.

En cas d'erreur "Label table full" (plus de place pour les chaînes du label), le nombre de labels est incrémenté à tort.

#45 [Monogams/Madram] Valeur bidon pour labels non définis.

Petit avatar du todo #28.
On assemble un source, on ajoute ensuite le label "toto". La commande "?toto" du moniteur affiche une valeur bidon. Il faudrait afficher "Undefined label" jusqu'à ce que le source soit ré-assemblé.

#44 [Monogams/Madram] ?1/0 renvoie #1ff

XXX #43 [Editeur/Fred] CTRL-P ne met pas le flag 'modified'

XXX #42 [Editeur/Fred] Bugs saisie goto line (CTRL-G)

  • On peut appuyer sur DEL dès le départ.
  • On ne peut pas rentrer 9 !? (problème de comparaison, à coup sûr).

XXX #41 [Editeur/Madram] CONTROL-* n'itère pas sur toutes les occurrences.

09/02/2015 Corrigé (doublon #37, qui se produit même quand la ligne erronée est isolée par IF 0).

Il y avait déjà eu une instance de ce bug, dans le cas particulier où le label était en début de chunk.
Mais là, ça se produit dans un autre cas de figure (trouver lequel pour résoudre ce bug).

Pour reproduire : label moniteur dans MONFO

XXX #40 [Monagams/Madram] Crash dans moniteur après BRK

08/02/2015 Corrigé dans MONFO. On récupérait un backup du système avec la 'mauvaise' rom sélectionnée (celle qui a initié le backup).

Introduit tout récemment avec ces histoires de "Firmware Backup/ Mirroir #9800-#9FFF"

|TR,0 puis ESC puis HELP : crash

XXX #3F [Trace/Madram] CPI, CPD, CPIR… mal émulé.

08/02/2015 Corrigé dans TRJ

Pour reproduire :

   BRK:LD HL,t:LD A,#80:CPI
t     BYTE #80

Le flag Zéro est enlevé !

XXX #3E [Monogams/Madram] Zone #9800-#BFFF invisible du moniteur.

10/02/2015 Corrigé (CH12) : RET emprunte le même comportement que RESTORE.
08/02/2015 A moitié corrigé (TRJ+MONFO). Maintenant le problème c'est quand on revient avec un simple RET.

(il s'agit d'une excroissance vérolée du TODO #0B)

Pour reproduire :

    LD A,#42:LD (#9800):RESTORE

Dans le moniteur, m#9800 ne montre pas l'octet modifié (mais d#9800 oui !).
On voit le 'firmware' restoré (toute la zone #9800-#BFFF est sauvée en cas de ROMs externes gourmandes).

XXX #3D [Orgams/Madram] Retour crash si ROM sélectionnée dans programme assemblé.

8/02/2015 : Corrigé dans CH11. Pfff, FAR_CALL rétablit ROM seulement si appel autre ROM, pas si appel RAM. Défaut de conception, à mon avis.

Pour reproduire :

        LD A,9:JP #B90F

NB : le code suivant marche, mais ce n'est pas une raison !

      LD A,9:CALL #B90F
   RESTORE

XXX #3C [Editeur/Frédéric] Flag 'modified' RAZ après annulation CTRL-O

Pour reproduire à partir de source vierge :

  • On saisie un truc
  • CTRL-O : On nous demande "Continue" ? On répond non !
  • Le flag 'modified' a disparu. Pourtant le source est toujours modifié (absence de sauvegarde).

XXX #3B [Trace/Hicks] Ne pas afficher de source quand pas de source trouvé.

Quand getLine renvoie 0, il ne faut pas afficher de lignes de source, mais un message adéquat ou une image de chat.
NB : Dans monFN, je force getLine à renvoyer 0 justement.

XXX #3A [Trans-modules] Transitions CRTC

Corrigé 20/02/2015 dans MonHM. Seulement, le passage BRK vers trace n'est pas tout terrain.

  • Passage Editeur de/vers Moniteur
  • Passage BRK vers Trace
    • En common_init, il est dit de ne pas appeler 'frame'. C'est parcequ'on peut avoir un breakpoint en pleine rupture : plus de VSYNC. Mais rien n'empeche de l'attendre tout de même pendant 312 lignes (i.e. attente synchro avec timeout). Idéalement avec lecture bidon en mémoire xx00 à xxFF pour refresh RAM au cas où le CRTC soit vraiment dans les chous. En outre, si on choppe la VSYNC, il y a une technique pour repartir du bon pied quelque soit la configuration inconnue précédente (en gros, R0=1 puis R9=0 puis R4=0 pendant la VBL, de sorte que quelques lignes plus tard, on soit sûr des compteurs correspondants).
  • Passage RESTORE vers Editeur. Idem
  • Passage Moniteur vers Basic
  • Avant RST0 (CONTROL-SHIFT-ESC)

XXX #39 [Trans-modules] Passage vers moniteur trop sensible.

Après CTRL-1, ESC permet de passer vers le moniteur.
Mais la plupart du temps, on repasse directement vers l'éditeur.
Ceci est dû au passage test touches PPI / test firmware, il faudrait réinitialiser le buffer clavier.

XXX #38 [Editeur/Fred] Erreur fatale non remontée.

10/02/2015 Corrigé dans EDWM. On appelle oDispFail le cas échéant.

Pour reproduire :

  • charger labfull.o
  • décommenter la ligne pour ajouter un label
  • Cela échoue (normal), mais on s'attend à voir un message d'erreur adéquat.

XXX #37 [Editeur/Madram] Recherche interrompue quand erreur de syntaxe

Corrigé 09/02/2015. ASSL. (on essayait de lire ASIS comme une expression pour y chopper un label).

Avec le code suivant, CTRL-* sur la 1ère ligne ne permet pas d'atteindre la 3ème.

lab
targhan renegat
           jr lab

XXX #36 [Monogams/Madram] Crash quand demande label avant |org

10/02/2015 Résolu en même temps que #1C

Si on n'est jamais rentré dans l'éditeur, ?toto crash dans le moniteur.

XXX #35 [Codec/Madram] Echoue à importer "labfull.txt"

Corrigé avec IOC.

Labfull.txt contient 768 labels. On échoue à l'importer, sans aucune indication.

XXX #34 [Trace] Lower ROM inadéquate.

Pour reproduire : |tr,0 ou d0 depuis monogams.
Après le JP #591, on voit que la RAM est dumpée, alors que le status indique bien LROM.

Corrigé dans monFN.o :
Il faut que la ROM basse soit toujours connecté comme indiquée dans valRMR (via OUT dans trace, et vecteurs système dans monogams).

XXX #33 [Moniteur/Madram] Rom basse non visible

CTRL-R + m#1000 ne montre pas les octets en ROM.

Corrigé dans monFN.o.

XXX #32 [Editeur] Recherche de chaîne CTRL+F indique des lignes bidon

08/02/2015 : corrigé dans EDVO

Pour reproduire : prendre le source "monf.o" et chercher la chaîne "["… Ca indique de nombreuses lignes où ce caractère ne se trouve pas.

XXX #31 [Monogams/Madram] Connection RAM perdu de Trace vers Moniteur.

Lors d'un BRK, la bank est généralement bien détectée (pour #C4, #C5, #CC …).
Mais quand on passe au moniteur (ESC), on rebascule en #7Fc0.

XXX #30 [Editeur/Frédéric] Disparition numéro de ligne après Import invalide.

Pour reproduire : |ORG (source vierge), CTRL-I toto (fichier inexistant).

XXX #2F [Editeur/Frédéric] Flag 'modified' enlevé après échec sauvegarde.

Le marqueur ne doit pas être enlevé si la sauvegarde a échouée (disc missing, disc full, etc : flag NC renvoyé par oSave).

#2E [Assembleur/Madram] Sous bug : Numéro lignes erratiques quand erreur fatale.

En cas d'erreur grave (mémoire corrompue), l'assemblage renvoie bien un message 'Failure', mais également les erreurs d'assemblage.
Les lignes associées aux erreurs sont alors complètement fantaisistes.

La solution simple est de court-circuiter les messages d'erreurs, car il est peu probable qu'ils sont instructifs dans cette situation. Mais il serait bon de jeter un œil dessus, afin de vérifier qu'un bug plus subtil ne s'y tapisse pas.

XXX #2D [Editeur/Madram] Pas de tabulation entre label et commentaire.

8/02/15 Corrigé dans DISAK

compute_3d ; In one frame
donne :
compute_3d; In one frame

XXX #2C [Editeur/Frédéric] Ligne status non nettoyé après CONTROL-N

Pour reproduire :
CTRL-N, N

XXX #2B [Trace/Hicks] Pointeur PC copié dans partie grisée quand séparateur.

Comment reproduire :
ùtr,5 (là on voit déjà un doublon, mais c'est sûrement à cause de l'absence d'un get_pc_backward correct)
S (copie supplémentaire !)

XXX #2A [Editeur/Frédéric] Flag 'modified' non RAZ après CTRL-O.

Il n'est pas logique d'avoir le flag 'modifié' après un chargement.

XXX #29 [Editeur/Frédéric] Perte position quand retour moniteur.

[corrigé dans EDU]

On perd la ligne du curseur quand on revient du moniteur (en ROM : ESC puis ESC).
C'est le pendant du bug #08.
Par ailleurs ça décale aussi l'affichage bloc.

XXX #28 [Madram] Crash quand table des labels pleine.

XXX #27 [Assembleur] Crash avec 'IF lab' si lab défini après if.

12/02/2015 Corrigé dans assM. On interdit forward référence.

Le code suivant fait planter l'assembleur.

    IF ll
m = 1
   ELSE
m = 2
   END

ll= 0

XXX #26 [Trace Madram] Emulation MMR incohérente avec X-MEM.

12/02/2015 Corrigé dans TRK.

Avec X-MEM : out #7Exx,#C4 diffère de #7Fxx,#C4.
Or l'émulation (dans trace ou moniteur) ramène tout à #7Fxx.
J'avais pourtant prévu le coup (cf variable MMR sur 16 bits), mais ce n'est pas branché partout.

Argl, bourricot. Ca m'a fait perdre des heures de debugging sur une routine qui ne se comportait pas comme attendu (ni comme la trace le montrait !).

XXX #25 [Madram] |o peut crasher.

Corrigé 19/02/2015 dans ORG17. Oubli de sauver SP pour sortie urgente (exit_mess).

Après utilisation des banks supplémentaires (eg, avec PARADOS), |o est susceptible de planter. Il faut alors lancer |org.
Il est compréhensible de ne pas retrouver le source si celui-ci a été écrasé par d'autres utilitaires. Mais planter est impardonnable !

XXX #24 [Editeur: Frédéric] ".o" n'est pas toujours rajouté lors du CRTL-O.

Ca m'arrive de temps en temps, j'ai l'impression que c'est le cas quand il y avait déjà un nom de fichier (complet) et qu'on veut en charger un nouveau.

XXX #23 [Editeur: Madram] Corruption ligne après recherche infructueuse.

8/02/2015 : Corrigé dans EDVO. Veuillez laisser le buffer aussi propre que vous l'avez trouvé en entrant.

Détecté sur orgams-25_11_24. Peut-être présent avant.
Pour reproduire.
- Saisir ligne quelque (eg : toto1 nop:nop)
- CTRL-F, puis chaîne absente (eg : arheamroehrma)
- Insérer un caractère : la ligne est corrompue (disons, elle subit le même sort que la chaîne de recherche. Cf bug 1F).

XXX #22 [MADRAM] Problème dans oCopyBlk

si l'on sélectionne deux lignes (copy+s et copy+e) et qu'on les copie au dessus par un copy+c le résultat de la fonction oNbLines devrait être de 2 lignes de plus or…il n'y a qu'une ligne de plus.

XXX #21 [Madram] Label non détecté avec CTRL-ENTER.

(corrigé dans orgams-1203 / org11. Concernait les lignes en début de chunk ou contenant des $).

Dans certains cas, CTRL-ENTER est inactif alors que le label pointé existe (d'ailleurs CTRL-* fonctionne).

XXX #20 [Madram] Choix label pour CTRL-ENTER et CTRL-*

Correction complète le 7/09 DISAT ORG1F
Quasi-Corrigé le 14/08/2016 DISAQ ED-AZN ORG1E. Manque le todo #71.

Quand plusieurs labels sont présents sur une ligne, le dernier est choisi arbitrairement comme référent.
Il a été décidé (Reset#18) d'appliquer le comportement suivant :

  • prendre le premier label sous ou après le curseur.
  • s'il n'y en a aucun, prendre le dernier label rencontré avant le curseur.

XXX #1F [Madram] Editeur : chaine recherche modifiee CTRL-F

08/02/2015 : corrigé dans EDVO

La chaîne mémorisée par CTRL-F est passée en majuscule. C'est normal (utilisé pour recherche insensible à la casse), mais :

  1. les chiffres sont aussi modifiés à tort.
  2. on pourrait le cacher, pour ne pas troubler l'utilisateur.

XXX #1E [Madram] RSX |tr foire quand |org n'a jamais été lancé.

Une iniit fait dans |ORG devrait être faite par défaut (ou du moins dans |TR également, pour ne pas corrompre les banks si on n'utilise pas ces outils).

XXX #1D [Frédéric] Éditeur : source non affiché au chargement.

Quand la ligne courante du fichier chargé est égale (ou proche ?) de la précédente ligne courante, rien n'est affiché.
On peut provoquer facilement ce comportement en chargeant un même fichier 2 fois de suite.

XXX #1C [Moniteur/Madram] Labels inconnus renvoient valeur bidon.

10/02/2015 Résolué par parseD/org16. Le parser créait le label manquant ! (même comportement que pour l'éditeur)

Par exemple ?chambre renvoie #0033, alors que le label n'existe pas.

#1B [Madram] Parser. LD A,1 + 1 non reconnu.

Trouvé par Targhan à la reset#18 !
Si 2 espaces avant opérateur arithmétique, alors erreur de syntaxe.

NB : Dans orgams les espaces sont significatifs (eg 1+ 2*3 donne 7, tandis que 1+2*3 donne 9).
Aussi, je ne considère pas ça comme un bug critique.

XXX #1A [HICKS] TRACE : Affichage flags indigent.

L'affichage des flags (SZ.H.VNC) ne correspond pas du tout au registre F.

XXX #19 [Madram] Parser. Opérande a_ non reconnue.

Tous les labels de la forme 'reg' 'sep' 'xxx' ne sont pas reconnus en tant qu'opérande. Où sep est l'un des caractères _ ' #.

Eg

a_ = 1
b#1 = 4
   cp a_      ; Syntax error
   ld a,b#1  ; Syntax error
   add

XXX #18 [HICKS] TRACE. Problème scrolling dans version ROM : on affiche la ROM !

Le bug classique : en version ROM, on ne peut pas lire la page RAM #C000 directement (en revanche on peut écrire dedans).
Pour les scrollings, il faut donc utiliser une copie intermédiaire (eg copy_here en sélectionnant mmr=#C0 rmr=#8e). Ou alors, placer la routine de scrolling dans la bank de travail.

XXX #17 EDITEUR] BUG Décalage lors du chargement d'un source

Lancer ùorg. Insérer une ligne vide puis CTRL+O, entrer un nom de fichier valide.
Double ligne 1 à l'affichage si POS_LINE = 1 à l'enregistrement.

XXX #16 [M/X ?] BUG CTRL-ENTER dans trace

(résolu dans orgams-1122 : disah + mondm)

Après T#38 puis CTRL-ENTER, on ne se retrouve pas en #B941 comme attendu.
NdHicks: actuellement CTRL-ENTER saute à une adresse bidon en attendant la routine de Madram qui me dit s'il y a bien une adresse positionnée sur la lignée courante.

#15 [MADRAM] BUG LD A,"AA"

Le code

    LD A,"AA"
lab

Aboutit à l'erreur : "Line 2: label inconsistancy".
Plus grave, la cause initiale de l'erreur (ici ligne 1) peut ne pas être reportée.

[[/code]]

XXX #14 [MADRAM] BUG BREAK - Registres invalides.

(corrigé dans orgams-1124 -trk.t)

De temps en temps, lors du breakpoint (RST 6) les registres ne sont pas correctement communiqués à la routine de trace.
Dans ce cas, on a par exemple PC=4000 plutôt que la vraie adresse du breakpoint.

XXX #13 EDITEUR - BUG COPY+SPC

10/02/2015 Corrigé dans EDWM ('uppercase' malencontreux)

Fait rebooter le CPC

XXX #12 CODEC - BUG CTRL+L ou CTRL+F

[Ne se produit plus, depuis que l'éditeur ne triche plus avec le nombre de lignes en incrémentant TOT_LINE au chargement]

Si position à la fin du fichier alors CTRL+F et CTRL+L ne fonctionnent pas

NB Madram. Hum, se produit quand la dernière ligne est une "fausse ligne" (eg, ligne vide après la dernière ligne encodée). Ce qui est bizarre c'est que cette ligne ne devrait pas être décomptée et donc atteinte par 'CTRL .'

XXX #11 CODEC - BUG word

word B_ESC affiche : word BYTE _ESC
[madram] Ce n'est pas un bug à mes yeux. Sans espace, on considère en premier lieu que le mot (ici 'word') est un label, si le reste de la ligne fait sens. Ce qui est le cas ici.
Solution : ajouter un espace préalable (comme sous DAMS) pour aiguiller le parser.

XXX #10 EDITEUR - BUG si CTRL-S ou CTRL-L suivi de DEL, dès qu'on entre une nouvelle chaîne

Le bug n'est peut être que graphique (problème dans la mise à jour des coordonnées du curseur ?).

XXX #0F CODEC - BUG évaluation expressions arithmétiques

Par exemple "LD BC,74*15" dans l'éditeur, ou "? 74*15" dans le moniteur.
Corrigé dans AssF.T (orgams-1006.hfe)

XXX #0E CODEC - BUG ld (FLAG), a ne se valide pas

Alors que ld (FLAG),a lui se valide. Problème de parse ?

XXX #0D EDITEUR - BUG Pas de saisie après un chargement

Après un chargement (CTRL+O) l'appui sur une touche puis flêche bas provoque l’effacement de tout un bloque de lignes

XXX #0C EDITEUR - BUG Perte du pavé numérique

Uniquement dans la saisie de l'éditeur mais pas dans la barre d'infos

XXX #0B CODEC [MADRAM] - BUG Orgams ne se burn pas en ROM

En mettant le flag inRom de l'éditeur afin de burner la nouvelle compilation en ROM de l'éditeur ne fonctionne pas.

XXX #0A CODEC [MADRAM] - BUG UNKNOW FILE TYPE

(corrigé dans orgams-1203 / org11. Je faisais une vérification trop zélée sur le EOF)

Lors de la sauvegarde ou du chargement d'un source le message "Unknwow file type" apparait.
Le source ne semble pas corrompu ni au chargement, ni à la sauvegarde.

XXX #09 CODEC [MADRAM] - BUG CTRL+f0

CTRL+f0 ne va pas au début du source.

XXX #08 EDITEUR - BUG Perte position ligne après assemblage

Comment reproduire : ouvrir elines.o, déplacer le curseur au milieu de l'écran (en hauteur), CONTROL-1, espace : on se retrouve en haut de l'écran.
On aimerait retrouver l'écran en l'état après assemblage (avec ou sans exécution), il n'y a aucune raison de scroller.

Il y a 3 variables en jeu :

  • numéro ligne en haut de l'écran
  • numéro ligne courante (celle du curseur)
  • position y curseur

Pour résoudre le bug, il ne faut pas réinitialiser la 3ème.
NB : chaque variable peut se déduire des 2 autres. Il convient donc d'éviter de les maintenir toutes. Par exemple, pour obtenir la première, on recourra à une routine qui ôtera la 3ème à la 2ème (+1 si position commence à 1). Un CALL prend aussi peu de place qu'un LD HL,(…), le surcoût sera indétectable, et on évite ainsi les bugs de synchronisation.

XXX #07 EDITEUR - BUG Report des erreurs discs

Comment reproduire : importer un fichier inexistant.
On ne voit ni "file not found" ni aucun signalement d'erreur.

NB : pour la v1, on n'essayera pas de détourner les messages système. On contraire, on laisse les "Retry, Ignore or Cancel?" et cie.
Il faut donc soit réserver tout l'écran pour les sorties système (ie : nettoyer par MODE 2 !), soit leur dédier une fenêtre (cf &BBB4 - TXT STR SELECT &BB66 - TXT WIN ENABLE, &BB6C - TXT CLEAR WINDOW).

[TODO] A voir comment traiter les erreurs 'internes' (eg : le fichier existe mais n'est pas reconnu).

XXX #06 Trace [Madram] Instructions non gérées.

outi otir outd otdr
ini inir ind indr

#05 Trace [Madram] Crash si trace trace

En traçant la trace, on aboutit à un crash. Difficile à prévenir quand le RST 6 est rencontré en "trace rapide".
Solution 1 : repérer l'appel trace et le traiter comme un 'NOP'.

A voir plus tard :
- détection plus générale d'écriture sur les zones de travail ORGAMS.
- possibilité de tracer la trace (Nécessite 2 zones de travail distinctes).

XXX #04 Trace [Hicks] - BUG Désassemblage erratique

Pour moi, la partie grisée doit montrer ce qui vient d'être exécuté.
Bien sûr, lors d'un breakpoint (RST 6), on ne peut pas le deviner, aussi par défaut on montre le contexte environnant (via get_pc_backward). Mais cette routine ne doit être appelée que la première fois, lors de l'entrée en mode trace (et éventuellement en retour de trace rapide, pour une raison similaire).
Ensuite, en mode pas à pas, il convient simplement de "scroller" la partie grisée, en injectant la ligne venant d'être exécutée. NB : la partie grisée ne doit pas être regénérée avec org_disassemble, car on veut montrer ce qui a été exécuté, et non pas l'état actuel de la mémoire, qui a pu changer suite à auto-modification.

Cela amène deux remarques très pernitentes (de l'avis de mon assistante) :

  • [sous-requête] on pourrait distinguer visuellement le code 'contexte' (obtenu via get_pc_backward) du code assurément exécuté en préfixant le premier par '?'
  • [sous-bug] à mes yeux, les séparateurs ne devraient pas être déclenchés selon les opcodes, mais uniquement en cas de saut d'adresse, c'est à dire quand le PC après exécution d'une ligne différe du PC après désassemblage de cette même ligne. Corollaire : les séparateurs n'interviendraient que dans la partie grisée.

XXX #03 Trace [Hicks] - BUG CONTROL-R non actif

CONTROL-R lance la commande 'R' (trace rapide jusqu'à RET).
Les touches ne sont pas testées dans le bon ordre !

XXX #02 EDITEUR - BUG Tabulations à l'export

Export : Replace code tabulation (09 nn) par espaces, comme pour l'affichage.

XXX #01 EDITEUR - BUG Tabulations à l'écran

Traiter les tabulations en milieu de ligne, pas seulement en position 0.
NB : 2 tabulations possibles sur une même ligne (pour instructions, et pour comment)

Sauf mention contraire, le contenu de cette page est protégé par la licence Creative Commons Attribution-ShareAlike 3.0 License