Reverse engineering

Hi,

I have a few "user interfaces" for a piece of medical kit that I would like to repurpose for use at a local non-profit.

The boxes are ~pentium 90 vintage machines running a *severley* pruned down NT4. Aside from their physical form factor, the big draw for them is the integrated touch panel.

As the boxes are highly integrated (not COTS machines), the touch panel controller is a "special".

Without investing much time, I have been able to locate an EXEcutable that appears to implement the touch panel driver ("mouse emulator"). And, a quick peek inside suggests that it is a resistive overlay. I suspect the driver is actually talking to the A/DC's directly (i.e., there isn't another microcontroller that just handles the touch panel and, perhaps, talks to the main processor via a serial port).

I'm looking for ideas on how to reverse engineer the touch panel interface without a lot of effort (I will need to reimplement it under a different OS). I don't tinker with MS software so I'm pretty clueless as to how to proceed.

I have other touch panel *monitors* available but they are considerably larger and not packaged as nicely as this touch_panel-display-computer.

Thanks!

--don

Reply to
D Yuniskis
Loading thread data ...

You can set it up as a mouse HID device. There should be four wires to the resistive touch panel. These should go to the keyboard/mouse controller's A2D port. If you have USB (very unlikely for P90), then it's very simple. Otherwise, multiplex into the 8051/2 controller.

By the way, I am working on a open platform USB keyboard/mouse controller using AVR.

Reply to
linnix

NT doesn't have native USB support! There are (or, at least, were) third-party USB stacks for NT4 but who knows if they are still available.

-a

Reply to
Andy Peters

Perhaps I wasn't clear enough in my original post. :< I have no desire to reinvent the wheel. This is "donated time" on my part so I'd like to keep it as productive as possible. If this was not a criteria, I would have no reason for trying to rescue these machines as I have nicer kit to play with IF I WANT TO START FROM SCRATCH (I don't! :> )

I was hoping to find pointers on how to look at what the "driver" (executable) is doing and just mimic that in the system I will eventually load *onto* the machine. I.e., I can do anything (in software) that the existing "driver" is doing so why tinker with the hardware?

The box won't be running NT once I figure out how the "driver" works (*under* NT).

Reply to
D Yuniskis

I don't understand exactly what you're trying to do. My guess is that (a) this "driver" is not really a "driver", but more like a daemon, and (b) there is a .SYS file you don't know about, loaded by the "driver". The "driver" is either just a loader for the .SYS file, or more likely (unless you see the touch panel as a pointing device in Device Manager) the driver program is grabbing touch data and stuffing WM_MOUSEMOVE and other messages into the message queue.

How is the panel connected to the PC anyway? It's not clear from your posting. You seem to say it's not connected by a serial port, so how exactly IS it connected? If the mainboard has a direct connection for the touchscreen, then it probably has a hidden onboard RS232 or PS/2 interface.

Reply to
larwe

Oh yes, BTW - if this is all integrated, you may find the touchpanel stuff is built into the KBC, which is why you don't see a separate micro. But a 4-wire to RS232 interface IC is typically only a 16-SOIC anyway and might be labeled as an ASIC.

Reply to
larwe

People here would like to help you, if you would tell us what this "piece of medical kit" is.

I see people guessing at what they would do with it, but without some details of "what it is", its only guessing.

If this equipment is available surplus, maybe some of us can actually look at it and see whats inside to work with.

Reply to
don

If I had thought there was any realistic chance of someone finding another like it someplace, I'd have considered that worth mentioning. I suspect they are few and far between (?).

It is called an "FCR ID Terminal". Feel enlightened? ;-)

I suspect I will just pull the laptop drives out of them and toss the rest -- seems to be pretty commonplace nowadays to treat hardware as "disposable" :(

Reply to
D Yuniskis

Is this it ??

formatting link

Reply to
don

Yes. Crappy photo. The slit to the right of the display is a mag card reader. The round grey circle in the upper right is just a power switch.

The top "edge" ("side" seems confusing in this context :> ) has most of the connections -- shown in one of the little photos. From left to right (wrt the photo):

- AC inlet w/ master power switch above

- barcode reader (8 pin circular DIN)

- ps2 keyboard

- ps2 mouse

- 10BaseT

- video out There is a single ISA slot (empty in this photo) with three RJ11's (?) beneath and a "reset" button.

I suspect the RJ11's (labeled "Remote 1" and "Remote 2") are possibly for something as simple as a switch closure? Each implements just two conductors (though that can mean damn near anything!)

One of the side "edges" has brightness and volume controls (pots) and a 3.5" floppy. The other "edges" are empty.

The ISA slot in the units that I have is filled with a three port (?) card. Each looks to be a 10BaseT style (female) connector accompanied by two LED's labeled "RT" (receive transmit?). I suspect these are either simple serial ports (EIA232) or party-line busses (485) to communicate with the mechanism for which this serves as the user interface.

Nothing inside appears to be COTS -- with the possible exception of the mag card reader (I'm relying on memory, here, as it has been quite some time since I rescued these boxes and decided they might be worth using -- their form factor/packaging makes them a win as I can simply fasten them to a wall at eye level without having to make room for display, "computer", power strip, etc.). The fact that they are relatively low power, no fan noise, and, presumably, designed for continuous duty is another plus.

The fact that there are only three of them and replacements would be unobtainable (the folks listing these for $1,000 each are obviously dealing with a different market :> ) is a big *liability*!

Reply to
D Yuniskis

I've examined the timestamps on the various files to identify those that "look like add-ons". There are no "unusual" .SYS files.

OTOH, there is a TouchDrv.exe file (interesting choice of name, eh?) that is apparently exec()-ed at startup (I have no idea what mechanisms NT uses to run programs at startup). If I KILL the process having that name, the touch panel stops working.

Since it is easier to work from the top *down* (i.e., OS down to hardware), it seems likely that an examination of the internals of TouchDrv.exe will provide some insight on what this "driver" *consumes* in order to *produce* mouse events.

At 170KB, I doubt it is just acting as a loader!

AFAIK, NT4 does not have "Device Manager". Nor can I figure out how to get a list of hardware devices probe()-ed during startup.

It doesn't *appear* to be connected via a serial port. The panel is not a COTS device (complete with "controller"). Of course, they may have integrated the controller on one of the various PCBs within. And, done so in any of a number of different ways.

I had originally assumed they would have taken this approach since people designing devices like this usually don't bother trying to economize on hardware by having *the* processor do

*everything* (which is more common in resource constrained markets).

E.g., the box has a barcode reader, mag card reader, touch panel, NIC and all the regular trappings of a "PC" but with no COTS parts (IIRC, the mag card reader appeared to be a COTS module -- probably interfacing through a serial port). I would have assumed touch panel, barcode and magstripe would *all* be "smart" modules talking to the "computer" via serial ports.

If PS/2, it would have to be in addition to the keyboard and mouse ports already on the machine (see another post of mine for more details)

Reply to
D Yuniskis

You can get an idea from "Devices" in Start -> Settings

--
ArarghMail912 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
 Click to see the full signature
Reply to
ArarghMail912NOSPAM

I did not ask how it appeared to be connected, I asked how it was connected. Connector, intermediate board, etc.

This is a technical support conversation where the customer is intentionally obscuring the details that might solve the problem; this eats my patience very rapidly.

Reply to
larwe

Look for a four pins or two pairs of two wires. Most resistive panels are hooked up that way. The chip we use has a build-in resistor to frequency conversion. It could be external op-amp or 555. There are many way to do it.

Reply to
linnix

So disassemble TouchDrv.exe looking for IN and OUT instructions (mostly OUT). Somewhere, you will find a sequence that sets the touchscreen x and *x switches, triggers an ADC and reads the adc, likewise for y. Then there will be a little bit of offset and scaling before some sort of hook into mouse event ints. If you're asking what tools NT4 has to disassemble, how about debug.exe? You'll have to lookup the details of an exe file structure. Try finding a copy of Advanced MSDOS by Ray Duncan.

HTH, Bob

Reply to
Bob

As a thought, have you tried just grabbing an Ubuntu CD, booting from it, and seeing whether it just magically works? It's something of a long shot that the drivers might already be in and working, but it would only take about 20 minutes to try. If it miraculously manages to know how to talk to the touch panel then you've either a) got access to the driver source or b) got your new OS ready to go.

--=20 Rob Gaddi, Highland Technology Email address is currently out of order

Reply to
Rob Gaddi

It has been a long time since I wrote for NT, but I'm pretty sure it does not run apps with IOPL. I would bet a small amount of money that there is a serial or PS/2 interface involved, and an external "ASIC" doing the actual scanning.

Reply to
larwe

Doctor Dobbs Journal, May 1996 'Direct Port I/O and Windows NT' by Dale Roberts

The Giveio.sys driver is still in use by some hobbyists with legacy programmers.

--
Ian Malcolm.   London, ENGLAND.  (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
 Click to see the full signature
Reply to
IanM

OP claims there are no suspicious .sys files associated with the application, hence my comment stands.

Reply to
larwe

As I understand it, there may not be any sys files if the undocumented calls Giveio uses to grant user mode IO permission are incorporated directly in the application.

Medical electronics can't very well include a driver from hackerland . . .

--
Ian Malcolm.   London, ENGLAND.  (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
 Click to see the full signature
Reply to
IanM

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.