dencorso

As far as I know the OEM Field at Offset 3 is not part of the BPB. The BPB that is used internally starts at Offset 0xB. That would make the two fields above BPB+8 and BPB+0x11 respectively. Very true. You're right, of course.

Congratulations! I'm glad you feel more confortable now about going "under the hood" with Win 98.

The FAT-32 "bootsector" actually comprises 3 sectors, but since the second of these is the FSINFO sector, the bootstrap itself is somewhat less than 2 sectors, like I said. Now, if we just consider the FAT12/16 bootsector for the moment, by simply zeroing out the first 64 bytes, we loose just the initial jump and two bytes of code before the region that would be preserved. I think that's acceptable. A more extensive idea would be just to zero out the BPB, then calculate the MD-5. Then again allen2 is right when he says that compressing the actual bootstrap might be more useful, although that would be less compact. Another question you posed and that remained unanswered: The MS standard (fatgen.pdf v. 1.03) has BPB_TotSec16 for BPB+0x10 and BPB_TotSec32 for BPB+0x1D, and I think this is good, in that it does not create ambiguity. I do think "Total Sectors (16)" and "Total Sectors (32)" are good labels. Of course, everybody else will disagree, but life is like that. I've revised the bootsector sheets and they are correct, byte-by-byte. An interesting fact is that, when the FreeDOS bootsector is compared to the one present in the released floppy image version of FreeDOS 1.0 Final (2006-08-11), the bootstrap code in both is identical, but they have different OEM names, the one in your worksheet using the already classic FreeDOS, while the FreeDOS 1.0 Final (2006-08-11) floppy has "LINUX4.1" (attached). LINUX41.7z

Very true... OK. If it should cater for FAT-32 too, let's make it thus: 1. Copy the whole bootsector to a temporary buffer 2. Zero-out the first 96 bytes to remove the BPB down to a paragraph boundary. 3. Calculate the MD-5 Hash for the resulting image in the buffer. As for the fact that the bootstrap is divided in two sectors, I'd bet the MD-5 of just the last 416 bytes of the 1st sector should still be distinctive enough.

I see. I think the best way to determine the contents of the bootstrap code might be: 1. Copy the whole bootsector to a temporary buffer 2. Zero-out the first 64 bytes to remove the BPB down to a paragraph boundary. 3. Calculate the MD-5 Hash for the resulting image in the buffer. This is fast and efficient, provided we create a list of such "truncated MD-5"s for all "known bootstraps" The "truncated MD-5 of bootsector" or "partial bootstrap MD-5" would become an entry in the .INI, of course. MD-5s have been gathering discredit in recent times because they're not unuque. However, they're way better than CRC-32s, and, moreover, only in very contrieved situations does their non-uniqueness manifest itself, so I do think they're still distinctive enough for our purposes and small enough, when compared with their "better" competitiors.

I'm using IE8 on Win XP SP3, and, to me, the .PNG image Larry posted a link to appears *much* darker than the .jpg image. If they were meant to be exactly the same, well, I simply am not seeing them as the same at all. I think that was what Larry was referring to. Of course this is not IE9 on Win 7, but about 50% of all Windows users are still on XP, and IE9 is simply not available for this platform. IMHO, .jpgs for photos and most art and .gifs for line drawings and most everything that can be reasonably represented in up to 256 colors (or where the lossy compression is a problem) still is the way to go. And the .gif patents have al expired, AFAIK, so there's no reason anymore not to use them.

I'll review it again more closely by the weekend, but for now, here's what I got to offer: 1) For the Common Floppy Formats list: 800K size=819,200 sectors=1600 c=80 h=2 s=10 (b/s)=512 (s/c)=1 Re=112 Mt ? 1600K Re=224 1760K - 1920K Re=224 The above also adds "10" to the list of known values for sectors_per_track (aka sectors_per_head) 2) For the question of the labels, my suggestion is: 1. Sectors_per_Track 2. Number_of_Heads 3. Sectors Before 3) While I didn't review the FreeDOS bootsector sheet, I did better than that for the MS-DOS sheet: I actually booted my 128MB SD card using that bootsector and it works OK. So I suppose it's mainly OK, but I'll review both byte by byte during the weekend. 4) I didn't review the INI sheet very closely, because it's not clear to me which application is it intended to work with. Can you please elaborate? Later edit: Never mind. I had failed to notice the quote below in a previous post of yours. It's clear enough. I'll review the .INI bearing it in mind.

While I don't disagree with you, after some musing, I think you are insisting in using the most misleading label possible, for an otherwise simple thing. So let me make some considerations on what CHS is: Cylinder is the set of all tracks that are at the same distance from the center. Once you define a value for "Cylinder", the position of the whole head-manifold (which moves all heads solidarily) is fixed. So Cylinder means "distance from the center". Head is which of the heads is the head-manifold that is activated. In general, that means just which side of which plater will be used, and in this general sense, head means "side". However, after fixing the cylinder, defining a head defines one side of one platter, and as such, it does define which track inside the cylinder is used. But this is true solely when the cylinder has already been fixed. And that's why "sectors per track" is unmistakeable and graphic, while "sectors per head" requires contextualizing. Sector indicates which part of the track selected by the other two coordinates is to be addressed. Moreover, there's no reason at all for different uses for floppies and hard-disks, unless you go all the way back to single sided floppies, for which cylinder = track and head is irrelevant, because there can be only one (as Connor McCloud used to say ).

What really annoys me is that nobody has any doubts that an old piece of hardware, like an old GeForce2 is worth some money. And if it was refurbished, the work of the refurbisher, say, in exchanging the caps, has to be paid for, and the new capacitors also have some cost. I've never seen anyone defend the refurbisher should pay for the caps, the solder and whatever else is needed, repair the board and then give it away at no cost. Why is it that software is different? Is it not work, perchance?

Even if this is nowadays not more than an intangible metaphor, for floppy disks and very old hard disks (winchester disks, remember them?) a sector is the minimum transferable data packet, a track is a collection of sectors on the same side of the disk, which are at the same distance from the center, and a cylinder is a collection of tracks of the same number throughout the different heads, so that they delineate an imaginary actual cylinder. So, a cylinder is made of tracks and a track is made of sectors. That's why it must be "Sectors per Track". The left-hand Figure shows reasonably well the relationship between cylinders and tracks, while the one at the right hand highlights in yellow a full track (with its respective sectors) and in blue a single sector within another track. Now, floppy that have two sides do actually have cylinders: they are composed of the tracks of the same number on each side. Only sigle sided floppies "don't have" cylinders, or, more precisely, are in a situation where tracks = cylinders. ... of course, this is just a model, and as such, not more than a thought-aid, with little or no compromise to reproduce reality (for floppies, for instance, the actual tracks on one side are not exactly below those on the other side, but interleaved instead, in order to minimize the magnetic "print-through"), which always is more "complicated".

Perhaps DISKEDIT.EXE (from Norton Utilities 2002 ..10E) with the /M switch for the ATAPI/IDE LS-120 drive (if it's recognized by the BIOS) on true DOS or (even more delicate) on a Win 98SE DOS box, after telling it to proceed, regardless of its dire warning. Another idea is either HDD raw Copy Tool or HDD LLF from HDDGuru. There are many possibilities with those tools, but I'd bet on SCSI mode.

And also try AFDISK again in true DOS, after loading the apropriate ASPI drivers.

I'd say DOS 6.22 isn't a good idea. MS-DOS 7.10 from Win 98SE would be much safer. When in DOS, the DOS device driver for the LS-120 should be loaded from config.sys. On a windows DOS Box, within Win 98SE this may not be necessary, and it would be the first way I'd try. Never mind that Win 98SE is unable to mount the volume, I bet it creates the virtual SCSI device all right. Do give it a shot.

I've just given your spreadsheet a try: I found two issues right away: (i) [minor Bug?] the dropdown menu offers *two* "FREE" options... I picked the 1st, but I suppose the other would have worked equally (I didn't try it). If so, there's no reason for two identical entries. If not, there must be made more clear which is the difference between them. (ii) [nomenclature issue] "Sectors per Head" everywhere shouldn't be rendered as the more usual "Sectors per Track"? I liked the way it does not impose, but just suggests sensible values, and that it goes on with the red "Calculated image size from data:", until it considers the paramenters sensible. I went on to create a 125,960,192 bytes, then copied the batch to notepad, saved it as batch.cmd and run it, and it gave me a perfectly sensible 42 kiB truncated image of the sought after 120 MiB FAT-12 superfloppy, named XLSimage.ima The batch is quite clever, I liked it a lot! [Caveat:] But it should warn that anything on the same directory named *.bin wil be deleted by it, with no warning... Moreover ".bin" is a too common extension... Perhaps ".tmp" or something like ".@" might be safer? I noticed however, that the calculated BPB values are not automagically transfered to the other pages, which do contain the bootstraps. It would be handy, because, then, a simple copy of the whole sector could be used to enable bootability. As it was, I added the first two bytes (0x33 0xC0) of the bootstrap by hand to the image, to get to a paragraph boundary, then copied all the rest as suggested, but using WinHex, instead of TinyHexer. I then extended the truncated image to full size using WinHex, but probably DCopyNT would also have worked well. I didn't try it here, though. I liked very much the way the spreadsheet suggests the number of directory entries to be used. I think it might also suggest a Volume Serial Number. Here's a suggestion of how to do it. The quotation below is taken from Brian Carrier's "File System Forensic Analysys", Addison-Wesley, 2005 (ISBN 0-321-26817-2) Chapter 10, p. 258. Here's a link to the reference cited in the above quotation: [Wilson 2003]. Keep on the great work! You do rock!

AFAIK, GDISK can do it on DOS, Win 9x/ME and Win XP. WinHex can do it on Win 9x/ME (sometimes) and Win XP. Under DOS or Win 9x/ME, any fully zeroed/randomized device that Windows cannot mount but which respond to SCSI commands can be recovered by Adaptek's AFDISK 3.34. Both AFDISK and GDISK will create an MBR and a HDD structure, but that can be changed afterwards, when Windows is already capable of mounting the device, by using WinHex or any other sector editor. AFDISK 3.34 is free. Did you try it?

Well, Drugwash, IMO what blorked your system was the .inf inside USB20DRV. Of course the files it contains are OK for your system, provided USBSTOR.INF is edited to load WDMSTUB.SYS with USBSTOR.SYS. Now, adding the untested (AFAIK) USBSER.SYS from XP SP3 didn't help any, either. Fact is, I tested it with WDMCHECK.EXE, and it turns out to have the same 3 unsatisfied dependencies that the USBSTOR.SYS (v. 5.0.2195.6773) from USB20DRV has. On the bright side it means it should work, provided it's also loaded with WDMSTUB.SYS, and this means finding the .inf that sets its registry entry and editing it too. The downside is it may be more than one .inf... USBSER.SYS is for the USB virtual serial port, which is mostly used to support USB modems, AFAIK. Here's a screenshot of WDMCHECK's output:

There are too many utilities that deal with reading/writing the first sector of physical devices. It'd be much more useful to have one outstanding utility capable of writing/reading the first sector of an image and creating boot sectors and MBRs there at will. I would concentrate on that. The ability to create custom images from scratch, in a user-friendly way would also be welcome. Just my 2¢, of course. mkdosfs is limited in that it doesn't bother with creating bootable images.

I've moved the posts I thought would really be best in the superfloppy thread. Should I move more posts? PM me your comments, please. This post and the one above it are candidates for deletion as soon as we are all agreed upon this latest split/merge operation.

I think, with all that's been said about it, till now, that the best divide between floppy and superfloopy remains 4.0 MiB (and no MBR nor partitions, of course). This little beauty arrived by snail-mail yesterday. Yay! Its true size is 125,960,192 bytes, and it's not quite empty, as there are some patterns written to many sectors, besides the skeleton MBR, PBR and FATs (which are FAT-16). The attached .7z contains a full image of it (acquired with the write lock set, so forensically sound), and a fully blank image of the same size, to help finding fast the non-zero regions, for those using Beyond Compare or analogous utilities. 20110805_128MB_SD_Card.7z

@Multibooter: Well, gdisk can do it, but it'll write an MBR there. So hexediting it subsequently would be in order, to create a floppy-like format. And WinHex template editing will let you do it relatively easily by hand. I think even when unregistered WinHex will allow you to do so, but of that I cannot be sure, since I'm a registered user for a real long time already.

Wow! Now, using your common garden-variety FDD as the criterion is something that sure hadn't crossed my mind at all. Which, BTW, also puts the frontier at 2.0 MiB, the maximum the common drive can format/write/read... It does make sense, however, I guess.

Some BIOSes (and the one for the Asus A7V600-X is a case-in-point) when set to boot an "USB ZipDisk" will boot a pendrive having an MBR and exactly one partition, regardless of if that partition is active or not, as A: (and, of course, will do so also with a real USB ZipDisk). After the device is booted all sectors preceeding the Partition Boot Record (PBR = the Boot Sector of the given Partition) will be unaccessible. It seems that those BIOSes use the MBR to locate the PBR and then will set it as LBA 0, thus rendering the preceeding sectors unavailable. So this creates problems to use how a device mounts at boot as a criterion to define floppy-like and HDD-like. I prefer the presence of the MBR makes a device HDD-like and its absence makes it floppy-like, regardless of the way it can boot, for the above reason.

Well, for 1 GiB you can simply add Xeno86's modified VCACHE.VXD, and it should be stable. Alternatively you can use Usher's method (link and link), and modify both SYSTEM.INI and SYSTEM.CB, with the following statements: [386Enh] MaxPhysPage = 40000 ; 1024 MiB [vcache] MinFileCache=16384 ; your HDD cache size (optional) MaxFileCache=393216 ; size recommended for 1+ GB RAM Now, bear in mind that the idea is to add those statements, but not to remove any other statements that may exist under the [386Enh] or [vcache] sections. If SYSTEM.CB does not exist, it must be created... it's just a plain text file, like SYSTEM.INI is, and it should be in C:\WINDOWS In fact, you may also use Xeno's VCache and add just the MaxPhysPage = 40000 under [386Enh], to both SYSTEM.INI and SYSTEM.CB... But I bet just adding Xeno's VCache shall be enough. Do let me know your results.

An IBM 5081Datacard, for those who never saw one.

OK. But the table you provided is for 82 tracks. And almost all FDD made after 2000, including my quite unremarkable Samsung SFD-321B Rev. T4 (manufactured in Feb 2002), and the Mitsumi D359T7 I've just decommissioned, are capable of formatting/writing/reading 83 tracks reliably. This pushes up the max capacity on ED disks to ~4,150,000. Then I think 4.0 MiB as a round-number limit is a good number, after all. Can we agree on using it to define the frontier between floppy and superfloppy?