bugs

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

XXX #1f7 [Ass/Import] Dependent labels not properly invalidated when closing imported source.

Fixed 28 Dec 2025. See commit

Introduced in HH Beta C.
Reproducing is complicated, host source A must import B and C, use some labels from both in a certain order.
Then if we "close" B (by loading another source in its tab), B will be loaded in a new tab when re-assembling A, but some labels will be still pointing to the old tab, while others would be simply corrupted.

Reason

For speed reasons, we store (tab import, Id in import) for imported labels.
When the tab is closed, thoses dependent labels must be invalidated.
This was done, but with a bug in a internal routine, which didn't respect "save HL" contract.

XXX #1f6 [trace/profiling] Time > 65535 wrapped

Fixed 9 Dez 2025 (HH Beta I) framagit commit

To reproduce:

  ld bc,12000
  BRK 
  ldir

• Then CTRL-2, N in trace
• Expected: 71999

XXX #1f5 [trace/profiling] Wrong LDIR timing

Fixed 9 Dez 2025 (HH Beta I) framagit commit

To reproduce:

  ld bc,1000
  BRK 
  ldir

• Then CTRL-2, N in trace
• Expected: 5999
• Got instead: 4719

XXX #1f4 [RSX] |orgload,"tata.o",tab broken

Fixed 18 Nov 2025 in ed-brdb (HH beta H).

Recent regression.

• Expected: load tata.o in tab
• Got instead: empty source in tab

Reason

ed.oSelect wasn't returning Carry anymore for empty tab (surely introduced by some refactoring).

#1f3 [Ass/Import] Dangling label when moving imported source

To reproduce:

   import "whatever.o"
   ld hl,toto   ; a label defined in whatever.o

• Assemble: Success (loads whatever.o in tab 2)
• In tab 2: Load another source
• Re-assemble-tab 1 (loads whatever.o in tab 3 as expected)
• Expected: Success
• Got instead: "Oups" in line 2

Reason

For fast resolution on imported labels, the hosts stores the tab (2) + id of toto (its id in whatever.o, which typically differs from its id in host source).
When Orgams closes whatever.o in tab.2 (to load a new source), all labels from this tab should be invalidated in host source.
I've done exactly that, or so I thought.

XXX #1f2 [Ass] "ld a,_" raises assert

Fixed 17 Nov 2025 in asseva-ad (HH beta H).

• Expected: "Not implemented"
• Got instead: Assertion failure (jump to debugger)

Reason

The special label "_" is reserved. A stub was done for it, but without implementation and an ASSERT_FAIL() instead.

Solution

Replace assertion by regular assembler error flagging.

#1f1 [Ass] Wrong label reported when undefined macro

To reproduce:

tutu = 1
   TITI()

• Expected: Undefined label TITI
• Got instead: Undefined label tutu

Reason

Undefined label is reported for expression evaluation, but macro invocation use a different code, and I forgot to set the label id there.

#1f0 [Ass] Spurious "double defined error" when trying to resolve ambiguity

Same context than bug #1ef. Once solved, it should raise "Ambiguous label".
We could try to solve the ambiguity like this:

   IMPORT "impa.o"
dev = dev   ; Pull dev from impa as global host label
   IMPORT "impb.o"

• Expected; dev = impa.dev
• Got instead: "Double defined"

Solution

I don't see a clean and easy solution for this. The neater solution is to provide a namespace qualifier to desambiguate:

   IMPORT "impa.o"
   IMPORT "impb.o"
dev = impa.dev

#1ef [Ass] Ambuigity not reported anymore

Suppose IMPA.O and IMPB.O both define dev with different values.
A host importing both and using dev should raise "Ambiguous label"

XXX #1ee [Ass] Assert in some rare cases.

Fixed in HH Beta F (ass-hp)

Cannot reproduce with a simple example.

Reason

After fix_error_lines we assert than bk base is connected.
Apparently, it is not always the case after source2line (rare case when overlap error in user code put wrong source pnt reference?).

Solution

Reconnect bk base inconditionaly !

XXX #1ed [Ass] Overlap with import: wrong line reported, then assert

Fixed 1st Nov 2025 in ass-ho, chunckcc-2, (HH Beta F).

To reproduce, create a "dummy.o" source with e.g. "BYTE 0", then:

   ORG &40
   IMPORT"dummy.o"
   ORG &40
   BYTE 1

• Expected: line 2 and 4 reported.
• Got instead: line 0 and 2. And then assert if trying to assemble again.

Reason:

Context: For speed reasons, the overlap check is not done at each instruction, but for the whole range of a tempory buffer (containing at most 256 emitted code) when flushed.
Hence we don't get the exact line of the conflicting address. To mitigate this, we stored the current source pointer at some strategic anchor points.
This was the problem: sometimes anchor point not properly initialised (hence the assert). Plus, an imported file would set this anchor point, and when returning to host the source line couldn't be resolved, since pointing another source (hence the line 0, but only when the import is assembled the first time, not when we use the cached version).
Another problem : it could report a line pointing before the conflicting address.

Solution

Drop this anchor mecanism. Instead report the line at flush point. We get the opposite problem (this can point past the conflicting address), but for now it's considered good enough.

XXX #1ec [Ass] RESTORE directive doesn't work in page C000

Bug as old as Orgams itself.

To reproduce:

    ORG &C000
    RESTORE

• Expected: direct return to editor after CTRL-2
• Got instead: crash

Reason

Well, the RESTORE routine connect high rom to jump back in orgams -> subsequent code in C000 RAM page isn't executed.

Solution

• Connect work bk and jump to the routine doing the rom connection?

No! If we were in C1/C2/C3 we get a similar problem.
The solution is acrobatic. We must jump in #E006. We put the OUT doing the high-rom connexion (&7fxx,&86) at #E004 and jump to it.
Glorious details:

• If the RESTORE routine is itself overlapping #E004 we use an alternative entry address
• We poke back the word overwritten at #E004

XXX #1eb [Trace] Hang after RET when SP in page C000

Fixed 21 Oct 2025 in tr-ba (HH Beta D)

Might have been introduced when adding TM count in trace.
To reproduce:

    BRK
    ld sp,0
    call toto
    inc a
toto ret

• CTRL-2
• S several time
• Expected: we get to INC A after RET (well, there is another problem, that is the value stored in FFFE is trashed by screen display. But in connection 7fc2 we won't have this issue)
• Got instead: hang

Reason

Context: The user memory is connected at trace time, we can simulate a RET by a simple POP HL (HL = PC in the Z80 emulator).
Except when SP is in C000! Because Orgams ROM is connected. In this case a special code path (popret_byhand) will fetch the address.
This code path wasn't saving IX (the continuation address).

#1ea [Ass/minor] Wrong error message when forward reference + imported label.

Very old bug.

Since label in-source override imported ones, we should get the same error message whenever imported source defines it or not.

To reproduce:

   import "toto.o"  ; defnies t
   t ** inc a
t = 2

• Expected: undefined at line 2 (which is itself confusing, it should be "Forward reference not allowed here", but that's another issue)
• Got instead: double defined at line 3.

Reason

When first met (t ** inca ), there is no definition known for t. We hence pull it from imported source.
We have no easy way to know in advance than t will be defined later on.

XXX #1e9 [Monogams] Inspecting label fails after error with imported macro

Fixed in HH Beta ?

To reproduce:

t = 1
   IMPORT"macro.i"  ; Defines ASSERT(pred)
   ASSERT()  ; arg mismatch on purpose

• CTRL-1
• ESC
• ?t
• Excpected: 1
• Got instead: Undefined label

Mitigation

Switching back and forth (CTRL-f2, CTRL-f1) solves the issue!

#1e8 [ED] Minidump slowing down navigation

Also makes the status bar flicker.
The bug is as old as minidump itself.

Mitigation: deactivate it! (CTRL-V). Note: it is not activated by default.

#1e7 [Trace] Source not found in some macro corner cases.

Regression Bug #DEb

XXX #1e6 [Ass] Slowness introduced by overlap check

Fixed 8 Oct 2025 in cocopy-ag and liszt-ag (HH Beta B)

Introduced in HH Beta 7.

Reason

To allow for overlap detection, we store the occupation map in a list. With multiple ORGs, SKIP (or empty BYTE, WORD), we get several disjointed areas (8 for aya/testlib.o).

1. Now, with each new area, we run through the list -> quadratic behavior. The process is repeated when importing a file (to merge the areas in the host source).
2. Plus, the list scanning is done twice: first to check for overlap. then to insert the list

Solution

1. Maintain the list sorted, and first check against last node (the frequent case, where code slices are contiguous).
2. Do check+insert at once.

XXX #1e5 [Ed] Bloc selection may freeze for a while with undefined repetition

Fixed 5 Oct 2025 in ass-hg (HH Beta A)

To reproduce:

  titi - toto ** nop

Then select the line.

• Expected: immediate display of "? nops"
• Got instead: freeze, and might display 0 or random number.

Reason

When a label is undefined, its value is set to 0 (to avoid this exact freezing situtation, or trying to assemble a huge (dummy) number of repetition).
The value of a more complex expression wasn't similarily cleared.

Solution

Force expression value to 0 as soon as it is erroneous. And set nop counter to "unknown" in that case.

XXX #1e4 [Ed] Minidump may assert in some rare case

Fixed 5 Oct 2025 in ass-hg symb-aq (HH Beta A)

Bug as old as minidump?
Cannot reproduce with a simple example

Reason

For get_pc_from_line to be fast enough, it uses the PC stored at the start of source chunch (see speedinguptheprocess).
Then we scan (phase 3) from the start if the chunk containing the line.
If a MACRO was defined in the previous chunk and we encounter its corresponding ENDM in the current chunk, it triggers a call to exit_scope. Since the scan started afresh, the opening scope wasn't met -> ASSERT.

Mitigation

From monogams, enter an empty source (e.g. ed63), deactivate the minidump (CTRL-V) and go back to your source.

Hard solution

Store the complete state (e.g. scope level) in chunk header.

Easy solution

Don't assert! Return an error code instead.

• For assembly (phase 1/2), it should never happen. But in case of Orgams bug or memory corruption leading to that, it's better to raise an assembly error than to assert anyway.
• For scan (phase 3) or trace visu (phase 4), there is nothing we can do. In most cases, it won't hinder the scan (the scope info is only needed if we use a local label impacting $, like in .tempo ** NOP). At worse, we won't get the right PC, which could be detected and warned about.

XXX #1e3 [Ed] CTRL-* may assert in presence of SAVE directive

Fixed 17 Sep 2025 in ass.o (HH Beta 9)

Solution

We must scan lines to find target label. This is done in phase3
We were skipping the params instead of scanning them. Don't know why it triggered the assert!

XXX #1e1 [Save] When several SAVE directives, only the last one is properly saved.

Fixed 05 Sep 2025 in HH beta 7.

That's a bummer.

#1e0 [Ass] Overlap error might indicate wrong lines

Introduced in HH beta 7 (no such error raised before)

To reproduce (case 1):

   org &4000
    byte 42
   org &3ffe
     di
     di
     di
     di

• Expected: Returned error point on line 6 (the 3rd di causing the overlap) and line 2 (the conflicting area)
• Got instead: Lines 3 (wrong) and 2 (ok).

Reason: The sequence provoking the conflict starts at the second ORG. We know the address of conflict (&4000), but for now get_line_from_pc can only return the first instance (line 2).

To repoduce (case 2):

  org 1,&4000
  BYTE 42
  org 2,&4000
  BYTE 43

• Expected: Lines 4 and 2 returned
• Got instead: Line 3 only

Reason: the conflict detection works on physical address ($$). We feed to conflicting address (&4000) to get_line_from_pc which can only track logical address ($). Since $<>$$ , no line is found (hence only 1 line returned, with a sub-bug: we should point on line 4, not 3). A tottaly irrelevant line could also be returned (i.e. if $ = &4000 at some point in the source).

XXX #1df [Trace] Visu lost after import

To reproduce:

   IMPORT"whatever.o"
t
  di

• CTRL-1
• ESC
• dt
• Expected: line 3 shown
• Got instead: Line not found

Reason

Each souce chunk must contain its starting address at chead_pc in the chunk header (see speedinguptheprocess).
It was not set (+), hence tracking PC was starting at 0, unable to reach the target PC.
There is a sub-bug. Normally when encouterning the IMPORT directive in this phase 4, we infer the correct PC from it.
For that, we must discrimiate regular vs skipped import. This is done by comparing current PC (0 here) with the starting PC of the import (9000 in this exemple), as they differ, it is wrongly assumed skiipped, and PC stays at 0.

(+) chead_pc is set to the next chunk (with current $ value) when we have reached the end .
The first emitting chunk is handled seperately, we set its chead_pc the first time code is emitted (*).
This is detected via a flag va_emitted, reset at assemblage init, and set when we first flush the code buffer.
What happens here it that the imported source set the flag (and its own pc_chead correctly.
So, when returning back to host, we consider this process already done and skip it.

(*) Some chunks don't emit code, for instance if they only contains comments, macro definition, or disabbled code.

Solution

• Simplify code: only update at flush time. Cf update_chead_pc
• Well, almost : do it also post import (because, because,
• Oh! Actually must also update when invoking macro, to handle the following corner case:
  • Macro X is defined across chunks
  • X is invoked. The buffer is flushed because full. We don't update chead_pc inside the macro (because the current chunk is not the invoking one, see bugs C0, DEb, 109). But va_pc0 is updated.
  • At next flush, the wring va_pc0 is used.

XXX #1de [visu] Visu source crash when tracing an imported MACRO.

Fixed 30 Aug 2025 in visu.o (HH Beta 7)

Introduced in HH Beta 6 (no such possibility before).
Cannot reproduce yet in a simple example!

Reason

• Bug1: We used speedinguptheprocess to locate the chunk with the target address. That was wrong in general, because the currently pointed chunk was the one containing the macro definition. Its PC marker are wrong (we want the one from the invoking chunk). This triggered bug2.
• Bug2. We restarted the scan from this chunk. This implies getting the line corresponding to the beginning of the chunk (source2line. But source2line works for the current (host) source, and here we pointed to a chunk in the imported source. This triggered an assert (for the crash I have no idea of why it occured, and wasn't able to reproduce anymore).

Solution

• Bug1: To detect that we can restart from the currently pointed chunk, we introduced a variable storing the PC of the chunk following the invoking one. As long as we don't reach this address, we can continue incrementally.
• Bug2. Isn't triggered anymore in incremental tracing (command S). If we jump to another address, that remains to see. But now we return "line not found" (with blue border 01) instead of asserting.

XXX #1dd [ass] Local label lost when using IMPORT in imported MACRO.

Fixed 29 Aug 2025 in symb,org,swap,import (HH Beta 7).

Introduced in HH Beta 6 (no such possibility before).

Reproducing this bug is a bit involved. See testdata/#1dd/instruit.o in the (incoming) repo.

Reason

The scope context (see ) was reset for each source. Before the possibility to invoke imported macros, that was fine, as each source was assembled in isolation.

Solution

Share the scope context across all assemblage. That is, reset it only for main source, don't store it with source metadata (that implies that now a "child scope context" must be created before importing, before it was naturally restored by switching back to host source).

XXX #1dc [Ass] Local labels in imported macros may raise "double defined"

Fixed 28 Aug 2025 in org-ht symb-an (HH Beta 7).

To reproduce, in source B.O:

  MACRO M
.hu
  ENDM

Then, in A.O:

   IMPORT"B.O"
   M()

• CTRL-1 -> this one is ok
• Touch A
• CTRL-1 -> double defined!

Mitigation: Touch B as well!

Reason

Local labels are stored in lists. See AssemblerInternals
The lists are cleared at each assemblage start (but only for current source up to HH Beta 6),
In this bug, B isn't re-assembled (since up-to-date), and when we invoke the macro, the sitting lists leads the label to be seen as already assembled in the same scope (hence "double defined" error).

Solution

Main host must clear the lists also for (recursively) imported source.
Trivia: the dependencies are known from previous assemblage. If a new IMPORT is added in the main host, it won't be seen in this process. That's ok, since it will be freshly assembled anyway.

XXX #1db [Ed] |m + CTRL-f4 set the border red

Fixed 25 Aug 2025 (HH Border 6)

(Internal assertion failed in this case)

XXX #1d9 [Ass] Some errors are displayed twice

Fixed 10 Aug 2025 (HH Beta 6)

Case 1:

   save "toto",&1000,unknown_label

• Expected: just one 1 error
• Got instead: duplication

Case 2:

   MACRO DUMMY n
       word n OR 1
   ENDM

  DUMMY(unknown_label)

• Expected: just two errors (inside macro and invocation site)
• Got instead: duplication

XXX #1d7— [ass status] Overflow in display when assembly takes more than 32.76 seconds—

Fixed in HH Beta 5

Of course the real problem is that an assemblage could take that long.
To reproduce:

  &4000 ** WORD #

• Expected: ~36000 ms
• Got instead: 4006 ms

XXX #1d6 —[monagams/diff] Diff might wrong depending on memory used —

Fixed 18 Aug 2025 (HH Beta 6)

Actually it wasn't a memory full issue, but depended on current chunk allocation.
When asset started at the last chunk of a bank, the link of the next was wrong. Happened 1.66% of the time.

To reproduce (in monogams):

• Leave ~45k memory free
• load"ayalib.bin",&40 (file is &a1be long)
• x&40,"ayalib.bin
• Expected: memory full message
• Got instead: difference at start, as if ayalib started with c0,10,06,e2 instead of 00,00,00,00.

#1d4 [Ass/Import] Imported label is too sticky (might raise "Double defined")

To reproduce: have a host source A.

  import "B.O"
  word glup

In B:

  glup = &cafe

Assemble A, add glup = &baba after the import. Reassemble A.

• Expected: WORD &baba is assembled (in-source labels take precendence)
• Got instead: "Double defined"
• Mitigation: Touche source B (e.g. enter a dummy line or space).

Reason

Imported label are cached. The cached version conflicts with the new definition.
It doesn't happen if glup is inserted first in host source (since we don't even have to look in imported files).
Touching B clears the cache.

Solution

Overide the definition when label is known as being imported.

XXX #1d3 [Ed] Ouch! Selecting a block with LOAD directive before assembling crashes

Oh! This bug was never public. Just happened at home while refactoring HH.

To reproduce:

  LOAD"beuh"   ; doesn't even have to exist.

Then select the line (COPY-S COPY-E).

• Expected: The selected lines (1-1) displayed
• Got instead: Crash

Reason: when the file isn't in cached, Orgams try to load it. But it musn't access firmware in the MachineTime computation loop

XXX #1d1 [ED/Staus] Display of tabs messed up when too many tabs.

Fixed 20 Aug 2025 in ED-BRCV (HH Beta 6)

E.g. with 31 sources opened, we see the last tabs instead of the ones around the currently selected tab.

Reason: the temp buffer wraps into itself.
Solution: when it happens, stop the "scan" if current source is met in pos < (-r1), or shift last half of buffer in first, and continue.

#1d0 [Debugger] 'R' command doesn't work at top-level

To reproduce

BRK
    cp (hl)
    ret

• Expected: fast trace returns just after the RET, with machine-time displayed = 5
• Got instead: continue tracing past RET

#1cf [Monogams] Command "type" may crash when line > 256 chars

To reproduce:

type"xmem-17a/getstart.txt

XXX #1ce [Ass] Spurious "end missing" when error and IF before import

Fixed 2025 Jun 29 in IMPORT AU (gg beta N).

Introduced in GG beta-M (refactoring)
To reproduce

!!   ; Syntax error on purpose
  if 1
  import"toto.o"
  end

• Excepted: Just syntax error on line 1
• Got instead: Also "END missing" on line 2

Reason

For internal motive (error list became global, but without TAB id), we now stop assemblage when there is an error prior to import directive. Since we check non-closed IF at post-assemblage time, the early exit failed the test.

Solution

Skip this check when there is already an error. This is not perfect (as we don't report all errors at once for a legit END missing in that case), but it is less confusing.

XXX #1cd [Ass/Import] Regression: ambiguous import not detected anymore

Fixed 2025 Jun 29 in IMPORT AU (gg beta N).

To reproduce, load a same source in two different tabs, and import it from a third tab.

• Expected: Ambiguous IMPORT error
• Got instead: No error, and the assemblage is boggus.

XXX #1cc Import DAMS failing

Fixed 23 Jun 2025 (GG Beta M).

CTRL-I wasn't recognize dams sources anymore.

XXX #1cb [ass/import] Crash if cyclic import.

Fixed 19 Jun 2025 (GG Beta M).

In case of cyclic import chain (e.g. A imports B, and B imports A), we enter an infinite loop and crash due to stack overflow.
Appartently bug as old as IMPORT themselve (I thought I handled this case, but apparently now).

#1ca [ed/minor] CTRL+F: Right cursor not interpreted as space

To reproduce:

• create a label toto
• go to a different line
• CTRL+F tot<right cursor><enter>
• Expected: stay on same line (no label found)
• Got instead: go to to toto line

Adding a <space> at end of search only returns suffixes (hence toto skipped). This works well.
Now, right cursor visually adds a space, so I expect the behavior to be the same.

XXX #1c7 [Monogams/Diff] Parameter not recognized as filename in: x&100,"toto"

Fixed 30 May 2025 in mon-ci.o (GG Release)

x"toto",&100     -> OK, compare "toto" file with memory at &100
x&100,"toto"     -> KO, compare memory at &100 with &9100

The two commands should read "toto".

XXX #1c6 [Trace/Profiling] Machine Time off by 256 (*n) in corner cases

Fixed 25 May 2025 in GG Release (tr-az.o)

To reproduce:

 BRK
   ld a,0   ; any even number
   ld r,a
   128 ** neg
 BRK

Then CTRL-2, Space (will stop at next BRK).

• Expected: 261 (nops) displayed
• Got instead: 5

Reason

Context:

• Register R is emulated.
• We use it for machine time computation.

Here, `neg` adds 2 to R, and since the instruction takes 2 nops, there is nothing more to add to internal "machine time" counter (reg_tm).
For this to work, we must adjust reg_tm when R wraps.
The adjusment is done at instruction emulation loop (R+=1), but not for ED prefix (or CB for that matter), which also increment R

Solution

After each INC_R() (for instance in ti_ed, ti_cb), add the functionnal equivalent of "call z,add_tm_100".

XXX #1c5 [Monogams/UI] Wrong cursor position when refreshing past content.

Fixed 21 May 2025 In GG Release (mon-ch.o).

Introduced in GG beta K (no permanent display before that).
To reproduce:

|m
x + ENTER (validating command for reference. Return "Wrong parameter", nevermind)
xxxxx + ESC  (move cursor without validating the dummy line)
ESC

• Expected: ">x" + "Wrong parameter" left aligned.
• Got instead: shifted display.

XXX #1c4 [Monogams] Bank connection lost after save binary

Fixed 23 April 2025 in GG Beta L

To reproduce:

> b&ca
CTRL-1
B

• Expected: &7fca connected (displayed top left in monogams)
• Got instead: &7fc0

#1c3 [RSX] Wrong "locate" for |ORGPILOTED

Using |ORGPILOTED may not respect current firmware/basic cursor location, hence io messages (like "Exporting bobs.z80") might be displayed at random location.

XXX #1c2 [Ass] Possible crash when syntax error in macro

Fixed 17 April in GG Beta K. + added assert to detect similar problem from another codepath.

Reason: the syntax error handling unvalidated DE (= buffer), so the subsequent assembled line where corrupting the memory.

XXX #1c0 [Monogams] Print command with multiparameters: they are reversed

Fixed 14 April in GG Beta K

To reproduce:

?1,2

• Expected: 1 before 2
• Got instead: 2 before 1

XXX #1bf [Ass] Missing endm not reported if another macro declared

Fixed 13 April 2025 in GG beta J

To reproduce:

 macro m
 macro n
 endm

• Expected: Missing ENDM at line 1
• Got instead: ** Success **

XXX #1be [RSX] |orgget crashes when undefined label

Fixed 11 Apr 2025 in GG Beta J

Introduced in GG Beta H (no such RSX Before)
Reason: too aggressive factorization of error message! Variable address wasn't POPed in that case.

#1bd [UI] Custom key tokens aren't restored when returning to BASIC

See NoRecess's example: CONTROL-TAB mapping to |CATRUN is lost.

XXX #1bc [UI/RSX] Message not displayed at the end of page

Fixed 7 Apr 2025 in GG Beta I

This is the counterpart of bug #1a8 for firmware display.
To reproduce:

• In BASIC, go to end of page (y cursor = 25)
• |orgload,"3dboobs.o"
• Expected: "Loading 3dboobs.o in tab 1" displayed
• Got instead: Blank line

XXX #1bb [Ass] Memory corruption when unknown label passed to macro

Fixed 6 Apr 2025 in GG Beta I

This is a bug as old as MACRO.
To reproduce:

   MACRO m n.word n.ENDM
  m(unk)

• Expected: memory untouched
• Got instead: stuff poked if &fe

Reason: A normalisation routine was called unconditionally. But in case of error, DE wasn't pointing in the expression buffer anymore.

XXX #1ba [Ass] Dangling IF in MACRO leads to label inconsistency or crash when imported

Fixed 6 Apr 2025 in GG Beta I ("if 0" switched to phase 0, which was an unexpected state when returning from do_import)

Friend of bug #1b0, #1ae, #179.

To reproduce:

  MACRO b
     di 
  IF 0    ; not closed !
     ei
  ENDM   

    scf
    b()
    byte 1

• Expected: Error in line 3 (Missing END)
• Got instead: No error, nothing assembled. "label inconsistency" in more complex scenario. Crash if this source is imported.

XXX #1b9 [Editor] Assertion raised in one unreproducible instance

Mitigated 30 Mar 2025 in GG Beta I
Introduced 29 Mar 2025 in GG Beta H

An assert was raised (with e.g. CTRL-B) because hook_km_wait_key wasn't initialised.
I never managed to reproduce that.
I guess it happened because I was playing with different instances of Orgams (different versions AND custom bank location).

Anyway, mitigation: insert of breakpoint, actually initialise the hook.

XXX #1b5 [UI] Dispqrate help mechanisms for help (CTRL-H)

Fixed 01 Apr in monui-bk (GG Beta I)

In editor: Press CTRL-H to invoke, press a key to exit
In monogams and trace: Hold CTRL-H to view
Thanks @hicks

#1b4 [RSX] |ORGSAVEBIN partially install code in RAM

Introduce in GG beta H (no such RSX befoire!)
The code is installed except in page &8000
The save itself performs without issue, but it can overwrite your BASIC program.

Easily fixable once we have "sorting chunks" routine.

XXX #1b2 [Assembler] No more error raised for real empty files

Introduced 21 Mar 2025 in GG beta G.
Fixed 22 Mar 2025 (GG beta H). Oh yes for non-ascii files cmd_examine return the size with the header.

If a file (ASCCI or binary) has size 0, the error "empty file" should be raised.
Since the fix of #143, that's not the case anymore.

XXX #1b0 [Assembler] Crash when importing a source with missing ENDM

Fixed 6 Apr 2025 in GG Beta I. Was another instance of #1ba, conjuged with #161

When a macro is opened is defined and not closed properly (ENDM) in an imported source, crashes instead of reporting error.

XXX #1af [Editor] Modification history (CTRL-M) not updated for CTRL-P, CTRL-SPACE

Fixed 07 Mar 2025 in ed-brbz (GG Beta F)

Solution: edInsertLine_com must call upd_modified_last_line

XXX #1ae [assembler] Crash in some specific condition

Fixed in GG Beta I (was an instance of bug#1ba)

To reproduce:

• In ayane v0c (copied in ORGBUG/#1ae), load ply.o
• Comment IMPORT"instr.o"
• Control-1

• Expected: undefined labels
• Got instead: crash (happens in phase 2 after all imports processed)

XXX #1ad [general] Wrong CRTC transitions for OSSC SCART->HMDI converter

Fixed Jan 2025 (GG beta F).

To recenter the screen between Trace and Monitor I change R2 at flyback.
The decrochage is invisible on CTM, but is enough to make OSSC go blank for 1 second.
So we need proper transtion (R0 compensation).

#1ac [monogams+unidos] Wrong return when |DIR failing

To reproduce, switch to missing drive. E.g. remove USB drive from albireo, and type from BASIC:

|drive,"a","ums:"  then (I)gnore.
|m
|dir then (C)ancel

• Expected: return to monogams
• Got instead: return to BASIC

XXX #1ab [monogams/RSX] BASIC mode used for RSX instead of mode 2

Fixed 07 Mar 2025 in monui-bg (GG beta F). s/mc_set_mode/scr_set_mode

To reproduce (from BASIC):

MODE 1
|m
|dir

• Expected: display in mode 2
• Got instead: dispay in mode 1

XXX #1aa [Ass/Import] Modification of label not reported in host source in specific scenario with skipped import.

Fixed 21 Oct 2024 in GG beta E. For some reason the (recursive) dependency wasn't flagged in phase 2.
Introduced in GG beta D

To reproduce. A import B then C. C import B.

• A assembled
• B modified
• A assembled -> C isn't reassembled to take B's changes!

Reason

• Skipped imports aren't flagged as recursive dependencies. I have no idea why, as the code looks correct.
• Before beta D: we
• After beta D: we use recursive dependency flags to know which sources to re-assemble.

XXX #1a9 [Ass/Import] Modification of label not reported in host source in specific scenario

Fixed 17 oct 2024 (GG beta D) in org-hl.o and cache-l.o

Bug as old as IMPORT directive.

To reproduce:

; A.O (tab 1)
  IMPORT "B.O"
    LD a,toto

; B.O (tab 2)
toto = 1

• CTRL-f1, CTRL-1 (assemble A.O)
• CTRL-f2, change to toto = 2}
• CTRL-1 (assemble B.O)
• CTRL-f1, CTRL-1 (assemble A.O)

Expected: LD a,2
Got insteand : LD a,1

Reason

Same phenomenon than bug#19A, but the fix for that one isn't enough, since neither B's generated content or length has changed.

Workarounds

• Do not assemble B separately!
• Assemble A from scratch (with CTRL-5, or by modifying it, e.g. entering a blank line)

Solution

I intend to change the "up-to-date" checking mecanism. Instead of transitively try to check if imports are up-to-date at assembly time, flag dependant sources as not up-to-date at modification time. It will also be faster.

XXX #1a8 [Monogams/UI] Error message not displayed at end of page

Fixed 01 Apr 2025 in mon-ca (GG Beta I)

To reproduce, go to end of page (25 x RETURN or with m command), then

|ayahuasca

• Expected: 'Unknown RSX' error message display
• Got instead: blank line.

Due to incorrect fix of bug#157?

XXX #1a7 [Trace & Minidump] Wrong PC after 'skipped' import

Fixed 13 Oct 2024 in ass-gc.o (GG beta C).

To reproduce:

; C.O
    Byte &ca

; B.O
    IMPORT "C"
b1
   byte &ca
b2

; A.O
   IMPORT "B"
a1
   IMPORT "C"
a2  
     BRK

Then control-1, espace.

• Expected: When cursor on a2, dump should point at the same address than a1
• Got instead: Same address than b1.

Reason

Since each import is only instantiated once, when A met C, it is skipped (meaning $ and $$ don't change).
But when tracking $ (for source visu in trace or minidump in editor), we update it to C's end address (i.e. the $ reached when it was imported by B).

Solution

Discriminate "instantiated" vs "skipped" case.

• Instantiated: use cached end-address (current behavior, after (incomplete) fix of bug#199)
• Skipped: do nothing

Solution actually used

When assembling, it's easy to know which imports to skip, that's the ones that have been visited.
After assembling, all imports have been visited, it's harder to infer back this information.
So another criteria was used: if the starting $ of the import is different to current $, it means it wasn't instanciated here, hence necessarily skipped.

XXX #1a6 [Trace/Profiling] Wrong timing for BIT n,(hl) BIT n,(ix)

Fixed 14 May 2025 (GG Release).

To reproduce:

    BRK
    BIT 0,(hl)

Then CONTROL-2, N
Expected time displayed: 3
Got instead: 4

XXX #1a5 [Editor/Profling] Wrong auto-update in some cases.

Fixed 14 May 2025 (GG Release). Solution: call update_bloc after having deleted the line.

To reproduce:

   nop
   inc bc 
   nop

Select the 3 lines, we get 4 nops as expected.
The delete the line 2 (CONTROL-DEL).

• Expected: 2 nops
• Got instead: 3 nops

XXX #1a4 [Trace] ARGLLLLL. Memory corrupted after CONTROL-UP.

Fixed 1 Oct 2024 (GG-Beta B) in monhelp vC. mGetBck expected DE = buffer, which wasn't set.

Not sure whether it's an old bug or introduced whilst refactoring.
To reproduce:

  org &700
   fill 256,1

Then CONTROL-1 (assemble), ESC, d&700, CONTROL-DOWN, CONTROL-UP.

• Expected: ld bc,&0101 still here
• Got instead: nop until &72c

XXX #1a3 [Ass] CP "A-1" triggers weird errors

Fixed 20 Sep 2024 (asseva-q). Was off-by-one when skipping string in case of error.

Might be as old as Orgams. Also problems for BYTE 1+"boob"

Thanks @Hicks.

#1a2 [Editor/Inline profiling] When not assembled, label ** opcode reset machine time counter

We should put "?" instead, as label isn't resolved yet.

#19f [Editor] Inline dump doesn't honor ROM / Bank selection.

E.g. at C000 we'll get current videoram data, which is nonsense.

XXX #19E [Ass] Internal assert triggered in some rare case

Another instance of #1ba, but was then masked by the fix of #160

It happens at home when assembling orgnrt/bug#19e/compnrt.o, which imports tons of source.
Oh! I have found an easy to reproduce:

source A.O:  IMPORT "B.O"
source B.O: IMPORT "C.O"
source C.O: IF 0

Then assemble A -> assertion triggered because bk base not reconnected.
That's an unfortunate side effect of bug#160

XXX #19D Filename not present in header when saving assembled as binary.

Fixed 23 Apr 2025 (GG Beta K). DE/HL mixed up.

Thanks Krusty!

XXX #19C [Trace/Visu] Wrong source line pointed with deactivated code in macro

Fixed 14 Aug 2024 (GG Beta 7).

To reproduce:

  MACRO M
  IF 0
;
  END
  ENDM

  BRK
     M()
     ei 
     ei
     ei

Then CTRL-2 (and maybe CTRL-V to see the source).

• Expected: Source visu pointing on first 'EI'
• Got instead: Source visu pointing on third 'EI'

XXX #19B [Editor/status] Information about selected lines not properly erased for some messages

Fixed 16 Aug 2024 in GG-Beta7 (ed-brbw)
Introduce in GG-Beta6 (no such info before!)
E.g. COPY-DEL -> the confirmation question partially overwrite, with a dangling "nops"!

XXX #19A [Import/cache] Old version of source used in very specific scenario

Fixed 15 Aug 2024 (GG Beta 7) (cache-h, org-hb, import-al). Now we also check post $ and $$ of imported source to decide whether host source must be re-assembled.

To reproduce:
Let's assume unrelated sources A and B both import C from the same ORG address.

1. Assemble A.
2. Modify C.
3. Assemble B
4. Assemble A -> kaboum! Uses previous version of C.

What is happening:

• A is considered up-to-date (step 1)
• C is considered up-to-date (via step 3)

So everything is considered up-to-date, and it uses the previous version.
Oh! Actually it's a bit worse: it's using new version, but with the size of the previous version.

XXX #199 [PC tracking] PC tracking lost after IMPORT

Fixed 9 Aug 2024 in ass.cpt_import, import-aj, org-ha (GG beta 7). It wasn't handled at all.

It affects both in-editor monitor and source visu in trace.
To reproduce: NoRecess Example
Thanks NoRecess!

#198 [Editor/Profiling] Assembling needed for conditionals and macros.

If the source is not assembled, the wrong condition might be taken, and macros aren't resolved.
At least we should put a message about that.

#197 [Editor/Profiling] Machine time not counted for CALL, DJNZ and other loops, IMPORT.

To reproduce:

   call subroutine

Then select the line (COPY-S, COPY-E).

• Expected: total machine time
• Got instead: just 5 (time of the call instruction)

XXX #196 [Trace/Profiling] Wrong timing for LD A,I LD I,A LD A,R LD R,A

Fixed 05 Aug 2024 (GG beta 6).

To reproduce:

   BRK
  ld a,i

Then CTRL-2, N
Expected: 3 nops reported
Got instead. 2 nops reported

XXX #195 [Trace/Profiling] Bunch of DD/FD won't update clock properly

Fixed 25 May 2025 in GG Release (tr-az.o)

   BRK
   call toto
toto
   fill 256,&dd
   ret

Then CTRL-2, N
Expected: 264 nops reported
Got instead. 8 nops reported

Edit Cannot reproduce anymore with this example. Cannot find another one.

Reason: cannot be bothered right now. See ti_ixy_com

Introduced in GG beta 5 (no profiling before).

XXX #194 [Trace] "ld a,r" doesn't load the right value

Fixed 28 May 2024 in tr-as (GG beta 5). Copy-paste error?

To reproduce:

   BRK
   ld a,8
   ld r,a
   ld a,r

Then CTRL-2, N, N, N.
Expected: A = 10
Got instead. A = 6

XXX #193 [Trace] "ld a,r" / "ld a,i" wrongly reset carry

Fixed 28 May 2024 in tr-as (GG beta 5). Was based on F rather than F' (emulated F).

XXX #192 [Trace] out (n),a wrongly emulated when opcode in page c000

Fixed 26 May 2024 in tr-as (GG beta 5)

Reason: Register 'b' used as backup overwritten when reading in C000 (due to the acrobatics needed).

#191 [Trace/profiling] Wrong timing for cpir/cpdr when value found.

Introduced in GG beta 5 (no profiling before).
It's couting 6*(BC-1) + 4 instead of real # of iterations.
R emulated in this case is off for the same reason.

#190 [Trace/minor] Flags 3 and 5 wrongly emulated after ldi/ldd/ldir/lddr

The undocumented behavior (cf z80.o) isn't respected in some corner cases. Or is it?
Does anyone care?

XXX #18f [Trace] Wrong R emulation for LDIR / LDDR / CPIR / CPDR

Done 24 May 2024 in tr-as (GG Beta 5). Ok for LDIR/LDDR. See #191 for CPIR/CPDR.

XXX #18e [Trace] RLD/RRD wrongly emulated when HL in page C000-FFFF

Done 29 May 2024 in tr-as (GG Beta 5).

Reason: Well, RLD/RRD weren't emulated, but executed as is, which would read Orgams ROM in page C000.

XXX #18d [Trace] Wrong LSB POPped when SP = &ffff

Fixed 23 May 2024 in tr-as.o (GG beta 5).

This affects both POP and RET.

To reproduce:

     ld sp,&ffff
   BRK
     pop bc

Then CTRL-2, N.
Expected: C = whatever is in &ffff (00)
Got instead. C = the byte in monogams ROM (&55 at time of writing)

Reason: For page 0000, 4000, 8000 we can read directly (execute POP as is).
For page C000 we need to disconnect ROM etc…
Hence there are 2 code paths. The discriminating test properly handled the corner case SP=&BFFF, but not &FFFF

XXX #18c [Trace] Wrong R emulation for IX/IY instructions

Fixed 23 May 2024 in tr-as.o (GG beta 5).

To reproduce:

    BRK
    ld ix,0

Then CTRL-2, N.
Expected: R += 2
Got instead. R += 3

Reason: Two "INC_R()" in DD/FD prefix handling (copy-paste or refactorisation mistake?).
Also, corner case for "invalid" prefix:

    BYTE &fd:exx

• &fd loads IY in HL' internally (INC_R)
• Read exx opcode (another INC_R)
• emulated exx detect &fd state. We flush that, and re-read the opcode. Oopps, supernumerous INC_R.

#18b [Editor/minor] OTIR instruction not recognized.

It is seen as a label.
Note: No problem for OTDR

Considered minor bug:

• OTIR is not really usable on CPC
• There is a workaround: enter OUTIR instead (not the official opcode name, but makes more sense).

XXX #18a [Trace] Visu LOAD directive corrupts &8900

Fixed 18 May 2024 (asseto-c), GG beta 5. ass.o already copied filename out of bank in a safe place.

To reproduce:

    BRK
    LOAD"data"

Then CTRL-2, (CTRL-V to visualize code), N.

• Expected: 8900 zone intact.
• Got instead: 8900 zone trashed with filename.

Reason: asseto.get_file routine use 8900 buffer to find size of file (in order to update $).

#189 [Trace] INIR/OTIR/INDR/OTDR wrongly emulated.

XXX #188 [Trace] IND wrongly modified after A

Fixed 8 May 2024 in tr-ae.o (GG beta 5). Was copy-paste error.

To reproduce:

    BRK
    IND

Then CTRL-2, N.

• Expected: A not changed.
• Got instead: A trashed.

XXX #187 [Trace] Crash trying to emulate IM n

Fixed 8 May 2024 in tr-ae.o (GG beta 5).

To reproduce:

    BRK
    im 1

Then CTRL-2, N.

• Expected: Just skip the instruction (interuptions not emulated anyway).
• Got instead: Crashes.

Reason: copy-paste typo (OUT (C),C instead of OUT(C),A to connect work bank).

XXX #185 [Assembler] Local label not found after empty repetition

Fixed 2 Aug 2024 in ass-fs (GG beta 6). "Bloc scope" was entered but not closed when rep = 0

To reproduce:

   jr .ko
   0 ** inc hl
.ko

• Expected: Assemble without errors
• Got instead: Undefined label

#184 [Editor] Bookmark not registered for key W (Azerty)!

On Qwerty, that's the Z key.

Reason: SHIFT-CRTL-W (71) also triggers Q keycode (69), due to CPC keyboard matrix bug.
And the routine doesn't found any bookmark associated with Q.

#183 [Trace/UI] Call-Stack not refreshed when switching tab.

Plus, resolved labels shoud be sticky.

XXX #180 [Trace] LD A,I doesn't set P/V := IFF2

Cannot reproduce. To check: does BRK capture IFF?

XXX #17D [Ass/Import] Inadequate "Ambiguous label" error.

Introduced with IMPORT directive.
Fixed 17 March 2024 in impevabc (just raise error if value is different). Available in GG beta 4.

When you import several sources which defines the same label, using this label raise the "Ambiguous label" error.
But it doesn't have to be the case if it's the value is the same.

XXX #17B [Trace/Visu] Tracing macro with source visualisation may corrupt memory. Argl.

Introduced long ago.
Fixed 17 March 2024 in ass-fm, visu-o, org-gy. Available in GG beta 4.

To reproduce:

• Trace juste before macro invocation (with source visu)
• Reset
• |m
• Resume tracing, enter the macro

• Expected: Correct line source is found after macro invocation
• Got instead: Source not found, area 00 and more erased.

Reason

At some point I move a lot of variables out of bank (simpler & faster code).
When resetting and returning to orgams, those variables are reset (or not set at all).

Solution

Put back every non-temp variables in bank.

Actual solution used

It was too cumbersome to put everything in bank. Not only the variable must be moved,
but all the working areas (like macro stack). Not worth it.
Instead, we put the current caching state in temp memory as well: after reset, it is zeroed, so we start from scratch, not rellying on erased variables.

XXX #17A [Orgload] Doesn't restore 8000-A000 memory.

Fixed 3rd Mars 2024 (GG Beta 3). ch-cj + monui-bc

Introduced in GG beta 1 (no such RSX before!). Quel distrait !

• Reason: Orgams install stuff in 8000-A000.
• Solution: Must restore (goto_basic) like CONTROL-B in monagams.

XXX #179 [Assembler] Dangling 'ELSE' raises "Label inconsistency"

To reproduce:

ELSE
  DI
END
toto

• Expected: "Unexpected ELSE" at line 1
• Got instead: "Label inconsistency" at line 4

XXX #178 [Editor] New entered lines aren't put in "modified" history (CONTROL-M)

My bad! They are. Only the last one of them when in succession. It was on purpose, not to fill history with succesive lines.
The new history manager deluxe will propose a better solution anyway.

XXX #177 [Monogams] Label shown as "undefined" in monitor after reset.

Introduced in FF release.
Fixed 21 Feb 2024 (GG Beta 1). symb-w.o

To reproduce:
- assemble source with label (e.g. tutu)
- reset
- |m
- ?tutu

Expected: The value of the label
Got instead: Undefined (try to assemble)

Reason

Label index was put out of bank:
- simpler code
- slightly faster assemblage

So it isn't persistant anymore.
For assemblage it doesn't matter: either the source is up-to-date and the index isn't needed (cache is used instead), or the index is rebuilt from scratch.
It might cause a memory leak though.

Solution

Find the real reason of assemblage slowness, and revert this change !

In some cases, when trying to print (?tutu, monogams will show:

Undefined label (must assemble first)

Yet the source has been properly assembled.

#176' [Ass UI] Exec (CTRL-2) doesn't honor BANK for forward ENT.

To reproduce:

    ENT start   ; Oups, start in bank C7, but as bank C0 is connected here,.
    BANK &c7
    ORG &4000
start   BRK

Expected: CTRL-2 (or CTRL-1 +J) Jump into bank C7
Got instead: Bank C0 is selected at exec time -> crash.

Discarded solution: 24 bits linear address

I was tempted to store the complete address (e.g &011555 for &5555 in bank &c4).
Unfortunately we would lose some information : E.g. &5555 in bank &c4 would give the same address than &1555 in bank &c2.
In each case we want the label to resolve to the proper 16 bits Z80 address (&5555 and &1555 respectively).

Proper solution: Store selected bank with 16 address

We should even store the full bank selection (e.g. 7ec4) for > 512k memory.

XXX #176 [Ass UI] Exec (CTRL-2) doesn't honor BANK

Fixed 28 Jan 2024. For FF release 29 Jan. Assfg (store selected bk when encountering ENT). chcg (connect stored bank).

Spotted by Hicks!

To reproduce:

    BANK &c7
    ORG &4000
    ENT $
    BRK

Expected: CTRL-2 (or CTRL-1 +J) Jump into bank C7
Got instead: Bank C0 is selected at exec time -> crash,

XXX #175 [Assembler/Import] Wrongly using "cache" in some cases

Fixed 9 Jan 2024 in org-gr (Release FF).

To reproduce, have a source A importing a source B.

• 1/ Assemble A (there shouldn't be any error)
• 2/ Add an error on B.
• 3/ Assemble A (it points as expected on the error on B)
• 4/ Assemble A again, it doesn't point to the error anymore, and produce wrong code.

Workaround

Use CONTROL-5 to force assemblage from scratch

Reason

• A itself was flagged as uptodate.
• In step 3/, we clean dependencies as it is a new assemblage. Since assemblage was interrupted by the error, the dependency A -> B wasn't setup.
• In step 4/, we check recursively if all imported files are uptodate. The problem is B isn't flagged anymore as dependency.

Solution

When the assemblage isn't considered recursively as up-to-date (step 3, works great), set the host source as not up-to-date ("dirty" flag), to force re-assemblage in any case (except of course if assemblage completes without error, in which case the dirty flag is cleared).
Another solution would be to set the dependency regardless of the error status, but the previous solution is simpler.

XXX #174 [Trace] Control-f4 not active

Fixed 5 Jan 2024 in trui-am (FF Release). Was a copy-paste error.

If source to be visualized is in tab #4, we have to go back to editor to switch.

XXX #173 [Assembler] Garbage generated after IMPORT not found

Fixed 5 Jan 2024 in ass-ff (FF Release).

When assemblage is erroneous, the expected behavior is that no code is installed in RAM.
This bugs breaks this principle.

To reproduce:

   org &cafe,&3000
   import "absent.lol"
   word $

Assemble (CONTROL-1)

• Expected: memory untouched
• Got instead: &03 at &3000

Reason

DE = $$ instead of work buffer after the directive IMPORT itself failed.
Note that some code is emitted (in buffer) even in phase 1, due to shared routines.

Solution

Restore DE in any case

How to avoid same mistake

??? Make sure API is respected at each exit point (difficult to automatically test)

XXX #172 [Assembler Speed] Forward EQU are too slow

Fixed 4 Jan 2024 in asseva-o (FF Release). Cf solution. Gain ~5% assembly time (depending on the source. Nothing is gained when you don't use such forward references).

When we have:

jump = benediction
; [...]
benediction

At phase 1, "benediction" wasn't met yet, so eval_label try to resolve it in imported deps.
This requires:
- Getting the label name (rather than just the id, which is distinct in each source)
- Iterate through possible dependencies.
It is done even when no dependencies exist! That is, it is slowed done even if no IMPORT is used.

Solution: first check if there are any dependency (this check is fast), Do nothing if not.

XXX #171 [Assembler] LD BC,1/0 accepted

Fixed 3 Jan 2024 in assevo-n for FF release.

Excepted: "Division by zero" error
Got instead: ld bc,&1ff "successfully" assembled

#170 [Editor] CTRL-L: Adding a space hide suggestion.

Related: bug #124.
Adding a space in CTRL-L forces exact search rather than prefix search.
That's exactly the wanted behavior, following the same principle than for regular search:
Adding a space in CTRL-F forces suffix search rather than complete search.

But then the exact label disappears from suggestions.

Workarounds:

• Don't add space! Use cursor right for exact search.
• Or just press enter, the search itself works.

Solution: in case of trailing &20 char :

• remove it from completion pattern
• only take the completion suggestion that matches exactly the pattern

#16f [Assembleur/minor] LD A,-256 accepted

Bug as old as Orgams itself?

• Expected: Error 'overflow 8 bits'
• Got instead: LD a,0

NotaBeneDiction1. LD bc,-256 correctly gives LD bc,&ff00

NotaBeneDiction2. An error is raised, as expected, for:

• SKIP -256
• FILL -256,0
• -256 ** INC L

The error itself could be more accurate (e.g. "unexpected negative value" rather than "overflow 16 bits"), It's Monday and I don't really care.

XXX #16e [monogams] 'tabs' command doesn't scroll properly

Introduced in FF Beta M (well, no such command before).
Fixed 05 Jan 2024 (for FF Release) in mon-bt and txtfirm2 (to update offset even without bandeau). Hum, must call "ScrollUpIfNeeded". What an awkward set of routines.

XXX #16d [Editor] Invalid state for new tab accessed from monogams's ED n

Fixed 30 Dec 2023 (ed-brbg org-gp). Ed's init must be called for new source, even when not triggered by ed itself. Available in release FF

To reproduce:

|orgams
ed2

• Expected: Brand new tab with 1 line and cursor at top
• Got instead: Cursor in the middle of the screen, 0 line

XXX #16a [Orgams] Binary Save doesn't work for code assembled in C000.

Fixed 18 Dec 2023 in CH-CF.o (FF Beta L). Install code just before saving.

To reproduce, cf code in #169. CONTROL-1 + B.
Expected: Proper binary is created.
Got instead: File with correct start and length, but 00 filled.

XXX #169 [Assembler] CONTROL-1 + Jump doesn't work for code assembled in C000.

Fixed 5 Dec 2023 (FF Release). Install code after command is pressed ('J' or any other for that matter: code must be installed to allow inspection by monagams).

To reproduce:

   org &c000
   ld a,"!":call &bb5a
   jp &bb06

It works with CONTROL-f2, but surprisingly not with CONTROL-f1 + J, which is meant to be equivalent.

Expected: Proper execution (we see "!" displayed)
Got instead: Direct return to Orgams.

Thanks Cwiiis!

#168 [Monogams/minor] Cannot evaluate imported but unused label from host source

Classified as minor as: we don't often need that, plus there is a workaround

To reproduce, have a source B.o with label chaussette.
Switch to a tab for source A:

    import"B.o"

• CONTROL-1 to assemble
• ESC to go to monogams
• ?chaussette

Expected: Got the value of chaussette from source B
Got instead: Undefined label

Reason

Since chaussette isn't used in source A, it's not in symbol table and resolution won't be tempted.

Workaround

Switch to tab with source B!

Solution

• asseva.o: Remove fix used for bug#167
• asseva.o: Resolve label from imports even if not in symbol table.
• mon.o: redraw status bar after command, as a new workaround for bug#167

XXX #167 [Monogams UI] Garbage in status bar when label not found

In assemblage, when a label is not found, it is searched for in imported sources. Great!
It also happens in monogams e.g. ?unexisting, which is not meant to be:

• the search itself use the same area than the status bar (hence the garbage)
• it shouldn't happen at all: the source must be already assembled to get labels' values, so no resolution is to be done!

In other words, either the source is not assembled, and we cannot give the label's value, or it is assembled, and if a label isn't found, that means it isn't used at all in the source.

Solution: set phase to 0 before monogams evaluation, and in that case do not try to resolve labels.

Note: this solution actually conflicts with bug#168 resolution.

XXX #166 [Editor] Cannot switch source if filename is longer than 52 chars.

Fixed in org-gv 26 Feb 2024. Available in GG Beta 3.

If the filename is too long, typically due to a long path like ums:overlanders/music/shap/2013/novembre/un-soir-d-ete-sur-le-balcon/ds44.128,
switching to another tab will provoke an assert.

Reason

To switch tab we store information about the source (meta-data like filename, cursor location and other editor related, internal housekeeping).
When the filename is too long, it goes over the reserved 248 bytes. Hence the assert (rather than a corrupting buffer overflow).

Solution

Split meta-data in several chunks (well, the spliting should be done automatically by the chunk.o library).
Actually was already using data-chunks (heap.append_raw_in_chunk). It's the intermediate buffer that was full and needed to be flushed.

#165 [Assembler/Import+Macro] Invalid 'Double Defined' error in some corner case.

To reproduce:

     MACRO RWORD(w)
          byte w/&100, w AND &ff
     ENDM

     IMPORT":lib/math.o"  ;  Contains routine_toto

     RWORD(routine_toto)

routine_toto
     ; whatever

Expected: Assembled without error.
Got instead: Error 'Double Defined' for routine_toto in host source.

Reason

The IMPORT semantics dictates that labels in host source should shadow the ones in imported files (to prevent spurious conflicts).
Normally labels aren't evaluted in phase 1. The MACRO invocation is an exception, since the passed value could be used for conditonal assembling.
So when routine_toto is first resolved, it is assigned to the only instance met so far (the one from math.o).
Then, when encountering the local instance, it is seen as already defined.

Solution

Local definition should override assignation to imported labels.

XXX #164 [Assembler/Import] Host source not re-assembled as expected in some corner case.

Status: False Alarm. I saved an imported source on a backup device. Since the whole path serves as ID, the original version was reloaded in another tab, and I was modifying the wrong source.
TODO: use filename as ID (not the whole path)?

To reproduce:

• Have a source A importing B. B contains an assembling error (e.g. syntax error).
• Assemble A. The assemblage points to the error in B (which is expected)
• Fix the error.
• Assemble B (that's not really what we want, as B is imported).
• Assemble A -> it doesn't take into account the change in B.

Expected: A is reassembled from start.
Got: Wrongly assembled code.

#163 [Editor Help] Cycle: Wrong mapping indication for QWERTY

For QWERTY keyboards, the cycle shortcut is CONTROL-+
(since CONTROL-% conflicts with already used CONTROL-5).
To be clear : the mapping is as intended, it's just wrongly documented in case of qwerty keyboard.

XXX #162 [Assembler] Supernumerous 'END' not detected.

Fixed 2 July 2023 (for release FF) in ass-ax. We track if_level. Slight regression: only 8 levels of IF allowed (previous version allowed a bit more when outermost where 'if 1').

The assember doesn't complain if 'END' doesn't match any 'IF'.
That could be seen as a feature (forgiving assembler), but:

• It prevents to detect potential mistake.

It is usually more helpful to be more strict.

XXX #161 [Assembler] Missing 'ENDM' for macro not detected.

Fixed 6 Apr 2025 in GG Beta I

XXX #160 [Assembler] Missing 'END' for 'IF' not detected.

Was fixed 17 Sep 2024 in GG beta 8

The assembler doesn't complain if 'IF' isn't closed.
That could be seen as a feature (forgiving assembler, allows 'IF 0' to deactive code until end of source).
But:

• It prevents to detect some typo / real errors
• It leads to bugs when the source with dangling 'IF' is imported.

XXX #15f [Trace] Visu crash when macro invoked with local label.

Fixed 26 Apr 2023 (FF Release) as indicated in the solution. Required an update of farcall.o.

To reproduce:

MACRO n:word n:ENDM
n(.rout)
.rout

Then assemble and try to debug with source visualisation.
Expected: Source line is found and displayed
Got instead: Crash/Reset/Hang

Reason

Local label resolution in symb.o use firmware call to bricbrac.rom (list search among instances of local label with the same name).
Or, for source visualisation in the debugguer (visu.o), we cannot use firmware:

• User RAM is connected at A000-BFFF, so there may not be firmware at all.
• We use regs' (exx).

On most occasion, we don't have to compute expressions, we just need to know the length of the code to infer $ (e.g. CALL .rout -> 3 bytes, we don't evaluate the address).
For MACRO invokations thought, all parameters are evaluated systematically (strict evaluation), since the parameters could be used for conditionnal assembly (IF directive).

Solution

Use Orgam's own far_call routine.
That should be the default anymore when calling low-level routines in BRICBRAC which don't use firmware (i,e. no I/O or the like).
-> Faster and safer (since can be used in any context). The only drawback is that firmware isn't aware of the ROM change:
* BUG at return if we use I/O (Amsdos)
* Orgams debugger doesn't know which ROM is connected.

XXX #15e [monogams/rsx/minor] load"toto" isn't recognize as rsx. The "|" is mandatory.

Fixed 28 Mar 2025 in GG Beta H (i forgot a stub for a monogams LOAD command, which wasn't connected to anything).

Minor, because:

• From editor no issue since the "|" is pre-entered
• The workaround is simple
• There may be a "load" monogams command one day, so it's actually good the users explicit type the RSX invocation.

#15D [rsx] Lot of stack used to pass parameters.

Introduce in FF beta I (before you couldn't pass parameters).
A big chunk of stack (72 bytes) is used to pass parameters.

They are released when the RSX returns, but it could cause issues:

• For stack heavy command (e.g. |copy involving fatfs node)
• For big tools (e.g. if invoking orgams from itself, stack space will decrease rapidly)

Solution, either:

• Use some free room in BASIC or FIRMWARE workzone.
• Cleany reserve space from firmware (like BASIC does to store its variable, or UNIDOS's |COPY).

XXX #15C [minor] Invoking |o,"source" from orgams itself crashes.

Introduce in FF beta I (before you couldn't pass parameters to rsx).
Solved in FF beta I. Actually consisted of two bugs:

• Expecting DE = last RSX parameters. That was bad.
• Lack of handling of empty string, due to temporary lack of room in rom.

Minor: Well, there is no reason you want to do that, but here it is.

To reproduce, under monogams:
o,"mysource"
Expected: Source is loaded in free tab.
Got instead: Crash

XXX #15B [editor/io] When loading a corrupted file, "he" written instead of "checksum error"

Fixed 12 Apr 2023 in org-gb.o (Beta I). I was just using the bad error code.

There one checksum by &100-chunk in ".o" file!
Maybe my sd card is garbage, but I recently got one corruption detected by those checksums.
Expected: "Checksum error. File is corrupted"
Got instead: "He"

#15A [minor] Internal assertions may leave Orgams in a bad state.

Minor bug since:

• Such assertions are very rare now.
• If they are due to memory corruption, there is little we can do anyway.

Orgams is packed with tons of assertions checking everything is as expected.
An inconsistency indicates a memory corruption (rare) or a bug in orgams (also rare).
In that case, it triggers a breakpoint (call to &BE00, as you would do as a user), jumping in the debuggeur, so you can take a screenshot and send it to the author-ities.

Now exiting the debuggeur becomes funky.
As a reminder, the memory can be in two states:

• user (like when your program is executed)
• orgams (for the tool itself to function! user-memory is mirrored, so that when you dump memory you see your stuff like from an emulator, not orgams internals).

When orgams breakpoint itself, you could argue it's both user and orgams state (since orgams becomes the program under observation).
Maybe you're confused. Well i was as confused as you, and didn't handle this corner case.
It means that when you return from the debuggeur, a switch is wrongly done, and orgams is using your memory state (e.g. music called from &38), which can severely impair its function.

WORKAROUND: When an assertion happens:

• Take a screenshot (please)
• Reset
• Re-enter orgarms via |o
• Save your source under a new name and/or export it (safer)
• Restart from scratch via |orgams

Solutions:

• Orgams could track whether it is being executed, and debugger would handle this case.
• Better: instead of calling the generic breakpoint, call a dedicated routine which does the right thing, possibly reporting more useful info.

XXX #159 [monagams/rsx] Unsafe return from RSX

Fixed 13 Apr 2023 in rsx4.o for Beta I. See solution below.

To reproduce (with unidos):

|cat
|cat

The second |cat triggers an exception (jumping in the debuggeur)

Reason

The |CAT RSX use some memory around 9d00 (in my case, since HIMEM = ~A200), which overwrite some Orgams internal stuff.
The second time, Orgams detects that its internal are gone, hence raise an exception.

Solution

Before running an RSX, we must restore user memory, like when returning to BASIC.
After, we must follow the same path than |m (basic to monagams). Well, maybe not the full blown re-installation, as it could make simple RSX (|a, |CD) slugish.

Real reason

As it turn out, I'm not entirely clueless, and I was already doing the swapping mechanism.
But I was trying to pass register C via an helper far_call which in turn used 1B (hence overwritting C for the ROM number).
So, xx00 bytes were saved instead of &2000, XX being the ORGAMS.ROM number (ridiculous !).
The downfall of having additional layers and lack of API validation.
As long as RSX weren't using (too much) memory, it wasn't an issue.

Real solution

Use the non-firmware far_call equivalent.

XXX #158 Source not flagged as modified with 'hh' command.

Fixed 12 Apr 2023 (FF Beta I), in cache vB, org vFY, ed vBRAQ. Simpler code! Also fix related bug "CONTROL-ESPACE to insert/remove BRK doesn't flag source as modified"

To reproduce:

CONTROL-N  (or SAVE, so that we clear 'modified' flag.)
ESC
hh10,10
ESC

Expected: Modified flag (the * before the filename).

Reason: 'hh' calls org_insert_line to inject data bytes, so the editor doesn't know anything has changed.
Solution: Let 'ORG.O' codec track modified status instead. It already does it to know when to re-assemble.
So we would have 2 flags, both set whenever a change is made, and:

• One is reset when assembling.
• One is reset when saving.

Concretely:

We already had a flag 'up_to_date'.
1/ We rename it to up_to_date_since_assembly
2/ We introduce:   up_to_date_since_save
Now that's a new variable, where to put it in memory?
Well, it has a similar role than the existing one.
They must be handled together (for instance, when switching source, both variables must be stored/restored).
In other worlds, they are persistent variables associated with source, rather than global variables or temporary work variables.
Object-oriented people can see them as fields attached to the source object. 
For this reason they are defined in the codec module ORG.O
There are checks to ensure added variables doesn't overwrite existing ones.

Now, you might assume that a modification since last assembling implies a modification since last saving. 
There is a subtlety here. The 'set_modified' from the cache module force re-assembling, and it is used by the import module to handle a tricky case of diamond import.
Bottom-line: we may want to flag the code as modified to force assembling, but we don't we to flag the source as modified from an UI point of view.
Properly handling this also fix bug#144.

XXX #157 [Monogams] Garbage line after firmware scroll.

Fixed 12 Apr 2023 FF beta I (mon-br? and rsx3). The final NewLine didn't clear the scrolled line, apparently. Since this NL wasn't necessary anyway (i.e. useless blankline after e.g. |a), removing it solved the issue. Plus, the flickering was removed by re-enabling status bar *after* converting back firmware offset to orgams offset, as one would expect.

Thanks Offset!

To reproduce: |dir to make screen scroll.
At return, offset flickers and a random line is displayed.

XXX #156 [Completion/ED] Previous list shown when no candidate.

Fixed 10 Apr 2023 FF Beta I in ED (vBRAM). We didn't check if refresh_suggestions returned NC (no suggestion).

To reproduce (in big source), type the first letter of existing labels (e.g. 'e' for 'eval' 'elasped'….),
then TAB (those labels are shown) and then a second letter corresponding to no label.
Instead of erasing the candidates, they are all shown in bold.

XXX #155 [MOD Arithmetic] -4 % 4 gives -4 instead of 0.

Fixed 03 Jan 2024 in asseva-n (FF Release).

Related but less serious that bug #126.
Weird i didn't think to test such a case.

XXX #154 [Assembly] Code not assembled in C000

Was introduced in FF Beta E. Fixed 18 June 2022 in FF Beta G (problem in mirror correction. +&40 was replaced by res/set, which doesn't work for 8000->C000 correction).

This happens when code is overlapping BFXX-C0XX.

To reproduce:

    org &bffc
    ld hl,(&c000)
  3 ** BRK

Then CONTROL-2.
Expected: HL = F7F7
Got: HL = 0000

XXX #153 [Editor/Open] Breakboint triggered when file not found.

Introduced in FF beta D. Fixed 18 June 2022 in FF beta G (some assertion about loaded source not being cached assembly-wise, was invalid when actually not source was loaded!).

To reproduce:

• Load/create a source.
• open a non existing source in the same tab.
• Return to editor.

A breakpoint is then triggered (so ogrsam switches to debuggeur).
Expected: no breakpoint!

XXX #152 [Assembly/LOAD] Files non reloaded if source haven't changed.

Bug introduced in FF (with cache). Fixed 18 June 2022 in FF beta G (force flag 'modified').

CONTROL-5 and CONTROL-6 are meant to force reloading of all files (LOAD directive).
It doesn't work if source wasn't changed, as cache is used instead.

Solution: Force reassembling with CONTROL-5 / 6 (needed anyway, e.g. if loaded files' lengths have changed).

XXX #14c [Assembly] MAJOR! LOAD"myfile" incomplete when overlapping &8000.

Fixed in mirror-r.o. A slightly different code was used for 7fxx-80xx overlap, which reconnected dest bank rather than source bank. Ouch!
Fix available in FF Beta E.

To reproduce:

   org &7f00
   load "myfile"  ; binary file with size e.g. &400.

Expected: the whole file loaded.
Got instead: truncated at &80e0.

XXX #14a [Monogams UI] Garbage in status bar after first assembly.

Fixed 16 Apr 2023. There was a residual wait state before cleaning, meant for CED logo!

Happened with reswrit.o, control-1, ESC

XXX #148 [Import] Embarrassing. Some ghosts labels might shadow valid labels.

Fixed 23 April 2022 in impeva-9, available in FF Beta D. Skip source when existing undefined label (aka ghost), not only unknown label.

To reproduce:

• A imports B and C, which both define a label "facheux". When A uses "facheux", the error "import: ambiguous label" is raised. That is normal.
• Now if you remove "facheux" in C, the label is still in the table (for a dubious internal reason: label table is append-only, to simplify code).

That led to "ambiguous label" to still pop-up, or (depending on Orgams version) "undefined label" because the version in C (indeed no more defined) would overwrite the valid one picked from B.

Solution: Skip undefined labels in imported label resolution.

XXX #147 [Import] MAJOR Assembly error in transitive import not reported?

Fixed in Beta D. Covered by 128 tests (test_remove_error and test_remove_error2). I think it the same cause than bug#149.

Instead of displaying the error, a zero-length code is assembled. Hence CONTROL-2 would crash.

XXX #146 [Import] Labels seen transitively. Leads to "Import: Ambiguous label" at assembly time in diamond configuration.

Fixed 22 April 2022 in asseva-c + impeva-9. Flag imported/lifted labels as such (asseva) + skip them (impeva).

In the following import chain X -> Y -> Z, X can seen the labels of Y (fortunately!) but shouldn't be able to see Z's labels.
Motivation:
- The fact that Y imports Z is an implementation detail of Y. We don't want to rely on that.
- It becomes more complicated to see where the labels come from (especially since CONTROL-ENTER doesn't work yet cross sources).

Yet, when Y is assembled, the used Z-labels are pulled into Y's symbol table (for efficiency reason, so we don't have to resolve at each occurence).
Such used label become them visible.

The real problem is when X imports Z to explicitly use it.
Then the label is seen from 2 import chains, which trigger the "ambiguous label" error.

Workaround. Well, temporarily rely on transitivity and don't import "Z" directly.

Real Solution: Prevent transitive visibility.
- Flag pulled labels as such, so they are not considered for resolution coming from host.

#145 [Editor] Imported files -> wrong pre-filled file name.

See also #144 below.

If A imports B, when we switch to tab with B and do CONTROL-O, it pre-fill name with "A".
It would be more consistent to pre-fill with the current source name ("B").

XXX #144 [Editor] Imported files are shown as modified in the editor.

Fixed 12 Apr 2023 (FF Beta I), alongside with bug #158

See also #145 above.

IMPORT directive loads source in free tabs inside the editor.
When you switch to them (CONTROL-f2 etc), they are shown as modified (e.g. f2:*psg.o)
Since they are freshly loaded, it shouldn't be the case.

#143 [Assembleur] LOAD directive: header-less files should be loaded.

When LOAD"myfile" is used with an "ASCII" files, nothing happen (since real length is not known).
At least, we should issue a warning.
The right solution would be to load the file:

• As text (e.g. until &)
• As binary (using physical length in this case)

Think of a syntax to discriminate the two. Same as BASIC?

   LOAD "myfile",a  ; interpreted as text
   LOAD "myfile",b  ; interpreted as binary (may have garbage at the end, when AMSDOS is used)

XXX #142 [Debuggueur] CONTROL-B in the debuggeur make it crash.

Fixed May 7th 2023 (FF Release) in trui vAI. It was a residual shortcut for internal debugging!

The shortcut isn't defiined (shouldn't do anything!).

#141 [Assembling] "reload" (CONTROL-5) not taken into account if source not changed.

When source have already been assembled, CONTROL-5 would use the cached version, hence not redoing any LOAD"myfile" directive.
Workaround: add a dummy line or comment. Or even just a space!

XXX #140 [Import] Regression! Changed imported files might not be reassembled.

Introduced yesterday in FF BetaB. Fixed in FF BetaC. Tracking of deps was broken for transitive import (A->B->C). Don't use "global" variable for recursive behaviour.

Wrongly using cached version. The host won't incorporate changes in imported files.
Introduced in FF beta B?

XXX #13f [Import] May re-assemble even when not necessary.

Fixed 21 April 2022 in cache-8.o (available in orgams beta D). Was copying va_pre_pc in a temp variable -> didn't play well with recursion. What can I do to avoid this kind of mistakes?

Minor issue. In some rare configurations (involving transitive import), it might re-assemble instead of using cached version.
That doesn't change anything, just a bit longer.

#13e [Import] Filename comparison is too strict (not Amsdos compatible).

Case sensitivity fixed (was a bug regarding last char, I wrongly assumed djnz changed Z, as the name would suggest). Available in FF beta B.
TODO: normalize by removing trailing spaces.

When importing "GONCHO.O", Orgams checks if the source is already open in one tab, and take this version if found.
That allows to edit GONCHO.O and have the modifications immediately taken up in the host source, even if no source were saved.
That's faster for testing and more intuitive (no risk to have a modification not taken into account).

But… If the file was already opened in lowercase ("goncho.o"), the filename comparaison fails, and then it is loaded again in another TAB.
Similar thing with additional spaces ("goncho .o") -> no match, although for amsdos it represents the same file.

Expected: same rules as amsdos for comparison. That is, case insensitive and trailing spaces skipped.

Thanks Hicks!

XXX #13d [Editor] Tab in invalid state after import not found.

Fixed 30 Dec 2023 (ed-brbg org-gp). Ed's init must be called for new source, even when not triggered by ed itself. Available in release FF

To reproduce:

  import "dfasdfa" ; source doesn't exist

CONTROL-1: Try to import in tab 2
CONTROL-f2: Switch to tab 2.
Got: Not line numbers#, curseur might be in arbitrary line (same line than in tab 1).
Expected: Valid empty tab with just 1 blank line.
Workaround: CONTROL-N set things right.

XXX #13c [Editor/minor] In rare cases, suggestion not properly cleaned.

Doublon #156.

To reproduce:

• open assnrt.o (i was unable to reproduce from scratch)
• type "i" then tab -> a lot of labels are proposed (inRom iotest_screen…)
• type "s" -> No labels match, but only the two first chars are cleared, and the rest shown in bold

XXX #13b [Monogams] Artefacts when label not found in current source.

Duplicate of #167.

To reproduce:
In tab1:

IMPORT "B"

In tab2: just save as "B"

• CONTROL-F1 (go back to tab 1)
• CONTROL-1 (assemble)
• ESC (goto to monogams)
• ?aline (ask value of inexistent label)

Expected: Just "label not found" printed.
Got: Garbage in status bar.

(Garbage happens when

XXX #13a [IMPORT] Wrong cache behaviour with "generating diamond" configuration.

Fixed 06 Feb 2022 in import-bu. Solution: "visited = visited OR deps" (i.e. deps are properly flagged as visited even when cache is used). Available in FF alpha A.

When a source D is IMPORTed twice, the expected behaviour is to skip the second instance.
That only matters when D actually generates code.

Consider a source A importing B and C.
Now, if B imports the first instance of D and C the second one D.
All works as expected, until we assemble once and then modify A and C.
Then, the cache version of B is used (which is expected).
That implies we don't explicitly visit D, so it is reintroduced by C.
So, even no-op changes (e.g. adding a comment) would lead to a different binary produced.
That's very bad.

Explanation:

• To keep track whether an import was met earlier, a 'visited' data structure is maintained.
• But when B's cache version was used, the flag for D wasn't set.

XXX #139 [IMPORT] Wrong cache behaviour when manually assembling an imported source.

Fixed 30 March 2022. Available in FF betaB.

To reproduce:

• In tab 1

  org &2000
  word $
   import "B"
  word $

• In tab 2

  word $

Then:

• CONTROL-S B ESC (to name the file just 'B' without saving it)
• CONTROL-f1 (go back to tab 1)
• CONTROL-1 (assemble)
• CONTROL-f2 (tab 2)
• ENTER (add a dummy line so the cache is invalidated)
• CONTROL-1 (the source is assembled as default address &9000)
• ESC CLP RETURN (clear memory under monogams)
• ESC (go back to editor)
• CONTROL-f1 (tab1)
• CONTROL-1 (reassemble)

Got in &2000: 00 20 00 00 04 20
Expected:    00 20 02 20 04 20
Got in &9000 : 00 90
Expected: nothing

The &9000 version was wrongly used.
Normally, the cached version stores at which address it was assembled, to precisely avoid this kind of confusion.
But it's only refreshed when import is used, not for manual assembly.

No that wasn't the issue.
The cache is considered valid since both host source and imported source are considered up-to-date.
When A depends on B, we need to indicate on A->B edge (*) what was the last used address.
Note: even with several version of B caches (indexed by start address), we need this index. Also, we would need one symbol table by start address (see below).
(*) Either:

• dedicated data structure.
• at reference point in code-store (this latter works well for no-emitting import? !! No -> doens't fix label dependent on $/$$).

XXX #137 [Import] MAJOR PROBLEM. No assembly when unnamed tab + IF.

Fixed 06 Feb 2022 in import-t (restore vo_phase_backup as well). Available in FF beta A.

To reproduce:

Tab 1: A.O

   IMPORT "B.O"
   IF 1
     BYTE "K"
   END

Tab 2: B.O

    BYTE "O"

Tab 3: Unnamed, can be empty or not.

Asssemble once, then add a blank line in tab 1, and re-assemble so the cache is used for B.

Expected: "OK"
Got: "O"

Explanation:
1. IMPORT directive checks all the tabs to find the import (or a free slot).
2. Free slot detection is done by checking number of lines is 0.
3. Lines# computation switch to phase 0.
4. The phase was hence saved. But va_phase_backup wasn't
5. va_phase_backup was read back by IF directive -> phase 0 instead of 1 or 2.

XXX #135 [Import] Assertion triggered with 2 successive imports.

Cannot reproduce! Maybe a neutrino.

XXX #134 [Import] MAJOR PROBLEM. Diamond imports not properly handled.

Fixed 8 Dec 2021 in import-s (track visited sources). Available in FF Beta 10.

That a big issue, since it fails even when the source imported twice only contains constant.
See assnrt.o / nrtdiaa2 to reproduce.

Cause:
With those dependencies:
S -> T -> X
S -> U -> X
When X doesn't even generate code.

I.e. S is main source, dependency graph (left to right):

  T
 / \
S   X
 \ /
  U

The following assembly flow is happening.

• Phase 1: X is first reached (via T) with $Start = X1
  • We assemble X. $End = X1 (same than
• Phase 1: X is then reached (via U) with $Start = X2
  • We re-assemble X since $Start != Cached $Start (this is needed

- Phase 2 :

#133 [Import] Far too slow when imported file has many labels.

Using import might be a bit slower than monolithic equivalent.
This is mitigated by the fact than the imported file are just assembled once,
and then the cache version is used.
At the end of the day, this may add one or two seconds typically.

But when the imported file has many labels, (e.g ED.O with ~555 labels), it adds ~50 seconds.

Suspects:

• Source switching.
• Label resolution.

Workarounds:

• Have fewer labels (e.g. by reusing the same names for local labels).
• Have a deeper hierarchy. The imported file B should mainly have the labels it wants to expose to the host A. All other private stuff (helper routines, internal constants and variables) should be extracted in another source C. B would then import C. In that case, C isn't seen be A, making label resolution must faster. That's also neater as an organisation.

TODO (mdr) for profiling: add counters for each label resolution, at host level, and when digging into imported sources.

XXX #132 [Import/UI - Minor] No proper scrolling when more than 7 imports.

Fixed together for #131

When 8 files or more are imported, the loading messages reach the end of the screen.
Instead of scrolling, it loops at incongruous place.

XXX #131 [Import/UI - Minor] Orgams and Amsdos message mixed-up in case of error.

Fixed May 4th 2023. Update ch.o, impexp.o. Introduce txtfirm to ensure firmware cursor is in sync with internal (disp.o) one.

When an imported file is not found, the messages overwrite each other.
This is not very critical, because it is soon replaced by the nice status screen,
but that's not serious.

XXX #130 [Editor/Ergonomics] CONTROL-O / CONTROL-S, after ESC, filename is overwritten.

Fixed 20 Nov 2021 in ed-brah. Available in ff alpha 8c.

Bug as old as Orgams itself.

Note1: for CONTROL-S, if filename was empty, that's actually nice.
Note2: same as #12F's note.

XXX #12F [Editor/Ergonomics] When file not found, filename is overwritten.

Fixed 20 Nov 2021 in ed-brah. Available in ff alpha 8c.

Bug as old as Orgams itself.

To reproduce:

• Have a named source loaded (e.g. DEMO.O
• CONTROL-O to load an invalid or unexisting one (e.g. __niet).
• It should show 'invalid command' or 'file not found'
• The previous source is still here

Then:

• Expected:
• Got instead:

Note: Retrying CONTROL-O should give back the entered name __niet.
Rationale: sometimes we try to open a file but we are on wrong drive/directory.
After fixing the drive/directory, we don't want to re-enter the name.
Idem if it was just a small typo.

XXX #12E [Editor/Save] Breakpoint when disc error is met while savings labels (LBLs phase).

Fixed 16 Nov 2021 (FF alpha 8c).

That's an old bug. Happens for instance when disc full met just when writing the label section of the .O.
For some reason, a debugging hook was still here.

XXX #12D [Editor/Auto-completion/Fred] Suggestion still creeping in (in another corner case).

Introduced in alpha8a (since not auto-completion before!).—

Fixed 29 Nov 2021 (FF alpha 10). If LINE_ED=0, don't trigger completion.

This is not the same bug than #128.
To reproduce, type this in the editor:

ab     (then RETURN)
;--a   (then ARROW UP)

Le curseur se retrouve donc en line 1, colonne 5.
Presse TAB.
Expected: Nothing (or 'searching…' displayed very quickly before being erase)
Got instead: 'ab' dans la ligne de suggestion.

Cause: Le buffer ligne contient BYTE "AB",0 mais aussi le residue du buffer precedent (BYTE "a",0).
La routine de suggestion

Solution: Dans la routine de gestion de la touche TAB, on doit appeler search_next dans les cas suivants:

• Si la ligne n'est pas modifiee.
• Si le curseur est apres le marquer de fin de buffer (c'est-a-dire, le premier 00).

Il suffit de tester un de ces cas (le premier fera l'affaire).

XXX #12C [Editor/Auto-completion] Doesn't respect "."

Duplicate of #124

If there is a local label (e.g. ".loop"), you can autocomplete "loop".
If you explicitly enter ".", the suggestions should only come from local labels.

XXX #12B [BRK] Bank not detected first time BRK is invoked.

Fixed 06 Mov 2021 in BRK-B.O (FF alpha8b):
The bank detection was properly working, but only stored the MMR value itself (e.g. &c6).
Since we extended the reg_mmr to contains the full connexion id (e.g. 7dc6 to support > 512K mem in the future),
the &7f (default) was missing.
At a latter stage, a sanity check validate the whole ID, and set the default &7fc0 if incorrect.
That explain why it was working with the subsequent BRK invocations (persistent &7f still here).

To reproduce

   ld bc,&7fc6:out (c),c
   BRK
; + CONTROL-2

Expected: Bank C6 detected.
Got instead: Bank C0.

Thanks Ast!

XXX #12A [Editor/Auto-completion/Fred] Ligne non modifiee apres validation suggestion.

Fixed 06 Nov 2021 alpha8b. Apparently it could only be reproduce in conjonction with #128.
Since #128 is fixed, cannot reproduce at all.

To reproduce:

label1
l + TAB + CURSOR RIGHT 
CONTROL-1

"Label1" est bien affiche apres la validation par CURSOR RIGHT.
Au retour a l'editeur, le curseur est a la bonne position, mais le label manque.

Il doit manquer un `call set_modifed`:)

#129 [Editor/Auto-completion] Ghosts labels are shown.

When labels are entered then deleted (because of typo or else), they are still in the internal label store.
Those are "ghost labels".

Sadly (even for halloween) there are suggested for auto-completion.

Workaround: export + import your source to get rid of current ghost labels (also, it's always nice to have a backup in ascii form).
Solution: expose a routine is_ghost, and skip the ID le cas echeant.
Note: that routine will rely on "used" and "defined" flags associated for each label.

Used | Def | Type
Yes  | Yes | Typical label
Yes  | No  | Case of 'undefined label error'
No  | Yes | Dead label / bookmark (a label is defined, but never used).
No  | No  | Ghost label

But those flags are set as asm phase 1.
So the routine will give false negative until first assembly.

For a complete proper behaviour, we'll either need:

• A/ To run phase 1 as a background task.
• B/ To clean up ghosts labels. Well, for that either A/ is needed, or a potential long scan.

ARGGLL!! What about labels in 'if 0' section? They would be wrongly discarded.

XXX #128 [Editor/Auto-completion] Suggestion still creeping in (halloween bug).

Fixed 06 Nov 2021 alpha8b. ed-braf: call SuggestionsOff in quitLine.

Introduce dans alpha8a (since not auto-complete before!).

Suggestion not properly cleared when we quit line.
That's even worse when we quit editor and come back in, since cursor right would insert a label,
despite nothing displayed.

XXX #127 [Assembler] Wrong last address (hence wrong binary size) when skip.

Fixed 1st June 2022. Available in FF beta F. SKIP was reusing same routine as LOAD (which updates range hi-low), instead of non-updating routine like BYTE and WORD.

SKIP must work like non-emitting BYTE or WORD

To reproduce:

    org &2000
  ld a,1
    org &3000
my_var1 BYTE
my_var2 SKIP 3

After CONTROL-1:

• Expected: Last = &2001, Size = 2
• Got instead: Last = &3003, Size = &1004

Workaround

my_var2  3 ** BYTE  ; Works as expected.

XXX #126 [Assembler] Wrong MOD calculation with negative numbers and modulo >= &8000.

Fixed 10/10 2021 in asseva-e.o (FF alpha 8). Root cause: in `a % b` we saved `b` for neg->pos post-correction. Then `divide_com` was normalising it: saved `b` dangling.

Bug as old as orgasm!

To reproduce:

|m
?-4 % &8000

• Expected: &7ffc (32764)
• Got: &fffe (-2)

XXX #125 [Assembler Stress test] Memory full not reported when if occurs in a middle of a FILL.

Introduced in FF alpha 2 (due to caching mechanism).
Fixed 26 Sep 2021 in FF alpha 8 (ass-do: properly handle error after copy_com).

To reproduce:

• |Org,&c7 ; mimic orgams with just 128k
• ESC
• then:

FILL &4000,0

• CONTROL-1

The assembly fails, but the number of errors is 0.

#124 [Editor] CONTROL-L: explicit search for local label doesn't work.

If you have a local label:

.genere

You can access it as usual with CONTROL+L genere.
But that search can also lead to global labels like genere_texture.
Hence you might want to be more specific and prefix with the dot ".", but then nothing is found.

Related: bug #116

#123 [Editor] Space doesn't come back to editor (random)

After CONTROL-1, typing space too shortly stops the rasters, yet doesn't go back to editor.
You then have to press another time.

XXX #122 [Debugger] Visu source lost with 2 levels of repeats.

Fixed 04 Aug 2024 in ass-fs (GG beta 6), by storing start line of bloc in repetitition structure.

To repeat (thanks ast):

   BRK
   10 ** [
      INC BC
      4 ** INC DE
   ]
   LD HL,1

After stepping 5 times, visu source doesn't go back to start of loop.

The problem: the repeat stack (and macro stack for that matter) doesn't store starting line as line# (just pnt in bank).
An hack was used. Cf cpt_factor_bloc: ld (va_save_line),de.
Hence this address is overwritten.
Possible solutions:

• Use an array instead. Meh
• Re-use factor/macro stack. Meh.
• Better? Don't track line number at this stage! Only call source2line at the end (hum, might complicate incremental computation).

#121 [Display] Lines > 72 characters with errors wrongly display at assembly time.

If a line is both too long (can happen when importing source) and erroneous, it will break coloring (rasters) at status page!

#120 [Editor/Monogams] Tilde '~' cannot be entered on Azerty keyboard.

On azerty you get it with CONTROL-2. In editor, that's the shortcut for Assemble+Jump.
When entering filename (e.g. CONTROL-O) it's inactive.

#11f [Disassembly] Instructions eaten after invalid &dd / &fd.

This bugs seems to be as old as orgams itself.
To reproduce:

   BRK 
  b &fd
    xor c  
    jp hl
   b &dd 
    ld a,0
    xor a
; Then CONTROL-2

Got:

   BYTE &FD
   jp hl
   BYTE &DD
   xor a

Expected:
Both xor c and ld a,0 should be seen!

XXX #11e [Internal] Assert triggered from time to time when switching source.

Fixed 13 Jun 2021 in head-6 (FF alpha6), by reusing cocopy approach. Fix buf ovf and other things!

Not present in release: introduced in FF alpha3.

A bad ID (e.g. FC00) is present as 'next' field in e.g. AAP chunk.
If you get the previous sentence, you are madram.

XXX #11d [IO] Some sources won't load anymore (expect on CubeMDOS!)

Fixed 8 Jun 2021 in org-eg (FF alpha6). The internal checks on io_load_bloc was too strict, since we voluntarily read past the end of file in order to fill a &100-sized buffer.

Not present in release: introduced in FF alpha3.
Some internal checks about IO were added in FF alpha3 (to help investigate an issue with uniDOS).
But we sometimes force reading past the end of file (since we read by ~100 chuncks), depending on the total filesize.
So this triggered the checks!
This bug was hidden by a CubeMDOS bug, which never returns an error past the end, but instead always returns EOF.
See: https://www.cpcwiki.eu/forum/applications/cubeios-fat16fat32-rom-for-the-cpc's-with-xmass/msg203159/#msg203159

Thanks to Ast/Impact for the help.

XXX #11c [IO] Control-I and type command don't return for certains file with CubeMDOS.

Fixed 01 Sep 2021 (FF alpha7) in iov.o. "last line detection" (empty line) was bugged.

Different behaviour past real end of file.
See: https://www.cpcwiki.eu/forum/applications/cubeios-fat16fat32-rom-for-the-cpc's-with-xmass/msg203159/#msg203159

XXX #11B —[Editor/Parser] 'ex(sp),hl' not recognized anymore. XXX

Fixed in FF alpha5 (parse-bp).

It works with a space, but not without, despite the lack of ambiguity.

Only present in FF alpha 4, due to too hasty correction of #11A!

XXX #11A [Editor/Parser] 'exa' wrongly interpreted as 'ex af,af'.

Fixed in parse-bo 3 Jun 2021. Available from FF - alpha 4.

The expension should only occurs if it is unambiguously an opcode. E.g.

  exaf, ; Must expand
  exa   ; Must stay as label
toto exa  ; Must expand
toto exa( ; Stay as macro invocation.

#119 [Trace] Infinite BreakPoint Loop. The return.

When Orgams memory itself is corrupted (by another program), this is usually detected when invoking Orgams.
But that detection isn't performed when a breakpoint occurs.
In that case, one of the assertion may trigger, causing a breakpoint in trace mode -> infinite breakpoints!

Resucee du bug #FB.

Exemple:

• connect_bk_source: inconsistency in vo_curbk.

Call stack:

* visu.glfp_from_start. (which does a call seek_source_begin)
* visu.glfg_gross
* connect_bk_source
* BRK

In summary, the following sequence fails:

  call seek_source_begin
  call connnect_bk_source

#118 [Editeur] Memory full not handled when switching to a new tab.

Basculer vers une toute nouvelle tab (e.g. CONTROL-F9) requiert un peu de memoire.
S'il n'y en a plus du tout, l'editeur commence a suer.
A la place: afficher un message memory full, et rester sur la tab en cours.
Pour reproduire: demander ! (introduire un flag test_low_memory, et brider la memoire expres).

#117 [Editeur/CubeMDos] CWD still displayed when on A:

Introduced if FF alpha 3 (no CWD at all before!)

It falsely suggests we are still on drive D:
NB: |D doesn't update Amsdos drive at ((bc7d)), that's why i didn't bother yet.

#116 [Editeur/Scan] CONTROL-L doesn't work for explicit locals.

• If you search for "loop", you'll find both global and locals starting with "loop" (or ".loop"). That's good.
• If you search for ".loop", you'll find nothing. That's bad.

#115 [Editeur/parseur] ".end" interpreted as directive.

Not exactly a bug, since:

• We must be able to import ASCII sources
• TurboAss uses "." to denote directives
• We cannot know for sure if an ASCII file come from TurboAss

Workarounds:

.Ende
.end_
.fin
.ret
.finito
.finalize
.done
; etc....

Introduced in FF alpha1, (not local label before that, so no clash possible!).

#114 [Editeur] Wrong state after memory full while opening source.

Pour reproduire: ouvrir un gros source dans la version dev (qui n'a que 12k free).
Après le message memory full, l'editeur est dans les choux (pas de numéros de lignes, curseur a la ramasse).

Attention, il ne faut pas 'resetter' de façon indiscriminee quand le OPEN échoue.
Par exemple, pour l'erreur 'file not found', c'est bien pratique de retrouver le source courant.

#113 [Assembler] Too many nested if: neither handled nor detected.

Update GG: only the first 8 IFs are countend, so it will raise a boggus "Unexpected END"

If you nest more than 8 ifs, e.g.

   if toto1
     if toto2
       if toto3
[...] ; 6 more 
       end
     end
   end

they are not respected correctly.
There should be an assembler error instead.

XXX #112 [Monogams] Type command requires both quotes.

Done 19 Apr 2023 (FF Beta I). In parse.o. (You still need the first quote though, like for LOAD, SAVE…)

You must use:

type"readme.txt"

I want to be able to type either:

type"readme.txt
type readme.txt

XXX #111 [Monogams] Type command doesn't stop if no EOF (aka &1a)

Fixed 01 Sep 2021 (FF alpha7) in iov.o. "last line detection" (empty line) was bugged.

You must press ESC/Q.

#110 [Monogams] Type command doesn't handle line bigger than 80 charaters.

They will be overwritten be next line.

XXX #10f' — [Editor] Label navigation doesn't work for local labels.—

Fixed 21 Jan 21 (scan5, findt). Those two must also handle new escape codes!

• CONTROL-ENTER does nothing
• CONTROL-* might trigger assertion.

#10f [Editor] Go to definition (CONTROL-ENTER) confused by local labels.

If there are several local labels with the same name, CONTROL-ENTER pick the first one rather than the right one.
If you press CONTROL-ENTER again, it cycles through the different instances, but that's not satisfying!

This one is though and will require more collaboration between the editor and the assembler (to "understand" the code).

XXX #10e [Orgams] Transition |orgams cahoteuse.

Thanks ast.

XXX #10d [ED/Monogams] Screen shifted if cat scrolls.

Fixed 15 Jan 2021 in ed-brw and upd-scr7. Available in FF alpha 1.

When CAT (CONTROL-C) makes the screen scroll, the wrong offset is set back while waiting for a key.

XXX #10c [Monogams] Amsdos error message in wrong screen location.

Fixed 14 Jan 2021 in monuiap and monay. Available in FF alpha 1

E.g. with rsx |b, disk missing.
Especially after scroll, the screen is shifted.

XXX #10b [Asssembler] LD A,"" randomly introduce spurious error.

01 Jan 2021: Fixed in asseva5.

On top of "empty string" error (expected), an overflow was sometimes reported.

XXX #10a [Monogams] ?"A" shows &9000 instead of &41

02 Jan 2021: Fixed in evacomd. Distinguish rsx command from others.

Was introduced in EE with RSX handling.

XXX #109 [Trace/Visu] Wrong source line in visu mode when repeat block spans over several chunks.

17 Dec 2020: Fixed in asscm.O

Flags and internal variables must only be set at first iteration, not for each one.
Cf test_repeat_cross_chunk
I thought I already fixed this one (bug #C0a).

#108 [Trace/Visu] Wrong source line in visu mode when out of order ORGs.

Avatar of bug #C0.
Points to some line with ORG directive rather than BRK line.
Workaround: make sure ORG directives are increasing.

Will confuse trace visu:

 org &1000
[...]
 org &4000
[...]
 org &2000
[...]

This order is fine and healthier anyway:

 org &1000
[...]
 org &2000
[...]
 org &4000
[...]

XXX #107 [Editor] Wrong line# displayed after copy/del block.

Fixed 31 Dec 2020 in ed-brv.o and status3.o:

• After copy, no need to refresh.
• After del, use POS_LINE rather than internal line pointer (out of sync).

Introduced in EE-F? (some point after status bar).

To reproduce: select bloc >= 2 lines.
COPY-C: show last line rather than current line.

#106 BRK doesn't always capture right bank connection (MMR).

This is a bug as old as Orgams itself! That is a known limitation due to the heuristic of detection mechanism.

• Special mappings (e.g. C1, C2, C3, …) aren't detected.
• Bank will be mixied up if they have the same content in some addresses.

NB: Starting with EE BetaJ, when a Multiface II is plugged and visible, the capture is exact for all 7Fxx connections.

#105b BRK doesn't capture ROM connection when VGA is used.

To reproduce:

    di
    ld bc,&df0c:out (c),c
    ld bc,&7f86:out (c),c
  BRK

Expected: ROM &0C connected.
Got: Previous Upper ROM connection (RAM, typically).

NB: This bug is unlikely to be solved anytime soon.

XXX #105a BRK doesn't capture ROM connection when firmware is used.

Fixed 14 May 2020 in brk4.o (BetaJ).

To reproduce:

    ld c,12:call &b90f
  BRK

Expected: ROM &0C connected.
Got: Previous Upper ROM connection (RAM, typically).

XXX #104b R register not properly restored after breakpoint

Fixed 17 Mai 2020 (EE beta J)

To reproduce:

   xor a:ld r,a
      BRK
   ld a,r
      BRK

Then

• Expected: a = 2 at second breakpoint
• Got: shifted value

XXX #104a R register not properly captured at break time.

Fixed in brk3.o (EE beta I).

To reproduce:

   ld a,&80:ld r,a:BRK

• Expected: R = &80 in trace screen
• Got: Another value.

XXX #103 Cursor disappears after DEL on first column

Fixed in ed-brt (EE beta I).

Pour reproduire. ENTER puis DEL!

XXX #102 SHIFT-DEL may show garbage

Introduced in EE Beta H (shortcut was inactive before that).
Fixed in EE Beta I.

To reproduce: right arrow, SHIFT-DEL.

#101c [Trace] Trace -> Monogams crashes in particular condition. Part c.

If firmware is trashed in user program, it makes it hard to recover from Basic.

To reproduce:

  FILL &2B00,&F0
CONTROL-1
CONTROL-SHIFT-ESC
call &be00
ESC

#101b [Trace] Trace -> Monogams crashes in particular condition. Part b.

If firmware is trashed in user program, it makes it hard to recover from Basic.

To reproduce:

  FILL &2B00,&F0
CONTROL-1
ESC
CONTROL-B
call &be00
ESC

XXX #101 [Trace] Trace -> Monogams crashes outside Orgams context.

Fixed in EE betaH, but for avatars #101b & #101c

E.G. when there is a BRK in a ROM program launched from BASIC.
Probable cause: incomplete setup?

• |orgams (complete init, erase all sources)
• CTRL-B
• call &30
• ESC -> crash.

#100 [Editeur/Fred] Bénin. Si COPY-DEL de tout le source, 0 ligne.

Pour reproduire sur source vide: COPY-S, COPY-E, COPY-DEL, Y.

• statut affiche 1 / 0
• pas de numéro de ligne affiché.

NB: Ne pas introduire de nouveau code !! Au pire, factoriser avec le test fait dans C_DEL.

XXX #FF [Assembler] Wrong error message

Status: cannot reproduce.

Introduced in EE.

To reproduce:

   skip leprous - $

• Expected: Undefined label.
• Got: Overflow 16 bit.

XXX #FE [Editeur/Fred] Clignotement pour |o,"toto"

Was fixed long ago.

La barre status apparaît pour disparaître aussitôt.
NB: La barre status doit être activée, mais seulement si on pose la question "Source modified, Continue? …"

XXX #FD [Editeur/Fred] Buffer fantôme avec SHIFT-DEL.

Introduced in EE-Beta?
Fixed in EE-BetaH via todo #BE!

Pour reproduire, saisir:

;abcde
;ab

Aller sur le c, SHIFT-DEL, flèche bas, SHIFT-DEL, flèche haut
Expected:

• 2ème ligne vide

Instead:

• 2ème ligne contient aussi "de"!

MERCI DE RESOUDRE LE TODO #BE AVANT CE BUG.
(il est possible que le TODO #߀ résolve ce bug tout seul, une pierre de coup)

#FC [Monogams] CLP doesn't take bank MSB into account.

To reproduce:

b&7ec2
CLP
m0  ou gr

&7fc2 is cleared instead of built-in CPC-RAM.

Workaround: Clear your banks with code instead!

XXX #FB [Brk] Endless Breakpoint loop: cannot access the trace debugger.

Good as of 2020 Dec 31. Verified by AST!

• One instance fixed in EE Beta G
• One instance fixed in EE Beta H (truiad.o)

Introduced in EE Beta E.

A breakpoint is triggered in the trace itself => infinite loop.

Possible causes:

• Bank corrupted. So an assertion is triggered (especially for source visu).
• Incomplete setup (if BRK used outside Orgams).

XXX #FA [Editor] Import may hang/crash when trying to import binary.

Fixed long ago.

Even if the binary has been renamed "toto.txt".
Thanks Hicks!

XXX #F9 [Editor] Spurious opcode displayed.

Introduced in EE beta D, fixed in EE beta E.

A incongruous opcode can appear (it's just a display issue, it's not assembled and the source remains ok).
To reproduce, wait for full moon, then

yes
     IF yes

Go back to first line first column, CTRL-*, right.

#F8 [Editor] Modification lost when reset.

If you start writing a line and reset before validating, the line is lost.
That's a bug as old as Orgams.

XXX #F7 [Ass] Spurious error when label undefined (introduced in EE)

Fixed 19 Jan 2020 in Ass BZ. Forgot one call in refactoring, wasn't covered by tests. Now it is.

To reproduce:

   call titi  ; titi not definied

• Expected: Only 'Undefined label' error.
• Got: Also 'Overflow 16 bits' error.

XXX #F6 [Ass] Assemblage crashes with BYTE "" (introduced in EE)

Fixed 24 Dec 2019 in asseva2. -> Beta C.

#F5 [Editor/Madram] CONTROL-ENTER does not work for macro parameters

To reproduce:

MACRO EGG x
   ld a,x  ; <- CONTROL-ENTER here does nothing instead of going to x declaration.
ENDM

#F4 [Editor/Madram] CONTROL-ENTER may not work for `; call routine ; toto titi `

When `call`, `toto` or `titi` are ghost labels, CONTROL-ENTER fails to jump to routine.
Workaround: put cursor on `routine`.

#F3 [Trace] Current call stack frame not saved at exit.

To reproduce:
* BRK into nested calls.
* 'u' would go to caller.
* ESC + D -> Youngest callee is highlighted instead.

#F2 [Editor/Madram] 'label empty' shown when opening a source [IMPDOS only?]

Spurious warning. Shouldn't impact anything. Thanks Ast!

#F1 [Editor/Fred] Copy-paste ne devrait pas valider la ligne.

C'est gênant quand on fait ça en cours d'édition.
Pour reproduire:

• Entrer ld bc(
• CTRL-DEL, CTRL-P

• Résultat attendu: La ligne est recopiée tel quelle.
• Résultat courant: La ligne est interprétée ld bc() (label + macro !)

XXX #F0 [Trans-module] CRTC screen transitions are too chaotic.

Good as of 31 dec 2020.

Todo:

• Screen without status bar should remains at the same position (c.f. CTRL-C or RSX in monogams).
• Don't use intermediate transitions.

#EF [Monagams] Wrong evaluation order of parameters.

To reproduce: ?1,2 shows 2 then 1.

#EE [Monagams] Logo screen may be instable with PlayCity.

Experienced by Ast on Amstrad Pus.

XXX #ED [Font] "," shaded is shown as "."

Fixed 21 Dec 2019.

XXX #EC [Editor] Nagivation (up/down) is slower (introduced in EE beta6).

Fixed in EE beta F.

XXX #EB [Trace] Some bytes are corrupted (introduced in EE beta4).

Fixed 7 Aug 2019 in truic and findh.

When visualizing source with if/then/else in trace, bytes 98D0 to 98FF could be overwritten.

XXX #EA [Editor/Madram] Error state not reseted in export.

Fixed 7 Aug 2019 in impexp3. (disc_out_close not enought to clear the error? disc_out_abandon did the trick).

To reproduce: Export a file in a full disk, then try on an empty one.

• Problem 1: Wrong error message (cf #BA).
• Problem 2: The error "Disc full" continues to pop up.

Workaround: display cat to close the file.

XXX #E9 [Assembler] # outside [ ] might corrupt the source.

This one is fixed in EE. Qué?
Fixed 1 Jan 2021 in asseva6 + tests in assco.
Buffer address wasn't properly restored, so it overwrote the source instead :/

To reproduce:

    macro tt n:fill n,&f7:endm
    tt(#)
    ld hl,#+#

• Issue 1: all the memory is filled (as if n=&10000).
• Issue 2: the source is corrupted.

XXX #E8 [Trace/Disa] (EE) d&a000 crashes if bricbrac not in rom 9.

Fixed 20/07/2019 in mirrorF. The rom# was hardcoded, wth?

Reported by AST (Thanks!). To reproduce: CTRL-H in monogams (no display) and d&a000 (crashes sometimes).
It depends on rom locations

Ok: Orgams:10 Orgext:21 Monogams:26 Bricbrac:9
KO: Orgams:10 Orgext:11 Monogams:12 Bricbrac:13 (Default, argl)
KO: Orgams: 9 Orgext:10 Monogams: 8 Bricbrac:13 (Ast)

XXX #E7 [Editor] Export: File not closed when disc full.

Edit: Duplicated in #EA.

It prevents to retry elsewhere.
Current workaroud: CONTROL-C or Reset!

#E6 [Assembler/Begnin] Cannot jr from FFxx to 00xx

To reproduce:

 org &ffff
loop ld (hl),a:inc l
  djnz loop

Expected: Success.
Got: jump out of range.

XXX #E5 [Editor] COPY doesn't behave as a real dead key.

Fixed 11 May 2020 in EE beta H.

For instance, we cannot chain COPY-E, COPY-DEL by maintaining COPY pressed.
We currently have to release it, which is a pity.

XXX #E4 [Orgams] Erasing BRK with CTRL-SPACE correct markers in the wrong direction!

Fixed 27 Jun 2019 in ed-bpal.

XXX #E3 [Orgams] Import doesn't correct history/error markers.

Fixed 27 Jun 2019 in ed-bpal.

#E2 [Orgams] Breakpoint reinstalled when met or when returning from exec..

Orgams allows to assemble from &0000. If you erase &30-&32, you cannot use BRK anymore (the fact that is this not detected is bug #E1),
but you can still call &BE00.
The issue is that then the breakpoint (and the jump at &30) are reinstalled, trashing your own code.

Pour reproduire

  org 0
  fill &33,&AA
  ent $
  call &be00

Then CONTROL-2.
Expected : AA,AA,AA in &30
Got: JP &be00

#E1 [Assembler] Should warn in case of memory conflict.

• When &30-&32 is overwritten and BRK used (actually in this case the assembler could emit CALL &BE00 instead of RST &30).
• When &BE00-&be?? is overwritten and BRK or &BE00 called.
• When stack area is overwritten and RESTORE not used.

XXX #E0 [Trace/visu] Source lines not properly clipped.

Fixed 22 June 2019 in monoz. +Use "\" instead of "$".

Clipped too soon. Also, residual '$' appears.

XXX #DF [Trace] ROM connection not detected at BRK point.

Fixed (duplicate #105a).

To reproduce:

    ld c,4:call &b90f:BRK

The UPPER RAM is still selected instead of ROM 4.

XXX #DEb [Trace] Source not found in some macro corner cases.

Fixed 19 May 2020 (EE beta J, visu7.o). The issue was that macro invocation + end of chunk wrongly set 'emitted' flag.
NB: If code is emitted between X and Y, the bug still manifest itself, for a slightly different reason!

To reproduce:

• Have an initial ORG X (e.g. default one at &9000), but no code emitted until next ORG.
• Have a macro definition spanning over 2 chunks
• Then change ORG to a lower address Y.
• Invoke the macro.

Then source at address between Y and X won't be found in trace.

XXX #DE [Trace] Wrong line source when using macro.

Copain du bug #C0

XXX #DC [Orgams] Error when too much macro invocations.

Fixed Jun 1 2019 in assaj. Macro parameter stack wasn't properly poped.

To reproduce:

   MACRO CUI n:BYTE n:ENDM   ; Useless macro, just for test.
   128 ** CUI(#)

• Expected: proper assemblage (00, 01, 02, … , 7F)
• Got: Args mismatch.

XXX #DB [Orgams] MACRO not expanded in very particular case.

Fixed Jun 1 2019 in assaj. Same root cause than #DC + issue: error reported in phase 2 rather than 1.

The case is so particular I don't know what it is.
Since it only happens in phase2, the subsequent labels are shifted, leading to 'label inconsistency' error.

XXX #DA [Orgams] Bank directive not honored for save

Fixed 29 July 2025 (HH Beta 2).

To reproduce:

   bank &c4
   org &4000
   byte "Piou!"

Then CTRL-1, B, filename.bin
The bytes in C0 are saved instead.

XXX #D9 [Trace] mdump visu not refreshed with ctrl-r / ctrl-e

Fix 28 May 2019 in monou.

To reproduce: m&40, d, CTRL-V if needed.
CTRL-R doesn't refresh the visu. We must navigate to trigger refresh.
Similar issue with ctrl-e.

XXX #D8 [Monogams] Spurious dump at &d0

Fixed. Same cause than D7.

To reproduce: m&40
The dump should skip all zeros. But it displays line &d0 (full of zeros!).

XXX #D7 [Monogams] Wrong first line with gr.

Fixed May 28 2019 in mirrod. Case C = 0 (256) wasn't properly handled.

To reproduce: clp (to make sure 00-ff is cleared), then gr.

• Got: Some pixels on first line.
• Expected: Clear first line.

XXX #D6 [Monogams] Inaccurate plotting with m.

Fixed 28 May 2019 in monot. Simple typo.

To reproduce:

m 64 ** Byte #

Then CTRL-1, ESC, mm

• Got: Wonky line.
• Expected: Straight line.

XXX #D5 [Parser] init interpreted as ini:t()

Fixed 22 May 2019 in parseaq.

Come on!

#D4 [Assembler] MACRO/ENDM and IF/END interleaving not supported.

Not that you would need it.

To reproduce:

   MACRO zub
   IF 1
aa = 1
   ENDM
       zub()
   END
       ld a,aa

Expected: Correct assemblage (3E, 01)
Got instead: Undefined label "ld a,aa"

XXX #D3 [Parser] skip aa-$, crashes the editor.

Fixed 21 May 2018 in parseao (skip seen as macro invocation without resetting vp_output0 which has been changed at ',' trying to parse a new instruction).

Note the trailing comma.
That's not an easter egg.

XXX #D2 [Parser] ld (ix +1),reg wrongly interpreted.

Fixed 19 May 2019 in parsean (ps_eat_space in t_index_shift rule).

Due to the space after ix, it is interpreted as a label. (Merci à Ast).

XXX #D1 [Editor] CTRL-DEL on modified line doesn't properly delete.

Fixed 15 May 2019 in ed-bpaa. Was due to GotoLine factorisation (was calling quitline, validating current buffer).
Introduced 08 May 2019 (Rc1).

To reproduce:

ENTER 
Go back to line 1
;;;;; + CTRL-DEL . (that is, modify the line and immediately delete it)

XXX #D0 [Editor] DEL on very first char (line 1, col 1) wrongly adjust markers.

Fixed 15 May 2019 in ed-bpz. We checked for this corner case too late.

To reproduce:

* Edit line 3
* Go to top (CTRL-f0, CTRL-left)
* DEL
* CTRL-M goes to line 2 instead of 3

XXX #CF [Monogams] Erratics graduations for gr.

Fixed 11 May 2019 in monor. Pressing left when already at C0 corrupted HL.

To reproduce : shift-left several times. Thanks Beb!

XXX #CE [Editeur] Crash pour CONTROL @

Fixed 2nd May 2019 in ed-bpn

Resucée d'un bug déjà rencontré. CONTROL-@ ne correspond à aucun raccourci en particulier, mais renvoie le code 0.
Il y a confusion avec le 0 de la table code->routine qui sert normalement de marqueur fin.
Cela a été corrigé dans la boucle principale, mais pas dans le field_editor.

XXX #CD [Assembler] Macro invocation isn't repeated with inline **.

Fixed: May 1st 2019 in parseak,l,m. Tested in ass1x,1y

Also, the rest of the code isn't properly generated.

  MACRO test n:byte n:ENDM
  3 ** test(#+1)
  byte -1

Expected: 01 02 03 FF
Got: 00

Workaround:

  MACRO test n:byte n:ENDM
  3 ** [ 
     test(#+1)
  ]
  byte -1

XXX #CC [Moniteur] Quand on fait appel à la commande hh et qu'il n'y a aucune ligne de code, le curseur ne peut pas accéder aux lignes du dessous

Pour reproduire:
|orgams
hh#4000,#100
escape (on se trouve en ligne 33 normalement)

• la touche Curseur Up est inopérante

on utilise ctrl+g pour aller en ligne 1 puis impossible de redescendre.
ND-AsT : Ce bug doit être facile à résoudre ; il suffit juste d'initialiser le compteur de ligne qui doit être resté à 0 ou à 1.
17-03-19 : C'est bien une erreur liée au Label TOT_LINE qui n'est pas initialisé correctement lors de la commande hh. (Bank #ff adr #780a-Ob)
Fred: Moi j'ai un petit soucis. Je ne peux pas reproduire car ça fige mon CPC.

XXX #CB [Editeur] Insertion en premier ligne de bloc décale le bloc.

Pour reproduire:

• Sélectionner un bloc
• Se placer à la fin de la première ligne du bloc
• Return

On obtient:
La ligne en question n'est plus dans le bloc!
On aimerait:
Le début du bloc reste tel quel. La fin est décalée pour prendre en compte la nouvelle ligne.

XXX #CA [Editeur] CTRL-P ne décale pas les blocs.

Copain du bug #BC

XXX #C9 [Assembler] May hang when invoking macro with mismatching number of parameters.

Fixed 9 Mar 2019 in ass1v. Bank wasn't reconnected in case of error.

To reproduce, pick a big source (since definition and invocation must sit in distinct banks).
At the beginning:

MACRO PSG var,reg:ENDM .  ; No need for actual instructions to reproduce the bugs

At the end:

     PSG() ; No param

Then, CRTC-1.
Expected:
Error: Macro parameters mismatch.
Got instead:
Assembler frozen.

XXX #C8 [Monogams/Ed] Commande hh n'ajuste pas les lignes dans l'éditeur.

Fixed 10 Mar 2019. ed-bl + monoe

Pour reproduire, définir un bloc (e.g. ligne 10 à 20), placer le curseur avant (ligne 5).
Sous Monogams: hh0, 20. Cela injecte trois dans le source. Les markers bloc (et historique) ne sont pas corrigés.

Le problème est que Monogams appelle directement org_insert_line, de sorte que l'éditeur ne voit pas les modifications.

Todo:

• ED: Exposer une routine edInsertLine prenant en entrée HL = texte. Elle ne prend pas d'autre paramètres. L'insertion se fait à la ligne courante, puis on doit passer à la ligne suivante. curseur doit passer à la ligne suivante (de façon à ce que plusieurs insertions successives se déroulent comme attendu.)
• MON: label hf_line. Remplacer tout le bloc edGetLine# … org_ins_line par un appel à edInsertLine.

XXX #C7 [Monogams] Source corrupted when scrolling!

Fixed 08/03/2019 dans MonoA.

When reaching the bottom of the screen, Monagams starts corrupting memory.
Buffer overflow, for a buffer that wasn't even used! (ASCII save for potentiel refresh. Deluxe version of TODO #2D).

XXX #C6 [Editeur] Ne pas sauter sur des lignes invalides.

Dans certains cas (bug tiers ou metadonnées d'un .O invalides), on essaie de sauter à une ligne supérieure au nombre de lignes total !
Il faut détecter ça et l'interdire. Au choix:

• Sauter à la dernière ligne à la place. (bof)
• Afficher un message d'erreur. (est-ce vraiment utile ?)
• Ne rien faire.

NB: Attention, quand ligne = 0, il faut continuer à ne rien faire.

XXX #C5 [Monogams] Lower ROM not visible

Fixed 28 May 2019 in mirrorc. RST &18 disable L_ROM!

Despite the LROM indication (CONTROL-R switch), m or x command doesn't show the lower rom but the ram instead.
To reproduce:

CONTROL-R (LROM must be displayed)
m&100

We get:
0100: 00 00 00 00 00 00 00 00
Instead of proper firmware opcodes.

XXX #C4 [Assemblage] Expression wrongly expanded in macro

Fixed 07 Mar 2019 in parseAG. The pre-encoding was missing the $ marker to instruct the assembler to store the current value at the beginning of the instruction (the macro invocation isn't an instruction per se).

To reproduce:

    MACRO F n:FILL n,0:ENDM
    ORG &9000
      nop
      F(-$ AND 7)
m

Expected: m = &9008
Result: m = &9007

XXX #C3 [Trace] In a,(n) changes PC!

Fixed 14/03/2019 in TRR. Has never been tested, and HL (= PC) was mixed up with DE (= temporary variable).

To reproduce:

   BRK
    ld a,&f4:in a,(&ff)

Then, N (or S) twice show PC is being changed to a garbage value.

#C2 [Assemblage] Code assembled in &BFCC-&BFFF is overwritten.

To reproduce:

 ORG &BF00
 fill &100,0
 RESTORE

Then, CONTROL-F2

Expected: All zone free.
Got: &bfcc - &bfff used.

Reason: actually this is a routine needed to jump back

XXX #C1 [Monogams] Command history sometimes broken.

Fixed in monob 10 Mar 2019: wrapping handling mistakenly modified current pnt to first entry.

Eg, cursor up doesn't give anything, cursor down pulls garbage.

XXX #C0 [Trace] Wrong line source when using conditional assembling.

Edit 9 June 2019: improved situation in ASSar.O
Edit 20 June 2019: make room in chunk header (ASSas, ORGat).
Fixed 21 June 2019: recover state of 'ifs' (ASSau, ORGau).
Reopen 11 July 2019: still happens in some configurations.
Closed 15 December 2020: Opening dedicated bugs for each instance. See #108.

Prerequisite: #B9

The routine retrieving the line source corresponding to the navigation pointer can be completely lost when IF directive is used.
It leads to either:

• "Source not found"
• An unrelated position in the source.

XXX #BF [Assembler] Erroneous error lines when unordered.

Edit: Fixed 08 Dec 2018 in ass1t. Don't use incremental search!

We previously assumed error lines were ordered. But with macro (cf example below), this is no longer necessarily true.
If 2nd error appears in the source before the 1st one, assembler either:

• repeats the previous error line
• gives a completely wrong one
• hangs

   MACRO m
      ld a,unknown  ; undefined (2nd error met)
   ENDM
      ld a,256  ; 1st error met
      m()

XXX #BE [Editeur/Fred] DEL en première colonne ne fait rien.

DEL en première colonne est censé joindre la ligne avec la précédente,
mais sur certaines lignes, cela reste sans effet.
Edit(fred) je n'arrive pas à reproduire. est-ce possible d'avoir un cas concret ?

Yep,pour reproduire:

lignes:
772 (&304)
515 (&203)
258 (&102)

Un test 16 bits (line == 1) discutable ? :)
OK: ld a,e:dec a:or d:jr nz,notline1
Là ça ressemble plus à du XOR !

Cf diagonale du mail ! (encore ??? Faut que je change de lecteur de mail !)

XXX #BD [Editeur/Fred] CONTROL-RETURN sur ligne effacée = kaboum.

Pour reproduire:

;
CALL TT
TT

En ligne 2, CTRL-ENTER: ça mène en ligne 3. Parfait!
CTRL-RETURN ramène en ligne 2. Tout bon!
Maintenant, effacer la ligne 2 (CTRL-DEL) et de nouveau
CTRL-RETURN: ligne erronée (e.g. 65340)

A corriger par le todo #A6 !

XXX #BC [Editeur/Fred] BRK via CONTROL-SPACE doesn't correct markers (block, errors, …)

To reproduce, select a bloc, and press CONTROL-SPACE above or inside the block.

#BB [Editeur/Madram] very low priority 'DEFS n' from DAMS source not correctly imported.

The one parameter variant of this directive is wrongly converted to 'F' (as fill).
Solution: now that DEFS is correctly parsed, leave it as is.

XXX #BA [Editeur/Madram] Wrong error message instead of "memory full" when importing.

Ok in GG Beta N. Was fixed while fixing other bugs!

If imported file is too big, "unexpected mess" or another buggy message (e.g. "syntax error in 27556) is printed.
To reproduce (with Ayana v0.0ab):

• Assemble plynrt.o
• The assemble gednrt.o

XXX #B9 [Editeur/Madram] Block: must copy all or nothing.

Edit: Fixed 8 Mar 2018 in orgAB. Fix chunks count (nb of chunks used by block as an upper bound of memory needed).

When memory is almost full, block copy may stop in the middle of the copy, leaving the source in a half-baked state.
We should cancel the whole copy in this case (and of course report the Memory full error).

XXX #B8 [Assembler] wrong numbers of parameters for macro: assembler assert failure

24 Apr 2018: Fixed in ass1N (wasn't implemented!)

(obviously absent in Codigo public version)

To reproduce:

    MACRO jeanlouis n
         BYTE "jeanlouis", n
    ENDM

    jeanlouis()    ; fail
    jeanlouis(1, 2)   ; fail

Copain du bug #AD

#B7 [Trace] $ not shown if in middle of instruction.

To reproduce:

   ORG &9000
   BRK
   CALL 0

Then:
CONTROL-2
ESC
$&9002

Since the disassembled opcode start at &9001 != &9002, no $ is shown.
A shaded $ should be displayed instead.

XXX #B6 [Orgams/Internal] Delete doesn't report error in case of invalid line.

Edit: fixed 4 March 2018 in orgAA.o

To reproduce: call org_delete_line with out or range number. Carry shouldn't be set.

NB1: this bug cannot be triggered from the editor.
NB2: current buggy behavior was actually made on purpose, but I cannot figure out why.
-> Edit: it was to allow org_set_line (done via insert+delete) post last line (E.g. line 3 on a source with 2 lines). It's still allowed, without any dirty hack this time.

XXX #B5 [Editeur] Label starting with "im" taken as IM instruction

Edit: Fixed 2018 March The 3rd in parseaa.O (+ rst0, inca, pushde, …)

To reproduce: juste type img_c000 as a label then it will be interpreted as "im g_c000".

XXX #B4 [Orgams] Save binary doesn't work

Edit: Fixed in ch1q 17 Feb 2018.

*Not present in public release, but in previous working since …*

To reproduce: CONTROL-1 then B. When trying to save, an internal breakpoint is triggered.
Reason:
* Moving of mirror routines wasn't reported here. Another reason why we need includes!
* Buffer clash when disc buffer was moved.
* No unit test!

XXX #B3 [Trace/Madram] SP in debugger not set until first BRK

Edit: Fixed in ch1r 18 Feb 2018 (set debugger's SP to good default at cold init time).

*Not present in public release, but in latest working*

Thanks to Pascal for pointing this out.

To reproduce: go to debug via D.
If BRK has never been met, SP is 0000.

Copain: #8A

XXX #B2 [Editor/Madram] Memory corruption.

Edit: fixed 12 Feb 2018 in ED-BFM.

*Not present in public release, but in latest working*

Oups! Rookie mistake in display routines, leading to corruption/crash.

XXX #B1 [Assembler] BANK command not taken into account

Edit 12 Mar 2018. Fixed in ass1M. Buffer wasn't flushed when changing bank.

To reproduce:

   BANK &C4
   ORG &7000
   BYTE 1,2
   BANK &C0
   BRK

All is written in &C0.

XXX #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

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

24 Apr 2018: Fixed in ass1N (wasn't implemented!)

(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.

Edit: Even simpler example fails:

    MACRO dummy n
       ld a,n
    ENDM 

      dummy(unknown)

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

Fixed 22 Apr 2018 in orgAD.

It should move from invocation to definition.

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

Fixed since at least EE! Points to macro invocation.

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).

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

Edit 1/1/2018. Fixed in disa11: macro invocation uses () to disambiguate.

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.

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

Fixed May 5th 2023 (FF release) in ass-es. As we already had a flag indicating 'ent' was met, we just raise an error if the flag is already set. See ass_ent.

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

XXX #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

Edit 23 Apr 2017 parseAB. 2x faster for invalid lines!

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 !

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

Fixed 30 May 2019 in assag. If no ent met, exec=first pc.

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.

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

Edit 7/7/2018: It wasn't an editor issue after all, but a codec one: error returned by the parser wasn't taken into account. Fixed in orgAF
NB: With now more than 100 kb shared with label table, it's unlikely to hit this error anyway.

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.

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

Fixed 2 May 2019 in ch1U. SP was incorrectly saved.

• 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.

XXX #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…

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

Fixed 8/8/2018 orgah. Rahh OR A:INC A instead of XOR A:INC A to set

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.

Copain: bug #b6

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 ?
-> Réponse. OR A:INC A (test: bank &c7 -> ok NC NZ. inrom: bank &ff -> boudin)

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.

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

Edit: I think it was fixed a long time ago.

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é.

XXX #92 [Editeur/Madram] Export bloc corrompu

Not a bug!! Cf NDMadraM

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.

XXX #90 [RSX] |O,"file" broken when HIMEM en &4000-&7FFF

Fixed 23 Mar 2025 in ch-cn (GG beta H)

Il faut faire une copie trans-bank. -> actually stored out of 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.

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

Fixed 29 May 2019 in chAA: Do not install breakpoint at rom init (less intrusive).

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

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

Fixed sometime in May 2019.

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.

XXX #85 [AsT] Erreur pour lecteur Hxc/Gotek

Edit: Fixed in ch1r.o 18 Feb 2018. Rom init musn't change IX.

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…

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

Fixed 29 May 2019 in ch1Z. Set emulated SP to actual SP when assembling.

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.

XXX #82 [Monogams] Wrong system mode for CAT.

Fixed 29 May 2019 in monoW.

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.

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

Duplicate: Described more thoroughly in #160.

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.

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

Fixed 19 Apr 2023 (FF Beta I). In evacmd, make sure bk base is reconnected. In txt, set message for error code 237.

Edit 25 Jan 2021: Now it prints "he". Also happens when source loaded but not assembled.

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é.

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

Fixed 3 Jan 2024 in assevo-n (FF release).

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.

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

Fixed long time ago.

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

XXX #05 Trace [Madram] Crash si trace trace

Fixed 18 May 2024 in tr-ar (GG beta 5).
When RST &30 encounter and contains JP &BE00: Just skip it with S/N, and stop with SPACE (fast trace). Emulated R is preserved
If not JP &BE00: trace as usual (assume it was replaced by user)
SImilary, for any CALL [ccc] &BE00 and breakpoint routine at BE00 (just check 3 first bytes) acts as breakpoint.

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)