Marcus Meissner wrote:
> > In the flags there are 2 bits. One is tested for by the current TARGET_TO_HOST
>macro, the other is tested for by the current
> > HOST_TO_TARGET macro.
>
> Not exactly. TARGET_TO_HOST is 1 bit (bit 3), HOST_TO_TARGET are 2 bits
> (bit 3,4).
>
huh?? SRB_DIR_IN is defined as 0x08 (bit 3).. SRB_DIR_OUT is defined as 0x10 (bit 4).
SRB_DIR_SCSI is defined as 0x00 (neither
bit). According to WNASPI32 docs, OUT and IN flags are mutually exlcusive. According
to WINASPI/DOSASPI docs, setting both means
no data transfer, and setting neither means transfer determined by the command. Okay,
so then your patch would seem correct,
since it determines whether we should do host to target or target to host based on the
command.
>
> > To accomplish that I just thought of it as: As long as you don't
> > specifically specify a transfer in the opposite direction, you want to
> > transfer the data. So instead of checking for TARGET_TO_HOST, you check
> > to make sure that HOST_TO_TARGET was /not/ specified, and instead of
> > checking for HOST_TO_TARGET, you check to make sure that TARGET_TO_HOST
> > was /not/ specified.
>
> > Like I said, I have no idea if that is correct, but that may be an easier
> > way to do it than checking for every possible case.
>
> We should not confuse the SCSI subsystem. Your approach certainly will.
>
Sorry, I was smoking crack or something when I thought SRB_DIR_SCSI meant do both
transfers unconditionally. I now realize that
you are correct with this patch
I guess my problem was that I didn't think any company would be stupid enough to
include extra code to determine which way the
transfer is supposed to be going based on the command, so that app developers could be
lazy and just specify SRB_DIR_SCSI. That
is kind of lame on Adaptecs part.
>
> > And I'm definitely glad to see other people hammering on the code. ASPI
> > is very cool because it is the first step to actually using Wine to support
> > a piece of hardware (like a CD-R or DVD). Although in a way, a DVD
> > player/CD-R program is not really a hardware interface, it's more of an
> > application, and thus more along the lines of what Wine does.
>
> Not really, several people already use the serial comm interface to talk
> to digital cameras, and the parallel port stuff to talk parallel devices.
>
Okay.. point taken.. it's still cool that my CD-R works though ;). And believe me.. I
did some thorough testing last weekend,
burned like 20 CDs (as fast as I could switch 'em for a few hours). I think I need to
be getting a faster new burner (now that I
got the old one working in Linux). Saw a 12X SCSI, but it was "Smart & Friendly" so I
am going to research it before I just jump
out and buy it. If it was a Plextor or Sony or something, I probably would have
picked it up right there and then.
>
> Ciao, Marcus
-Dave
