r328: OS/2 Warp 3 format error; CD access crashes PCem

[ppgrainbow]

For the next month, I think it's time to get the bugs ironed out rather than adding new features...so, here we go!

Has anyone attempted to install OS/2 Warp 3 via floppy diskettte or CD-ROM? I bet that you didn't know this but here is what happened.

First of all on the Intel Advanced/PCI-based (Endeavor) machine (75 MHz Pentium, 32 MB system memory, Phoenix S3TRIO 32 graphics card with 2 MB VRAM), I did a floppy-based installation of Warp 3, used its FDISK utility to partition the drive so that the OS can recognise it.

But when the installation process is asked to insert disk 2 and when it tries to format the drive as a FAT or HPFS partition, this error message shows up:

Warp 3 Floppy.png (42.1 KiB) Viewed 26262 times

Now on the Award 430VX PCI chipset machine (same specs as the Intel Advanced/PCI), attempting to install OS/2 Warp 3 via virtual CD-ROM crashes PCem. Here's the pclog.txt file on what caused it to crash:

pclog.txt

(8.63 KiB) Downloaded 541 times

I had to trim the size of the log to fit within the 256 KB limit.

I mounted the CD-ROM ISO of Warp 3 using IMDisk and mapped it as drive N so that PCem can recognise the mounted CD-ROM. Whatever I mounted the CD-ROM ISO as a virtual drive or used the real CD-ROM when trying to install OS/2 Warp 3 or 4, PCem aborts!

I know that some of you hate having to fix the bugs in OS/2, but it's not easy and it has to be done and it will take time to improve.

Thanks.

(It would also be helpful to provide development screenshots if you successfully got OS/2 Warp 3 fully working.)

[SarahWalker]

That crash is a result of the networking code, not anything currently in the main repository.

I have incidentally installed Warp 3 off floppies fairly recently, and it mostly worked for me; while there were some disk read errors they were much later in the install, after the initial reboot and once OS/2 was in graphical mode.

[ppgrainbow]

That crash is a result of the networking code, not anything currently in the main repository.

I have incidentally installed Warp 3 off floppies fairly recently, and it mostly worked for me; while there were some disk read errors they were much later in the install, after the initial reboot and once OS/2 was in graphical mode.

That's what I've been thinking. It turns out that the networking code that neozeed implemented still remains buggy...so, I'll probably have to inform neozeed about this issue.
I might have to retest OS/2 1.3, 2.0 and 2.1 to see if the problem still exists or not.

Edit: Uh...I'm STILL getting the format error in r332 on the Intel Advanced/EV PCI machine and the error still persists on the Award 430VX/PCI machine as well. I was using the unmodified floppy installation diskettes to try to install OS/2 Warp 3 from floppy.

As for the virtual CD-ROM usage in the Award 430VX/PCI, the good news is that I managed to partially install OS/2 Warp 3 in text mode using the CD-ROM ISO image mounted as drive N. The buggy networking code caused PCem to crash when attempting to access the virtual CD-ROM drive.

Even if I'm using r332 (without any networking capabilities), when I got to the graphical portion of OS/2 Warp 3 setup, I get this when trying to access the mounted CD-ROM ISO image:

Warp 3 CD install failure.png (36.75 KiB) Viewed 26245 times

It turns out that the CD installation didn't copy some of the files and ends up complaining that it couldn't access the source drive which is the mounted CD-ROM ISO image and as a result, the disk read/write corruption seems to be too severe to allow the installation to continue.

[neozeed]

the disk read/write corruption seems to be too severe to allow the installation to continue.

Is anyone else getting this 'disk corruption' thing? I've never had this issue.

And other than shitty CD-ROM probes I don't see how the NE2000 has anything to do with what is going on.

This just reeks of un-reproducable 'issues'.

[ppgrainbow]

the disk read/write corruption seems to be too severe to allow the installation to continue.

Is anyone else getting this 'disk corruption' thing? I've never had this issue.

And other than shitty CD-ROM probes I don't see how the NE2000 has anything to do with what is going on.

This just reeks of un-reproducable 'issues'.

I've been getting disk corruption issues before especially when I try to install IE5 16-bit on Windows NT 3.51, I had to try numerous times to get the browser functional. I'll bet that disk corruption can often occur when I try to copy the file to the hard disk image either by using WinImage or IMDisk (via mounting the hard disk image). I'll have to do more testing to see if the disk corruption occurs and report it when neccessary.

I'm really baffled to see any networking related bugs that could be causing OS/2 Warp 3 installation to crash with r328. Perhaps Tom can try to clarify what part of code in the networking caused PCem to crash when attempting to install OS/2 Warp 3 using the virtual CD-ROM.

[neozeed]

look we don't need 30 threads, and you don't need to post it all over the place, try to keep this in one spot.

First OS/2 warp is a total piece of shit. It has zero auto-detection for anything. As always the problem is that it's spamming port 0x300 and one of the drivers doesn't like what it see's. I don't know why PCem EXITS. It doesn't crash. there is no gpfault. It just quits. Did you try removing the drivers you don't need? YES OS/2 WARP was a clusterfuck to install when it was out. This is why nobody used it. It was a BEAR to install, even the IBM reps used Windows 3.1 then Windows 95 because even they couldn't get OS/2 installed.

So honestly I'm not surprised about an emulator emulating vintage hardware of the period having massive OS/2 issues.

You are the only one with disk corruption issues, so no doubt it is something you are doing. USE DISKS SMALLER THAN 500MB!!!!

The only 'good' version of OS/2 was 2.00, and that is because it was mostly Microsoft code. The more IBM tried to 'improve' things the further they just broke it because they had no clue what they were doing.

I know this may be hard to believe, but again installing OS/2 WARP 3.0 and beyond was not easy, it was not trivial, and it 99% of the time needed you to modify the config.sys and the device drivers on the install diskettes. It was *NOT* user friendly in the least bit.

[amadama]

Agree with what neozeed is saying. If you really want to tackle installation of OS/2 3 please read the following:
http://www.os2world.com/cgi-bin/ultrabo ... D=914&SID=

You are going to have to replace and configure a few files on the installation disk #1.

[ppgrainbow]

Thank you for telling me. I have to apologise that I gotten carried away on how to get OS/2 Warp 3/4 to work on PCem.

I'm gonna have to go with neozeed and stick with OS/2 2.0, just to play safe. If I really wanted to install Warp 3, I'm gonna have to modify the CONFIG.SYS file to make things work.

[neozeed]

Thank you for telling me. I have to apologise that I gotten carried away on how to get OS/2 Warp 3/4 to work on PCem.

I'm gonna have to go with neozeed and stick with OS/2 2.0, just to play safe. If I really wanted to install Warp 3, I'm gonna have to modify the CONFIG.SYS file to make things work.

For what it's worth, I installed NT 3.51 without any issues at all. Installed service pack 5, again no problem. I found probably the same IE 5 you have from browers.evolt.org ... same thing no toolbar. It's corrupt no doubt.

I'm installing SQL server, and it's doing it's thing without any issues (so far). Keep your disks small.

Back in 93/94/95 the only time OS/2 had a fighting chance, there were an incredible amount of machines, and configs that were just not OS/2 compatible. Especially to the newer versions. IBM made so many poor decisions with OS/2 and it's technical direction that when they finally pissed Microsoft enough to abandon it, you can see that the newer MS software has much better and more robust driver support. OS/2 2.0 and higher is more of a 16bit kernel than 32bit. The 32bit stuff is added onto the existing 16bit kernel, which is why they can use the same device drivers, and why so many other limitations of 16bit OS/2 permiated all the way through OS/2 2, 3 and 4. Meanwhile NT had a far better driver model and far superior performance, not to mention SMP in the box, and was just all around far more robust and easier to install.

There is a fundamental reason why the world went with Windows NT, and that is simply because Netware 3.x and 4.x were more unfriendlier than OS/2, and everyone had enough.

NT 4.0 was icing on the cake, as far as a usable UI with a server OS. OS/2 never kept any friends with it's 16bit drivers, and lack of features that you were constantly expected to pay and pay and pay for. Just try to install Oracle on Netware or SQL server on OS/2, and see what a delicate stack of crap it is vs installing SQL on Windows NT.

[ppgrainbow]

Thank you for telling me. I have to apologise that I gotten carried away on how to get OS/2 Warp 3/4 to work on PCem.

I'm gonna have to go with neozeed and stick with OS/2 2.0, just to play safe. If I really wanted to install Warp 3, I'm gonna have to modify the CONFIG.SYS file to make things work.

For what it's worth, I installed NT 3.51 without any issues at all. Installed service pack 5, again no problem. I found probably the same IE 5 you have from browers.evolt.org ... same thing no toolbar. It's corrupt no doubt.

I'm installing SQL server, and it's doing it's thing without any issues (so far). Keep your disks small.

Back in 93/94/95 the only time OS/2 had a fighting chance, there were an incredible amount of machines, and configs that were just not OS/2 compatible. Especially to the newer versions. IBM made so many poor decisions with OS/2 and it's technical direction that when they finally pissed Microsoft enough to abandon it, you can see that the newer MS software has much better and more robust driver support. OS/2 2.0 and higher is more of a 16bit kernel than 32bit. The 32bit stuff is added onto the existing 16bit kernel, which is why they can use the same device drivers, and why so many other limitations of 16bit OS/2 permiated all the way through OS/2 2, 3 and 4. Meanwhile NT had a far better driver model and far superior performance, not to mention SMP in the box, and was just all around far more robust and easier to install.

There is a fundamental reason why the world went with Windows NT, and that is simply because Netware 3.x and 4.x were more unfriendlier than OS/2, and everyone had enough.

NT 4.0 was icing on the cake, as far as a usable UI with a server OS. OS/2 never kept any friends with it's 16bit drivers, and lack of features that you were constantly expected to pay and pay and pay for. Just try to install Oracle on Netware or SQL server on OS/2, and see what a delicate stack of crap it is vs installing SQL on Windows NT.

Thank you for the advice and the information regarding OS/2.

Netware is indeed *much worse* than OS/2. Windows NT 4.0 required at least 110 MB of free disk space and it all of the updates and Internet Explorer 6, it turned out to be too much to fit on a hard disk smaller than 504 MB.

When Windows 95 came out, OS/2 fought the battle with its Warp 3/4 operating system and lost.

Speaking of data corruption, I finally found the culprimt...it's the HIDE87 utility that causes CHKDSK to falsely report errors on drive C when running the MS-DOS prompt not just under Windows 3.1, bot Windows 3.0 as well! This was tested on both machines...the AMI 486 BIOS, 16 MB RAM, Tseng ET4000 w/1 MB VRAM and AMI WinBIOS 486, 64 MB RAM, Trident 8900C graphics card with 1 MB VRAM).

I think that this bug should be fixed soon. I ran the HIDE87 utility on another MS-DOS PC on VirtualPC and there is no such issue at all.

[neozeed]

Ok, so here is some more information on this crash.

I've tried updating the CD-ROM drivers, and the stock drivers, and they fail the same way..... Which I suppose is good.

I'm running Windows 10 (x64) with a 32bit MinGW building PCem. I'm using VirtualCloneDrive 5.4.7.0 mounting the BlueSpine CD.

By default OS/2 can't find the CD-ROM on the secondary controller/slave position so I tried a small modification to ide.c to make the CD-ROM slave in the primary controller:

Code: Select all

        loadhd(&ide_drives[0], 0, ide_fn[0]);
        if (cdrom_enabled)
                ide_drives[1].type = IDE_CDROM;
        else
                loadhd(&ide_drives[1], 1, ide_fn[3]);

Which is for the good news. I 'fixed' all the 'fatal' paths in the NE2000 driver so it could continue, so PCem no longer exits during the multitude of device probes. As far as I can tell the driver loads then encounters a GP fault:



And looking through pclog.txt this is what it was doing with the CD-ROM (the prior events are onesec ticks)

Code: Select all

New ATAPI command 00 62138593
New ATAPI command 03 62139358
New ATAPI command 12 62139721
New ATAPI command 5A 62140175
New ATAPI command 55 62140634

So if I'm not mistaken it's

TEST UNIT READY
REQUEST SENSE
INQUIRY
MODE SENSE (10)
MODE SELECT (10)

Naturally Windows NT 3.51 doesn't care, and works fine out of the box with the IDE-CDROM wherever I want.

Code: Select all

New ATAPI command 12 59598736
New ATAPI command 25 59925791
New ATAPI command 12 59946377
New ATAPI command 00 84957986
New ATAPI command 25 84958745
New ATAPI command 43 84960278
New ATAPI command 28 84985117
New ATAPI command 28 84989864
New ATAPI command 28 85005983
New ATAPI command 28 85008573
New ATAPI command 28 85009017
New ATAPI command 00 85020273
New ATAPI command 00 85041305
New ATAPI command 00 85042690
New ATAPI command 00 85045483
New ATAPI command 00 85127381
New ATAPI command 00 85272262
New ATAPI command 28 85274456
New ATAPI command 00 85302039
New ATAPI command 00 85303961
New ATAPI command 00 85326091
New ATAPI command 00 85327449
New ATAPI command 00 85334314
New ATAPI command 00 85827306
New ATAPI command 00 85829712

More of a FYI, not expecting any miracles for the 2-3 fringe OS/2 Warp 3.0 tourists out there... lol

[amadama]

The ATAPICD$ error is repaired using the IBM fixpack that was mentioned in the link I posted above:
http://service.software.ibm.com/os2dd/free/idedasd.exe

I will send you my updated "fixed" floppy disk 1 this afternoon. But if you want to do it now check out the readme file in the pack.
(delete the SCSI and SONY drivers from the disk 1 to make room and remove those entries from the config.sys and add "set copyfromfloppy=1" to it (this will use the updated drivers you put on the disk and override the ones on the CD)).
God forbid you have a typo or blank line in the config.sys. You will get a stop error with the following code:
c0000005

[neozeed]

The ATAPICD$ error is repaired using the IBM fixpack that was mentioned in the link I posted above:
http://service.software.ibm.com/os2dd/free/idedasd.exe

I will send you my updated "fixed" floppy disk 1 this afternoon. But if you want to do it now check out the readme file in the pack.
(delete the SCSI and SONY drivers from the disk 1 to make room and remove those entries from the config.sys and add "set copyfromfloppy=1" to it (this will use the updated drivers you put on the disk and override the ones on the CD)).
God forbid you have a typo or blank line in the config.sys. You will get a stop error with the following code:
c0000005

Heh I was using an atapi.zip that specifically said it was for OS/2 Warp 3.0 ... LMFAO. I'd forgotten just how bad this stuff was, and even then my memory of having to do installs for other people because they couldn't get it to install.

Seriously nobody could get OS/2 to install on their own, and Windows 95? I don't think anyone had any problems.

lol spoke too soon!



testconfig.sys or some shit I think... or it's not likeing my copyfromfloppy...

[amadama]

Try this disk. (this is disk 1, disk 0 stays stock)

https://www.dropbox.com/s/0mzaha844q2wd ... 1.zip?dl=0

[Battler]

Speaking of data corruption, I finally found the culprimt...it's the HIDE87 utility that causes CHKDSK to falsely report errors on drive C when running the MS-DOS prompt not just under Windows 3.1, bot Windows 3.0 as well! This was tested on both machines...the AMI 486 BIOS, 16 MB RAM, Tseng ET4000 w/1 MB VRAM and AMI WinBIOS 486, 64 MB RAM, Trident 8900C graphics card with 1 MB VRAM).

I think that this bug should be fixed soon. I ran the HIDE87 utility on another MS-DOS PC on VirtualPC and there is no such issue at all.

HIDE87 was created in order to hide the FPU to fix WIN87EM.DLL problems when running 16-bit Windows applications on a virtualized modern CPU/FPU. Most probably it might do things that just don't work and cause unpredictable behavior on an old CPU. Virtual PC won't be a good reference here, as it virtualizes your host (modern) CPU. What you'd need to do is run HIDE87 on a real 486 or Pentium and see what happens.

I don't know why PCem EXITS. It doesn't crash. there is no gpfault. It just quits.

You'd need to compile a debug binary and see what appears in pclog.txt . Generally, it's going to be either a triple fault, or a pccache-related fatal. Both indicate bugs in the CPU emulation, be it bugs during execution of CPU instructions, or incorrect MMU behavior, which there are plenty of.

[ppgrainbow]

Speaking of data corruption, I finally found the culprimt...it's the HIDE87 utility that causes CHKDSK to falsely report errors on drive C when running the MS-DOS prompt not just under Windows 3.1, bot Windows 3.0 as well! This was tested on both machines...the AMI 486 BIOS, 16 MB RAM, Tseng ET4000 w/1 MB VRAM and AMI WinBIOS 486, 64 MB RAM, Trident 8900C graphics card with 1 MB VRAM).

I think that this bug should be fixed soon. I ran the HIDE87 utility on another MS-DOS PC on VirtualPC and there is no such issue at all.

HIDE87 was created in order to hide the FPU to fix WIN87EM.DLL problems when running 16-bit Windows applications on a virtualized modern CPU/FPU. Most probably it might do things that just don't work and cause unpredictable behavior on an old CPU. Virtual PC won't be a good reference here, as it virtualizes your host (modern) CPU. What you'd need to do is run HIDE87 on a real 486 or Pentium and see what happens.

I don't know why PCem EXITS. It doesn't crash. there is no gpfault. It just quits.

You'd need to compile a debug binary and see what appears in pclog.txt . Generally, it's going to be either a triple fault, or a pccache-related fatal. Both indicate bugs in the CPU emulation, be it bugs during execution of CPU instructions, or incorrect MMU behavior, which there are plenty of.

I will run HIDE87 under MAME 0.165 with the ct486 driver and under DOSBox to see if I could reproduce the false CHKDSK corruption bug when running the MS-DOS prompt in Windows 3.0 (or Windows 3.1). It seems that HIDE87 doesn't seem to get along with any expanded memory manager driver such as EMM386 and QEMM386.

Notable applications that don't work correctly without HIDE87 is Distant Suns 1.2 and Netscape Navigator 4.08.

[Battler]

Yes, but I think they need HIDE87 on a modern CPU/FPU, not on a CPU/FPU from the period they were made in. So there's no need to use HIDE87 in PCem, as that emulates a period CPU/FPU.

[SarahWalker]

Why are you running HIDE87 anyway? If you don't want a coprocessor, just emulate a CPU without one.

[ppgrainbow]

Yes, but I think they need HIDE87 on a modern CPU/FPU, not on a CPU/FPU from the period they were made in. So there's no need to use HIDE87 in PCem, as that emulates a period CPU/FPU.

If there is no need to use HIDE87 on a emulated 80486 or Pentium-based machine in PCem, there will be consequences that certain software under Windows 3.x will not work at all with certain graphics cards such as the Tseng Labs ET4000 and the Trident 8900D to name a few.

[ppgrainbow]

Why are you running HIDE87 anyway? If you don't want a coprocessor, just emulate a CPU without one.

If I'm going to use certain software where it causes Windows 3.x to crash due to WIN87EM.DLL, HIDE87 is required in order for it to work. Unfortunately, running HIDE87 as a TSR via the AUTOEXEC.BAT file is going to have unpredictable results when running under PCem, such as CHKDSK falsely reporting errors when running the MS-DOS prompt under Windows 3.x.

80486-based processors have co-processors built in as far as I know. Emulating a CPU without a coprocessor will render the CPU as a 80486SX (or 80486SX2) processor. 80386 processors had the option to support a co-processor and under PCem, 80386-based emulated machines don't emulate co-processor support.

[SarahWalker]

Yes, but I think they need HIDE87 on a modern CPU/FPU, not on a CPU/FPU from the period they were made in. So there's no need to use HIDE87 in PCem, as that emulates a period CPU/FPU.

If there is no need to use HIDE87 on a emulated 80486 or Pentium-based machine in PCem, there will be consequences that certain software under Windows 3.x will not work at all with certain graphics cards such as the Tseng Labs ET4000 and the Trident 8900D to name a few.

???

Why would not using HIDE87 prevent you from using certain graphics cards?

[SarahWalker]

Why are you running HIDE87 anyway? If you don't want a coprocessor, just emulate a CPU without one.

If I'm going to use certain software where it causes Windows 3.x to crash due to WIN87EM.DLL

Which only happens on virtualisation software from what I can tell. PCem does not perform any virtualisation.

I don't entirely know what HIDE87 does, but if running it causes problems and it serves no purpose (which seems to be the case), stop running it!

[Battler]

- ppgrainbow: HIDE87 is required under virtualization because it seems like WIN87EM.DLL doesn't like modern CPU's FPU's for some reason. Inside PCem that's irrelevant as WIN87EM.DLL sees the correct CPU/FPU for its time, which is also the one the software from that time expects, so unless there's some bug this horrible in PCem's x87 emulation (which I doubt, otherwise most stuff wouldn't work at all in PCem), HIDE87 is completely pointless in PCem.

[ppgrainbow]

Tom, HIDE87 is a part of a utility called WINFLOAT, it's a TSR utility that hides the 80x87 from Windows applications. HIDE87 is installed before starting Windows in thinking that there is no coprocessor. Because PCem does not use virtualisation, I'll have to stop using HIDE87, because it causes unpredictable issues that are not going to be fixed.

[ppgrainbow]

- ppgrainbow: HIDE87 is required under virtualization because it seems like WIN87EM.DLL doesn't like modern CPU's FPU's for some reason. Inside PCem that's irrelevant as WIN87EM.DLL sees the correct CPU/FPU for its time, which is also the one the software from that time expects, so unless there's some bug this horrible in PCem's x87 emulation (which I doubt, otherwise most stuff wouldn't work at all in PCem), HIDE87 is completely pointless in PCem.

That's what I've been thinking all along. There could be a annoying bug in PCem's x87 coprocessor emulation, so...I'm gonna have to stop using HIDE87.

Update 1: The removal of HIDE87 and the files associated with it stopped the issues that I have been experiencing. No more data corruption bugs.

Update 2: Battler and Tom...it turns out that I was totally stupid in believe that only HIDE87 caused corruption issues. To tell you the truth here, that's not totally true. It has to do with the CONFIG.SYS settings in the expanded memory manager that I've been using, QEMM386. It took a lot of trial and error and I finally got it right all along!

In line 7 of the CONFIG.SYS file, I put this in:

Code: Select all

DEVICE=C:\QEMM\QEMM386.SYS RAM BE:N ARAM=C900-DFFF I=B000-B7FF I=E000-EFFF R:1

In the QEMM386.SYS file, including address below E000 and using HIDE87 caused the CHKDSK to misreport errors while I was running MS-DOS inside Windows 3.1. I'm now going to correct the problem on the AMI 486 clone machine and put this issue to rest once and for all!

[neozeed]

Try this disk. (this is disk 1, disk 0 stays stock)

https://www.dropbox.com/s/0mzaha844q2wd ... 1.zip?dl=0

It bombs in the same spot. Oh well it's no big deal, personally I hated Warp 3 with it's stupid dock thing. It wasn't good enough to be like in NeXTSTEP, and it sure wasn't enough to compete with the start menu. And OS/2 4.0? what a disaster, even the last time I did an OS/2 upgrade from 1.0/1.1/1.2/1.3/2.0/2.1/3.0/4.0 it destroyed so much it was pretty much useless.

I would install 2.0 or 2.11 but the massive pause/lag between shuffling disks is just too tedious.

[ppgrainbow]

Try this disk. (this is disk 1, disk 0 stays stock)

https://www.dropbox.com/s/0mzaha844q2wd ... 1.zip?dl=0

It bombs in the same spot. Oh well it's no big deal, personally I hated Warp 3 with it's stupid dock thing. It wasn't good enough to be like in NeXTSTEP, and it sure wasn't enough to compete with the start menu. And OS/2 4.0? what a disaster, even the last time I did an OS/2 upgrade from 1.0/1.1/1.2/1.3/2.0/2.1/3.0/4.0 it destroyed so much it was pretty much useless.

I would install 2.0 or 2.11 but the massive pause/lag between shuffling disks is just too tedious.

I'm with you on this one. OS/2 Warp turned out to be a big failure which lead to IBM withdrawing all support by the end of 2006. Here's an article on the reason why OS/2 failed: http://ps-2.kev009.com/michaln/history/failed.html

I'm wondering is any reason why Warp 3 bombs in the same spot?

[Battler]

- ppgrainbow: It's I=B000-B7FF that's at fault. For some reason, using that option in PCem makes DOS rather unstable and prone to all sorts of weird behaviors (CD-ROM drivers freezing, random EMM386 errors, etc.), that happen neither in, say, Virtual PC 2007, nor did they happen on real hardware - I always used that option on my Pentium 100 MHz to gain extra upper memory and never had any problems.

Edit: And I forgot to say, it happens even with EMM386.

With just I=C800-EFFF, everything is perfectly stable. But as soon as B000-B7FF is assigned to UMB's, and anything is loaded into UMB's in that region of the memory, whatever is loaded there, behaves erratically. If it's a CD-ROM driver, it will freeze for example.

[ppgrainbow]

- ppgrainbow: It's I=B000-B7FF that's at fault. For some reason, using that option in PCem makes DOS rather unstable and prone to all sorts of weird behaviors (CD-ROM drivers freezing, random EMM386 errors, etc.), that happen neither in, say, Virtual PC 2007, nor did they happen on real hardware - I always used that option on my Pentium 100 MHz to gain extra upper memory and never had any problems.

I think that I'll remove the I=B000-B7FF reference from CONFIG.sYS. Is there even a way to exclude the B000-B7FF address from the CONFIG.SYS?

[Battler]

- ppgrainbow: Just remove I=B000-B7FFF, it will cause your memory driver to not assign those drivers to UMB's.

However, I would appreciate it if the problem was fixed, because as I said, this behavior does not occur on real hardware, it only occurs inside PCem, so it's definitely a PCem bug.