Programming / Reverse Engineering Sampler OS ?

[studioscience]

Hello, I have some older vintage Samplers which have OS/software loaded on Eeproms.
I am interested in learning how to write/modify OS, reverse engineer, etc.

In particular older 12 bit samplers like the E-Mu SP-12/1200 or Sequential Circuits Studio 440.

I believe the latter is built around a Motorola 68000 CPU (Mostek).
I am not even sure what languages I would need to know to disassemble & anaylze something like this.

I have a very basic programming background, in Perl, Python & some C, but no embedded or assembly/machine language - so at this moment I don't even know where to start.
However I will read & learn whatever it takes.

I can read the Eeproms with a Eeprom programmer & see stuff in editors like Winhex or Hackman, though I don't know if thats much help at all.

My goal is really to create new OS & customize features to keep these samplers alive.

Can anyone provide some insight?

Thanks!

[blue hell]

studioscience

You're nearly there, just add one "r"

Erm I mean ... you used the word disassemble, you'd want a disassembler for that.

A disassembler usually is quite specific for a certain processor or at best it will handle a family of similar processors, So you'll have to know about the details of the processor. Also you'd need to have some good picture of the peripheral chips connected to the processor as you'll have to do a lot of guess work on the disassembly listing as to what an operation at a certain memory or i/o address could possibly mean in terms of functions being performed for the machine in question.

It has been a while since I last looked into disassembly tools, but there used to be ones with nice features. Like the possibility to tell it what piece of code would actually be data (like a lookup table or string data), or the possibility to add comments to the disassembly, or the possibillity to add symbols to the system, like being able to give subroutines, memory cells or i/o locations a name.

You'll have to google a bit I think to find things that work for you. Ideally you'd want to have a combination of an assembler and a disassembler where the output of the disassembler is suitable as input for the assembler. An inbtegrated text editor could be very handy.

To complicate matters the ROM code might have been obfuscated, for instance address or data lines could have been swapped or part of the code might be encoded. All of this should be solvable though with some extra time and possibly writing a tool that de-mangles the ROM image, just don't be too disappointed when a disassembly at first just seems to give nonsense results.

[DrJustice]

Hi studioscience!
to electro-music.com.

You need a 68k users manual and programmers manual, a 68k disassembler and lots of spare time. Starting your assembly experience with a big'ish reverse engineering project like this is quite a challenge, but it's not impossible.

Since you have already read the EPROMs you can make binary file of those and use a disassembler to see the raw assembly code. It's practically a necessity to have the schematics for the machine in question as well as the datasheets for the peripheral devices (LCD modules, UARTs, DACs/ADCs etc.). It is also crucial to find out how the CPUs external interrupts are used. In general you then need to find out how the address decoding of the EPROMs is handled and which address your particular CPU starts executing from. In older/simpler computers the ERPROMs will usually start at address 0 and this is also where most CPUs starts executing from after a power-on reset. From there you just have to follow the disassembled program step by step - in this process you will learn 68k assembly _very_ well.

Since you now should have worked out where the IO addresses are from the schematics and the datasheets, you can catch all reads and writes to the peripheral devices and refer to their datasheets to work out exactly what is happening where. If the machine uses any proprietary chips you may have to use some educated guesses to find out how they're handled The same applies if there's any programmable logic (PAL,PLA,PLD,GAL) in use; thes are sometimes used for address decoding and state machines. For the cases where some unknown chips are at work, a logic analyzer may be of great help in mapping out their function.

As you find out how the program works and identifies data regions, you will have to write this down in the form of a nicely cleaned up, labelled and generally readable and commented assembly source. A new EPROM image can now be built from this source using a 68k assembler. This image should match the contents of the original EPROMs - burn a set and verify that everything works as it should. If all is well up to this point you can start modifying the program, provided that all aspects of your analysis and subsequent recreation of the original was thorough, correct and fully understood.

There's no magic bullet, only hard work.

DJ
--

[DrJustice]

Ahhh... I see Bue Hell beat me to it - Hey, I could've saved a lot of typing

DJ
--

[blue hell]

[DrJustice]

[studioscience]

I appreciate the warm welcome!

Yes it's a huge undertaking, but i gotta start somewhere...
I've already got the .Bin file, I think.

There are 2 Eeproms which host the OS/Software.
MS / LS configuration.
I read both, then `unified` them using Winhex.
Saved it as a .bin (also .hex as well).

I try to look at the raw data but it is indeed just jibberish to me right now.
I don't even see comments or anything.

I' downloaded the 68000 reference manual, wow, this will be quite a read.
hopeully I can poke around & eventually find my way thru.

For starters it would be cool & fun to say re-arrange some of the boot-up text or just rename some of the text names for certain functions. This would get me going, but at the moment I am still blindfolded & don't even see where I would do this.

Can you recommend a good 68K Disassembler?
I've downloaded a few I google'd up so far, Easy68K, FlexSim 68K but I can't seem to get them to give me any useful info from this .Bin file.

[blue hell]

I'd first try to find out from the 68000 docs what the start address for code is, i.e. the value of the instruction pointer after reset. At that point there should be valid code in the eproms (otherwise the thing wouldn't boot).

There is one thing that possibly complicates matters a bit, when the processor's starting address is a low memory address the eeprom probably was mapped into the address space starting at zero but otherwise you'll have to make an educated guess as to where the eeprom was sitting in the address space, then see if the disassembly makes sense, maybe making a new guess.

Re. the place where strings reside, you could try to make an ASCII dump of the bin and then see if there is any text you recognize. That is when the text was encoded as ASCII, which probably but not necescerraly is the case.