14 Jun
2006
14 Jun
'06
6:08 p.m.
Chuck Guzis wrote:
Having unknown hardware in your hands isn't,
IMOHO, nearly as bad as
unknown software. Consider my conundrum right now...
I've got a diskette with software (no documentation beyond how to stick it
in the slot on the machine) for a computer that a customer wants to emulate
on a PeeCee, the last remaining sample of the original hardware having
Not sure I understand what *you* are being asked to do...
- reverse engineer the code?
- develop emulators (simulators) for the I/O devices?
- etc.
flown the coop. No engineering documents at all. The
instruction set
(from the disk) appears to be 8086, but the OS is unknown to me and from
the looks of it, the disk is loaded into memory as a single 240K image. I
Do you know what format the disk image is in? I.e. is it recognizeable
as a DOS FAT-12, etc. (gives you some clues)
can figure out the load address by explicit segment
references. From the
very few ASCII text strings in the code, this is apparently a
multithreaded, interrupt-driven OS.
Can you share those strings? Or, are you bound by NDA?
They might be recognizeable messages to identify the OS
(QNX, VRTX, etc.)
From the scant documentation, the box came with a
keypad, an LCD(or plasma
or some-such) readout and a diskette drive with an RS-232 port. Otherwise,
ASCII searches yeild no error messages, prompts, or anything that would
allow me to quickly determine control flow. I have absolutely no idea of
the peripheral configuration. This is circa 1981-82.
Given the timeframe -- and your description of the peripherals -- it
could likely be an 80186 design. (IIRC, that was available around
'81/82). This gives you a *little* more information (assuming it
turns out to be true) as the 186 had some onboard peripherals
(DMA, timer and some few IRQ's, IIRC). This gives you some idea
of the support complement that went with the processor.
Given that, you could track down how each of these appear to have
been used (to get a *better* idea of what the balance of the
hardware was). I like starting with timer routines as they
get you into the code far enough UP from the bottom so that you
get a picture of what's talking to what... yet not TOO high up
that everything is lost in abstraction.
So, where do I start? I could put it on an emulator
and attempt to trace
program flow, but given the nature of the OS (event-driven) it's not going
to be easy. I can locate a few ISRs, and from their appearance, the box
doesn't use an 8259 PIC (no EOI sequences at the end of the ISRs).
If this were a hobby thing, I wouldn't care about the time I put in--but
the customer wants a quote.
Any suggestions?
Run it through a disassembler and look at the output to
convince yourself what type of CPU it is. An emulator (I assume
you mean a "simulator" and not an ICE) could be of some help
(no worse than a disassembler ?) but without hardware to talk
to, I suspect much of the code will just hang...
grep(1) the disassembled code for I/O instructions. I'm more
hardware oriented so I like to work bottom up. Nailing the I/O
devices first helps a lot, IMO.