How to write an EPROM program

Question

We've got some products that use 27C256 EPROMS.

The guy who wrote the original programs (many years ago) is gone and we'd like to make changes and write some new programs for some new products and keep it in-house.

We've got the burner and all that, so that's not an issue.

My question is very basic, how do you write an EPROM program? Machine language? C? Is it specific to the burner we use?

All we've got is the compiled version of the existing programs, so no help there reverse engineering it to see the original format.
I've searched online, but can't find any specifics on how to actually write a program from scratch.

Answer 1

There is no such thing as an "EPROM program" ... you need to know what the EPROM supplies its data to. Any such information you can add to the question may help, even a good quality photo of the PCB.

If that's a Z80 microprocessor (for example), there is such a thing as a Z80 program, which you may be able to disassemble (read the EPROM in the burner, write out as a hex file, probably INTEL HEX format), then run through a disassembler program to generate a source listing in Z80 assembly language.

At this point you may get lucky - a "hex dump" of the file, separate from the disassembled listing, will probably show you some ASCII strings - text that give you some clues what it does.

(Same is true for whatever other microprocessor was used ... if the EPROM stored the configuration for an FPGA you have a whole different problem).

Then comes the difficult bit ... understanding what it does, well enough to successfully modify it.

Even if it was originally written in C or another language, you're not, realistically, going to be able to recreate anything higher level than assembler from it.

Knowing what it does will also require intimate knowledge of the hardware design : for example, if it writes a number to an I/O port address, you need to know what hardware is connected to that port, and what that number means to that port... for example, if a UART is mapped to that address, it'll probably be mapped to 4 addresses, and one of those addresses will be its "Transmit Data" port. Then whatever number (say, 65) is written to that port will appear on an RS232 serial port - in this case as the character "A". (If it's written to the UART's Control port, read the UART's datasheet : it could disable the UART, or change the baud rate, or do something else altogether).

If you have all that knowledge then you have a laborious and tedious but possibly feasible task.

If you don't, (and possibly even if you do) then it is probably faster and cheaper to define exactly what the circuit does, and re-implement it from scratch using whatever microcontroller you are most familiar with (Arduino etc) - in C, C++, Ada etc.

Answer 2

At a basic level the EPROM is going to contain binary op-codes and data for the specific processor you are using. ("Machine code/language").

How you generate those op-codes is up to you. You can write machine code directly, use an assembler, or use a high-level language to generate the instructions. From there, you download the (probably) hex file generated into your burner and burn the EPROM.

It sounds like you need to learn the basics of embedded programming, so I would look for resources online or local classes you can take.

Answer 3

The last time I used 27C256 devices, all the code was in assembly (it is a 32k x 8 device after all; setting up C call stacks would have to be very optimised!)

If you have the original files, there may be tools to describe programme flow (this will depend on the specific processor / controller).

You would need to try and find the original assembler (doing hand coded machine code is very laborious and even more error-prone than assembly); if it was done in machine code, it would need to be re-assembled to make sense of the programme itself.

To do new programmes would require knowing the fundamentals of embedded programming from many years ago (most current embedded programmes are done in C or C++, perhaps Java) and a solid understanding of the processor instruction set.

That said, there are some C compilers that are extremely efficient; investigate if one is available for your target processor; C code (although it has its limitations and foibles) will still likely be more maintainable and less error-prone than assembly.

Answer 4

I don't know what you mean by "gone," but if you don't mean "dead" then I think you should first do everything possible to make contact with him. It's quite likely he has the source code, somewhere. You should find out if there is any possibility to secure the source code from him. This is far and away the easiest path ahead. Even if he left in difficult circumstances. You just need to find out what might motivate him and see if you can get the source that way.

If he is dead or for whatever reason you simply cannot contact him under any circumstances, then the path is harder. I assume you know what functions are necessary and I'd suppose you have all the schematics. So that's a start, of course.

For the x86 (and you don't say what processor this happens to be) the languages used will either be assembly, C, or a mix of the two. I worked on EPROM systems back in the mid to late 1980's, for example, which used Lattice C and assembly mixed together and other systems which just used assembly only. It would be rarer, but possible still, to have used only C. For example, Intel was selling an embedded linker at the time which could be used with Microsoft C or Lattice C. And Borland had been using their C compiler (even after selling the rights, the new owner continued this with Paradigm C++ Professional) for embedded work, as well. I have a summer2k edition, along with their link/locator.

For other processors, you need to investigate the available coding environments -- both "back then" as well as "now" -- and make some decisions about how to proceed.

The process is usually something like this: Use the C compiler to generate object files, as appropriate. Use the assembler to generate more object files, also as appropriate. Use a specialized linker/locator tool to combine these object files and then to locate them into a binary output file (or more than one, if your system uses more than one to make the EPROMs.) Take the binary output file and select it with your EPROM programming tool. Drop in a blank EPROM. Verify that it is blank. Program the EPROM. Plug it into your board. Boot and test. Old EPROMs are erased (UV eraser box) in order to make them blank and re-usable.

To figure out how to direct the linker/locator, you do need to understand the memory map of your EPROM(s). Otherwise, you won't know exactly where to locate things. It's even possible that the EPROM is directly driven by some hardware or used to boot a processor through some funky mechanism (the ADSP-21xx supports something like that -- very weird, very specific to the device.) So you may need to figure that out, as well, if your processor (assuming you have one) boots out of EPROM rather than running code and getting data directly from one as an addressed device.

You really do NOT provide enough information about your system. If you had, I might have written less than I did here.