Jump to content

emanymmud

Member
  • Posts

    4
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Netherlands

Everything posted by emanymmud

  1. I'm no expert in this field, but I suspect that the dos version (I'm not sure which version is used during a bad-shutdown scan) is more likely to depend on the bios than the windows version. However, the bad-shutdown scan used to be able to scan the drive whereas the windows version complained about having too little memory. So you might be right afterall. What was your BIOS setup for this disk? My experience is that it is necessary to set it to "NONE" but then there is problem with the transfer speed because the IDE disk controller (PIIX4 in this case) is not programmed correctly. Have you tried to test the transfer speed, for example by HDTach 2.7? The transfer speed should be around 30 MB/s. Petr As far as I know I have the disk set to auto and LBA (normal is for smaller disks and "large" is a seldom used setting, at least that's what I read somewhere). I tested the disk by copying files generated by h2test, a small tool that came with a computer magazine over here. It writes pseudo-random data into a bunch of files and can read it back and verify that it's correct. This read back and verify processed the data at about 15MB/s (the P2 400MHz could be a bottleneck). I'll check out that HdTach tool and get back when I have some numbers. CORRECTION The disk is set to AUTO mode in the bios, not LBA. The website of HdTach mentions that it's going to install lowlevel drivers. Since my system is working correctly now I don't want to risk messing it up. Another benchmark (h2bench for those who read c't magazine) showed read speeds of around 9MB/s in dos mode. I'm happy with it since I bought the drive for size, not speed.
  2. My bios is Award Modular Bios v4.51PG on an Asus P2B-LS mobo. I have the 1014 Beta 003 bios patch installed. Works fine but doesn't include 48bitLBA. There seems to be a commercial upgrade to version 6.00 or something but I think it's not necessary (see below). I guess that the missing bios support is why just about all partitioning tools don't work. I've tried Free FDISK, SuperFdisk and some other mentioned in this thread. At best they showed big partitions correctly but they were not able to create them. None of them showed the harddisk size correctly. Anyway, I've installed the patch and tools from the BigHDD2.0 setup from post #56 (on my system drive which is small and scsi, so no problems there). Then used a Knoppix CD (live linux booting from cdrom) to create partitions on the 250GB Samsung disk (model SP2514N) and create a FAT32 filesystem in them. After some experiments I found why windows sometimes shows two driveletters for the same partition, one formatted and one seemingly unformatted. It turns out that windows likes just about any set of partitions as long as there are no primary partitions that start above the 128GiB limit. Extended/logical partitions can start anywhere, primaries that start below the limit can stretch across the limit and be bigger that 128GiB. For any primary starting beyond the limit windows will show a ghost driveletter. With that sorted I filled the drive (then one big primary partition) to the rim by copying some big files over and over again. There was no corruption at all. All data verified 100%. The copying was done partly by the normal explorer copy&paste functions, partly by an ancient version of FileSync and partly with xcopy calls in a batch file. No problems with any of them. Note that I haven't tried any copying in dosmode! So, once again thanx to LLXX for developing the patch!!! If anybody wants some input on how to partition/format with linux, let me know. It's just a few (relatively) simple commands but I don't want to fill this thread with off-topic info if nobody is interested. p.s. Scandskw and defrag from the BigHDD2.0 install work fine where the originals wouldn't even start because the disk was too big for them. To avoid problems I've disabled (renamed) all older versions of scandskw, defrag and don't forget chkdsk. Hopefully that will prevent windows from messing things up on a boot-time scan after a bad shutdown.
  3. The setup I used indeed installed the patch for 4.10.2225. I went back to the one from 4.10.2222F.zip attached to the first post in this topic. No improvement there. Ran Free FDISK, which showed the two primary partitions I had made (though claiming the drive is less than 9GB and claiming that both partitions each used 100% of the disk capacity). I deleted the second partition, rebooted and then tried to create it again but free fdisk claimed that there was no space left on the drive. Deleted teh first partition as well, still no luck creating new partitions of decent size with free fdisk (or other partition tools that should be able to do it under windows). Can you tell me where I can get your latest/greatest version of the patch. The attachment from the first post might be outdated by now. Thanx for any help you can give! In the mean time I'm gonna check whether the patch I have now at least fixes the data corruption problem when using just a single 250GB partition.......to be continued
  4. Hello all, First of all, thanks for making this patch! I have installed it on my win98se machine using http://www.mdgx.com/files/48BITLBA.EXE and will be testing it on a 250GB drive. There seems to be a strange side-effect though: Using a knoppix cd (to get around the 8GB limit of the standard win98se fdisk) I created two primary partitions, the first of close to 200GB, the second using the rest. With the standard ESDI_506.PDR windows recognised both correctly but of course messed up once data is written over the 128GB limit. With the patched version there seems to be no data mutilation (so far) but the second partition shows up twice in the explorer. The first instance E: (which is the drive letter I'd expect) appears to be unformatted. The second instance gets G: (in between the SCSI cdrom drive F: and the IDE dvd-burner H:). That one is formatted correctly and shows the proper drive label. I can format E: without breaking data on G:. Writing data to both E and G will mess things up of course. Has anyone ever seen this effect before? Better still, is there a known solution?
×
×
  • Create New...