SweetLow

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

For 9x modern version of hardware accelerated access interfaces exists: Direct Draw DDI & Direct 3D DDI available in ME DDK.

Attention grabber? My friend, if you want to see what is attention grabber look at hidusbf... Yes, subject is not the last thing in my TODO list.

There is minor error in himemex, i described it on ru-board. I recommend you read there too.

As with any PM only drive - in Device Manager made it Removable, set letter, made it non Removable. And as drive can stopped and started in Device Manager - no reboot needed (if no swap file on this drive, of course). >It seems that this is the first full-fledged PSE ramdisk in history that installs and works directly under WINDOWS! The first PSE drive for Windows was made by Intel for Windows NT 4.0 ~ 25 years ago >It would be nice if someone (who already uses such hardware) checked this right away. You have to know already that I'am running one of my Windows 98 SE on Core i7 10700... >the question also arises of the compatibility of RAMDRV4M with more promising hardware There is no problem for compatibility for pure protected mode software. The problem of RLoew's solution is transition from real mode code that drives something to protected mode code that access memory and back. >and a message appeared on a blue background "Windows The volume that was removed had open files on it. Next time please check first to see if the volume can really be removed. Press any key to continue." Read readme... > Is it really in RAM? Read readme...

ramdrv4m - Universal RAM Drive for Windows 9x https://github.com/LordOfMice/Tools/blob/master/ramdrv4m.zip Features description: 1. Memory support above 4GiB (default mode). Primary purpose of creating this software. 2. A full-fledged 32-bit protected mode driver. 3. High speed of operation. 4. Can utilize RAM Drives created in memory by other software. In particular, it is compatible with RAMDSK32/64 from RLoew. 5. It consumes only 4MiB of virtual address space. In addition to the real memory used for RAM Drive itself, of course. 6. Works on Pentium and higher class processors (i.e. it does not work on 80486). As usual - readme is your best friend...

Ok.

Flashing to Quadro to work in 2000/XP? Something is very bad with your logic.

And what? You supported off-topic no matter am I admin or not.

Of course, but you wrote hard off-topic for THIS thread.