Author Topic: Reverse Engineering a Flash Card for a vintage music synthesizer keyboard...  (Read 1195 times)

0 Members and 1 Guest are viewing this topic.

Offline STM32Topic starter

  • Newbie
  • Posts: 9
  • Country: tr
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.



« Last Edit: November 15, 2022, 11:58:54 am by STM32 »
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8526
Since they're x16, if every 2 bytes are reversed, you need to swap D0-D7 and D8-D15.
 

Offline STM32Topic starter

  • Newbie
  • Posts: 9
  • Country: tr
Yes, you were correct. It was Endianness. I used dd conv=swab to 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.
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 6403
  • Country: es
So you expect us to figure out without having any files to check?
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline NiHaoMike

  • Super Contributor
  • ***
  • Posts: 9321
  • Country: us
  • "Don't turn it on - Take it apart!"
    • Facebook Page
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).
Far 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.
Cryptocurrency has taught me to love math and at the same time be baffled by it.

Cryptocurrency lesson 0: Altcoins and Bitcoin are not the same thing.
 

Offline STM32Topic starter

  • Newbie
  • Posts: 9
  • Country: tr
So you expect us to figure out without having any files to check?

Of 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.
 

Offline STM32Topic starter

  • Newbie
  • Posts: 9
  • Country: tr
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf