Technics SX-KN1500 — the TLCS-900 outlier

The SX-KN1500 (1996) is an early Technics arranger keyboard. Unlike the later MN10300 models (KN2400/KN2600, KN6000, KN6500, KN7000), it is built around a Toshiba TLCS-900 (TMP95C061) — the same CPU lineage as the SX-KN5000. It has its own driver file, src/mame/matsushita/kn1500.cpp — it does not live inside kn5000.cpp — though it is bundled into the single kn7000 binary alongside kn7000.cpp.

The ROM — confirmed BAD_DUMP, and this is the boot blocker

⚠ Updated 2026-08-25: an earlier version of this page said the dump “boots coherently” and was “very likely already a good dump.” Measured, that is wrong on both counts, and BAD_DUMP here is not the conservative/unvalidated marker it usually is.

A mask ROM marked IC15 (QSIGT3C16079, date code 9649 = 1996) was dumped into two 2 MB files, mapped as two logical ROMs:

File Region CPU address
…ic15 prog (program) 0xe00000
…ic15.rest rhythm 0xc00000

The program image splits into eight 256 KiB blocks. Four of them — 0xE00000, 0xE40000, 0xF00000, 0xF40000 — have 0xFF in every odd-offset byte, and each one’s even-offset stream is exactly the odd-offset stream of the block 512 KiB above it: 131,072 of 131,072 bytes match, in all four pairs, no exceptions. The odd bytes are not missing — they are displaced. This is measured by notes/wsa1-probes/kn1500_ic15_dump_defect.py in the overlay repo.

This is load-bearing: it is why the machine never boots. The crt0 memory test at 0xFA0460 fetches 10-byte region descriptors from a table at 0xF38B24, which sits inside one of the damaged blocks. It reads start = 0xFFDEFFF2 / length = 0xFFF2FF00, walks the whole 24-bit address space, and ends up writing its 0xA5/0x5A test pattern over the CPU’s own internal I/O registers (caught live by a Lua tap that saw the RAM test scribbling on T4MOD, T4FFCR and T45CR). The machine then spins there forever — a run of tens of seconds never leaves 0xFA047F–0xFA04A3.

The obvious repair does not work and is deliberately not applied: treating the four undamaged blocks as if they were the whole 1 MiB ROM leaves 0xF38B24 pointing at instrument-name ASCII, not at a descriptor. IC15 needs a re-dump. Nothing is invented in the meantime — the ROM stays BAD_DUMP and the driver is MACHINE_NOT_WORKING.

MAME status

kn1500.cpp declares a TMP95C061 CPU at 24 MHz and an SVG-backed LCD panel (SCREEN_SVG, 600×232). Its memory map, corrected from the service manual and the crt0’s own chip-select setup:

CPU address Contents
0x000000-0x07FFFF (mirrored at 0x080000-0x0FFFFF) Work RAM, IC21 (M5M4417, 512 KB DRAM) at CS3
0xC00000-0xDFFFFF Rhythm/accompaniment ROM, IC17, at CS1
0xE00000-0xFFFFFF Program mask ROM, IC15, at CS2
0x780000 (CS0) Not yet mapped — believed to be IC18/IC19 EPROMs

The machine does not currently boot past its RAM self-test, for the dump reason above — so nothing is written to the LCD yet. The LCD panel artwork (kn1500_lcd.svg) is preserved and rendered, but only statically: the driver does not yet toggle any of its 40 titled 0.0.X.Y dot-matrix cells from CPU output, because the boot never reaches that code. The service manual (schematic + block diagram, provided 2026-07) describes the panel as a hybrid of custom icons and a pixel-grid region, driven over what looks like an HD44780-style 8-bit parallel bus (D80-D87, LCDCS/DSPCS, RS/R-W/E) — that interface is not yet modeled in the driver.

Image hashes (unchanged by the above — the dump’s content is confirmed bad, not its recorded hash):

ROM size CRC32 SHA1
…ic15 (program) 2097152 0f78da9a 53d5c43d833fb005a7bd377583252b84b646253d
…ic15.rest (rhythm) 2097152 ce60897a 9b54f693f693488132b93e8bfed1927d7e741ae1
kn1500_lcd.svg (LCD panel) 221081 d779a7b9 0b40105175cc6e2ac05dea65f1ddb6c7c52c4662

See kn7000_mame/notes/kn1500-lcd.md for the full boot-trace diagnosis and the patch experiment that confirmed the dump defect (injecting a valid descriptor lets the boot proceed past the RAM test, then immediately derail into the same garbage 0xFF-padded regions elsewhere in the ROM).