Technics SX-KN7000

The Technics SX-KN7000 (2002) is the successor to the KN5000. Reverse engineering of the KN7000 is at an early stage; this section documents what has been established so far from its system-update disks.

Status: early research. The update-disk container format is fully decoded and both flash images are extracted byte-exactly; firmware disassembly has just begun. Much of the KN5000’s knowledge does not carry over directly because the KN7000 uses a completely different CPU — but the two firmwares share a common source lineage (see Shared Codebase Map).

At a glance

Property KN7000 (KN5000 for comparison)
Year 2002 1997
Main CPU Panasonic MN103002A (MN10300 / AM33 core) Toshiba TLCS-900/H2 (TMP94C241F)
CPU clock 32 MHz (16 MHz crystal × PLL; IOCLK = 16 MHz) 25 MHz
RTOS/kernel MILK MN10300 Ver1.0R1 (embedded banner) custom
Program flash mapped at CPU 0x48400000 mapped at 0xE00000
Table/data flash mapped at CPU 0x48000000 Table Data ROM
Compression lib zlib 1.0.4 (in addition to LZSS) LZSS
Update container .SLD (JKPRG4K/JKTB14K/JKTB24K) .SLD (SLIDE4K)

The main CPU is a Panasonic MN10300 — not a TLCS-900

The single most important finding for anyone extending KN5000 knowledge to the KN7000: the CPU architecture changed. The KN7000 program image disassembles cleanly with unidasm -arch mn10300 and embeds the kernel/library banner MILK MN10300 Ver1.0R1 at file offset 0x3B8AAC. It also links zlib 1.0.4 (deflate/inflate banners at 0x3B8604 / 0x3B863C).

The practical consequence: none of the KN5000’s TLCS-900 opcode-level knowledge transfers — instruction encodings, patch offsets, and the disassembler backend are all different. What does carry over is the update container format, the higher-level firmware design, and large amounts of shared resource data (see the Shared Codebase Map).

Memory map (as used by the firmware)

CPU address Contents
0x48000000 Table flash (kn7000_table.rom; firmware reads *(0x4800001C))
0x48400000 Program flash (kn7000_program.rom; file offset + this base = CPU address)
0x4C000000 Library/kernel code called by the firmware — not in either dumped image (an internal boot ROM, still undumped)
0x50000000 Work RAM (initial SP = 0x50021CF8; BSS cleared to ~0x50180000, so ≥1.5 MB)
0x57800000 “Picture” flash (separate device, not covered by these updates)
0x20000070, 0x320000xx, 0x34004002, 0x360080xx, 0x98020004 I/O registers

CPU clock: 32 MHz (16 MHz crystal, doubled)

The main CPU is IC4 = MN103002A on the MAIN 1/5 board. Its clock was pinned down two independent ways that agree exactly:

From the service-manual schematic (SCHEMATIC DIAGRAM-1): a 16.0 MHz reference crystal X1 (part H0J160500026 — the H0J<freq×10> code family is consistent with X102 H0J177=17.73 MHz, X103 H0J240=24 MHz, X104 H0J143= 14.32 MHz) drives a clock generator IC6 (C02BZ0000667); its SSCLK output also feeds a TC7WH74 divide-by-two flip-flop that clocks the peripherals — so the CPU core runs at the full (non-÷2) rate.

From the firmware’s MIDI setup (the decisive confirmation): MIDI is exactly 31250 baud. The firmware configures its serial channel for 8N1 with the baud clock = Timer-3 underflow ÷ 8, and Timer 3 counts at the internal peripheral clock (IOCLK) with reload TM3BR = 0x3F (63). Therefore

baud = IOCLK / (8 × (TM3BR + 1)) → 31250 = IOCLK / 512 → IOCLK = 16.000 MHz, exactly.

Only 16 MHz reproduces the actual reload value (32 MHz would need 0x7F). With the schematic’s ÷2 peripheral branch and the MN10300 convention that IOCLK is half the core clock, the CPU core is 32 MHz. This matches the measured boot workload (~400M cycles / 32 MHz ≈ 12.5 s, the real machine’s boot time). See the MAME driver notes and the blog write-up “Learning to tell time” for the full investigation.

The program-flash mapping (file offset + 0x48400000) is proven by ~68,000 self-consistent 32-bit pointers in the image.

Hardware map (from service-test strings)

The firmware’s service test mode enumerates the hardware with IC designators:

  • Program ROM IC16 / IC17, rhythm ROM IC18 / IC20, custom flash IC21, picture ROM IC19
  • Work RAM IC12 / IC13, static RAM IC23, LCD V-RAM IC104, fast S-RAM IC14/IC15
  • Dual tone generators: main TG ROMs IC203 / IC204, sub TG ROMs IC207 / IC208
  • DSP IC306 / IC307, floppy controller IC103 / IC308
  • Panel sub-CPUs CPL / CPC / CPR / CPSD
  • Wave expansion board, SD card slot, video-out

I/O register map (from firmware analysis)

Static analysis of every absolute I/O access in the program ROM recovered 112 memory-mapped I/O registers, in these banks:

Bank Registers Likely function
0x20000000 7 small register block; the reset code writes 0x30/0x03 to 0x20000070
0x32000000 15 system / timers (0x40/0x42 loaded with 0x497/0xEA6 at reset; 0x800 is a 32-bit counter)
0x34000000 58 large peripheral block — dense 16-bit writes, likely the LCD/display controller and key/panel scan
0x36008000 8 bit-mapped control / GPIO — every access is bset/bclr/btst; 0x36008004 is toggled 125× (chip selects / strobes / resets)
0x98040000 + 0x98050000 7 + 9 parallel 16-bit register sets — the dual tone generators (main TG IC203/204 + sub TG IC207/208)
0x98020000 8 floppy disk controller IC103 (custom C1DB00000607, N82077AA-compatible). Confirmed by the service-manual schematic — a 3-to-8 chip-select decoder (IC1, TC74VHC138F) splits the 0x98000000 region by CPU A16–A18; output Y2 = FDC.CS = 0x98020000 (Y4 = 0x98040000 = the TG select fixes the base). The firmware drives the standard PC/AT register file here: +4 DOR, +8 MSR/DSR, +A data FIFO, +E DIR/CCR. Data transfer is software-DMA: the controller’s DRQ raises a CPU interrupt whose handler moves one byte via the FDC.DACK slot at 0x98010000 (decoder output Y1). (This bank was previously mislabelled “sound-subsystem control”; it is not sound.)
0x98060000 / 0x98070000 — further sound-subsystem control (0x98060000) + a status/strap word (0x98070000)

The reset code’s first act is programming the 0x36008000 GPIO and the 0x32000000 timers, then toggling 0x36008004 — the classic hardware bring-up sequence. This map is wired into the MAME driver’s memory map (as logging handlers pending real device models).

Documentation

Page Description
System Update Discs .SLD container format, LZSS decompression, .INF checksum oracle, extraction tool
Firmware Images Program & table flash layout, version numbers, string & hardware inventory, byte-exact disassembly project
Image Gallery 169 images extracted from the firmware (demo slideshows, product photos, digital-drawbar UI graphics)
User Data & Initial Data Disk The custom-data flash (0x56000000/0x96800000), the Initial Data floppy (idd7000), Favorites/Memory/Home-Page install, and how the rhythm menu resolves style names
Sound & Style Names The complete inventory of 1,454 built-in voices + 931 accompaniment styles, extracted from the ROMs
Shared Codebase Map Where the KN5000 and KN7000 firmwares match
Roadmap (vs KN5000) What was done for the KN5000 and how each piece maps onto the KN7000

Tools & repositories

The extraction and disassembly tooling lives in dedicated repositories:

  • kn7000_extraction — decompresses the .SLD update files and rebuilds the flash images (verified against the disks’ own checksums); also splits the table image into its 84 asset segments.
  • kn7000_disassembly — a byte-exact reassembly project for the MN10300 firmware. make verify reassembles the source and asserts a 100% byte-match against the originals.

Source of these disks

The KN7000 system-update disks documented here were distributed via ca-software.com:

  • kn7-16 — Program update (2 floppies: JK1.SLD + JK2.SLD)
  • kn7-14 — Table update (2 floppies: JKT1.SLD + JKT2.SLD)

(The cb7-update package in the same distribution is unrelated PC software — a Windows installer for the “SD-Jukebox” application, not keyboard firmware.)