jaclaz

I don't want to seem grumpier than I normally am, but SEVERAL ramdisk "options" have been listed (and most if not all of them will "normally" work). BUT you put so many "limits" that it is very possible that such a tool, you want Win2k AND >3 Gb AND NOT use /PAE simply does not exist. Would they work under 2K? You try and report. Would any of them work with /PAE or without /PAE? You try and report. I pointed you to a possibility (UNTESTED by me) which is NOT IMDISK, but rather IMDISK in connection with AWEALLOC. Will it work "under 32-bit Windows" ? Up to you to try and report, but please do report EXACTLY, with DETAILS. I.e. a report like this has NO USE whatsoever. I suggested you to try using IMDISK+AWEALLOC, you do not answer "Yeah, I already tried IMDISK". Just for the record, the whole "catalog" (AFAIK) of Filedisk/Ramdisk drivers that work "under some versions of NT based 32-bit Windows (and possibly with different features available under different versions of NT based 32-bit Windows) is here: http://reboot.pro/1507/ jaclaz

NO, it does NOT . What the readme says is (I KNOW, as I have actually written it ): You asked for it, you are wrong! If you use the SAME adapter CarterinCanada used, that specific adapter is powered at 5 V AND works at 3.3 V TLL level. If you use the SAME specific adapter used in first post of this thread (Sparkfun SMD shifter) listed in the read-me-first as EXCEPTION, that will output 3.3 V TTL level (good) IF powered at 3.3V BUT 5V TLL level (bad) IF powered at 5V. A number of other adapters should be powered at 3.3V (actually as said anything *around* 3V will do) in order to produce 3.3V TLL levels. Another number of other adapters should be powered at 5V (actually these may work as well with anything *around* or above 3V will do) in order to produce 3.3V TLL levels. Another number of other adapters should be powered at 5V (actually these will require anything *around* 5V or exactly 5V) in order to produce 3.3V TLL levels. You have to understand that one thing is the power Voltage Vcc and another is the Logic Level (go back to read-me-first and re-read it). Particularly, re-read pont #6 AND ALL the links posted under: It is the same thing as if you ask which fuel goes in *a* car. A normal gasoline (US) car will need petrol (in the UK) or Benzin in Gemany. A Diesel car will need Diesel fuel. But if you mounted on your car a jet turbine you will need probably Aviation kerosene or Flugbenzin (which is NOT the same thing). If you have an adapter that is supposed to be powered at 5V in order to provide a 3.3V TTL level, you power it at 5V, if you have an adapter that is supposed to be powered at 3.3V in order to provide a 3.3V TTL level, you power it at 3.3V. If you find/build an adapter supposed to be powered at 9.83V in order to provide a 3.3V TTL level, you power it at EXACTLY 9.83V..... jaclaz

No. You got it wrong. An "ordinary" MBR is 512 bytes long, NO MATTER sector size of the hard disk. The BIOS will read first 512 bytes of the hard disk, NO MATTER sector size of the hard disk. *ANY* bootmanager/bootloader may be longer than 512 bytes AND has to provide code to read beyond the 512th byte, NO MATTER sector size of the hard disk. AS AN EXAMPLE of such kind of MBR bootloader/bootmanager I cited grub4dos and it's grldr.mbr. That PARTICULAR, SPECIFIC EXAMPLE uses bytes 512÷1023 to store a backup of previous - if any - MBR. In normal operation the grldr.mbr code (within the first 512 bytes) "jumps over" the second 512 bytes and continues to read up to where it is instructed to, in the specific case not beyond the end of it's code which is in total 9216 bytes. You are falling in the usual "generalization" error. *any* makes no sense, as well as "ordinary". In theory yes, *any and all* MBR codes and bootmanager/bootloaders, including "ordinary" and "rather uncommon" and "exceptionally good" ones will work allright, NO MATTER sector size of the hard disk. BUT: YMMV. It is not an "international" standard, it was a "practical consequence" of the initial completely botched approach (in the sense of not enough "open" to future increasing in size of hard disks) which is (was) the CHS addressing scheme AND for historcal reasons (actual way hard disks were initially made). If you think of a common floppy, it has a geometry of 80x2x18 AND it actually has 2 Heads (Sides) and actually each side has 80 cylinders, each containing 18 sectors. Early hard disks were the same. Very soon physical geometry lost each and any resemblance with logical geometry. You will need to go all the way through this to understand this "evolution" and to understand WHY the nx255x63 geometry became a "standard". http://www.pcguide.com/ref/hdd/bios/size.htm Be warned that the mentioned site goes through ALL historical size barriers (no matter which was the cause) whilst you are interested in those that are BIOS/IDE/ATA related only, BUT you need to read them all to understand the path taken. jaclaz

The Pololu will obviously work though please DO READ the page about LC spikes when using "longish cables": http://www.pololu.com/catalog/product/126 (this is always good advice: "keep it short" ) The "Droids" one really cannot say, being MAX3238: http://www.maxim-ic.com/datasheet/index.mvp/id/1517 http://datasheets.maxim-ic.com/en/ds/MAX3238.pdf from the Datasheet it seems like it uses lower TTL level (which should be compatible). For less than 1 € difference, I would get the one that is known to be working. Yes/yes. Yes, if you review the guide, you will see this thingy: which is the "equivalent" to the thingy called "5/12V StromKabel SATA" in your picture, BUT that has an additional (old "floppy" type) connector, from which CarterinCanada gets the power (0/+5 V)for the adapter, see here: Since you don't have this second connector, you will need to solder two wires to the "5/12V StromKabel SATA" wires or use on of these thingies here: or peel off the insulation of the wires and connect to them *somehow* the two wires needed to power the Pololu (or whatever) adapter. jaclaz

So, in any case, you will have a bottle-neck in the network transfer, so actual speed of the PCI card should be irrelevant. Even if you have a "Gigabit ethernet" network, it's speed will be slower than ATA100 (and very few hard disks, even if they "sport" ATA133 can actually reach ATA100 speed, they are more likely to be around the 40/50 Mb/s mark) Have a look at this: http://www.tomshardware.com/reviews/gigabit-ethernet-bandwidth,2321.html And you have the PCI bus overhead, and what not (including the OS you will be running). Being notoriously cheap I would go for anything you can get with the smallest price tag. jaclaz

Yes/No. http://reboot.pro/15911/ YMMV and "under 32-bit Windows" is slightly less INaccurate than "under an OS" jaclaz

64 x 512 = 32768 bytes (=8 times 4K sectors) Unless otherwise specified, 512 bytes/sector. Well, with disks of hundreds of Gigabytes, 1 Mb is not that much. If you think about it, older (much smaller) disks always had a bunch of unused sectors at the end, as the "steps" or "size increment/decrement" for any partition was 1 cylinder, i.e. 1x255x63x512=8,225,280 bytes, depending on a few factors there has always been this unused space in the theoretical range 0÷8,224,768, but often nearer to the upper limit. No, you got this part wrong. We thought for years that the BIOS accessed first (512 byte) sector and that that (first seector) was the MBR. It is simply not like this. The MBR is the first 512 bytes of the first sector, NO MATTER sector size. There are already more than a few (grub4dos as an example) bootmanagers/bootloaders that use several (512 bytes) sectors after the first one (grub4dos' grldr.mbr uses, if I recall correctly, first 18 sectors of a hard disk (512 bytes each) or if you prefer, it is 9,216 bytes in size. The grub4dos' grldr.mbr contains in the first 512 bytes, i.e. what is actually READ during booting some code that makes the BIOS read from 513th byte onwards (actually normally from 1025th, as second block of 512 bytes is a backup of the previous MBR if any) up to 9,216th. jaclaz

My very scarce German tells me that "5 V-TTL" translates in English to "5V-TTL" . Compare with point #10 of read-me-first: You want 3.3V TTL, NOT 5V TTL. These are seemingly suitable (BUT do check with the seller): http://de.futureelectronics.com/de/technologies/interconnect/usb-to-ttl-rs232-rs422-rs485-cables/Seiten/1177955-TTL-232R-3V3-WE.aspx http://parts.digikey.de/1/1/1398465-module-usb-srl-3-3v-ttl-conv-ttl-232r-3v3-pcb.html http://www.tme.eu/de/details/ttl-232r-3v3-aj/ftdi-module/ftdi/ttl-232r-33v-aj/ http://www.ebay.de/itm/FTDI-USB-UART-seriell-Adapter-AVR-PIC-TTL-RS232-/270748929489 This one has several types listed: http://www.unitronic.de/index.php?id=ftdi-r TTL-232R-3V3 (TTL-232R mit 3,3V IOs) good TTL-232R-AJ (Audio Jack connector, 5V IOs) bad TTL-232R-3V3-AJ (Audio Jack connector, 3.3V IOs) good TTL-232R-PCB (Populated PCB from the TTL-232R USB connector, 5V IOs) bad TTL-232R-3V3-PCB (Populated PCB from the TTL-232R-3V3 USB connector, 3V3 IOs) good TTL-232R-WE (No connector at serial end, 5V IOs) bad TTL-232R-3V3-WE (No connector at serial end, 3.3V IOs)good This may help you (together with the read-me-first) understand the issue: http://www.mikrocontroller.net/articles/Pegelwandler jaclaz

Well, I am. The hard disk in the link seems an OLD (possibly a 40 or 80 GB IDE "Calypso" series. I can teach you how to completely disassemble and re-assemble (with nothing but a set of spanners, screwdrivers and a few other tools included in the set you get with the bike) a 1938 BMW motorcycle (actually you could do this as well up to R65 or R70 series, in the '80's ). Now you try doing the same with the S1000RR. ..... Problems reading? Click on the 7200.11 board listed there: http://www.hdd-parts.com/10110501.html It is perfectly possible, with the APPROPRIATE TOOLS to read the data from a "dead board" (if the chip is "OK") and transfer it's contents on another identical board. Only noone exception made from the pro's have this kind of specialized hardware, and the only "poor man's choice" is to de-solder the chip and transplant it on the identical board. BTW, professionals have at their hands also tools like the PC-3000 that comprises both the hardware and software to (among a zillion other things on every hard disk ever made) fix the BSY or LBA errors on a 7200.11. A PC-3000 should sell for something like US$ 3,000,00. The info in this thread allows to fix the SPECIFIC Seagate stoopid thingy for less than US$ 30,00. By swapping PCB's WHICH CANNOT BE DONE WITHOUT TRANSFERRING THE FIRMWARE on this SPECIFIC model, you risk to fry the PCB or the disk, or both, for good. Please, DO NOT post info about something that you are not very sure about, and that NOT ONLY CANNOT WORK, but that can also make things worse. Cannot say specifically about the 7200.10. IT WILL NOT WORK on a 7200.11 (check the title of this thread, please) A video among the "related" on that youtube page: jaclaz

Yep . That's a MS decision , if you check the "alignment jumper" that there is on some 4 Kb sector HD's (I seem to remember Seagate), you will see that they add a "fake" sector so that older OS (XP, that has hardcoded 63 as "boundary") will partition disk starting from sector 64. Since this has been made by the actual HD manufacturer, it means that 64 is "good enough". Yes/No. There is NOT any gap between two primaries. (the previous is already aligned at start and has a size that is a 4 Kb multiple, so also it's end is aligned, hence the following is already aligned). There is no "gap" between a primary and an Extended (for the same reason) but there is a gap inside the extended until the beginning of the first Logical Volume and between any two Logical Volumes. These gaps were 63 sectors in the "previous standard" and are probably (but I have never had an occasion to check) 2048 in the "new standard". This is a common doubt. Traditionally we have seen (because they were like that ) that the MBR is first sector of a hard disk. It is NOT like that (it is , but we have to slightly change the definition) The MBR is the first 512 bytes of the first sector of a hard disk. When we say that the "magic Bytes" 55AA are the last two bytes of first sector, we commit a mistake they are the last two bytes of the MBR, or even more properly the bytes at offset 510 and 511 of the first sector of a hard disk. The above, that now may seem obvious, comes (extrapolated by yours truly porting it from "bootsector" to "MBR") UNexpectedly by a seemingly not connected MS doc , the FAT32 specification: http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc Though evidently written by a snotty MS kid that thinks to be much smarter than his intended audience , and provides among senceful info also a few wrong or misleading info, it contains this: jaclaz

All DOS (MSDOS) up to and INCLUDING MS-DOS 6.22 need IO.SYS as first file and MSDOS.SYS as second. Starting from MS-DOS 7.0 (Windows 95) this is not needed anymore. In a nutshell the bootsector code was changed in 7.0 and could access IO.SYS no matter where in Root Entries it was, whilst previous DOS versions needed both IO.SYS and MSDOS.SYS as first root entries. (and only IO.SYS is used, MSDOS.SYS having become a ".ini" file) http://thestarman.pcministry.com/asm/mbr/index.html#Flop http://thestarman.pcministry.com/asm/mbr/DOS50FDB.htm http://thestarman.pcministry.com/asm/mbr/WIN98FDB.htm Using the FORMAT command MSDOS 5.00, when using NO switch (AND giving a label) creates: the given label in the bootsector a first entry in "Root"with the SAME label as the bootsector MSDOS 5.00, when using ONLY the /B switch (AND giving a label) creates: the given label in the bootsector a first entry in "Root" pointing to IO.SYS a second entry in "Root" pointing to MSDOS.SYS a third entry in "Root" with the SAME label as the bootsector makes the needed FAT table "allocated" for the mentioned two system files writes some "garbage" where the two files should go MSDOS 5.00, when using ONLY the /S switch (AND giving a label) creates: the given label in the bootsector a first entry in "Root" pointing to IO.SYS a second entry in "Root" pointing to MSDOS.SYS a third entry in "Root" pointing to COMMAND.COM a fourth entry in "Root" with the SAME label as the bootsector makes the needed FAT table "allocated" for the mentioned two system files AND copies them, as well as COMMAND.COM MSDOS 6.00 when using NO switch (AND giving a label) creates an IDENTICAL formatted floppy as 5.00. MSDOS 6.00, when using ONLY the /B switch (AND giving a label) creates a SIMILAR formatted floppy as 5.00 (the "garbage" is different) MSDOS 6.00, when using ONLY the /S switch (AND giving a label) creates a SIMILAR formatted floppy as 6.22 (including the DRVSPACE.BIN entry the given label in the bootsector a first entry in "Root" pointing to IO.SYS a second entry in "Root" pointing to MSDOS.SYS a third entry in "Root" pointing to COMMAND.COM a fourth entry in "Root" with DBLSPACE.BIN a fifth entry in "Root" with the SAME label as the bootsector makes the needed FAT table "allocated" for the mentioned two system files AND copies them, as well as COMMAND.COM AND DBLSPACE.BIN MSDOS 6.22 when using NO switch (AND giving a label) creates an IDENTICAL formatted floppy as 6.00 (and 5.00). MSDOS 6.22, when using ONLY the /B switch (AND giving a label) creates a SIMILAR formatted floppy as 6.00 and 5.00 (the "garbage" is different) MSDOS 6.22, when using ONLY the /S switch (AND giving a label) creates: the given label in the bootsector a first entry in "Root" pointing to IO.SYS a second entry in "Root" pointing to MSDOS.SYS a third entry in "Root" pointing to COMMAND.COM a fourth entry in "Root" with DRVSPACE.BIN a fifth entry in "Root" with the SAME label as the bootsector makes the needed FAT table "allocated" for the mentiuoned two system files AND copies them, as well as COMMAND.COM AND DRVSPACE.BIN MSDOS 7.0 (Win95a) when using NO switch (AND giving a label) creates a SIMILAR formatted floppy as 6.22, the LABEL is both in the bootsector and as first entry. MSDOS 7.0, when using ONLY the /B switch (AND giving a label) creates a SIMILAR formatted floppy as 6.22 (the "garbage" is different and is very few bytes) MSDOS 7.0, when using ONLY the /S switch (AND giving a label) creates a SIMILAR formatted floppy as 6.22 (including DRVSPACE.BIN) MSDOS 7.01 (Win95b) when using NO switch (AND giving a label) creates an IDENTICAL formatted floppy as 7.00, the LABEL is both in the bootsector and as first entry. (BUT the boot sector code is different) MSDOS 7.01, when using ONLY the /B switch (AND giving a label) creates an IDENTICAL formatted floppy as 7.00 MSDOS 7.01, when using ONLY the /S switch (AND giving a label) creates a SIMILAR formatted floppy as 7.00 (including DRVSPACE.BIN) MSDOS 7.1 (Win98FE 4.10.1998) when using NO switch (AND giving a label) creates an IDENTICAL formatted floppy as 7.01, the LABEL is both in the bootsector and as first entry. ( BUT the boot sector code is different) MSDOS 7.1, when using ONLY the /B switch (AND giving a label) creates an IDENTICAL formatted floppy as 7.01 MSDOS 7.1, when using ONLY the /S switch (AND giving a label) creates a SIMILAR formatted floppy as 7.01 (including DRVSPACE.BIN) MSDOS 7.1 (win98SE 4.10.2222) behaves exactly as 4.10.1998 MSDOS 8.0 (Windows ME 4.90.3000) creates an IDENTICAL formatted floppy as 7.x MSDOS 8.0 has NOT anymore a /b switch. MSDOS 8.0 has NOT anymore a /s switch. (the test was made with the Me bootdisk, so it is not "definitive") Quite interestingly the "garbage" that is written when the /b switch is used has a size that is NOT exactly the same as the actual files that it "fakes". NOW the tests running on each OS the SYS command on the floppy previously formatted by the SAME OS, WITHOUT ANY switch AND writing to the empty formatted floppy a "random" file before running the SYS, as to have first entry the label and second the file:. MSDOS 5.00 System transferred (no error) <- this is UNLIKE MS info, the root entries are re-ordered with IO.SYS first, MSDOS.SYS second and LABEL third. MSDOS 6.22 same as above. MSDOS 7.0 root entries are NOT reordered (as expected) LABEL remains first entry. .... MSDOS 8.0 has NOT anymore a SYS command working on B: drive. (the test was made with the Me bootdisk, so it is not "definitive") What happened in DOS 6.0 (and EVIDENTLY also though undocumented by MS in 5.00) was simply the same behaviour as bootpart, when you use the SYS command the root entries are shifted so that IO.SYS is first and MSDOS.SYS is second, and the volume needs not having being previously prepared with the /B switch. I will see if I can get my hands on a 3.3 and 4.0 or 4.01 boot disk and check that oooold versions. I tested DOS 4.01 in the meantime. It works allright WITHOUT needing the /B switch. The effect of format /s is IDENTICAL to the 5.00 version (bootcode is different). By doing SYS on a "no-switches" formatted floppy after having copied to it a file the IO.SYS and MSDOS.SYS are correctly "bubblesorted" to the top. Queerly whilst with format /s the COMMAND.COM is copied, with the SYS on the pre-formatted floppy it is not (and needs to be copied manually and as expected "goes last", i.e. after the label and the copied file). I managed to get a 3.3 version but it is not really-really DOS, it's a NEC OEM DOS, and in it the /b switch seemingly does not work. (or possibly it needs some additional parameter, I'll have to check) Also, this verson of format does NOT prompt for a LABEL and there is no label command in the image I found. BUT finally I found what we were looking for, when trying to SYS the floppy previously formatted with no switch and to which I had copied a file, I finally got: So all in all, AS EXPECTED, the MS info is either inaccurate or deceiving or late or all of them at the same time! BTW I found while checking another couple "strange" things. ALL DOS versions tested have an attribute of the label as 0x28 (i.e. Archive+Label), whilst XP uses the 0x08 (Label Only). This has a nice side effect. If you access the floppy image with 7-zip you can actually see the LABEL, it's created date & time, modified date & time and the last accessed date. XP, though it writes 0x08 treats the 0x28 just as the 0x08, i.e. somehow the 0x08 is "prevailing" on the 0x20 @All This is as always a quickly put together report, if you spot any error/typo/whatever in the above, please post about it and I all correct it. jaclaz

Given a partition that has just been formatted, if you just copy IO.SYS alone to it, using DOS, it'll be copied as a single continuous image, starting at cluster 2 (the first cluster). Now, to put in a continuous image of any file, starting at an arbitrary cluster number, especially when the partition in not empty anymore, that requires a lot more calisthenics and patience, but can be acomplished by hand, with a good hexeditor/sector-copier, by anyone who has a really strong reason to do it (like learning how-to, for instance). Or you can use bootpart (as said) to "rewriteroot" (i.e. to put the IO.SYS as first file). A set of related handy (though a bit complex to use/potentially dangerous) are here: http://www.partitionsupport.com/utilities.htm @egrabrych Sometimes (read often) reality becomes a myth, the fact that traditionally an OS behaves in a given way makes people assume that the new version will behave the same (actually this happens often) but some things "remain" and little by little it becomes a myth. Recently while doing a few experiments with DOS FORMAT /B I found another little quirk (obslete info perpetuating). I will post this in a new thread as to not clutter this one. jaclaz P.S.: OK, posted here:

Good. jaclaz

Naah, it is an OLD requisite, up to DOS 6.22 IO.SYS had to be FIRST file in FAT. Compare with the bootpart.txt attached to bootpart: http://www.winimage.com/bootpart.htm This requisite is not needed anymore with DOS 7.x/8.0. Cannot say if - in "peculiar" cases - the IO.SYS is put beyond some "limit" (say beyond 512 Mb or 8 Gb or 128 Gb ) something bad can happen . jaclaz

Just for the record, Examdiff is Freeware and have similar (or at least "enough") comparison capabilities: http://www.prestosoft.com/edp_examdiff.asp jaclaz

Sure , partition info was developed WHEN the "standard" was n/255/63, it is normal that it tells you that the current partitioning scheme does NOT respect cylynder (255/63) or Head (63) alignment. The partition is ALREADY aligned. The (FAT32) filesystem clusters most probably WON'T be, and if you re-format (still FAT32) it under windows 7 NOTHING will change, as I tried to explain you. If you re-format (no matter if under XP or 7) as NTFS, filesystem clusters will be (inherently) aligned. Further explanation: due to how NTFS is made, data clusters are alway aligned on 4K multiples from the beginning of the partition, hence, IF the partition is aligned, so will be the filesystem clusters (the bootsector, i.e. reserved sectors is a multiple of 4Kb, being 16 x 512 bytes long and all other structures are actually "files"). on FAT there are a number of data structures (bootsector/reserved sectors, FAT tables and - on FAT12/16 only - root directories) that are placed BEFORE the actual data clusters and that may not result as being a multiple of 4 Kb, hence, even if the beginning of the parition is aligned, filesystem clusters may not. This is the essence of the referenced thread. I hope now it is more clear. jaclaz

You do not "export" data in .csv format, you actually "Save as" .csv the actual spreadsheet (single sheet). About importing it greatly depends on HOW EXACTLY the soource data is formatted, no way to give you any "meaningful" answer without some DETAILS. Excel has a built-in import filter for either "fixed length" or "delimited" data, but it's behaviour may be influenced by a number of factors, including repeated separators and what not. Also in some cases Excel "automagically" determines *something* to be text or date or number and makes the importing procedure more difficult/prone to error. You may need to use a "more dedicated2 program such as: http://record-editor.sourceforge.net/Record02.htm to do an intermediate conversion. jaclaz

You mean that you do not trust my word for it? BTW I provided a link, that - had you actually checked it - may have lead you to here (from the mouth of the wolf, but you will need to "read between the lines"): http://support.microsoft.com/kb/931760/en-us Vista and 7 have a Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\VDS\ALIGNMENT which you can use to override default partition alignment (which is respecting the 4K multiple). Additional (JFYI): http://www.techpowerup.com/forums/showthread.php?t=107126 The MBR will use 512 bytes sized sectors. Block (or sector) size has nothing to do with cluster size. I am NOT "insinuating" anything, I am stating (rather flatly )that the internal structrures of a FAT (12/16/32 and presumably 64) may (actually will in, say, 90% of cases) produce the effect that the filesystem clusters NOT to be aligned properly (and provided a link that explains in detail the issue). jaclaz

Yep , additionally, the issue with SSD is not exactly the "same" one as with HD's. The use of a TRIM enabled OS (like Windows 7 is) AND enable it may make a BIG difference (after some time): http://reboot.pro/9615/ Direct link to the article: http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=1 More: http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx And how to make sure TRIM is running: http://blog.corsair.com/?p=3468 http://lifehacker.com/5640971/check-if-trim-is-enabled-for-your-solid-state-drive-in-windows-7 jaclaz

By default Windows 7 will align the start of the partition to a 4 K boundary. Namely first partition will start at CHS 0/32/33 or LBA 2048. (and all following partitions will all be aligned as well) Having a partition aligned as above makes sense if the partition is NTFS formatted. If you need/want to use a FAT filesystem you will need to align the fiilesystem clusters (additionally): To check the alignment you just inspect the MBR (and the eventual EPBR(s)) and verify that the "Sectors Before" or "LBA start Address" can be divided by 8. A suitable tool could be PTEDIT32 or any similar partition table editor/viewer. Maybe better if you use partinfo (so that there is no risk to edit a field by mistake): ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PartInNT.zip I don't know if it runs on 7, but it should. If -by any chance - you are going to use Logical Volumes inside Extended (partitioned/created under 7) AND use on the disk the XP disk manager, be VERY aware of the possible issues: http://reboot.pro/9897/ jaclaz

NO. Totally UNdocumented, UNreliable, DO NOT EVEN THINK of doing this! We have a sticky EXACTLY to avoid this kind of senseless and risky attempts. Doing a PCB swap REQUIRES exactly matching PCB's (much less easier to find than you might think) AND REQUIRES a ROM swap, which involves quite tricky de-soldering and re-soldering. If you come here and ask what to do you simply CANNOT (meaning that you miss the NEEDED knowledge/experience involved) in doing this (and you will get it only after you have "fried" several hard disks or their PCB's making practice). jaclaz

Who was actually quoting Douglas Adams Just in case of need : http://www.thateden.co.uk/dirk/ jaclaz

Sounds like hardware issues. http://support.microsoft.com/kb/315266/en-us I would check RAM (try one OR the other memory bank, one at the time) and remove and reseat *everything* first thing, then verify disk/filesystem from an "external" boot (Recovery Console or PE). jaclaz

Cannot say, you should check yourself by connecting the hard disk "directly" (without the USB enclosure) to a desktop and see what the BIOS detects. THIS guide: http://www.mapleleafmountain.com/seagatebrick.html See here: APTLY titled: Also : http://en.wikipedia.org/wiki/There_ain't_no_such_thing_as_a_free_lunch There is NOTHING connected with dial-up, EXCEPTION made for this : You may want to re-read (actually READ for the first time) the mentioned guide. An internet connection may be handy if you need help, but there is no actual *need* for one. Sure you can . jaclaz

When talking of software beauty is very often in the eyes of the beholder. I never had an actual need for such a program, for my use a OFM: http://www.softpanorama.org/OFM/index.shtml (which includes - though not exactly Orthodox - 7-zip ) is enough. However, have a try with this thingy here: http://www.copyhandler.com/en/what-is-copy-handler coincidentally (or maybe casually ) it is written by a Polish guy jaclaz