LibretroAdminandLibretroAdmin 0ee912a661 Rebase (#28) ...

* 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]>

2026-08-04 08:36:56 +02:00

..

oracles.md

Rebase (#28)

2026-08-04 08:36:56 +02:00