14 Jun
2006
14 Jun
'06
8:05 p.m.
Chuck Guzis wrote:
Is the display known to be intelligent (e.g., addressed in ASCII
over a serial link, etc.)? It is quite possible that it is a dumb
display (7, 11, 14 segments, etc.) that is explicitly multiplexed
via software (typically in or tied to a timer IRQ). A common
hack was to use the same I/Os to scan the keypad at the same time
(i.e. treating it as a set of discrete SPST switches). Hence
the suggstion that you start poking around the timer IRQs
to see what hardware they talk to (of course, that was based
on the assumption that you *knew* where the timer IRQs were!
But, you can probably find them quickly by walking through the
crt0.o equivalent code...
But Shirley the customer knows what it was *used* for (?).
I.e. if the display was purely numeric or if it also conveyed
textual messages; the types of data shipped over the UART
(volume and rate are usually tied to the application... a
device that scans groceries at checkout moves data differently
than a device that processes telemetry from a weather satellite...)
On 6/14/2006 at 11:08 AM Don Y wrote:
Yes, this is common of embedded products. I will assume the device
served some *specific* purpose and wasn't "just a computer"...
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)
Oh, I've already identified the OS--it's MTOS-86--but that doesn't mean
it's known to me. The filesystem is CP/M-ish. But the app itself is tied
into the OS in a single unified whole--there is only one file holding
everything. Can you share
those strings? Or, are you bound by NDA?
They might be recognizeable messages to identify the OS
(QNX, VRTX, etc.)
No NDA here--messages are of the nature "Unexpected Interrupt"--about a
half-dozen such things, all of them, your basic debug message-and one
reference to an "integrated debugger"--and no application-specific
identifiable ASCII in the remainder of the code. My suspicion is that the
ASCII is sent to some diagnostic port and not to the main display. But the
code referencing the debugger messages might be a place to start. Given the
timeframe -- and your description of the peripherals -- it
could likely be an 80186 design. (IIRC, that was available around
'81/82).
Almost certainly not--figure 18 months average lead time from design to
production. I worked with early steppings of the 80186 back then and they
weren't ready for prime time yet. Besides, I don't see any references to
setting up the relocation block, which ought to be about the first thing to
occur. I'm very sure that this is a garden-variety 8086/8088--no
80186-specific instructions to be seen anywhere (e.g. PUSHA).
I'd look for I/O devices if I was certain of what they were. No keyboard,
just a numeric-type keypad, some kind of one-line display, RS-232 and some
sort of interval timer and a floppy drive. The RS-232 was used as a data
link, not to drive a terminal. Like I said, if this were a hobby thing, I'm sure
I could suss it out given
as much time as I needed. But I'm on the clock on this one.
I'd still stick with the "find the I/O's" approach and see
where they lead you. After all, that really is what you will
ultimately be doing for this project (since emulating the
purely computational stuff is straightforward).
Good luck!
--don
PS If you are *sure* that this is running MTOS-86, I can dig
through some boxes of OS documentation to see what I have for
it. At the very least, that would tell you how various
structures are initialized (from which you could guess at how
and where they are used.). Probably best to do that off-list