LibretroAdminandLibretroAdmin
0ee912a661
* emumem: trim handler template matrix to the combinations this core uses
Answering 'which unused deps cost binary size': none -- all remaining
3rdparty code combined contributes ~1.1 MB. The weight was MAME's own
memory system: ~29 MB of the 45 MB text segment was emumem template
instantiations (address_space_specific, memory_view_entry_specific and
the handler_entry dispatch/passthrough/tap/units matrix) for every bus
width (8/16/32/64) x address shift x endianness x dispatch level, all
referenced unconditionally by the runtime dispatch switches and
therefore all linked.
The CD-i machines allocate exactly two configurations:
scc68070 program/oprogram/cpu_space: 16-bit, shift 0, BE, level 1
m68hc05 program (cdimono2/cdi910): 8-bit, shift 0, BE, level 0
Trimmed to that set:
- memory_manager::allocate keeps 4 cases; anything else now lands in
a fatalerror naming the requested width/shift/endianness so a future
device addition fails loudly at machine start, not mysteriously.
- mview's mve_make/h_make dispatchers and the explicit instantiation
lists in emumem_hedr0-3/hedw0-3 (which partition HighBits ranges,
not widths), hedp, het, heu, heun, hem, hep and mud are cut to
(width 0, shift 0) and (width 1, shift 0).
Verification: dummy-ROM boot harness (correctly named, zero-filled
BIOS images; romload proceeds past checksum warnings) through a
minimal libretro host. cdimono1 completes machine start and runs 30
frames; a scratch build forced to cdimono2 completes device start
including both MC68HC05C8 program spaces, exercising both kept
combinations live; the only failure is the zeroed MCU ROM executing
an unimplemented opcode, past memory setup. Link with
-Wl,--no-undefined audits that no trimmed instantiation is still
referenced. mingw-w64 -fsyntax-only passes on all emumem TUs.
Text shrinks 51.1 MB -> 18.5 MB; stripped .so 51.8 MB -> 19.0 MB.
* m68k: remove the 68881/68882 FPU; drop 3rdparty/softfloat
Nothing this core emulates has an FPU: the SCC68070 is an FPU-less
68000 derivative and the MCUs are MC68HC05s. m_has_fpu is never set,
so every FPU path in the m68k core was runtime-dead and existed only
to satisfy the m68kops dispatch tables, which is what kept m68kfpu.o
and its 3rdparty/softfloat floatx80 arithmetic in the link.
Dependency audit (link map + nm):
- softfloat is referenced only by m68kfpu.o
- the rest of the core needs exactly nine symbols from m68kfpu.o:
READ/WRITE_EA_{16,32,64} (also used by the PMMU code inlined into
the opcode handlers via m68kmmu.h) and m68040_fpu_op0/op1 +
m68881_ftrap, all three of which the generated handlers already
gate behind m_has_fpu with an F-line trap fallback
- m_fpr is not registered with the save system, so removal does not
change the savestate format; FP debugger state entries are gated
behind MASK_030_OR_LATER and never registered for these CPUs
m68kfpu.cpp is reduced to the generic EA helpers (kept verbatim) plus
three F-line trap stubs, matching real FPU-less silicon. m68000.h
loses the softfloat includes and all floatx80-typed members and
declarations; the FP display cases in state_string_export are inert.
3rdparty/softfloat and the softfloat build group are deleted, along
with the now-unused compile-.c-as-C++ rule.
Verified: full relink of the m68000.h include closure (a partial
rebuild reproduces a vtable-layout crash, caught by the boot harness);
cdimono1 boots and runs 60 frames on the dummy-ROM harness; a scratch
cdimono2 build completes device start including both MC68HC05C8s;
dlopen smoke OK; zero floatx80/float64 symbols in the .so;
mingw-w64 -fsyntax-only passes on every TU in the closure.
* doc: record accuracy oracles (CDi_MiSTer, cdichips)
CDi_MiSTer was evaluated as an accuracy reference against this core's
own status headers. For the CD-i ASICs it is the more faithful
implementation: LLE slave (dumped 68HC05 firmware vs our HLE), a
register-level CDIC with real DMA through the 68070 DMA controller
(ours is 'just enough' HLE with high-level DMA), an MCD212 pipeline
with ICA/DCA and VideoIRQ timing measured on a real 210/05 with a
logic analyzer (ours is a scanline renderer without QHY DYUV), and
implemented 68070 on-chip peripherals (ours are a skeleton with
magicard hacks). It is validated per-title against real hardware and
the BIOS self test, and maintains a list of quirks confirmed authentic
on real machines -- valuable to avoid fixing behavior that is real.
It is not authoritative for 68000 instruction semantics or 68070
instruction timing (TG68K.C base, approximated timing; both sides are
approximate there), nor the servo (HLE on both sides).
The RTL is GPLv3: behavioral reference and measurements only; nothing
may be ported verbatim into BSD-3-Clause files. cdifan/cdichips is
the shared primary written source for register maps.
---------
Co-authored-by: LibretroAdmin <[email protected]>
2.6 KiB
Accuracy oracles
Reference implementations and measurements to verify same_cdi behavior against, in order of preference.
CDi_MiSTer (FPGA implementation)
https://github.com/MiSTer-devel/CDi_MiSTer
Mono-I (210/05-class) FPGA implementation, actively developed, validated
per-title against a real CD-i 210/05 and against the BIOS self test. Its
doc/ directory contains logic-analyzer measurements taken on real
hardware (MCD212 VideoIRQ position relative to VSync/VBlank, ICA/DCA
execution timing, Display Active edges) and a curated list of quirks
confirmed present on real hardware (doc/quirks.md) -- useful to avoid
"fixing" behavior that is authentic.
Where it is more accurate than this core (verified against our own status headers):
| Subsystem | same_cdi | CDi_MiSTer |
|---|---|---|
| SLAVE MCU | HLE (cdislavehle, "TODO: Proper LLE") |
LLE: dumped slave 2.0 firmware on a 68HC05 core |
| CDIC | "just enough" HLE, DMA is high-level | register-level model (cdifan RE), real DMA, hw-verified timing |
| MCD212 | scanline renderer, QHY DYUV unsupported | fetch/decode pipeline, ICA/DCA timing measured on hardware |
| 68070 peripherals | "Skeleton" (UART/DMA/timers), magicard hacks | implemented, DMA validated against OS-9 driver traces |
| DVC (MPEG cart) | absent | implemented (VMPEG) |
Where it is not automatically better: 68000 instruction semantics and instruction timing (it uses TG68K.C with approximated 68070 timing; our interpreter core is functionally better tested but its 68070 cycle counts are approximate too), and the servo (HLE on both sides).
License note: the RTL is GPLv3. Use it as a behavioral reference and for its hardware measurements; do not port RTL verbatim into BSD-3-Clause source files.
cdifan / cdichips
https://github.com/cdifan/cdichips
Register-level reverse engineering of the CD-i ASICs (notably the IMS66490 CDIC and MCD212) underlying both CD-i Emulator and the MiSTer core. Primary written source for register maps and buffer layouts.
Real-hardware ground truth
CDi_MiSTer's doc/quirks.md documents title-level behavior reproduced
on a real 210/05 (micro-jitter in Zelda map scrolling, Myst transition
line glitches from mid-display VideoIRQ, per-title audio artifacts).
Treat entries there as authentic machine behavior, not emulation bugs.