KN2400 / KN2600 / PR54 — the KN7000’s closest siblings

The Technics SX-KN2400 and SX-KN2600 are, at the firmware level, the closest relatives of the KN7000 — closer than the KN6000/KN6500. Both run a Panasonic MN10300 CPU on the MILK application framework, and their firmware is a near-twin of the KN7000’s. All findings below were verified byte-for-byte (and cross-checked by an adversarial verification pass).

One firmware image, three models

The update disk (kn24-11.zip → kn24_11a/b.exe → LKG1.SLD + LKG2.SLD) carries a single firmware image that serves three products, selecting behaviour at runtime:

Selector value @ RAM 0x5002f610 Model
0 SX-KN2600
1 SX-KN2400
2 PR54

The selector is the value of the MILK IvKNPRWin object (handlers at 0x485f85a5 / 0x485f8560: message 0x60042 → the pointer 0x5002f610, 0x60043 → state count, 0x60044 → %d display). The image carries complete parallel resource sets in the same fixed order, indexed by that value.

PR54 is a full model, not a stub: the firmware carries dedicated PR54title, PR54icon, PR54show, PR54pmmdscreen, TtDemoMenuPR54 and FSWSelPR54 resources right beside the KN2400/KN2600 ones. The likely product is the Technics SX-PR54 digital ensemble, but the ROM uses only the short PR54 code, so the exact designation is unconfirmed (a pr54 MAME clone is pending that confirmation).

Correction. An earlier assumption named the trio “KN2000/2400/2600”. That was wrong: KN2000 occurs only once, as a lone entry in an expansion-board name list — it has no resource set. The real trio is KN2400 / KN2600 / PR54. This was caught by adversarial verification, not by the initial pass.

The KN2600 update package’s KN24PRG.DAT is byte-identical to LKG1.SLD + LKG2.SLD concatenated — the raw contiguous program.

Memory layout

Region Contents
0x48400000 LKG1.SLD (2 MB) — program + name/style tables
0x48600000 LKG2.SLD (0x1965D3) — more program, incl. the crt0
0x48000000-0x483fffff a separate table/font ROM, like the KN6000/KN7000’s — but undumped on this family

Correction (2026-08-15). An earlier pass here claimed the KN2400 family has “no separate table flash” and reads nothing from 0x48000000. Both halves of that were wrong, and the driver’s own ROM_START(kn2400) comment now says so: a read tap (tools/rigs/kn24_fontsrc.lua) counts 164,300 reads of that range starting at t = 0.84 s, so the region is mapped, addressed and functionally live — it is simply undumped, hence ROMREGION_ERASEFF. notes/FINDINGS-kn2400-table-rom.md traces what the firmware does with it (a ~0x40-byte descriptor, a 40×712-byte record copy into RAM) and rules out the obvious theory that its missing contents are why on-screen text renders as solid black bars — overwriting the RAM buffers copied from it, and forcing its contents to 0x00, both leave the screen unchanged; the routine that actually paints the UI plane never reads this ROM at all. The black-bar defect is real but sits upstream of this ROM, not in it.

The reset vector at 0x48400000 is jmp 0x48705bdf, which lands in LKG2 and is a textbook MN10300 crt0 (port/bus init at 0x360080xx, DRAM controller 0x497 → 0x32000040, SDRAM refresh setup, .bss zeroing, .data copy to RAM). That crt0 is byte-identical to the KN7000’s reset routine at 0x4840ff7e, differing only in the stack address — direct proof of the shared source tree.

Cross-model code reuse

Measured against the KN7000 and KN6000 program ROMs (distinct ≥8-char strings, and 16-byte code windows under a relocation-tolerant match):

Metric KN2400 ↔ KN7000 KN2400 ↔ KN6000
Shared distinct strings 74.3 % (11310/15220) 23.6 % (3587/15220)
MILK MN10300 Ver1.0R1 banner identical absent in KN6000
Relocated byte-identical code 38.9 % of non-trivial windows 11.0 %

A correction to the shared-codebase model: earlier notes described KN7000↔KN6000 as “~0 % byte-identical code.” That figure came from a same-offset comparison. Under a relocation-tolerant metric the sibling firmwares share a great deal of byte-identical executable code — it is simply shuffled to different addresses between builds (e.g. KN2400 0x48420000 == KN7000 0x485BBFB0, disassembling to the identical instruction stream). The right mental model is one source tree, re-linked per model, not independent rewrites.

The name/symbol tables (10,671 strings incl. 4,149 internal MILK symbols) live in LKG1 — see the cross-version diff guidebook for how these drive symbol recovery across the family.

MAME drivers & ROM chip modeling

The drivers kn2400 and kn2600 (a clone of kn2400) live in kn7000.cpp, reusing the KN7000 machine config as drafts. For the whole MN10300 family the flash is modeled as its physical even/odd 16-bit chips: the checksum-verified .SLD update image is de-interleaved into *_even.rom / *_odd.rom and loaded with ROM_LOAD32_WORD (even → D0–D15 @ off 0, odd → D16–D31 @ off 2). Because the region bytes are unchanged, emulation is identical to the linear load while the ROM set now reflects the real chips. These are good dumps (the .SLD/.INF block checksums verify the decompression); real chip reads would supersede them. The full chip list with sizes, CRC32 and SHA1 is in the driver repo’s ROM manifest.