A hack, anyone, to turn on dma ?

July 5, 2008

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

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 :P

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.

July 5, 2008

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

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

>© 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.

July 6, 2008

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

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.

July 6, 2008

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

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.

July 6, 2008

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

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 :D

|>| []'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

July 6, 2008

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

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

July 7, 2008

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

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

|>© 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

July 7, 2008

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

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.

July 7, 2008

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

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/Firmware/FWDownload/FWDownload.asp?product_code=SDR&language_code=&SearchMode=TOTALSEARCH&SearchWord=182f

I am a compulsive flasher :P

Above link probably wraps.

[]'s

July 8, 2008

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

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

July 8, 2008