Hi,
I'm trying to do some reverse engineering, but don't really have a clue how to go about it.

We have a "pizza oven" for reflowing PCB boards. It is an APS GF-12A, and it has a controller board with a Z80 and two ROMS.

I'm trying to fiddle with some of the temperature limits in the program (max temperature is set to 550, and we need 650 fahrenheit).

I got a rom reader, and pulled the data off the two roms. The first one is called GF12 Right.hex and the second is GF12 Left.hex (both attached).

I tried to run the programs in an emulator called zemu, but didn't get very far. I don't know how the emulator works, or if I can get it to display what screen of the oven would display.

I also poked around in the ascii translation of the hex data, but couldn't see anything that popped out.

I'm not sure if disassembling will be fruitful, because there won't be much in the way of comments, labels, or variable names.

Anyhow, I was curious what people thought; what the best approach would be, or if there isn't a rat's chance in hell that I can achieve my goal.

 

Hi,
I'm trying to do some reverse engineering, but don't really have a clue how to go about it.

We have a "pizza oven" for reflowing PCB boards. It is an APS GF-12A, and it has a controller board with a Z80 and two ROMS.

I'm trying to fiddle with some of the temperature limits in the program (max temperature is set to 550, and we need 650 fahrenheit).

I got a rom reader, and pulled the data off the two roms. The first one is called GF12 Right.hex and the second is GF12 Left.hex (both attached).

I tried to run the programs in an emulator called zemu, but didn't get very far. I don't know how the emulator works, or if I can get it to display what screen of the oven would display.

I also poked around in the ascii translation of the hex data, but couldn't see anything that popped out.

I'm not sure if disassembling will be fruitful, because there won't be much in the way of comments, labels, or variable names.

Anyhow, I was curious what people thought; what the best approach would be, or if there isn't a rat's chance in hell that I can achieve my goal.

You might be able to disassemble the code, but I think it would be easier to hack the temperature probe feed and tell the MPU that the temperature of the probe is about 100 °F too low.

 

I would assume if the pizza oven was capable of safly running at 650 Fahrenheit then the temperature limit in the program would not be set to 550.

 

Both very good points.
I could swap in type J thermocouples, which fudge the reading. I'd prefer for the controller readings to be accurate, so that I remove the guess work from the thermal profile.

I know the oven will run safe at 650F. Actually, it's a funny story... The temp in each zone is set by pressing up and down arrows. When you try to set it to 551, it drops you back down to 100F.

I was probing the controller board with a multimeter, and I accidentally shorted out the main regulator pins. The controller reboot, but when it came back all the settings were scrambled, and the set points were above 550. As long as I don't set them back under 550, the oven will actually run hotter. I tried it out and it worked like a charm.

Of course, if I mis-set them, or if the controller resets, I can get restricted again. Hence the desire to hack the code.

 

I did a fast web search and it seems there are only two disassemblers out there that work on windows: IDA pro ($$$) and Oshon Soft Z80 SIMULATOR IDE.

I used IDA years back and it was excellent but expensive. I've used another OshonSoft produce (an excellent PIC Basic compiler) and found it too excellent and inexpensive.

I can't say Oshon's will work for you with what you have but it is probably well worth a try.

Even with a disassembly listing it would still be hard to find the magic >550 comparison statements, but once you do so it should be an easy fix (like always fail or pass the comparison to eliminate the limit).

BTW: hacking the code in a piece of equipment you own for purposes of extending it's capabilities falls well within the boundaries of "fair use."

Selling such code does not. As I see no intent to sell this there's no need to nit pick this point.

 

BTW: hacking the code in a piece of equipment you own for purposes of extending it's capabilities falls well within the boundaries of "fair use."

Ah, but distributing the code does not. And he and AAC are currently distributing the code.

 

The code is useless without the equipment, and vice-versa. The machine probably over 30 years old, and is no longer manufactured in this form, and is no longer supported by the manufacturer.

I would find it difficult to argue that posting the ROM dumps in this forum for the purpose of this discussion is not fair use. Am I incorrect? If yes, how should I remedy that?

I haven't been able to find the hex value for 549, 550, or 551 in the instructions/data unfortunately.

 

There's a big problem trying to find any number above 255 in an 8 bit processor: it just doesn't exist! Decimal 550 would exist as nearby values of 2 and 38 (or 2 and 26 in hex) as the comparison needs be done in two steps on an 8 bit platform.

True story: I once worked for a company that made the sensor & controller that made sure there was enough water in a nuclear reactor. Unfortunately, either they or the company contracting this work lost all the source code for the controller (also a Z80). All that was available was the binary inside an EPROM (one E, they didn't erase).

I made several copies of that and left them in different places.

 

The code is useless without the equipment, and vice-versa. The machine probably over 30 years old, and is no longer manufactured in this form, and is no longer supported by the manufacturer...

Just saying. Copyright lasts for life of author + 50 years. Verbatim distribution of code is not covered under fair use.

 

Just saying. Copyright lasts for life of author + 50 years. Verbatim distribution of code is not covered under fair use.

I appreciate your concern, but I think fair use isn't a magic phrase that can be slung around in this way.

http://www.copyright.gov/fls/fl102.html

"Section 107 contains a list of the various purposes for which the reproduction of a particular work may be considered fair, such as criticism, comment, news reporting, teaching, scholarship, and research. Section 107 also sets out four factors to be considered in determining whether or not a particular use is fair.

-The purpose and character of the use, including whether such use is of commercial nature or is for nonprofit educational purposes
-The nature of the copyrighted work
-The amount and substantiality of the portion used in relation to the copyrighted work as a whole
-The effect of the use upon the potential market for, or value of, the copyrighted work"

 

As a way to get a successful result fairly easily, why not scrap the 1980's controller and buy a cheap programmable temperature controller from ebay? Some come with thermocouple and have digital displays etc.

 

Hi,
I looked at the ROM data (as HEX) the reason you are having trouble with disassemblers / emulators is that the file format is odd. I don't recognise it.

I has 3 byte address that always starts 20h instead of 00h. The rest of the address will be right for the page zero ROM (0000h - 7FFFh) but will need to be shifted up by 7FFFh for the page one ROM (7FFFh - FFFFh).

Then, after the address there is a 2 byte number that may be a check sum.

Can you tell me what the file format is?

Does your ROM reader default to starting at 200000h ? for some reason ??

What file format do you want it in ? I can convert it for you. ie what format does you disassembler / emulator expect ???

I can give you pointers as I am good with Z80.

I will go and convert it to something standard like intel format and disassemble it. Then I can see which is page zero and join the files into one in the correct order.

 

I changed the file format and converted it to a binary file to run it through a disassembler.

It didn't make sense as if the code is scrambled.

An old hardware trick once used to hide code was to change the address and data pins between the CPU and the ROM. Then change the ROM data to match the changes. I suspect that this trick may have been used.

Can you give me a connection list for the connections between the CPU A0 - 14 and D0 - D7 --- and the ROMs A0 - A14, D0 - D7 so that I can unscramble the ROMs ???

 

Does it good to upload the asm file, is it legal, no any problem?

 

Ok, I will get that info in short order. There's also a chance I screwed up the data readout; the reader was made in China, and the documentation and GUI leave room for wanting. I will double check it to see if I can get the addressing right. I may also be able to get a raw form of the data not translated or otherwise manipulated.

 

Also, please note that this is a Z180, not a Z80 as I previosly stated!

 

Ok. The good news is that the data and address pins are connected in the correct order. A0-A14 to A0-14, and D0-D7 to DQ0-DQ7.

I'm still not sure why the programmer writes the addresses starting at 20h. I was however able to save them in a bin format instead (attached). The bin format has some encouraging human-readable text (search for word AUTOMATED) and scroll.

I also re-saved the hex files. I noticed that sometimes the reader garbles the data if you don't turn it off when switching proms.

 

One more mistake - The built-in limit is 500 F, not 550 F as I said before.

 

The reason the lines start with :2000... is because the programmer is saving the data in an INTEL Hex formatting:

http://en.wikipedia.org/wiki/Intel_HEX

 

The reason the lines start with :2000... is because the programmer is saving the data in an INTEL Hex formatting:

http://en.wikipedia.org/wiki/Intel_HEX

Actually the lines are starting with 20 hex to denote a following byte count of 32, and the address is the next 4 hex digits.