FYI, SATA and DOS drivers
Rod Pemberton
"14. Using the Boot Manager as USB harddisk driver for DOS"
Unfortunately, it says it's read-only USB due to size constraints. Since I
don't need this for my current machine, has anyone tried this?
PLoP Bootmanager
http://www.plop.at/en/bootmanager.html
Recently, I also ran across this SATA driver for DOS:
http://marktsai0316.googlepages.com/gcdromfordos
I did try the SATA out. They work with my SATA cd-rom in DOS and under
Win98SE.
Rod Pemberton
Rugxulo
On Apr 25, 1:31 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
>
> I just ran across the PLoP Bootmanager which has an interesting feature:
>
> "14. Using the Boot Manager as USB harddisk driver for DOS"
>
> Unfortunately, it says it's read-only USB due to size constraints. Since I
> don't need this for my current machine, has anyone tried this?
>
> PLoP Bootmanagerhttp://www.plop.at/en/bootmanager.html
I've heard of PLoP, and it sounds very good (and USB booting
apparently has gotten much better since I last looked), but I've never
gotten around to trying it although my P4 could probably use it.
> Recently, I also ran across this SATA driver for DOS:http://marktsai0316.googlepages.com/gcdromfordos
>
> I did try the SATA out. They work with my SATA cd-rom in DOS and under
> Win98SE.
That was a SATA-only fork of Jack Ellis' XCDROM driver. Somebody else
also merged GCDROM with XCDROM to create XGCDROM (although "less
tested than UIDE"):
http://rugxulo.googlepages.com/xgcdrm24.zip (w/ srcs)
I don't have any SATA CD drives, so I can't test that. BTW, are SATA
CD drives that much faster than others?
Rod Pemberton
news:51fe848d-da50-40b2...@x1g2000prh.googlegroups.com...
> > I did try the SATA out. They work with my SATA cd-rom in DOS and under
> > Win98SE.
>
> That was a SATA-only fork of Jack Ellis' XCDROM driver. Somebody else
> also merged GCDROM with XCDROM to create XGCDROM (although "less
> tested than UIDE"):
>
Well, I tried GCDROM because I couldn't find any other SATA support. A
powerful advantage of GCDROM is that it is SATA only.
As for Jack Ellis, I know he went to a lot of trouble and work to create his
continously changing and adapting drivers. I kept trying them up until he
asked "Johnson" to no longer post them. But, still, they were awful as far
as I'm concerned. I'm not sure if the problem was he opened sourced them
way too early in their development or if he was just too
rushed/reckless/careless in programming them. Jack Ellis' cdrom drivers
were exceptionally horrible and problematic. IMO, *NONE* of his drivers
have ever worked _properly_ for me. Admittedly, my last PC wasn't based on
a popular chipset, but it worked with *everything* thrown at, except Jack
Ellis' cdrom drivers... AND, I already had working DOS cdrom and eide
drivers... So, I'm exceptionally leary to try anything else by him with
cdrom or ide support. Of course, about that time, he became intermittently
hostile and angry to the "problem reports" by various upset "groups", e.g.,
FreeDOS users, Linux, et. al., "attacking" his work.
Now, if I saw that an Ellis based driver had been reworked by Japheth or
Jason Hood, I'd feel much more comfortable trying them again. Or, if you
can convince me that they're "phenomenal" and I'm missing out, I'd try them.
> I don't have any SATA CD drives, so I can't test that. BTW, are SATA
> CD drives that much faster than others?
Not sure. I haven't used it much yet although I've been needing to do so.
I don't really have a need for cdrom in DOS other than to install Windows.
However, when I do use my SATA cdrom it will be in Win98SE *through* the
16-bit gcdrom driver, since I haven't found any native support for
Win98SE... Porting GCDROM from 16-bit DOS driver to a 32-bit Win32 driver
for Win98SE seems an important task to me. But, I've got no familiarity
with Win32. If I ever get a chance, I might pitch the idea to those who
created KernelEx or NUSB. One of the issues porting GCDROM is likely to be
that GCDROM is GPL'd. I'm not sure if there are actually *ANY* GPL'd Win32
drivers or driver templates. The all seem to be non-GPL'd, AFAICT. Without
one, you can't produce a SATA driver from GCDROM for Windows. I've been
searching and searching...
Rod Pemberton
Robert Riebisch
> I don't have any SATA CD drives, so I can't test that. BTW, are SATA
> CD drives that much faster than others?
No, but more and more modern mainboards don't have PATA connectors anymore.
--
Robert Riebisch
Bitte NUR in der Newsgroup antworten!
Please reply to the Newsgroup ONLY!
Robert Riebisch
> Now, if I saw that an Ellis based driver had been reworked by Japheth or
> Jason Hood, I'd feel much more comfortable trying them again. Or, if you
> can convince me that they're "phenomenal" and I'm missing out, I'd try them.
Jack's drivers are back:
http://www.bttr-software.de/forum/forum_entry.php?id=6542
Rod Pemberton
news:51fe848d-da50-40b2...@x1g2000prh.googlegroups.com...
> > http://marktsai0316.googlepages.com/gcdromfordos
> >
> > I did try the SATA out. They work with my SATA cd-rom in DOS and under
> > Win98SE.
>
> That was a SATA-only fork of Jack Ellis' XCDROM driver. Somebody else
> also merged GCDROM with XCDROM to create XGCDROM (although "less
> tested than UIDE"):
>
> http://rugxulo.googlepages.com/xgcdrm24.zip (w/ srcs)
>
> I don't have any SATA CD drives, so I can't test that. BTW
Hey, I thought you said it had SATA... Did they merge in just the IDE
support and cut out the SATA?!?! I was using GCDROM and couldn't install
some software. The software installation (in Win98SE) was wanting LFN's
(probably Joliet), but only recognizing truncated ISO9660 filenames and
directories. So, I tried XGCDROM. AFAICT, XGCDROM driver does
NOT support SATA. There doesn't seem to be anything in version 22's or 24's
documentation indicating it does either.... It recognizes my IDE
controller, then it states no CD/DVD drives are found and fails. It never
detects anything SATA related.
Rod Pemberton
Rugxulo
On May 10, 5:13 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:51fe848d-da50-40b2...@x1g2000prh.googlegroups.com...
>
> > That was a SATA-only fork of Jack Ellis' XCDROM driver. Somebody else
> > also merged GCDROM with XCDROM to create XGCDROM (although "less
> > tested than UIDE"):
>
> >http://rugxulo.googlepages.com/xgcdrm24.zip (w/ srcs)
>
> > I don't have any SATA CD drives, so I can't test that. BTW
>
> Hey, I thought you said it had SATA... Did they merge in just the IDE
> support and cut out the SATA?!?!
No. XCDROM is IDE only, and GCDROM is SATA only, so somebody merged
them together to form XGCDROM.
> I was using GCDROM and couldn't install some software. The software installation (in Win98SE) was
> wanting LFN's (probably Joliet), but only recognizing truncated ISO9660 filenames and
> directories. So, I tried XGCDROM. AFAICT, XGCDROM driver does
> NOT support SATA. There doesn't seem to be anything in version 22's or 24's
> documentation indicating it does either....
(from XGCDROM2.ASM):
; V2.4 08-Jun-07 Rebuilt pci scan. Now SATA and PATA works
together.
> It recognizes my IDE
> controller, then it states no CD/DVD drives are found and fails. It never
> detects anything SATA related.
It wasn't tested much, so who knows, I guess it doesn't work for you.
Try Jack's latest drivers if you really want to try something that
should hopefully work (since the others are older). Otherwise, I
dunno. :-/
Rod Pemberton
> On May 10, 5:13 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> > "Rugxulo" <rugx...@gmail.com> wrote in message
> > news:51fe848d-da50-40b2...@x1g2000prh.googlegroups.com...
> > >
> > > That was a SATA-only fork of Jack Ellis' XCDROM driver. Somebody else
> > > also merged GCDROM with XCDROM to create XGCDROM (although "less
> > > tested than UIDE"):
> > >
> >
> > Hey, I thought you said it had SATA... Did they merge in just the IDE
> > support and cut out the SATA?!?!
>
> No.
Um... How can XGCDROM *not* have SATA if they merged a working SATA driver,
GCDROM, with a working IDE driver, XCDROM? Honestly, I'm not trying to be
pedantic here.
> XCDROM is IDE only, and GCDROM is SATA only, so somebody merged
> them together to form XGCDROM.
So, you said it, XGCDROM, has SATA, yet again... Yes? If you take two
things and mix them together, you should have a mix of two things... not one
of the two, I think.
Well, they didn't enable the SATA part of the driver. If one wants XGCDROM
to scan for SATA drives, one must uncomment a few lines of code and rebuild
with NASM. After which, the SATA part of the driver is identical GCDROM,
i.e., not improved in any useful way AFAICT.
> > I tried XGCDROM. AFAICT, XGCDROM driver does
> > NOT support SATA. There doesn't seem to be anything in version 22's or
24's
> > documentation indicating it does either....
>
> (from XGCDROM2.ASM):
>
> ; V2.4 08-Jun-07 Rebuilt pci scan. Now SATA and PATA works
> together.
Which is false... They don't work together, because only the PATA part of
the driver is enabled. PATA works alone. These commented out lines are
what allow SATA to be detected:
cmp cl,80h ;Other?
; je found
; and cl,4
; cmp cl,4 ;Not tested yet, SATA AHCI, RAID, and smth else
jne nextfunc
In other words, XGCDROM.sys, as distributed in binary, is *not* a SATA
driver because SATA is disabled in XGCDROM2.asm.
Rod Pemberton
Rod Pemberton
> Try Jack's latest drivers if you really want to try something that
> should hopefully work (since the others are older). Otherwise, I
> dunno. :-/
>
> http://johnson.tmfc.net/dos/file/drivers.zip
The first use hung for DOS. After that, the two seconds I used it with DOS,
it seemed to not present any immediate blatant errors for DOS.
However, I've never seen a DOS device driver *not* work with Win98SE...
until now:
"Write fault error writing device PRN. Abort, Retry, Ignore, Fail?"
And, it corrupts something in the Windows registry files... I hope whoever
tries this with driver with Windows has backups. GCDROM and XGCDROM with
SATA code enabled both work with Windows without any issues. I think you
should take head of my harsh earlier words about his programming...
Rod Pemberton
Rugxulo
On May 11, 2:29 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:bc98ad15-1b37-45dd...@b1g2000vbc.googlegroups.com...
>
> > On May 10, 5:13 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> > > "Rugxulo" <rugx...@gmail.com> wrote in message
> > >news:51fe848d-da50-40b2...@x1g2000prh.googlegroups.com...
>
> > > > That was a SATA-only fork of Jack Ellis' XCDROM driver. Somebody else
> > > > also merged GCDROM with XCDROM to create XGCDROM (although "less
> > > > tested than UIDE"):
>
> > > > I don't have any SATA CD drives, so I can't test that. BTW
>
> > > Hey, I thought you said it had SATA... Did they merge in just the IDE
> > > support and cut out the SATA?!?!
>
> > No.
>
> Um... How can XGCDROM *not* have SATA if they merged a working SATA driver,
> GCDROM, with a working IDE driver, XCDROM? Honestly, I'm not trying to be
> pedantic here.
I meant "no", they didn't cut out the SATA.
> > XCDROM is IDE only, and GCDROM is SATA only, so somebody merged
> > them together to form XGCDROM.
>
> So, you said it, XGCDROM, has SATA, yet again... Yes? If you take two
> things and mix them together, you should have a mix of two things... not one
> of the two, I think.
Right, obviously. ;-)
> Well, they didn't enable the SATA part of the driver. If one wants XGCDROM
> to scan for SATA drives, one must uncomment a few lines of code and rebuild
> with NASM. After which, the SATA part of the driver is identical GCDROM,
> i.e., not improved in any useful way AFAICT.
I don't think it was meant as an improvement, just a more universally
useful driver (IDE + SATA) instead of relying on separate ones for
different devices.
> > > I tried XGCDROM. AFAICT, XGCDROM driver does
> > > NOT support SATA. There doesn't seem to be anything in version 22's or
> 24's
> > > documentation indicating it does either....
>
> > (from XGCDROM2.ASM):
>
> > ; V2.4 08-Jun-07 Rebuilt pci scan. Now SATA and PATA works
> > together.
>
> Which is false... They don't work together, because only the PATA part of
> the driver is enabled. PATA works alone. These commented out lines are
> what allow SATA to be detected:
>
> cmp cl,80h ;Other?
> ; je found
> ; and cl,4
> ; cmp cl,4 ;Not tested yet, SATA AHCI, RAID, and smth else
> jne nextfunc
>
> In other words, XGCDROM.sys, as distributed in binary, is *not* a SATA
> driver because SATA is disabled in XGCDROM2.asm.
I e-mailed the guy who patched together the 2.4 release, and here's
what he says:
-----------------
(lexapass):
Hello, Rugxulo.
I think this is misunderstanding of SATA modes and my code. Let I
explain.
In my code I scan PCI bus for class code 01h (Mass storage
controllers)
and then in this fragment I check subclass codes. From Intel specs I
found that 01h related to IDE (and only this code used in
XCDROM/GCDROM/UDVD/UIDE), 04h - for RAID, 06h - for SATA AHCI and 80h
-
"Other" types. I don't describe other codes which are not
interesting.
SATA controllers can work in "IDE emulation", "enhanced" and AHCI
modes.
For us "IDE emulation" and "enhanced" modes are identical to normal
IDE.
AHCI uses different programming protocol. All this is known from Intel
specs.
When I wrote my driver I test it on normal IDE (my own i815 MB),
enhanced SATA (Dell Optiplex 745 at work), both are with 01h subclass
code, IDE Promise Ultra66/100 (=80h), IDE Promise FastTrak66/100
(=04h)
and some AHCI enabled notebooks (=06h).
The results are:
01h - working in UDMA and PIO modes;
80h - only PIO;
04h - CD-ROM not detected by controller BIOS, system hangs;
06h - only controller detected.
So my driver works only with normal IDE, Non-AHCI SATA and partially
with other IDE controllers.
In lines
----
> ; and cl,4
> ; cmp cl,4 ;Not tested yet, SATA AHCI, RAID, and smth else
----
I just masked all subclass codes equal or higher than 04h when I
thought
that I can work with them. Later I just disable this part when I've
got
more info about them.
As result it is not correct to say that my "driver is *not* a SATA.
The
correct variant will be that my driver is *not* a SATA AHCI (like any
other, even UIDE still doesn't support this mode) and this is a big
difference.
-----------------
Hope this clarifies things since it's way out of my league!! :-P
Rod Pemberton
>
> I e-mailed the guy who patched together the 2.4 release, and here's
> what he says:
Thank you.
> From Intel specs I
> found that 01h related to IDE (and only this code used in
> XCDROM/GCDROM/UDVD/UIDE), 04h - for RAID, 06h - for SATA AHCI and 80h
Since my SATA _works_ with XCDROM, according to him it must be class code
01h... Right?
> In lines
> ----
> > ; je found
> > ; and cl,4
> > ; cmp cl,4 ;Not tested yet, SATA AHCI, RAID, and smth else
>
> ----
> I just masked all subclass codes equal or higher than 04h when I
> thought that I can work with them. Later I just disable this part when
> I've got more info about them.
Since my SATA only works with XGCDROM with those lines enabled, according to
him it must be subclass code 06h or 80h, or at least greater than subclass
code 04h... Right?
Tragically, I do not understand how my SATA could be subclass code 01h for
XCDROM which supports nothing else _and_ at the same time be some other
subclass code for XGCDROM... Do you?
> So my driver works only with normal IDE, Non-AHCI SATA and partially
> with other IDE controllers.
He's confused, clearly... since XGCDROM doesn't work with what must
obviously be a non-AHCI SATA, unless those three lines are enabled.
> Hope this clarifies things since it's way out of my league!! :-P
Unfortunately, no it doesn't. A non-indepth logic review dictates something
is wrong with his statements or his code. I think the later.
Rod Pemberton
Hendrik Schmieder
I think there are dos programs which scan the pci bus.
What do this programs tell ?
Hendrik
Rod Pemberton
news:4A0E6EDA...@t-online.de...
> Rod Pemberton schrieb:
> > "Rugxulo" <rug...@gmail.com> wrote in message
> > news:4528b447-7336-4367...@x6g2000vbg.googlegroups.com...
> > >
> > > I e-mailed the guy who patched together the 2.4 release, and here's
> > > what he says:
> >
> > Thank you.
> >
> > > From Intel specs I
> > > found that 01h related to IDE (and only this code used in
> > > XCDROM/GCDROM/UDVD/UIDE), 04h - for RAID, 06h - for SATA AHCI and 80h
> >
> > Since my SATA _works_ with XCDROM, according to him it must be class
> > code 01h... Right?
Sorry, correction: that was GCDROM, but that makes no difference in his
statements, or subclass code...
> >
> > > In lines
> > > ----
> > > > ; je found
> > > > ; and cl,4
> > > > ; cmp cl,4 ;Not tested yet, SATA AHCI, RAID, and smth else
> > >
> > > ----
> > > I just masked all subclass codes equal or higher than 04h when I
> > > thought that I can work with them. Later I just disable this part
> > > when I've got more info about them.
> >
> > Since my SATA only works with XGCDROM with those lines enabled,
> > according to him it must be subclass code 06h or 80h, or at least
greater
> > than subclass code 04h... Right?
> >
> > Tragically, I do not understand how my SATA could be subclass code 01h
> > for XCDROM which supports nothing else _and_ at the same time be some
Sorry, again correction: that was GCDROM...
> > other subclass code for XGCDROM... Do you?
> >
> > > So my driver works only with normal IDE, Non-AHCI SATA and partially
> > > with other IDE controllers.
> >
> > He's confused, clearly... since XGCDROM doesn't work with what must
> > obviously be a non-AHCI SATA, unless those three lines are enabled.
> >
> > > Hope this clarifies things since it's way out of my league!! :-P
> >
> > Unfortunately, no it doesn't. A non-indepth logic review dictates
> > something is wrong with his statements or his code. I think the later.
> >
>
> I think there are dos programs which scan the pci bus.
> What do this programs tell ?
>
AFAICT, they tell me exactly what I deduced to be the truth. Both of my
PC's SATA interfaces are Class 01, Subclass 01. I.e., my deduction that
something is wrong with his code should be true.
I located two DOS programs that emit PCI bus-scan info. I found MHDD 4.6
which has a PCISCAN command, and Craig Hart's PCI Diagnostic program. Craig
Hart's program seemed far more useful.
MHDD 4.6
http://hddguru.com/content/en/software/2005.10.02-MHDD/
Craig Hart PCI Diagnostic
http://members.datafast.net.au/dft0802/downloads.htm
The GCDROM SATA driver works with the SATA in my PC. GCDROM says it found a
"SATA Native IDE controller" at ports C480/C080 with ID: 10DE037F. PCI.exe
with /I option emits 22 PCI device lines. The two lines with a matching
Vendor and Device ID's are (i.e., the SATA controllers):
V:10DE D:037F S:72601462 B:0 E:05 F:0 I:05 N:A C:01 U:01 P:85 R:A2
V:10DE D:037F S:72601462 B:0 E:05 F:1 I:10 N:B C:01 U:01 P:85 R:A2
The C:01 is Class 01 and U:01 is Subclass 01. PCI.exe with other options
shows ports C480/C080 are for the first line above.
He's got a bug somewhere...
Rod Pemberton
Rod Pemberton
news:gunhl1$tgu$1...@aioe.org...
> He's got a bug somewhere...
>
I had a copy I downloaded some time ago from another source that I hadn't
deleted. I was looking over the code trying to find a bug and wasn't seeing
a bug. I worked through it a couple of times with the class and subclass
info from PCI.exe thinking maybe another device was causing the driver to
fail to locate the SATA devices. So, I tried the driver from that download.
It worked... Then, I pulled the Rugxulo version again and it worked too.
Strangeness... So, I'm not sure what was going on since both the driver
binary and NASM rebuild failed for me at first, _until_ I enabled those
lines. I don't think I changed anything in my BIOS, although I do have some
autodetected USB devices that aren't always installed. Something was
definately wrong or has been changed. Anyway, since things are working
_today_..., tell "lexapass" I'm sorry for any trouble. However, I might be
complaining again _tomorrow_... if I'm experiencing Deju Vu again. ;-)
Rod Pemberton
Rugxulo
below:
On May 16, 10:02 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm>
wrote:
> "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote in message
Here's what lexapass says (from e-mail):
---------------------------------------------------
I'm interesting if he reads about PCI if he asks such questions? If he
doesn't have any basic knowledge about PCI devices and programming all
discussions are meanless.
At first he should read Ralph Brown's Interrupt list for INT 1AH,
functions 03h and 0bh and other PCI programming related documents.
If he takes a look to XCDROM code he should find that it scans for
class 01h, subclass 01h
---
I_FindC cmp si,ClCEnd ;More interface bytes to check?
jae I_ChkNm ;No, check for valid driver name.
mov ecx,000010100h ;Find class 1 storage, subclass 1 IDE.
<==HERE
lodsb ;Use next class-code "interface" byte.
mov cl,al
push si ;Save class-code table pointer.
mov al,003h ;Inquire about an UltraDMA controller.
xor si,si ;(Returns bus/device/function in BX).
call I_In1A
---
and specific programming interface codes (which are refer to specific
controllers)
---
ClCodes db 0FAh,0F0h,08Ah,080h,0BAh,0B0h
ClCEnd equ $
---
The difference with GCDROM is that GCDROM scans for DIFFERENT ClCodes
and in addition it determines correct port adresses (not 1f0h/170h
like for standard IDE in XCDROM) to work with founded controllers thru
PCI programming access (in parts after %if 1).
---
%if 0
ClCodes db 0FAh,0F0h,08Ah,080h,0BAh,0B0h
%else
ClCodes db 08fh,085h <== HERE
%endif
ClCEnd equ $
---
It's wellknown that GCDROM can works with certain SATA controllers
while XCDROM not, so here is the prove.
In my code I use different algorithm for finding supported controllers
without link to specific "programming interface" codes. Details were
in my previous letter. Other information can be found in Intel ICH
datasheets.
> Since my SATA _works_ with XCDROM, according to him it must be class code
> 01h... Right?
Right if subclass code equal to 01h (see above). There is a big
difference between class and subclass in PCI. And according to
hardware specs, not me.
README.TXT from xcdrom22.zip makes me sure that SATA controller works
in Legacy IDE mode (IDE compatible by other words).
> Since my SATA only works with XGCDROM with those lines enabled, according to
> him it must be subclass code 06h or 80h, or at least greater than subclass
> code 04h... Right?
Without details from him I can say nothing. Again see above and my
previous letter.
And I don't see any info about important in this situation "/Cn"
parameter for my driver, because if he enables additional subclass
codes the numeric order of founded controllers may be changed. See
README.TXT for my dirver.
---------------------------------------------------
Hope this helps, but it is strange that it now works for you.
(Hardware is confusing!) I await your (potential) further
comments. ;-)
Rod Pemberton
> Hi, I guess you don't use e-mail (?),
Not anymore...
> Hope this helps, but it is strange that it now works for you.
> (Hardware is confusing!) I await your (potential) further
> comments. ;-)
Well, at least I confirmed my SATA II are normal class and subclass values.
But, yeah... that's the wierdest thing I've had happen in a while. The
last one I did track to a bug in CWSDPMI. A few years ago, I had a hard to
locate a problem with OpenWatcom's argv,argc. I let it sit for a while and
unfortunately it disappeared and never came back... IMO, it's probably
still there but just not being triggered. The one before that I tracked to
a bug in OW's library. But as for this problem, it seems to be working
properly, for now. I recall quite well what I tested. I was thorough. So,
I'm not sure what was wrong or what I may have done wrong. Although it
works now, I do know it has hung twice. I'll keep retrying it.
Things I've considered:
1) /Cn wrong. The config lines were cut-n-paste. There shouldn't have
been an error with these. But, that could explain it.
2) Corrupted download. If so, it should've worked with first rebuilt
version of the driver.
3) Copied wrong driver. (How?) If so, it too should've worked with first
rebuilt version.
4) legacy USB BIOS SMM code or BIOS setup issue. I did make some changes I
forgot about. If so, error should've retriggered when changed back.
5) intermittent PCI timing issue or system cpu/memory startup/warmup
issue...
6) possible conflict with some other DOS utils I use...
At this point, I just don't know... Anyway, it's a fast machine with the
2nd cpu core not in use. Of one the SATA devices exceeds SATA I throughput,
so it's unlikely but possible there could be some timing issue during the
PCI scan, although it should be OK since the board supports SATA II speeds,
uses proper SATA II cables, and should just be scanning the controller
logic, not accessing the actual device.
However, I've also been noticing other intermittent "ghost-in-the-machine"
effects with this new PC. For example, after rebooting, Windows
applications, or interrupted DOS commands, specifically DIR/S, will still be
running. Yes, that is not normal. But, hopefully, it's not just some hacks
using my 2nd core, or future "time bandits" having fun with me... ;-)
Actually, my current completely unprovable suspicion is that a reboot is
switching cpu cores, and for some reason, the "2nd" core was "mirroring"
execution on the "1st" core and the "2nd" core didn't reboot. Otherwise, I
can't see how I could make it through a reboot and see rebooted applications
still running as if a reboot never occured. This only happens once in a
while, but it happens. This OS (Win98SE and MS-DOS) doesn't support
multi-threading, AFAIK. Perhaps something is wrong with the BIOS
power-management power down, or power idle states...
Rod Pemberton
Martin Str|mberg
> Well, at least I confirmed my SATA II are normal class and subclass values.
> But, yeah... that's the wierdest thing I've had happen in a while. The
> last one I did track to a bug in CWSDPMI. A few years ago, I had a hard to
> locate a problem with OpenWatcom's argv,argc. I let it sit for a while and
> unfortunately it disappeared and never came back... IMO, it's probably
> still there but just not being triggered. The one before that I tracked to
> a bug in OW's library. But as for this problem, it seems to be working
> properly, for now. I recall quite well what I tested. I was thorough. So,
> I'm not sure what was wrong or what I may have done wrong. Although it
> works now, I do know it has hung twice. I'll keep retrying it.
One thing that can make a big difference is cold boot vs warm
boot. Especially if you're runnning WINDOZE.
I've not seen your problems, but I have seen Linux seeing different
things after a reboot from cold boot vs reboot from WINDOZE. In my
case I think old ISA 3COM NIC jumped around/was not detected etc.,
although I had disabled PNP on them. Also some integrated sound card
works (a different computer) or doesn't, depending on the pre-reboot
state.
My conclusion is that WINDOZE tickles hardware in some ways that makes
it behave differently.
--
MartinS
mezuk...@sprynet.com
shall post my
comments here.
I have always written DOS drivers, and ONLY DOS drivers. I have never
tested my drivers
on any of the [very] "junior" Windows systems (95/98/SE/ME/etc.) that
"load on top of"
MS-DOS, because (A) I do not have any of those systems and (B) I
detest them! Far
too many comments like "They all SUCK!" from others, for far too many
years!
The documentation for my drivers says they are DOS drivers, with
absolutely NO mention
of their being used with any Windows system. Anyone who tries it does
so "at your own
risk", which is ALSO in the documentation. It was never my intent,
and it never WILL be,
for my DOS drivers to support Windows.
One might also note that, along with 16-bit DOS drivers, the [very]
"junior" Windows
systems provide for 32-bit "VxD" drivers as well. There are REASONS
for "VxD"
drivers -- they offer more capabilities AND they solve many 16-bit
driver problems,
as others more-familiar with Windows than me HAVE noted!
Pemberton, get yourself a better mainboard, NOT another "off brand" or
"El Cheapo".
Or get yourself a "VxD" driver, and run your [very] "junior" Windows
the way Gates &
Co. INTENDED that you should! Sorry your system has problems, but
THEY ARE
your problems, and you need to FIX your "Ghost in the Machine"
troubles, before you
fault either me or UIDE! UIDE really DOES work quite well for me and
for many others,
in case you haven't NOTICED!!!!
Jack R. Ellis
Rod Pemberton
news:557f3a76-d920-4926...@d25g2000prn.googlegroups.com...
>
> Given no-reply from Pemberton to the E-Mail I sent him 2 days ago,
Don't lie. That's _NOT_ possible. Did you read my email address? Did you
look at the name or domain? If you had, you wouldn't have even tried to
send an email to me... If you did, it should've rejected immediately.
> I
> shall post my
> comments here.
But, let's say I am using email and am assuming this is actually from Jack
Ellis... I'm not sure how a reply from me would've gotten TO you. Although
_some_ DNS lookups indicate that "sprynet.com" has MX records to
mindspring.com servers. _All_ indicate it's missing the _required_ A record
needed for routing the email reply. Are you sure you still receive incoming
email?...
> I have always written DOS drivers, and ONLY DOS drivers. I have never
> tested my drivers
> on any of the [very] "junior" Windows systems (95/98/SE/ME/etc.) that
> "load on top of"
> MS-DOS, because (A) I do not have any of those systems and (B) I
> detest them!
Fair enough. I assumed as much.
> Far
> too many comments like "They all SUCK!" from others, for far too many
> years!
Maybe you need to get a clue? Maybe you need to take my statements about
reckless coding to heart? Why would so many people complain so vehemently
and continously about _your_ drivers? Do you realize that *every one* of
these people have a vested interest in finding and using a working driver?
Do you realize that *not one* of these people has any interest in
disparaging your drivers? They just reported the problems they
experienced... As stated in the other parts of this thread, I know you've
worked very hard. But, your drivers have had a long history of problems for
me. This is confirmed for me as a valid and shared experience by the
numerous posts of others stating the same. How you fail to recognize this
as the actual state of affairs is beyond me...
> The documentation for my drivers says they are DOS drivers, with
> absolutely NO mention
> of their being used with any Windows system.
The documentation _also_ makes absolutely NO mention of the drivers possibly
not working with other OSes that are MS-DOS .sys driver compatible, such as
the near 100% compatibility provided by Windows 98 etc. So, one would and
should expect them to work with Windows 98, if they also work with FreeDOS
and OpenDOS, etc.
> Anyone who tries it does
> so "at your own
> risk", which is ALSO in the documentation.
What? There is no mention that these will likely fail with non-DOS OSes
that _use_ DOS device drivers.
> It was never my intent,
> and it never WILL be,
> for my DOS drivers to support Windows.
Sigh... Perhaps true, but like I said, I've _NEVER_ seen a functioning DOS
device driver that _DOESN'T_ work with Windows 98. Congrats! I.e., you
likely broke something with the DOS driver model, but haven't noticed yet...
> Pemberton, get yourself a better mainboard, NOT another "off brand" or
> "El Cheapo".
I *am* using a high-end motherboard. It's listed in posts above... But, I
experienced problems with my prior systems also. By "better mainboard", do
you mean Intel only? Yup, I have three of them around here too... So, what
system must I buy to get your drivers to work right?
> Or get yourself a "VxD" driver, and run your [very] "junior" Windows
> the way Gates &
> Co. INTENDED that you should!
AFAICT, Win98 native drivers for SATA devices don't exist, yet...
> you need to FIX your "Ghost in the Machine"
> troubles, before you
> fault either me or UIDE!
Sorry, this has *nothing* to do with UIDE working. If you'd read the
thread, you'd have known that GCDROM works with Windows 98 even with a
"Ghost in the Machine." If you'd read the thread, you'd have known that
XGCDROM - after a few serious fits with DOS - works with Windows 98 even
with a "Ghost in the Machine." If you'd read the thread, you'd have known
the problems with your drivers existed long before this machine. And, I
think the "Ghost in the Machine" is gone being something related to ACPI
power management (and/or APIC), but it's only been disable for a day...
Rod Pemberton
mezuk...@sprynet.com
<http://support.microsoft.com/kb/139052>
It gives a LONG list of "dirty and deadly" TSRs known to upset Win/95
and its installation
procedures. Note how many of the listed items were written by
MICROSOFT themselves!
I used "CED" for over 10 years, and now Gates & Co. says it is NOT for
use with Win/95,
which is far-worse TRASH than "CED" ever was.
And if you really believe that all such trouble was fixed by Gates &
Co. in Win/98 or later
issues of their [very] "junior" Windows systems, then you have my
deepest sympathies.
I could tell you what the "common thread" shared by CED, UIDE, and
likely others on that
list is. But, given your "harsh words" about me and my programming,
I will not waste my
time with you any further, except to say-again that you should get
yourself drivers written
to run disk/CD/DVD devices ON WINDOWS! If, as you admit, you can
FIND any!
Jack R. Ellis
johnsonlam
but PLEASE ... at least, send an email to me and provide some
information so I can forward the problem to Jack.
Recently, for the few release of UIDE, I got no complain from DOS
users in China, and UIDE run smoothly under my previous PC (Athlon64
3200+, dual core, Nvidia chipset). I've not setup the DOS environment
on my new Phenom X4 9550 yet, but since I use Jack driver, I've
changed more than 3 mainboard, I don't even have to change the
CONFIG.SYS, compatibility is excellent.