2
\$\begingroup\$

Not sure if this is the correct place to ask such a question, but here goes.

Ok so I mess around with an old 80's drum machine a lot. It's based around an old 8031 Processor Program code is stored on a 27c256 eprom and sound data is stored on 2 x 27c040 mask roms.

The 27c256 in this machine holds the OS and also the data table containing the names of the various drum sounds and the start addresses for each sample. and in this chip there is data either side of the table. I already make customised eproms for the machine, but I am limited to only 'replacing' the data in this table, which confines the machine to 47 different sounds.

I had an idea, and want to put it out to the heads to see if I'm talking rubbish or not..

The existing OS has quite a lot of space left at the end of the file (FF) Is it at all possible to hack the firmware so that at the point where it would read the table, insert the instruction to JUMP to another part of the firmware and read in a table that is larger in length with more samples etc. (lets say 100 sounds instead of 47 or something) and then at the end of this, JUMP back to where the end of the old table resides in code.

In essence I'm talking about bypassing a part of the code and replacing it with a larger piece. I know that of course I cant just make whats already there bigger as it would move the rest of the code, which as I understand would break then.

I'm currently replacing the data in the table by just patching the bytes that are already there.

Perhaps I'm talking jibberish, perhaps I'm not.

thanks Brad

\$\endgroup\$
3
\$\begingroup\$

What you're proposing sounds absolutely feasible. You're not talking jibberish! If there's unused space in the main EPROM, you can patch the code to jump out of the main part into a small routine in the presently-unused part, and jump back again.

You will probably need to disassemble the existing 8031 code to determine where to apply the patch. You may be able to modify the existing code without changing its size. Or you may be able to overwrite instructions with NOP (no-operation) if the new code is smaller. The logic in the EPROM may do some sort of test to make sure that no more than 47 samples are used. You'll need to find all the places where this test is done and increase the 47 to some higher value.

\$\endgroup\$
  • \$\begingroup\$ thanks for giving me a little hope, John. I can't actually program, I just know a little that allows me to make (often wrong) assumptions. I actually have a software emulator that uses the actual rom images from the real machine, SO I think this could be used to do some testing on. I guess then I need to find out what those jump instructions are and try to copy the existing table to a new location and see if that works. then move onto perhaps making the table bigger. Now how might i go about getting a dissassembly of the code thats actually usefull in any sense? \$\endgroup\$ – Brad Holland Nov 23 '14 at 0:45
  • \$\begingroup\$ @BradHolland Se if you can find an 8031 disassembler -- somebody's bound to have written one! As for those data tables, they're likely to be addressed by indexed load-accumulator instructions rather than by jumps. But then agan, maybe the 8031 is peculiar in this respect, or maybe the original programmer used jumps for some reason. Sounds like you're ready to do some exploring with the ROM, though! \$\endgroup\$ – John Honniball Nov 23 '14 at 10:50
3
\$\begingroup\$

The approach you are talking about is called "patching" and is done all the time to fix bugs. Put in a jump to an unused area, add a few instructions in the unused area, then jump back to rejoin the original code.

If you can't find a disassembler write one! It will be a good way to learn the basics of programming and to become familiar with the 8031 architecture and instruction set. The disassembler can be written in any language and on any machine that is convenient.

\$\endgroup\$
3
\$\begingroup\$

Agree with the other two answers about patching; there was a comment about finding an 8031 disassembler. (Note 8031, 8032, 8051, and 8052 are all the same microcontroller, just slightly different memory options.)

Install the free SDCC - Small Device C Compiler http://sdcc.sourceforge.net/ (Not affiliated with San Diego Comic-Con, which often appears first in google search of SDCC...) This free toolkit includes SDCC itself (a C compiler), and some support tools for simulating and debugging the hex codes. For what you're doing, the tool that will be most useful to you is the simulator.

Open a command-line prompt and start the 8051 simulator (assuming your hex code is in a file called yourFileNameHere.hex and you've installed SDCC\bin on the path):

s51 yourFileNameHere.hex

Within the simulator, type help to print help about commands. Type dc to show disassembly of the 8051 instructions. run runs the whole program, and step runs just the next instruction and then stops. You can use this to trace through what the original code is doing, this may help point the way towards what you will be patching and how.

I'm not sure whether it's possible to modify/patch the code from within the simulator itself, all I could find was a fill command. So you may want to use a hex editor such as Frhed http://frhed.sourceforge.net/en/ to enter your patch into the hex file, and then reload it into the simulator to test using the download command.

Source control is your friend in a situation like this. Git, subversion (svn), fossil-scm.com, all fine choices and free. Think of it like climbing a mountainside: move a little bit, make some progress, and commit that checkpoint. Move a little further, do another commit. If you take a risk and slip and fall (i.e. get the code badly messed up), it's easy to go back to the last checkpoint that worked so you don't end up losing hours of work.

The SDCC installation itself includes a pretty decent C compiler, if you're inclined to go that route. If you end up writing a lot of code, you can use SDCC to compile it either from C or from assembly into hex code. But if you're just going to be patching an existing memory image, and you don't have the C source code that builds that hex code, then s51 is the only tool you'll be using.

A search for 8051 instruction set turns up several valid sources. Of the top search results that I see, ateml.com and silabs.com are manufacturers of 8051 based microcontrollers, and keil.com sells compiler/debugger tools. (Side note: my employer maximintegrated.com still makes 8051's under the Dallas Semiconductor part numbers DS89C450.)

Hopefully this should be enough to get you going!

\$\endgroup\$
2
\$\begingroup\$

I'm going to disagree with most of the other answers here -- I don't think you will need to jump to a new section of code at all -- just patch some pointers in the code that's already there.

In the existing code, there should be addresses in the code that point to the beginning of the table(s) you want to expand. You apparently have already discovered these addresses if you are patching the data in these tables.

So you do need to disassemble the code, and discover where these addresses are located. Once you have relocated the tables past the end of the existing code, you just need to replace the start addresses of the tables with their new values.

In addition to the addresses of the start of each table, it is possible that the program is also checking for the end of each table, which you need to look out for. (The reason for doing so would be to insure the user is not trying to access a drum sound beyond the end of the table.) The code could either being using the ending addresses of the table, or a count of the number entries in the table, or the table may have a zero entry at the end (in which case you wouldn't need to patch anything).

\$\endgroup\$
  • \$\begingroup\$ This is all such very helpful feedback. thank you guys. \$\endgroup\$ – Brad Holland Nov 24 '14 at 5:43
0
\$\begingroup\$

Thanks for all the help so far.

So I have disassembled the code so far, and then I found exactly the point at which the sample location and sample name table starts in the hex file (0x6BFD) I then searched the disassembled code and found a statement like this: L0179: 2E36 906BFD MOV DPTR, #06BFDh

So, going back to address 2E36 in the Hex file, sure enough I saw 2 bytes saying 6B FD.

I then copied the table data to a blank area of the file and changed that address accordingly, the machine boots up and works just fine.

I guess now I need to see if I can start hacking away at it to see If I can now make the machine address more samples :)

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.