SweetLow

Definitely some problem exists with PS/2 handler. What is the result on unpatched (original) HIMEM.SYS? And to check more precisely it is better to run himem in verbose mode: device=himem.sys /v http://sweetlow.orgfree.com/download/a20speed.zip The modern version of this kind of software.

1. Instead of trying to setup RLoew SATA patch you probably need to setup something like "Legacy" or "Compatible" for chipset ATA Controller in BIOS. 2. Why is this thread in THIS subforum?

Or just use boot menu "Command Prompt Only" item what I suggested few posts above. But no luck.

Why did you use plural noun? I'm alone. Yes, I slightly confused too. Now even AI bots can follow the thread of a conversation better...

1. You didn't answer my previous question is BIOS handling your USB drive. It's crucial for direction of debugging. 2. https://github.com/LordOfMice/Tools/blob/master/rmmremove.zip http://sweetlow.orgfree.com/download/usb20_win9x.zip

Ok, MS-RAMDRIVE is bad case. But there are two other names treated as RAM Drives - RDV and VDISK. And as they are shorter than 11 characters - any name RDV* or VDISK* are treated as RAM Drives too... Yes in general, but IDK such software for XP.

Two fixes, I suppose now. Every one should help, but using both even better.

Do not delete anything. Set the name you wish from begin of "MS-RAMDRIVE" and add spaces to get string with 11 characters (exactly the "MS-RAMDRIVE" and DOS file record name length). I.e. replace "MS-RAMDRIVE" to "RAMDRIVE ".

No. Try to search yourself and don't forget that VMM32.VXD is actually packed collection of system VXDs

https://github.com/LordOfMice/Tools/blob/master/ramdrv4m.zip Fixed bug in detection of FAT32 support.

1. With high probability this device handled by BIOS. There is driver that remove such devices. 2. We have EHCI controller. There is driver with forced EHCI hand-off.

I didn't talk about MS-DOS. Read the whole statement, don't skip some part.

Yes, it is NOT normal. It shoud be FAT32 and grow as RAM added. Ok, try to setup this registry file, it is forcibly enable FAT32: REGEDIT4 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\RAMDRV4M] "Config"="Home.Default" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\RAMDRV4M\Home.Default] "UseFAT16"=hex:00

It is not correct question precisely. Under Windows ME on RAM drive you should get FAT32 volume (not FAT16) by default with size ~4.5 GiB on 8 GiB RAM. 2GiB swap file is just maximal size of swap file under Windows 9x AFAIK, but to get such size you have to set it directly, by default swap file has volatile size and is less than 2GiB.

Thank for testing. Looks like some subtle bug exists in Windows 98/SE: too early shutting down the drive with swap file and probably it is masked by the fact that usual drives much slower than RAM drives.

1. It's definitely problem with this device. 2. OS is loaded successfully really. 3. Does this devices work correctly if you hot-plug it in running OS? 4. Is this device visible in DOS (Command Prompt Only)?

It's one of the startup options for booting system - Logged. And I assume there is descriptions in the Internet.

On Windows ME? Glad to hear. P.S. Do you get Blue Screen message when try to shutdown your system when swap file locates on RAM drive?

Insulate the problem point by bootlog.txt

http://sweetlow.orgfree.com/download/esdi_506.zip Patches for ESDI_506.PDR from Windows 98SE [98SE] / RLoew's Terabyte Plus Pack 2.1 [TBP2.1]. Fixes: 1. [TBP2.1 - BigHDD] Handles drives with LBA48 support using algorithm from Windows NT: LBA48 commands are only used for drives that really need them, i.e. >= 128GiB, for drives < 128GiB LBA28 is used. Needed as work-around the rare situation of badly functioning hardware that reports support for LBA48 commands, but in reality does not process them. 2. [TBP2.1 - SATA] Interrupt handler: - Based on code from RLoew's TBP3.0. - For dedicated interrupts (Legacy ATA controllers) the code is completely identical in behavior to the original one (no unnecessary access to ports). - DMA error flag is preserved, only the Interrupt flag is reset. 3. [TBP2.1 - SATA] Data synchronization with BIOS: - LBA usage is enabled for drives with LBA support without any additional checks, drives without LBA use the old (full) algorithm - rollback to PIO if DMA fails 4. [98SE] Driver retrieves shared interrupt flag not from the CONFIGMG shared interrupt flag, but from the level/front interrupt flag. The CONFIGMG incorrectly changes the shared interrupt flag for multi-function devices (which are the vast majority of standard PCI ATA controllers). 5. [98SE] Fixed minor bug of non-saving register with the value of error of command execution for drives with removable media and media status notification enabled. 6. [98SE] Changed drive characteristic flags for the default record. Additions: 1. [98SE] Added IOR_IDE_PASS_THROUGH request processing for ATAPI devices. Also this request is correctly processed for ATA devices with sector size other than 512 bytes. Allows you to execute drive identification commands and SMART commands for such drives. It is recommended to use together with updated SMARTVSD.VXD for full functionality. Fixes 2 - 6 and Addition 1 are non-specific to TBP2.1. Corollary projects updated accordingly: https://github.com/LordOfMice/Tools/blob/master/atanames.zip - Right names of ATA drives plus version of device firmware in Device Manager for Windows 9x/ME http://sweetlow.orgfree.com/download/smartvsd.zip Patches for SMARTVSD.VXD - works for any combination of ATA channels and devices on these channels and more

Hardcoded not value, but values. Old BIOSes just do not "know" how to display anything different from standard modes and just select one of them. The only variant is to replace BIOS code to something else like UniVBE.

It depends of software you try to run, to be precise. Few options: 1. HARDWARE Registry Subkey (HKLM\Enum\). Search registry keys with name == "PORTNAME" 2. BIOS Data Area, 40h:0 - 40h:7, 4 WORDs, BIOS known COM port base addresses.

You probably misunderstand the problem. Software get the right mode (which it requested), but hardware output to monitor has different mode (resolution) because between software visible surface and hardware output locates the scaler. The question is how to eliminate it.

1. It is not Nvidia specific behaviour. BIOSes of old ATI cards setup 1280*1024 on DVI output for example no matter what is native resolution of monitor (if it is above or equal to 1280*1024, of course) and requested video mode. 2. Only patch BIOS or direct program GPU.

Yes. But I assume "label" command does its work still... If you will point me why do you need variable label when driver create volume I do option for this. > Do you need a separate 16-bit client? No. Drive can or can not be mounted before. readme related options: - checking for third-party drives in memory at start address: "CheckExternalVolume"=hex:FF enabled by default. If a drive is detected, there are two options (by configuration) - it is either used or left under the control of the of the old software, with use option enabled by default: "GrabRMVolume"=hex:FF "GrabExternalVolume"=hex:FF. The first parameter defines the use of known DOS drives (e.g. RAMDSK32/64), the second - all other drives (no examples yet) i.e. GrabRMVolume - use DOS mounted drive, GrabExternalVolume - use unmounted volume, no matter how it was loaded into memory