Reverse Engineering a Flash Card for a vintage music synthesizer keyboard... - Page 1
Forum section: electronics / general

author: STM32
author_rank: Newbie
timestamp: November 15, 2022, 11:46:17 am
content: Hello guys,First of all, I'm not sure if this is the most appropriate place to ask this. Moderators, you may move the topic at will!Well, I've been trying to understand how an 8 Mbytes flash card for a vintage synthesizer keyboard (based on 4x 16 Mbit parallel NOR flash chips) is read/written by its target system (the keyboard) as I plan to design an expanded version. The schematic of the keyboard's main board shows 12 additional CS signals that are not used (NC) on the flash card, which indicates possibility for future expansion of the flash card. Each CS line corresponds to one flash IC, which makes the total flash memory 32 MBytes if all 16 CS signals are used. The keyboard activates only one flash at a time, depending on the program chosen, which means it can only address 2 MBytes of memory.From design and PCB perspective, there's no problem making a new flash with 16 chips (32 MBytes). However, the problem is how to make the keyboard access them?I have been working on this for several months now and here are my observations so far:The keyboard recognizes the flash by reading a 4-bytes header written to IC1 during initialization of card. In order to understand what's going on under the hood, I had to de-solder the flash, read it, solder it back to the board dozens of times. Because the approach was time consuming and risky for both of flash chips and PCB, I eventually designed a breakout board that has a receptacle connector (same as that on the keyboard's main board) and a ZIF connector that routs all signals to my Xeltek SP3000U programmer. I can now read/write any of the 4 flash ICs in the card in matter of moments without having to worry about soldering/de-soldering.First thing I have noticed is that the values written inside the binary are somehow arranged in reversed order. Not sure if this has anything to do with Endianness. For example, if you look at any ASCII value for a file named "File01" loaded into the flash (using the keyboard) the values are arranged like this in the binary file read from flash IC: iFel10.I have done a series of analyses on the flash loading it with variety of files in different sizes, then reading the binary back from IC1 in order to do comparison and find differences in the binary. As far as I can understand, IC1 has 3 chunks of bytes that tell the keyboard how many free bytes are still free or how much was used on all 4 chips, location of files, and if I'm not wrong, which CS to switch in order to locate the file in the IC that corresponds to that CS.To sum it up, IC1 is used to store info about the files loaded to any of the 4 chips, their locations, and the space they occupy. I believe the only possible way for me to expand this card is to design a system that emulates the nor flash so I can modify the chunk of bytes written to the flash during write accesses by keyboard so I can make keyboard switch the other CS signals that are not used originally by existing card.Reverse engineering and binary gurus, any input is highly appreciated. Please let me know if there's anything unclear or confusing above. At least, understanding the arrangement of data inside the binary file would help me a lot to understand the other chunks of bytes written by keyboard, what are they, and how they relate to the files stored, their locations, and how the keyboard calls them across the 4 chips.

author: amyk
author_rank: Super Contributor
timestamp: November 17, 2022, 03:57:37 am
content: Since they're x16, if every 2 bytes are reversed, you need to swap D0-D7 and D8-D15.

author: STM32
author_rank: Newbie
timestamp: November 17, 2022, 11:39:44 am
content: Yes, you were correct. It was Endianness. I useddd conv=swabto swab bytes and now the ASCII values are readable. I'm now trying to understand the chunks of bytes written to IC1 and see whether I can do something to modify the flash based on that.

author: DavidAlfa
author_rank: Super Contributor
timestamp: November 17, 2022, 12:01:10 pm
content: So you expect us to figure out without having any files to check?

author: NiHaoMike
author_rank: Super Contributor
timestamp: November 17, 2022, 02:05:23 pm
content: Quote from: STM32 on November 15, 2022, 11:46:17 amFar more compact would be to OR the CS signals (AND if active low) and use a priority encoder to control additional address lines on a larger Flash chip.

author: STM32
author_rank: Newbie
timestamp: November 22, 2022, 03:31:34 pm
content: Quote from: DavidAlfa on November 17, 2022, 12:01:10 pmOf course not. I would love to share my findings and get some insight from other members here. I was waiting for some interaction from other members. On the other hand, I didn't want to give someone a puzzle to solve on their own. I made hundreds of experiments for the past couple days and now I have some new results. Hex Editor Neo was of great help with features like bit/byte swapping and coloring schemes.Let me know if you want to take a look at the binary files so I can upload some here.

author: STM32
author_rank: Newbie
timestamp: November 22, 2022, 03:54:11 pm
content: I had similar scenario in mind (ANDing CS signals) but unfortunately, that won't work. The keyboard writes a chunk of bytes in IC1 for every new file loaded to the flash card. So, basically IC1 is used to keep meta data about files stored across the flash chips, their locations, sizes, and how to recall them (which CS to activate). The good news is, the 16 CS signals appear on the receptacle connector of flash card (main board). Of those 16 CS signals, only four { CS[12..15] } are used on the original flash card. The other CS signals are connected to an address decoder to switch between 6 mask ROM chips on the main board.The only way for me to achieve the mission is to imitate the same mechanism used by the system when switching between the ROM chips. By loading multiple files to the flash, then reading data off IC1, I can see what happened. With the help of Hex Neo I was able to recognize some patterns inside the binary file.