rishooty wrote:

That's because /B is meant for use with UMBPCI. Good to know XDVD seems to be ok now, but try it with some disc based games. That's also where shsucdx seems to have issues.

I'm Johnson Lam post the following for Jack R. Ellis, since he can't access the Vogons forum:

I am the author of the XMGR/XHDD/XDV2 drivers. I am totally dismayed and upset
by the IGNORANT posts of 17-Sep-2019 on VOGONS about XMGR and XHDD.

First, if you had read the drivers' README file, you would know that the XMGR /B
switch is not for UMBPCI usage. It applies to "booting" XMGR into upper memory
when used with an "EMM" driver like JEMM386 or Microsoft EMM386. Using /B also
requires loading XMGR a second time after the "EMM" driver enables upper-memory,
like I show in CONFIG.SYS example C (Section 5 of the drivers' README). If you
do not load XMGR again, which deactivates its "boot" code in "temporary" memory,
the still-active "boot" is overrun by other programs. THAT is why you CRASHED!

Second, XHDD does not work the same as wretched SMARTDRV. SMARTDRV "eats" many
times more memory for a maximum 20-MB cache, too small to be of any value with a
Terabyte disk of today. XHDD uses a maximum 2848 bytes of upper/DOS memory (or
720 if most of it loads in the HMA via its /H switch), offers XMS caches up to 4
GIGABYTES, and is far faster than SMARTDRV, given XHDD's Read-Ahead, DMA/caching
overlap, and other improved logic. Also, XHDD uses no C+ /N /U or /? switches!

Finally, I spend hours writing clear and concise README files, as a lot of XMGR/
XHDD/XDVD2 users reside in countries other than the U.S.A. You should actually
READ the drivers' README file before saying I'm "not the best at documentation".
Might also help you avoid making IDIOTIC posts which prove you paid NO attention
to information you MUST know, before using XMGR/XHDD/XDVD2!

If you cannot (or will not) read their README file, FIND YOURSELF OTHER DRIVERS,
and do not try to fault ME over your own miserable IGNORANCE!!

Jack R. Ellis

He seems mad

Depends on how to define "MAD", he's furious since nobody read the manual and claim his drivers (XHDD, XDVD2) not working.

Please stand in his position and think if someone talk boldly about your program didn't work, just because he got the wrong way. And the drivers exist for many years with tons of work, keep improving from time to time, without charging a single cent for the people.

Forward Jack's reply:

I know what VOGONS is. I specifically put the /S2 2.5-MB cache in
XHDD for their 4-MB 80386 users, and nobody had word 1 to say about
it. Also, do note Johnson Lam's post on my behalf re: wny XHDD /B
did not work for you, as you obviously did not "R.T.F.M"!

I have never heard of a "Redbook Audio Test", nor could I run it as
my PC has no audio speakers. I test XDVD2's audio with headphones
plugged into my 12-year-old CD/DVD drive. So, I cannot help you.

Jack R. Ellis

Thanks for clearing it up and thank you jack 😘 🤣 😒 😲 😵

As far as the redbook audio test the decent 2 game runs that, and i have no idea what that means i guess thes redbook cd audio. Problem is we do not know if that user is using a GOG or wares version of the game which has reports of redbook audio bugs. But I have decent 2 original Cd from the official definitive I&II release and I can test it this weekend. so this may or not be fake news. 🤣 😲 😵

@maxtherabbit Well, it brings back memories of CB radio. 😀
Edit: Never mind.

One question I have - can XHDD/XDVD2 be used in Windows 98SE pure DOS mode, without disrupting Windows? I recall I tried one of the predecessors once (UDMA.SYS) and it did not play well with Windows - it either forces it to 16-bit disk access or locks up. This behavior means one has to have a separate boot menu for pure DOS and for Windows when running 98SE, which is a minor inconvenience. Using Microsoft's tools (SMARTDRV/MSCDEX) does not cause such issues. I don't know if it's because 98SE is somehow specifically built to recognize them or because of the nature of their operation. Still, a second boot menu entry might be a good compromise for much better performance as long as DOS compatibility is not affected.

I guess I should try but my 98SE machine is inaccessible at the moment.

Warlord wrote:

Thanks for clearing it up and thank you jack 😘 🤣 😒 😲 😵

As far as the redbook audio test the decent 2 game runs that, and i have no idea what that means i guess thes redbook cd audio. Problem is we do not know if that user is using a GOG or wares version of the game which has reports of redbook audio bugs. But I have decent 2 original Cd from the official definitive I&II release and I can test it this weekend. so this may or not be fake news. 🤣 😲 😵

I'm sorry if my request was not clear. I hope this screen can clarify:

Thank you in advance for testing it.

I mean. I'm really sorry if I offended him. Technically I was half right about umbpci usage, it just needed an emm driver of some kind. I don't mean to bash his products at all, I'm was just trying to find the highest compatibility with the simplest configuration. If his drivers don't necessarily work with all games or hardware then they don't, that's all we were trying to find out.

The documentation thing was complete ignorance on my part, I had no idea that everything was much further down in the readme. I'll admit, I was guilty of skimming it as if it were any other readme and assumed it was just an introduction and changelog, until much later in this thread. I just didn't go back and redact it when i found out, which I just did now.

maxtherabbit wrote:

He seems mad

It's easy to be a tough guy on the internet but let's not allow this thread to go down that road so everyone stay on topic.

dr_st wrote:

One question I have - can XHDD/XDVD2 be used in Windows 98SE pure DOS mode, without disrupting Windows? I recall I tried one of the predecessors once (UDMA.SYS) and it did not play well with Windows - it either forces it to 16-bit disk access or locks up. This behavior means one has to have a separate boot menu for pure DOS and for Windows when running 98SE, which is a minor inconvenience. Using Microsoft's tools (SMARTDRV/MSCDEX) does not cause such issues. I don't know if it's because 98SE is somehow specifically built to recognize them or because of the nature of their operation. Still, a second boot menu entry might be a good compromise for much better performance as long as DOS compatibility is not affected.

I guess I should try but my 98SE machine is inaccessible at the moment.

I don't think DOS TSRs of these kinds play well with Windows in general. If such DOS TSR is loaded, it'll take precedence over Windows' 32-bit I/O drivers, forcing Windows to use 16-bit mode. A replacement Windows driver might be a better option.

When I used Windows 9x I'd just create a menu with one option for Windows and some other options for different types of DOS configurations (where such DOS TSRs will be used). For the Windows option, I'll only load the necessary drivers (such as HIMEM) and boot to Windows straight after (as Windows will take care of the rest with its 32-bit drivers).

LSS10999 wrote:

I don't think DOS TSRs of these kinds play well with Windows in general. If such DOS TSR is loaded, it'll take precedence over Windows' 32-bit I/O drivers, forcing Windows to use 16-bit mode. A replacement Windows driver might be a better option.

Right. The question is what exactly the phrase "of these kinds" means. Because I know for a fact that if you launch Win98SE with loaded VIDE-CDD, MSCDEX and SMARTDRV - it does not conflict in any way and does not force Windows to use the 16-bit mode. I know this because this is how my Win98SE system has been set up for ages.

I also know that with UDMA.SYS that did not work - Windows was forced to the 16-bit path and in fact locked up quickly after load.

LSS10999 wrote:

When I used Windows 9x I'd just create a menu with one option for Windows and some other options for different types of DOS configurations (where such DOS TSRs will be used). For the Windows option, I'll only load the necessary drivers (such as HIMEM) and boot to Windows straight after (as Windows will take care of the rest with its 32-bit drivers).

I guess this is overall the most compatible approach. Typically a single DOS configuration is enough to cover 99% of the scenarios, and then you have a single Windows one and that's it.

dr_st wrote:

Right. The question is what exactly the phrase "of these kinds" means. Because I know for a fact that if you launch Win98SE with loaded VIDE-CDD, MSCDEX and SMARTDRV - it does not conflict in any way and does not force Windows to use the 16-bit mode. I know this because this is how my Win98SE system has been set up for ages.

I also know that with UDMA.SYS that did not work - Windows was forced to the 16-bit path and in fact locked up quickly after load.

I guess this is overall the most compatible approach. Typically a single DOS configuration is enough to cover 99% of the scenarios, and then you have a single Windows one and that's it.

"Of these kinds" I mean those which can take control of I/O accesses (such as RAM, hard drive, optical drives). I recall seeing warnings about certain drivers forcing Windows into "MS-DOS compatibility mode".

I'm not an expert, but given the examples, it's possible the TSRs you mentioned (VIDE-CDD, MSCDEX, SMARTDRV) are "Windows-aware", that upon Windows startup, they'll properly give up the I/O accesses they took control and not to interfere, so Windows can be run without issues. Not all TSRs are designed with Windows 9x in mind.

Or the other way around with Windows 9x being designed to load with those TSRs.

From my heart: Jack and I just want to make DOS better, no intentional personal attack on others, just plain problem want to solve. Many memory manager did have compatibility issue, especially HIMEMX and JEMMEX, both have quite serious problems. Quote an email from Jack (2019-04-9):

JEMMEX was never updated to support new mainboards with "fragmented" XMS areas due to ROMs, memory mapped I-O addresses etc. J […]
Show full quote

JEMMEX was never updated to support new mainboards with "fragmented" XMS
areas due to ROMs, memory mapped I-O addresses etc. Japheth told me in
2012 he desired to "remain compatible with Microsoft HIMEM", which bails
out of looking for more XMS after finding the first XMS area. Good for
old mainboards with "linear" XMS. But BIOS writers had REASONS for the
1995 "Int 15h AX=E820h" memory-LIST calls for XMS memory! JEMMEX needs
an update to issue and support those calls, or it will continue to fail!

HIMEMX V3.34 failed for Dimitris Zilaskos in 2016 due to a FOOLISH error
by Pemberton et al: Adding "Int 15h AH=EAh" BIOS calls to get XMS, with
NO validity check on the results and NO WAY to disable such calls! And
the FreeDOS WIKI, in its comments about JEMMEX, mentions HIMEMX as still
causing problems, even after its 2013 update. That needs to be "looked
into" and resolved, and NOT by Pemberton!

HIMEMX V3.32 cannot find all XMS memory on newer mainboards, as it lacks
Pemberton's now-questionable 2013 updates. V3.32's logic for old main-
boards does not use Pemberton's "Int 15h AH=EAh" request and should work
fine. Putting V3.32's logic BACK into V3.34 might also be a good idea!

FDXMS allows NO interrupts at all during XMS moves, a clear violation of
XMS specs and a BAD risk with real-time programs. I wrote Stromberg in
2007 about this, and he replied an upgrade is "not yet needed". WRONG!

All old XMGR drivers have improper "386 errata" logic, if we can believe
what Ninho needed with his 386/SX. They also do not set the "XMSXXXX0"
driver name used by Microsoft HIMEM, which was not part of the XMS specs
but appears to have become a "de-facto standard", for DOS games or other
programs that may not work if they do not find "XMSXXXX0". Fixed now,
in the Closed-Source XMGR. I hope this fixes some "odd" XMGR problems.

And I'm glad to tell you, XHDD still updating despite it's more than 15 years development.

Normally "XDVD2.SYS" would work flawlessly, but I'm currently struggling with it on one specific CD/DVDRW drive that identifies itself as "TSSTcorpCD/DVDW SH-S182M".
This specific drive refuses to read any inserted CD when initialized with:

1DEVICEHIGH=XDVD2.SYS /D:OPTICAL /H

in combination with either MSCDEX or SHCDX33F. "XDVD2.SYS" recongizes the drive with ATA33 and MSCDEX or SHCDX33F also assigns a drive letter.

However, I can access the CD-drive when replacing "XDVD2.SYS" with "OAKCDROM.SYS" or "VIDECDD.SYS"?

Any suggestions, why "XDVD2.SYS" does not like the drive?

Is anyone aware that using XHDD on a system with XTIDE results in a cached floppy A: drive?

This means if XTIDE is loaded and you access the floppy drive with the DIR command, change the disc and then rerun DIR again, the content from the first disc is still presented as the floppy drive is not accessed again. (The green light is not lit when you enter DIR here).