dencorso

It's Maximus-Decim's Native USB Drivers (NUSB) for 98 SE, also findable here: Windows 98 USB Mass Storage Device Drivers.

May she RIP.

Seems I was right, after all: I converted the inner megafloppy (690 MiB !) image to MS-DOS 7.1, and it booted all right, just as before. reanimatolog rocks!

Frédérik (Reinhard) Mey - Le Politicien BTW, there's a version of it in German, too, named " Was kann schöner sein auf Erden als Politiker zu werden"...

Yes! That's it. But what I can do is move the contents of a short post to the next, especially when the posts are subsequent, then liberating an empty post that I can prepend here. This changes the thread ID number and start date, but that's not impotant in this case. I've just done that. So now you, Multibooter, have an empty 1st post to fill. I'm sure you can manage it from here. The post I've moved used to precced this one and it's contents are preserved in as the material before the second quote. Please use jaclaz's converter on the links to posts you will surely have to add, in the process, so that the links will be in a form that is more permanent.

No, soory. I don't think that can be done by a smod, at least, not in a straightforward manner. But I'll think about it and see what can be done.

Glad you liked it! Now, that's from 1982... I've never seen a video clip of it. Sorry.

A new, consolidated list has been created and stickified here, and must be used from now on. There's a link there pointing to this one, just in case. This thread is now closed.

@jaclaz: Sorry! I hadn't time for any tests today... But I did write this handy little app to check and change the Media Byte. Please test it thoroughly and let me know of any bugs you all find. Enjoy! Later edit: Just tested FAT12build.cmd. Works beautifully. Bravo! @RLoew: Are you implying that it wouldn't boot were it set as MS-DOS 4.1 boot disk, instead of a FreeDOS one? That sure would be an interesting finding. So I have a new test to perform, or have you tested it already? It was my understanding that the 36 MiB limit stemmed from the classic CHS BIOS 1024 cylinder limit when combine with The El Torito Standard (section 4.1, p. 14) 2 heads and 36 sectors-per-track, which I presumed the El Torito loader enforced for Media Type 3 booting... And, in any case, both heads and sectors-per-track are also set in the BPB, while the number of cylinders is not. Am I wrong, then? cheltomb3.7z

Saint Tropez - Femmes Fatales http://www.youtube.com/watch?v=ROpPF8sp5Ds

While the sfloppy method appears to have limitations, the ISO created directly using the Free ISO creator works OK both with MS-DOS 7.1 and with FreeDOS 1.0, so that whatever may be the problem, it appears to be related to the ISOHDRs... It simply works! Yay! Now I know of a way to edit the ISOs, without having to recreate them: set the Media Byte=0, edit the .ISO, then set it back to 3. If a custom Validation Block is being used (optional), then that has to be restored too, because UltraISO recreates it, on editing. And, in the process of testing this, I've also demonstrated that any value, zero inclusive, set as the System Type = Partition Type Code works, no matter what (so, it is as it should be: since there is no partition in the boot image, the System Type byte is ignored).

The El Torito Standard and Andrew Smith's Supplement to it let a careful reader understand that, when a floppy is emulated, it's booted by the BIOS as if it were a real floppy disk (the only difference being that the Int 0x41 pointer is not valid at boot time [standard, section 4.0, p. 14]), CHS being used. It's also stated [standard, section 4.1, p. 14] that a fixed head number (2) and a number of sectors per cluster dependent on the media byte, thus correponding to that used by the floppy format being emulated (15, 18 or 36, respectively) are used. But it's further stated that the number of cilinders used is fixed at 80 (care in reading the Standard: hexadecimal numbers are used everywhere), so that the undocumented fact that up to 1024 cylinders are acceptable is a precious piece of information uncovered by RLoew (as also is the undocumented fact that the > 32 MB sector count in the BPB is acceptable for FAT-12, which pushes the maximum limit of the FAT-12 system all the way to about 128 MiB). Of these facts we're all convinced by now. Of course the limit for a El Torito floppy emulation *is* 36 MiB. Of course a DDO would be a solution to circunvert it. But what's beautiful in reanimatolog's solution (burn this proof-of-concept image and boot it to see for yourself) is that he avoided the need for a DDO by lateral thinking and used, instead, a perfectly normal no-emulation 4 sector boot image, called bcdwboot.bin, that loads a further 27 KiB file named bcdw.bin from the CDFS part of the CD, then transfers control to it, and it reads a configuration file named bcdw.ini (or bootcat.ini in the various versions of BCDW), and then bcdw.bin either presents a boot menu or boots the default entry if so instructed, by loading, by itself the image pointed to in bcdw.ini. When bcdw.ini actually loads the image, the El Torito routine in the boot part of BIOS has finished for a long time already, so that its limitations don't apply to bcdw.bin (which is a "normal application, from the BIOS POV, since it thinks booting is already over). The boot extension created by reanimatolog reminds me of the boot sequence in the NT-OS Family so much that I believe it may have been one of the sources of inspiration during the process of crating BCDW. That's how reanimatolog (wherever he may be nowadays) succeeded in doing the "impossible", and way back in 1999 or thereabouts! It's a real pity his beautiful solution never got very popular or widely known, AFAIK.

Back ontopic, please! I've done too much thread surgery already. Here's the progress we've made: 1) The 36 MiB floppy image had to be created by hand, but that's done (by myself), and it's available for download. 2) It was truncated. That's been solved by using DCopyNT (by Jorgen Bosman). 3) The image is empty (at least that's what the FATs say...) so it must be populated): VDM (by jaclaz) / VDK (by Ken Kato) solves that nicely 4) The bootable ISO must be created. That's solved now by using The Free ISO Creator, by miniDVDsoft. 5) I've used Nero 6.6 to burn the ISO onto a physical medium (a mini-CD RW, in my case)... but any burner can do it, so it's not a problem. Of course there are some hexediting to be done, for adjusting the Media Type in the El Torito Boot Catalog Default Entry (and more hexediting in case one wants to substitute the boot sector in the floppy image), but that's acceptable. But what I miss is having an application to edit the ISO 9660 part of the ISO. I tried UltraISO for that, but it trashes the image. My current working hypothesis is that UltraISO might do it right *iff* (iff = if and only if) one changes the media byte to 0 (no-emulation) before editing, and then, after all is done, changes it back to 3. This is what I'm going to test from now on. And more, although 36 MiB is the largest floppy image that can be used in an El Torito floppy emulation boot, I do suspect one can use a 127 MiB (the maximum FAT-12 image) to boot, in case on uses reanimatolog's great BCDW. Since jaclaz's pointed to reanimatolog's image repository, some posts above, I think it's just fair to mention it here, too. But I'll let that for later, at the moment. BTW, BCDW *is* a great way of creating multiboot CDs, in my experience. And, for sure, if FAT-12 is not used, reanimatolog himself has already gone well beyond that (see pic) so I'm sure the 127 MiB image will work. And, for the more adventurous, the german page hosting the last alpha version of BCDW is gone, but here's bcdw201a.rar. It has MD5 = CC821E28B3ED5FC32821D0861630CD6C. The stable 1.50Z version, which I use, can be found here, of course, as always. @Multibooter: Do look into this, if you really are interested in > 100 MiB bootable diskete images working in optical media.

Yes, it works! And no, I did not use any VM, but an Asus EeePC with an external USB CD/DVD burner as the test machine.

I got that datasheet too. That's why I said I'm not sure the chip is to blame... most probably conception of the adapter board is flawed. Too bad 95% of what one finds for sale right now is that adapter I posted a pic of, in two flavours: with 2 electrolytic caps below the IDE connector (as in the pic I posted) or with 2 smd tantalum ones instead. Neither works, in my experience.

Here's what I did, using the tools I already had, and a lot of patience: (i) Tried to populate my original image with WinImage, but the result had messed-up FATs and was unbootable. I may have been unlucky in this attempt, but I did not stop to test whether WinImage always blorks the FATs or if it indeed was an unfortunate run. (ii) Tried to populate my original image using jaclaz's VDM, which relies on Ken Kato's VDK, and this worked like magic! Then I run Win XP's chkdsk on it and it reported no problems. (iii) Proceeded to boot the image directly with grub4dos, and succeeded. Then, while booted from the image, run MS-DOS SCANDISK (from Win ME) on it, and it found no problems. Here's the relevant excerpt of my MENU.LST: (iv) Fed the image to UltraISO, and had it create a bootable 185 MB mini-CD ISO, and it did so. However it was unbootable. But it had incorporated the full Floppy image and created a reasonable ISO, to start with. On the other hand, it decided it was a no-emulation boot image it had loaded. And, BTW, it blorked the boot sector, and specifically destroyed the BPB, while creating this image. So, in the Default Booting Catalog, I set the media type to 03 and the partition type to 06 (!, but probably it could have been any value), and, using WinHex, copied the known-good floppy image again, over the blorked image UltraISO had included in the .ISO (they did have the same size, of course). I saved a copy of the floppy image blorked by UltraISO and compared it (with Beyond Compare) to the known-good one, finding that all the damage done was solely to the boot sector (so I might have copied over again to the .ISO just the boot sector instead of the whole image). The ISO 9660 part of the image I populated with 3 videoclips, just to fill space, and the full ISO ended up having a 91 MiB size. (v) Fed the image to Nero and it burned it into a mini-CD RW, which it did without complaining. (vi) Booted the freshly burned CD and took that picture I posted yesterday.

I'm currently working on it. Whatever you do, don't buy the ones labeled HXSP-071218! (see pic below) They only work with 40 wire ribbon cables, thus limiting the interface to Ultra ATA-33 (or ATA-4), and slow a SATA drive to a crawl. Unfortunately, those are the most commonly findable on eBay. They are based on the SunplusIT SPIF223A chip. However, I cannot, at this moment, decide whethter the HXSP-071218 are just the result of a flawed project, or if the SPIF223A is really flawed itself. And be sure to buy one that has a jumper (or switch) for MASTER/SLAVE selection. Apparently the best are based on the Marvell 88SA8040, but those are not easy to find. The most widely known among them are those made by Rosewill. See this thread, elsewhere, for more details. I've bought two different ones, which should be arriving soon. After I test them, I'll let you know.

Install RP9.7.2, without setting any skining (I'm sure it's possible, that's how I use it), and it'll take care of your resource problems.

The Mission - Severina

And work it does! I can boot the image directly, with grub4dos... and I can boot it as the boot sector of a CD! Yay! Thanks for the great info!

Well, I, for one, think that any driver is way better than no driver...

This is not a marketplace indeed, but users are free to make comments about things they buy. And while RLoew cannot advertise his products here, he can give free support and info. That said, I think an owner of 7900GT with 256 MB, if he/she hasn't any problems with it, does not need any patch. It's as the saying goes: "If it's working, don't fix it!"

GPRS modems are a PITA! Welcome back, Drugwash! You've been missed!

Here is the appropriate FAT-12 36 MiB floppy image. Usually double-compression doesn't give good results, but this is an unusual file, so I gave it a shot, and it worked! @jaclaz: Now it's up to you... can you convince mkisofs to create a bootable .ISO from it? Empty_FAT12_36MiB_Floppy.rar

CAUTION: Do *NOT* buy any adapter based on the SunplusIT SPIF223A chip! Full thread Summary, thanks to bphlpt Suggestions for improvement, by PM only, are welcome. BTW, the real thread starter for this thread is shae, and the original initial post is the next one. I've inserted this post just to add the Summary to the thread, but that also makes me the apparent OP, so I decided to add this note to point out who the real thread starter is.