Dave-H

Sounds good, but I must say that I never thought that the diskpart delay was a problem. I only mentioned it at all because on my system at least there was an apparent pause in the script at one point which wasn't explained, which might lead impatient people to think that something had gone wrong! It's only 10 seconds at most though.

Yes, I remember AGP aperture settings being critical as well, but that was with my old motherboard. My present one isn't AGP, it's PCI, PCI-X, and PCIe. I certainly had the AGP version of the X850 working very happily with my old motherboard for several years, and the 256 MB of memory didn't seem to be a problem. I even for a while had an AGP Nvidia card installed on the old motherboard until the fan died, and that had 512 MB of memory! All made possible by the RAM limitation patch of course.

My "new" X800 card arrived today, and I put it in in place of the X850. It found the drivers and seemed to work fine, but it's still crashing exactly the same! I then did some more experimenting. I put the X850 back in, and removed the Nvidia card. Still crashing. I then moved the X850 into the 16x PCIe slot where the Nvidia card normally lives. Still crashing. So - 1/ It isn't a hardware fault in the card. 2/ The presence of the Nvidia card doesn't seem to affect things. 3/ It doesn't matter which PCIe slot it's plugged onto. I still suspect a memory issue. Not main RAM of course, some other low level memory issue that didn't happen with my previous motherboard, but does with this one. I am using the RAM limitation patch from @rloew, which may have an effect, but Windows 98 wouldn't work at all without it I suspect!

OK, I've been through it and here are my suggested changes. The changes are marked in red so you can see what I've altered, and because of that I've converted it to a Word document, which I hope you can read OK. ReadMe.doc

The only thing I saw immediately is that the readme still refers to "mkdualmode.cmd" in a number of places, which should be "mkdualdisk.cmd" of course!

Yes, that's good! It is strange that the pause is a lot longer going from 512 to 4096 than is is going the other way. Anyway, it doesn't matter, and the output does now tell you that there's going to be a pause, so that's fine.

Hmm, mine's nowhere near as quick as that! Running diskpart from the command prompt it goes to the diskpart prompt almost immediately. On running "rescan" there is about a four second pause before the next output appears, but only the first time it's run. If rescan is run again it's instant, the pause only re-appears if diskpart is closed and run again.

Yes, that's good, as the whole output now fits in the window without scrolling. There is a definite pause after "OK, written 4096 bytes at offset 0" before "Please wait while DiskPart scans your configuration..." comes up. It's about 10 seconds when going from 512 to 4096, and about 6 seconds when going from 4096 to 512. I've only tried in on XP as that's what I happen to be running at the moment.

The only place there seems to be a bit of an unexplained pause now is after "OK, written 4096 bytes at offset 0". Not really a problem though, it is quite short. I assume this is where DISKPART is being run. The shorter the output the better I agree.

The actual history is that I had a single AGP ATI X850 card on my old motherboard, and when I updated the motherboard to a PCIe one with no AGP of course I had to change my video card. I bought a cheap AMD card and that worked fine on XP (and later also on 8.1) but of course there were absolutely no drivers for Windows 98. After messing around with modified VGA drivers for 98, which gave me the resolution setting I wanted but with very slow screen refresh rates, i decided to try and find the PCIe version of my old X850. This I did, and I used that for a while, but I wasn't very happy with its performance, especially on 8.1 doing HD video editing. I then realised that it was possible to run two different cards in the two PCIe slots on my board, and as I wanted to keep the X850 for Windows 98, I went out and bought a cheap NVidia card, which I fitted in the 16x slot for best performance, and put the X850 in the remaining 4x slot. I didn't believe that it was possible to use two cards of the same brand with very differing ages, as they would surely use different driver files with the same name, which would inevitably cause a lot of problems to say the least! As it is, I can now use either card in Windows XP or 8.1, but only the X850 in Windows 98, as there are no 98 drivers for the NVidia card of course. The NVidia card has the standard MS VGA driver loaded in Windows 98, and is disabled. As I said earlier, the crashing on the X850 driver was I'm pretty sure occurring even when it was the only card fitted (in the 16x PCIe slot) so I don't think that the presence of the NVidia card has any bearing on the problem.

I think it would be good if it worked faster as a result, but as everything it does is essential I assume, it would take the same time to run even if it was less verbose, so is there any advantage? I would have thought that it's better if people can see that it's actually doing something, rather than having pauses with apparently nothing happening.

Hi again jaclaz. I've now checked with the other machine, and I'm pleased to report that the switcher operates correctly on it, and it now sees drive E: which is the network drive as being in use, and therefore ignores it.

Yes, I'll wait and see now what happens with the other card. Hopefully I will get it at the beginning of next week. If it's OK I think we'll have to assume that the first card just had a hardware problem. Incidentally, I meant to say in my last post that I'm pretty sure that it's not coming back with the standard VGA driver, as it still looks perfectly normal, in 1920x1080 with full colour depth. The square at the top left and the strange mouse cursors are the only sign that there's anything still wrong. I already have an NVidia card installed in the other PCIe slot, so I can't really add another one as there would surely be a clash of driver files on Windows XP and Windows 8.1, even if I had no NVidia drivers installed on Windows 98.

Running SVGACOM doesn't clear the display corruption I'm afraid. As you can see, the square of rubbish is still there in the top left corner. I have now decided that I need to eliminate the card itself being the source of the problem. Although it does work fine in Windows XP and Windows 8.1, I did read somewhere that they run hotter under Windows 98, and if the hardware is more stressed that could be the issue. I found another used card on eBay for a very cheap price, so I have ordered that. It's an X800 card rather than an X850, but I'm hoping it's close enough to just directly substitute it without any driver complications, as the driver is for both. That will hopefully eliminate whether it is actually a hardware issue.

OK, that has fixed it! The command window is closing again at the end though, instead of going back to the command prompt. One thing I have noticed is that Windows 8.1 seems to feel the need to scan drive I: quite often when it mounts. Why I'm not sure, as looking in the event log it never seems to actually find any problem! The scan is of course almost instantaneous anyway as it's such a small volume. The only other thing I must now try is to check that it all works OK on the other 4096 interface only machine, to make sure that there are still no complications caused by the network drive.

No, sadly your tool restores exactly the same garbled desktop. I'd certainly be using it if it didn't! I think once the "damage" has been done, the desktop cannot return to normal except by a reboot. When it's come back in the garbled state, whether it's restored by your tool, the ATI Control Panel, or by putting the machine to sleep and waking it again, it never looks right again, even though it is apparently back at its normal settings. The differences are the mouse cursor display (which may be a clue!) and the box of rubbish at the top left, which stays there, although proportionately larger, even if you go to DOS. Only a restart will clear it. That looks like some sort of corruption in the RAM of the graphics card.

Yes it does indeed, thanks Drugwash! Actually after I used it I realised that in fact the ATI Control Panel has a hot key function which will do exactly that same thing, so I'm actually now using that! Now when the display suddenly vanishes to I don't know what, I can just hit Ctrl+F12 and bring it back again, albeit with the square of digital rubbish in the top left hand corner, and a big blurry mouse cursor in a grey square box, as per my original screenshot! I've no found any way of returning it completely to normal apart from a reboot, but at least I can finish what I was doing easily now before rebooting. I'm still no nearer to finding out why it's doing what it's doing though. It would be a help to find exactly what triggers the problem! I have a program called Registry Workshop, which has a pop out menu that allows you to select favourite registry locations. Getting that to pop out and double clicking on any of the entries crashes the display pretty reliably! The other crashes seem to happen quite randomly after using Explorer for a while to move files around and that sort of thing. I've never managed to provoke a crash by using any other program (so far!)

OK, tried that, and what's happening with "run as an administrator" is this - Vista , or later, ...OK, I am a local admin ..."DUAL" disk found as \\.\PHYSICALDRIVE5Disk is connected as 4096 bytes/sector* Volume 9 J RAW Partition 931 GB Healthy'dsfo' is not recognized as an internal or external command,operable program or batch file.'dsfo' is not recognized as an internal or external command,operable program or batch file. Checkpoint#1Press any key to continue . . .

Sorry for the long delay in replying again. I did manage to get the Asus ICM driver to work in Windows 98 after a bit of a struggle, but it didn't affect the problem I'm afraid. I've been experimenting with other earlier driver versions, but all the ones I've been able to find either have the same problem, or don't contain any hardware IDs for the card. I've tried manually adding the necessary information to the INF files, but without success. Catalyst 4.3, and possibly 4.4, are supposedly the last "proper" Windows 98 ATI drivers, but the card post-dates them. Catalyst 5.2 is a driver for ME which does support the card, but also crashes. I'm now working on the principle that it isn't actually a problem with the driver itself. It does install fine and works fine until you try something taxing, at which point it decides to switch spontaneously to some other output standard, which unfortunately my monitor can't display! It passes all the DirectX tests with flying colours, so it can't be that unstable.

Yes, changing the elevate.exe switch from -c to -k does exactly what I wanted! The window now stays open when the batch ends. I've tried just double clicking on the switcher file and that all works fine, which is good as it means it can be run from a shortcut, but there is a problem with right clicking and selecting "run as administrator". The command prompt window comes up OK after the UAC prompt is dismissed, it says what interface the disk is connected with, but then just outputs some lines that are too fast to read, and closes! Needless to say it hasn't done the switch.

That's all fine jaclaz, works a treat, both in elevated and non-elevated prompts! The only thing I would suggest is that when you are using a non-elevated prompt, a second command window opens when you dismiss the UAC prompt. That window closes itself when it's finished what it's doing and you "press any key to continue..." It might be nicer if it went back to the command prompt rather than just closing, so people could check its contents if they want to before closing it manually, especially considering that the first command window does stay open. I haven't tried just double clicking on the switcher file, or right clicking and running as an administrator. Would that now work? With regards to getting a bit of drive space back when using the 512 interface, I personally don't think that's important enough to complicate things over. I think we're only talking about a quarter of a gigabyte, and the disks being used nowadays are almost certainly going to be tens of gigabytes in size at least, so the extra would be a very small proportional increase in size. Especially as it will only work with one interface, I really wouldn't bother with it. As a matter of interest, if you did implement this, and the disk was being used on the 512 interface and data was written to the "extra" area, what would happen to that data when you switched to the 4096 interface? I assume it wouldn't be accessible, but would it be damaged? This has been a really fascinating exercise, and I've really enjoyed doing it!

Sorry for the delay, the site's been down again! I've tried the new version just in Windows 8.1 with elevated command prompts, and I'm delighted to say that it all seems to work perfectly, switching happily in either direction! This is the setup output - Microsoft Windows [Version 6.3.9600](c) 2013 Microsoft Corporation. All rights reserved.C:\WINDOWS\system32>cd\mkprilogC:\mkprilog>mkprilogPlease input an approximated size in Megabytes for the FAT12 partition,minimum 1, maximum 32...The image will be created in the same folder as this batchand will be named PriLog.imgPlease consider how in the a size roughly 7 times the size of this partitionwill NOT be accessible/usable normally, in other words the PriLog.img oncedeployed will reduce disk capacity by 7 times the size you input, exampleIf you choose 1 Mbyte, you will lose roughly 7 Mbytes...If you choose 32 Mbyte, you will lose roughly 224 Mbytes32Writing MBR at offset 0 ...... done.Writing the 512 bytes/sector bootsector BPB at offset 32768 ...... done.Writing the 4096 bytes/sector bootsector BPB at offset 262144...... done.Writing FAT tables incipit ...... done.Press any key to continue . . ..The image should have been created as PriLog.img, now you need tomanually dd it to the destination disk, a suitable command would be:dsfi.exe \\.\PhysicalDrive[n] 0 0 PriLog.imgMake sure that you use the RIGHT Disk Number [n], do check in Disk Manager.The disk can be mounted indifferently through the 4kb or the 512 bytes/sectorinterface to deploy the image.Once the image has been deployed you may need to disconnect and reconnect thedisk to have the FAT12 volume be recognized and mounted to a drive letter.Then you can go to Disk Manager and create a Primary partition, NTFS formattedextending on all the available space on disk (or on just a portion of it).The size of the NTFS partition you create must be at least 7 times the size ofthe FAT12 one.It is "better" to use a Vista (or later) OS to create the NTFS partition asthe partition would be better if Megabyte aligned.(or do it manually or use a suitable third-party tool) as the XP will align iton head/cylinder boundaries, whilst a MB-aligned partition will be faster onslow buses such as USB 2.0The partition and the NTFS filesystem MUST be created when the disk is connectedas a 4kb sectored device, this is NOT negotiable.Once the second partition has been created, and I repeat, this MUST be donewith the device connected as 4kb sectored, you can run the mkdualdisk.cmdWhich will modify the disk and create the needed EPBR's.Press any key to continue . . .C:\mkprilog>dsfi \\.\PhysicalDrive5 0 0 PriLog.imgOK, written 33554432 bytes at offset 0C:\mkprilog>mkdualdisk"DUAL" disk found as \\.\PHYSICALDRIVE5Creating a temporary copy of the MBRdsfo \\.\PHYSICALDRIVE5 0 4096 temp.mbrOK, 4096 bytes, 0.016s, MD5 = c5e2a6e6a72dd713bde01cef7939e4ddNow the extent of the FAT12 partition is 65472000001B8h: 44 55 41 4C DUAL000001BEh: 00 00 00 00 0F 00 00 00 3F 00 00 00 01 00 00 00000001CEh: 00 00 00 00 01 00 00 00 40 00 00 00 C0 FF 00 00000001DEh: 00 14 11 04 07 FE FF FF 00 00 01 00 00 0B 8D 0E000001EEh: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00The disk was recognized as created with the Prilog schemeCreating a temporary copy of the NTFS partition bootsectordsfo \\.\PHYSICALDRIVE5 268435456 4096 tempNTFS.bssOK, 4096 bytes, 0.000s, MD5 = 13193b512259ee7256e9a592720f4821Press any key to continue . . .and copying it to the filedsfo tempNTFS.bss 0 0 as4kbNTFS.bssOK, 4096 bytes, 0.000s, MD5 = 13193b512259ee7256e9a592720f4821Creating a copy of the 4kb bytes/sector NTFS bootsectorAnd modifying it to become the 512 bytes/sector NTFS bootsectordsfo tempNTFS.bss 0 0 as512NTFS.bssOK, 4096 bytes, 0.000s, MD5 = 4476465c2498dd63a3c97e8a17cb6d21Press any key to continue . . .Creating a copy of the 4kb bytes/sector EPBRand writing to it the values for the NTFS volumeOK, 4096 bytes, 0.000s, MD5 = fc86b746e3b8c6f0108aaf1a1ac6271aCreating a copy of the 512 bytes/sector EPBRand writing to it the values for the NTFS volumeOK, 4096 bytes, 0.000s, MD5 = 620f0b67a91f7f74151bc5be745b7110Press any key to continue . . .Now we write the sectors to the diskdsfi \\.\PHYSICALDRIVE5 0 4096 Prilog.mbrOK, written 4096 bytes at offset 0dsfi \\.\PHYSICALDRIVE5 29672 4096 EPBR1_512.epbOK, written 4096 bytes at offset 29672dsfi \\.\PHYSICALDRIVE5 258048 4096 EPBR1_4Kb.epbOK, written 4096 bytes at offset 258048Deleting temporary files ...temp.mbr deletedtempNTFS.bss deletedPrilog.mbr deletedEPBR1_4kb.epb deletedEPBR1_512.epb deletedPress any key to continue . . .C:\mkprilog>This is switching from 4096 mode to 512 mode - Microsoft Windows [Version 6.3.9600](c) 2013 Microsoft Corporation. All rights reserved.C:\WINDOWS\system32>I:I:\>switcherdaVista , or later, ...OK, I am a local admin ..."DUAL" disk found as \\.\PHYSICALDRIVE5Disk is connected as 512 bytes/sectorNTFS volume found as \\.\Volume{e308684d-bc26-11e4-bfa7-00304879f908}, drive J:* Volume 9 J RAW Partition 931 GB HealthyRemoving drive letter J: ...The current NTFS bootsector is NOT the 512 bytes oneswitching it ...dsfi \\.\Volume{e308684d-bc26-11e4-bfa7-00304879f908} 0 4096 as512NTFS.bssOK, written 4096 bytes at offset 0Please wait while DiskPart scans your configuration...Leaving DiskPart...* Volume 9 New Volume NTFS Partition 931 GB HealthyMounting the volume to a drive letter...Checking drive letters ...In use: C: D: E: F: G: H: I: S: W:Free : J: K: L: M: N: O: P: Q: R: T: U: V: X: Y: Z:Mounting volume to first free drive letter J: ...OK, done:* Volume 9 J New Volume NTFS Partition 931 GB HealthyPress any key to continue . . .I:\>This is switching back to 4096 mode, with is what failed before - Microsoft Windows [Version 6.3.9600](c) 2013 Microsoft Corporation. All rights reserved.C:\WINDOWS\system32>I:I:\>switcherdaVista , or later, ...OK, I am a local admin ..."DUAL" disk found as \\.\PHYSICALDRIVE5Disk is connected as 4096 bytes/sectorNTFS volume found as \\.\Volume{e308684d-bc26-11e4-bfa7-00304879f908}, drive J:* Volume 9 J RAW Partition 931 GB HealthyRemoving drive letter J: ...The current NTFS bootsector is NOT the 4kb bytes oneswitching it ...dsfi \\.\Volume{e308684d-bc26-11e4-bfa7-00304879f908} 0 4096 as4kbNTFS.bssOK, written 4096 bytes at offset 0Please wait while DiskPart scans your configuration...Leaving DiskPart...* Volume 9 New Volume NTFS Partition 931 GB HealthyMounting the volume to a drive letter...Checking drive letters ...In use: C: D: E: F: G: H: I: S: W:Free : J: K: L: M: N: O: P: Q: R: T: U: V: X: Y: Z:Mounting volume to first free drive letter J: ...OK, done:* Volume 9 J New Volume NTFS Partition 931 GB HealthyPress any key to continue . . .I:\>Unfortunately we're not quite there yet as I then tried with a non-elevated command prompt and got this in the second window - Vista , or later, ...OK, I am a local admin ..."DUAL" disk found as \\.\PHYSICALDRIVE5Disk is connected as 512 bytes/sectorNTFS volume found as \\.\Volume{e308684d-bc26-11e4-bfa7-00304879f908}, drive J:File not found - I:\ELEVATEDCannot access file I:\+ECHO is off.Houston, we've had a problem.The current NTFS bootsector is already the 512 bytes oneCannot access file I:\elevatedECHO is off.Mounting the volume to a drive letter...Checking drive letters ...In use: C: D: E: F: G: H: I: J: S: W:Free : K: L: M: N: O: P: Q: R: T: U: V: X: Y: Z:The parameter is incorrect.Oh, oh, something prevented the correct mounting to K: ...Cannot access file I:\elevatedECHO is off.Press any key to continue . . .Looking at it, I immediately thought that there must be a typo somewhere in the switcher file resulting in an invalid path, but I can't see any obvious one.

Well I don't understand what's changed. All I did was change the ":do_switchDA" section in the switcherda file to your new version, and add the lockdismount file to drive I:. I ran the commands you stated, and got this - Microsoft Windows [Version 6.3.9600](c) 2013 Microsoft Corporation. All rights reserved.C:\WINDOWS\system32>diskpartMicrosoft DiskPart version 6.3.9600Copyright (C) 1999-2013 Microsoft Corporation.On computer: ASHFIELDCOURTDISKPART> select disk 5Disk 5 is now the selected disk.DISKPART> list partition Partition ### Type Size Offset ------------- ---------------- ------- ------- Partition 0 Extended 4096 B 252 KB Partition 1 Primary 254 MB 256 KB Partition 2 Primary 931 GB 32 MBDISKPART> exitLeaving DiskPart...C:\WINDOWS\system32>I:I:\>lockdismount -lock 5 dsfi \\.\PhysicalDrive5 33554432 4096 as4kbNTFS.bssLocking volume I: ...FAILED (Access is denied.)Operation failed!Please close all files/applications accessing the affected volumes and try again.I:\>diskpartMicrosoft DiskPart version 6.3.9600Copyright (C) 1999-2013 Microsoft Corporation.On computer: ASHFIELDCOURTDISKPART> rescanPlease wait while DiskPart scans your configuration...DiskPart has finished scanning your configuration.DISKPART> select disk 5Disk 5 is now the selected disk.DISKPART> list partition Partition ### Type Size Offset ------------- ---------------- ------- ------- Partition 0 Extended 4096 B 252 KB Partition 1 Primary 254 MB 256 KB Partition 2 Primary 931 GB 32 MBDISKPART> exitLeaving DiskPart...I:\>

I had rolled back the "official" KB3013455, but I reinstalled it before applying the new version. All fine and the fonts all look great again, although I did have to re-do the ClearType tuning. Thanks so much from me too harkaz!

Yes, I wondered about that too. Wouldn't it have been better to keep the same version number as the faulty version of the file on the "fixed" version? Then Windows Update will just think you've got the "official" faulty version installed.