Jump to content

rloew

Patron
  • Posts

    1,964
  • Joined

  • Last visited

  • Days Won

    13
  • Donations

    0.00 USD 
  • Country

    United States

Everything posted by rloew

  1. Try the latest version 5.0. The older versions only supported English versions of Windows. I assume you got an error trying to install it. If the error occurred during use, please PM me.
  2. Device Drivers such as IOS.VXD and ESDI_506.PDR use 64-Bit Sector Arguments. The Interrupt 13 Extensions (DOS) also use 64-Bit Sector Numbers. The existing ESDI_506.PDR files, including LLXX's version and my High Capacity Disk Patch, ignore the upper 32 Bits. I created versions of my High Capacity Disk Patch and BOOTMAN Overlay to use the additional 16 Bits supported by the 48-Bit LBA Protocol. The IO.SYS and VFAT.VXD Filesystem Drivers use 32 Bits. I altered the way Logical Sector Numbers are mapped to Physical Sector Numbers. This allowed me to create Partitions of up to 2TB starting above the 2TB limit. 24 Partitions can be defined to provide a total space of 48TB. It may be possible to redo Cluster mapping. If so, the size of a single Partition could be increased to at least 32TB using 256 Sectors per Cluster. I have already developed Patches for IO.SYS and VFAT.VXD that support 256 Sectors per Cluster.
  3. I tested Fast Defrag 2.3.1 (reports 2.3) with my Patch to see if the problem was memory or the MaxPhysPage workaround. I did not get error messages but the Cleaning Command would not display it's wait message and would never complete when there was too much memory. Between 1280MB and 1664MB it would work once. With 1664MB or more RAM, it would never work. This indicates that Fast Defrag has a problem handling large amounts of RAM. The other two Programs have problems when used as a workaround. These problems do not exist when using my Patch instead of a workaround. The problems are not related to the amount of memory. My Patch enables all RAM to be used so MaxPhysPage is not needed. This eliminates the issue with MSCONFIG.EXE Since the Patch enables all RAM to be used, there is no reason to use XMSDSK for Swap since better performance would be obtained by disabling Swap entirely.
  4. That might have been OK if I had a lot of business customers. So far all of my customers have been home users. Maybe, but then there would be no point in developing Windows 9x Patches. I could work on the 2TB limit in Windows XP and Vista instead.
  5. SATA uses nearly the same commands as PATA so it is subject to the same issues as PATA. Most SATA controllers come with their own drivers so 48-Bit LBA support depeds on the driver used. Being a newer standard, it is more likely that a SATA driver would support 48-Bit LBA but there are no guarantees expecially with older drivers. Some motherboards with SATA built into their chipsets are compatable with the ESDI_506.PDR driver. If ESDI_506.PDR is used then there will be no support for 48-Bit LBA. In addition, the MSHDC.INF file will incorrectly configure some of these SATA drivers causing problems especially when IDE and SATA drives are used together. In anticipation of the 2TB limit being reached, I have developed true 48 Bit versions of my Patches and a couple of workarounds to enable Windows 98 to utilize up to 52TB.
  6. I haven't experimented with it so I don't know if the power management handler causes any problems. In normal operation it should have no effect. It might make a difference when suspending or hibernating. Of course it is larger and uses slightly more resources. It is an update. All changes made between 2222 and 2225 are present.
  7. The difference between the 2225 and 2226 versions is as follows: Several routines were moved from the PCOD Segment to the LCOD Segment so they would be preloaded. A Power Handler is registered that allows the Virtual Power Management Device to flush the Driver.
  8. The ECS GEFORCE 6100SM-M Motherboard is a nVidia MCP61S Based system for the AMD CPU. The manual say it can support up to 16GB of RAM using two slots. I have 2x2GB of RAM installed totalling 4GB. The BIOS has a setting that determines the limit of 32-Bit RAM. Additional RAM is shifted above 4GB into the 64-Bit Address Space. The setting is a 8-Bit HEX value that sets the limit in 16MB increments. The default is C0 which provides 3GB of 32-Bit RAM. With the on-board video disabled, I was able to set the value to E4. This provides 3648MB. 1MB and 64K are reserved by the BIOS leaving just under 3647MB. I was able to run my modified Windows 9X using this setting.
  9. With the proper Patches, Windows 98/SE/ME can run as close to 4GB as your Motherboard will map to the 32-Bit Address Space. Most Motherboards will only map 3GB to the 32-Bit Address Space pushing any additional memory above the 4GB boundary. I found an ECS Motherboard that allowed me to tweak this limit, allowing me to run Windows 98/SE/ME with 3647MB of RAM.
  10. The unpatched ESDI_506.PDR driver checks if the sector number is within the 28-Bit range. Whoever designed the driver never wrote the code to handle higher sector numbers, or reject them. The code falls through to the older CHS algorithm. The CHS code does the math using unintialized geometry and 16-Bit cylinders to come up with settings that are sent to a drive which has never been initialized for CHS. The end result is a complex pattern of accesses over a portion of the 137GB range, intermixed with disk errors.
  11. Just because you don't INTENTIONALLY write to a Partition does not mean writes don't occur. Win 9X creates RECYCLE bins, WinME creates restore points, and Win XP writes Disk Management info, without user interaction. This type of damage can be very localized and not show up unless you test every byte of every file in every Partition. The unpatched ESDI_506.PDR does not simply wraparound when crossing the 137GB boundary but jumps around to different areas in a complex pattern.
  12. Motherboard chipsets that have SATA integrated into them, rather than a separate chip, often appear to Windows 98SE as additional IDE controllers. Windows 98SE does not correctly configure these additional controllers causing lockup during boot. So far I have only resolved the problem for the MCP61S Chipset.
  13. Even a Patched Windows 9X System is not safe if the BIOS does not support 48-Bit LBA. During Startup, Windows 9X uses DOS and the BIOS to load software and update system files (WININIT). It also uses the BIOS in Safe Mode or Compatability mode. Windows XP and Vista also have to use the BIOS to load their Kernels and Disk Drivers during Startup. This leaves a window of vulnerability in which any Writes to the higher partitions could corrupt data in the lower ones. Since the damage could be just a few bytes, as occurs when Windows XP tags an extended partition table entry, the damage may not be obvious Neither LLXX's Patches nor my High Capacity Disk Patch solve this problem. I wrote a separate package called BOOTMAN for my customers to provide an overlay to the BIOS to provide the necessary support.
  14. The problem is not in Windows, when it is Patched, it has no problem even when the BIOS does not support 48 Bit-LBA. The problem occurs in the early boot phase when Windows loads itself, runs SCANDISK or does Real Mode tasks such as WININIT. Safe Mode or running in Compatability Mode will also fail since it uses the BIOS code. Programs run in Real Mode, such as DOS, FDISK and the Windows Install CD will also fail. Most Disk Management tools use System Calls to access Hard Drives. They do not know anything about 48-Bit LBA mode, so they should work. Some may simply overflow from working with drives larger than they were tested with. Partition oriented tools such as SCANDISK and DEFRAG are affected by Partition size rather than Physical Hard Drive size. My Patch works in a similar manner to LLXX's. The difference is that I do not provide the Drivers but Patch whatever is there. This avoids any issue of Microsoft Copyright problems. Ontrack does not appear to support 48-Bit LBA properly and may disable BIOS support, if present. As mentioned above, BIOS or DDO support is required for safe operation with large Hard Drives. Ontrack does not appear to do sector shifting as some older DDOs did. These older DDOs caused serious problems since the Drives became unreadable if moved or if the DDO was removed or damaged. Being unable to get any of the Hard Disk Vendor DDOs to work and wanting to work with my own Multi-Boot Manager, I wrote my own DDO called BOOTMAN. It only provides 48-Bit LBA support, without a lot of bells and whistles, and comes in different versions for different needs. One version is loaded from a Floppy Disk so it can work with any Boot Manager since nothing is changed on the Hard Drive.
  15. I ran some experiments on OnTrack and was unable to get it properly support 48-Bit LBA. As you found out the hard way, it is not safe to test 48-Bit LBA support on a Hard Drive by writing test files above the 137GB Limit while having important files below the limit. BIOS issues, bad DDOs and Windows XP RTM, and to a lesser extent Windows 9X, will write data intended to go above the 137GB limit to other locations below the limit destroying the data you thought was safe. The new files are probably mostly still OK. You would have to read them with the same bad driver and get around the probably corrupted partition table. You will need the help of the CIA to get back any of your old data. I wrote my BOOTMAN Package to provide the necessary support that older BIOSes, and some buggy newer BIOSes, lack. It is compatable with LLXX's files and should work with the Autopatcher. I have no problem with new threads for these subjects. Links to them would of course be appreciated. It was a recent posting about my BOOTMAN Package that appears to have triggered these discussions when people saw my new RAM Limitation Patch on my website.
  16. I have written a set of Programs that add to or replace the BIOS Hard Disk Drivers, providing 48-Bit LBA Support. If your BIOS does not support 48-Bit LBA and a BIOS update is not available, one of these programs will provide the necessary support. Although designed to work with my High Capacity Disk Patch, they will work with the LLXX files. Rudolph Loew rloew@hotmail.com
  17. More elegant maybe, but it would require a major redesign. A new partition table format would be required making it incompatable with all existing operationg systems. Splitting the drive using a DDO and a Patched ESDI_506.PDR file remains compatable with existing DOS and Windowx 98/SE/ME systems. Unsupported systems will still see the first 2TB.
  18. Dear erpdude8, I am aware that the latest version for Windows 95 OSR2 is 1119. I have successfully patched all of the OSR2 versions. I added support for version 1111 for users of the original Windows 95. I have not gotten involved with recommending upgrades as that information is available from Microsoft. I support all of the readily available versions with my HDCP. Sometimes an upgrade can have unintended consequences. Only my new >2TB Patch requires an upgrade from the original versions. I only recently mapped out the actual differences between the 2222, 2225 and 2226 versions. So only now can I properly support 98SE users with respect to which version to use.
  19. My High Capacity Disk Patch instructions and support programs are only provided in English. The Patch itself works with all localized versions of ESDI_506.PDR versions 2186 and 2225. It should work will all others as well. If the Demo Version can patch the file, the Full Version will also. I added support for the original Windows 95 (ESDI_506.PDR Version 1111) also but do not have a setup to test it. The patch also removes some bad code that may be causing the problems known to exist with that version above 32GB.
  20. Not yet. Should be available before the end of the decade. But I have an ESDI_506.PDR Patch for it. Most of the new code has already been tested using a smaller hard drive. It will be one of a number of Patches I am working on for the future, building upon my original High Capacity Disk Patch and an Encrypting Disk Patch I released recently.
  21. It would not be hard to modify ESDI_506.PDR to combine a Master and Slave Drive into a single drive. I have already done the reverse (split one large hard drive into smaller drives) in the experimental versions of my High Capacity Disk Patch for Hard Drives larger than 2200GB. The D and E drives would have to be inaccessible, or at least not mount any parititions, as they would conflict with the partition on the virtual F drive. A matching DOS DDO, similar to my BOOTMAN packages, will be required for DOS support and to pass the protected mode validation precedure in the IOS.VXD and ESDI_506.PDR code.
  22. Repeating my previous warning: Dear Eidenk,Sorry, you were sick the last few days. Your experiment demonstrates how people can be fooled into thinking that everything is fine while their data is being turned into mush. The corruption is not always obvious and may not even show up until you access some vital data that has been overwritten. I hope that people who read your last two posts will take my warning seriously and take the necessary measures before they lose irreplaceable data. Dear Azaqahl, The bug is in the VIADSK.MPD file. I have only seen one version so far. I have a Patch for this file. I have not advertised it on my website since no one had shown an interest in it. Interestingly enough the bug appears only when using hard drives that actually follow the ATA-7 Standard. Many hard drives do not follow the Standard and work with the VIA driver, which is probably why they never found the bug themselves. The Western Digital drives I have tested fall into the latter category. This may change in the future if they decide to correct their non-compliance. Note: SCANDISK may not detect this problem. Depending how the partitions are laid out, SCANDISK may not access the sector in a way that triggers the error. Dear it_ybd, My approach allows up to 2TB which is also the limit for SCSI drives. The Trackdisk64 protocol effectively provides 55-Bit Support. I bought the X-Surf Card for the LAN. The IDE Port was a bonus, and a challenge. It supports Trackdisk64. I added my protocol to it and added the 48-Bit LBA Support it lacked. Yes, this is off-topic. You may want to correspond directly with me at rloew@hotmail.com. Rudolph R. Loew http://rloew1.no-ip.com
  23. Dear azaqahl, SCANDISK does not know or care about 48-Bit LBA. It's limitation appears to be an issue with memory allocation. It's limit is actually 500MB below the 137GB limit. Some people have reported limits as low as 64GB. Upgrading or replacing your ESDI_506.PDR will not help. Even using a PCI Card or an external USB drive will not help. The only good news is that the Windows version of SCANDISK will fail immediately without doing any damage. The same for DEFRAG. This might not be true for third party SCANDISK and DEFRAG programs. The Windows ME versions are not any better. If your hard disk controller driver supports 48-Bit LBA you can place a 136GB partition anywhere on the hard drive you want. I haven't seen Tihiy's SCANDISK so I cannot comment on it. I haven't tried Diskeeper but you may want to look at my response to Eidenk later in this post. DOS SCANDISK will work with larger partitions PROVIDED that the BIOS supports 48-Bit LBA. Performing SCANDISK in DOS on a system, who's BIOS does not support 48-Bit LBA, whether voluntarily or as a result of a bad shutdown, virtually guarantees corruption. This is true regardless of the partition sizes if any data is written past 137GB on the physical drive. The VIA driver is not compliant with the ATA-7 Specification. A drive that is compliant with the specification will appear to have a read/write error when a specific sector is requested. Since the sector can be accessed in more than one way, the error may seem intermittent. I have seen this problem on Seagate drives and there may be others. I have written a Patch for the VIA driver but have not advertised it on my website since no one has shown an interest so far. Dear Eidenk, Did you upgrade Windows ME to support 48-Bit LBA (Patch, IAA, VIA, PCI Card, etc.)? If you were in Safe Mode, does your BIOS support 48-Bit LBA? If so, then Diskeeper may have a serious flaw. One corrupted, recovery of the lost or damaged data is usually very difficult. I am not surprised that your attempts at recovery have had poor results. Recovery software is somewhat effective in recovering deleted files on a partition that is not significantly fragmented, but not good for much else. A recovery expert is usually required to recover much from this type of corruption. Rudolph R. Loew http://rloew1.no-ip.com
  24. Dear Petr, I agree that 0xFFFFF00 is a safe limit. I've even used 0xF000000 in some applications, which is still more than a 120GB Hard Drive. The ambiguity is in paragraph 4.2.2 which limits the requested LBA number to less than words (61:60) rather than the last sector accessed. One hard disk manufacturer used this interpretation, the others don't even meet this requirement. Using a switching threshold does not require reading either (61:60) or (103:100) so that paragraph is not applicable. Only if there were hard drives with0xFFFFF00 < Sectors < 0x10000000 would this be necessary. Dear it_ybd, There are two approaches to overcoming the 4GB limit. I wrote one that patches the drivers and works with AmigaOS 1.3, 2.0, 3.0 and 3.1 and the X-Surf Card. The Amiga community developed a number of extensions to the driver interface standard. One of these is the Trackdisk64 protocol that provides 64 Bit Byte offsets. Support for larger hard drives was integrated into the AmigaOS 3.5 and above. Many of the files are on Aminet but I am not sure if enough of them are there for a complete solution. Rudolph R. Loew http://rloew1.no-ip.com
  25. Dear Petr, I saw your solutions to the Award 32GB and 64GB problems. Having a Tyan S1590 motherboard, I encountered the 32GB problem until they updated it. They stopped supporting it in 1999, before the 137GB limit was overcome. I developed a fix for the 137GB limit but have only tested it in the S1590 BIOS. Most of my experience is on the Amiga computers which I still use for some projects. There the biggest limit was 4GB. Your original post suggested switching modes at sector 0xFFFFF00 which I used in some versions of my Patch. The ATA-7 specs are a bit ambiguous on that point. None of the hard drives I have tested require switching at that sector. VIA chose an even higher switchover point which makes their driver faulty. I haven't seen "warez" people posting in this forum but one I know of is a member and was browsing this topic earlier this morning. Credit card payments add cost which would raise the price. Paypal does not allow separate charges for cash and credit. Western Union is a last resort. So far only person paid me through Western Union. He lived in Poland and wanted the Patch immediately. Rudolph R. Loew
×
×
  • Create New...