Voltage Monitor Error

[Grandcheapskate]

FDISK is nothing more than invoking INT13 hard disk services directly, whereas the other activities use the built-in MSDOS driver for C:.

Some old BIOSes had a BIOS "antivirus" provision. Make sure that if you've got it, that it's disabled.

Try running the attached partition display program from a DOS floppy. See if it hangs also.

Thank you Chuck, I will try this later today. I have disabled the anti-virus option in the BIOS and have looked for anything else which may try to block the update of the master boot record, but so far nothing stands out.

I did try a FDISK /MBR on the WD 4.3 GB drive. This command did not hang the system, but a subsequent FDISK did hang so it appears the /MBR option had no effect - if it even did anything.

Thanks...Joe

 

[Agent Orange]

Thank you Chuck, I will try this later today. I have disabled the anti-virus option in the BIOS and have looked for anything else which may try to block the update of the master boot record, but so far nothing stands out.

I did try a FDISK /MBR on the WD 4.3 GB drive. This command did not hang the system, but a subsequent FDISK did hang so it appears the /MBR option had no effect - if it even did anything.

Thanks...Joe

Joe,

If you have time, what is the exact syntax that you are using when you FDISK?

Tom

 

[Grandcheapskate]

Joe,

If you have time, what is the exact syntax that you are using when you FDISK?

Tom

Hi Tom,
Nothing, no output at all. The system just hangs at that point. Only using the RESET button or power off/on will reboot the machine.

Hi Chuck,
I ran PARTIT from the A: drive after booting off the Maxtor HD. I got a display, so I assume the program worked. I then copied it to the C: drive and ran it successfully there as well. It seems to show only a C: drive on the Maxtor (which according to a DIR listing is only a portion of the whole 546mb).

I then replaced the Maxtor with the WD drive and booted from the A: drive. If I am reading the output correctly, it seems there is a C: partition and an extended partition already on the WD drive, but I cannot access anything on that drive.

Thanks...Joe

 

[Chuck(G)]

Here's something to try---let's wipe out the partition table on a hard drive of your choice--shouldn't matter since you're trying to fdisk the drive anyway. Boot from a floppy, making sure that DEBUG.COM is on the floppy. Then do this (your entries are bolded; regular text is what the system displays.

A:\>[B]debug[/B]
-[B]f200 l200 0[/B]
-[B]a100[/B]
0AF7:0100 [B]mov ax,0301[/B]
0AF7:0103 [B]mov bx,200[/B]
0AF7:0106 [B]mov cx,0001[/B]
0AF7:0109 [B]mov dx,0080[/B]
0AF7:010C [B]int 13[/B]
0AF7:010E [B]int 3[/B]
0AF7:010F
-[B]g=100[/B]

AX=0001  BX=0200  CX=0001  DX=0080  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=0AF7  ES=0AF7  SS=0AF7  CS=0AF7  IP=010E   NV UP DI NG NZ AC PO NC
0AF7:010E CC            INT     3
-[B]q[/B]

A:\>

In particular, note the value shown for AX and that the NC flag is displayed. If the system is cutting you off, the value for AX will be different and instead of NC, you'll see CY.

If you start fdisk or partit after this, it should show an empty hard disk. If you still can see a partition table (use the partit utility if you want), then something is getting in the way of your disk writes.

 

[Grandcheapskate]

Hi Chuck,
Before I had a chance to try your suggestion above, I got FDISK to work...and quite by accident. I also see the cause but I have no idea about the reason. Let me explain.

While I was trying to get the DEBUG program onto a bootable floppy, I also wanted to have my floppy load the CD drivers. This led to a comedy of errors because all my DOS boot disks (except one) didn't have CD drivers and I wanted access to the CD drives. I was finally able to copy the one bootable CD driver floppy onto another and add the DEBUG program. I then rebooted from the A: drive.

Before running DEBUG, I decided to once more try FDISK...and it worked with the WD hard drive! I powered down and replaced the WD drive with the bootable Maxtor and booted from the floppy. And I was able to FDISK the Maxtor drive. So I then ran the FDISK program off the Maxtor DOS directory and it worked also. Hummmm.

So I booted off the Maxtor and ran FDISK...and it hung. I then booted off the Maxtor and ran FDISK from the floppy...and it hung.

Long story short...the only difference was the floppy which worked did not load EMM386.EXE RAM and did not have the line DOS=HIGH,UMB in CONFIG.SYS. It seems this stopped FDISK from running. Once I removed EMM386 from the Maxtor CONFIG.SYS, booting off the Maxtor also allowed FDISK to run.

Now the question is...why? This has to be related to something about this particular motherboard because I load EMM386 on every DOS machine I have and have never had this problem.

Thanks...Joe

 

[Chuck(G)]

Having seen the code for EMM386, I'll opine that it's a rat's nest of special cases.

I'd start with some good web searches such as "EMM386 problem". Or run down the Microsoft troubleshooting pages. Be sure that you've identified the chipset for your motherboard, as this may be relevant.

 

[njroadfan]

Any reason why your boot disks load EMM386? It really isn't needed in most cases. Its always best to boot clean and in real mode unless you really need to use the CPU's MMU for something. Also, if you need UMBs, there are quite a few memory managers out there that can unlock UMBs without resorting to the MMU and putting the machine into V86 mode.

 

[Chuck(G)]

I manage to work with 286+ PCs using only HIMEM.SYS. You can still shrink the lower memory DOS footprint using it.

 

[Grandcheapskate]

Any reason why your boot disks load EMM386? It really isn't needed in most cases. Its always best to boot clean and in real mode unless you really need to use the CPU's MMU for something. Also, if you need UMBs, there are quite a few memory managers out there that can unlock UMBs without resorting to the MMU and putting the machine into V86 mode.

For a boot diskette, assuming I am using it for nothing more than accessing the machine, there is probably no reason to load EMM386. However, the problem also reared it's head when I booted off the hard drive. So if I wanted to load DOS for use on this motherboard ( I am going to go with either Win95 or Win98 ), I would run into this problem if I wanted to load EMM386. It's going to be interesting to see what happens when I boot this MB with either Win95 or Win98.

Thing is, I have never run into this before on any other board. On the other hand, I may never have booted a P2 with a DOS diskette (loading EMM386) and tried to run FDISK.

Joe

 

[Stone]

When you say P2 does that mean you are using a Slot 1 processor?

 

[Grandcheapskate]

When you say P2 does that mean you are using a Slot 1 processor?

Yes. A Pentium 2 350MHz. My friend gave me the board with an adapter card which uses a socket 370 CPU (a Celeron 400 MHz). However, the adapter card doesn't really lock in place (it can rock back and forth), so I replaced it with a standard slot 1 P2.

Joe

 

[Stone]

But you still haven't explained why you are using that archaic EMM386.EXE?

 

[Chuck(G)]

When you get to quirky problems like this on just about any motherboard that's later than a 386, the support chipset tends to matter more than the exact CPU used. What chipset is used on the problematic motherboard?

 

[Grandcheapskate]

When you get to quirky problems like this on just about any motherboard that's later than a 386, the support chipset tends to matter more than the exact CPU used. What chipset is used on the problematic motherboard?

Why would I use EMM386? It's what I have always used for my 386+ DOS machines and never had an issue..well actually I use QEMM. Once I get a configuration that works, I stick with it. I can tell you that after being on this site for a while, I realize how little I may understand about the internal workings of the PC. Being a long time IBM mainframe guy and learning how logically mainframes work, learning about the internal workings of microprocessors is like looking into a cobbled together mish-mosh which seems to have been designed on the fly. Probably due to the way the microprocessor made it's way into the general public.

According to the manual, the ASUS P2B-F motherboard uses the Intel 440BX AGP chipset.

Joe

 

[Stone]

So, what do you run that actually uses Expanded Memory? Lotus? Desqview? What? If you're not using EMS you don't need an EMS Manager.

 

[Chuck(G)]

I have fond memories of the 7090, 1401 and 1620. Did some work with S/360, then converted to CDC big iron myself. Thence to little iron, then back to very big iron, then back to little iron, often simultaneously. Meh, it's all bits...

The 440BX is a very solid chipset--almost legendary in the p2 and p3 world. Note that the P2B manual mentions that the EMM386 needs to be from DOS 6.22 or later. (I have a couple of P2A's but not a P2B).

 

[Grandcheapskate]

I have fond memories of the 7090, 1401 and 1620. Did some work with S/360, then converted to CDC big iron myself. Thence to little iron, then back to very big iron, then back to little iron, often simultaneously. Meh, it's all bits...

The 440BX is a very solid chipset--almost legendary in the p2 and p3 world. Note that the P2B manual mentions that the EMM386 needs to be from DOS 6.22 or later. (I have a couple of P2A's but not a P2B).

I did a quick scan through my manual and did not see the DOS 6.22 requirement, but I didn't read it cover to cover.

I firmly believe that having "grown up" on the IBM mainframe has made it nearly impossible for me to get my head around the arcitecture of the microprocessor as it relates to the machine/assembler code - especially the instruction set. Maybe had I never seen the mainframe, I might think the PC design was "normal".

Joe

 

[Chuck(G)]

I firmly believe that having "grown up" on the IBM mainframe has made it nearly impossible for me to get my head around the arcitecture of the microprocessor as it relates to the machine/assembler code - especially the instruction set. Maybe had I never seen the mainframe, I might think the PC design was "normal".

Oh, after the first dozen or so instruction sets, it doesn't seem so strange--and that applies to the old IBM mainframes as well. What does the 1401 have in common with the S/360? Pretty much nothing--other than being able to drive a 1403 printer.

Some of the MCUs out there are more or less along the mainframe type architecture. Consider, for example, the PIC32 family. Based on the MIPS R4000 series. A couple of members have more memory under the epoxy than that old 360/40 ever did--and a very mainframe-like instruction set. The ARM ISA is a very typical RISC one.

The PC world is unlike any other in that there are various vendors making hardware--including the CPU. Since it's all non-centralized bleeding edge progress, you get sort of a "survival of the fittest and cheapest" evolution.

I don't think that, had Intel had a clue about where all of this microprocessor stuff would take us, that the x86 ISA would have hung on for so long. The 432 was a sign of an attempt to get away from that, as was IA32.

But we're still sticking with the 8008 ISA model core after more than 40 years.