jaclaz

Yes, most probably you are right, my memory is not as good as it was , I'll check and fix. But the main issue I was trying to point out is that no "modern" floppy sizes use anything different from 240 and all hard disk partition/volumes use 248, so I was wondering if in the drop-down list any of the older values was to be included (as it is in current/latest) or if those "other values" should ONLY be coupled to the corresponding "oldish/smallish" floppy formats (and disappear from the drop down list used when "FREE" is selected). The quote from: http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html Was only to highlight (as it has been done :whisting:) TWO things: still within my "obsession" to try calling things with their names AND agree on a common terminology. For the record, the J De Boyne Pollard's page you mentioned: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/volume-boot-block-oem-name-field.html (guess why the suggested OEM string in the .xls is "IBM 2.0" ) are complemented by these other onee: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/bios-parameter-block.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/determining-filesystem-type.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/determining-fat-widths.html These also contain some bits of info that may come of use. The existence of 0x28 as an "alternative" to 0x29 is something I never suspected And this is aso fun/interesting: http://homepage.ntlworld.com/jonathan.deboynepollard/Proposals/version-7-bpb.html jaclaz P.S.: Re: Disk number (or "Drive Number" (usual confusion on names. You are of course right , it's there that the 255 gets a meaning in FreeDOS. The thingy should be the same as the FreeDOS SYS parameter: http://www.freedos.org/kernel/sys.txt So, we do know (from here and there ) that 0 (0x00) means "A:" (or first floppy drive) and that 128 (0x80) means "C:" (or first hard disk). But I cannot find - if not on makebootfat related things - any reference to the 255 as autodetect in FreeDOS. There is this thread here: http://osdir.com/ml/emulators.freedos.kernel/2004-09/msg00057.html that seems to suggest that the 0xFF is a bad idea anyway, but cannot understand if the good guys resolved to leave it or remove it alltogether... Attachment removed, see a few posts below for version 06.

Are you sure? The referenced page says the opposite. http://ss64.com/nt/copy.html Maybe it changed between 2K and XP? http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/copy.mspx?mfr=true jaclaz

The WHOLE idea about batch files is that you DO NOT change hundreds of lines manually! That's ALSO exactly the ide of having a "configuration file". You have same command line (which you change just once) and a LIST of files (source/destination) that it's much easier to create or change. Meet REDIRECTION of standard output and standard error : http://www.robvanderwoude.com/redirection.php Also, please, ALWAYS use COPY /B when copying files, you never know: http://ss64.com/nt/copy.html This: @ECHO OFF SETLOCAL ENABLEEXTENSIONS SET DESTINATION=C:\somewhere\ ECHO.>newfile.cmd FOR /F "tokens=* delims=" %%A IN (list_of_dlls.txt) DO ( ECHO IF EXIST %%A COPY /B %%A %DESTINATION%>>newfile.cmd ) Will create a new file "newfile.cmd" with all the entries in your list of dll's "list_of_dlls.txt" automatically (as opposed to manually) jaclaz

grub4dos can be added to BOOTMGR choices (actually to the BCD) adding an entry for grldr.mbr. It's in the Guide allright: http://diddy.boot-land.net/grub4dos/files/install_windows.htm#windows3 LATEST grub4dos has grub.exe directly chainloadable from NTLDR, but cannot say if it works from BOOTMGR also. jaclaz

That's not "being curious" is "using a tool improperly". You should NOT re-start the process. You should do it as it was suggesterd to you, in "chunks". BTW, for the "copy" you may want to try YCOPY: http://www.softpedia.com/get/System/System-Miscellaneous/Ycopy.shtml at least you will have a list of the failed files. jaclaz

Is the <destination> always the same? Or can you use a "configuration file" (like a CSV)? LIke: 1.dll ,"C:\Windows\Whatever\" 2.dll,"C:\Somewhere Else\" .... <source file>,<target destnation> You do a FOR loop: @ECHO OFF SETLOCAL ENABLEEXTENSIONS FOR /F "tokens=1,2 delims=," %%A IN (Files_to_copy.csv) DO ( ECHO IF EXIST %%A COPY /B %%A %%B ) jaclaz

Yes, and if it behaves like it did before (i.e. spinning and is still BSY, use Victoria to check) it means that the PCB is still good (or at least as bad as it was before). No other way of testing it without a TTL converter that I know of . jaclaz

You have to lookl at it "historically": The original procedure was to completely detach PCB and re-mount it "live/hot" Then someone thought about the piece of paper/cardboard/plastic on the Head contacts Then someone verified that (for UNKNOWN reasons) the trick worked with the motor contacts instead. If you prefer the #2 and #3 are two (more practical) sub-sets of the original #1. So, if #2 didn't work for you, and #3 worked only partially, go for #1. But remember that this is not the "fix all problems" trick, it is well possible that your drive suffers from "something else". jaclaz

NICE work! . As said it's a good thing that the Filesystem selector doesn't work, since it will (when it will be finished ) seemingly select BOOT CODE, instead. No need to pose ourselves this kind of questions , I am only trying to come to an agreement of some sort to make sure that SAME elements are called with tthe SAME name (or that a Rosetta's Stone of some sort is provided ), or, if you prefer, that other MSFN members that will read this thread or use the little apps/tools will have a less confusing experienced. You know how I do like people taking the Red pill, but it should be their own choice, not be forced upon them by the lack of clearness in the tools/posts/instructions. To add to the list of references: http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html On that page, the "Media descriptor byte" is interesting. It seems like most of the values are/were checked by old versions of DOS, and I remember from here: http://advancemame.sourceforge.net/doc-makebootfat.html that the FF or 255 in FreeDOS means "auto-detect" AND that the actual "Drive Type" or "Media Type" needs to be correct. What shall we do? jaclaz P.s.: Attached verion 04 with the above "Media descriptor byte" added tentatively and a couple more fixes. REMOVED: se a couple posts below for new version

That's good news. Yes, as said anything that is somehow replaceable is usually NOT worth the time to recover/fix. Sure, that's what you see, how it actually works is through a sensor, a kind of accelerometer. Point is how long does it takes before intervention and, IF it works in time, IF it effectively places heads in a "safe" parking zone (anyway, and expecially with modern hard disks, spin down will take much more time that it takes to hit the ground) Well, Victoria is NOT a recovery application. BEFORE using it, I would see what DMDE can find/recover (single file at the time in the free version): http://softdm.com/ and, still before Victoria, and after DMDE, a pass with PHOTOREC may be able to recover a few more things (like .doc or .xls files, since it can be targeted to a number of filetypes). Naah, you got it wrong, unfortunately here in Europe we don't have little green men at all, we have gnomes instead , and they become pretty much hostile when it comes to work for file recovery overnight, so we need to do everything by ourselves .... jaclaz

Short answer: NO. Long answer: NO, meaning NOT in a way that will allow the kind of filesystem fixing/data recovery that will probably be needed. BUT, you can (and again this would be easier if you have a set of many relatively little files) create a sparse file the size of the original disk and process (as an example by using dsfo/dsfi through a batch) these files, ONLY copying to the sparse image non-zeroed sectors. This may work on a pristine disk, but I doubt it will give any sensible saving on an used disk (with data deleted form filesystem but actually still on the actual sectors, that make them non-00's). IF the disk was defragmented, you can try using a partial image (let's say the intiial 499 Gb) but of course YMMV. jaclaz

Unfortunately , as expected. Well, no, this can be a temporary storage while recovering, but at the end you need to re-compose a "monolithic image". BTW, the idea of using smartly datarescuedd (as suggestd in the gicen link) is to minimize the time wasted reading unreadable sectors, if you tell it to "just image" it will try again and again each and every sector and it is NOT a good idea to "insist" when a bad zone is found. Sure , by sheer magic during the night some little green men will come to your house and instead of stealing your socks will: install an adequate software associate the .dd extension to it and if you are nice they will also rebuild the filesystem and recover each and every file in it.... ... come on, get real: once you will have (hopefully) a complete image you will need to fix it's filesystem and/or recover the files in it (at least those that you cannot replace) jaclaz

One word of advice, both "/I" and "neq" need command extensions enabled: http://www.computerhope.com/if.htm the: call :%COMPUTERNAME% goto :eof is case insensitive and needs not command extensions enabled. jaclaz

Yes. My 36 MiB image has 1 boot sector and 7 sectors-per-fat, so 1 + 7 + 7 = 15 sectors. As I decided to have a full cluster outside the filesystem, to contain the filesystem's structures, 32 - 15 = 17 sectors. Now, (17 sectors * 512 bytes-per-sector) / 32 bytes-per-entry = 272 entries. Nice logic. Basically it "fills up to the brim" the space between the end of FAT table(s) and next "cluster boundary". I like it. We are going to misunderstand each other if we use different terminology . To me the filesystem is the WHOLE thing. You seem like calling "filesystem" what I call "filesystem structures". I.e. in my view a filesystems spans over the whole volume, and contains: filesystems structures (including the ROOT entries) actual directories and files You will agree that something that resides outside of itself doesn't sound really "right" jaclaz P.S.: Version 3 attached: Tentative support for "Root entries optimization" added Set cluster limits to <4079 and <65519 EDIT: Attachment removed see a few posts below for version 04

Sure , but "normally" ( "normally" means *normally*, still well in the YMMV range ) they are, as said, 224 on floppy and 512 on hard disk. Any reason why you used 272? I think 4078 is the right max value. With all due respect for Wikipedia , I like to have more "specialized" sources for info : http://www.forensicswiki.org/wiki/FAT (though even there it seems to me there is quite a bit of misinformation) FAT12 1 0x000 (Free Cluster) 1 0x001 (Reserved Cluster) 4078 0x002 - 0xFEF (Used cluster; value points to next cluster) (as in FEF-2=4079-2=4077+1=4078 7 0xFF0 - 0xFF6 (Reserved values) 1 0xFF7 (Bad cluster) 8 0xFF8 - 0xFFF (Last cluster in file) --------- 4096 FAT16 1 0x0000 (Free Cluster) 1 0x0001 (Reserved Cluster) 65518 0x0002 - 0xFFEF (Used cluster; value points to next cluster)(as in FFEF-2=65519-2=65517+1=65518 7 0xFFF0 - 0xFFF6 (Reserved values) 1 0xFFF7 (Bad cluster) 8 0xFFF8 - 0xFFFF (Last cluster in file) --------- 65536 So, FAT16 should be 65518. About this: I am not so sure, the "old" (but as we have seen for the El-Torito thingy it might be a "perceived" rule, rather than a "real" one ) it had to be a a power of 2, like: 512 = 512*2^0 1024=512*2^1 2048=512*2^2 4096=512*2^3 .... 32768=512*2^6 And we also have the non-standard 64 Kb clusters possible on NT/XP (at least for FAT16) ...... http://support.microsoft.com/kb/140365 jaclaz

Surely NOT, additionally you may ALREADY have fried the PCB for good. Please READ the read-me-first: ALL of it, with PARTICULAR attention to points #6 and #10. Basically you are SHOUTING (probably at a 12 V RS232 level ) in Hindi to a hard disk that only understands English and (due to a rare condition ) only understands whispered English (3.3 V TTL level), no real suurprise it doesn't want to talk to you.... jaclaz

Well, as always you are perfectly free to call whatever with whatever name you like. BUT: OEM string is one thing, BOOT CODE is another and FIle System is yet another, if you like to call the BOOT CODE "File system", it's OK, as long as you say so . I wouldn't take Ultraiso as a "reference" for English or proper terms, being itself written by a Chinese guy/gal. Every tool I remember having seen do use the "Small sectors" and "Large sectors", of course "Sectors 16" and "Sectors 32" are fine as well, you can also call them, respectively, Mickey Mouse and Minnie , but that won't help people understanding them easily . just for the record, the "Sectors Before" are actually " "Sectors Before" and are not "hidden" at all since they are OUTSIDE (before ) the actual filesystem, but, as said, a number of tools do call them (incorrectly IMHO) "Hidden sectors" so it's allright. . @dencorso So, 4079 is the number for FAT12? WHICH one is for FAT 16? WHAT about number of entries in ROOT? WHAT about cluster size "strategy"? jaclaz

Please, STOP posting on the 7200.11 thread, your drive is a 7200.4, this thread is about it, STOP posting on the 7200.11 thread! I have NO idea about your drive model. You should make sure that you have a TTL adapter and NOT a RS232 one. You may want to try (or have a look at) SEDIV: http://sediv2008.narod.ru/ here is the English help: http://sediv2008.narod.ru/HelpEn.rar I have NO idea if it can be of use or not, though. You were TOLD to try lowering baud rate and what you do? AGAIN, try with 9600: jaclaz

A good start would have been actually READING. This thread is about 7200.11 ONLY. You ALREADY started a new theread, here: continue there. jaclaz

I wonder where bit 8 and 9 reside in a one-byte media descriptor... But I'll try to digest that once beer gets out of my system. While I enjoy having fixed my broken roof, have a look at this alpha-stage tool. It can only read and display (partly) floppy image info, for now. It will be able to create/edit one lateron when I would have figured out all the pieces of the puzzle. That's NOT bit 8 & 9 inside byte #1. It is actually byte 8 & 9: jaclaz P.S.: Nice tool, but can we have "standard" names for the fields? (just to avoid misunderstandings) File system is definitely NOT "Freedos 1.0" or "Windows Vista/7", etc. Sectors 16 and Sectors 32 are usually referred to as "Small sectors" and "Large Sectors". "Hidden sectors" are also sometimes referred to as "Sectors Before" (and this IMHO better conveys the idea).

Good moorning, Mr. de La Palice! WHY would we be making speculations and tests, IF there were some actually valid standards (and if they were actually respected by everyone)? The 36 Mb limit is given by the actual limits of the geometry of 1024/2/36. What Ultraiso makes is probably another thing, since they also make the Easyboot, it is possible that they use a loader as a no-emulation bootsector and later load the super-flopy image (just like it is perfectly possible with grub4dos and with isolinux/memdisk). For the record I just checked the El-Torito reference: http://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf and it does state (page 14) and (page 19): That can be read as it has been read till now. rloew found how evidently a number of BIOS programmers did not make: but rather: For all we know it is very possible that some BIOS programmers actually use (WARNING: just a speculation, as an example): jaclaz

I doubt this. Maybe you did something similar, but not that exact "fix" (mainly the actual terminal commands are AFAIK/AFAICR different on earlier version of the disk drives and the communication protocol is different, lower transmission baud rate). It would be nice if you could post the EXACT (meaning EXACT) settings you made and the EXACT commands you gave. No, it should take a bunch of seconds at least. Hard to say. It is also possible that by using something similar to the 7200.11 fix you brought the disk drive beyond any possible "DIY" repair/recovery. The "Not initialized" in Disk Management is normally a "translation" into MS jargon of: And the: "The request could not be performed because of an I/O device error." sounds like the same for: Which "Windows" are you running? I would hope XP and NOT Vista or 7 (for which most probably you have the added layer of UAC and "run as Admin"), if I were you I would try checkng what Victoria ( or mhdd form DOS) has to say about the disk. jaclaz

Maybe you could analyze the contents/formula's of the not-so-classy Excel sheet, the idea behind it is exactly that of exploring the logic behind the values that existing apps, like FORMAT, mtools and the like calculate and use, or, if you prefer, have an easy test bed for learning in practice what you are asking for in theory. jaclaz

According to the calculations made on the referenced thread: (which I have NO idea if correct, but seemingly so ), yes it is considered a "bad hit" I have NO idea if the Toshiba software works/worked (and HOW it works). Those kind of things should move the head arm to a parking zone, but see below. Maybe the "ticking noise" was a coincidence? And the bad sectors found afterwards also? I cannot say anything about Toshiba's, I don't remember ever taking one apart and anyway probably not the same model you have, what I can say is that - generally speaking - "oldish" disks had a head parking zone on a plastic ramp or similar outside the platter while "newish" ones tend to have the parking zone ON the disk. It is possible that the sensor or whatever actually reacted but that was not fast enough: as a matter of fact - and of course within limits - having the laptop fall from a greater height (say 1 m or more) could paradoxically be better , as the shut-off sensor would have more time to do whatever it is supposed to do. I would use datarescuedd to make an image of the disk. Hints: http://reboot.pro/15040/ With "high level" software (like moving/resizing parition) you remove the "logical" part of the problem, not the physical one. I'll try to explain. Say you had a very small head crash "groove" on the platter, that only affects "logical" sectors 65 to 105. You could make first partition start (say) at sector 126 and have the damaged area outside the filesystem (no more chkdsk errors). But still the first (both logical and physical) sector 0 will remain where it is now, and in order to travel from sector 0 to sector 126 the head will hover (very, very close to the surface of the platter) over sectors 65 to 105. Now, if there is any debris in that zone, it is likely that the head will get it and move it a bit, possibly scratching the platter in zones corresponding to another bunch of sectors, and this will cause some more *something* get loose, etc. etc. Mind you I am not telling you that this is what has/will happen, only that it may happen , and given the relatively small price of hard disks, expecially when compared to how invaluable data are, I would take no chance on this. jaclaz

Version 02 added, with a couple formulas fixed and a preliminary provision for the three "max CD super-floppy" formats. Only the one corresponding to dencorso's image implemented (with a small change). Open question : How many ROOT directory entries do we expect? (usually it's 512 if F8 media, 224 if F0, dencorso's image has 272 ) Maybe we can change this logic to "proportional to image size, with a minimum of 224"? (and a max of 512 if file is bigger than, say, 100 Mb or something like that?) A different kind of question, this part is not fully clear to me : How should cluster size calculated (vs. image size)? In dencorso's image there is a 32 sectors cluster, but scrap the "theoretical max size", provided that the actual max number of clusters in a FAT12 is 4086 (and in FAT 16 65526): http://www.pcguide.com/ref/hdd/file/partSizes-c.html (or what is the actual number) would it make more sense an image around 4086*16*512=33,472,512 instead of the current 37,748,736 (losing 3 Mb of space but have less slack space for DOS smallish files?) Or we should forget the whole thing about FAT12 and make the image FAT16? jaclaz P.S.: Attachment removed, see a few posts below ...