I started to analyze the K4r. The first thing I did is to dump the contents of the Firmware EPROM and the Wave ROMs.
I dumped the firmware just to verify that the content on the chip matches the firmware image that I already had on disk, which it does.
Wave ROM dumps
In contrast to the K1, the K4 has three Wave ROMs in total.
From left to right: Kawai K4 Wave ROM chips U40, U39, U38
Nothing unexpected so far. As the K4 claims to be a 16 bit sampler, it was expected that it needs more storage for the samples.
After having dumped all of them, which was very easy due to them being socketed this time, I loaded them into my wave editor to take a first look. I imported the raw data as 16 bit and listened.
Analyzing Wave ROM chip data
While I had no issues with chips U39 and U40, chip U38 (the rightmost one in the picture above) sounded like garbage. What I also noticed is, that the former two chips sounded a bit distorted, had a lot of noise and the pitch seemed to be pretty high.
I looked at the data in a hex editor and was surprised to find content that much more looked like 8 bit samples rather than 16 bit samples. This can be seen by adjacent bytes constantly rising or falling, as below:
I changed the import format and loaded them again.
To my surprise, chips U39 and U40 sounded just fine now! A little bit of 8 bit noise, but nothing unexpected.
I guessed that the K4 somehow creates 16 bit samples by combining the contents of the chips together. But I had three chips only, where are my remaining 512k of data that I would need? Maybe the samples are 12 bit?
Chip U38 is special
I took a closer look at chip U38, the chips that only produced random noise so far.
The end of the chip data raised my attention as it looked like sample data:
What do we see here? We see eight least significant bits of a sample. This proved that this is not „random“ data but actually raw sample data. It furthermore cleared up that this chip does not contain a nibble for each of the other two chips to create 12 bit samples.
If this chip contains the LSB of another chip, to which chip does this data belong?
This can be tested by looking at the frequency spectrum of all three chips. Obviously, for chip U38 this is mostly noise, but not everywhere. For U39 and U40, we see regular frequency spectrums of sample data.
Do you see it? There is a relationship between the two chips U38 and U39.
Getting 16 bit samples out of two chips
I wrote a small program which combines the contents of these two chips to form 16 bit samples and loaded the result into my wave editor.
Gotcha, now we have 16 bit samples. If you look at these two pictures, you can see the difference immediately. The lower picture has got a much lower noise floor and it sounds much cleaner.
What about chip U40 then? I also tried to merge chips U38 and U40 but this did not work out, as expected. As there is no data left, the conclusion is that chip U40 is used as a source for 8 bit samples.
Although Kawai claimed that the K4 is a 16 bit synthesizer, this is only partially true as only half of the sample data is 16 bit, the other half is 8 bit.
What they did to hide it is to move all samples with lots of noise, like flutes, the choir, cymbals, snares and others to chip U40 which holds 8 bit sample data.
Samples without lots of noise like the piano, basses, acoustic guitar and others are stored as 16 bit samples. Chip U38 carries the 8 bit LSB while chip U39 8 bit MSB.
What I also found out is that the single cycle wave forms have more multisamples and the PCM wave forms are now partially multisamples, too! Which should give a quality boost compared to a K1.
Nevertheless, the K4 is more similar to a K1 than one might think. Most chips are identical, the firmware dumps look quite similar (same velocity curves, KS curves etc.) and the K4 even has got lots of 8 bit samples still!
I was not 100% happy with my waveform recordings, I outlined it briefly in one of my previous articles, where I explained how I recorded them.
The recordings still had the issue of being quite large in size, and more importantly, they contained noise. It’s not just simple noise from some amplifiers (that one is also there, but very low). The K1 resamples the waveforms pretty badly and the aliasing that this produces is clearly audible.
Don’t get me wrong, of course, I want to recreate the aliasing and the dirtyness, as it is part of the K1s character, but it does not help if it is already part of the waveforms, which should be as pure as possible as they are pitched during playback. The aliasing needs to be added at a later stage in the audio generation process. Details about it can be found here.
Furthermore, working with recordings from a device introduces a lot of errors in general: The data has to go through The K1s D/A converters & amplifiers, the cables that go from the K1 to the recording interface and the A/D converters of recording interface itself all introduce small unwanted modifications to the signal
K1 Wave ROM Chip Data
I was browsing the K1 service manual, my intention was to repair my broken K1m, which still suffers from broken envelope attacks, when I noticed the pinout of a chip that had the letters WAVE ROM behind it.
If you have read some of my other articles, you might know that I’m a bit into Home Automation things. For this, I not only buy ready-to-use devices, but also create my own, using Arduinos or similar microcomputers. Given that the pinout of this chip is pretty straightforward, just some address lines and some data lines, I wanted to give it a try.
The service manual lists the used chip as being a HN62304BP. I’ve searched the internet and found a data sheet. I verified that the pinout was identical to the Kawai layout.
More information that I’ve taken from it: Its size is 4Mbit, or 512KiB and the operating voltage is 5V.
5 Volts perfectly fits an Arduino, but having 19 address lines and 8 data lines, my Arduinos and NodeMCU devices that I have laying around lack plenty of GPIOs for this job. Therefore, I ordered an Arduino Mega 2560 R3 which has a lot of them, 54 digital GPIOs in total.
Preparing the Arduino Mega
I wrote the Arduino code upfront before my order arrived. I used a Google Spreadsheet to help deciding which pins of the Arduino I use to keep the wiring chaos at a minimum. Then, I created some mapping tables in the Arduino Code.
After it arrived, I wired a breadboard to the prototyping shield that came with the Arduino according to the specifications of the ROM chip. After having everything wired up, I was quite happy that it didn’t look too chaotic, definitely maintainable.
I did a dry run to verify that the code works fine, fixed some issues here and there and then started to desolder the K1m Wave ROM.
Desoldering the Wave ROM
Given that the chip is not socketed , I had some work to do 🤔 I didn’t want to risk ruining the K1 at all costs so I had to be extra careful! The plan was to put the chip back into place after having finished reading it.
I started by adding fresh solder to the pins and furthermore connected each pair of two pins together. This was a preparation for the next step, I heated the new joints up again and used a pump to remove it. The result was pretty good already, some pins required some manual extra work but after a while I was able to remove the chip.
After the dump had finished, I had a first look at it, mainly to verify that my code to dump the ROM was not faulty, I didn’t swap any address lines and such.
I have not been able to find any text or something that would tell me if the dump was correct or not. I verified that all 8 bits are not always zero and not always one, but I couldn’t guess if the data is correct just by looking at it in a hex editor. As it is a Wave ROM, assuming it might contain mostly audio data, I converted the text dump into a binary and loaded it in a wave editor.
When I saw and heared it I was so excited! 😍 Although something was obviously wrong, at the same time, it verified two important of things:
I didn’t swap any address lines or data lines
The ROM had no encryption that I would’ve had to fight against
Though I recognized some of the used waveforms, they appeared to be heavily distorted. I imported them both as signed PCM and unsigned PCM data, but that didn’t help.
I browsed a bit in the ROM and found the sine single cycle waveform.
Apparently all negative waveform values were inverted. I added a small code snipped to the wave ROM text-to-binary converter to fix it:
// convert audio data to signed PCM data
for (size_t i = 0; i < data.size(); ++i)
unsigned int d = data[i];
if (d >= 0x80)
d = 127 - d;
data[i] = d & 0xff;
After I did that and loaded the wave ROM again I got goosebumps! 👍All waveforms were present, in a quality that is, obviously, much better than anything I had before.
Wave ROM data analysis
Having the data as audio data, I was able to verify that there is only audio data in it, there is no meta information, such as offsets, any kind of init pattern, whatever. The whole ROM consists of audio data only.
I began analyzing the file by adding markers to the waveforms. What I got quite quickly is, that every waveform has a length that is a power of two. The lengths are different, ranging from 4096 samples (some of the drums) to 32768 samples (choir, strings etc).
Knowing that every length is a power of two helped a lot to set the markers at their correct positions, resulting in perfect loop points.
What I also noticed: There are only 30 PCM waveforms in it, although there are 52 PCM waveforms that you can select. This is because the waveforms are used multiple times. For example, there is a one-shot Voice (Wave 233) and a Voice Loop (Wave 238). They are based on the same waveform. This is the same for all loops.
The reversed waveforms that you can select are not present, the K1 generates them in realtime by just playing the waveform backwards.
All „Alt“ loops are not present either. The K1 plays them as forward-backward-forward-… loops.
All „Omnibus“ loops just play through a larger range of the wave ROM. If you listen to the audio above, you can even hear all of them. For example, Omnibus Loop 8 plays a loop consisting of 6 waveforms: F. Guitar, A. Guitar, Piano Noise, Pan Flute Attack, String Attack and Bowed String. Its easy for the K1 because that is the layout in the Wave ROM. The picture below illustrates it.
On the left side of the picture, you can see how I named my markers. I use these markers to map segments of the Wave ROM to waveforms 1-256 when I load the Wave ROM in the VSTi plugin.
Single Cycle Waves
The single cycle waves are stored in the Wave ROM, too, but in a much different way.
It took me a while to understand what I am looking at. Initially, I thought that my conversion code is broken and that there is still a signed/unsigned/something mismatch.
One of these cycles is always 128 samples long, something that I’ve read previously somewhere. And each cycle seems to exist 5 times. Why? And these snippets are definitely not loopable.
What helped me to understand this is to compare the wave ROM data against my recordings:
What the K1 does is, it uses the cycle twice. To form a loop of one waveform, it uses it once in forward mode, the second part is the same cycle, but inverted and negated. If I do this manually in the wave editor, the result looks like this and is a perfect match to the recording:
So what is stored in the ROM are half-cycles only.
The next topic was to figure out why there are always 5 repeats for each waveform. I quickly verified that this is always the case for all single cycle waveforms by calculating the following:
The total data length for all single cycle waveforms in the Wave ROM is 130560 samples
Divided by 5 (number of repeats), the result is 26112
Divided by 128 (length of one cycle), the result is 204. This is the value that we expect as the K1 contains 204 single cycle waveforms
In one of my previous articles, I talked about that some of the single cycle waves are multisamples, and this is what the 5 variations of each waveform are for.
Now the only problem was to find out when to use which multisample. I had another look at my multisample markers that I’ve put into my recordings and noticed that, if there is a multisample transition, they always happen at the same notes. Something that I just didn’t notice. After looking at each of my recordings and writing down the notes, I had a list of 5 different notes that were used, exactly what I was looking for. The final mapping for multisamples is:
Midi Note Number Range
48 – 59
60 – 71
72 – 83
84 – 127
You may have noticed that the range of one multisample is one octave and that there is support for 5 octaves in total. The reason why I didn’t recognize all multisamples while recording is, that not every waveform uses them. For many waveforms, the data in each multisample is identical.
After adding support to load the Wave ROM in my emulation, the quality increased significantly! 😎 Some of the not-really-good sounding singles now perfectly match the real K1. Especially bell-type sounds that use the amplitude modulation were missing the very low and very high frequencies, now they are as present as on a real K1. I’m going to post new audio demos soon so you can hear the improvements.
One final step is missing: I still have to put the Wave ROM chip back into my K1m. Instead of adding it directly, I’m going to add a socket to the K1m board and insert the Wave ROM there. The socket didn’t arrive yet so I have to wait some days before doing so.
Update: The socket has arrived and the K1 is fine again.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.