[N8VEM: 18569] Help with deciphering 8088 roms

Discussion:

lennart rolland

2014-08-20 18:42:06 UTC

Hi all!

This is my first post. I was recommended to ask my questions here after
talking about my project on different CNC related forums, because someone
felt (rightly so) that it would be more on topic here.

So I have these old 1985'ish CNC machines (computer controlled milling
machines for metal). They are of very high quality and was quite popular at
the time. I bought one in need of repairs, and a second one as a spare
parts machine. After getting both of them into physical shape, I needed to
configure the computer controller. Basically this is a large box with a CRT
monitor and some buttons that is used to operate the machine. It has a
registry of around 100 configuration parameters, some that are general
settings and some that are machine specific calibration. When the machine
was new, this data would be delivered on a mini cassette. Unfortunately I
don't have the cassette for any of my machines. It is also possible to load
the parameters from RS232, but it is NOT possible to save the values OUT
via RS232. Finally there is the option of entering them manually through a
very old fashioned keyboard at the front of the controller. Needless to
say, the manual typing takes ages.

After fiddling about for a while it became evident that I would need to
find a quicker way to change and send the configuration settings to the
machine so that I can test the parameters one by one and determine what is
the correct settings. Since I am a software developer at trade, I decided
to make a small GUI where I could change the settings and then export them
directly over RS232 to the machine. But there is only one problem with this
approach: I don't know which format the data needs to be in to successfully
send them over RS232.

I decided to step it up one notch, and peaked inside the computer. To my
supprise the "main" board had an intel 8088 CPU and 4 detachable EPROMS. So
I went straight to ebay and both a cheap EPROM reader (TOP853) and now I
have 4 shiny binary files on my desktop. So now I am looking for clues to
how I can disassemble the data on these chips. In my naive approach I tried
to use objdump -b binary -m i386 -d D0.BIN but it didn't output anything. I
did actually write a miniscule of assembly code back in the day but that
was a very long time ago and I am sure the tools of the trade has come a
long way since then.

So, what would you recommend that I do in my search for intelligence in
these chips? Would it be feasible to run them in an emulator? What
preparations/conversions would I need to perform to have them work? I don't
know much about the object code loading practices that were common in 1985
(or today for that matter). Are there any good graphical dis-assembly tools
that would allow me to browse the instructions and follow the jumps around
and look at segments of data etc?

I am on Ubuntu, but I have a windows box handy as well.

All tips and tricks are welcome.

Thanks!

--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/d/optout.

John Coffman

2014-08-21 03:05:30 UTC

Permalink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
The disassembler, NDISASM, a part of the NASM (Netwide Assembler),
is a good tool to disassemble ROMs.  Links to the NASM project will
be found on 'sourceforge.net'.  Consider using version 0.98.39 for
disassembling code from an 8088.  You don't need any of the ia64
opcodes. 
 
--John 
 
 
 
On 08/20/2014 11:42 AM, lennart rolland wrote:
<blockquote
cite="mid:9129523b-0afe-4c2a-8eb9-6ef159e7c26e-/***@public.gmane.org"
type="cite">
<div dir="ltr">Hi all! 
 
This is my first post. I was recommended to ask my questions
here after talking about my project on different CNC related
forums, because someone felt (rightly so) that it would be more
on topic here. 
 
So I have these old 1985'ish CNC machines (computer controlled
milling machines for metal). They are of very high quality and
was quite popular at the time. I bought one in need of repairs,
and a second one as a spare parts machine. After getting both of
them into physical shape, I needed to configure the computer
controller. Basically this is a large box with a CRT monitor and
some buttons that is used to operate the machine. It has a
registry of around 100 configuration parameters, some that are
general settings and some that are machine specific calibration.
When the machine was new, this data would be delivered on a mini
cassette. Unfortunately I don't have the cassette for any of my
machines. It is also possible to load the parameters from RS232,
but it is NOT possible to save the values OUT via RS232. Finally
there is the option of entering them manually through a very old
fashioned keyboard at the front of the controller. Needless to
say, the manual typing takes ages. 
 
After fiddling about for a while it became evident that I would
need to find a quicker way to change and send the configuration
settings to the machine so that I can test the parameters one by
one and determine what is the correct settings. Since I am a
software developer at trade, I decided to make a small GUI where
I could change the settings and then export them directly over
RS232 to the machine. But there is only one problem with this
approach: I don't know which format the data needs to be in to
successfully send them over RS232. 
 
I decided to step it up one notch, and peaked inside the
computer. To my supprise the "main" board had an intel 8088 CPU
and 4 detachable EPROMS. So I went straight to ebay and both a
cheap EPROM reader (TOP853) and now I have 4 shiny binary files
on my desktop. So now I am looking for clues to how I can
disassemble the data on these chips. In my naive approach I
tried to use objdump -b binary -m i386 -d D0.BIN but it didn't
output anything. I did actually write a miniscule of assembly
code back in the day but that was a very long time ago and I am
sure the tools of the trade has come a long way since then. 
 
So, what would you recommend that I do in my search for
intelligence in these chips? Would it be feasible to run them in
an emulator? What preparations/conversions would I need to
perform to have them work? I don't know much about the object
code loading practices that were common in 1985 (or today for
that matter). Are there any good graphical dis-assembly tools
that would allow me to browse the instructions and follow the
jumps around and look at segments of data etc? 
 
I am on Ubuntu, but I have a windows box handy as well. 
 
All tips and tricks are welcome. 
 
Thanks! 
</div>
-- 
You received this message because you are subscribed to the Google
Groups "N8VEM" group. 
To unsubscribe from this group and stop receiving emails from it,
send an email to <a moz-do-not-send="true"
href="mailto:n8vem+unsubscribe-/***@public.gmane.org">n8vem+unsubscribe-/***@public.gmane.org</a>. 
To post to this group, send email to <a moz-do-not-send="true"
href="mailto:n8vem-/***@public.gmane.org">n8vem-/***@public.gmane.org</a>. 
Visit this group at <a moz-do-not-send="true"
href="http://groups.google.com/group/n8vem">http://groups.google.com/group/n8vem</a>. 
For more options, visit <a moz-do-not-send="true"
href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>. 
</blockquote>
</body>
</html>



-- 
You received this message because you are subscribed to the Google Groups "N8VEM" group. 
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:n8vem+unsubscribe-/***@public.gmane.org">n8vem+unsubscribe-/***@public.gmane.org</a>. 
To post to this group, send email to <a href="mailto:n8vem-/***@public.gmane.org">n8vem-/***@public.gmane.org</a>. 
Visit this group at <a href="http://groups.google.com/group/n8vem">http://groups.google.com/group/n8vem</a>. 
For more options, visit <a href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.

Nikolay Dimitrov

2014-08-23 17:28:02 UTC

Permalink

Hi Lennart,

Post by lennart rolland
So, what would you recommend that I do in my search for intelligence in
these chips?

Post by lennart rolland
Would it be feasible to run them in an emulator?

It's theoretically possible, but you'll have to provide a realistic
environment for the emulation, like all custom peripherals that are
mounted on the PCB. If you're really desparate, I can suggest you to
attach a logic analyzer to the board, and trace all IO accesses of the
CPU, this way you can guess what peripherals are attached and what's
their typical communication pattern. Get your favourite 8088 simulator
and write plugins that emulate the peripherals, so you can run inside
your code and watch how it behaves. You should even be able to exercise
the serial protocol this way.

And a final word of warning - please evaluate how dedicate you're for
this task. It could turn out that the journey is rather long and without
expected ROI. It's at least theoretically possible to replace the CNC
electronics with some open-source hobby-CNC board that's documented and
theoretically easier to interface. You need to decide yourself.

Hope that this bunch of ideas helps more than breaks. Wish you success
in this project.

Kind regards,
Nikolay

Alan Cox

2014-08-23 17:52:40 UTC

Permalink

I think its a big assumption that the CNC machine will be using 16450/550
UARTS. It's clearly very old in design as it would otherwise have used an
801C88 so may well have older style uarts too. The 3f8/2f8 convention is
also just a DOSism it's unlikely to be followed by non PC hardware but you
might be lucky.

I would start by looking through the ROM for copyright strings. See if
there are any that indicate it's actually some kind of embedded PC class
board (mentions of BIOS, useful makers names etc).

Also look through the code for sequences of the form

mov bp, sp
add sp, somevalue
[lots of code]
mov sp , bp
ret

if you see those then the firmware was probably written in C and you can
start breaking out the C functions to analyse (assuming reverse engineering
is legal in your country).

What sort of system are we talkng here - Hurco, Denford Orac, VMC100 ?

For some of these machines the manufacturers still provide software in DOS
form (Denford certainly do) and I think Ultrimax drives most of the really
old Hurcos still and for them the master tapes in rs232 form are available
via amts inc.

Post by Nikolay Dimitrov
Hi Lennart,

Post by lennart rolland
So, what would you recommend that I do in my search for intelligence in
these chips?

Here's what I can suggest - check which is the UART chip mounted on the
PCB. The usual suspect there is a chip from the 16450/16550 family.
Carefully check whether the UART IRQ line is attached to some
interrupt-controller or to the CPU, so you can know where to look for the
corresponding code.
Finally, look in the disassembly code for IO port access in the range of
3F8-3FF, where COM1 is typically attached. It's possible that your
machinery has different layout, but you need to check this out - there
could be some boot messages (POST/BIOS/firmware/whatever) that can hint you
for the proper IO address. Another method is to reverse-engineer the IO
address-decoding circuit for the UART - just watch out which ICs are
generating signals for the RD/WR/CE pins. Yet another method is to use
logic analyzer attached to the CPU pins to confirm which is the IO address.
When you understand for sure which is the proper IO-address for the serial
port, look for it's number in the disassembly. Look for the surrounding
- initialization, should be done once or rarely, should set baud-rate
registers and other parameters
- sending code
- receiving code
Depending on the (already verified) fact whether the UART IRQ is attached
to the CPU (directly or via PIC), you'll know whether to look for the
receive code in the IRQ handlers addresses or just in the program body
(same goes for the transmit complete notification code).
You need to build a good knowledge about which functions handle the
communication code, so you can see who calls these functions, and how the
received data packet is later parsed by the code. This will give you a
fairly good understanding at least for the "alphabet" of the communication
protocol - start of packet, command IDs, payload, CRCs, end of packet. But
still you'll have to experiment a little bit more to see which commands
affect which features of your machine (be careful not to injure yourself!).
Would it be feasible to run them in an emulator?
It's theoretically possible, but you'll have to provide a realistic
environment for the emulation, like all custom peripherals that are mounted
on the PCB. If you're really desparate, I can suggest you to attach a logic
analyzer to the board, and trace all IO accesses of the CPU, this way you
can guess what peripherals are attached and what's their typical
communication pattern. Get your favourite 8088 simulator and write plugins
that emulate the peripherals, so you can run inside your code and watch how
it behaves. You should even be able to exercise the serial protocol this
way.
And a final word of warning - please evaluate how dedicate you're for this
task. It could turn out that the journey is rather long and without
expected ROI. It's at least theoretically possible to replace the CNC
electronics with some open-source hobby-CNC board that's documented and
theoretically easier to interface. You need to decide yourself.
Hope that this bunch of ideas helps more than breaks. Wish you success in
this project.
Kind regards,
Nikolay
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/d/optout.

Nikolay Dimitrov

2014-08-23 19:11:33 UTC

Permalink

Hi Alan,

I absolutely agree with this. It's totally possible that the machine is
entirely different from a conventional DOS PC. Still there are finite
ways to attach the UART, and most of the time the UART chip label is
still there, so one can get good clues about the HW and possibly how SW
interacts with it.

Also, my practice shows that usually engineers like to stick to already
known and working solutions, which means that embeddeding a 8088 board
can be the way to go if there was already some prototyped SW and the
engineers wanted to reduce the risk, but I totally agree that this is
just a possibility and not a guarantee.

Kind regards,
Nikolay

Andrew Bingham

2014-08-24 00:59:46 UTC

Permalink

A friend of mine bought an old Bridgeport CNC mill to use on his projects,
and he ended up getting rid of the original controller entirely. He
replaced it with a Mini ITX computer running LinuxCNC, with a parallel port
sending the step commands to a parallel port->stepper driver. (You need a
real parallel port, USB adapters won't work).

He was able to buy everything and get it up and running relatively quickly.

Unless you are married to that old CRT interface and the features it has vs
something more modern, I would strongly consider just replacing it....

Andrew B

Post by Alan Cox
I think its a big assumption that the CNC machine will be using 16450/550
UARTS. It's clearly very old in design as it would otherwise have used an
801C88 so may well have older style uarts too. The 3f8/2f8 convention is
also just a DOSism it's unlikely to be followed by non PC hardware but you
might be lucky.
I would start by looking through the ROM for copyright strings. See if
there are any that indicate it's actually some kind of embedded PC class
board (mentions of BIOS, useful makers names etc).
Also look through the code for sequences of the form
mov bp, sp
add sp, somevalue
[lots of code]
mov sp , bp
ret
if you see those then the firmware was probably written in C and you can
start breaking out the C functions to analyse (assuming reverse engineering
is legal in your country).
What sort of system are we talkng here - Hurco, Denford Orac, VMC100 ?
For some of these machines the manufacturers still provide software in DOS
form (Denford certainly do) and I think Ultrimax drives most of the really
old Hurcos still and for them the master tapes in rs232 form are available
via amts inc.

Post by Nikolay Dimitrov
Hi Lennart,

Post by lennart rolland
So, what would you recommend that I do in my search for intelligence in
these chips?

Here's what I can suggest - check which is the UART chip mounted on the
PCB. The usual suspect there is a chip from the 16450/16550 family.
Carefully check whether the UART IRQ line is attached to some
interrupt-controller or to the CPU, so you can know where to look for the
corresponding code.
Finally, look in the disassembly code for IO port access in the range of
3F8-3FF, where COM1 is typically attached. It's possible that your
machinery has different layout, but you need to check this out - there
could be some boot messages (POST/BIOS/firmware/whatever) that can hint you
for the proper IO address. Another method is to reverse-engineer the IO
address-decoding circuit for the UART - just watch out which ICs are
generating signals for the RD/WR/CE pins. Yet another method is to use
logic analyzer attached to the CPU pins to confirm which is the IO address.
When you understand for sure which is the proper IO-address for the
serial port, look for it's number in the disassembly. Look for the
- initialization, should be done once or rarely, should set baud-rate
registers and other parameters
- sending code
- receiving code
Depending on the (already verified) fact whether the UART IRQ is attached
to the CPU (directly or via PIC), you'll know whether to look for the
receive code in the IRQ handlers addresses or just in the program body
(same goes for the transmit complete notification code).
You need to build a good knowledge about which functions handle the
communication code, so you can see who calls these functions, and how the
received data packet is later parsed by the code. This will give you a
fairly good understanding at least for the "alphabet" of the communication
protocol - start of packet, command IDs, payload, CRCs, end of packet. But
still you'll have to experiment a little bit more to see which commands
affect which features of your machine (be careful not to injure yourself!).
Would it be feasible to run them in an emulator?
It's theoretically possible, but you'll have to provide a realistic
environment for the emulation, like all custom peripherals that are mounted
on the PCB. If you're really desparate, I can suggest you to attach a logic
analyzer to the board, and trace all IO accesses of the CPU, this way you
can guess what peripherals are attached and what's their typical
communication pattern. Get your favourite 8088 simulator and write plugins
that emulate the peripherals, so you can run inside your code and watch how
it behaves. You should even be able to exercise the serial protocol this
way.
And a final word of warning - please evaluate how dedicate you're for
this task. It could turn out that the journey is rather long and without
expected ROI. It's at least theoretically possible to replace the CNC
electronics with some open-source hobby-CNC board that's documented and
theoretically easier to interface. You need to decide yourself.
Hope that this bunch of ideas helps more than breaks. Wish you success in
this project.
Kind regards,
Nikolay
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/d/optout.