0
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ Quite a task to reverse-engineer. Perhaps those EPROMS contain programs, or could contain data, or both. A processor is likely involved - which one? Peripheral chips may be involved - how are they programmed and at what addresses are they hard-wired? Burners often expect a serial protocol. Intel hex format is an example:en.wikipedia.org/wiki/Intel_HEX \$\endgroup\$ – glen_geek Oct 4 '16 at 15:50
  • \$\begingroup\$ Many years ago I wrote machine code and built a 2708 programmer with and for a National SC/MP. The process was to first set up the address lines, second, set up the data and then strobe it with a burn pulse. As I recall the 2708 got very hot during the burning process and they were, in the beginning, very expensive chips. \$\endgroup\$ – Harvard Oct 4 '16 at 16:11
  • \$\begingroup\$ I would start by using a serial sniffer and capture the RS232 communications between the PC and the Programmer WHILE sending a know parcel of data to the programmer. Personally, being retired, I would love the challenge. \$\endgroup\$ – Harvard Oct 4 '16 at 16:38
  • \$\begingroup\$ EPROM is just a non-volatile memory like flash, hard disk etc. You can't "write program for EPROM" because it only stores instructions and data for other elements like microcontrollers (or maybe gate-based sequential logic if it is very old and simple system) - You have to create program for whole system. \$\endgroup\$ – Jakub Rakus Oct 4 '16 at 18:40
  • \$\begingroup\$ I'm voting to close this old abandoned question because as so many have already explained, it is the unspecified system which will consume the program or data that determines what form it must have. The asker has not been back for years so it seems that the necessary information to resolve this by any means other than closure will never be provided. \$\endgroup\$ – Chris Stratton Jul 21 at 21:48
5
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Could you give some examples of a higher level language? Or maybe even point to some sample programs and how it's done? We just need help with the details getting started, then we should be good. \$\endgroup\$ – Russ Oct 4 '16 at 15:33
  • \$\begingroup\$ Probably the most common high level language used in embedded processing is some form of C. You can search Google for "Embedded C example programs" and see lots of examples. You will need a compiler that takes the C code input and outputs machine code for your specific processor. You can usually get one from the processor vendor or a third party. Once you compile the C code it will output a file that you can transfer to your EPROM burner. There are lots of details to work out, but that's the basic process. \$\endgroup\$ – John D Oct 4 '16 at 15:35
  • \$\begingroup\$ I know Pascal from way back, using it on a computer, just don't know the embedded part of the issue and how to get the Pascal program into a format the chip can use. But I'll look for some resources. \$\endgroup\$ – Russ Oct 4 '16 at 15:50
1
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ 32k is nothing to be afraid of when programming in C++ even with some object oriented code - depends on the application of course, but surely not out of the question. \$\endgroup\$ – Arsenal Oct 4 '16 at 16:24
1
\$\begingroup\$

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.

\$\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.