From: dabl2@nlm.nih.gov (Don A.B. Lindbergh)
Subject: Re: AHA1542B and Sound Blaster Pro Problem
Keywords: SCSI SB Pro, 1542B, SCSI
Organization: National Library of Medicine
Date: Thu, 30 Jul 92 16:43:40 GMT

Long windy diatribe on use of 1542B with midi/audio cards, hit 'n' now
or forever hold your flames :)

>Just a guess here, but one thing you might do is set the bus on time to
>7 with ASPI manager and see what happens.  Another thing I do know about
>has to do with multiple DMA channels running at the same time.
>Apparently, there are systems that can't do this well.  SCO, for one,
>put in a special control flag to keep multiple DMA's from running unless the
>user makes a conscious effort to enable it.
>As I understand it, FASTBACK fails high DMA tests from this problem as
>well and resorts to using non-overlapped DMA when this is detected.
>---
>
>			Roy Neese
>			Adaptec Senior UNIX/SCSI Software Engineer
>			UUCP:	convex!egsner!adaptex!neese
>			Inet:	neese%adaptex@cirr.com

Yes, this helps for operation with a PAS-16, but I have to say that I would 
warn people away from bus mastering controllers for use with an audio card that
uses dma to transfer data.  One can 'kludge' by adjusting bus on/off times and
get acceptable performance (although reducing the throughput of the card) in
WINDOWS with the Mediavision recording/playback software using full 44.1 16 bit
stero format, but in DOS, forget it, it glitches and NO amount of tweaking will
fix it.  I'm not sure why this doesn't happen in Windows, probably MVs software
is better about 'reading ahead/caching' etc in that environment.  Perhaps the
DOS stuff could be made workable with a better/different diskcache, but I 
haven't been able to make it work.  I have an Adaptec 1542B and a Quantum
240MB scsi drive (plenty fast, with a 256k cache) using a 2 meg smartdrv cache
and it glitches badly on 44.1khz 16 bit stereo playback in DOS, even reducing
the bus on/off times to fastest on both 'ends'.  An equivalent Quantum IDE 
has ABSOLUTELY NO PROBLEMS with NO DISKCACHE employed on the identical data.

 Also, the 1542B has been a
nightmare for general midi apps (like games that use mt-32 sound)  One must
'burn' a new ROM bios which operates at another port (334 vs 330).  No, Adaptec
won't sell you one.  The docs you get AFTER you buy the card reference an 
alternate version, but I've never heard of anyone actually mention it in the
real world.  I learned about all these problems with midi cards AFTER I bought
the card, even with a good amount of research and reading of comp.scsi.periphs
So, after jumping through hoops to 'burn' another rom bios, beating Adaptec
over the head for 'little' details like the proper speed of the cmos chip to
be used (not included in the doc with the microcode) and finding someone who
would burn the cmos for me (no, I didn't really want to buy a rom burner
for one application) the latest is that even with the new bios, using
Windows 3.1 and a Music Quest MQX-32M midi card (mpu-401 register level
compatible) I get a hang condition shelling to dos from win 3.1 running in 
enhanced mode with the Music Quest 3.1 midi drivers (old or new) active!
I do not see this problem with the old, regular adaptec bios.  Otherwise, the
new bios works as advertised and I was, for a short time :(, actually able
to use my mt-32 with games.  I just debugged this last night, so in fairness
I have yet to contact bot Music Quest and Adaptec to see if a solution can
be found.  I don't have high hopes for either Music Quest investigating a 
proposed problem with their driver and a non-standard custom bios on a scsi
card which apparently none of their other customers use (nobody else has 
reported this problem.  Not surprisingly, again, things work fine with
an equivalent IDE setup on the same machine)

  So, it's this kind of bullshit that anyone
thinking of Adaptec for use with midi/audio may want to think about.  I am 
basically throughly disgusted with the whole experience with the 1542B,
(I won't even talk about the problems with their first OS/2 2.0 driver)
although I will give them the admission that the card is very well made
and performs better than the other guys for non-midi/audio applications and
*is* talked about/supported everywhere.  Their technical support people and
BBS I found to be extremely frustrating, however, and there are forever
ongoing discussions about how bad they are and then 'how they are improving'
etc.  Basically they NEVER call you back when you leave phone messages, the
replies on the BBS are often terse and not thorough, and one sees a constant
stream of desperate, irate messages from people asking basic questions or
having all kinds of problems and getting no response etc.

This card requires all kinds of special
'tweaking' to Windows .ini files and qemm parameters to make it work under
Ms Dos.  There is an additional complication and overhead (and performance
increase) using their special aspi4dos driver.
I believe it's pretty painless for unix though.  But most of the world doesn't
use unix now do they? (please, no flames).  I'm cross posting to the scsi
group and others not to start a war, but hopefully find another person with
my particular setup and perhaps a solution.  Otherwise, the Future Domain
cards are lookin' mighty good to me these days, but I have to find out the
bottom line here to.  They are not bus masters correct?  Can anyone tell me
about stuff like the bios (does it use a particular port, like 330 and/or
can it be changed and still function as the boot controller) and/or opinions
on whether a move to a Future Domain (or other, preferably explicitly supported
under OS/2, ie not just using the INT13 driver) will actually solve all these
problems?  Email or post, again I'm really not trying to antagonize, just
reporting my experiences and trying to learn more and also save some others
pain and frustration.


--Don
dabl2@lhc.nlm.nih.gov
Xref: sparky comp.periphs.scsi:3814 comp.sys.sun.hardware:3630