Dumping Korg i5m PCM ROMs – part 2 - Learning to Fail

Previously I have started writing on fixing my korg i5m (part-1). Removing the ROM chips was not fixing the problem but taking advantage of this opportunity, I have started trying to dump them out. The problem was that I was not sure if I am reading correct values or not. After working for hours and fiddling with address lines using an oscilloscope, I was able to get some consistent results. Sometimes some of the address lines was getting stuck resulting in repeating patterns in the dump. To make things worse, the memory layout of samples is not very clear except for GM1, which apparently just have 8 bit signed PCM data all aligned properly. After getting an acceptable output for this particular chip, I am pretty confident now that I am doing things right but have some connection issues due to contact resistance (or maybe CMOS-TTL incompatibility as someone over hackaday has suggested). Reading the contents of every chip and being able to sometimes get the same exact data out increased my confidence on the contents of the other chips although they are not perfectly aligned PCM data as the first one - thus harder to verify. I believe the odds of getting the exact same data with inconsistent connections is pretty low though. I am also sure that I have every possible hex value in the output assuring all data bits have proper connection. Here are the statistics (from 00 to FF on x-axis) of the perfectly aligned chip and a sample PCM waveform from its contents;

(BTW audacity is a great tool foor quickly checking PCM data) Now as I have dumped the contents, it is time for looking after the actual problem again. Resoldering ROMs back into place until I get all internal tests on i5 to pass (meaning no read errors on ROM lines), I started to think about possible causes. Other candidates on my mind are DRAM and SRAM chips that are temporarily holding sample data during playback. Disabling all the DSP effects on the device makes the output silent suggesting the problem is indeed on the digital output stage. I then started randomly shorting out RAM address lines together to make them become corrupt while listening on the earphones. Corrupting SRAMs resulted in locked states but when I have corrupted a particular RAM chip (which also luckily having spares on aliexpress), only the output was changing erradicaly, suggesting that this is used on the output stage. I have removed this chip but problem still there! This leaves only the co-processor used apparently as a DSP on the output stage, which is a fine-pitched and hard to find component, bringing this project practically to an end. I finally gave up. The i5m module will go to the parts bin as a spare if I find another one in the future to combine into one or fix my i5s. Only plan I have now is interpreting the memory layout of these chips and get all the samples out but I probably will not share the samples as they are Korg’s proprietary content. Reach me out if you have suggestions or comments.

Ali24th February 2022 at 08:00

archived comment

That’s great news! For the memory layout I think the easiest is experimenting with potential candidates using Audacity’s raw import. It supports different formats with different endianness. You may first try options that are native to the device you are using. i.e if it is a 32bit big endian device, starting with 32bit PCM is a good idea. There is the possibility that there are multiple banks which may interfere with the overall integrity but you should still be able to extract meaningful pieces of samples if you find the correct format.