OT-ish: Build-it stuff

[Don Y]

Chuck Guzis wrote:
> On 6/14/2006 at 11:08 AM Don Y wrote:
>> 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.

Yes, this is common of embedded products.  I will assume the device
served some *specific* purpose and wasn't "just a computer"...

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

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

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

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...)

> 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