Jump to content











Photo
- - - - -

USB(ZIP/LS120-)Booting with minimalist MBR code and GRLDR


  • Please log in to reply
24 replies to this topic

#1 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 07 September 2010 - 05:57 PM

Prologue :
To point it out clearly: I'm far from saying, that my used method works for anyone else but me (resp. my systems). See it as a case report or experiment. Furthermore, I don't mind, if my USB stick boots as ZIP/LS120 drive or Harddisk, as long as it boots at all on as much systems as possible.
Booting Rule #1: BIOS rules, MBR and/or PBR react(s).

The Background :
I own an older Laptop ( Gericom X5; MoBo P14G, P4 1.6 GHz, AMI BIOS 070010,R1.03, 04/02/01, purchased Aug. 2002 ), which is not able to boot from HDD style bootable USB Pendrives, opposite to all my other systems. My Laptop's BIOS recognizes any bootable USB stick as removable LS 120 drive. I tried to get it working with LS120 or ZIP style geometry to no avail. When I finally tried tinybit's triple MBR/PBR method, I had a first success.
I needed only one dual-use MBR/PBR, but applicated "recursive" partitioning (Partition starts at sector 1/LBA 0). Result was a true fd0 mountable floppy with Grub4dos(G4D), even if there was more than one partition...and NO Bootflag at all. With an appropriate Filter driver Windows even shows ALL partitions ! Linux has no problems to mount them as well, but not all at the same time. Mounted first partition (possible as sda) blocks mounting others (sda1,sda2...). G4D may also mount partitions as fd0,0 (identical to fd0), fd0,1 etc. But to my deception, this so prepared stick was NOT bootable as ZIP/LS120 resp. HDD on any of my other systems. It was recognized as HDD, but did not boot. On a friend's Laptop (Fujitsu Siemens Amilo 1650 G) it booted flawlessly as HDD (I had to adapt menu.lst of course).

My Way to success :
My aim was to get any of MY bootable USB Sticks working on MY laptop AND all MY other systems, launching rescue utilities and other stuff with the help of GRLDR. So I had a look at Steve's RMprepUSB. Since I wanted a M$-free method, I did not use it, but was amazed about his Test-MBRs, which show some BIOS/MBR secrets in real time. I then recalled my X86-Assembler knowledge of the Mid-80s and tried to create my own "MBR-SPY", a program within one sector, which shows Processor register content, when booting as MBR to reveal more BIOS secrets. There was so much space left within that single sector, that it's possible to test own code and call the display routine multiple times at appropriate breakpoints.
And of course, there is space for Disk signature and complete partition table, so that you do NOT loose any other content of your USB stick's filesystem. Very helpful for testing and debugging was an W98-EBD image (with "debug"), launched by G4D and equipped with Panasonic's famous "mottu hairu" driver for USB storage media under MS-DOS. So I had a nearly unfiltered access to Interrupt 13h and to my stick. Important sources of information were Steve's Manual for RMprepUSB (within the ZIP-package) and the BIOS Specifications of Phoenix (and other companies) ... and last but not least forum posts (keywords for search: "disk error" ZIP).

Steve shows some essential aspects, how to cope with a non-booting "bootable" USB stick. You should be skilled to use a HexEditor, if you want to work in that field. I don't like blind methods (e.g. dd). Be warned: You might easily ruin your harddisk's or stick's content, if you write to the wrong sector. There is no "undo", unless you backup (best: as drive image) everything before !
After analyzing (disassembling AND running with "debug") a W2K-MBR and PBR (result: inappropriate for my purpose), the FAT32-GRLDR-PBR (result: appropriate with minor changes), I tried to create my own minimalist MBR code, which calls FAT32-GRLDR-PBR (only ONE sector).

The Prerequesites for a successful function of MINI-MBR:
1. BIOS "tells" MBR, how it boots the involved device: as floppy or as harddisk ( Processor Register DL set appropriatly)
2. USB ZIP/LS120 (Super-)Floppy disk read access works through Function 02h of Interrupt 13h (CHS based).
3. ZIP/LS120 (Super-)Floppy PBR is at C/H/S = 1/1/0 (to test before with my MBR and Floppy.PBR, see tools below!)
4. USB HDD read access works through Function 42h of (extended) Interrupt 13h (LBA based).
5. Successful Read Access does NOT need more than a single access attempt and no disk reset.
6. BIOS tells, how it sees Disk geometry (CHS based); Sector/track value is used for (LBA) PBR location of HDD.
7. Partitioning is totally ignored by MBR code (Bootflag doesn't matter; any of the four primary partitions is accepted as Boot partition.
8. Filesystem of Boot partition is FAT32(FS-Id 0Bh; for best compatibility and to avoid rapid flash memory wear out).

The Tool Box to share with you :
1. MBR-SPY.REC ( Verbose customizable Boot Record )
2. FLOPPY.PBR ( Non-booting Floppy Boot record )*
3. MINI.MBR ( Minimalist MBR code, Code Size with message: 167 Byte, total Size 440 Bytes )
4. Modified G4D-FAT32-PBR ( Source extracted from GRLDR 0.4.4 2009-10-16)**
5. Modified (GRLDR) internal menu.lst***
6. ReadMe.PDF as Manual and Technical Reference ( with active Web-Links to supplemental information and downloads)

All packed in one slim ZIP file (153kB, Download here, MD5: AEF74C318874DCBAD3C9B329C945E148)

*) Put it at Sector 3Fh (=63) and/or sector 20h (=32), and you will see, which sector boots.You may append "(sector xx)" to the message string inside. It also works on a legacy floppy as regular PBR ( I created it for that purpose more than a decade ago ). Its advantage is, that it continues booting the next boot device, when a key is pressed (no infinite loop, if not removed).

**) You have to adapt the BPB (the Boot Parameter Block), either by keeping it from an earlier formatting or by fillng in partition values manually. An empty (fresh formatted) filesystem is easily to relocate. Do not forget the duplicated root FAT, when moving to a new location.

***) My MBR doesn't look at partition table, but GRLDR does. So if you don't use first primary partition for booting, you might have to adapt the device name (fd0,0; fd0,1 ...). If you don't modify internal "menu.lst" GRLDR defaults to commandline ( or finds some on your harddisk!), if system boots as ZIP/LS120, because Floppies are ignored, when searching for "menu.lst". If you type "configfile (fd0,0)/menu.lst" (provided that you used first primary partition and an appropriate "menu.lst" is present in Root directory), you get your menue. Maybe you find it useful, that no one else knows, how to proceed. There is a sample (external) menu.lst in ReadMe.pdf for the case, that one system boots your USB stick as ZIP-SuperFloppy and the other as Harddisk.

Epilogue :
Feel free to experiment with my work. You do it at your own risk, of course. I did NOT find a way (or better a shape) , to get my USB Stick recognized as Harddisk by my Gericom X5 Laptop, although the latter is able to boot from mechanical USB HDDs. BIOS rules (see Prologue). It may be possible on some systems to format the same stick as HDD or alternatively as ZIP/LS120 floppy. This is more or less a sophistic approach to me, not a practical. I need a reliable Boot process either way... and the features of G4D Boot Manager, nothing else.

I'm looking forward to your critics and comments


Kind Regards
COD 11

#2 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,276 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 07 September 2010 - 06:23 PM

Hi, interesting post! Sounds like you were having fun!

What size USB sticks did you try. BIOSes often treat a USB device as zip or hdd depending on physical size (not volume/ptn size). So it is important to test with 1GB, 2GB .. 16B devices - you may find when you get to xxGB it no longer works...

#3 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 07 September 2010 - 06:44 PM

Hi Steve,

Hi, interesting post! Sounds like you were having fun!

yes, I had fun ... and got some gray hairs more. This is not mutually exclusive.

What size USB sticks did you try.

Following YOUR advice, I used a 512 MB stick.

BIOSes often treat a USB device as zip or hdd depending on physical size (not volume/ptn size). So it is important to test with 1GB, 2GB .. 16B devices - you may find when you get to xxGB it no longer works...

I totally agree. Finding out, that BIOS suggests (or detects/reads/calculates) a CHS geometry of the booting storage media as a whole, 1023/255/63 might be such a boundary since function 02h of interrupt 13h is used for floppy access, due to my experience.

Regards
COD11

#4 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 September 2010 - 10:13 PM

Interesting and nice. :D

If I may, there is some confusion with the use of the term LS120/ZIP and "superfloppy".

ZIP can have TWO different "formats":
  • "normal" superfloppy"
  • "partitioned ZIP"

Some reference is here:
http://www.boot-land...?showtopic=5133
http://www.win.tue.n.../zip/zip-1.html

If possible, some disambiguation would be advisable.

:D
Wonko

#5 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 08 September 2010 - 05:28 PM

Legacy Floppy style magnetic storage media with higher capacity

1. Iomega ZIP-Disk-Drive
Iomega, the manufacturer of this type of removable magnetic storage medium, had in principle a good idea : how could one create a dual-use (HDD and Floppy style) booting medium, without having to change Boot Records (MBR, PBR) in any way.
The result was this layout and a hardware trick:
MBR at sector 1 (CHS; sectors count from 1), one partition on fourth primary partition (a remnant to early DOS Harddisks, where partition count started the other way round), PBR at sector 32(=20h;CHS). This design corresponds to a Harddisk, concerning the Boot Records. To get the same drive Floppy style, MBR got hidden by just shifting each access to sectors by 32 sectors upwards. There was a jumper at the hardware to switch between both variants. So there was no need to ever format a ZIP diskette as "Superfloppy" (see below). I bet, someone did it anyway. There were two drive capacities : 100 MB (CHS 96/64/32) and 250 MB (CHS 239/64/32). Reliability was comparable to legacy Floppies (keyword for ZIP: "Sudden click of death").

2. Imation LS 120 Drive (an advanced "floptical" diskette; LS stands for "Laser servo")
I have no reliable informations, whether legacy LS120 drives had a MBR or not (never saw one in reality). Since Iomega's ZIP drive was the de facto standard for this capacity class of storage devices as LS 120 came up, I assume, that any technical difference (besides increased capacity and reliability) should have been avoided by the manufacturer. There were two main drive capacities : 120MB (CHS 963/8/32) and 240MB (CHS 963/16/32, assumed).

3. Other Manufacturers :
Syquest, Sony and Nomai (750MB) offered comparable removable magnetic storage media, but upcoming cheaper (Re)writable CDROM soon replaced all Super Diskettes.


A "Superfloppy" in the narrow sense has no MBR, but a PBR at sector 1 and a storage capacity greater than 1.44 MB (HD, resp. 2.88MB ED). It might be bootable. Newer BIOSes might take a USB Pendrive with PBR at sector 1 as USB Floppy. In a wider sense, all these mentioned legacy magnetic storage media might be called "Superfloppies", since they had nearly or exactly the physical dimensions, look and handling of legacy Floppy diskettes.

USB Pendrives are able to mimic legacy ZIP or LS120 drives at boot, if they are structured in a similar way. It's up to the BIOS to decide, whether this disguise or camouflage was successful. Unfortunately the criteria are not foreseeable. Every BIOS manufacturer seems "to cook its own soup", there are no mandatory specifications. IMHO the size of the whole stick (not the partition) plays an important role. You get the result of BIOS decision by Processor Register DL (00h=Floppy; 80h=Harddisk), when MBR code takes over. MBR (and/or PBR) has (have) to be prepared for both cases . Windows MBRs are definitly NOT.

Regards
COD11

Addendum:
[quote name='Matthias Paul @http://www.mail-archive.com/freedos-kernel@lists.sourceforge.net/msg00366.html']...
ZIP-100/250/750 and JAZ-1/2 media are *partitioned* media, that is,
they work as so called "removable drives." They have only a single
FAT16 partition (type 06h) on them, their BPB has a boot unit of 80h
and the media ID and FAT ID tags are both F8h. If you access them
through driver software, you won't see that they are organized like
harddisks, because you only see the logical drive through the driver.
However, if you boot from them, they get logged in as drive 80h and
you can use f.e. FDISK to create partitions on them (the latter is
not recommended, though).
For reference, my 3.5" Iomega ZIP-100 disks have a logical CHS geometry
of C/H/S/Z=96/64/32/512 on BIOS level, my 2.0" Iomega Clik! 40 disks
(also known as "PocketZIP 40") report with C/H/S/Z=37/64/32/512.
Does someone have a Clik! 25 drive (possibly the same as the rumoured
2.0" ZIP-25, but I'm not sure about this), a ZIP-250 or a ZIP-750 drive here?

This in contrast to so called "super-floppies", which are organized
like extra-large floppies, that is, they do not have a partition
table in the first sector. For example, LS-120/LS-240 3.5" UHD media
are super-floppies and get logged in as drive 00h if you boot from them.
Their media and FAT ID bytes are set to F0h and they use FAT16
. For
reference, my LS-120 disks have a logical geometry of C/H/S/Z=963/8/32/512,
but I have also seen them reported as having 960/8/32/512. My LS-240 media
are organized as C/H/S/Z=262/32/56/512.

...[/quote]

#6 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 08 September 2010 - 08:32 PM

:)

A couple little things, for sake of completeness:

There was a jumper at the hardware to switch between both variants. So there was no need to ever format a ZIP diskette as "Superfloppy".

Actually there were several "versions" with different interfacecs and slightly different features/small details:
External:
  • Parallel interface ZIP 100
  • SCSI interface ZIP 100
  • SCSI interface ZIP 250
  • IEEE 1394 interface (Firewire) ZIP 250
  • IEEE 1394 interface (Firewire) ZIP 750
  • USB ZIP 100 (USB 1.1)
  • USB ZIP 250 (USB 1.1)
  • USB ZIP 750 (USB 2.0)

Internal:
  • SCSI ZIP 100
  • SCSI ZIP 250
  • IDE ZIP 100
  • ATAPI ZIP 100*
  • ATAPI ZIP 250*
  • ATAPI ZIP 750*

AFAIK ONLY the ATAPI ones (marked with * above) had the jumper to switch between partitioned and "superfloppy".
i.e. and still AFAIK ZIP disk were partitioned "by default" and "normally".

Some more data on them:
http://www.mail-arch...t/msg00366.html

There were two drive capacities : 100 MB (CHS 96/64/32) and 250 MB (CHS 239/64/32).

Actually there was a third capacity: 750 Mb.
I have no data about it's geometry, though it *should* be 717/64/32.

...but I still have a (small) trick up my sleeve :):
I do have a *BRAND NEW* USB 2.0 ZIP 750 Drive! :D
I got it from e-bay some time ago, but I have NO actual 750 Mb media :).

If anyone happens to find one or more 750 Mb ZIP disks and he/she is willing to part from them, I would accept them graciously and post first hand reports on the geometry found. :)

This may interest you:
http://www.911cd.net...showtopic=18873
particularly the Phoenix document found by diddy, which can still be found, among other interesting ones, here:
http://www.singlix.net/specs/
http://www.singlix.n.../specsatapi.pdf

Also, something that may be worth mentioning is that the LS-120 was an actual floppy replacement (as it could read "standard" 720 Kb and 1.44 Mb floppies, and though connected to the IDE bus, it used the "floppy type" power connector, unlike the ZIP that used a "HD type" power connector) and - strictly speaking - he LS-120 should be called "Superdisk", as also a (rare) version LS-240 existed, more here:
http://en.wikipedia.org/wiki/SuperDisk

The 963/8/32 for the LS 120 is confirmed:
http://www.mail-arch.../msg349006.html

Here is a (quite rare) LS-120 install guide:
http://www.mitsubish...is/ls-120in.pdf

:D
Wonko

#7 km2

km2
  • Members
  • 8 posts
  •  
    Alderney

Posted 17 January 2011 - 08:26 AM

COD11,
I have encountered the same problem on almost identical AMI BIOS 07.00T, 04/02/01 in an old desktop computer, mobo ECS P4VMM2, where most UFDs are identified as USB-LS120 and do not boot 100%, no matter what what formatting is applied. Only fbinst was partially successful and I could boot some ISO/FDD images, but never MS/FreeDOS.

Would you be able to offer an installation script or utility based on your research?

As I have access to a large variety of UFDs, I discovered two controller chips compatible with the AMI BIOS. They work without special formatting, I used the HP utility, or their own Mass Production Tool format facility.

1) Chipsbank CBM2091 (1GB)
It works with the AMI in any mode: normal, zip, hdd, removable/fixed
When set to fixed hdd, it seems to boot EVERY computer so far without special formatting.

2) Ameco (MXTronics) MXT6208 (1GB)
It works with the AMI only in fixed hdd mode.

UFD Mass Production Tools are available at http://flashboot.ru
The Google translation service works well on the site.

You can ID chips with ChipGenius.

#8 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,276 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 17 January 2011 - 03:21 PM

I am dubious about BIOSes recognising different controllers and behaving differently.

As an experiment, could you take a Chipsbank CBM2091 1GB (fully bootable on all systems), image it to a file using RMPRepUSB USB->File (or DD or any other tool you prefer) and then take a 'bad' 1GB UFD (preferably of identical physical memory size or as close as possible) and use File->USB to copy the image onto it. Then try them both on all systems.

This will prove that the contents and physical drive size are not an influence on it's bootability.
The Removable bit (Fixed/Removable) should also be the same to keep things fair.

Also, would be interested in seeing the output from USBDeview on both UFDs to compare them...

In the case of it not booting, please give details of how far it got in boot process, what it was running/booting to and error messages.

#9 km2

km2
  • Members
  • 8 posts
  •  
    Alderney

Posted 18 January 2011 - 05:04 AM

I am dubious about BIOSes recognising different controllers and behaving differently.


I believe it is the other way around, some controllers can recognise different BIOSes and behave accordingly. After all they are not dumb sticks:

"Comprehensive applications, such as PC boot up, disk partitions, password check for security disk, are available as part of our standard mass production software package... PC boot up as USB Zip Disk, USB Hard Disk or CDROM " (Chipsbank CBM2091 datasheet)



As an experiment, ...use File->USB to copy the image onto it. Then try them both on all systems.


I have tried bootice, fbinst, HP and your RMPrepUSB in identical way on all UFDs. Shifting the image around is not going to reveal anything new. The OP has already established how peculiar the AMI BIOS is. Unlike OP, I had more UFDs to throw at it.



Also, would be interested in seeing the output from USBDeview on both UFDs to compare them


There are different VID/PID of course. What else relevant can USBDeview show?



In the case of it not booting, please give details of how far it got in boot process, what it was running/booting to and error messages.


Depending on UFD model and prep method, there are these symptoms when trying to boot MS DOS:

1) dos lockup
2) bypass and boot local hdd
3) grub error about geometry
4) dos error about missing interpreter
5) grub lockup

The key observation is that with the exception of the two controllers, the BIOS recognises ALL UFDs as USB-LS120 and produces odd errors.

Not only Lexar can change from removable to fixed. Run ChipGenius, then try production tools and all your booting problems may go away.

#10 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,276 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 18 January 2011 - 08:10 AM

Can you give examples of which ones work and which ones do not on the AMI BIOS pc (of similar size and same Removable Bit type).

The BIOS must be interrogating these sticks and if one stick works and another does not then either:

1. The sticks respond differently to BIOS interrogation (e.g. report different physical size, or status bits in info)
OR
2. Sticks contain different data in their sectors.

So to prove the 2nd you need to do an image copy from one to the other. To prove the first you can show us USBDeView output to see if we can see any differences.

You come to a conclusion that the controller is the important thing but with no proof...


For instance, some BIOSes will refuse to boot from a 512 MB stick but will boot from a 256MB stick. Some will boot as a HDD from a 1000MB stick but boot as a ZIP from a 999MB stick - the controller is irrelevant, it is the physical memory size reported by the stick that is important as the BIOS treats different sized USB devices in different ways.

#11 km2

km2
  • Members
  • 8 posts
  •  
    Alderney

Posted 18 January 2011 - 01:28 PM

The first two are non-bootable, the last two are bootable. All are 1GB.


USB Mass Storage Device JetFlash TS1GJFV10 USB Device Mass Storage Yes No No No G: ebf65ee42321c5 18/01/2011 11:00:54 PM 19/01/2011 12:01:03 AM 1307 0163 1.00 08 06 50 7&1a948628&1 USBSTOR USB Mass Storage Driver USBSTOR.SYS USB Compatible USB storage device 80 mA USB Mass Storage Device 5.1.2600.0

U3 Titanium SanDisk U3 Titanium USB Device Mass Storage Yes No No No G: 000017989860B6EB 18/01/2011 11:01:52 PM 18/01/2011 11:47:58 PM 0781 5408 0.10 08 06 50 7&38ebf155&1 USBSTOR USB Mass Storage Driver USBSTOR.SYS USB Compatible USB storage device 200 mA USB Mass Storage Device 5.1.2600.0

Flash Disk Hisun Flash Disk USB Device Mass Storage Yes No No No G: O000709273000151 18/01/2011 7:20:01 PM 18/01/2011 11:42:40 PM 2008 2018 0.00 08 06 50 USBSTOR USB Mass Storage Driver USBSTOR.SYS USB Compatible USB storage device 100 mA USB Mass Storage Device 5.1.2600.0

Flash Disk CBM Flash Disk USB Device Mass Storage Yes No No No G: 161858145451FB00 18/01/2011 11:02:13 PM 19/01/2011 12:02:20 AM 1e3d 6025 1.00 08 06 50 USBSTOR USB Mass Storage Driver USBSTOR.SYS USB Compatible USB storage device 100 mA USB Mass Storage Device 5.1.2600.0


Not sure why you insist on the USBDeview application. It's output has nothing to do with the issue.

#12 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,276 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 18 January 2011 - 01:56 PM

Now, if you make a small DOS partition on the CBM flash disk and then use RMPrepUSB to make a copy of it to a file CBM.IMG. Then use File->USB to blat CBM.img onto the JetFlash stick and check bootability of both sticks. :)


Don't use U3 as these are known to be non-standard.
I notice that the first two (non-bootable) have USBSTOR as the service name but the last two (bootable) do not - which is a strange coincidence - or was this a typo???

This doc describes how a host computer communicates with a USB boot device - what the USB controller returns will affect how the BIOS 'maps' the USB storage device - i.e. the BIOS treats it as a floppy, ZIP or HDD depending on what data is returned.

http://www.usb.org/d...bmass-ufi10.pdf

So it may not be the controller chip itself, but the controller firmware that determines how compatible a device is with a certain BIOS. So if we remove the uncertainty of the USB ram size returned by the device and the data it holds in it's flash memory, what remains must be an inconsistency between the USB devices in terms of what data they return when asked by the BIOS for Mode Sense, Read Capacity, Inquiry, etc.

#13 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 18 January 2011 - 07:56 PM

Hi,

I follow this thread with great interest, but have nothing new to contribute at the moment. Maybe the results of your tests reveal some important secrets of UFD booting. Good luck!

COD11

PS:
The CHS drive geometry, that is "assumed" by BIOS is the same with my "MBR_SPY.REC" and Grub4dos command "geometry (...)". But with 8GB UFDs, I saw rather queer Sectors/Track values, which Grub4dos automatically "tuned" to more appropriate values, if it booted at all.

#14 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,276 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 18 January 2011 - 09:38 PM

Once we have ruled out the data in the memory (partition table, MBR, VBR, etc.) and the physical size problem (BIOSes treat different sized devices differently) we can try looking at what each device returns when you use the SCSI Inquiry and Read Capacity commands - see my tutorial page here for a useful tool to have in your arsenal!

#15 km2

km2
  • Members
  • 8 posts
  •  
    Alderney

Posted 19 January 2011 - 05:55 AM

"Now, if you make a small DOS partition on the CBM flash disk and then use RMPrepUSB to make a copy of it to a file CBM.IMG. Then use File->USB to blat CBM.img onto the JetFlash stick and check bootability of both sticks. "

Done, CBM boots, but JF not. Specifically, I press F8 to go into the boot menu and select "USB LS120 JetFlash" manually for direct booting, BIOS blanks out and without any message boots local HDD. The JF boots other computers OK.


"Don't use U3 as these are known to be non-standard."

The U3 function has been removed long time ago. This Sandisk is prepared with fbinst and booted all other computers I have ever used. As it has above average write speed of 13MBs, it is one of my preferred service UFDs.


"I notice that the first two (non-bootable) have USBSTOR as the service name but the last two (bootable) do not - which is a strange coincidence - or was this a typo??? "

No typo, direct copy/paste from USBDeview. I see USBSTOR in all four.


"Once we have ruled out the data in the memory (partition table, MBR, VBR, etc.) and the physical size problem (BIOSes treat different sized devices differently) we can try looking at what each device returns when you use the SCSI Inquiry and Read Capacity commands - see my tutorial page here for a useful tool to have in your arsenal!"

The data has nothing to do with it. I did zero-out entire CBM in "normal" mode and the AMI reports LS120. Then using UMPtool I set it to HDD mode and again did zero-out, the AMI reports it as HDD. "Normal" CBM mode is a typical removable UFD. Have a look at http://ifile.it/p5evyu1 I also included CBM's MBRs in both modes.

I have tried from 0.5 to 16GB, size is not an issue. The AMI BIOS must be buggy in geometry communication probably. The SCSI app does not work on my XPSP3 at all.

Wouldn't you be able to analyse COD11's data and create a new AMI option in RMPrepUSB? My objective is bootability without reliance on specific controller. Let's shift the focus from CBM2091 to generic UFDs.

#16 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,276 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 19 January 2011 - 07:54 AM

Wouldn't you be able to analyse COD11's data and create a new AMI option in RMPrepUSB? My objective is bootability without reliance on specific controller. Let's shift the focus from CBM2091 to generic UFDs.


Yes, that is my objective. But RMPrepUSB only reads and writes sectors from/to the flash drive. So if you have copied the entire image from the CBM to the JetFlash and it did not work (which is what you have kindly done and proven), then nothing I can do in RMPrepUSB will make it work (unless I reprogram the controller!). The difference is what is in the controller and how it responds to the BIOS and then how the BIOS tweaks Int 13h and the drive geometry before it boots from the MBR. That is why I am very keen to find out what the difference is between the two (hence we are left with looking at the SCSI command responses that we get from the USB controllers).

RMPrepUSB can at at least Read the SCSI command data from the USB stick and report to the user the 'critical' states of various important values and report to the user on how 'bootable' it might be

e.g. 'WARNING: This USB stick is reported to the BIOS as USB-ZIP and would work best formatted as USB-ZIP or USB-FDD'

#17 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 19 January 2011 - 10:00 PM

...
Have a look at http://ifile.it/p5evyu1
I also included CBM's MBRs in both modes.
...

I had a close look at the MBRs on your ZIP file.
1. MBR_HardDisk1_LS120.dat
This is a standard WinXP MBR with a HDD-style (PBR at sector 3Fh=63) "active" first primary partition (File ID 0Eh = W95 FAT16 (LBA)). Does Grub4Dos really assign (fd0) or (fd0,0) to it ??? I'm in doubt, see below.

2. MBR_HardDisk1_HDD.dat
This is a CHS geometry based MS-DOS MBR with an unusual PBR location at sector 40h=64 (this location is normally used by ISO 9660's "Primary Volume Descriptor" on a CD; CD sector size is 4 x 512B, so CD sector number is 10h=16). At least it is greater than 3Fh. File ID is 06h (= FAT16).

...
LS-120/LS-240 3.5" UHD media are super-floppies and get logged in as drive 00h if you boot from them.
Their media and FAT ID bytes are set to F0h and they use FAT16. For
reference, my LS-120 disks have a logical geometry of C/H/S/Z=963/8/32/512,
but I have also seen them reported as having 960/8/32/512
...

LS 120 drives originally have NO MBR, but may have a BOOTABLE PBR at sector CHS 1 (CHS 1 = LBA 0) instead (Floppy style / Drive number 00h=A:). If BIOS uses the original LS 120 geometry (at least its sectors / track value) and the partition table entry corresponds (first track hidden), it might work with a PBR at sector 20h (=32). But since your configuration (PBR at 3Fh) is typical for a HDD AND you use a WinXP MBR, I assume, that it's identified as HDD, otherwise it wouldn't work IMHO. Like any Win/Dos MBR its code uses the activity flag 80h in partition table as real mode INT 13h boot drive number. In other words: those MBR do NEVER boot the UFD PBR, when STARTED by the BIOS as Floppy ! They just load the PBR of your bootable built-in HDD, IF sectors per track values / CHS startpoints are identical and then start your Boot filesystem on built-in HDD C: or otherwise they crash.

If your BIOS gives DL=80h (HDD drive number) for the UFD, THEN your UFD with valid WinXP Boot Records will boot as HDD on ANY size of UFD, provided that there is a bootmanager like NTLDR or Grub4Dos, of course.

The advantage of the DOS MBR is, that it does NOT compare MBR partition table and PBR Boot Parameter Block, so little differences are tolerated (not different hidden sector values), but it only works with the appropriate FAT16 PBR. So it's restricted to smaller UFD sizes.

The AMI BIOS must be buggy in geometry communication probably.

I assume due to my experience, that it takes all UFDs with RMB=1 as USB LS120 AND that there is a limit of approx. 1GB total size for floppy booting. IMHO, the main problem is, that you can't easily find out (or get appropriate documents), what criteria BIOS (not only AMI) uses to determine the INT 13h drive number of the boot device or at least how it reads or calculates the CHS geometry. I own a 8 GB UFD, which is reported by the AMI BIOS to have incredibly small 128 MB total size.

#18 steve6375

steve6375

    Platinum Member

  • Developer
  • 5,276 posts
  • Location:UK
  • Interests:computers (!), programming (masm,vb6,C,vbs), OSes, photography,TV,films,guitars
  •  
    United Kingdom

Posted 19 January 2011 - 10:29 PM

We cannot assume that the PBR is ONLY where the MBR says it is - we would need to to see the first say 100 sectors.

The TESTMBR code in RMPrepUSB was written to try to throw some light on what different BIOSes do. There is no rule for how a BIOS treats a UFD - there is evolution! Each new BIOS changed the rules.

Many years ago I managed to persuade Intel to have BIOS options for USB-floppy, USB-ZIP and USB-Fixed disk booting in their BIOSes and also an auto-size option (small USB drives boot as ZIP - above a user-determined size they boot as HDD). They took my comments (and no doubt others) on board. I dare say the MS WinPE v2 UFD booting requirements also had something to do with it!
With the disappearance of floppy drives, we had DOS for flashing BIOSes which often required a UFD 'floppy' and WinPE v2 which requires to boot from UFD as a HDD.

#19 km2

km2
  • Members
  • 8 posts
  •  
    Alderney

Posted 20 January 2011 - 08:04 AM

This ancient and buggy AMI BIOS is not worth our time, but it proves that the USB-HDD mode is most compatible and reliable. While setting our UFDs as fixed HDD may not be always possible, one can simply use a 2.5" HDD in a USB enclosure for all PC service and setup tasks. To ensure absolute compatibility, the triple MBR preparation could be applied. This approach also results in a vastly increased disk space and read/write transfer speed limited only by the USB interface itself.

Wouldn't you agree with my conclusion?

#20 km2

km2
  • Members
  • 8 posts
  •  
    Alderney

Posted 26 January 2011 - 09:20 AM

Just after I gave up on the AMI, I read the following:

FlashBoot is compatible with all known BIOS bugs and weird features

http://www.prime-expert.com/flashboot/why_flashboot.php

And it works with the BIOS. I tried SanDisk (ex-U3) 1GB with FreeDOS, Grub or Isolinux installed by FlashBoot. The SanDisk UFD had never worked before when formatted by fbinst, HP, Bootice or RMPrepUSB.

FlashBoot does display diagnostic messages and with the AMI it works in CHS mode 966/16/63

Posted Image

Whereas in QEMU the same UFD works in LBA mode.

Posted Image

Is there a non-commercial utility capable of applying the same bootstrap technique?

#21 tinybit

tinybit

    Silver Member

  • Developer
  • 914 posts
  •  
    China

Posted 27 January 2011 - 01:29 AM

AFAIK, fbinst works on all cases, except that the BIOS would suicide when it detects the code mark/stamp that fbinst or any other software would use. Here about "suicide", I mean hangup, reboot or simply skip the (fbinst) boot record and try next boot device. I would like to consider those cases as an attack on (some of) the Open Source Softwares(including fbinst). Note: I do not force anyone to think the same way as me. And I am not sure I am perfectly right, so do not ask me more. It is just my point of view(my opinion). And I do not want to be forced by anyone(to think in another way).

After fbinst successfully gains control, it can boot grldr of grub4dos, syslinux, grub2, burg, and many more.

#22 km2

km2
  • Members
  • 8 posts
  •  
    Alderney

Posted 29 January 2011 - 09:07 AM

FlashBoot is not perfect. It seems to boot 100%, but some applications do not work. For example, all HBCD’s DOS apps die at the CD detection stage. There might be a work-around, but as I mentioned earlier, I’m very happy with USB 2.5”HDD formatted with fbinst.

#23 Sadeghi85

Sadeghi85

    Newbie

  • Members
  • 15 posts
  •  
    Iran

Posted 03 February 2011 - 05:56 PM

Is there a non-commercial utility capable of applying the same bootstrap technique?


@km2:

Could you please try Fbinst with forced chs enabled? If that still doesn't work set max-sectors=1 and try again?

As I understand it, if the usb stick supports flipping the RMB, there is no need for these tricks.

#24 ito pedalracer

ito pedalracer

    Member

  • Members
  • 35 posts
  •  
    Barbados

Posted 17 September 2011 - 09:46 PM

I do not want to hijack an excellent thread like this one!
But could Cod11 (German, too?) or some one else send me his <1gb UFD image?
Information above says there are at least two images that promise a certain degree of
compatibility on an old buggy AMI bios (I own a K7S5A with Cheepbios mod).
I could then write those with the marvellous RMPrepUSB and hope.

Thank you

#25 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 09 February 2013 - 12:42 PM

The thingy is not available anymore from Rapidshare.

Please find it attached.

 

:cheers:

Wonko

Attached Files






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users