[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    RE: PATCH: winaspi
From:       Jesper Pedersen <jep () systematic ! dk>
Date:       2000-03-23 9:33:46
[Download RAW message or body]

> -----Original Message-----
> From: David Elliott [mailto:dfe@infinite-internet.net]
> Sent: 23. marts 2000 10:24
> To: Marcus Meissner
> Cc: wine-devel@winehq.com
> Subject: Re: PATCH: winaspi
> 
> 
> 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.
>

If you want a 12x drive you should go for the: PlexWriter PX-W124TSi
(32x/12x/4x)
It is a killer drive !

> >
> > Ciao, Marcus
> 
> -Dave
> 
> 

 /Jesper

[prev in list] [next in list] [prev in thread] [next in thread]