I have this Ford SBDS (Service bay diagnostic system). And it has OS/2 V3
running on HP vectra 386 server RS/25. I would like upgrade this anc�ent HP
system with more modern system(mostly due to ESDI HDD with bad sectors). I
have installed OS/2 and SBDS software on pentium 90. The only problem seems
to be HP Vectra PSI card. It is ISA bus programmable serial adapter(this
connects to meaurement unit). The card driver is PSIOS2DR.SYS Revision 4.3
On pentium during OS/2 boot driver says "no response from PSI card
attempting reset..." but card never responds. I have stripped all devices to
minimum from machine bios. And also checked that PSI card is on IRQ5 (that
is free). So my question is could this driver be "time-critical" so when cpu
speed goes up driver/card wont work anymore? Only way I have gotten this
card to work was to disable processor caches from BIOS. Below details of
card:
VECTRA PSI CARD
5062-6809
a-312225504778
Chip on card Zilog Z85C3010PSC
OS/2 kernel 8.206
Also if someone has details of this card (dip setting etc.) I would like to
have these. I have tried using RMVIEW on RS/25 to get settings but this
driver seems to be "uncompatible with rmview"
Tero
Cards that do port I/O have a problem with IO responses.
If the driver isn't coded to take this into account, the
card may/may not fail. In the 286, it was sufficient to
do a J .+1 to flush the prefetch queue. This doesn't
work on anything from 386 on. OS/2 has a variable defined
(DOSIODELCNT) that by looping on it's value
should give a fairly constant delay. It sounds like it's
probably this.
Without the source code for the driver, you will probably
have problems solving this.
Bob Plyler IBM 3890/XP development
(not an official IBM spokesperson)
Hi,
In case you are still working on this...
>bad sectors). I have installed OS/2 and SBDS software on pentium 90. The
>only problem seems to be HP Vectra PSI card. It is ISA bus programmable
>serial adapter(this connects to meaurement unit). The card driver is
>PSIOS2DR.SYS Revision 4.3 On pentium during OS/2 boot driver says "no
>response from PSI card attempting reset..." but card never responds. I
>have stripped all devices to minimum from machine bios. And also checked
>that PSI card is on IRQ5 (that is free). So my question is could this
>driver be "time-critical" so when cpu speed goes up driver/card wont
>work anymore?
It is probably time-critical in the sense that the driver has hardcoded
delay loops that do not provide sufficient delays on faster systems.
Given that the card appears to have a CPU, it's probably an intelligent
serial card similar to the GTEK cards found on BBS systems. These often
need delays so that the CPU can respond to a request.
>Only way I have gotten this card to work was to disable
>processor caches from BIOS.
So you can get the card to work correctly by slowing down the system? If
so, the existing delays appear to be almost sufficient.
Below details of card:
> VECTRA PSI CARD
> 5062-6809
> a-312225504778
> Chip on card Zilog Z85C3010PSC
> OS/2 kernel 8.206
>Also if someone has details of this card (dip setting etc.) I would like
>to have these. I have tried using RMVIEW on RS/25 to get settings but
>this driver seems to be "uncompatible with rmview"
Given the age of the system, this makes sense.
Send a copy of the driver to my de-spammed address and I will look at the
code, as time permits. If the problem is just the hard-coded delays it
should be easy to patch the driver.
You can do some looking yourself if you grab
ftp://sunsite.cnlab-switch.ch/mirror/simtelnet/msdos/disasm/ida37fw.zip
and use it to disassemble the driver. Ida runs very well in a DOS
session.
Steven
--
--------------------------------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
--------------------------------------------------------------------------------------------
Hi,
Tero sent me a copy of the failing driver. As I noted
> It is probably time-critical in the sense that the driver has hardcoded
> delay loops that do not provide sufficient delays on faster systems.
I took a look at the driver and as I suspected it is heavily dependent
on hard coded delay loops. If the driver had been correctly written
to use DOSIODELAYCNT to establish the delay loops it would probaby
still be working.
The driver can probably be patched to work by doubling or, perhaps
quadrupling the delays. The outer count for most most the delays is
75 units so, overflow will not be an issue for this delays. There's
one piece of code that seems to calculate the delay count. This
might take some care to avoid divide overflow.
Steven
--
Do you have time to do this patch for me ? I viewed code with IDA
but I am afraid patching is beyond my skills.
Tero Kaarlela
On 16 marras, 07:33, "Steven Levine" <stev...@nomail.earthlink.net>
wrote:
> On Tue, 11 Aug 2009 00:57:54 UTC, Steven Levine
>
> <stev...@earthlink.bogus.net> wrote:
>
> Hi,
>
> Terosent me a copy of the failing driver. As I noted
>
> > It is probably time-critical in the sense that the driver has hardcoded
> > delay loops that do not provide sufficient delays on faster systems.
>
> I took a look at the driver and as I suspected it is heavily dependent
> on hard coded delay loops. If the driver had been correctly written
> to use DOSIODELAYCNT to establish the delay loops it would probaby
> still be working.
>
> The driver can probably be patched to work by doubling or, perhaps
> quadrupling the delays. The outer count for most most the delays is
> 75 units so, overflow will not be an issue for this delays. There's
> one piece of code that seems to calculate the delay count. This
> might take some care to avoid divide overflow.
>
> Steven
>
> --
> ---------------------------------------------------------------------
> Steven Levine <stev...@earthlink.bogus.net>
> eCS/Warp/DIY etc.www.scoug.comwww.ecomstation.com
> ---------------------------------------------------------------------