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