Jump to content











Photo
- - - - -

Need help understanding RMPartUSB parameters about super floppies


  • Please log in to reply
19 replies to this topic

#1 Leolo

Leolo

    Newbie

  • Members
  • 22 posts
  •  
    Spain

Posted 01 March 2015 - 03:00 AM

Hi people,

 

I've read the documentation of the RMPartUSB tool, but I still cannot understand what some parameters do.

Specifically, I'd like to know what's the difference between CHS, ZIP and USBFDD

 

Do the CHS and ZIP parameters add an MBR to the drive?

 

What partition type does ZIP set when the filesystem is FAT16 ?

 

Thanks!



#2 steve6375

steve6375

    Platinum Member

  • Developer
  • 7063 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 01 March 2015 - 09:13 AM

RMPrepUSB is a front-end GUI for RMPartUSB - the options are explained in the 'Tip box' in RMPrepUSB when you hover the pointer over each option - also if you press F1 you will get a PDF with lots of explanations.

 

OR - why not read the info on the website?

http://www.rmprepusb...verride-options

HTH

Steve



#3 Leolo

Leolo

    Newbie

  • Members
  • 22 posts
  •  
    Spain

Posted 01 March 2015 - 01:03 PM

Hi,

 

Well, d'oh! I had only read the RMPartUSB.txt file. I guess I should have searched a bit harder before asking :)

By the way, where does RMPrepUSB (the GUI version) put the IO.SYS file?

Microsoft says that you don't need to put it in the first three sectors anymore in recent MS-DOS versions (5.0 and later):

 

http://support.microsoft.com/kb/66530

But it's still required for MS-DOS 4.0 and older.

 



#4 steve6375

steve6375

    Platinum Member

  • Developer
  • 7063 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 01 March 2015 - 01:05 PM

It doesn't add IO.SYS. If you need to use MSDOS 4 (if you can find it) then use freedos instead or use a floppy image file (.ima) instead.



#5 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15025 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 01 March 2015 - 01:09 PM

More generally the partition ID (FAT 16 will have either a 0x06 or a 0x0E) see:

http://www.win.tue.n...on_types-1.html

has nothing to do with the ZIP format.

 

Read about the ZIP format here:

http://www.win.tue.n.../zip/zip-1.html

and here:

http://reboot.pro/to...code-and-grldr/

http://reboot.pro/to...zip-or-usb-fdd/

 

Of course your mileage may (and will) vary, example of ZIP queerness:

http://reboot.pro/to...tion-boot-flag/

 

I bet you are wrong about IO.SYS the article you mentioned is about the capabilities of SYS.COM, not about where the IO.SYS needs to be, the "switch" happened - unless I am mistaken - with DOS 7.0, up to DOS 6.22  the IO.SYS needed to be the FIRST file on the filesystem, this is the reason why BOOTPART has a command for that:

http://www.winimage.com/bootpart.htm

if you prefer, the SYS.COM starting from DOS 4.0 can "make space" to copy the IO.SYS where it should be.

 

 

:duff:

Wonko



#6 Leolo

Leolo

    Newbie

  • Members
  • 22 posts
  •  
    Spain

Posted 01 March 2015 - 01:31 PM

Thanks for the links, I will read them to get more info. USB booting in older mainboards is always a hit and miss operation! :(

Right now I'm trying to boot MS-DOS 7.1 with a Gigabyte GA-945GCM-S2L mainboard, using latest BIOS version F8d

 

My USB Flash Drive is a very old and dusty 128MB SanDisk Cruzer mini, but none of the methods I've tried have been successful.

I tried partitioning with old Microsoft Diskpart versions, with newer Diskpart versions (they align partitions differently), with Symantec Gdisk (using both CHS and the new 1MB alignment)... 

 

I also tried Microsoft's SYS.EXE tool from the Windows 2003 OPK cdrom (although it only works for fat32, it doesn't support fat16 unfortunately)

I even tried to manually install the grub4dos MBR code by copying and pasting the hexadecimal code using Runtime DiskExplorer for FAT!!

But the stubborn BIOS didn't boot. Then, when I was about to accept defeat and feel humiliated, I found info about "supperfloppies" on google and decided to give it a last try.

I typed this command line on Steve's RMPartUSB tool:

rmpartusb.exe DRIVE=9 DOSZIP CHS USBFDD ZIP

I copied all the files to the flash drive, then I plugged it, turned on the computer, selected "USB-ZIP" on the BIOS boot menu and... YESSSS! MS-DOS 7.1 booted correctly!! I'm happy at long last!! :)



#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15025 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 01 March 2015 - 01:57 PM

Good that you succeeded. :thumbsup:

 

Next time you want to boot an old, dusty 128 Mb stick, you may find interesting info on a couple old, dusty pages (shameless plug :w00t:, nowadays more like computer archeology than anything else, but JFYI ;)):

http://jaclaz.alterv...B/USBstick.html

http://jaclaz.alterv...SB/USBfaqs.html

 

I keep them untouched just to be able to show off a bit and be able to say "... been there, done that ... " :whistling:, and unless I am mistaken you re-discovered the contents of FAQ #10.

 

:duff:

Wonko



#8 steve6375

steve6375

    Platinum Member

  • Developer
  • 7063 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 01 March 2015 - 02:07 PM

You might like to try FlashBoot which is intended to get round the issue of these old BIOSes

http://www.rmprepusb.com/tutorials/113

Also, be aware that some old BIOSes will treat a 128MB Flash drive differently from a 1GB flash drive even if the contents of them is byte-for-byte identical! The 128MB will boot as USB-ZIP but the 1GB will boot as USB-HDD!



#9 steve6375

steve6375

    Platinum Member

  • Developer
  • 7063 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 01 March 2015 - 02:11 PM

Why not use RMPrepUSB?

 

Attached Thumbnails

  • CaptureDOSZIP.JPG


#10 Leolo

Leolo

    Newbie

  • Members
  • 22 posts
  •  
    Spain

Posted 01 March 2015 - 02:52 PM

Wow, great info on those links, Wonko, I've bookmarked them! The links may be old, but there's a wealth of tips and tricks there. They will be very useful next time I have to battle another buggy BIOS!

Steve,

Thanks for the info about FlashBoot, I will also keep it in my mind. Normally I like to try to solve the problems I find using the command line, but sometimes it takes away too much time, and a "ready-made" solution can be worth the price.

Kind regards.



#11 Leolo

Leolo

    Newbie

  • Members
  • 22 posts
  •  
    Spain

Posted 01 March 2015 - 06:03 PM

Guys, I've just seen this article:

http://support.microsoft.com/kb/168293

 

And it says that authentic ZIP drives use 12 heads and 32 sectors per track.

Then why are we writing 64 heads and 32 sectors per track in our FAT boot records??
 



#12 steve6375

steve6375

    Platinum Member

  • Developer
  • 7063 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 01 March 2015 - 07:00 PM

LBA translation of the drive geometry results in a translated geometry of 97 cylinders, 32 heads, and 63 sectors per track. Zip drives using standard Zip disk geometry will be unable to read the alternate disk geometry presented by Zip cartridges formatted under LBA mode.

 

So MS say there is a compatibility problem if you use 12 Heads x 32 Sectors and so you are asking why RMPartUSB doesn't also use 12 x 32 and also fail to boot??!!! :loleverybody:



#13 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15025 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 01 March 2015 - 07:12 PM

Guys, I've just seen this article:

http://support.microsoft.com/kb/168293
 
And it says that authentic ZIP drives use 12 heads and 32 sectors per track.

Then why are we writing 64 heads and 32 sectors per track in our FAT boot records??

 
Ow, come on :), you are big enough to NOT trust MS info at face value, they have a knack for writing anything in such a way that it needs to be interpreted as it never means what it seems.

I will gladly translate it for you in plain English :w00t:.
 

It has been brought to our attention that a specific ZIP drive model, the ZIP IDE Insider, behaves differently from more common (please read as external parallel or SCSI) models of the ZIP.

We don't know anything about ZIP drives and their geometry, but we are Microsoft, so we had last arrived intern have a look into the matter allowing him/her to spit out some (wrong) assumptions as if they were the "Word of God".

A single ZIP IDE Insider was tested on a single motherboard with a crappy CHS/ECHS/LBA translation code, and from the result of this test a (wrong) theory was derived that will be called from now on "The Truth", while what we observed is ONLY valid for the specific Iomega Zip model we tested on the specific (crappy BIOS) motherboard we have and while Iomega will soon correct the reported issue and - as a matter of fact - produce another 3 (three) series of internal ZIP drive, the ATAPI, ATAPI2 and ATAPI3 models, that will not behave like this (also because in the meantime the crappy BIOSes will also be largely updated).
However we will keep this KB as "current", additionally adding to it a completely faked "Last Review: December 29, 2014 - Revision: 1.1" so that people may actually believe that the info in it is valid, current and that we actually give a sh*t about ZIP drives and NT 3.5 or 4.00.
BTW, and JFYI, we joked, had you actually read previous documentation, we don't and will not support IDE ZIP drives at all in NT 3.51, see:
ftp://ftp.microsoft.com/misc1/BUSSYS/WINNT/KB/Q159/4/56.TXT

Currently, the Zip IDE Insider will only work on Windows NT 4.0. Windows NT 3.51
has no removable IDE capability in its Atapi.sys driver because no removable IDE
media products were available during its product cycle.

The Windows NT 4.0 ATAPI driver is designed to recognize the new capabilities of
removable IDE products such as the IOMEGA Zip IDE Insider or the SyQuest
DataFlyer 230 IDE, and so forth.

MORE INFORMATION
================

Currently, there are no plans to add removable media IDE capability to the
Windows NT 3.51 Atapi.sys driver.


Now, seriously.

A ZIP 100 drive (which is the media that was tested as in the EARLY times it was the ONLY available size for the "cartridge") has 196608 sectors, each 512 bytes. (FACT).

Since a ZIP is NOTHING but a beefy floppy or single platter hard disk in a fancy cartridge, internally it can have ONLY (just like a floppy) 2 (two) "sides" or "heads", anything different is a "faked" geometry, it is well possible that the specific ZIP IDE Insider model faked a 512*12*32 CHS geometry (which does result in 196608), and that a given (crappy) BIOS' LBA translation made it into a 97/32/63 one (that results into 195552 :w00t:  :ph34r:), BUT ALL OTHER ZIP DRIVES 100 Mb EVER EXAMINED ALL OVER THE WORLD do expose a geometry of 96/64/32 (which also does result as 196608 sectors) OR (another singularity) 1024/4/48 (but that anyway results as 196608 sectors), the correct references were already given.

The ZIP IDE Insider was produced (in relatively small quantities) in 1996 or 1997 and was quickly replaced by the various ATAPI versions, or, if you prefer, any NON SCSI, NON Parallel, NON USB ZIP produced since at least late 1997 or early 1998 is one of the three ATAPI versions, and BIOSes were adapted to work with those, it would be an extremely rare case that you will ever come across a BIOS that creates the crazy LBA translation that the mentioned KB discusses.

:duff:

Wonko

#14 Leolo

Leolo

    Newbie

  • Members
  • 22 posts
  •  
    Spain

Posted 02 March 2015 - 12:33 AM

Argh, I fell for it again :( I should've known that you always have to take Microsoft's documentation with a grain (maybe a mountain!) of salt.

 

But now you've piqued my curiosity, and I'm curious to know more about the real USB ZIP drives (the ones made and sold by Iomega).

 

Given that they used the USB bus, did they also accept ATA or ATAPI commands? Or did they encapsulate SCSI commands inside the USB protocol?

 

How does the BIOS calculate their size? (as far as I know, they were either 100 MB, 250 MB or 750 MB) Does the BIOS send an ATA "IDENTIFY DRIVE" command to the drive? Or is it an equivalent SCSI "INQUIRY" command?

 

And, is there an easy way to check if my old and dusty Sandisk Cruzer mini flash drive is reporting itself both in CHS and LBA addressing?

 

Is it normal for USB Flash drives to report their capacities using CHS geometry? Or do they use LBA geometry exclusively?

Aaah, so many questions! The more I learn, the less I know! 


Edited by Leolo, 02 March 2015 - 12:45 AM.


#15 Leolo

Leolo

    Newbie

  • Members
  • 22 posts
  •  
    Spain

Posted 02 March 2015 - 05:13 AM

I've searched a bit more and it seems that USB drives report both their CHS and LBA geometry in a table called FDMP (Flexible Disk Mode Page)
http://www.usb.org/d...sc_boot_1.0.pdf
 

And here's a very interesting post about what the BIOS does with that info:
http://www.t10.org/f...03/r0311171.htm

Does anyone have a real Iomega USB ZIP drive and can capture the USB packets to see the values of the FDMP table reported by the drive?



#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15025 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 02 March 2015 - 10:22 AM

Hmmm. :dubbio:

 

http://www.t10.org/f...03/r0311171.htm

The one C:H:S address we can translate without knowing geometry is the
address C:H:S=0:0:1 which always means lba 0. I haven't yet heard of a
BIOS willing to translate that address while unwilling to translate
less unambiguous addresses.

 

Right, but *somehow* wrong :w00t:.

http://jaclaz.alterv...B/USBstick.html

... what we want to do is to find a start (BOOT) sector address for the FIRST partition that can be reached both with LBA and CHS and with ALL the geometries seen above, the only one that fulfills this is Cyl 0 Head 0, we could start as low as Sector 2 but as some utilities use the first few hidden sectors for their data, including the “normal” FAT32, best option is to get the last addressable sector with geometry 125*64*32, BEFORE “switching” to Cyl 0 Head 1, i.e. Cyl 0 Head 0 Sector 32, this way even if cylinders, heads and sectors number differs, the result is GUARANTEED, let us set the size of the partition , so that the entire partition can be accessed again BOTH as LBA and CHS on ALL geometries.

 

any address belonging to Cyl 0 Head 0 (with sector number smaller than geometry max sector) is actually translated correctly, and since number of sectors is anyway at least 32 in observed media (actually either 32 or 63) 0/0/32 is usually "good enough".

 

About USB ZIP drives, you are falling for a historical trap, you cannot even think about USB ZIP drives without knowing how/what their previous incarnations were.

 

The ZIP drive was born as an external device and came in two flavours, the SCSI and the parallel one, the parallel was never meant to be booted[1] while the SCSI was AFAICR bootable fine on some "real" SCSI cards, not with the el-cheapo one that was given as option with SCSI disk drives, which had no BIOS Extender/was not bootable  (and yes I did have a Windowsw NT 4.00 "emergency" system booting from a SCSI ZIP).

[1]I lied ;), there WAS a way:

http://opcug.ca/publ...ws/zipdrive.htm

http://www.blueskyinnovations.com/

unfortunately the good guys at Blue Sky innovations prevented the Wayback machine from caching their pages  :( a brief excerpt can be found here):

http://xoomer.virgil...ot/aero-faq.pdf

 

The "IDE insider" came third and as said was soon replaced by the ATAPI, ATAPI2 and ATAPI3 versions.

 

The USB was the last one and it was an adaptation to a brand new technology (the USB bus) of a good ol' one, the ZIP drive came out like in 1994 or so, by the time the USB version came it was already "established" technology and when USB came, it was slow, the "pros" had all the (fastish) SCSI version or the ATAPI internal one, and soon the 100 Mb (which had become later 250) was too small and the later 750 version was more like a meteor than anything else.

 

So, all in all there are (were) more ZIP drives models than stars in the sky, and it is not at all easy to know what/which did what.

 

All devices - including USB sticks - AFAIK do report their geometry, the point is that every BIOS around may choose to respect it, translate it to something else, expect a specific one and/or fake a completely different one. :(

It is (maybe was) a mess. 

 

:duff:

Wonko



#17 Leolo

Leolo

    Newbie

  • Members
  • 22 posts
  •  
    Spain

Posted 03 March 2015 - 02:13 AM

Hey, you know quite a bit about ZIP drives! I never had one in my computer, back in the day. I was too poor to afford one :(

But I did have a neighboor who had a SCSI external zip drive. It was insanely fast compared to my humble floppies!

 

I've been experimenting a bit more with my "super floppy", and I'm noticing that it works really well with older mainboards, but unfortunately the newer ones hate it with a passion!

I'm currently testing it with a gigabyte GA-EP41-UD3L board, using the latest BIOS version F6

 

Oh, and by the way, I think I've found a bug in this mainboard's BIOS that is not mentioned in your FAQ, Wonko! ;)

This BIOS will not boot my pendrive if the first active partition is not located on sector 63.

The Microsoft's DiskPart versions included in Vista and later automatically put the first partition in sector 2048 for big drives (in my small drive the first partition starts in sector 128)

Using Symantec Gdisk to align the partitions (forcing the first partition to start at sector 63) solves the problem in this case.



#18 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15025 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 March 2015 - 10:29 AM

Oh, and by the way, I think I've found a bug in this mainboard's BIOS that is not mentioned in your FAQ, Wonko! ;)

This BIOS will not boot my pendrive if the first active partition is not located on sector 63.

The Microsoft's DiskPart versions included in Vista and later automatically put the first partition in sector 2048 for big drives (in my small drive the first partition starts in sector 128)

Using Symantec Gdisk to align the partitions (forcing the first partition to start at sector 63) solves the problem in this case.

Well, though I try to keep my crystal ball finely tuned it is not much surprising that what I wrote more than one year before the release of Vista :ph34r: was not taking into account that behaviour, since at the time the (BTW MS instated) "standard" was to align on cylinder boundary.

Diskpart however does what you tell it to do. :whistling:

 

Here kid :), let me help you delve deeper in the misteries of the Registry....

....

http://support.micro...om/kb/931760/en

 

... and if you have the guts to follow me, you will also be surprised to learn how easy it is to lose in a flick a logical volume inside extended by simply changing the active status of another primary partition ....

http://reboot.pro/to...itioning-issue/

 

:duff:

Wonko



#19 Leolo

Leolo

    Newbie

  • Members
  • 22 posts
  •  
    Spain

Posted 03 March 2015 - 06:35 PM

Hey, thanks for the link! That means that Symantec Gdisk is no longer needed, I can use DiskPart (with that registry tweak) as well. Nice!

By the way, thanks to this thread I'm discovering a lot of info that I didn't know before, and always mystified me. Like, for example, the strange missing space at the end of a drive partitioned by FDISK (in the paragraph 6.1, titled "the last cylinder"):
http://www.tldp.org/...sk-HOWTO-6.html

Another interesting bit of info is that old versions of Windows NT used 64 heads and 32 sectors for CHS addressing, while Windows 2000 and newer prefer 255 heads and 63 sectors.

Given that the ZIP drive doesn't have 64 physical heads, and its reported CHS info is "fake", could it be possible that Iomega decided to fake its geometry using the values preferred by Microsoft at that time?



 


Edited by Leolo, 03 March 2015 - 06:37 PM.


#20 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15025 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 March 2015 - 11:19 AM

Hey, thanks for the link! That means that Symantec Gdisk is no longer needed, I can use DiskPart (with that registry tweak) as well. Nice!

By the way, thanks to this thread I'm discovering a lot of info that I didn't know before, and always mystified me. Like, for example, the strange missing space at the end of a drive partitioned by FDISK (in the paragraph 6.1, titled "the last cylinder"):
http://www.tldp.org/...sk-HOWTO-6.html

Another interesting bit of info is that old versions of Windows NT used 64 heads and 32 sectors for CHS addressing, while Windows 2000 and newer prefer 255 heads and 63 sectors.

Given that the ZIP drive doesn't have 64 physical heads, and its reported CHS info is "fake", could it be possible that Iomega decided to fake its geometry using the values preferred by Microsoft at that time?

Very likely. :)

 

You have to remember that the ZIP disk (in it's SCSI version) was born aimed to the "pro's" (at the time it was not very cheap, at least initially) as the typical "beefy" or "server" machine (in  a business) was SCSI  and it ran either NT 3.51 or 4.00, while the other "more common" desktop computers were likely to be IDE (in those years typically IBM PS/2 machines BTW) were guaranteed compatibility through the (slowish) Parallel interface.

 

JFYI, 64/32 is also the "native" geometry that by default (i.e. in absence of a suitable .pln descriptor file) Ken Kato's VDK driver uses.

 

And - still JFYI - there is a known exception to the "switch" between 64/32 and 255/63 which is WinHex that uses (or used, it's a lot of time I don't use it) 128/63 which probably has been the geometry adopted by some development tool in the years after NT 4.00 and before Windows 2000,

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users