electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Articles  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links  |  Store
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » DIY Hardware and Software » Developers' Corner
Programming / Reverse Engineering Sampler OS ?
Post new topic   Reply to topic Moderators: DrJustice
Page 1 of 1 [8 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
studioscience



Joined: Sep 25, 2006
Posts: 2
Location: Cali

PostPosted: Mon Sep 25, 2006 4:45 pm    Post subject: Programming / Reverse Engineering Sampler OS ?
Subject description: Possible to Rewrite an OS for a vintage Sampler?
Reply with quote  Mark this post and the followings unread

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!
Back to top
View user's profile Send private message
Blue Hell
Site Admin


Joined: Apr 03, 2004
Posts: 20622
Location: The Netherlands, Enschede
Audio files: 150
G2 patch files: 318

PostPosted: Mon Sep 25, 2006 5:57 pm    Post subject: Reply with quote  Mark this post and the followings unread

welcome studioscience

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

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.

_________________
Jan
Back to top
View user's profile Send private message Visit poster's website
DrJustice



Joined: Sep 13, 2004
Posts: 2048
Location: Morokulien
Audio files: 3

PostPosted: Mon Sep 25, 2006 6:05 pm    Post subject: Reply with quote  Mark this post and the followings unread

Hi studioscience!
welcome 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
--

Last edited by DrJustice on Mon Sep 25, 2006 6:14 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
DrJustice



Joined: Sep 13, 2004
Posts: 2048
Location: Morokulien
Audio files: 3

PostPosted: Mon Sep 25, 2006 6:09 pm    Post subject: Reply with quote  Mark this post and the followings unread

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

DJ
--
Back to top
View user's profile Send private message Visit poster's website
Blue Hell
Site Admin


Joined: Apr 03, 2004
Posts: 20622
Location: The Netherlands, Enschede
Audio files: 150
G2 patch files: 318

PostPosted: Mon Sep 25, 2006 6:15 pm    Post subject: Reply with quote  Mark this post and the followings unread

DrJustice wrote:
Hey, I could've save a lot of typing Laughing


Not really .. you typed a lot of words I realized I had forgotten Very Happy

Another important thing is .. this could be FUN Exclamation

_________________
Jan
Back to top
View user's profile Send private message Visit poster's website
DrJustice



Joined: Sep 13, 2004
Posts: 2048
Location: Morokulien
Audio files: 3

PostPosted: Mon Sep 25, 2006 6:22 pm    Post subject: Reply with quote  Mark this post and the followings unread

Blue Hell wrote:
.. this could be FUN Exclamation

Absolutely! Just kidding around; I don't mind the typing at all - it's clearly a subject which we cherish around these parts of the forum Smile It was inspiring to hear studioscience wanting to get into this!

DJ
--
Back to top
View user's profile Send private message Visit poster's website
studioscience



Joined: Sep 25, 2006
Posts: 2
Location: Cali

PostPosted: Mon Sep 25, 2006 6:55 pm    Post subject: Reply with quote  Mark this post and the followings unread

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.
Back to top
View user's profile Send private message
Blue Hell
Site Admin


Joined: Apr 03, 2004
Posts: 20622
Location: The Netherlands, Enschede
Audio files: 150
G2 patch files: 318

PostPosted: Tue Sep 26, 2006 12:00 pm    Post subject: Reply with quote  Mark this post and the followings unread

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.

_________________
Jan
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Moderators: DrJustice
Page 1 of 1 [8 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » Developers' Corner
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
e-m mkii

Please support our site. If you click through and buy from
our affiliate partners, we earn a small commission.


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use