fix(video): Merlin 8 title banner renders MouseText where flashing text belongs

[relmer]

Symptom

Booting Merlin 8 v2.47 on --machine Apple2e, the title banner renders as
garbage glyphs where MERLIN should be. Everything else on the screen is
correct, including the 8 2.47 on the same line and the whole menu below it.

  <garbled>  |-8  2.47      <- only the "MERLIN" part is wrong
   By Glen Bredon
   C :Catalog                <- all correct
   L :Load source
   ...

What the character ranges say

The split is the diagnostic. Reading the banner as a text line:

• 8, , 2, ., 4, 7 are $38 $20 $32 $2E $34 $37 -- all in $00-$3F,
  which is inverse uppercase under BOTH ALTCHARSET settings. Renders correctly.
• M E R L I N written as $4D $45 $52 $4C $49 $4E lands in $40-$5F, which
  is flashing uppercase when ALTCHARSET=0 and MouseText when ALTCHARSET=1.
  Renders as garbage.
• The menu text is $80-$FF normal. Renders correctly.

The garbled glyphs are consistent with MouseText shapes (partial boxes, line
segments, arrow-ish forms) appearing where flashing letters were intended.

That points at ALTCHARSET reading as 1 while Merlin expects 0 -- or at the
MouseText glyph data in the alt set being wrong. Only the one range is affected,
which is why nothing else on screen is disturbed.

What I ruled out

• Renderer range logic. Both text renderers handle the ranges correctly.
  Apple80ColTextMode.cpp guards inline (flash = !m_altCharSet && charCode >= 0x40 && charCode < 0x80) and AppleTextMode.cpp gets the same effect from its
  if (charCode < 0x40) ... else if (charCode < 0x80) structure. They agree.
• Missing video ROM. Apple2e_Video.rom is present at 4096 bytes, the 4K
  //e ROM that carries MouseText, and HasAltCharSet() keys off it.
• Propagation. MachineManager::SelectVideoMode reads
  iieSoftSwitches->IsAltCharSet() and pushes it to both text renderers.

So the wiring is right and the suspect is narrower: either the soft-switch state
itself, or the alt-set glyph data.

Reproduction

Needs a Merlin 8 disk image, which is commercial software and not in the repo.

Casso.exe --machine Apple2e --disk1 <merlin8.do>

The banner is on the boot screen; no interaction required.

Impact

Display only. Found while validating Merlin 8 as the reference assembler for
specs/019-assembler-dialects -- the assembler itself is unaffected, and Merlin
is otherwise fully functional under emulation (menus, catalog, and disk access
all work correctly).

[relmer]

Blast radius is probably wider than the title suggests

The diagnosis points at ALTCHARSET rather than at anything Merlin-specific. If
the soft switch reads 1 where a program expects 0, then every program
writing $40-$5F to text memory renders MouseText instead of flashing
uppercase — not just this one.

That range was ordinary: flashing text was the period idiom for cursors,
prompts, alerts, and menu selections. So a plausible worst case is that a
noticeable share of //e software shows garbled glyphs wherever it flashes,
and Merlin is simply where it happened to be noticed first.

Worth establishing before sizing the fix:

• Does a $C00E write (clear ALTCHARSET) actually take effect, or does the
  state persist from wherever it was set?
• What is ALTCHARSET at power-on and after a reset? A //e should come up on the
  primary character set.
• Does anything set it unconditionally — 80-column firmware entry, or machine
  init — without a path back?

If the answer is "ALTCHARSET is stuck on," this is retitled as a general text-mode
defect and the priority moves up. If it is genuinely something in how Merlin
enters the display, it stays where it is.

Cheap check: any program that flashes something. A BASIC FLASH statement
writes the same range, so FLASH : PRINT "TEST" from the prompt is a
one-line reproduction that needs no disk at all — and it distinguishes the two
hypotheses immediately.

[relmer]

Ran the FLASH reproduction: this is NOT a general text-mode defect

Tested on DOS 3.3 System Master, --machine Apple2e, no Merlin involved.

Flashing text in $40-$5F renders correctly. Two independent instances:

1. DOS 3.3's own greeting line BE SURE CAPS LOCK IS DOWN is flashing text, and
   it renders as readable inverse — correct for the flash-on phase.
2. FLASH : PRINT "TEST" from the BASIC prompt renders its echoed command line
   in flashing form, correctly and readably, and prints TEST.

No MouseText glyphs appear in either case.

So the earlier hypothesis in the issue body — that ALTCHARSET reads 1 where
programs expect 0, making every $40-$5F write render as MouseText — is
disproved for the general case. Flashing works at the BASIC prompt.

That narrows this back to something specific about how Merlin sets up its
display, rather than a defect every program writing that range would hit. The
blast-radius concern raised above does not apply on this evidence, and the
priority can come back down.

Remaining candidates, none of them ruled in yet:

• Merlin explicitly enables ALTCHARSET (it is a //e-aware program) and genuinely
  intends MouseText for its banner, in which case our MouseText glyph data
  is what is wrong rather than the switch.
• Merlin toggles the switch around the banner draw and we latch it at the wrong
  moment.

The first is worth checking before the second, since it would make this a
character-ROM decode question rather than a soft-switch timing one — and the
banner is the kind of decorative logo MouseText exists for.

Method note

Driven with scripts/SendCassoKeys.ps1, which posts WM_CHAR to the emulator
window and needs neither focus nor a click.

[relmer]

Ran the set-then-clear test, plus two more. Three hypotheses now falsified.

All on DOS 3.3 System Master, --machine Apple2e, no Merlin involved. Driven
with scripts/SendCassoKeys.ps1.

1. Flashing text renders correctly — ALTCHARSET-stuck-on is dead

FLASH : PRINT "AAAA" renders as readable flashing letters, as does DOS 3.3's
own BE SURE CAPS LOCK IS DOWN greeting. No MouseText.

2. Set-then-clear: the SET appears not to take effect at all

FLASH : PRINT "AAAA" : NORMAL                      -> readable letters
POKE 49167,0 : FLASH : PRINT "BBBB" : NORMAL       -> readable letters
POKE 49166,0 : FLASH : PRINT "CCCC" : NORMAL       -> readable letters

With ALTCHARSET set, BBBB writes $42 four times, which is MouseText range —
it should have rendered as MouseText and did not. So this does not isolate a
broken clear path; it suggests the set never took.

Stated as an observation rather than a conclusion: an Applesoft POKE to $C00F
may not be a sound way to exercise this, and I have not ruled out something
re-clearing the switch before the PRINT executes. A proper test wants a few
bytes of assembly, not BASIC.

3. Inverse renders correctly in both sub-ranges — the ROM-decode theory is dead

I suspected the $00-$1F inverse-uppercase region specifically, since Merlin's
banner splits exactly there: MERLIN inverse is $0D $05 $12 $0C $09 $0E
($00-$1F) while 8 2.47 inverse is $38 $20 $32 $2E $34 $37 ($20-$3F), and
only the first half is garbled.

INVERSE : PRINT "MERLIN" : PRINT "8 2.47" : NORMAL
INVERSE : PRINT "ABCDEFGHIJKLM" : PRINT "0123456789.,-" : NORMAL

All of it renders correctly, including the word MERLIN itself in inverse.
So the character ROM decodes both inverse sub-ranges fine.

Where that leaves it

Ruled out: ALTCHARSET stuck on; a broken ALTCHARSET clear path; inverse-uppercase
ROM decode; MouseText-by-design (the reference screenshot on the Internet Archive
item shows MERLIN-8 2.47 as legible text in an inverse box, so the glyphs are
meant to be letters).

Every ordinary text-mode path renders correctly from BASIC. Whatever Merlin does
to draw that banner is not any of them, and the remaining candidates need
inspection of what Merlin actually writes rather than more black-box probing —
reading the text page while the banner is displayed would settle it in one look.

Item 2 above may be a separate defect worth its own issue if $C00F writes
really are ignored; it needs the assembly-level test first.

[relmer]

Correction, and a handover

The "set does not take" observation is probably not a defect

I flagged it as an observation; it now has an ordinary explanation and should not
be chased as a fourth bug.

Soft switches respond to access, so the POKE almost certainly does set
ALTCHARSET. What happens next is the issue: PRINT goes through COUT, and with
//e 80-column firmware in the path, the firmware's output routine can reset the
character-set state as part of its own housekeeping. By the time the bytes reach
the screen the switch is back where the firmware wants it.

So that test does not show a broken set. It shows Applesoft cannot hold that
switch across a PRINT, which is a property of the firmware rather than of the
emulator. A sound test needs a few bytes of assembly that set the switch and
write straight to $400 without going through COUT.

The black-box avenue is exhausted

Four eliminations, none of which need repeating:

1. Normal text renders correctly.
2. Inverse renders correctly in both sub-ranges — $00-$1F uppercase and
   $20-$3F digits and punctuation. Verified by printing the word MERLIN
   itself in inverse, which is the exact text that garbles in Merlin's banner.
3. Flashing renders correctly — both DOS 3.3's own greeting line and an
   explicit FLASH : PRINT.
4. Design intent is out. The reference screenshot on the Internet Archive
   item shows the banner as MERLIN-8 2.47 in legible text inside an inverse
   box, so the glyphs are meant to be letters, not a MouseText logo.

Every ordinary text-mode path is correct from BASIC, and whatever Merlin does to
draw that banner is none of them.

What it needs next

Diagnosis now requires reading the text page while the banner is on screen —
seeing which character codes Merlin actually wrote. That is not currently
possible: there is no memory viewer (#51 interactive monitor, #59 debugger
panel), and reaching the guest's own monitor overwrites the very screen under
inspection.

Parking it here rather than guessing further. This is a decent first customer for
#59 — a concrete, reproducible bug that a debugger panel would settle in one
look is a better case for building it than a general appeal to usefulness.

Cosmetic, display-only, does not touch assembly, and cannot affect the
019-assembler-dialects corpus.