Adaptec SCSI and Hayes JT FAX 9600

[Rick Richardson]

I recently posted the following query, and got back several responses
by mail and news.  First, the query and summaries of the replies,
then my theory.  Note that I did get a response from Doug Pintar
who has not had a problem with this configuration.

Me:
| We have a customer with an Adaptec SCSI controller who is
| trying to install a Hayes JT FAX 9600 fax board in his system.
| The system crashes or locks up when the Hayes board is installed.

Daniel Zuccarelli:
| I had the identical problem described above when trying to install the
| JT FAX 9600 in an 80386DX NCR machine.  The problem is with the JT FAX
| card and the way it handles memory references.  It ignores the control line
| that says this is a memory reference and just fires off the shared ram address
| being on the address bus with a read or write signal.  This is fine except
| that on 1 Meg multiples of the shared ram address it also responds as if it
| were being accessed.

Robert Lin:
| Rick, this excerpt from UniFax manual page 24 may help you with your
| current problem with the JT9600 fax board:

| "A long outstanding bug in the Hayes/Quadram JT9600 board interfers
| with any use of 16bit DMA. This means the Hayes card cannot be used
| in systems which have other cards that use it. For example the
| Adaptec 1540/1542 SCSI hard disk controller."

Doug Pintar:
| I'm running a Hayes JTfax 9600 & Adaptec 1542B (have also used an A) on a
| Micronics 25MHz (cache) motherboard from Gateway 2000 with NO problems at
| all!  Everything just came up and ran the way the FAX/ix documentation said
| it would, and I was able to send a FAX the first time I tried.  (Congrats,
| BTW, this is almost a rarity in the Unix world [more's the pity]).  Perhaps
| there's some problem between the VGA and the SCSI/HAYES.  This has been known
| to happen -- some boards jam the bus into 16-bit mode whether they want to
| be or not, and 8-bit things break.

Stuart Lynne:
| The problem is that the JTFax board will respond to addresses like 0x1cc000,
| 0x2cc000, etc, even though it should only respond to 0x0cc000. In other
| words, even though it is an 8 bit board that *should* be incapable of
| responding to a 16 bit address request, it does. 

My latest theory:

The Hayes JT FAX 9600B (aka Quadram JT FAX 9600) is an 8 bit card.
Many of the replies seem to indicate that some sort of aliasing is
going on.  However, on the XT portion of the AT bus, the read/write
signals are called SMEMR and SMEMW, and are supposed to be guaranteed
active (by the motherboard) only in the first 1MB of address space.
An 8-bit card doesn't have access to the upper address lines (which
are on the AT portion of the bus), so it is pretty obvious why SMEMR
and SMEMW must be defined this way (the AT portion of the bus has
MEMW and MEMR, which are active for all addresses).  So, it is
difficult for me to believe that aliasing is going on, unless
the motherboard is at fault.

I think Doug may have hit the nail on the head, or pretty close.
Its interesting to note that he runs a similar configuration
without problem.  Coincidentally, PC Magazine, Sept 25, 1990
has an article on page 443, "Facing the Truth About 16-bit VGA
Display Adapters", which shed even more light on the problem.
Its not clear to me whether the Adaptek or the VGA adapter
or some other device is the source of the problem, but the
theory goes like this:

There's a signal, MEM-CS16, on the AT portion of the bus which
a peripheral card must assert in order to switch the bus from
8 bit to 16 bit transfers.  The peripheral card is supposed
to decode address lines LA17-LA23 (also on the AT portion of
the bus) and assert MEM-CS16 to request a 16 bit transfer.
I don't know whether the bus timing allows for qualifying
LA17-LA23 with additional lower order address lines.  Without
additional qualification of the address, a 16 bit card, such
as the Adaptek or some VGA adapters, can only decode to a
granularity of 128 kbytes.

What happens, then, is that any 16 bit card located within
A000:0000 to BFFF:0000 forces the bus into 16 bit mode for
that entire range of addresses.  Likewise, a 16 bit card located
within C000:0000 to DFFF:0000 will jam the bus into 16 bit
mode for that entire range of addresses.

This is bad news for any 8 bit card that is located within
the same 128k range as a 16 bit card, since it can deal only
with 8 bit transfers.

The solution appears to be to disable 16 bit operation of
the VGA or other 16 bit card, or to move things around
such that all 8 bit cards with mapped memory are in one of
the 128k segments by themselves. 

If this theory is correct, then I would blast IBM's design
as being utterly wasteful of the available address space.
I'm sure that will popularize the theory, as IBM bashing
is the second favorite sport here (after ISC/SCO bashing). :-) :-)

BTW, the story has a happy ending, as the customer who
reported the problem in the first place just moved the
JT FAX over to a different machine which has a Future
Domain SCSI controller.

Thanks to everybody who responded, especially our esteemed
competition.  Its this spirit of cooperation that sets
UNIX people apart from the norm!!!

-Rick

-- 
Rick Richardson | Looking for FAX software for UNIX/386 ??? Ask About: |Mention
PC Research,Inc.| FaxiX - UNIX Facsimile System (tm)                   |FAX# for
uunet!pcrat!rick| FaxJet - HP LJ PCL to FAX (Send WP,Word,Pagemaker...)|Sample
(201) 389-8963  | JetRoff - troff postprocessor for HP LaserJet and FAX|Output