dencorso

To me, common floppies formatted to 32 MB by LS-240 drives and those 40 MB click! from Iomega are superfloppies already. So the 36 MiB FAT-12 image we are discussing from the start of this thread *is* a supperfloppy image, not a floppy image. And it'll get A: on boot, and it has a single logical device starting in a boot sector, so it has all the characteristics of a floppy (or superfloppy). And that's why the original thread had superfloppies in the name, which ended up causing the split of the original thread into two threads. But then it dawned on me that it's not at all clear what idea each of the participants in this discussion has about what is a superfloppy. And I realized that not even to me it's actually clear how big a floppy may become, before starting to be a superfloppy. So I posted about reaching a consensus about it. It was relevant enough to cause a thread split, even if it may be irrelevant for practical purposes (I mean: actual usage or the way they are seen by any given OS).

OK. Except for formats having their own 0xFX code, 0xF0 for what will become A: or B: and 0xF8 for all other cases is a rule-of-thumb that makes sense to me. However, 1966080 Bytes is 1.88 MiB, which is still < 3.5 MiB... and I don't think Amigas can use a "2.88 MB" drive. Or are you suggesting we should put the floppy/superfloppy frontier at 4 MiB GiB? What is a superfloppy for you? Please elaborate.

Well... since we've agreed that a filesystem is a bunch of bytes (or whatever) that can be divided in a System Area and a Data Area (we did agree to that, didn't we?), I'm thinking that there's one more concept I'd like to find a common terminology for: (i) By looking at the floppy disk format list I posted, we can easily see that the maximum a common "1.44 MB" FDD can actually format is a 83 * 21 * 2 * 512 floppy, which means 1,784,832 bytes or 1.70 MiB (before adding the filesystem), the so called "1.74 MB" floppy. (ii) The "2.88 MB" floppy uses a special FDD, which can create twice the sectors the normal one can. So I conclude that the most extreme floopy format possible (although I've never heard about anyone ever having formatted a floppy like this) should be a 83 * 42 * 2 * 512 floppy, which means 3569664 bytes or 3.40 MiB (before adding the filesystem), which might be called a "3.49 MB" floppy. Hence, I propose that we use floppy disk format or floppy disk image to refer solely to formats or images having up to 3.5 MiB of total capacity, and that anything above that should be called a superfloppy. Of course, floppy formats or images must represent a single device, starting in a boot sector (or be fully zeroed). Of these, all that have a capacity >= "1.44 MB" would receive a Medium Type Byte = 0xF0. Anything having a MBR and partitions (regardless of being a ZipDisk, a pendrive, or other hardware, or their respective images) would be called a "hard disk image/device" or "hard-disk-like image/device", and have Medium Type Byte = 0xF8. Please let me know your opinion.

I know... but it's handy, all the same, provided it's used just to peruse the hives, not to edit them. Well... that's the problem with quoting, instead of writing from scratch: some things get out of context. That comment was addressed to Dave-H, in the thread that quote originated from, not to the OP of the present thread, who asked for a command-line tool. My, bad. Sorry!

Just for the sake of completeness: While I wrote that with unmounted hives from other profiles in the same system, it of course applies to any unmounted hives, so certainly a mounted WIM image qualifies, too.

BTW, it's been so long since I starte doing it as a routine that I even forgot to tell you about it, but I'm sure your hardware is a good case-in-point where disabling both ACPI and APM would contribute to a much improved stability.

Never mind Event 1517 for the time being. Did you go through all the steps in those links in the above quote? Also, did you read this? Can it be relevant?

Hi, Art.Welcome to MSFN I'm confident you'll like it here a lot.

The Table below is quoted from Thom Hogan's "The Programmer's PC Sourcebook", 2nd. ed., Microsoft Press, 1991 (ISBN 1-55615-321-X) Section 2, p. 26. IMO, it's the most autoritative offical source for this particular info. So I think we sould, for our purposes, adopt it as the standard reference, and use the media types as described in it, and solely for those formats. In all other cases I do favor 0xF8 for HDD and 0xF0 for all formats >= "1.44 MB" (= 1440 kiB, that is 1.41 MiB, unformatted and 1.39 MiB formatted), which, BTW, is the common pratice, so, by now, a de-facto standard. BTW, attached is a list of all the formats I've ever heard about, for 5.25" and 3.5" floppies, just for the record. FDFORLST.7z

And here is what you didn't quote: Meaning that's as the title in the page says, is the: TeraByte Plus Package, which does include the SATA Patch and the > 137 GB Patch (each @ US$11 apiece), among a whole bunch of other software: From that package you need, at most, just the SATA Patch and the > 137 GiB Patch , which are sold separately. With all due respect, take your time to actually read your sources, before you go ahead (mis)quoting them.

You can use Nuno Brito's handy RawReg to peruse unmounted registry hives, like NTUSER.DATs from other profiles than the one currently logged on. RawReg also should let you modify them, but that doesn't always work, in the current version, so If you need to do that, use Erwan.L's offlinereg instead, althought it's less user friendly.

You mean this: USB20DRV.EXE? Well, it's complicated... But it sure has problems. But it does contain some really interesting executables, some of which I'm using right now. I think the problem still lies in the .inf. Your machine has USB 2.0 and works OK with NUSB 3.3, is that right? If so, we can work it by hand at installing that update, without using the inf, and you'll see it does work. One more question however, is your machine's southbridge a Via chip? Or are you using a USB add-on card based on a Via chip?

Hi, Maximus-Decim! This post is just to say I support LoneCrusader's proposal. I do think that, with the current widespreading of USB Mouse/Keyboard combos, USBCCGP.SYS is a needed addition to NUSB, and the USB Printer support is equally welcome.

dencorso said *do* *NOT* load EMM386.EXE on the config.sys. I should have said "do not load EMM386.EXE in your machine ever, if you intend to run Win9x/ME". It's not needed at all, and it'll only help make Windows even more unstable. However, adding both the EMMExclude line and the MinFileCache line to SYSTEM.INI and SYSTEM.CB can do no harm, so do it, just in case. I doubt they'll help any, but, then again, why not?

Note that the quote from www.win.tue.nl must be read with due care. What you quoted is what they call "FAT-12 BPB", which is actually the original BPB. That one contains only the 16-bit number of sectors entry, so it'd be impossible to create any image bigger than 32 MiB (-1 byte) with that one. We already know, in fact this thread is full of attached demontrations, that we can use the Extended BPB (wich they misleadingly call "FAT-16 BPB") with FAT-12, and that's how our bigger floppy images are created. So, this would be the complete description of it (here all offsetes are in decimal and start from 0): Of course, the above table is not really a quote, because it represents the merging of two different tables form the source. Also of course, this is also described on the already mentioned MS FAT-32 Specification v. 1.03 (2000), so what is most interesting are the additonal comments or details. 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? I don't think you've got that right: to me it seems to refer to byte 0x24 = 36 which is the BIOS drive. Not the Media Type Byte. Read it again carefully: Here are two other quite interesting references: SuperVinx (a great complement to the Starman's Pages) and... J. de Boyne Pollard's FGA on OEM Names (which I'm sure you know, but not everybody is familiar with).

Get a DOS driver for SATA DVD and load it through CONFIG.SYS

Well, jaclaz, for the sake of agreement and common terminology I'm willing to accept a filesystem is something that can be divided in two parts: A (i) System Area and a (ii) Data Area The System Area comprises the Boot Sector, the FATs and the Root Directory (for FAT-12/16), while the Data Area comprises the actual files, the sub-directories and (just for FAT-32) the Root Directory. (adapting what's stated in Section 6.1.4 p. 5 of ECMA-107, where that statement refers to what they call "Flexible Disk Cartridge", a.k.a. floppy disk). I think this isn't the right place for us to philosophize on the ontological question of what a filesystem actually *is*. That said, I cannot avoid thinking that if one were a file inside the filesystem, the *only* way one can actually access the System Area is by taking the Red Pill. Now, since we've collected some links to standards already in this thread, I'll add some more, just for the record: MS FAT (FAT-32 Specification): v. 1.03 (2000) and v. 1.02 (1999); ECMA-107 (FAT 12/16) and ECMA-119 (=ISO 9660).

All the free ramdrives are XMS ramdrives. Adding a XMS ramdrive will fill your System Arena at the drop of a hat, and it'll crash. That's a sure way to crash your system seven ways to sunday. You seem not to realize that what I led you to do is a horrible kludge. But I never said or implied it wasn't. With 512 MiB of Video RAM, 3.5 GiB of RAM, running a SATA disk in compatibility mode and having no mobo drivers, your system is in a *very* unstable state, on the very brink of crashing all the time. The best XMS ramdrive is Frank Uberto's XMSDSK v 1.9I, for which there's a link in the 1st post of the > 1 GiB RAM thread. But rest assured it'll crash your system horribly. If you don't believe me, just install it and run a scandisk surface test on the ramdisk from inside Win 98SE. Do it using Win ME SCANDSKW.EXE and DSKMAINT.DLL (available in BHDD31, for which there's a link in the > 137 GB HDD thread), to be sure you're using the best version of them and be sure to set the /NUMHANDLES=64 switch to the HIMEM.SYS entry in config.sys and don't load EMM386.EXE. That's the very best you can do. In your system I doubt you'll be able to run a 256 MiB ramdisk, without crashing... and there's no way you'll be able to run a ramdisk of 1 GiB or more, which would be what you'd need to put the swapfile in it. Without RLoew's patches (and non-XMS ramdisk) you've got no chance of attaining a stable configuration. But you don't need to believe me: do it yourself and see it crash. And don't get me wrong: I'm not, in any way, set on getting you to buy anything, I'm just telling you what the facts are. My own experience is this: with all the needed drivers and a 32 MiB Video Card, plus up to 1.5 GiB RAM, I managed to run stably without any paches, but to go beyond that, only with RLoew's patches I was able to attain a stable configuration. Since both configurations are stable I've kept both in the > 1 GiB RAM list, so you can go there and compare them.

Since the filesystem resides outside itself, we're saying the exact same thing. We need 12 sectors for each FAT-12, plus 1 for the boot sector (or PBR) plus (at least) 1 for the root directory. That means 12 +12 + 1 +1 = 26 sectors used by the filesystem (and which cannot be addressed using the filesystem itself), if one is satisfied with just 16 root directory entries. So here, instead of just one, I'd use 7, which would result in a total of 32 sectors for the filesystem, and 112 root directory entries. Or, if I though 112 too little, then use 7 + 32 = 39, just to keep to full clusters, and it would then mean 624 root directory entries. That's my way of doing it. As I said before, here, YMMV. 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.

Before anything, we're entering a domain where YMMV. That said, I'm convinced 4079, meaning 4078 addressable clusters plus 1 for the fs is the safest choice for FAT-12. By the same token (2^16)-18 clusters, plus enough space for the fs. I've never created a FAT-16 by hand, but I remain firm on the idea that -18 is the magic number. If one follows the Wikipedia, and uses -12 instead of -18, there might be compatibility problems, because not everyone agrees about the allowability of using or not 0xFF0 - 0xFF5. I see no valid reason for courting trouble in this way. Now, the cluster size strategy, for FAT-12, is that, given a physical device size or having decided on a given image size, one divides it by a random bytes-per-cluster number (not so random as it must be a multiple of 512 and cannot exceed 32 kiB)... and look at the result: if one gets more than 4078 the bytes-per-cluster number is too small. I've not though about this for FAT-16, but I believe a similar line of reasoning must hold for it, too. As for the number of entries in the root directory, my guess is: (i) it must exist: so giving it just one sector means 16 entries, which is the bare minimum (actually used by MS in the MDF floppy format ), and (ii) the maximum, since BPB-0x11 is a word ( which, in principle, can have values ranging from 0 to 65,535) and directory pages must be sector sized, considering the last multiple of 512 that can be used is 65,024 and each entry 32 bytes, should be a huge 2,032 entries. That means it ranges from 16 to 2,032 entries.

Here you go! This *should* get your system booting (provided you also rename ESDI_506.PDR). system-ini-cb-new.zip

If you attach a zipped copy of your system.ini and system.cb files, I'll put the correct MaxPhysPage and MaxFileCache settings in the right places for you. Then, you install the system until it crashes, then boot to true DOS with a floppy disk, go to the WINDOWS folder, rename SYSTEM.INI to SYSTEM.OLD and SYSTEM.CB to SYSTEM.CLD, and then copy the edited files I'll have provided to the WINDOWS folder. Then go to the WINDOWS\SYSTEM\IOSUBSYS folder and rename ESDI_506.PDR to ESDI_506.OLD. Then reboot and you should be able to fully boot this time, although it may be slow. Does it sound like a plan?

@Drugwash: It's wonderful to have you fully back! Even if jaclaz already gave a pointer for the El Torito Standard, here's it again, just in case. A very simplified and handy version of ISO9660 is here, too, as also is Andrew Smith's Supplement to it the El-Torito Standard, although I don't think we'll be needing either for the following comments and considerations: i) The El-Torito Boot CD/DVD is simplicity itself. Remember all Optical Media sectors are 2048 bytes ( = 0x800 bytes, in hexadecimal). El-Torito follows ISO9660 and its predecessors in counting the Optical Medium's sectors starting from 1. So one goes to sector 17 (= 0x11) and reads one sector. The first 80 bytes of this sector contain the El-Torito "Boot Record Volume Descriptor", the contents of which are described in Figure 7, p. 13 of the Standard. Of relevance, there's only one pointer, a dword (= 4 bytes) at offset 0x47 (or absolute disc offset 0x8847), which contains the *sector number* of the next structure, which is the "Booting Catalog". ii) So, by getting the value at the absolute disc offset 0x8847 and multiplying it by 0x800, one gets the actual address of the "Booting Catalog", goes there and reads one sector. This sector contains two structures: the first 32 bytes are the "Validation Entry", which must be there, but is otherwise irrelevant to this nutshell description. Its contents are detailed in Figure 2, p. 9 of the Standard. The next 16 bytes are the really relevant structure, called "Initial/Default Entry", the contents of which are described in Figure 3, p. 10 of the Standard. Of relevance, there's only one pointer, a dword (= 4 bytes) at offset 0x08 (of this latter structure, in reality at offset 0x28 from the start of the sector), which contains the *sector number* of the next structure, which is the actual "boot diskette image or no-emulation boot code". Observe that the "Initial/Default Entry" only provides a pointer to the boot diskette image, and says nothing about it's size, which must be obtained from the image's BPB, at the boot sector. Also in the" Initial/Default Entry" are the "Boot Indicator", which must be 0x88 and the "Media Type" byte, about which lots have already been said. There's also the "Load Segment", which is the segment of the Real Mode conventional memory where the boot sector(s) will be loaded (and that means 0x07C0 when left zeroed!) and the "Sector Count", whic is the number of *512 bytes* sectors from the image (which is presumed to be the image of a diskette, hence the 512 bytes sectors) to be loaded before transferring control to that code for booting the emulated diskette. iii) Last, but not least, since I'm being punctilious here, all optical media are "discs", while their magnetic counterparts are "disks"... go figure! And, in what regards FAT, the English Wikipedia page and the Starman's Pages should be enough for almost all purposes. Note, however, that we're beyond both when we create 36 kiB, 100 kB or 127 kiB FAT-12 diskette images. My own way of creating FAT-12 images uses the following principles: There are 4078 possible values representable in a FAT-12. This means (2^12) - 18, which is a pessimistic view, because it excludes 0, 1, and all values from 0xFF0 to 0xFFF, inclusive. See notes 10 and 11 in the File Allocation Table English Wikipedia page. Now, since the first possible cluster is 2, by definition, then the last one is 4079 (in doubt count your fingers from one hand, starting from two, and you'll arrive at 6! So, considering that there are really 5 fingers, when one starts from two, one always arrives at total count plus one, and 4078+1 = 4079). And 4079 is 0xFEF, which is the last value meant to be used. So far, so good. However, the various OS use different maximum numbers of clusters for FAT-12: LINUX uses 4084 (see note 9 in the File Allocation Table English Wikipedia page), while Windows 9x/ME uses 4095 and MS-DOS uses 4086, according to RLoew's findings (this post). This really boils down to the fact that there can be no more than 12 sectors per FAT-12. With 4086 we'd have 4086 clusters * 1.5 bytes per cluster = 6129 bytes. Adding 3 to that (the first three default bytes, usually 0xF0 0xFF 0xFF), we get 6132 bytes or 11.9765 sectors of 512 bytes, hence 12 sectors at most. So, what then, is the biggest FAT-12 volume one may ever create? RLoew found out that using the "Large Sectors" count (or "Sectors 32", that is BPB+0x20) works, so we may have much more than 65536 sectors by setting BPB+0x13 to zero and using BPB+0x20 instead. So the limit is how many sectors the FAT-12 can hold. I settled on 4078 clusters * 32 kiB per cluster, so, to me, the maximum possible volume will have a net total of 133,627,904 bytes. But the filesystem structures do use space also, and we already know we need 25 sectors (1 boot sector plus 2 FATs) and the space for the root directory (which size is undefined, in principle). So, what I have been doing is to round the filesystem space to one cluster, and that gives me 64 -25 = 39 sectors for the directory, which would mean 39 *(512/32) = 624 directory entries (because each entry has 32 bytes)... Now, if I limited myself to 512 directory entries that would leave 7 unaddressable sectors in the cluster I set aside for the filesystem, as jaclaz led me to realize. So, the space needed to create a 133,627,904 bytes disk image is 133,660,672 if we wish to have a round number of clusters, which would be 4079. Of course I've made some decisions that lead to this particular value, so with different decisons it'll vary somewhat, but not much.

Sure. But mine is 7 GiB, with my rather big collection of installed applications. What I really meant is no minimization would be needed, in any case.

@jaclaz: Great idea! Let's let this new sub-thread here for now... if it proves to evolve in a direction more apropriated to the Superfloppy thread, then I'll move it there. @jaclaz and @RLoew: You two bring great news! @RLoew: Did you go renimatolog's way? I mean: is your new DDO a no-emulation El-Torito loader, which loads the remainder of the DDO? BTW, do you realize that on a 23 GB Blu-Ray (or even in a 8.5 DVD+R DL) it's possible to create a complete live Win 98SE or ME, with all bells and whistles? Maybe even with KernelEx and Aurora (= Firefox) 5? That opens all sorts of new possibilities, of course.