rloew

Limiting it would be a bad idea. I suspect that most of the users of a SP will be novices and others who are not even members. When I read this thread, I see that Guest users make up most of the people reading this thread at the same time. It may be simple but in the long run it leads to people creating different versions to accomodate their needs and publishing them if others have the same issues. Soon you have 40 alternative SPs instead of the 4 you kept referring to recently. This just leads to confusion and even more questions from inexperienced users.

rloew ... Quick question. How large is the registry export for that registry with 18 MB system + ?? MB user ? Also could you mention which machine it is ( from the Day-to-day thread ) so we can know the hardware RAM, CPU, etc ? Based on the 2011 Date shown for post #79 in this Thread, I assume it was my 16GiB RAM System "Rloew (2)" using an AMD ATHLON X2 6000+. I don't recall the size of the exported Registry. I built the Registry, tested it, exported it, rebuilt it, tested it, deleted all of the files, and put back the original Registry, all in one day. Most of the Registry was confined to a small number of Keys, with thousands of Text Values in each. Maybe this is why I was able to rebuild the Registry while others were unable to do so. The level of complexity was much lower. I solved the Registry Size issue in 2009 as reported by Dave-H. See Post #63. I created a modified version of REGEDIT that runs offline like REGEDIT does when run in DOS, but can be run in Windows.

The problem I found isn't caused by the Registry not loading. It is caused by where and how much RAM is used by the loaded Registry. It is affected also by the Network Drivers, not by Video. I added the /M Option to my RAM Limitation Patch to correct this problem. I was then able to load a Registry with an 18MB SYSTEM.DAT File.

CD/DVD and USB use different code in the BIOS, so their issues are different. To access a Hard Drive from a Bootable CD/DVD or Bootable USB, my DDO can be installed on it. Making a CD Boot Option from my Hard Disk DDO would have complicated it significantly as CD Emulation support would have to be added. I'm not sure what you are saying. It is possible to overlay the BIOS in the shadow RAM but this would be unique to each BIOS. I do have an IO.SYS based mini-DDO I use on my Laptop that supports one Hard Drive in a fixed controller. It is not MBR based.

My DDO allows you to choose to insert a Floppy Disk which can be booted from, with the DDO active. If you are booting from multiple drives the DDO can be placed in each one. I probably could customize the DDO to run with XOSL or Bootit-NG or almost anything else. It is fairly small and does not use a secondary MBR Table. Removal is not hard, but is unnecessary as it automatically drops out if placed in a Computer that does not need it's support.

I'm not sure about having the instructions only on the homepage. It is usually a good idea to have at least a README file if not an Information Dialog. I extracted your package looking for the instructions having already downloaded it. I didn't find the instructions. Remembering that there was a significant amount of info on the homepage, I went back there to get the instructions. I would recommend reconsidering your position if incompatabilities are found between Device specific Drivers and the underlying USB Controller Drivers, or if the Generic Mass Storage INF overrides a needed Driver, but that has not happened so far.

As long as the last Partition on the Drive starts below the clamp and is non-dos, you are OK. Of course that won't be true for the OS that actually uses it. Enumeration occurs before CONFIG.SYS so you must start the last Partition in the BIOS readable area. I'm not sure but DOS might mark the partitions as CHS when LBA accesses fail when using a CHS only (8GB) BIOS. To be 100% controllable you must make sure that no program or installer changes AUTOEXEC.BAT or CONFIG.SYS. In addition you must insure that all Files or Programs referenced are safely within the BIOS readable area. Recopying the files or defragging may move them. Oh, I see. I believe it's safe. Why wouldn't it be? It's both within the BIOS detected size and the Win98 supported size. I thought the BIOS detected size was 8GB. Zone #2 is the area ABOVE the BIOS Detected size. That version seems to cover a range of BIOSes, with and without those limits. I have also unpacked and packed some of these BIOSes and modified them. My Tyan S1590 Motherboard now supports 2 TiB Hard Drives. Some EPIA motherboards say they support 2TiB and even report sizes up to 2TiB but don't actually work. A one byte Patch fixed them. The only way to know for sure is to use a program like my free 48BITLBA.EXE test program.

The instructions for U98SESP3 tell you to remove the Drivers using Device Manager. This clears them from the Registry. This is needed because the underlying USB Controller Drivers are being replaced and different Registry entries may be needed to connect the layers. The Pre-existing Driver Files and INF Files are still present, unless you delete them too. Since an INF with a specific Device reference (VID/PID) takes precedence over a Generic Device reference, your previous Drivers should still be used if they specify Devices explicitly. The Generic Mass Storage Drivers would not be used, only the updated USB Controller Drivers. I would assume your Sony Camera Driver would still be used and should still work. If you are building or rebuilding a new System, it may be necessary to pre-install any USB Device that needs special Drivers, such as your camera, remove the Drivers with Device Manager and then install U98SESP3. Alternatively you can do a forced install after.

A DDO is not an option for more than 8GiB, unless you intend to Patch the BIOS itself. A DDO could be loaded from DOS but it leaves a vulnerable period before the DDO is loaded. Also it would prevent DOS from enumerating the Drives properly or setting them to the correct mode. I haven't checked if CHS Reads or Writes wrap around at 8GB, but if they do corruption is a certainty if a write occurs. Even a bad Read can cause problems. If the Reads or Writes fail, the intended operations will not occur and corruption can occur in the case of a Partiton that Overlaps the limit. The limit for full 28-Bit BIOSes is 2^28 but some BIOSes round down the actual size.

Not quite. My IO.SYS fix resolved a problem that I discovered and fixed with an earlier Patch long before your investigation. The current Patch fixes both. Really? Perhaps you've forgotten our little debate over the merits of Steven Saunderson's patches a few years back, in which (as I recall), you initially said these were only needed on NT systems. At that time, I had already found two of his patches to be required, whereas one was detrimental. Anyway, your current patch is the best because it also addresses another issue (and our collective thanks to you for it!). Joe. That other issue is the one I am referring to. The discussion about the Saunderson Patches came later. I extended the concept I had developed originally to come up with a single Patch for all of these issues.

Way too many posts to quote individually. With a full 28-Bit BIOS, there is no need to clamp as the BIOS will only report 137GB (or less). There is a legacy 28-Bit Capacity Field in the Drive's Information Data separate from the 48-Bit Capacity field. Clamping is only needed if the BIOS crashes during Boot. Capacity limiting Jumpers set an initial Clamp without setting a permanent HPA. Set the 28-Bit HPA to Clamp. Unclamping requires that the 48-Bit HPA be set. Some old DDOs shifted Sectors making the Drive unuseable without the DDO active. This is what gave DDOs a bad name. My DDO does not shift Sectors so the Drive can be moved to a newer Computer and used without activating the DDO. The Limitations and solutions are as follows: ~8GB, CHS Limit, LBA DDO ~32GB, BIOS Overflow Bug, Clamp Drive and use unclamping DDO ~64GB, BIOS Overflow Bug, Clamp Drive and use unclamping DDO 136.9GB, BIOS Overflow Bug, Clamp Drive and use unclamping 48-Bit DDO 137.4GB, 28-Bit Limit, 48-Bit DDO 2TiB, 32-Bit Limit, Extended 48-Bit DDO These limits apply to DOS, Windows Boot, Windows Safe Mode, and Windows Compatability Mode. Windows 9x Limits: 137.4GB, 28-Bit Limit, High Capacity Disk Patch, Raid Driver, or IAA 2TiB, 32-Bit Limit, Terabyte Plus Package If the BIOS Limits are not resolved, the following rules apply: 1. The Boot Partition and all other DOS/Windows accessible Partitions, on ALL Drives, must lie entirely within the BIOS supported area. 2. Logical Partitions, on ALL Drives, that are Non-DOS must start within the BIOS supported area, but may extend beyond if they are used by OSes that are safe from BIOS issues. 3. Non-DOS Primary Partitions can be anywhere. The only exception to #1 is a Partition that starts within the BIOS supported area, is never used for Installed Programs or Temporaries, is never used in DOS, never referred to during Boot and is never used in Safe Mode or if the Drive is in compatability mode. If the 137.4GB Limit is exceeded, the Windows Driver Patch is still required. I have all four DDOs and the two Windows Driver Patches. All support 2TiB. The last DDO and Driver Patch listed support 512TiB or more.

Not quite. My IO.SYS fix resolved a problem that I discovered and fixed with an earlier Patch long before your investigation. The current Patch fixes both.

A DDO is not an option with Windows 9x. It is a necessity. Any operations by DOS or Windows, before the Driver is loaded, to Drives other than C: can fail. In particular if you do any installations to other Drives that need to be updated on the next boot, they are likely to be done by WININIT in DOS mode. I have DDOs (BOOTMAN) that can provide the necessary support as well as letting you use the full 160GB.

I have a generic SATA Driver Patch if you cannot find a specific driver for your system. AHCI is not compatable with Windows 9x. Having an ACHI only Hard Disk Controller active will make Windows 9x unbootable.

You couldn't have installed all of my Patches. There is no Demo for the SATA Patch.

There is a reason for that. The people who complain are the ones that are stuck with what you offer. They don't have the skills or knowledge to get around issues, or provide useful suggestions. Jaclaz came up with a solution because he knew how. So of course he isn't going to complain, he didn't need to. There are plenty of people that deserve to be ignored, but I would go by the reasonableness of, and practicality of solving, a complaint, rather than who complains, before deciding to ignore it. You are right. There will definitely be more complaints, some reasonable, many unreasonable as long as you are maintaining this project or any other public project. I have had my share. Don't let them get to you.

I'm not surprised. You are a single source. The alternative is a pile of slightly different versions created by different people to customize their installations. These will be far harder to manage and update. The requests and complaints come with the territory. I get them too. You took charge of this project. You can't let them get to you. Listen to them. Decide if their requests are reasonable and practical to implement, or not, and act accordingly.

I'm not sure but it may be necessary to break up the import into multiple pieces. I was able to build a Registry of 19MB by repeatedly importing a synthesized import file containing a key with over a megabyte of value data in it, changing the Key name each time. I created the large Registry to test my RAM Limitation Patch's /M option that supports large Registries with Windows 9x.

Hi jaclaz, This link "SD MMC card fits in floppy connector" is an interesting find, to connect SD or MMC cards to an old 5.25" floppy cable (to the floppy drive controller? or to a different controller?), after doing "some rewiring of cable". As stated in the text, the cable connects the SD/MMC Card to a Microcontroller. They are using the Floppy Drive connector as a cheap alternative to a SD/MMC socket. After rewiring, it is no longer a Floppy Drive cable. It can no longer be used with a Floppy Drive Controller. 1. No 2. Still No.

The Mitsubishi LS-120 drive, which came with the plug adapter, does not have a 2nd 34-pin connector, only a 40-pin IDE connector. I checked some old 5.25" floppy drives. The connectors on these 5.25" floppy drives have on the back side metal strips for all 17 uneven pins 1 to 33. The plug adapter, in contrast, has on the back side only metal strips for pins 1 and 33, there are no metal strips for uneven pins 3 to 31 (see middle picture in posting #103 above). I am not sure whether this difference is relevant since all uneven pins 1 to 33 for standard floppy disk drive connectors are Ground. In any case, with this plug adapter, of the ground pins only pin 1 has a connection to the 40-pin IDE connector, and pin 33 connects to pin 1. Did the plug adapters you have seen have 17 metal strips on each side, or was their back side like the plug adapter here, with only 2 metal strips? I don't recall what was on the backside of the adapters. I haven't seen them in years.

Hi rloew, This plug adapter has been sitting in a box for over a year, and I haven't dared to try it out, yet. My gut feeling says there is a 50% chance that I would get a burnt out motherboard, a damaged LS-120 drive and a burnt out plug adapter. The irreplaceable component would be the burnt out plug adapter, I haven't seen such a plug adapter before. There must have been a reason why this plug adapter was included in the box with the LS-120 drive. Any ideas about how to connect the plug adapter, at my risk, is appreciated. I would speculate that this plug adapter could perhaps make this specific LS-120 drive model function like a normal 720KB/1.2MB/1.44MB floppy drive, without the ability of reading/writing/formatting 120MB diskettes. I would further speculate that this plug adapter works only with the LS-120 drives by Mitsubishi, and not with the drives by Matsus***a/Panasonic. I have seen adapters like that before. As far as I can tell, it allows you to use a 3.5" Floppy Drive on an older Computer that only has connectors for 5.25" Floppy Drives. I'm not sure why it would be included with an LS-120 Drive unless as you say it supports a normal Floppy mode as well. In that case it would have a 34 pin connecter somewhere. Using the 40-pin Connector is still a no-no.

Hi naaloh,This is a very good question: "Why was the IDE interface, and not the floppy drive interface, used for superfloppies/LS-120 drives?" Any insights? It is indeed strange that the LS-120 drives, as supposed successors of the floppy disk drives, did not connect to the 34-pin floppy drive cable from the motherboard, but to the 40-pin IDE cable.None of my 34-pin floppy drive cables fit onto the 40-pin IDE connector at the back of the LS-120 drive, because of the protrusion ("cable key") in the center and a protrusion at the side of the floppy drive cable. So the 40-pin IDE connectors were made in such a way that an IDE drive could not be connected with a 34-pin floppy drive cable to the floppy drive controller. But wait: In a shrink-wrapped box of an LS-120 drive by Digital Research Technologies, containing an IDE LS-120 drive by Mitsubishi Electric, Model MF357G-2111UAL, manufactured Feb.1998, there was a strange little plug adapter in the box, with no explanation. This adapter has on one side a female 34-pin connector [to the LS-120 drive?], and on the other side an old male 34-pin connector, as for 5.25" floppy drives. By means of the plug adapter the LS-120 drive, with its 40-pin IDE connector, can be connected to an old-style floppy drive cable (5.25" Drive B connector type), for those who like risky experiments. The 34-pin plug adapter does not have a "cable key" protrusion, so I don't know where to connect it on the 40-pin IDE connector of the LS-120 drive. I was afraid of damaging both the LS-120 drive and the motherboard when connecting the LS-120 drive via this plug adapter to the floppy drive controller on the motherboard. This plug adapter may reflect attempts to connect an LS-120 drive to the floppy drive controller. I am attaching 3 pictures of this wondrous plug adapter from the Digital Research box. The back of the plug adapter shows a custom connection. Any suggestions? Don't even think about it. The Floppy Interface is totally different from the IDE Interface. Connecting the 34-pin Connector in any position into the 40-pin Connector will not work. Without checking the pinouts, I am not sure if you will get a cloud of smoke or not. I don't know enough about how the LS-120 encodes data on the disk to say if it is possible to make a LS-120 Drive using the Floppy Drive Interface. The Floppy Controller in PCs is not very flexible.

My RFORMAT program can do the Formatting you requested and provide information on an existing Format.

I fixed that problem years ago.

As far as I can tell, only one Logical Partition can be in a single Extended Partition Table, so the chain is linear. DOS and Windows 9x support multiple Primary Partitions. The additional Primary Partitions are all placed after the Logical Partitions in the Drive letter sequence. You can have Partitions up to 2TiB in size but you may need my Patch if it is larger than 1TiB.