#Mitsumi & Windows Enh.
9 messages in this thread
I'm finding that in Windows enhanced mode an operation from a DOS session such
as TREE I:\ or SEARCH FOO I:\*.* for instance will start and then after a few
seconds the system will seem to go into hibernation. This lasts for around 10
seconds, after which the CD springs back into life for a bit more before it's
back to sleep!
Changing /M on MTMCDE.SYS and MSCDEX.EXE from 10 to 64 in various combinations
doesn't alter things.
It only seems to happen in enhanced mode, in standard mode and straight DOS
there's no such problem. I haven't got a Windows app. which uses the CD yet so
don't know if this is a DOS app. problem or system wide.
Has anyone seen this situation? If so is there a resolution to it?
Thanks,
Robin
I have this EXACT problem with a Mitsumi CD — under Windows enhanced mode DOS
box
(or sharing across a Workgroups LAN) the drive hibernates for 10 second
intervals but EVENTUALLY does complete the operation. If/when you resolve this,
please pass on the fix (via Email if you don't see me here). This is VERY
annoying.
Lee, try changing your windows setting for the application to exclusive and see
if that doesn't eliminate the 10 second "sleep". You can do this on the fly so
you can try it both ways.
Lee,
Here's a copy of my reply to Robin – just so you don't miss it.
Robin,
I've been working on this problem since my last message reply to you
(#46393). I've been to every forum on CI$ that seems appropriate – no luck.
But after much ditzing around I have come up with two patches for the
"Mitsumi stalls in Enhanced Mode DOS window" problem. I'm not happy with
either as a permanent fix, but I wanted to post this so you and others may
be able to shed some light on what's going on.
I've ruled out all of my software except Stacker. It's the only thing I
can't take out of my system. I don't think it's a problem but… Is anyone
experiencing this problem who is _not_ running Stacker?
"DOES ANYONE HAVE A SUPPORT NUMBER FOR MITSUMI?" he said in a loud voice.
The "Manual" that came with my drive has no phone numbers at all – no
address either.
Either ONE of the following will fix the problem:
1. Change the /T: switch on the device driver line for MTMCDE.SYS in
CONFIG.SYS to /T:S. Mine looks like this:
DEVICE=C:\DEV\MTMCDE.SYS /D:MSCD001 /P:300 /A:0 /M:40 /T:6 /I:11 /X
This changes the mode from DMA Transfer to Software Interrupt Transfer.
For stuff in DOS windows this shouldn't make much difference. But it
should slow the system a little when running multimedia apps.
—- OR —-
2. Add this line to the [386enh] section of your SYSTEM.INI file:
DMABufferIn1MB=true
As the name implies, this keeps the DMA buffer in the first 1MB of
memory. Windows Resource Kit says "…to be compatible with 8-bit bus
master cards." I have the 350ms Mitsumi drive with the 16 bit card. And
as far as I know it isn't a bus master.
This "fix" has the side affect of locking out my Sound Blaster Pro 2
card. So it won't work for me.
Does anyone know why this setting is messing up SBP?
Ken
Robin,
I'm trying to track down a similar problem. When running Visual C++ to build a
program, if Visual C++ has to go to the CD for anything (compiler, libraries,
etc.), the system seems to lock up for 10 second periods, followed by a
fraction of a second of CD-ROM activity – then back to sleep. The build
eventualy does complete – but it takes forever.
Visual C++ does the build with a DOS program in the background – so Windows is
supposedly able to keep running in the forground. The fact that it is a DOS
program running makes me think we're seeing the same problem. I have other
Windows specific CD software (Corel Draw, Street Atlas, etc) and it all works
fine – but it is Windows specific. I have also run CD based games and
Encyclopedia from Windows, but these have always been full screen.
After reading your message I just did a little test. If I run DOS Shell in a
window and type a long file from the CD-ROM (Over 64k), the system hangs after
most of the file has been listed. My guess is this happens at the 64k boundary.
After 10 seconds the ROM access light flashes and the rest of the file is
listed. If I try the same test running DOS Shell full screen, the full file
lists with no problem.
I've been trying to track down this problem with the help of some people on the
Microsoft Languages Forum. If I get it resolved I'll let you know – If you
figure it out I sure would appreciate a note.
Ken
Ken,
Interesting, we must be seeing the same thing.
Taking John Coan's suggestion I set exclusive and found something which may be
significant. After setting 'exclusive' and when running full-screen the problem
disappeared. I was also to start a SEARCH FOO *.* in a directory containing
350Mb of image files (ie. the search would never match) and the drive light
never went out …
.. _BUT_ as soon as I hit ALT-ENTER to make the session windowed the sleep-
wake-sleep cycle started immediately! It took a long time clicking and holding
on the control icon of the window to be able to get to the Settings… to
switch back to full screen.
So, while setting 'exclusive' has an effect it's not total. Given that windowed
exclusive sessions are still hit by the problem part of it at least must be
related to the differences between a DOS session running full-screen and one in
a window.
At this point my knowledge of the internals of Windows gives out. Obviously the
Windows desktop is being displayed, the graphics adaptor is in graphics rather
than text mode, but I have no idea what impact this would have on the CD driver
etc.
I'll see what I can find out and get back if something comes up, appreciate the
offer of the same!
Robin
Hello Ken
I also own a Mitsumi LU-005S-Drive and I tried to duplicate your problem under
win-386Enha (486-33EISA, 8MB, Mitsumi-controller, DRDos 6). I tried to type a
file>64kB from the corel-cdrom in a dos-window (=not exclusive) and everything
worked fine, no stop-and-go or anything like that.
What driver-versions do you use? The dates of the ones I use are:
MTMCDE.SYS 3/5/93 19232 Bytes
MSCDEX.EXE 4/18/93 25377 Bytes V2.22
Autoexec.bat:
PATH C:\DRDOS …
KEYB SG+
SHARE
DISKMAP C: D: E:
VERIFY OFF
PROMPT $P$G
c:\qemm\loadhi c:\cdrom\MSCDEX.EXE /D:MSCD001 /M:30 /E
Config.sys:
SHELL=C:\COMMAND.COM C:\ /P /E:256
BREAK=ON
HIBUFFERS=20
FILES=60
HISTORY=ON, 256, ON , OFF, OFF
COUNTRY=041,,C:\DRDOS\COUNTRY.SYS
DEVICE=C:\QEMM\QEMM386.SYS FRAME=E000 X=B000-B7FF X=C000-C7FF ROM RAM ST:M
DEVICE=c:\drdos\hidos.sys /B=FFFF
HIDOS=ON
DEVICE=c:\qemm\loadhi.sys c:\mouse.sys NOVCI
DEVICE=c:\qemm\loadhi.sys c:\cdrom\MTMCDE.SYS /D:MSCD001 /P:300 /A:0 /M:30 /X
DEVICE=c:\qemm\loadhi.sys c:\MTWAIN\MSCAN.SYS D3 I5 S4 A3EB
DEVICE=c:\qemm\loadhi.sys c:\drdos\vdisk.sys 900 128 64 /E
DEVICE=c:\qemm\loadhi.sys c:\drdos\ansi.sys
As everything is loaded high, I get about 627000 free bytes, but I have not
tried real windows-multimedia-applications.
Hope this may be of any help
Fridli
Fridli,
Thanks for your attempt to duplicate my observations. I am using the same
versions of MTMCDE.SYS and MSCDEX.EXE.
When looking at your CONFIG.SYS entries, I noticed you have the line:
DEVICE=c:\qemm\loadhi.sys c:\cdrom\MTMCDE.SYS /D:MSCD001 /P:300 /A:0 /M:30 /X
You don't set the /T parameter which is used to select the DMA channel. I
tried this setting and the result is DMA is not used and it defaults to
Software Interrupt Transfer (the same as setting the /T option to /T:S).
The corresponding line in my CONFIG.SYS file is:
DEVICE=C:\QEMM\LOADHI.SYS /R:1 C:\DEV\MTMCDE.SYS /D:MSCD001 /P:300 /A:0
/M:40 /T:6 /I:10 /X
I agree that without using the DMA channel, windowed DOS applications seem
to work fine. I would like to get DMA transfer working because things
should run faster and smoother in multimedia applications.
Thanks again for your help.
Ken
Robin,
I've been working on this problem since my last message reply to you
(#46393). I've been to every forum on CI$ that seems appropriate – no luck.
But after much ditzing around I have come up with two patches for the
"Mitsumi stalls in Enhanced Mode DOS window" problem. I'm not happy with
either as a permanent fix, but I wanted to post this so you and others may
be able to shed some light on what's going on.
I've ruled out all of my software except Stacker. It's the only thing I
can't take out of my system. I don't think it's a problem but… Is anyone
experiencing this problem who is _not_ running Stacker?
"DOES ANYONE HAVE A SUPPORT NUMBER FOR MITSUMI?" he said in a loud voice.
The "Manual" that came with my drive has no phone numbers at all – no
address either.
Either ONE of the following will fix the problem:
1. Change the /T: switch on the device driver line for MTMCDE.SYS in
CONFIG.SYS to /T:S. Mine looks like this:
DEVICE=C:\DEV\MTMCDE.SYS /D:MSCD001 /P:300 /A:0 /M:40 /T:6 /I:11 /X
This changes the mode from DMA Transfer to Software Interrupt Transfer.
For stuff in DOS windows this shouldn't make much difference. But it
should slow the system a little when running multimedia apps.
—- OR —-
2. Add this line to the [386enh] section of your SYSTEM.INI file:
DMABufferIn1MB=true
As the name implies, this keeps the DMA buffer in the first 1MB of
memory. Windows Resource Kit says "…to be compatible with 8-bit bus
master cards." I have the 350ms Mitsumi drive with the 16 bit card. And
as far as I know it isn't a bus master.
This "fix" has the side affect of locking out my Sound Blaster Pro 2
card. So it won't work for me.
Does anyone know why this setting is messing up SBP?
Ken