A hack, anyone, to turn on dma ?

[Franc Zabkar]

Re: A hack, anyone, to turn on dma ? SOLVED ???

On Wed, 2 Jul 2008 21:09:34 -0400, "PCR" <pcrrcp@netzero.net> put
finger to keyboard and composed:

>Franc Zabkar wrote:

>| When I look at the IO ports assigned to my IDE controller in Device
>| Manager, I see ports 0x4000 - 0x4007 assigned to my primary IDE
>| controller and 0x4008 - 0x400F assigned to the secondary.

>Are you looking at Device Manager, Computer, Input/Output?

No, I'm looking at the I/O Range under "Hard disk controllers".

My understanding is that these registers are associated with the bus
mastering function of the IDE controller and are an attempt at
standardisation. For example, the documentation for these registers in
my SiS 5597 chipset appears identical to the SFF-8038i spec.

I think it might be time to go to one of the storage groups for
advice. Maybe they've seen this problem before.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Franc Zabkar]

Re: A hack, anyone, to turn on dma ? SOLVED ???

On Tue, 1 Jul 2008 20:05:16 -0400, "PCR" <pcrrcp@netzero.net> put
finger to keyboard and composed:

>Unchecking DMA
>for my IDE-CD R/RW 4x4x24 was uneventful enough. It was gone after the
>requested reboot. Fine... BUT -- checking it back on -- I got a
>requestor saying I should ask the manufacturer first to see whether DMA
>is allowable!

This makes no sense to me. Why would the manufacturer of the IDE drive
need to be consulted? Surely all that Windows needs to do is to
interrogate the drive via a standard ATA/ATAPI Identify Drive or
Identify Packet Device command? The 512 bytes returned by the drive
will contain all the manufacturer's specifications, including which
UDMA modes are supported and which ATAPI standard applies.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[PCR]

Re: A hack, anyone, to turn on dma ? SOLVED ???

Franc Zabkar wrote:
| On Wed, 2 Jul 2008 21:09:34 -0400, "PCR" <pcrrcp@netzero.net> put
| finger to keyboard and composed:
|
|>Franc Zabkar wrote:
|
|>| When I look at the IO ports assigned to my IDE controller in Device
|>| Manager, I see ports 0x4000 - 0x4007 assigned to my primary IDE
|>| controller and 0x4008 - 0x400F assigned to the secondary.
|
|>Are you looking at Device Manager, Computer, Input/Output?
|
| No, I'm looking at the I/O Range under "Hard disk controllers".
|
| My understanding is that these registers are associated with the bus
| mastering function of the IDE controller and are an attempt at
| standardisation. For example, the documentation for these registers in
| my SiS 5597 chipset appears identical to the SFF-8038i spec.

Alright. It's much the same, though, except the many aliases as absent.

....For the Primary IDE Controller, it shows...
Input/Output Range 01F0-01F7
Input/Output Range 03F6-03F6
Interrupt Request 14
Input/Output Range 1440-1447

....For the Secondary IDE Controller, it shows...
Input/Output Range 0170-0177
Input/Output Range 0376-0376
Interrupt Request 15
Input/Output Range 1448-144F

That's actually exactly the same as shows for them in the "Computer,
Input/Output (I/O)" window. (I messed up a bit copying it last try.)
SO... we are only 50% alike for those. Our 2nd set of ranges differ.

| I think it might be time to go to one of the storage groups for
| advice. Maybe they've seen this problem before.

I think Shadow is fairly happy as is now that he has set the DVD to be a
slave. He's got his DMA.

| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net

 

[PCR]

Re: A hack, anyone, to turn on dma ? SOLVED ???

Franc Zabkar wrote:
| On Tue, 1 Jul 2008 20:05:16 -0400, "PCR" <pcrrcp@netzero.net> put
| finger to keyboard and composed:
|
|>Unchecking DMA
|>for my IDE-CD R/RW 4x4x24 was uneventful enough. It was gone after the
|>requested reboot. Fine... BUT -- checking it back on -- I got a
|>requestor saying I should ask the manufacturer first to see whether
|>DMA is allowable!
|
| This makes no sense to me. Why would the manufacturer of the IDE drive
| need to be consulted? Surely all that Windows needs to do is to
| interrogate the drive via a standard ATA/ATAPI Identify Drive or
| Identify Packet Device command? The 512 bytes returned by the drive
| will contain all the manufacturer's specifications, including which
| UDMA modes are supported and which ATAPI standard applies.

I tried & failed to make sense of it myself. Luckily, Windows knew
enough to retain the checkbox for DMA in the Device Manager requestor,
though-- for me to check it TWICE before it would work ONCE! Otherwise,
I'd have had to go for my full system backup-- if even THAT would work!
Had some bit been irrevocably turned off inside the ROM of my CD-ROM--
it might not have!

| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net

 

[Franc Zabkar]

Re: A hack, anyone, to turn on dma ? SOLVED ???

On Thu, 3 Jul 2008 17:10:20 -0400, "PCR" <pcrrcp@netzero.net> put
finger to keyboard and composed:

>Franc Zabkar wrote:
>| On Tue, 1 Jul 2008 20:05:16 -0400, "PCR" <pcrrcp@netzero.net> put
>| finger to keyboard and composed:
>|
>|>Unchecking DMA
>|>for my IDE-CD R/RW 4x4x24 was uneventful enough. It was gone after the
>|>requested reboot. Fine... BUT -- checking it back on -- I got a
>|>requestor saying I should ask the manufacturer first to see whether
>|>DMA is allowable!
>|
>| This makes no sense to me. Why would the manufacturer of the IDE drive
>| need to be consulted? Surely all that Windows needs to do is to
>| interrogate the drive via a standard ATA/ATAPI Identify Drive or
>| Identify Packet Device command? The 512 bytes returned by the drive
>| will contain all the manufacturer's specifications, including which
>| UDMA modes are supported and which ATAPI standard applies.
>
>I tried & failed to make sense of it myself. Luckily, Windows knew
>enough to retain the checkbox for DMA in the Device Manager requestor,
>though-- for me to check it TWICE before it would work ONCE! Otherwise,
>I'd have had to go for my full system backup-- if even THAT would work!
>Had some bit been irrevocably turned off inside the ROM of my CD-ROM--
>it might not have!

I was feeling adventurous so I tried playing around with my hardware
settings.

I used Wpcredit to turn off the DMA enable bit in the PCI register for
my UDMA capable DVD-ROM drive. After exiting Windows and returning to
a DOS command line, an Identify Packet Device command determined that
the drive was still in UDMA mode. I then returned to Windows (by
typing "win") and found that the relevant PCI bit was still in the off
state and that the DMA checkbox for that drive was now unticked. This
suggests that Windows is unable or unwilling to disturb the IDE
controller's PCI registers, even if they are not optimally configured,
preferring to leave that up to the BIOS (or third party device
driver?). It also suggests that Windows doesn't need to read any files
from a drive in order to test its UDMA capability.

Anyway, without changing any Windows settings, I exited Windows, hit
the reset switch and booted into Windows again. This time the PCI
register was back to normal, and the DMA checkbox was automatically
re-ticked.

Another thing I followed up was Glen's link:
http://support.microsoft.com/?kbid=159560

The Debug technique described by MS determines whether an IDE device
supports a multi-word DMA protocol, *not* UDMA. It suggests that any
device which supports multi-word DMA will get a tick in the DMA
checkbox, yet my Ricoh 2x CD writer, which supports multi-word DMA but
not UDMA, does not get a tick. I checked the output of the Identify
Packet Device command (word #63 = 0007) and found that it supports M-W
DMA modes 0,1,2. However none of these modes were selected. Maybe if I
selected M-W DMA mode 2 before starting Windows ...

Well, I dropped back to DOS, enabled M-W DMA mode 2, confirmed that
the output of the Identify Packet Device command reflected the change,
and then typed "win". Unfortunately the DMA checkbox did not stay
ticked. On returning to DOS I found that the drive was still set for
M-W DMA mode 2, so something else was amiss. I then discovered that
the "DMA supported" bit in word #49 was zero, ie not supported. Is
that what Windows is seeing? If so, then there doesn't appear to be
any way to set this bit. This then begs the question, does "DMA
supported" mean "M-W DMA supported" or "UDMA supported", or does it
refer to the long obsolete single-word DMA?

Referring to the method described in Glen's MS link above, to check
whether a device supports UDMA modes rather than M-W DMA modes, I
believe one just needs to replace the following step ...

o 172 22 22 is for DMA mode 2, use 21 for DMA mode 1

.... with ...

o 172 42 42 is for UDMA mode 2, use 41 for UDMA mode 1

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Shadow]

Re: A hack, anyone, to turn on dma ? SOLVED ???

On Thu, 3 Jul 2008 16:50:57 -0400, "PCR" <pcrrcp@netzero.net> wrote:

>I think Shadow is fairly happy as is now that he has set the DVD to be a
>slave. He's got his DMA.
Fairly ? I'm VERY happy
[]'s

 

[PCR]

Re: A hack, anyone, to turn on dma ? SOLVED ???

Franc Zabkar wrote:
| On Thu, 3 Jul 2008 17:10:20 -0400, "PCR" <pcrrcp@netzero.net> put
| finger to keyboard and composed:
|
|>Franc Zabkar wrote:
|>| On Tue, 1 Jul 2008 20:05:16 -0400, "PCR" <pcrrcp@netzero.net> put
|>| finger to keyboard and composed:
|>|
|>|>Unchecking DMA
|>|>for my IDE-CD R/RW 4x4x24 was uneventful enough. It was gone after
|>|>the requested reboot. Fine... BUT -- checking it back on -- I got a
|>|>requestor saying I should ask the manufacturer first to see whether
|>|>DMA is allowable!
|>|
|>| This makes no sense to me. Why would the manufacturer of the IDE
|>| drive need to be consulted? Surely all that Windows needs to do is
|>| to interrogate the drive via a standard ATA/ATAPI Identify Drive or
|>| Identify Packet Device command? The 512 bytes returned by the drive
|>| will contain all the manufacturer's specifications, including which
|>| UDMA modes are supported and which ATAPI standard applies.
|>
|>I tried & failed to make sense of it myself. Luckily, Windows knew
|>enough to retain the checkbox for DMA in the Device Manager requestor,
|>though-- for me to check it TWICE before it would work ONCE!
|>Otherwise, I'd have had to go for my full system backup-- if even
|>THAT would work! Had some bit been irrevocably turned off inside the
|>ROM of my CD-ROM-- it might not have!
|
| I was feeling adventurous so I tried playing around with my hardware
| settings.

Uhuh. You are using tools I don't have-- & I might not really want them
for the sake of my IDE-CD R/RW 4x4x24's safety!

| I used Wpcredit to turn off the DMA enable bit in the PCI register for
| my UDMA capable DVD-ROM drive.

What/where is the PCI register-- a construct in the computer's RAM or on
a writeable PCI device chip? If on the PCI device, is BIOS responsible
for setting up an interface to it?

| After exiting Windows and returning to
| a DOS command line, an Identify Packet Device command determined that
| the drive was still in UDMA mode.

If both DOS & Windows are expected to access the PCI register (i.e., it
is OS independent)... then I suppose it must be/originate on the PCI
device chip.

But DOS saw UDMA mode after Windows turned it off? Can it be DOS was
seeing & reporting a UDMA capability-- but not necessarily that it was
turned on?

| I then returned to Windows (by
| typing "win")

If you had done... "START, Shut Down, Re-start in MS-DOS mode",... then
normally EXIT (not WIN) would have been appropriate. WIN (I think)
wouldn't have worked-- you'd have gotten a message that Windows was
already started.

SO... I guess it is clear you exited Windows cleanly & without fear that
it might not have done its housekeeping. BUT can it be a full reboot was
necessary before the UDMA bit would be written to the PCI device?

| and found that the relevant PCI bit was still in the off
| state and that the DMA checkbox for that drive was now unticked.

By now, you did do a full reboot. I'm not sure that shutting off &
booting to DOS was enough. But I guess it might have been. All I really
know is, when I turned off DMA, I was requested to reboot. And --
turning it back on -- the machine actually shut fully down on its own
instead of requesting a reboot & on the second try!

| This
| suggests that Windows is unable or unwilling to disturb the IDE
| controller's PCI registers, even if they are not optimally configured,
| preferring to leave that up to the BIOS (or third party device
| driver?).

Both the IDE Controller & a device attached to it seem to be involved.
I'm thinking so because two registry keys are involved when I
check/uncheck DMA in my CD-ROM device...

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\hdc\0002
IDEDMADRIVE0 01 << Binary. It's 00 with DMA unchecked.

HKEY_LOCAL_MACHINE\Enum\SCSI\IDE-CD__R/RW_4X4X24_____C\MF&CHILD0001&PCI&
VEN_1106&DEV_0571&SUBSYS_00000000&REV_06&BUS_00&DEV_07&FUNC_0100
DMACurrentlyUsed 01 << Binary. It's 00 with DMA unchecked.

Are Wpcredit & that Identify Packet Device command accessing them both?
The first key actually is mentioned in MSHDC.inf (as Lee pointed out--
but the other one he mentioned, Diskdrv.inf, does not have it set)...

[ESDI_AddReg]
HKR,,DriverDesc,,"ESDI Port Driver"
HKR,,DevLoader,,*IOS
HKR,,PortDriver,,ESDI_506.pdr

HKR,,IDEDMADrive0,3,01
HKR,,IDEDMADrive1,3,01

| It also suggests that Windows doesn't need to read any files
| from a drive in order to test its UDMA capability.

What is the difference between UDMA & DMA? Do you have any .inf that
mentions UDMA? I don't. I guess its possible Windows does the DEBUG
thing glee posted to know whether a device supports DMA/UDMA instead of
reading a bit from its EPROM (programmable ROM chip).

| Anyway, without changing any Windows settings, I exited Windows, hit
| the reset switch and booted into Windows again. This time the PCI
| register was back to normal, and the DMA checkbox was automatically
| re-ticked.

What? How can that be? Can the DOS command have turned it back on? Then
it took a reboot of Windows to see it? WIN was not enough? Sheesh!

| Another thing I followed up was Glen's link:
| http://support.microsoft.com/?kbid=159560

I tried that gingerly from a Windows DOS box twice two days after glee
posted it & got an "FF" both times. I'm only sure I typed it wrong the
1st time. I think it must be done in True DOS to work. It says: "If the
value returned is not 00 or 04, you may not have typed the characters
correctly, or you may need to quit Windows." That is why I haven't tried
a 3rd. Also, it never actually mentions a CD-ROM device, but only speaks
of hard drives.

| The Debug technique described by MS determines whether an IDE device
| supports a multi-word DMA protocol, *not* UDMA. It suggests that any
| device which supports multi-word DMA will get a tick in the DMA
| checkbox, yet my Ricoh 2x CD writer, which supports multi-word DMA but
| not UDMA, does not get a tick. I checked the output of the Identify
| Packet Device command (word #63 = 0007) and found that it supports M-W
| DMA modes 0,1,2. However none of these modes were selected. Maybe if I
| selected M-W DMA mode 2 before starting Windows ...

My head is still swimming after reading that 7 times! The tick in the
DMA box I think more specifically would mean "to use" DMA. But I suppose
it can be inferred the box wouldn't/shouldn't be there if DMA wasn't
possible on the device. As far as "multi-word DMA protocol" vrs. UDMA, I
suppose the same tickbox could apply to either-- but I really don't
know. I see you are saying the IDE register is the same but would have a
different value in it for UDMA. But this tickbox may be referring to a
different bit in the register-- a bit that says to use or not use the
DMA/UDMA.

Are you saying the Ricoh 2x CD writer does not get a tickbox at all or
that the box is just unchecked? If the former, it could be an .inf is
involved.

| Well, I dropped back to DOS, enabled M-W DMA mode 2, confirmed that
| the output of the Identify Packet Device command reflected the change,
| and then typed "win". Unfortunately the DMA checkbox did not stay
| ticked.

So, the Ricoh 2x CD does have a checkbox in Windows. But Windows doesn't
allow you to check it-- just as was true for Shadow? (Did you try making
it a slave as worked for him-- even alone on the cable?) You did in DOS
what you believe caused the DMA box to get checked? But, back in
Windows, it was still unchecked?

(a) "START, Find, Files or Folders"
(b) Named: *.inf
(c) Containing text: IDEDMADrive
DMACurrentlyUsed
(d) Look in: C:\WINDOWS\INF

Is there any .inf that turns off IDEDMADrive (0 or 1) or
DMACurrentlyUsed? Only the one I posted above has either of those even
mentioned.

| On returning to DOS I found that the drive was still set for
| M-W DMA mode 2, so something else was amiss. I then discovered that
| the "DMA supported" bit in word #49 was zero, ie not supported. Is
| that what Windows is seeing? If so, then there doesn't appear to be
| any way to set this bit. This then begs the question, does "DMA
| supported" mean "M-W DMA supported" or "UDMA supported", or does it
| refer to the long obsolete single-word DMA?

You're making me dizzy again, Zabcar! But I'm still thinking at least
two bits are involved-- one says what kind of DMA is available & the
other says whether to use it or not. Also, I think both the IDE
controller & the particular IDE device attached to might be involved.

| Referring to the method described in Glen's MS link above, to check
| whether a device supports UDMA modes rather than M-W DMA modes, I
| believe one just needs to replace the following step ...
|
| o 172 22 22 is for DMA mode 2, use 21 for DMA mode 1
|
| ... with ...
|
| o 172 42 42 is for UDMA mode 2, use 41 for UDMA mode 1

So, you are saying the byte location is the same, but the value is
different. OK. Maybe I'll try that again in True DOS-- maybe!

| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net

 

[PCR]

Re: A hack, anyone, to turn on dma ? SOLVED ???

Shadow wrote:
| On Thu, 3 Jul 2008 16:50:57 -0400, "PCR" <pcrrcp@netzero.net> wrote:
|
|>I think Shadow is fairly happy as is now that he has set the DVD to
|>be a slave. He's got his DMA.
| Fairly ? I'm VERY happy
| []'s

Judging from the speed difference, it was well worth your effort! Looks
like Zabcar has found a Ricoh 2x CD writer with the same problem. I
wonder whether the same weird solution will work? Imagine-- a slave on a
cable all by itself! It turns conventional knowledge on its head! But
I'm glad it worked for you.


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net

 

[Franc Zabkar]

Re: A hack, anyone, to turn on dma ? SOLVED ???

On Fri, 4 Jul 2008 18:23:39 -0400, "PCR" <pcrrcp@netzero.net> put
finger to keyboard and composed:

>Shadow wrote:
>| On Thu, 3 Jul 2008 16:50:57 -0400, "PCR" <pcrrcp@netzero.net> wrote:
>|
>|>I think Shadow is fairly happy as is now that he has set the DVD to
>|>be a slave. He's got his DMA.
>| Fairly ? I'm VERY happy
>| []'s
>
>Judging from the speed difference, it was well worth your effort! Looks
>like Zabcar has found a Ricoh 2x CD writer with the same problem. I
>wonder whether the same weird solution will work? Imagine-- a slave on a
>cable all by itself! It turns conventional knowledge on its head! But
>I'm glad it worked for you.

My Ricoh writer appears to have been stuck in PIO mode all its life.
I've just assumed all along that it wasn't capable of DMA mode. It
appears that my motherboard's BIOS thought so, too.

But now my problem is *solved*! I found the firmware file ...

http://www.met.com.tw/download_file/cdrw/ricoh/mmp1/6200a/mp6200ad240.exe

.... extracted the .bin, and hacked it.

I did this by locating the section within the code that contained the
Identify Packet Device data block. I then changed the "DMA not
supported" bit at word #49 to "supported". I also recomputed the
checksum (which was stored in the first two bytes of the .bin) and
then flashed this modified firmware into my writer.

After booting into Windows, the DMA box was now ticked. It remained
ticked after copying 36MB of data from a CD to my hard drive, and all
the files verified OK using the "fc /b" command.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Shadow]

Re: A hack, anyone, to turn on dma ? SOLVED ???

On Sat, 05 Jul 2008 13:34:08 +1000, Franc Zabkar
<fzabkar@iinternode.on.net> wrote:

>My Ricoh writer appears to have been stuck in PIO mode all its life.
>I've just assumed all along that it wasn't capable of DMA mode. It
>appears that my motherboard's BIOS thought so, too.
>
>But now my problem is *solved*! I found the firmware file ...
>
>http://www.met.com.tw/download_file/cdrw/ricoh/mmp1/6200a/mp6200ad240.exe
>
>... extracted the .bin, and hacked it.
>
>I did this by locating the section within the code that contained the
>Identify Packet Device data block. I then changed the "DMA not
>supported" bit at word #49 to "supported". I also recomputed the
>checksum (which was stored in the first two bytes of the .bin) and
>then flashed this modified firmware into my writer.
You sound like an old cracker to me
I believe I was too, over 10 years ago. Softice 2.80, here we
come.
Does it verify the checksum every time it switches on, or only
when you upgrade the firmware ?
Might be easier to write directly to the firmware, if the
latter is true.
>
>After booting into Windows, the DMA box was now ticked. It remained
>ticked after copying 36MB of data from a CD to my hard drive, and all
>the files verified OK using the "fc /b" command.
Does it write any faster ?
[]'s
Funny Ricoh leaves the default on PIO. That firmware is from
mid-2001. Most motherboards supported DMA then.

 

[Franc Zabkar]

Re: A hack, anyone, to turn on dma ? SOLVED ???

On Sat, 05 Jul 2008 10:16:44 -0300, Shadow <sh@dow> put finger to
keyboard and composed:

>On Sat, 05 Jul 2008 13:34:08 +1000, Franc Zabkar
><fzabkar@iinternode.on.net> wrote:
>
>>My Ricoh writer appears to have been stuck in PIO mode all its life.
>>I've just assumed all along that it wasn't capable of DMA mode. It
>>appears that my motherboard's BIOS thought so, too.
>>
>>But now my problem is *solved*! I found the firmware file ...
>>
>>http://www.met.com.tw/download_file/cdrw/ricoh/mmp1/6200a/mp6200ad240.exe
>>
>>... extracted the .bin, and hacked it.
>>
>>I did this by locating the section within the code that contained the
>>Identify Packet Device data block. I then changed the "DMA not
>>supported" bit at word #49 to "supported". I also recomputed the
>>checksum (which was stored in the first two bytes of the .bin) and
>>then flashed this modified firmware into my writer.
> You sound like an old cracker to me

I'm old but I'm no cracker. Hacker maybe, but definitely not a
cracker. Those are the *bad* guys. I made a career out of third party
chip level repair of minicomputers and peripherals, so workarounds
like this often came in handy.

> I believe I was too, over 10 years ago. Softice 2.80, here we
>come.

Although I've written programs when I've had to, I'm not a programmer,
so stuff like that is probably beyond me.

> Does it verify the checksum every time it switches on, or only
>when you upgrade the firmware ?

The two checksum bytes appear to be part of the firmware. The uP in
the writer probably verifies the checksum at every power up. I could
try flashing firmware with a damaged checksum, but I don't know if I'd
be able to recover from it.

> Might be easier to write directly to the firmware, if the
>latter is true.

The .bin file (240KB) appears to be the firmware image (minus the 16K
boot block ???).

>>After booting into Windows, the DMA box was now ticked. It remained
>>ticked after copying 36MB of data from a CD to my hard drive, and all
>>the files verified OK using the "fc /b" command.
> Does it write any faster ?

The maximum write speed (2x) is limited by design, so whether the
drive is in PIO mode or DMA mode would make no difference. One would
expect an improvement in read performance, though.

To test this, I copied 575MB of data from a CD to my hard drive. With
the DMA box ticked, the transfer took 13m 51s. After rebooting with
the DMA box unticked, the transfer took 13m 18s. So it appears that
PIO mode is faster for this setup, or maybe DMA mode is not being
properly enabled.

> []'s
> Funny Ricoh leaves the default on PIO. That firmware is from
>mid-2001. Most motherboards supported DMA then.

Maybe Ricoh's DMA implementation was buggy so DMA was turned off for
that reason ??? Or maybe the meaning of the "DMA supported" bit was
obscure, and Ricoh misinterpreted it to mean that UDMA was not
supported ???

BTW, the Ricoh still powers up in PIO mode.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Franc Zabkar]

Re: A hack, anyone, to turn on dma ? SOLVED ???

On Fri, 4 Jul 2008 18:14:21 -0400, "PCR" <pcrrcp@netzero.net> put
finger to keyboard and composed:

>Franc Zabkar wrote:

>| I used Wpcredit to turn off the DMA enable bit in the PCI register for
>| my UDMA capable DVD-ROM drive.
>
>What/where is the PCI register-- a construct in the computer's RAM or on
>a writeable PCI device chip? If on the PCI device, is BIOS responsible
>for setting up an interface to it?

It's in the PCI IDE controller device within the southbridge component
of the motherboard chipset. The chipset registers contain
configuration settings which determine the behaviour and function of
the IDE controller. They can be set by the BIOS or by device drivers
or by the user.

BTW, you need to be careful because some registers, eg some SiS USB
controller registers, are "write-once". Whatever data you write to
them may become permanent. But the datasheet should tell you this.

>| After exiting Windows and returning to
>| a DOS command line, an Identify Packet Device command determined that
>| the drive was still in UDMA mode.
>
>If both DOS & Windows are expected to access the PCI register (i.e., it
>is OS independent)... then I suppose it must be/originate on the PCI
>device chip.

It appears that neither OS understands how to configure non-standard
PCI registers. Maybe a 3rd party driver can, though.

>But DOS saw UDMA mode after Windows turned it off? Can it be DOS was
>seeing & reporting a UDMA capability-- but not necessarily that it was
>turned on?

DOS (even Win98 DOS?) predates UDMA.

>| I then returned to Windows (by
>| typing "win")
>
>If you had done... "START, Shut Down, Re-start in MS-DOS mode",... then
>normally EXIT (not WIN) would have been appropriate. WIN (I think)
>wouldn't have worked-- you'd have gotten a message that Windows was
>already started.

I always boot to DOS, but my autoexec.bat file is set up so that I am
presented with a choice of continuing to Windows or remaining in DOS.
If I choose Windows, then autoexec.bat executes "win.com". When I exit
Windows, I am returned to autoexec.bat which then performs some
housekeeping and leaves me at the command line.

>SO... I guess it is clear you exited Windows cleanly & without fear that
>it might not have done its housekeeping. BUT can it be a full reboot was
>necessary before the UDMA bit would be written to the PCI device?

Yes, that's why I avoided a full reboot. I wanted to see what Windows
had done to the IDE controller registers and to the ATA/ATAPI drives.

>| and found that the relevant PCI bit was still in the off
>| state and that the DMA checkbox for that drive was now unticked.
>
>By now, you did do a full reboot. I'm not sure that shutting off &
>booting to DOS was enough. But I guess it might have been. All I really
>know is, when I turned off DMA, I was requested to reboot. And --
>turning it back on -- the machine actually shut fully down on its own
>instead of requesting a reboot & on the second try!
>
>| This
>| suggests that Windows is unable or unwilling to disturb the IDE
>| controller's PCI registers, even if they are not optimally configured,
>| preferring to leave that up to the BIOS (or third party device
>| driver?).
>
>Both the IDE Controller & a device attached to it seem to be involved.
>I'm thinking so because two registry keys are involved when I
>check/uncheck DMA in my CD-ROM device...
>
>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\hdc\0002
>IDEDMADRIVE0 01 << Binary. It's 00 with DMA unchecked.

Ditto.

>HKEY_LOCAL_MACHINE\Enum\SCSI\IDE-CD__R/RW_4X4X24_____C\MF&CHILD0001&PCI&
>VEN_1106&DEV_0571&SUBSYS_00000000&REV_06&BUS_00&DEV_07&FUNC_0100
>DMACurrentlyUsed 01 << Binary. It's 00 with DMA unchecked.

Ditto.

>Are Wpcredit & that Identify Packet Device command accessing them both?
>The first key actually is mentioned in MSHDC.inf (as Lee pointed out--
>but the other one he mentioned, Diskdrv.inf, does not have it set)...
>
>[ESDI_AddReg]
>HKR,,DriverDesc,,"ESDI Port Driver"
>HKR,,DevLoader,,*IOS
>HKR,,PortDriver,,ESDI_506.pdr
>
>HKR,,IDEDMADrive0,3,01
>HKR,,IDEDMADrive1,3,01
>
>| It also suggests that Windows doesn't need to read any files
>| from a drive in order to test its UDMA capability.
>
>What is the difference between UDMA & DMA?

I don't really know.

> Do you have any .inf that
>mentions UDMA? I don't.

I don't either.

>I guess its possible Windows does the DEBUG
>thing glee posted to know whether a device supports DMA/UDMA instead of
>reading a bit from its EPROM (programmable ROM chip).

I tried to test this as follows:

- set the DVD-ROM drive to M-W DMA mode 2 in DOS
- type "win" and allow Windows to do its thing
- exit to DOS
- check whether the drive is now in UDMA mode

Unfortunately, after typing "win" there was a substantial flurry of
IDE activity, but then the system hung (the IDE LED was on solid). I
saw a similar problem when I chose M-W DMA-2 for the hard drive.

Next I tried something less aggressive, ie I set the HD to UDMA-1 (it
is normally set to UDMA-2). The system now booted into Windows and
Everest Home told me that the HD was configured for UDMA-1. So it
appears that Windows leaves these settings as they are.

BTW, in another post you will notice that I have resolved my Ricoh
problem by hacking its firmware. This enabled its M-W DMA modes.
However, now when I exit to DOS and attempt to run ideinfo.exe, it no
longer finds a secondary slave device. I have to Ctrl-Alt-Del before
the drive can be detected again.

I get the feeling that M-W DMA doesn't work right and that Ricoh may
have intentionally disabled it.

>| Anyway, without changing any Windows settings, I exited Windows, hit
>| the reset switch and booted into Windows again. This time the PCI
>| register was back to normal, and the DMA checkbox was automatically
>| re-ticked.
>
>What? How can that be? Can the DOS command have turned it back on? Then
>it took a reboot of Windows to see it? WIN was not enough? Sheesh!

It was a hardware reset, ie like powering off and on again. DOS was
not involved.

>| Another thing I followed up was Glen's link:
>| http://support.microsoft.com/?kbid=159560
>
>I tried that gingerly from a Windows DOS box twice two days after glee
>posted it & got an "FF" both times. I'm only sure I typed it wrong the
>1st time. I think it must be done in True DOS to work.

That's right. BTW, the above test is harmless. It doesn't make any
permanent changes.

>It says: "If the
>value returned is not 00 or 04, you may not have typed the characters
>correctly, or you may need to quit Windows." That is why I haven't tried
>a 3rd. Also, it never actually mentions a CD-ROM device, but only speaks
>of hard drives.

The ATAPI spec uses that same Set Features command for both hard
drives and CD-ROMs.

>| The Debug technique described by MS determines whether an IDE device
>| supports a multi-word DMA protocol, *not* UDMA. It suggests that any
>| device which supports multi-word DMA will get a tick in the DMA
>| checkbox, yet my Ricoh 2x CD writer, which supports multi-word DMA but
>| not UDMA, does not get a tick. I checked the output of the Identify
>| Packet Device command (word #63 = 0007) and found that it supports M-W
>| DMA modes 0,1,2. However none of these modes were selected. Maybe if I
>| selected M-W DMA mode 2 before starting Windows ...
>
>My head is still swimming after reading that 7 times! The tick in the
>DMA box I think more specifically would mean "to use" DMA. But I suppose
>it can be inferred the box wouldn't/shouldn't be there if DMA wasn't
>possible on the device. As far as "multi-word DMA protocol" vrs. UDMA, I
>suppose the same tickbox could apply to either-- but I really don't
>know. I see you are saying the IDE register is the same but would have a
>different value in it for UDMA. But this tickbox may be referring to a
>different bit in the register-- a bit that says to use or not use the
>DMA/UDMA.
>
>Are you saying the Ricoh 2x CD writer does not get a tickbox at all or
>that the box is just unchecked? If the former, it could be an .inf is
>involved.

The Ricoh writer reports that it *can* do multi-word DMA mode 2, but
not UDMA. It also responds correctly to the Set Features command used
in the MSKB article above. However, the Ricoh also confusingly reports
that it does *not* support DMA. This must confuse Windows and is
probably the reason why the DMA checkbox does not stay ticked.

>| Well, I dropped back to DOS, enabled M-W DMA mode 2, confirmed that
>| the output of the Identify Packet Device command reflected the change,
>| and then typed "win". Unfortunately the DMA checkbox did not stay
>| ticked.
>
>So, the Ricoh 2x CD does have a checkbox in Windows. But Windows doesn't
>allow you to check it-- just as was true for Shadow? (Did you try making
>it a slave as worked for him-- even alone on the cable?) You did in DOS
>what you believe caused the DMA box to get checked? But, back in
>Windows, it was still unchecked?

It's already a slave, and no, I didn't try it by itself.

>(a) "START, Find, Files or Folders"
>(b) Named: *.inf
>(c) Containing text: IDEDMADrive
> DMACurrentlyUsed
>(d) Look in: C:\WINDOWS\INF
>
>Is there any .inf that turns off IDEDMADrive (0 or 1) or
>DMACurrentlyUsed? Only the one I posted above has either of those even
>mentioned.
>
>| On returning to DOS I found that the drive was still set for
>| M-W DMA mode 2, so something else was amiss. I then discovered that
>| the "DMA supported" bit in word #49 was zero, ie not supported. Is
>| that what Windows is seeing? If so, then there doesn't appear to be
>| any way to set this bit. This then begs the question, does "DMA
>| supported" mean "M-W DMA supported" or "UDMA supported", or does it
>| refer to the long obsolete single-word DMA?
>
>You're making me dizzy again, Zabcar! But I'm still thinking at least
>two bits are involved-- one says what kind of DMA is available & the
>other says whether to use it or not. Also, I think both the IDE
>controller & the particular IDE device attached to might be involved.

I believe a drive can still be in PIO mode even if its "DMA supported"
bit is set. If you want to make a particular mode active, then that is
what the Set Features command does. The Set Features command does not
appear to affect the "DMA supported" bit. I have a feeling this bit is
read-only.

>| Referring to the method described in Glen's MS link above, to check
>| whether a device supports UDMA modes rather than M-W DMA modes, I
>| believe one just needs to replace the following step ...
>|
>| o 172 22 22 is for DMA mode 2, use 21 for DMA mode 1
>|
>| ... with ...
>|
>| o 172 42 42 is for UDMA mode 2, use 41 for UDMA mode 1
>
>So, you are saying the byte location is the same, but the value is
>different. OK. Maybe I'll try that again in True DOS-- maybe!

Don't be concerned. All changes are undone by a power-on reset.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Franc Zabkar]

Re: A hack, anyone, to turn on dma ? SOLVED ???

On Sun, 06 Jul 2008 07:26:37 +1000, Franc Zabkar
<fzabkar@iinternode.on.net> put finger to keyboard and composed:

>On Sat, 05 Jul 2008 10:16:44 -0300, Shadow <sh@dow> put finger to
>keyboard and composed:

>> Does it write any faster ?
>
>The maximum write speed (2x) is limited by design, so whether the
>drive is in PIO mode or DMA mode would make no difference. One would
>expect an improvement in read performance, though.
>
>To test this, I copied 575MB of data from a CD to my hard drive. With
>the DMA box ticked, the transfer took 13m 51s. After rebooting with
>the DMA box unticked, the transfer took 13m 18s. So it appears that
>PIO mode is faster for this setup, or maybe DMA mode is not being
>properly enabled.

I tried this again. I used the Debug method (in real DOS) to configure
the drive for multi-word DMA mode 2 and then typed "win". This time
the machine didn't hang but booted into Windows (the DMA box was
ticked beforehand). The same test now took 13m 16s. <shrug>

The above transfer rate works out as 0.72 MB/s. The transfer rate for
my DVD 10x drive is 2.0 MB/s. The latter is configured for UDMA-2.

After all my experimentation, I finally found this Ricoh FAQ:
http://www.ricoh.com/drive/asia/support/faq/allmodels/dma_d.html#04

DMA transfer mode supported by each model:

* MP6200A 11.11 MB/sec. (Max.) PIO mode 3
MP7040A 16.7 MB/sec. (Max.) Multiword DMA mode 2, PIO mode 4
....
MP5240A / MP5125A / MP5120A 33 MB/sec. (Max.) Ultra DMA mode 2

Now why doesn't the user manual have this information, and why does
the drive allow M-W DMA modes 0,1, and 2 to be set via the Set
Features command if it doesn't support them? And why does the DMA
checkbox remain ticked in Device Manager if the drive is in PIO mode?

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Franc Zabkar]

Re: A hack, anyone, to turn on dma ? SOLVED ???

On Sat, 05 Jul 2008 10:16:44 -0300, Shadow <sh@dow> put finger to
keyboard and composed:

> Funny Ricoh leaves the default on PIO. That firmware is from
>mid-2001. Most motherboards supported DMA then.

This is what I extracted from your drive's SB01 firmware:
http://www.users.on.net/~fzabkar/DVD/Samsung/SH-S182F.txt

Word #63 has a value of 0x0407 which suggests that your drive powers
up in multiword DMA mode 2, not UDMA mode.

However, your ideinfo.exe output doesn't show any MW DMA transfer mode
as active, so it appears that your BIOS reconfigures the drive,
probably for UDMA mode. You really need to check word #88 to be sure.

FYI, these are the supported media types that I found in the SB01
Samsung firmware:
http://www.users.on.net/~fzabkar/DVD/Samsung/SH-S182F_media.txt

If any disc burns at less than its rated speed, then it may be because
it is not a recognised media type.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[PCR]

Re: A hack, anyone, to turn on dma ? SOLVED ???

Franc Zabkar wrote:
| On Fri, 4 Jul 2008 18:23:39 -0400, "PCR" <pcrrcp@netzero.net> put
| finger to keyboard and composed:
|
|>Shadow wrote:
|>| On Thu, 3 Jul 2008 16:50:57 -0400, "PCR" <pcrrcp@netzero.net> wrote:
|>|
|>|>I think Shadow is fairly happy as is now that he has set the DVD to
|>|>be a slave. He's got his DMA.
|>| Fairly ? I'm VERY happy
|>| []'s
|>
|>Judging from the speed difference, it was well worth your effort!
|>Looks like Zabcar has found a Ricoh 2x CD writer with the same
|>problem. I wonder whether the same weird solution will work?
|>Imagine-- a slave on a cable all by itself! It turns conventional
|>knowledge on its head! But I'm glad it worked for you.
|
| My Ricoh writer appears to have been stuck in PIO mode all its life.
| I've just assumed all along that it wasn't capable of DMA mode. It
| appears that my motherboard's BIOS thought so, too.

I see elsewhere you said your drive already is a slave so, Shadow's
solution could not works for you.

| But now my problem is *solved*! I found the firmware file ...
|
|
http://www.met.com.tw/download_file/cdrw/ricoh/mmp1/6200a/mp6200ad240.exe
|
| ... extracted the .bin, and hacked it.
|
| I did this by locating the section within the code that contained the
| Identify Packet Device data block. I then changed the "DMA not
| supported" bit at word #49 to "supported". I also recomputed the
| checksum (which was stored in the first two bytes of the .bin) and
| then flashed this modified firmware into my writer.
|
| After booting into Windows, the DMA box was now ticked. It remained
| ticked after copying 36MB of data from a CD to my hard drive, and all
| the files verified OK using the "fc /b" command.

Phew! That's more than I could have done-- altering the .bin file &
adjusting the checksum! Pretty nice! The .bin file (I think I read) has
something to do with the BIOS of the device. Too, too bad it did not
increase file transfer speed like it did so dramatically for Shadow. But
he had a DVD which normally is quicker & may more likely show an
improvement.

| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net

 

[PCR]

Re: A hack, anyone, to turn on dma ? SOLVED ???

Franc Zabkar wrote:
| On Sun, 06 Jul 2008 07:26:37 +1000, Franc Zabkar
| <fzabkar@iinternode.on.net> put finger to keyboard and composed:
|
|>On Sat, 05 Jul 2008 10:16:44 -0300, Shadow <sh@dow> put finger to
|>keyboard and composed:
|
|>> Does it write any faster ?
|>
|>The maximum write speed (2x) is limited by design, so whether the
|>drive is in PIO mode or DMA mode would make no difference. One would
|>expect an improvement in read performance, though.

Remember that article...?...
http://support.microsoft.com/?kbid=159560
DMA Check Box Does Not Remain Checked
........Quote......................
MORE INFORMATION

DMA (also referred to as bus mastering) reduces CPU overhead by
providing a mechanism for data transfers that do not require monitoring
by the CPU. The transfer rate for a particular data transfer event will
not noticeably increase. However, overall CPU overhead should be reduced
using DMA mode.
........EOQ.........................

So, it may be you haven't seen an improvement in speed of data transfer
because your CPU wasn't overly busy during the data transfer when in PIO
mode. In DMA mode, supposedly the CPU can afford to be busy with other
things while the CD-ROM chip handles the data transfer more/less on its
own. But the actualy speed of the CD-ROM device itself probably remains
about the same.

|>To test this, I copied 575MB of data from a CD to my hard drive. With
|>the DMA box ticked, the transfer took 13m 51s. After rebooting with
|>the DMA box unticked, the transfer took 13m 18s. So it appears that
|>PIO mode is faster for this setup, or maybe DMA mode is not being
|>properly enabled.

Well, I didn't try to time it precisely, but I copied about 300 MB from
my "IDE-CD R/RW 4x4x24" to HDD in about 8 minutes-- with DMA turned on.
All the while I was online with OE open & running. I can't look up any
specs-- I don't know precisely what that thing is! I recall seeing a
Philips in the box-- but can't recall where I may have written its model
number. And I hesitate to turn that DMA off again for another test! Here
is about all my Compaq Diagnostics says about it...

IDE-CD R/RW 4x4x24 CD-RW
Firmware Revision . . . . C12a
Adapter . . . . . . . . . . . . 0
Target . . . . . . . . . . . . . 0
Lun . . . . . . . . . . . . . . . 0
Medium Removable . . . . Yes
Write Type . . . . . . . . . . Track-at-once
Test Writing . . . . . . . . . No
Fixed Packet . . . . . . . . . No
CD-ROM XA Commands . . Not Supported
Mode 2 Form 1 Format . . . Supported
Mode 2 Form 2 Format . . . Supported
Multi-Session Format . . . . Supported
UPC Information . . . . . . . Supported
ISRC Information . . . . . . . Supported
Media Locking . . . . . . . . . Supported
Lock State . . . . . . . . . . . . Unlocked
Independent Channel Volume . . Supported
Independent Channel Mute . . . . Supported

| I tried this again. I used the Debug method (in real DOS) to configure
| the drive for multi-word DMA mode 2 and then typed "win". This time
| the machine didn't hang but booted into Windows (the DMA box was
| ticked beforehand). The same test now took 13m 16s. <shrug>
|
| The above transfer rate works out as 0.72 MB/s. The transfer rate for
| my DVD 10x drive is 2.0 MB/s. The latter is configured for UDMA-2.

Mine comes to about 0.625 MB/s. But it seemed quick enough for me. Part
of that was "preparing to copy". Also, the device seemed to power down &
up again at least once in the midst of the copy.

| After all my experimentation, I finally found this Ricoh FAQ:
| http://www.ricoh.com/drive/asia/support/faq/allmodels/dma_d.html#04
|
| DMA transfer mode supported by each model:
|
| * MP6200A 11.11 MB/sec. (Max.) PIO mode 3
| MP7040A 16.7 MB/sec. (Max.) Multiword DMA mode 2, PIO mode 4
| ....
| MP5240A / MP5125A / MP5120A 33 MB/sec. (Max.) Ultra DMA mode 2
|
| Now why doesn't the user manual have this information, and why does
| the drive allow M-W DMA modes 0,1, and 2 to be set via the Set
| Features command if it doesn't support them?

Can it be they had early plans to support them but later aborted without
undoing the prep work?

| And why does the DMA
| checkbox remain ticked in Device Manager if the drive is in PIO mode?

Maybe there is something non-standard about one of the PIO modes that
makes it look a lot like one of the DMA modes.

| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net

 

[PCR]

Re: A hack, anyone, to turn on dma ? SOLVED ???

Franc Zabkar wrote:
| On Fri, 4 Jul 2008 18:14:21 -0400, "PCR" <pcrrcp@netzero.net> put
| finger to keyboard and composed:
|
|>Franc Zabkar wrote:
|
|>| I used Wpcredit to turn off the DMA enable bit in the PCI register
|>| for my UDMA capable DVD-ROM drive.
|>
|>What/where is the PCI register-- a construct in the computer's RAM or
|>on a writeable PCI device chip? If on the PCI device, is BIOS
|>responsible for setting up an interface to it?
|
| It's in the PCI IDE controller device within the southbridge component
| of the motherboard chipset. The chipset registers contain
| configuration settings which determine the behaviour and function of
| the IDE controller. They can be set by the BIOS or by device drivers
| or by the user.

In Device Manager, viewing "by connection", there is (though leaving
some out)...

Computer
PCI Bus
VIA Master PCI IDE Controller
Secondary IDE Controller
IDE-CD R/RW 4x4x24

I'm thinking all of that is part of the computer-- except the last,
which is an add-on peripheral. I see I can get Properties for all of
those. The Settings tab of the PCI Bus allows "enumeration" to "Use
Hardware" or "Use BIOS". Mine is bolted to use hardware. There also is a
checkbox to "Override Bridges", which is unchecked for me. I'm thinking
these settings could make a big difference in our doings with this DMA
puzzle-- but I can't really precisely say what! The Settings tab of the
VIA Master PCI IDE Controller actually allows turning off IDE channels.
Mine is set to "default". The Secondary IDE Controller has no Settings
tab. (Neither does the Primary IDE Controller.)

Only the Settings tab of the IDE-CD R/RW 4x4x24 has a DMA checkbox,
which you know is checked for me (& I can uncheck it but much hesitate
to do so again). That is why I'm thinking the PCI Register is or should
be on the CD-ROM device itself. Why -- after unchecking DMA -- should it
go off for anything except the particular device unchecked?

| BTW, you need to be careful because some registers, eg some SiS USB
| controller registers, are "write-once". Whatever data you write to
| them may become permanent. But the datasheet should tell you this.

Yikes-- I was afraid of something like that!!! I seem to have survived,
but I hesitate to try that DEBUG thing of glee's again! I know for sure
I typed it wrong at least once!

|>| After exiting Windows and returning to
|>| a DOS command line, an Identify Packet Device command determined
|>| that the drive was still in UDMA mode.
|>
|>If both DOS & Windows are expected to access the PCI register (i.e.,
|>it is OS independent)... then I suppose it must be/originate on the
|>PCI device chip.
|
| It appears that neither OS understands how to configure non-standard
| PCI registers. Maybe a 3rd party driver can, though.

Maybe specs have changed along the way &/or maybe some manufacturers
never followed suggested protocols in the first place-- who knows?

|>But DOS saw UDMA mode after Windows turned it off? Can it be DOS was
|>seeing & reporting a UDMA capability-- but not necessarily that it was
|>turned on?
|
| DOS (even Win98 DOS?) predates UDMA.

It might not matter-- IF UDMA uses the same byte &/or bit as DMA for its
communications & if UDMA requires the same sort of shared memory area.
DOS would just have to get its data into the shared memory & tell the
CD-ROM device it is there, I guess. Then, the device does the transfer
using code on its chip.

|>| I then returned to Windows (by
|>| typing "win")
|>
|>If you had done... "START, Shut Down, Re-start in MS-DOS mode",...
|>then normally EXIT (not WIN) would have been appropriate. WIN (I
|>think) wouldn't have worked-- you'd have gotten a message that
|>Windows was already started.
|
| I always boot to DOS, but my autoexec.bat file is set up so that I am
| presented with a choice of continuing to Windows or remaining in DOS.
| If I choose Windows, then autoexec.bat executes "win.com". When I exit
| Windows, I am returned to autoexec.bat which then performs some
| housekeeping and leaves me at the command line.

OK. Now I recall you've said as much in other threads. I'm trying to
think whether this allows Windows to write data to the PCI Register &
whether DOS would then know of the change-- & visa versa too! Can it be
the machine must actually be turned off first-- to allow BIOS to put the
change into the device? Then, when turned back on, BIOS will read the
new data & make it available to DOS/Windows.

|>SO... I guess it is clear you exited Windows cleanly & without fear
|>that it might not have done its housekeeping. BUT can it be a full
|>reboot was necessary before the UDMA bit would be written to the PCI
|>device?
|
| Yes, that's why I avoided a full reboot. I wanted to see what Windows
| had done to the IDE controller registers and to the ATA/ATAPI drives.

DOS won't understand any Windows construct, if one is involved. I'm
thinking Windows or BIOS must get any change of DMA status written to
the device & BIOS must be started again. Even if your BIOS-DOS-WIN-DOS
had managed to get it written to the device-- BIOS must read it off the
device again to make the change available to DOS & possibly even to
another WIN-- or so I'm guessing.

|>| and found that the relevant PCI bit was still in the off
|>| state and that the DMA checkbox for that drive was now unticked.
|>
|>By now, you did do a full reboot. I'm not sure that shutting off &
|>booting to DOS was enough. But I guess it might have been. All I
|>really know is, when I turned off DMA, I was requested to reboot. And
|>-- turning it back on -- the machine actually shut fully down on its
|>own instead of requesting a reboot & on the second try!
|>
|>| This
|>| suggests that Windows is unable or unwilling to disturb the IDE
|>| controller's PCI registers, even if they are not optimally
|>| configured, preferring to leave that up to the BIOS (or third party
|>| device driver?).
|>
|>Both the IDE Controller & a device attached to it seem to be involved.
|>I'm thinking so because two registry keys are involved when I
|>check/uncheck DMA in my CD-ROM device...
|>
|>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\hdc\0002
|>IDEDMADRIVE0 01 << Binary. It's 00 with DMA unchecked.
|
| Ditto.

I'm not sure what that one is referring to. Is it capability of DMA for
the CD-ROM device? Why would capability be turned off?

|>HKEY_LOCAL_MACHINE\Enum\SCSI\IDE-CD__R/RW_4X4X24_____C\MF&CHILD0001&PC
I&
|>VEN_1106&DEV_0571&SUBSYS_00000000&REV_06&BUS_00&DEV_07&FUNC_0100
|>DMACurrentlyUsed 01 << Binary. It's 00 with DMA unchecked.
|
| Ditto.

This seems to be speaking of whether/not DMA is in use. This one makes
sense.

|>Are Wpcredit & that Identify Packet Device command accessing them
|>both? The first key actually is mentioned in MSHDC.inf (as Lee
|>pointed out-- but the other one he mentioned, Diskdrv.inf, does not
|>have it set)...
|>
|>[ESDI_AddReg]
|>HKR,,DriverDesc,,"ESDI Port Driver"
|>HKR,,DevLoader,,*IOS
|>HKR,,PortDriver,,ESDI_506.pdr
|>
|>HKR,,IDEDMADrive0,3,01
|>HKR,,IDEDMADrive1,3,01

This .inf didn't turn that key back on during my reboot after having
unchecked DMA. Neither do I see "ESDI Port Driver" anywhere in my
registry. Well, fine, I guess it just doesn't apply as my CD-ROM is IDE.

|>| It also suggests that Windows doesn't need to read any files
|>| from a drive in order to test its UDMA capability.
|>
|>What is the difference between UDMA & DMA?
|
| I don't really know.

Why do you keep bringing UDMA into it, then-- if neither of us knows
what it is? And I doubt Shadow does either!

|> Do you have any .inf that
|>mentions UDMA? I don't.
|
| I don't either.
|
|>I guess its possible Windows does the DEBUG
|>thing glee posted to know whether a device supports DMA/UDMA instead
|>of reading a bit from its EPROM (programmable ROM chip).
|
| I tried to test this as follows:
|
| - set the DVD-ROM drive to M-W DMA mode 2 in DOS
| - type "win" and allow Windows to do its thing
| - exit to DOS
| - check whether the drive is now in UDMA mode
|
| Unfortunately, after typing "win" there was a substantial flurry of
| IDE activity, but then the system hung (the IDE LED was on solid). I
| saw a similar problem when I chose M-W DMA-2 for the hard drive.

Sounds like Windows got confused. Your DOS manipulation may have been
incomplete or may have set the CD-ROM to do something it couldn't. Did
you try using the CD-ROM in DOS after setting it as you did?

| Next I tried something less aggressive, ie I set the HD to UDMA-1 (it
| is normally set to UDMA-2). The system now booted into Windows and
| Everest Home told me that the HD was configured for UDMA-1. So it
| appears that Windows leaves these settings as they are.

That sounds MORE aggressive to me-- to fool with the HDD! But, as it
worked, things could be different for HDD, I guess. After all, that
DEBUG article kept mentioning HDD-- not CD-ROM. I know you suggest they
are the same.

Since Windows did see the change DOS made... I guess DOS wrote to the
BIOS construct that Windows also will utilize. Or, the change got put to
the device & Windows read it from there.

| BTW, in another post you will notice that I have resolved my Ricoh
| problem by hacking its firmware. This enabled its M-W DMA modes.
| However, now when I exit to DOS and attempt to run ideinfo.exe, it no
| longer finds a secondary slave device. I have to Ctrl-Alt-Del before
| the drive can be detected again.

Could be somehow more got changed in the .bin file than expected. Sounds
like a dangerous enterprise!

| I get the feeling that M-W DMA doesn't work right and that Ricoh may
| have intentionally disabled it.

Could be. You didn't get a dramatic speed difference anyhow. I should
turn off DMA once more & see what the difference is for me-- but it was
a bit scary getting it back on!

|>| Anyway, without changing any Windows settings, I exited Windows, hit
|>| the reset switch and booted into Windows again. This time the PCI
|>| register was back to normal, and the DMA checkbox was automatically
|>| re-ticked.
|>
|>What? How can that be? Can the DOS command have turned it back on?
|>Then it took a reboot of Windows to see it? WIN was not enough?
|>Sheesh!
|
| It was a hardware reset, ie like powering off and on again. DOS was
| not involved.

I'm still unsure what to make of it. You went...
BIOS-DOS-WIN-DOS-WIN-RESET. At the 1st WIN you "used Wpcredit to turn
off the DMA enable bit in the PCI register for my UDMA capable DVD-ROM
drive". DOS didn't see it: "an Identify Packet Device command determined
that the drive was still in UDMA mode". The 2nd WIN still did still see
it: "found that the relevant PCI bit was still in the off state and that
the DMA checkbox for that drive was now unticked". RESET made it
disappear.

But, I'm guessing it's likely the 2nd DOS didn't try to update its
knowledge of the device. Actually, though, even if it had, it wouldn't
have gotten new knowledge-- Windows apparently never wrote to the
device. The 2nd WIN didn't re-read data from the device, either, but
relied on a construct that was updated in the 1st WIN, looks like. After
the RESET, the device was read anew by BIOS & all was back to original
spec. That's what proves the device was never written to.

I do know I can turn DMA off using Device Manager. Therefore, either
Wpcredit can't do it OR Windows was not shut down properly for it to
complete. OR UDMA is sufficiently different from DMA to prevent it being
possible in the first place.

|>| Another thing I followed up was Glen's link:
|>| http://support.microsoft.com/?kbid=159560
|>
|>I tried that gingerly from a Windows DOS box twice two days after glee
|>posted it & got an "FF" both times. I'm only sure I typed it wrong the
|>1st time. I think it must be done in True DOS to work.
|
| That's right. BTW, the above test is harmless. It doesn't make any
| permanent changes.

I'm reassured. I think never typed a line that wasn't in that document,
but only (the 1st time) left a line out. The 2nd time, I got those "FF"
anyhow, but we know why.

|>It says: "If the
|>value returned is not 00 or 04, you may not have typed the characters
|>correctly, or you may need to quit Windows." That is why I haven't
|>tried a 3rd. Also, it never actually mentions a CD-ROM device, but
|>only speaks of hard drives.
|
| The ATAPI spec uses that same Set Features command for both hard
| drives and CD-ROMs.

It could be the addresses differ slightly. (I don't know.)

|>| The Debug technique described by MS determines whether an IDE device
|>| supports a multi-word DMA protocol, *not* UDMA. It suggests that any
|>| device which supports multi-word DMA will get a tick in the DMA
|>| checkbox, yet my Ricoh 2x CD writer, which supports multi-word DMA
|>| but not UDMA, does not get a tick. I checked the output of the
|>| Identify Packet Device command (word #63 = 0007) and found that it
|>| supports M-W DMA modes 0,1,2. However none of these modes were
|>| selected. Maybe if I selected M-W DMA mode 2 before starting
|>| Windows ...
|>
|>My head is still swimming after reading that 7 times! The tick in the
|>DMA box I think more specifically would mean "to use" DMA. But I
|>suppose it can be inferred the box wouldn't/shouldn't be there if DMA
|>wasn't possible on the device. As far as "multi-word DMA protocol"
|>vrs. UDMA, I suppose the same tickbox could apply to either-- but I
|>really don't know. I see you are saying the IDE register is the same
|>but would have a different value in it for UDMA. But this tickbox may
|>be referring to a different bit in the register-- a bit that says to
|>use or not use the DMA/UDMA.
|>
|>Are you saying the Ricoh 2x CD writer does not get a tickbox at all or
|>that the box is just unchecked? If the former, it could be an .inf is
|>involved.
|
| The Ricoh writer reports that it *can* do multi-word DMA mode 2, but
| not UDMA. It also responds correctly to the Set Features command used
| in the MSKB article above. However, the Ricoh also confusingly reports
| that it does *not* support DMA. This must confuse Windows and is
| probably the reason why the DMA checkbox does not stay ticked.

Maybe it wasn't fully implemented or they knew they didn't get it right,
as I think you have speculated elsewhere.

|>| Well, I dropped back to DOS, enabled M-W DMA mode 2, confirmed that
|>| the output of the Identify Packet Device command reflected the
|>| change, and then typed "win". Unfortunately the DMA checkbox did
|>| not stay ticked.
|>
|>So, the Ricoh 2x CD does have a checkbox in Windows. But Windows
|>doesn't allow you to check it-- just as was true for Shadow? (Did you
|>try making it a slave as worked for him-- even alone on the cable?)
|>You did in DOS what you believe caused the DMA box to get checked?
|>But, back in Windows, it was still unchecked?
|
| It's already a slave, and no, I didn't try it by itself.

OK. I suppose you do have a master on the cable. I don't know whether it
would be worthwhile to try switching the two or even just remove the
master temporarily to get like Shadow-- slave alone on the cable. If you
really end up with no improvement over PIO-- it just isn't worth it,
anyhow.

|>(a) "START, Find, Files or Folders"
|>(b) Named: *.inf
|>(c) Containing text: IDEDMADrive
|> DMACurrentlyUsed
|>(d) Look in: C:\WINDOWS\INF
|>
|>Is there any .inf that turns off IDEDMADrive (0 or 1) or
|>DMACurrentlyUsed? Only the one I posted above has either of those even
|>mentioned.
|>
|>| On returning to DOS I found that the drive was still set for
|>| M-W DMA mode 2, so something else was amiss. I then discovered that
|>| the "DMA supported" bit in word #49 was zero, ie not supported. Is
|>| that what Windows is seeing? If so, then there doesn't appear to be
|>| any way to set this bit. This then begs the question, does "DMA
|>| supported" mean "M-W DMA supported" or "UDMA supported", or does it
|>| refer to the long obsolete single-word DMA?
|>
|>You're making me dizzy again, Zabcar! But I'm still thinking at least
|>two bits are involved-- one says what kind of DMA is available & the
|>other says whether to use it or not. Also, I think both the IDE
|>controller & the particular IDE device attached to might be involved.
|
| I believe a drive can still be in PIO mode even if its "DMA supported"
| bit is set. If you want to make a particular mode active, then that is
| what the Set Features command does. The Set Features command does not
| appear to affect the "DMA supported" bit. I have a feeling this bit is
| read-only.

Is that the bit you altered by editing the .bin file?

|>| Referring to the method described in Glen's MS link above, to check
|>| whether a device supports UDMA modes rather than M-W DMA modes, I
|>| believe one just needs to replace the following step ...
|>|
|>| o 172 22 22 is for DMA mode 2, use 21 for DMA mode 1
|>|
|>| ... with ...
|>|
|>| o 172 42 42 is for UDMA mode 2, use 41 for UDMA mode 1
|>
|>So, you are saying the byte location is the same, but the value is
|>different. OK. Maybe I'll try that again in True DOS-- maybe!
|
| Don't be concerned. All changes are undone by a power-on reset.

I'm reassured, thanks.

| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net

 

[Franc Zabkar]

Re: A hack, anyone, to turn on dma ? SOLVED ???

On Sun, 6 Jul 2008 18:20:51 -0400, "PCR" <pcrrcp@netzero.net> put
finger to keyboard and composed:

>Franc Zabkar wrote:
>| On Sun, 06 Jul 2008 07:26:37 +1000, Franc Zabkar
>| <fzabkar@iinternode.on.net> put finger to keyboard and composed:
>|
>|>On Sat, 05 Jul 2008 10:16:44 -0300, Shadow <sh@dow> put finger to
>|>keyboard and composed:
>|
>|>> Does it write any faster ?
>|>
>|>The maximum write speed (2x) is limited by design, so whether the
>|>drive is in PIO mode or DMA mode would make no difference. One would
>|>expect an improvement in read performance, though.
>
>Remember that article...?...
>http://support.microsoft.com/?kbid=159560
>DMA Check Box Does Not Remain Checked
>.......Quote......................
>MORE INFORMATION
>
>DMA (also referred to as bus mastering) reduces CPU overhead by
>providing a mechanism for data transfers that do not require monitoring
>by the CPU. The transfer rate for a particular data transfer event will
>not noticeably increase. However, overall CPU overhead should be reduced
>using DMA mode.
>.......EOQ.........................

Thanks, that makes sense, although PIO mode 3 is spec'ed for 11.1 MB/s
and MW DMA 2 for 16.6 MB/s.

http://en.wikipedia.org/wiki/Atapi#ATA_standards_versions.2C_transfer_rates.2C_and_features

>... I copied about 300 MB from
>my "IDE-CD R/RW 4x4x24" to HDD in about 8 minutes-- with DMA turned on.
>All the while I was online with OE open & running.

I had no apps running during the test.

>I can't look up any
>specs-- I don't know precisely what that thing is! I recall seeing a
>Philips in the box-- but can't recall where I may have written its model
>number. And I hesitate to turn that DMA off again for another test! Here
>is about all my Compaq Diagnostics says about it...
>
>IDE-CD R/RW 4x4x24 CD-RW
> Firmware Revision . . . . C12a

This discussion ...

http://discussions.virtualdr.com/archive/index.php/t-101564.html

.... suggests that you have a "CompaQ CDD4401/71 CD-RW, which is
basically a Philips PCRW404K".

I found these Philips support URLs:
http://www.p4c.philips.com/files/p/pcrw404k_00/
http://www.p4c.philips.com/files/p/

.... and this discussion ...

http://www.broadbandreports.com/forum/remark,16350636

.... which suggests that the following C1.8 firmware upgrade is for
your CDD4401 drive:
ftp://ftp.compaq.com/pub/softpaq/sp16501-17000/sp16704.exe
ftp://ftp.compaq.com/pub/softpaq/sp16501-17000/sp16704.txt

This is the Identify Packet Device data I extracted from the C18
firmware:
http://www.users.on.net/~fzabkar/DVD/C18.txt

It indicates that your drive supports MW DMA mode 2 and PIO mode 4,
but it does not support UDMA. It powers up in MW DMA mode 2. The "DMA
supported" bit is set.

>| I tried this again. I used the Debug method (in real DOS) to configure
>| the drive for multi-word DMA mode 2 and then typed "win". This time
>| the machine didn't hang but booted into Windows (the DMA box was
>| ticked beforehand). The same test now took 13m 16s. <shrug>
>|
>| The above transfer rate works out as 0.72 MB/s. The transfer rate for
>| my DVD 10x drive is 2.0 MB/s. The latter is configured for UDMA-2.
>
>Mine comes to about 0.625 MB/s. But it seemed quick enough for me. Part
>of that was "preparing to copy". Also, the device seemed to power down &
>up again at least once in the midst of the copy.

My FSB is set to 75MHz, so that means my PCI bus is running at
37.5MHz. Yours is probably set to 33MHz. Therefore I would expect a
13% speed advantage for the same transfer mode.

>| After all my experimentation, I finally found this Ricoh FAQ:
>| http://www.ricoh.com/drive/asia/support/faq/allmodels/dma_d.html#04
>|
>| DMA transfer mode supported by each model:
>|
>| * MP6200A 11.11 MB/sec. (Max.) PIO mode 3
>| MP7040A 16.7 MB/sec. (Max.) Multiword DMA mode 2, PIO mode 4
>| ....
>| MP5240A / MP5125A / MP5120A 33 MB/sec. (Max.) Ultra DMA mode 2
>|
>| Now why doesn't the user manual have this information, and why does
>| the drive allow M-W DMA modes 0,1, and 2 to be set via the Set
>| Features command if it doesn't support them?
>
>Can it be they had early plans to support them but later aborted without
>undoing the prep work?

Maybe. Or maybe the programmers used the same basic code for several
models and just disabled the modules they didn't need.

>| And why does the DMA
>| checkbox remain ticked in Device Manager if the drive is in PIO mode?
>
>Maybe there is something non-standard about one of the PIO modes that
>makes it look a lot like one of the DMA modes.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Shadow]

Re: A hack, anyone, to turn on dma ? SOLVED ???

On Mon, 07 Jul 2008 07:45:17 +1000, Franc Zabkar
<fzabkar@iinternode.on.net> wrote:

>On Sat, 05 Jul 2008 10:16:44 -0300, Shadow <sh@dow> put finger to
>keyboard and composed:
>
>> Funny Ricoh leaves the default on PIO. That firmware is from
>>mid-2001. Most motherboards supported DMA then.
>
>This is what I extracted from your drive's SB01 firmware:
Thanks for the effort. But I am quite happy, of the "best not to hack
what is already working type"
I use SB02:
http://www.samsungodd.com/eng/Firmw..._code=&SearchMode=TOTALSEARCH&SearchWord=182f

I am a compulsive flasher
Above link probably wraps.
[]'s

 

[PCR]

Re: A hack, anyone, to turn on dma ? SOLVED ???

Franc Zabkar wrote:
| On Sun, 6 Jul 2008 18:20:51 -0400, "PCR" <pcrrcp@netzero.net> put
| finger to keyboard and composed:
|
|>Franc Zabkar wrote:
|>| On Sun, 06 Jul 2008 07:26:37 +1000, Franc Zabkar
|>| <fzabkar@iinternode.on.net> put finger to keyboard and composed:
|>|
|>|>On Sat, 05 Jul 2008 10:16:44 -0300, Shadow <sh@dow> put finger to
|>|>keyboard and composed:
|>|
|>|>> Does it write any faster ?
|>|>
|>|>The maximum write speed (2x) is limited by design, so whether the
|>|>drive is in PIO mode or DMA mode would make no difference. One would
|>|>expect an improvement in read performance, though.
|>
|>Remember that article...?...
|>http://support.microsoft.com/?kbid=159560
|>DMA Check Box Does Not Remain Checked
|>.......Quote......................
|>MORE INFORMATION
|>
|>DMA (also referred to as bus mastering) reduces CPU overhead by
|>providing a mechanism for data transfers that do not require
|>monitoring by the CPU. The transfer rate for a particular data
|>transfer event will not noticeably increase. However, overall CPU
|>overhead should be reduced using DMA mode.
|>.......EOQ.........................
|
| Thanks, that makes sense, although PIO mode 3 is spec'ed for 11.1 MB/s
| and MW DMA 2 for 16.6 MB/s.
|
|
http://en.wikipedia.org/wiki/Atapi#ATA_standards_versions.2C_transfer_rates.2C_and_features

Alright. That article does state there is some variance in what speed
may actually be attained for any of the modes, due to clock cycle
considerations & bus congestion. But those were probably much the same
for your PIO 3 vrs. MW DMA 2 test. As far as whether the CPU was busy
(which the MS article implies gives DMA the edge because the IDE device
will do the transfer)... you do say you had no apps running. (Naturally,
the OS itself is always running, but CPU usage from that alone can often
show up as zero in System Monitor.)

Nevertheless -- because these various DMA modes have different speed
ratings (although that could be because devices got quicker themselves
by the time the UDMA modes came out)-- I'm beginning to wonder whether a
busy CPU is all that should make DMA quicker. I'm tempted again to turn
mine off & see what happens-- but I see PIO 4 & MW DMA 2 have the same
16.6 MB/s rating. So, that won't help!

Anyhow, let me start Process Explorer. That has made CPU Usage jump to
the 70's! With DMA still on, let me copy that 300 MB's again to see
whether it still takes only about 8 minutes....

YIKES, it took 19 minutes that time!!! Why???

(Well, I normally won't have a CPU that busy during CD-ROM usage,
anyhow.)

|>... I copied about 300 MB from
|>my "IDE-CD R/RW 4x4x24" to HDD in about 8 minutes-- with DMA turned
|>on. All the while I was online with OE open & running.
|
| I had no apps running during the test.
|
|>I can't look up any
|>specs-- I don't know precisely what that thing is! I recall seeing a
|>Philips in the box-- but can't recall where I may have written its
|>model number. And I hesitate to turn that DMA off again for another
|>test! Here is about all my Compaq Diagnostics says about it...
|>
|>IDE-CD R/RW 4x4x24 CD-RW
|> Firmware Revision . . . . C12a
|
| This discussion ...
|
| http://discussions.virtualdr.com/archive/index.php/t-101564.html
|
| ... suggests that you have a "CompaQ CDD4401/71 CD-RW, which is
| basically a Philips PCRW404K".
|
| I found these Philips support URLs:
| http://www.p4c.philips.com/files/p/pcrw404k_00/
| http://www.p4c.philips.com/files/p/
|
| ... and this discussion ...
|
| http://www.broadbandreports.com/forum/remark,16350636
|
| ... which suggests that the following C1.8 firmware upgrade is for
| your CDD4401 drive:
| ftp://ftp.compaq.com/pub/softpaq/sp16501-17000/sp16704.exe
| ftp://ftp.compaq.com/pub/softpaq/sp16501-17000/sp16704.txt
|
| This is the Identify Packet Device data I extracted from the C18
| firmware:
| http://www.users.on.net/~fzabkar/DVD/C18.txt
|
| It indicates that your drive supports MW DMA mode 2 and PIO mode 4,
| but it does not support UDMA. It powers up in MW DMA mode 2. The "DMA
| supported" bit is set.

Thanks for all of that. I took the download. That SP16704 wasn't among
the many I once downloaded for this Compaq 7470. It wasn't listed for
this computer, but I see now not all of them came with a Philips inside.
I wish my Compaq Diagnostics would precisely spell out which Philips
I've got-- in case more than one is a possibility. I only know I've got
a Philips at all because I vaguely recall seeing it in the box.

|>| I tried this again. I used the Debug method (in real DOS) to
|>| configure the drive for multi-word DMA mode 2 and then typed "win".
|>| This time the machine didn't hang but booted into Windows (the DMA
|>| box was ticked beforehand). The same test now took 13m 16s. <shrug>
|>|
|>| The above transfer rate works out as 0.72 MB/s. The transfer rate
|>| for my DVD 10x drive is 2.0 MB/s. The latter is configured for
|>| UDMA-2.
|>
|>Mine comes to about 0.625 MB/s. But it seemed quick enough for me.
|>Part of that was "preparing to copy". Also, the device seemed to
|>power down & up again at least once in the midst of the copy.
|
| My FSB is set to 75MHz, so that means my PCI bus is running at
| 37.5MHz. Yours is probably set to 33MHz. Therefore I would expect a
| 13% speed advantage for the same transfer mode.

I'm not sure of my figure. In the BIOS, IDE Devices requestor, I see
that "Ultra 33/66" is enabled. My processor speed is written: 533/97
MHz. I did kept avast! running & it scanned all the executables during
the copy process.

Neither of us got 16.6 MB/s for MW DMA 2-- but I'm not really sure when
they start/stop counting! Are they speaking of the device already has
everything set & is about to move its heads? And as soon as the heads
stop moving they are done counting? We are going through "preparing to
copy", watching the CD-ROM spin down & up again midst the copy, & even
waiting for Explorer to update its display after the copy is done.
Nevertheless, it all seemed quick enough for me. Possibly the highest
figures will only apply to hard drives, I'm thinking.

|>| After all my experimentation, I finally found this Ricoh FAQ:
|>| http://www.ricoh.com/drive/asia/support/faq/allmodels/dma_d.html#04
|>|
|>| DMA transfer mode supported by each model:
|>|
|>| * MP6200A 11.11 MB/sec. (Max.) PIO mode 3
|>| MP7040A 16.7 MB/sec. (Max.) Multiword DMA mode 2, PIO mode 4
|>| ....
|>| MP5240A / MP5125A / MP5120A 33 MB/sec. (Max.) Ultra DMA mode 2
|>|
|>| Now why doesn't the user manual have this information, and why does
|>| the drive allow M-W DMA modes 0,1, and 2 to be set via the Set
|>| Features command if it doesn't support them?
|>
|>Can it be they had early plans to support them but later aborted
|>without undoing the prep work?
|
| Maybe. Or maybe the programmers used the same basic code for several
| models and just disabled the modules they didn't need.

Now I'm thinking the drive software is just not looking at the time the
Set Features command puts info into the PCI Register. It could put
anything in there, probably. When Windows & the drive are ready to use
it to determine what mode to use, its up to them what to do if/when an
invalid value is found. Apparently, neither will correct the value, but
possibly they will ignore it & use a default that is valid-- who knows?

|>| And why does the DMA
|>| checkbox remain ticked in Device Manager if the drive is in PIO
|>| mode?
|>
|>Maybe there is something non-standard about one of the PIO modes that
|>makes it look a lot like one of the DMA modes.
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net