Maybe by now nobody but me remembers these three realities were in dispute, but both
you and I now can confirm more definitively, more repeatably, more precisely, what I
claimed before:
1) Yes the WinME Atapi host copies 5 bytes in, not 6, via AtapiPio if the presents a
DRQ for 5 bytes.
I think I remember seeing this first corrected in Win98, sometime after I saw Win95
crash when devices presented odd length DRQ's. I imagine people who think Windows
copies only even lengths are in fact working with Atapi devices designed to work with
third-party patches to Win95 by way of disregarding the Scsi standards in favour of
rounding up copy lengths to the nearest even number.
2) Yes using the WinME Gui to turn off AtapiDma, in favour of AtapiPio, lets 5 or 6
bytes move, rather than 8.
I hear WinME rounds up AtapiDma transfers to the nearest multiple of 4 only on certain
motherboards - like the newest one at My desk. I hear other WinME on other
motherboards round up AtapiDma data lengths only to the nearest multiple of 2.
3) If you wish to repeat these experiments yourself to confirm/deny the results, well
then, the email attached at left tells you how to do so, for the cost of nothing but
your time. The oddwinme.txt attached at right both walks you thru the Pio/Dma Gui of
Win95/98/ME and shows you soft traces of the rounding up of copy lengths.
Enjoy.
x4402 Pat LaVarre [EMAIL PROTECTED]
http://members.aol.com/plscsi/
--- Begin Message ---
> "When I use a word," Humpty Dumpty said,
> in a rather scornful tone, "it means just what
> I choose it to mean - - neither more nor less."
I'm saying the so-called Scsi devices available at retail can trivially be provoked
into copying an unexpected count of bytes and/or into copying data that describes
itself inaccurately, if we interpret the data according to the pretty fantasies that
people like Ansi T10, me included, publish.
How can less than all of us acknowledge this plain truth that I see immediately
whenever I look outside my own designs? And what else, equally plain, is wrong about
my own designs that I'm not seeing?
How about we try a scientific approach. How about we try talking about easily
repeatable results. Nothing like an easily collected bus trace for getting two
engineers to agree, right? Accordingly, now I can say, ...
If you have Microsoft Win 95/ 98/ ME as delivered (or an Aspi driver with Dos), and
you have your stuff backed up, then:
http://members.aol.com/plscsi/
offers you a plscsi executable, which you can rebuild yourself from the source and the
free 16-bit C compiler there. Microsoft Win2K/XP & Apple MacOF have been proved in
concept, and offline for Linux we have links to supposedly comparable examples.
That plscsi executable will let you casually, in system, without disassembling your
PC, capture traces like:
http://members.aol.com/plscsi/20020316/win98inq.txt
This particular trace shows the Microsoft Scsi to Ata bridge of Win98 zeroing byte 4
additionalLength. Even more creatively, this device copies in as many bytes as
allowed - this device flatly disregards the allocationLength of Cdb byte 4.
Having a player with the market position of Microsoft be creative didn't really
surprise me.
What did shock me was that the first 1394 Sbp2 device I tried does much the same
thing. A trivial experiment like:
plscsi -v -x 12 0 0 0 24 0 -i x28 -b x30
shows this 1394 Sbp2 device choosing to copy in the x28 bytes that Sbp2 allows it to
copy, x24 intelligible bytes followed by infinite zeroes ... here 4 bytes beyond the
x24 byte limit of the Scsi Cdb.
How about we all start publishing traces of what reality is like?
If we can all get to where we're talking about something real, maybe then we can agree
on how to improve it?
x4402 Pat LaVarre [EMAIL PROTECTED]
http://members.aol.com/plscsi/
--- End Message ---
C:\>rem WinME, with this anonymous Atapi Cd-rom,
C:\>rem copies in 8 Dma bytes when asked to copy in 5,
C:\>rem or else 6 Pio bytes.
C:\>ver
Windows Millennium [Version 4.90.3000]
C:\>dir plscsi.exe
Volume in drive C is MICRON
Volume Serial Number is 3831-1C89
Directory of C:\
PLSCSI EXE 67,808 03-26-02 9:53a plscsi.exe
1 file(s) 67,808 bytes
0 dir(s) 858.06 MB free
C:\>plscsi -v -x 12 0 0 0 05 0 -i x0E -b x10
// theCdb:
x 00000000 12:00:00:00 05:00 .. .. .. .. .. .. .. .. .. .. "R@@@E@"
// theOutData:
x 00000000 2E:2E:2E:2E 2E:2E:2E:2E 2E:2E:2E:2E 2E:2E:2E:2E "................"
x 00000010
// theInData:
x 00000000 05:80:00:21 5B:00:5B:00 2E:2E:2E:2E 2E:2E:2E:2E "E@@![@[@........"
x 00000010
// exitInt: x0 (0)
C:\>rem MyComputer, right click Properties, tab DeviceManager
C:\>rem CDROM, select your drive, right click Properties, tab Settings
C:\>rem turn off DMA, reboot.
C:\>rem
C:\>rem (Or just disable/re-enable the appropriate Hard disk controller,
C:\>rem if you know how to do that without disconnecting your boot drive.)
C:\>plscsi -v -x 12 0 0 0 05 0 -i x0E -b x10
// theCdb:
x 00000000 12:00:00:00 05:00 .. .. .. .. .. .. .. .. .. .. "R@@@E@"
// theOutData:
x 00000000 2E:2E:2E:2E 2E:2E:2E:2E 2E:2E:2E:2E 2E:2E:2E:2E "................"
x 00000010
// theInData:
x 00000000 05:80:00:21 5B:00:2E:2E 2E:2E:2E:2E 2E:2E:2E:2E "E@@![@.........."
x 00000010
// exitInt: x0 (0)
C:\>rem And now a less creatively implemented Atapi device,
C:\>rem that cooperates with WinME Atapi Pio
C:\>rem to copy in 5 bytes when asked to copy in 5 bytes.
C:\>plscsi -v -x 12 0 0 0 05 0 -i x0E -b x10
// theCdb:
x 00000000 12:00:00:00 05:00 .. .. .. .. .. .. .. .. .. .. "R@@@E@"
// theOutData:
x 00000000 2E:2E:2E:2E 2E:2E:2E:2E 2E:2E:2E:2E 2E:2E:2E:2E "................
x 00000010
// theInData:
x 00000000 00:80:00:01 75:2E:2E:2E 2E:2E:2E:2E 2E:2E:2E:2E "@@@Au...........
x 00000010
// exitInt: x0 (0)