dencorso

I see. While I do strive to be clear, some times ambiguity gets the best of me. So, just to set things right, what I wrote was: My intention was that those "it"s should mean "your software utilities", not Nero nor UltraISO. But "it" is too vague. Sorry, my bad.

Are you using Tihiy's Revolutions Pack?

Nobody, me included. I said I looked (after all I have both installed) and neither Nero 6.6 nor UltraISO 9.36 (the latest) do, AFAI can see.

The MS-DOS compatibility mode is in windows, not in the BIOS. Google is your friend: KB130179 and KB151911 are a good enough start.

I use both Nero 6.6 and UltraISO. I might be intersted if it gives me fine control to build unusual bootable .ISOs (as you said it does). I don't see how I can use a 36 MiB image with either Nero or UltraISO. However it'd be a bonus if it does run both on 9x/ME and XP, although a DOS only program would be welcome too.

I loved DCopyNT! I didn't know it. Thanks a lot! Yes, I agree the image is truncated, not sparse. And, since I've created the full image, while testing DCopyNT, the image attachement is updated. I was involved with too many tasks all at the same time, so I was unable, at first, to follow all the links you've provided. Well, now I'm gonna grab some sleep. Tonight I'll probably add the required FAT-12 36 MiB image to this thread. You rock!

Sure! The one and only of its kind: RLoew's (which is not free). If you have interest in it, there's more info here. I'm a satisfied user of it. My own ramdisk performance tests will show you why. Note that the Gavotte is free software, but works only on the NT-Family of OSes (and it's the one I use on XP SP3). RLoew's non-XMS RamDisk is not expensive and is worth the cost, IMO.

Well, that's a can-of-worms I'm saving for later. I can always hope NTLDR will work, until proven wrong by a test. But first we must know whether the boot sector will find NTLDR, to give it a chance to work (or fail)...

Thanks! Of course, the link is now changed. I'm working at it. Now, you, of all people, should now better than using "friendly names" in giving links... Next time, please do it by post ID number. Of course, I reckon not even post IDs would hold, in this case, since I'm splitting posts. Use BXIMAGE.EXE from Mtools for Bochs to create an all-zero file of the right size, then: copy sparse.ima + zeroblock.ima /b /v As I said before, should be a piece of cake. Now, I'll concentrate in: 0x03: 1024*2*36 * 512 = 37,748,736 When we have it and test it OK, I can create the other two as well. Just for the record, my images are created by hand, and I brush every single bit twice, before adding it. It also means threre's ample space for things to go wrong, too, so always check them for correctness, please.

Well, since the 100 MB image works OK in a real Zip100, I think the next step would be to create a bootable FAT-12 128 MB SD card and boot from it, for us to have an air-tight proof-of-concept that the real limit of FAT-12 is 128 MB. This may take some time, because 128 MB are not findable around here anymore... I'm going to get a good one, preferably a SanDisk or a Transcend from eBay. When I get it, I'll post my results. Would Bart PE or LiveXP boot from FAT-12? Can the FAT-16 NT boot sector be coerced to work with FAT-12? Seeing how FAT-12 and FAT-16 share code, I bet it would. What do you all think about it?

Now you know what incompatible means. It has a nVidia GeForce 7025/nForce 630a chipset. You probably are running in DOS compatibility mode, for lack of drivers. What;s the size of the HDD's you've booted from? And of the pendrives? Of course, it probably can be solved by adding both RLoew's >137GB and SATA patches (which are not free). If you have interest in them, there's more info here.

Here is my first attempt at creating a 36 MiB image, as per RLoew's specification, and my first attempt at a sparse image. I think I did it correctly, but please do verify it. WinImage loads it OK. It's a 4 kiB cluster FAT-16 filesystem, which follows closely Multibooter's original 32 MiB image. It should be straightforward to add zeroes to create a full image, if necessary. Fd-36Img_Full.7z

Never heard of vRamDir before... But, in any case, it clearly uses up the System Arena. Do read, at least, KB125691 and Igor Leyko's Article (in English, by GreyPhound and also in Russian, so one can see all the figures), and things will seem clearer.

Santana & Indie.Arie - While My Guitar Gently Weeps

I've done my best to split the CD floppy emulation without mangling either part. It's not perfect, but I think it worked... BTW, the image below wastes not a single sector! What did I do? Easy: just added the formerly unusable 11 sectors to the root directory, which now holds 688 entries. Empty_10sec688d_FAT12_SFloppy_Zip100.7z

Sure. Done. Here it is. And by mounting using your VDM and chkdsk (on XP SP3, of course), I confirm exactly one cluster gets added, as expected. So here is a lesson for me: never round down the sectors per FAT number, even when the residue is minimum. And BTW, just for the record: I originally put 2 instead of 64 heads, but when used in a real Zip100, the ZipDrive corrects it to 64 heads silently! And as the geometry is irrelevant, because the ZipDrive knows for a fact that there are exactly two heads and, since there is no MBR in a superfloppy, it never really gets used, because the 1st sector of the volume is also the 1st sector of the disk, no translation being necessary, IMO. Ken Kato's VDK doesn't care either. But other programs may be misled by it... Empty_10sec_FAT12_SFloppy_Zip100.7z

@Multibooter: The Medium ID Byte occurs in three places, at offsets 0x15 (BPB), 0x200 (1st FAT) and 0x1400 (2nd FAT). In the image attached to this post I've changed them all to F8 (a hard disk), instead of F0 (a 1.2, 1.44, 2.88 floppy or a superfloppy). Let's see how GRDuw likes this new image. @jaclaz: While you've got the numbers from the BPB all right, what is relevant here is: Total sectors: 196608 and Sectors per cluster: 64 So 196608 / 64 = 3072 clusters Now, each cluster uses 1.5 bytes per cluster in a FAT-12 so this means 3072 * 1.5 = 4608 to which you may add 3 bytes which is the "FAT start signature" So we have 4611 and 4611 / 512 = 9.006 sectors per FAT-12 Now, the question is, what do we do with the 0.006 sector? It means 3 bytes in the FAT-12 or 2 clusters. So, to be on the safe side there should be 10 sectors per FAT-12, which is what mkdosfs would create, if used. I decided it was too much, and used just 9, because, in my reasoning, 196608 is the total sector count, but we should subtract from them the boot sector, 18 sectors for two FATs and the root directory. So, since we have 512 root entries and each entry takes 32 bytes, that means 32 sectors are used for the root directory! Now 1 +18 +32 = 51, and so, the available sectors are just 196608 - 51 = 196557 and 196557 / 64 = 3071.2031 clusters or 4606.8047 + 3 bytes per FAT-12 or 9.004 sectors per FAT-12. Since my really precious data wouldn't ever be in all in this image, anyway, I decided to round that to 9 sectors per FAT-12. And that means you're right: when the last cluster happen to be filled, the second FAT might be trashed. Then again, I suspect DOS simply would never use the last cluster, because it *knows* there are just 9 sectors per FAT, so this image has 32 kiB of unusable space, which I find quite acceptable. On the other hand, if I had used 10 sector per FAT-12, that would change the numbers again and 1 +20 +32 = 53 --> 196608 - 53 = 196555 --> 196555 / 64 = 3071.1719 --> 9.003 sectors per FAT-12, so two more sectors are used, of which not more than 3, and, in fact, probably only 1.5 byte would ever be used... If you transfer the image to a real Zip100 and fill it to the brim, let's see whether DOS destroys the start of the second FAT, thus corrupting the disk or if, as I presume, it'll just consider the disk filled when there's no more free space in the FAT. You've got me curious. And, just to keep related things together, I think it proper that I should quote this older post here: 4078 is based on the standards. DOS and Windows computes the number of available Clusters then tests it against a threshold. If below, assume FAT12. If above, assume FAT16. To complicate things further, DOS and Windows do not even use the same threshold. DOS uses 4086 and Windows uses 4085. A partition could be interpreted as FAT12 by DOS and FAT16 by Windows. FAT16/FAT32 discrimination is even worse. DOS uses 65526 as a threeshold, Windows tests the 16-Bit # of Sectors per FAT field. Still according to the above cited Wikipedia page, under Linux, FAT12 is limited to 4084 clusters, adding to the confusion. Empty_FAT12_SFloppy_Zip100_F8.7z

Guns N' Roses - Don't Cry (original lyrics)

Sfor, I suspect I have an identical adapter on hand... Could you please provide pics of both sided of your adapter, after the modification, together with a description of how to modify it? Thanks in advance.

Thanks a lot! I've replaced the image by a corrected one. Now, the problems you've pointed out are fixed, and also now the Media Descriptor Byte is the same in the BPB and both FATs. In fact, the image has a working boot sector, so adding MS-DOS 7.10 IO.SYS and COMMAND.COM (and optionally a 0 byte MSDOS.SYS), using WinImage, should be enough for it to be able to boot.

My (very free) translation of an excerpt of an Imation Japanese FAQ, readly findable by googling "FD32MB.SYS":

Now it is! I hadn't realized that WinImage is able to deal with sparse images (images that omit almost all zeroed out sectors), so it was a pleasant surprise when it dawned on me the image Multibooter uploaded is a sparse one. Of course I should have noticed that it was too small to be a byte-by-byte image, but I actually only noticed it on opening that image in WinHex. That's good news!

@all: In case you all notice that some posts are missing, that's really a fact. I've just created the new thread: On Bootable CD's Floppy Emulation, split from this one, as per your request. Since the earliest post of the split was RLoew's, he became the OP of the new thread. If you feel I missed some post that should be there, instead of here, please let me know. @Multibooter: Thanks for the image!

@Multibooter: Would you please attach a zipped WinImage .IMA of a blank, fresh from format, 32MB floppy? That would be interesting to study and can be useful, inclusive as a staring point to creating the 36MB floppy image RLoew mentioned. Thanks in advance.

There's no reason to. It's use is to prevent delivery trough Automatic Updates, which don't actually exist on 9x (not sure about ME).