#2258 Magic Desk Plus (CRT id 87): the revision's EEPROM size is never applied, every EEPROM revision behaves as 32KiB

[Enver Haase-Beer]

Disclosure: this investigation and write-up were done with the help of Claude Code
(Anthropic). Every factual claim below is backed by a reproducible command line, a
file:line citation, or an SVN revision, given inline.

Version: git mirror VICE-Team/svn-mirror @ cbc2f46, self-reporting VICE Version 3.10
(trunk at or shortly after r46225)
Platform: Linux x86_64 (Ubuntu, kernel 6.8), configured --enable-headlessui

Note on the build: stock cbc2f46 segfaults before the emulator starts in the headless
UI, so I applied a one-line NULL guard in log_archdep() to run at all. That is filed
separately. It touches only src/log.c and no cartridge code; everything below was
measured with it applied.

A companion report covers a separate question -- what the subtype byte is supposed to
mean, where cartconv and the emulator disagree. This ticket does not depend on that
being resolved: it uses the emulator's own definitions throughout.

Found while adding Magic Desk Plus support to the 1541 Ultimate firmware
(GideonZ/1541ultimate#844).

---

Symptom

magicdeskplus.h:41 defines MAGICDESKPLUS_REV_SRAM_EEPROM_8K = 1, so on the emulator's
own terms a subtype 1 image has an 8KiB EEPROM. An 8KiB EEPROM is 32 pages, so the
page register must mask to $1F and page $25 must alias onto page $05. It does not: the
mask is $7F, the 128-page mask of a 32KiB part.

Reproduce

cartconv -t mdp -s 1 -i rom256k.bin -o s1.crt
x64sc -cartcrt s1.crt

In the monitor, write two pages that an 8KiB part cannot tell apart, then read the
first one back:

> de03 00      # bit 5 = 0 selects EEPROM
> de01 05      # page $05
> df00 aa
> de01 25      # page $25 -- aliases onto $05 iff the mask is $1F
> df00 55
> de01 05
m df00 df00

Expected for an 8KiB EEPROM: 55, because the second write landed on the same page.
Actual: AA. The pages are distinct, so the mask is $7F and the part is 32KiB.

Across every revision

subtype | declared (magicdeskplus.h)  | page $05 reads | implied mask
--------+-----------------------------+----------------+--------------------
   0    | SRAM + 32K EEPROM           | AA             | $7F
   1    | SRAM + 8K EEPROM            | AA             | $7F  <- expected $1F
   2    | 32K EEPROM                  | AA             | $7F
   3    | 8K EEPROM                   | AA             | $7F  <- expected $1F
   4    | SRAM only                   | 00             | no EEPROM

Presence is honoured -- subtype 4 correctly has no EEPROM -- but size never is.
(Subtypes 3 and 4 cannot be written by cartconv, which refuses anything above 2; for
those two rows I patched header byte $1A of a cartconv-produced file directly. That
restriction is the subject of the companion report.)

Where it comes from

magicdeskplus_eeprom_read() (magicdeskplus.c:280) and magicdeskplus_eeprom_store()
(:293) both take the mask from magicdeskplus_eeprom.size:

uint8_t page_mask = (magicdeskplus_eeprom.size == MAGICDESKPLUS_EEPROM_8K_SIZE)
                    ? 0x1f : 0x7f;

but magicdeskplus_eeprom_activate() (:343) allocates only when
magicdeskplus_eeprom.data == NULL and never resizes an existing buffer. In
magicdeskplus_crt_attach(), magicdeskplus_common_attach() runs at :596 and
set_magicdeskplus_revision() at :599, so the buffer is sized before the revision from
the CRT header is known.

I tried reordering those two calls so the revision is set first. The measured mask did
not change, so the allocation is reached before that point by another path. I am
reporting what I observed rather than proposing the fix.

Consequence: the 8KiB variants cannot currently be demonstrated at all, which also
means the emulator cannot be used as the reference for how an 8KiB Magic Desk Plus
should behave.

[Enver Haase-Beer]

Follow-up with a stronger reproducer: because of this, a shipping commercial release cannot load its own EEPROM image.

"Murder on the Mississippi Remastered" (by crystalct, who authored the Magic Desk Plus hardware) is distributed as a Magic Desk Plus CRT plus two sidecar images, exactly as section 87 prescribes:

Murder on the Mississippi Remastered [ENG].crt   262720 bytes, type 87, subtype $00,
                                                 32 ROM banks of 8K at $8000,
                                                 no CHIP packets at $DF00
EEPRom 8k.bin                                    8192 bytes
SRAM 128K.bin                                    131072 bytes

Its bundled instructions say to select both images under Preferences > Settings > Cartridges > Magic Desk Plus, then launch the CRT. Doing exactly that:

x64sc -default \
      -magicdeskpluseepromimage "EEPRom 8k.bin" \
      -magicdeskplussramimage "SRAM 128K.bin" \
      -cartcrt "Murder on the Mississippi Remastered [ENG].crt"

MAGICDESKPLUS: Invalid EEPROM image size (must be 32768 bytes).

The release's own 8KiB EEPROM is refused, and an internally created 32KiB part is used in its place, so the game cannot reach its saves.

The check is not reading the revision. Patching that CRT's header byte $1A from 0 to 1 -- MAGICDESKPLUS_REV_SRAM_EEPROM_8K, which declares an 8KiB EEPROM -- produces the identical message. The size being validated against is the 32768 that was already allocated before the revision is applied, which is the same root cause as the page-mask symptom in the original report.

So the consequence is worse than I first described. It is not only that the 8KiB variants cannot be demonstrated; an 8KiB EEPROM image cannot be loaded at all, under any subtype.

Same build as the original report: cbc2f46 (VICE 3.10), Linux x86_64, --enable-headlessui with the log.c NULL guard described in bug 2259.

As with the original report, this was investigated with the help of Claude Code (Anthropic); the evidence above is a reproducible command line and a verbatim log line.

[gpz]

I can't reproduce this at all, i can attach 8k eeprom file and the monitor (io de00) shows it as 8192 bytes as expected.

Please tell in a few words what the problem is :)