Are there any DOS 6.22 gurus out here - PST2 Tester

[ischmitz]

Hi everyone, read here on my recent project converting a KTS500 into a Porsche System tester. Everything works except a one thing that naggs the hell out of me. I am stuck I am looking for people who are very familiar with DOS 6.22 and machine programming. Especially TSR programs, interrupt vectors and that kind of stuff. The computer is essentially a 486 IBM clone with a PCMCIA card running WFW 3.11 on DOS 6.22 on an old AWARD BIOS with SIS 471 chipset. Pretty plain vanilla.

Now there is one little 2.2kb DOS TSR program that when loaded changes an interrupt vector at 0x60 and also tweaks the timer and mouse interrupts for DOS. It's main purpose seems to be to provide an interface for the tester software to write to a register controlling the contrast of the LCD display with certain key combinations. Besides that it checks for the presence of an API (in the BIOS I guess??) However, it also kills another essential function of the tester - talking to the PCMCIA port. And this is where the mystery begins....

I need to figure out exactly what that TSR program does and how it does it. I looked at it with IDA. So if IDA doesn't ring a bell [| maybe even +ORC] I probably lost you already, never mind....but if it does I am very interested to hear from you.

Cheers,
Ingo

[bhyde]

Originally Posted by ischmitz

Hi everyone, read here on my recent project converting a KTS500 into a Porsche System tester. Everything works except a one thing that naggs the hell out of me. I am stuck I am looking for people who are very familiar with DOS 6.22 and machine programming. Especially TSR programs, interrupt vectors and that kind of stuff. The computer is essentially a 486 IBM clone with a PCMCIA card running WFW 3.11 on DOS 6.22 on an old AWARD BIOS with SIS 471 chipset. Pretty plain vanilla.

Now there is one little 2.2kb DOS TSR program that when loaded changes an interrupt vector at 0x60 and also tweaks the timer and mouse interrupts for DOS. It's main purpose seems to be to provide an interface for the tester software to write to a register controlling the contrast of the LCD display with certain key combinations. Besides that it checks for the presence of an API (in the BIOS I guess??) However, it also kills another essential function of the tester - talking to the PCMCIA port. And this is where the mystery begins....

I need to figure out exactly what that TSR program does and how it does it. I looked at it with IDA. So if IDA doesn't ring a bell [| maybe even +ORC] I probably lost you already, never mind....but if it does I am very interested to hear from you.

Cheers,
Ingo

…well since I’m old enough to vaguely remember ms/pcdos and ASM, my guess would be that the TSR is chaining itself to the timer vector (IRQ 0x08) to refresh the LCD’s video at the usual 55ms rate. Your 0x60 vector (IRQ18) would normally point at ROM Basic in PCDOS but no one has used that for year (ok decades) and many people use it as a “free” user vector. Just out of curiosity, how is the LCD interfaced to the PC? Is it memory mapped into the normal video buffer or is it a serial device that uses a serial stream to animate the display? If it were a serial device it would probably modify the mouse vector (actually its just the comm port vector IRQ 0x0B and 0xC) to send data to the LCD. May wild guess on the PCMCIA card is that the card driver also uses IRQ 0x08 in a chain to perform some kind of periodic update function. The TSR could be installing itself in that chain without preserving the PCMCIA vector.

Oh and BTW, just to make things really complicated, not all interrupt vectors point at code. Some systems use it to point to data structures! Interrupt 1Eh points to a table containing floppy drive info. That’ll F’up the brain.

BTW: interesting project. glad I don't have a 996/997

[wrljet]

I know about such things. I was a contributing editor years ago to the books "Undocumented DOS" and "Undocumented Windows". If you remember back far enough to such things, I built the Windows support for the 386MAX memory manager.

I have reverse-engineered miles of code in the PST2 version 24 and have it running on a generic Windows 98 desktop PC or laptop. I built a wrapper that hooks many Windows (and some Bosch) DLL calls and either completely fakes the answers or simulates the functionality expected from the custom Bosch PC hardware.

I used IDA also, along with Microsort Virtual PC, and many of my old tools from years ago.

I have half a dozen or so ECUs from a 996/Boxster running on the bench talking to it.

Bill

[ghnat]

Wow, what a blast from the past. 16 bit code, oh fun... Used to write TSRs, ISRs etc.
wrljet - I read those books!

If the TSR checks for something in the BIOS look for an F000 segment, if I remember correctly. That should be where the BIOS is located.
is the TSR an EXE or COM?

[wrljet]

FWIW, I believe the special tablet PC the PST2 uses is a MicroDesign AIO486, or one very similar.

After lots of disassembly of the various pieces of the PST2 setup pgm, I found several calls and searches for strings which were associated with a particular BIOS, which happens to be the one used in the tablet. It's been a while and I don't remember the specifics, but I believe it scanned the BIOS for a particular string, and then backed up a few bytes and just assumed that would contain a FAR PTR to a BIOS entry point.

There is also a reload option on the PST2, to repair itself, including reloading the BIOS CMOS setup data, which helped in that research.

I finally found a Flash BIOS update for it, which I then disassembled to figure out what
the functions did.

[wrljet]

Is your TSR called by PWR_ISR.DLL ?

Address Publics by Value

0001:0730 @DoInt$qv
0001:0821 _TSR_Check
0001:08BA _InitPwrMon
0001:093E _DeInitPwrMon
0001:0986 _GetPwrStat
0001:09CE _ShiftContrast
0001:0A0F _TSR_CallAPI

[ischmitz]

Bob,

I confirmed with Norton Sytem Info the two interrupt vectors that get tweaked by the TSR: 08h (Timer) to 170D:0695 and 60h (user-range) to 170D:05B0 and hardware IRQ 0 (timer). The vectors point into the resident portion of the code in segment 170D.

Interrupt 60 (hex) is reserved for user programms. Without running the TSR the vector is 0000:0000. After running the TSR the vector points into the resident code range 170D:05B0. Timer was owned by Smartdisk beofore (first in chain since called last in autoexec)

The display of this computer is actually a simple VGA compatible device driven by a Western Digital 90C24A-ZZ VGA local bus video chip. It used to be a popular generic chip in the mid-nineties for laptops. And this chip probably has a register that controlls the contrast of the LCD pannel. The contrast value can be changed through the BIOS setup and is retained through power cycling. The contrast value is stored in the extended battery-buffered CMOS RAM. Once the TSR is loaded the + key increases the value and + decreases it when pressed while in the Porsche application. In DOS nothing at all happens. So the TSR does not monitor the keyboard.

If you use that key combo in the Porsche application without running the TSR prior the computer simply crashes hard and shuts off. I assume this key compo issues an interrupt 60h that simply runs into nirvana when the TSR did not set the vector properly.

When I run the TSR at the DOS prompt it identifies a "...MA-API" (whatever that means) when I run it on the actual hardware and then says Vector 0x60h is used. On a virtual DOS machine it does not find the MA-API but still sets the vector for interrupt 60h.

The PCMICA cards are controlled by Cardware V5.0. DOS loads tons of drivers through the config.sys and autoexec.bat. And with or without the TSR having been invoked the CISINFO utility can read CIS tuples from the PCMCIA card under DOS with no problem.

Now I need to figure out why the timer interrupt gets hooked. The TSR makes a difference in how the Porsche application measures timed events. Without the TSR things like automatic shutdown happen 2.66666 times too fast.....

Also, when the TSR was executed the Porsche application correctly identifies the computer with its Bosch part number and writes that to an ini file. Without the TSR it is identified at generic PC. So the question now becomes whether the correct identification triggers secondary mechanisms in the Porsche application the prevent the PCMCIA card from being accessible. What a mess.

My next step will be to trace the TSR with DEBUG and see what else it does. One suspision is that it copies the BIOS into RAM. And unfortunately that does not work with BIOS shadowing enabled because the RAM get write-protected. And I can not disable shadowing in the BIOS setup.

Ingo

[ischmitz]

Originally Posted by wrljet

Is your TSR called by PWR_ISR.DLL ?

Address Publics by Value

0001:0730 @DoInt$qv
0001:0821 _TSR_Check
0001:08BA _InitPwrMon
0001:093E _DeInitPwrMon
0001:0986 _GetPwrStat
0001:09CE _ShiftContrast
0001:0A0F _TSR_CallAPI

yep - exactly. I can see the labels in notepad without even firing up IDA. See my PM for more details. They weired thing is that most everything runs fine WITHOUT the TSR being loaded. That is what I don't understand (yet)

Ingo

[ischmitz]

Originally Posted by wrljet

FWIW, I believe the special tablet PC the PST2 uses is a MicroDesign AIO486, or one very similar.

After lots of disassembly of the various pieces of the PST2 setup pgm, I found several calls and searches for strings which were associated with a particular BIOS, which happens to be the one used in the tablet. It's been a while and I don't remember the specifics, but I believe it scanned the BIOS for a particular string, and then backed up a few bytes and just assumed that would contain a FAR PTR to a BIOS entry point.

There is also a reload option on the PST2, to repair itself, including reloading the BIOS CMOS setup data, which helped in that research.

I finally found a Flash BIOS update for it, which I then disassembled to figure out what
the functions did.

I guess herein lies the problem. There was a BIOS update issued by Bosch in '97 to make the MicoDesign tablet PC Win95 compatible. And that newer BIOS might just not be compatible with the Porsche SW anymore. That is my guess at this point. I tried the CMOS setup restore but that did not get me anywhere so far.

Ingo

[Wayne 962]

Just so everyone knows what we're talking about, here's a pic of the golden goose. I've also got two green KTS-500 units running version 24. Still looking for that elusive version 27?



-Wayne

[911cedric]

Hello everybody,

i talked on ebay yesterday with a guy in Italy, who sells on ebay KTS500 and laptops converted in PST2.
this guy has 160 x 100% feedback and sold number of them on ebay.

He certified me that the serial PCMCIA card of the KTS 500 is exactly the same than in the PST2. He told me that i only need a new hard drive with the program loaded in and all the plugs. When loaded for the first time, the program ask for a dealer number, you can give a random one.

He can sell it ready to plug and play for 500€, if you have a serial KTS 500 with all the leads.

I don't know how did you load the PST2 software in your KTS.
did you installed it via a CD with your PC or did you replace the hard drive?
maybe all your problems come from an installation defect.

all your computer talk guys sounds like chinese to me

it sounds too good to be true, but maybe should i try what he offers and let you know.

what do you think about?

Cedric
Paris, France

[911cedric]

sorry not worst, but worth

[ischmitz]

Cedric, it is certainly worth a try if you have the money to spare. But wouldn't it be better to have the guy do the install for you and confirm it working rather than doing it yourself? What if something goes wrong in the process. Would he refund the money?

Anyhow, let us know how it turns out.
Ingo