All ROM PACK lines follow 5V TTL standard: power supply must be 5VDC, signals are defined as "low" when between 0 V and 0.8 V with respect to the GND terminal, and "high" when between 2 V and VCC (5 VDC).If line voltage is between 0.8 V and 2.0 V it is considered "uncertain". Not sure at all of this, but it seems that some of the latest keyboard models like PT-88 require pull down resistors in the control and data bus lines. Earlier models like PT-80, MT-18, PT-82 or PT-87 do not require pull down resistors, but they are recommended anyway.

This is the pinout and signal names of ROM PACK cartridges:

Pin#	Name	CPU	ROM	Description
11	!D3	IN/OUT	IN/OUT	CPUs D7. ROM data/address bus bit 3. Inverted.
10	!D2	IN/OUT	IN/OUT	CPUs D6. ROM data/address bus bit 2. Inverted.
09	!D1	IN/OUT	IN/OUT	CPUs D5. ROM data/address bus bit 1. Inverted.
08	!D0	IN/OUT	IN/OUT	CPUs D4. ROM data/address bus bit 0. Inverted
07	R/!W	OUT	IN	READ/!WRITE or OP. '1':CPU reads from data bus data nibbles written by ROM, '0':CPU writes address nibbles to data bus and ROM reads them.
06	CLK1	OUT	IN	CLOCK1, C1 or CLOCK_PULSE1. Same than CLK2 but shifted some microseconds.
05	CLK2	OUT	IN	CLOCK2, C2 or CLOCK_PULSE2.Same than CLK1 but shifted some microseconds.
04	?	?	?	Always '0'?
03	GND	PW	PW	Gnd = 0VDC
02	!CS	OUT	IN	!CHIP_SELECT.'0':ROM is selected, '1':ROM is NOT selected.
01	VCC	PW	PW	Vcc = 5VDC

This is how the CPU of the keyboard and the ROM PACK are connected:

The access to the ROM is always managed by the CPU (the controller) who uses !CS, R/!W, CLCK1, CLCK2 lines to read the memory through the 4 !D0...!D3 data/address llines. The bus access timings may vary slightly depending on the keyboard model, The CPU and the ROM share address and data information through the 4bits !D0..!D3 bus. The data and address information is written and read by the CPU and by the ROM from that bidirectional bus as nibbles (4 bit packets).

CLK1, CLK2: There are 2 independent clock lines: CLK1 and CLK2. Both clock signals are always identical: they have the same waveform and frequency, and the only difference between them is that they are slightly shifted one each other. Some websites refer to that clock lines as biphase clock.

CLK1 and CLK2 pulses are inverted, so the lines are normally at 5VDC, and go down to 0VDC on each clock pulse. The exact CLCK1 and CLK2 clock lines waveform and its frequency/period may vary deppending on the keyboard model. As can be seen on the CLCK1 and CLCK2 captures of different keyboard models, the period of the CLCK1 and CLCK2 can be between 10us and 100us, and the pulses may be arround 1us ( to avoid loosing them the cycle/sampling period should be at leas 1us/2 ). Time between CLCK1 and CLCK2 pulses may vary on different keyboard models. First models had the option to be tunned through a hidden potentimeter in the back of the keyboard and doing that also afected to the frecuency of that clock signals. In that older models the clock signals were permanently running. In later keyboars clock signals only run when the keyboard accesses the ROM. Their frequency is also lower and not adjustable.

Clock frequencies managed by ROM PACKs are not too high compared to nowadays standars, so one of the easiest and most reliable ways to emulate a ROM PACK with a microcontroller is to configure it to generate an interrupt on each CLK1 or CLK2 pulse. There, on the code of the Interrupt Service Routine, the other bus signals can be sampled to read or write data from the data/address bus. To grant that the code is executed fast enough and that changes in the state of the signals are not lost, a CPU with highest clock frequency/throughput is also recommended.

!CS: The !CS signal enables or disables the devices in the bus and the CPU must set it to '0' whenever it wishes to access to the ROM PACK, whether it is for reading or writing in the address data bus. This signal is also used in slightly different ways deppending on the keyboard models: in few keyboard models the signal remains permanently at '0' (it seems to be forced to '0') while in the others the signal is activated or deactivated when the CPU is going to access memory ( it can be seen on the attached logic analyzer captures ). On read commands, that is when R!W is '1', the !CS must be attended in combination with the device code.

R!W: CPU sets R/!W and !CS to '0' while it writes an address in the bus, and once it finishes writting that address it sets R/!W to '1' and !CS to '0' to indicate to the ROM PACK that it is ready to read the requested content. Then the device with the requested device code should answer by writting in the bus the nibbles at the address previously requested by CPU. If there are other devices in the bus they should keep their data lines at high impedance state. So when R/!W is '0' the CPU is writting the address of requested ROM PACK position, and ROM PACK should be readding and temporary storing that address. While CPU keeps R/!W to '1', the ROM PACK or the corresponding device, keeps writting the content of the successive requested addresses: ROM PACK autoincreases its internal address counter on each CLCK1 / CLCK2 complete cycle, and this allows to the CPU to read the content of successive memory addresses.

!D0...!D3: That lines correspond to the bidirectional address/data bus and they are used by the CPU and the ROM PACK to share addresses and data. When the CPU writes an address on the data/address bus, it does so in 5 cycles, writing 1 nibble ( 4 bits ) per bus cycle. All bits are inverted so reading '0xF' means '0x0', or reading '0x3' means '0xC'. Service manual & part list SK-8 indicates that the first address written nibble corresponds to the "OP Code", following 3 nibbles correspond to the address and last nibble to the "Device Code". The "Device Code" for the ROM PACK seems to be always 0x3 ( 0x0aaa3, where 'a' means an address nibble and the 0x3 the inverted 0xC ). Don't have precisse information of what is this "Device code" used for, but it seems that it was added to allow accessing different devices connected to the same bus. The 4 bits of the device code nibble would theoretically allow to connect up to 16 devices to the same bus ( from 0x0 to 0xF ), but the actual purpose of that "Device code" has yet to be confirmed.

The previous graphic of CASIO SK-8 manual does not clearly specify the number of bits dedicated to the "OP Code", the data/address and the "Device Code", but according to the drawn clock signals ( 2 CLCK1 and 2 CLCK2 pulses per nibble ) and the logic analizer captures, it seems that the first sent nibble corresponds to the "OP Code" and the last sent nibble to the "Device Code". Therefore, the other 3 nibbles in the middle should correspond to the address.

The captures with the logic analyzer seem to indicate that the three address nibbles do not address specific memory addresses, but rather memory blocks of 16 nibbles (8 bytes). To access a specific nibble of a memory block, the controller must first execute a write address cyle to write the block address to the bus and then continue with a read data cycle sending CLCK1 and CLCK2 pulses so that the ROM PACK delivers the following nibbles of the block until reaching the desired one. As all ROM PACKs are accessed through three address nibbles and as each three address nibbles points to a 16-nibble data block, it means that the addressable space is (2^12) * 16 = 65536 nibbles = 32768 bytes. However, as I haven't been able to find the datasheet of the M5268 or MN6404, I cannot confirm all of this. In fact, addresses defined in the ROM PACK header are codified with 6 nibbles ( 3 bytes ). Any appreciation or correction is welcome.

Anyway, all the ROMs that I have dumped extend from block address 0x000 to block address 0x3FF, and then the content repeats. It seems that, although there are theoretically 12 bits of block address, the ROM PACK only addresses the lowest 10 bits of the address, and that's why when accessing addresses 0x400, 0x800, and 0xA00, the content of the ROM repeats.

The inverted address nibbles are written in the bus from lowest to hightest ( first lower address nibbles then higher nibbles ). Once the CPU has written in the bus the "OP Code" nibble, the 3 nibbles of the memory address to read and the nibble with the "Device Code", it waits for a moment and then requests to the ROM to deliver the value of that memory address. The memory will deliver the inverted contents of the successive memory addresses as long as the CPU maintains !CS='0' and R/!W='1' and keeps moving the CLK1 and CLK2 pulses.

From the controller point of view (that is the keyboard point of view), the address/data bus can be in 3 differentiated states :

- Write address: in that state the controller writes an address in the address/data bus and the ROM reads it. It sets the !CS and R/!W signals to '0' and keeps toggling the CLCK1 and CLCK2 while it writtes all the nibbles of the following address to read ( with the corresponding "OP Code" and "Device code" ). Meanhwile the ROM cart keeps reading that nibbles written by the controller and updates its internal address register with that values.

To write an address in the bus, the controller first sets !CS and R/!W to '0'. Then it writes the first ( lower ) address nibble just on, or just after, the first inverted CLCK1 pulse ( it deppends on the keyboard model ). It keeps writting the following address nibbles just on, or just after, each two CLCK1 pulses. Once it has written the 5 nibbles ( 10 CLCK1 pulses ) it sets the address data bus on High Z state again.

- High Z: controller keeps the address/data bus in high impedance: the controller sets !CS and R/!W to '1' and the D0..D3 in high impedance. The ROM cart also set its D0..D3 lines to high impedance when it detectts !CS to '1'.

- Read data: in that state the controller reads the data written by the ROM in the address/data bus. It sets !CS to '0' and R/!W to '1' and keeps toggling the CLCK1 and CLCK2 while the device with the requested device code ( in the ROM PACK case 0x3 ) writes in the address/data bus the content on the address previously requested by the controller. The controller keeps reading the data nibbles written by the ROM cart in the address/data bus. After writting each data nibble, the ROM cart increases in 1 its internal address register in order to provide the content of the following nibble of the block on the next read cycle. It keeps providing the following data nibbles, by repeating this sequence until the controller sets !CS to '1'.

To get the data at the preivously requested address, the controller first sets !CS to '0' and R/!W to '1' and keeps toggling CLCK1 and CLCK2 lines. Then ROM places the first data nibble just after the first CLCK2 pulse. Following data nibbles are updated each two CLCK2 pulses, just in the pulse ( between the falling and raising edge of CLCK2 ). Every time the ROM has written a data nibble in the address/data bus it increases the value of its internal address counter in order to provide the following nibble on the following cycle. The process continues untill the controller sets the bus on High Z state again.

Following images are logic analyzer captures of the start of the song "1-Unterlanders heimweh" of RO_551 WORLD SONGS on different keyboards played by different keyboard models. They may help to undertand how do the CPU access the ROM PACK cartridge:

Previous captures show the signals sequence on the bus when keyboard accesses the cartridge content while it plays the selected theme. Other keyboard models such as the MT-800 do not access the cartridge while the play selected theme, instead they first load the selected song into the keyboard's internal memory and then play it from there.

The following example image is an example of the organization information and the themes in any ROM PACK cartridge.

Each theme has a header with the start address of each of its 3 channels code: the melody, the accompaniment and the chords channels start addresses. Each instruction in the melody and accompainment channels takes 3 bytes, while the instructions on the chords channels take 2 bytes each one.

In case you want more precise information, it is recommended to check the CASIO US4624171 Auto-playing apparatus patent, which describes in high detail the organization of the data inside those CASIO melodies cartridges (according to Google Patents, this patent expired on 2004-04-05). The details and precise meaning of the bytes inside each theme block is also described in that mentioned patent document US4624171 Auto-playing apparatus.