x86 64bit USB boot?

[s_dub...@yahoo.com]

I was gifted a dysfunctional 64bit mini-desktop with ms Vista that would only boot into 'safe mode'. I think its of 2008 vintage. Debian was an easy install using an iso image on a usb memory stick as the bios allowed the option to boot from usb.

So, I'm wondering what boot codings for usb I can fiddle with for this system.

I spent this morning looking for that kind of info and its lacking.

I guess/hoping I can dd a floppy image, or a hd one, to a fresh memory stick. Or, is only an iso image allowed now a days?

But, what is the environment on a x86 64bit system at boot time??

Is it protected mode already, is 32bit code execution emulated/allowed?

Is the legacy bios still in effect on these machines at all?

What bios calls are used to access the booted usb as a block device?

..etc..

tia,

Steve

[Mike Gonta]

s_dubrovich wrote:
> I was gifted a dysfunctional 64bit mini-desktop with ms Vista that
> would only boot into 'safe mode'. I think its of 2008 vintage.
> Debian was an easy install using an iso image on a usb memory stick
> as the bios allowed the option to boot from usb.
> So, I'm wondering what boot codings for usb I can fiddle with for
> this system.
> I spent this morning looking for that kind of info and its lacking.
> I guess/hoping I can dd a floppy image, or a hd one, to a fresh
> memory stick. Or, is only an iso image allowed now a days?
> But, what is the environment on a x86 64bit system at boot time??
> Is it protected mode already, is 32bit code execution emulated/allowed?
> Is the legacy bios still in effect on these machines at all?

x64 circa 2008 may or may not have UEFI BIOS.
As long as it is not a Class 3 machine (server hardware) which laptops
aren't/weren't, UEFI required a compatibility support module for
transition support. This "Classic BIOS" module is still available on
most if not all current PC's. Additionally there are brand new late
model PC's which either cater to DOS / Linux as well as PC's such as
the intel NUC which for the most part are sold as barebones with no OS
which have the CSM. Even though intel is out of the motherboard
business the NUC is here to stay. On a WIN 10 machine (and probably
Vista) you have to enter the bios, turn off Secure Boot, and enable
legacy mode to boot the flash drive using the regular Classic BIOS
functions. The nice thing about the NUC is that it has intel Visual
BIOS. Plug the USB flash drive in, shut down the machine in hibernate
mode, restart the PC and enter the BIOS, click (using the mouse) on
the legacy device tab and double click on the listed USB device to
boot and run without changing any settings. CTRL-ALT-DEL and the PC
restarts exactly we you were before. Works just like an emulator except
it's bare hardware.

> What bios calls are used to access the booted usb as a block device?

Same as before, start in 16 bit RM and change to 32 bit PM and/or 64
bit LM.

The low price NUC's also have complete models available with WIN 10
installed or barebones to install LINUX.


Mike Gonta
look and see - many look but few see

http://mikegonta.com

[s_dub...@yahoo.com]

Thanks, I've got some more answers already..

I found a NOS mem stick, an imation 32mb, that I had saved for a project such as this, and never used. I dumped its contents first, which were a mbr and a single partition with MS WIN 4.1 vbr. No OS files (or any other files) such as IO.SYS, MSDOS.SYS, or WINBOOT.SYS are present, so I used this stick to test what would would happen.

The 64-bit crate, a Dell Insipon 530 mini-desktop, gives a pre-boot splash screen to press F12 for options on booting instead of the default hd, so usb is an option. Pressing that loads the legacy mbr, and that loads the vbr which then gives the expected error regarding the system files are not present.

So basically, I can treat the usb stick as a legacy hard drive, a removable one that I can populate with test code from another machine. And the legacy bios must be in effect for the mbr to load the vbr and print to screen the load error.

According to the partition entry for the vbr (bootsector), C,H,S = 0,1,1 so a head increment, i.e. a track size, is 4000h, as that is the physical offset of the vbr. So a track size is 16k, or 32d sectors in length, if I did that correctly.

I think I'm going to have some fun with this..

Now I'm wondering what to expect of GB sized usb mem sticks?

Thanks,

Steve

[Mike Gonta]

s_dubrovich wrote:
> So basically, I can treat the usb stick as a legacy hard drive,
> a removable one that I can populate with test code from another
> machine. And the legacy bios must be in effect for the mbr to load
> the vbr and print to screen the load error.

> According to the partition entry for the vbr (bootsector),
> C,H,S = 0,1,1 so a head increment, i.e. a track size, is 4000h, as
> that is the physical offset of the vbr. So a track size is 16k,
> or 32d sectors in length, if I did that correctly.

If the machine can boot from USB then the extended int 0x13
instructions will be available. There is no need to play with CHS on
media which has none anyways. In fact even a real floppy disk booted
from a USB floppy drive will support the extended instructions.

> I think I'm going to have some fun with this..

Too little too late, but it's still fun anyways.

> Now I'm wondering what to expect of GB sized usb mem sticks?

Even a 1.44MB FAT12 image boots and runs just fine on the largest
flash drive. And even though MS doesn't support FAT32 and exFAT on
floppy disks they both boot and run just fine too, thank you.

[Benjamin David Lunt]

<s_dub...@yahoo.com> wrote in message
news:40e8d153-0c18-4543...@googlegroups.com...

Hi guys,

> So basically, I can treat the usb stick as a legacy hard drive, a
> removable one that I can populate with test code from another
> machine. And the legacy bios must be in effect for the mbr to
> load the vbr and print to screen the load error.

Absolutely. The BIOS emulates the USB stick as if it were a
legacy hard drive, and you should be able to use the extended
BIOS read/write services as Mike mentioned.

The only thing to remember is, once you move to pmode, as you
know, the BIOS services go away, then so does the USB stick.
Also, if you are still in real mode and reset the USB Host
Controller that that USB stick happens to be on, the USB
stick goes away, as far as the BIOS is concerned.

Don't touch the USB and don't move into pmode and it is a legacy
hard drive the whole time.

When I was doing tests for my book, this is the problem I
ran into. A lot of people wanted to help test my code, but didn't
have a floppy drive. They even complained that floppies are so
old, why do I require one for the test. Couldn't they just
put the tests on a USB stick???

They didn't realize that as soon as my tests were done, the
"floppy emulation" or "hard drive emulation" was history. The
USB that this stick was inserted in was part of the test. :-)
With nothing to write the test results back to, they could not
submit a test result.

Anyway, have fun,
Ben

[Alexei A. Frounze]

On Thursday, January 12, 2017 at 2:02:12 PM UTC-8, s_dub...@yahoo.com wrote:
...

> I think I'm going to have some fun with this..
>
> Now I'm wondering what to expect of GB sized usb mem sticks?

I have a 2GB stick FAT32 formatted. I can boot my .COMs and
.EXEs off it with https://github.com/alexfru/BootProg.

Alex

[Rod Pemberton]

On Thu, 12 Jan 2017 20:30:29 -0700
"Benjamin David Lunt" <zf...@fysnet.net> wrote:

> Also, if you are still in real mode and reset the USB Host
> Controller that that USB stick happens to be on, the USB
> stick goes away, as far as the BIOS is concerned.

I'm aware of this situation also, but how does the BIOS detect that the
USB Host Controller was reset? Is there a fundamental change in
operation? Do the BIOS calls work, but fail because the device is
accessed differently? Or, is the BIOS polling a status register which
indicates emulation was turned off or that the method of access is no
longer available? Do you have any more info on how this works or which
spec this was in?


Rod Pemberton

[Benjamin David Lunt]

"Rod Pemberton" <NeedNotR...@xrsevnneqk.cem> wrote in message
news:20170113002632.234b7c45@_...

If the BIOS is written correctly, it will see a disconnect/reconnect
when the HC is reset.

However, now that the BIOS has already booted a drive, it really doesn't
know what to do with it anymore. It could be a different drive
for that matter. I would hope it would now mark the DL entry as
invalid, missing, or other.

Therefore, the BIOS will most likely assume you will not reset the
HC since the reason for the emulation is that you don't know anything
about the HC to begin with. Any access to the "drive" after this
is considered undefined and may/will have undefined results which
may or may not write to the "drive" destroying what is already there.

Ben

[s_dub...@yahoo.com]

On Thursday, January 12, 2017 at 9:31:35 PM UTC-6, Benjamin David Lunt wrote:
> <s_dub...@yahoo.com> wrote in message
> news:40e8d153-0c18-4543...@googlegroups.com...
>
> Hi guys,
>
> > So basically, I can treat the usb stick as a legacy hard drive, a
> > removable one that I can populate with test code from another
> > machine. And the legacy bios must be in effect for the mbr to
> > load the vbr and print to screen the load error.
>
> Absolutely. The BIOS emulates the USB stick as if it were a
> legacy hard drive, and you should be able to use the extended
> BIOS read/write services as Mike mentioned.
>
> The only thing to remember is, once you move to pmode, as you
> know, the BIOS services go away, then so does the USB stick.
> Also, if you are still in real mode and reset the USB Host
> Controller that that USB stick happens to be on, the USB
> stick goes away, as far as the BIOS is concerned.

This begs the question of: what happens then to the usb keyboard and usb mouse?

> Don't touch the USB and don't move into pmode and it is a legacy
> hard drive the whole time.

If I drop out of pmode, (to effect a bios call for example) would the 'usb mem stick as hd' be in context again? Or, what considerations are needed to restore its state on a mode switch out of pmode back to rmode?

> When I was doing tests for my book, this is the problem I
> ran into. A lot of people wanted to help test my code, but didn't
> have a floppy drive. They even complained that floppies are so
> old, why do I require one for the test. Couldn't they just
> put the tests on a USB stick???
>
> They didn't realize that as soon as my tests were done, the
> "floppy emulation" or "hard drive emulation" was history. The

Seems like there is more sleuthing to be done here. This is too reminiscent of the x286 not being able to return to rmode from pmode.

> USB that this stick was inserted in was part of the test. :-)
> With nothing to write the test results back to, they could not
> submit a test result.
>
> Anyway, have fun,
> Ben

Thx.

Steve

[Mike Gonta]

"s_dubrovich" wrote:

> "Benjamin David Lunt" wrote:

>> Don't touch the USB and don't move into pmode and it is a legacy
>> hard drive the whole time.
>
> If I drop out of pmode, (to effect a bios call for example) would
> the 'usb mem stick as hd' be in context again?

Of course it will, nothing changes. Just leave the USB controller alone.

> Seems like there is more sleuthing to be done here.
> This is too reminiscent of the x286 not being able to return to
> rmode from pmode.

Of course it can! There just isn't a cpu instruction to do so.
http://www.rcollins.org/articles/pmbasics/tspec_a1_doc.html

[Benjamin David Lunt]

<s_dub...@yahoo.com> wrote in message
news:42f86f00-db88-4c37...@googlegroups.com...

> On Thursday, January 12, 2017 at 9:31:35 PM UTC-6, Benjamin David Lunt
> wrote:
>> <s_dub...@yahoo.com> wrote in message
>> news:40e8d153-0c18-4543...@googlegroups.com...
>>
>> Hi guys,
>>
>> > So basically, I can treat the usb stick as a legacy hard drive, a
>> > removable one that I can populate with test code from another
>> > machine. And the legacy bios must be in effect for the mbr to
>> > load the vbr and print to screen the load error.
>>
>> Absolutely. The BIOS emulates the USB stick as if it were a
>> legacy hard drive, and you should be able to use the extended
>> BIOS read/write services as Mike mentioned.
>>
>> The only thing to remember is, once you move to pmode, as you
>> know, the BIOS services go away, then so does the USB stick.
>> Also, if you are still in real mode and reset the USB Host
>> Controller that that USB stick happens to be on, the USB
>> stick goes away, as far as the BIOS is concerned.
>
> This begs the question of: what happens then to the usb keyboard
> and usb mouse?

Until you reset the HC, the hardware still does the emulation,
if the HC supports it. There is no BIOS emulation of the
keyboard and mouse, its all hardware.

>> Don't touch the USB and don't move into pmode and it is a legacy
>> hard drive the whole time.
>
> If I drop out of pmode, (to effect a bios call for example) would
> the 'usb mem stick as hd' be in context again? Or, what
> considerations are needed to restore its state on a mode switch
> out of pmode back to rmode?

Yes, as long as you don't mess with the USB. The BIOS will maintain
its current state and the USB stick will retain its current state,
just as long as you don't reset or manipulate the USB.

>
> Thx.
>
> Steve

[Mike Gonta]

"Benjamin David Lunt" wrote:

> "s_dubrovich" wrote:

>> This begs the question of: what happens then to the usb keyboard
>> and usb mouse?
>
> Until you reset the HC, the hardware still does the emulation,
> if the HC supports it. There is no BIOS emulation of the
> keyboard and mouse, its all hardware.

Serial/ps2 keyboard/mouse "emulation" is handled by System Management
Mode firmware, which is technically part of the BIOS (in the same way
that video chip firmware and hard drive "option roms" are). If the
South Bridge supports serial and/or ps2 that "hardware" will be
"updated" by the SMM, if not it will be "emulated" in the BIOS or non
existent.

[Benjamin David Lunt]

"Mike Gonta" <mike...@gmail.com> wrote in message
news:o5bc1o$148r$1...@gioia.aioe.org...

> "Benjamin David Lunt" wrote:
>> "s_dubrovich" wrote:
>
>>> This begs the question of: what happens then to the usb keyboard
>>> and usb mouse?
>>
>> Until you reset the HC, the hardware still does the emulation,
>> if the HC supports it. There is no BIOS emulation of the
>> keyboard and mouse, its all hardware.
>
> Serial/ps2 keyboard/mouse "emulation" is handled by System Management
> Mode firmware, which is technically part of the BIOS (in the same way
> that video chip firmware and hard drive "option roms" are). If the
> South Bridge supports serial and/or ps2 that "hardware" will be
> "updated" by the SMM, if not it will be "emulated" in the BIOS or non
> existent.

You say potato, I say potato. :-)

The hardware contains this firmware to do the emulation, just as
Mike states above.

Ben

[Mike Gonta]

"Benjamin David Lunt" wrote:

> You say potato, I say potato. :-)
> The hardware contains this firmware to do the emulation, just as
> Mike states above.

You say tomato, I say tomato.
While it's true that firmware is implemented in hardware components,
typically when referring to firmware we are talking about code as
opposed to "hard wired" hardware, in the same manner as the BIOS is
referred to as firmware.

[Rod Pemberton]

On Fri, 13 Jan 2017 00:46:51 -0700

Well, I wasn't finding much on losing BIOS USB support after resetting
the USB hardware controller. So, I switched to searching for "Legacy
USB support" instead. It's slightly different, but I found some
interesting stuff. I also think I found the answer too and a
specification I wasn't aware of.


Certain devices USB can not be recognized upon reboot if their settings
are changed.
https://support.microsoft.com/en-us/kb/310923

The pdfs below have memory maps which shows the BIOS maps in an
additional 16KB of USB BIOS code when "Legacy USB support" is enabled.
ftp://ftp.boulder.ibm.com/software/retail/poseng/surepos300/sp300techref205.pdf
http://www.kontron.de/downloads/manual/m_coolmonster_c3_p3_leu6m123.pdf

The pdf below has "USB Legacy Support" section (pg 88) which describes
how "Legacy USB support" works in the BIOS.
http://www.mpcdrivers.com/sylvia/Support/desktop/manuals/mas001591/1591-00.pdf

According to those, and other pdfs, "Legacy BIOS support" is
temporarily enabled for POST, whether or not it's enabled in the BIOS.
This is to ensure you can enter the BIOS configuration with USB
keyboard and mouse. Also, 16KB of BIOS code is mapped in to the UMA if
"Legacy USB support" is enabled in the BIOS. "Legacy USB support"
provides keyboard and mouse support for non-USB aware OSes. USB aware
OSes do not have access to the keyboard or mouse until the OS loads the
USB drivers. If settings of the USB controller were changed, USB
devices may not work.

This one has some nice diagrams which show keyboard and mouse emulation
before and after an OS takes over. Obviously, something must be
changed in the USB Host Controller so that the "Emulation and Trapping
Events" no longer occur. This allows the OS USB software to take over
processing. This seems to be what you're saying is a reset of the
hardware controller.

MSDN "Platform Compatibility for USB Boot Devices"
http://web.archive.org/web/20101119010710/http://www.microsoft.com/whdc/archive/usbcompat.mspx?pf=true

That one also mentions a specification I don't recall seeing mentioned
previously (link below). It has three diagrams of how the USB and
legacy mouse and keyboard work. According to this, the emulation
hardware must be disabled/enabled by software using a "transition method
specified by the host controller manufacturer." So, I'm assuming OCHI,
EHCI, UHCI, xHCI each must specify this method in their specifications.

"USB PC Legacy Compatibility Specification"
http://cscott.net/usb_dev/data/devclass/usb_le9.pdf


Rod Pemberton

[Mike Gonta]

"Rod Pemberton" wrote:

> Well, I wasn't finding much on losing BIOS USB support after resetting
> the USB hardware controller. So, I switched to searching for "Legacy
> USB support" instead. It's slightly different, but I found some
> interesting stuff. I also think I found the answer too and a
> specification I wasn't aware of.
>
> Certain devices USB can not be recognized upon reboot if their settings
> are changed.
> https://support.microsoft.com/en-us/kb/310923
>
> The pdfs below have memory maps which shows the BIOS maps in an
> additional 16KB of USB BIOS code when "Legacy USB support" is enabled.
> ftp://ftp.boulder.ibm.com/software/retail/poseng/surepos300/sp300techref205.pdf
> http://www.kontron.de/downloads/manual/m_coolmonster_c3_p3_leu6m123.pdf
>
> The pdf below has "USB Legacy Support" section (pg 88) which describes
> how "Legacy USB support" works in the BIOS.
> http://www.mpcdrivers.com/sylvia/Support/desktop/manuals/mas001591/1591-00.pdf
>

These are not "standard" PC's of course, however typically System
Management Mode firmware DMI (aka the Desktop Management Interface)
which handles the "emulation" lives in this "shadow memory" area.

> MSDN "Platform Compatibility for USB Boot Devices"
> http://web.archive.org/web/20101119010710/http://www.microsoft.com/whdc/archive/usbcompat.mspx?pf=true
>
> That one also mentions a specification I don't recall seeing mentioned
> previously (link below). It has three diagrams of how the USB and
> legacy mouse and keyboard work.
>

> "USB PC Legacy Compatibility Specification"
> http://cscott.net/usb_dev/data/devclass/usb_le9.pdf

This one appears to be an implementation which preceded the now
ancient DMI specification which of course is an interface that doesn't
specify implementation.
https://www.dmtf.org/standards/dmi

[James Harris]

On 14/01/2017 07:49, Rod Pemberton wrote:

...

> This one has some nice diagrams which show keyboard and mouse emulation
> before and after an OS takes over. Obviously, something must be
> changed in the USB Host Controller so that the "Emulation and Trapping
> Events" no longer occur. This allows the OS USB software to take over
> processing. This seems to be what you're saying is a reset of the
> hardware controller.
>
> MSDN "Platform Compatibility for USB Boot Devices"
> http://web.archive.org/web/20101119010710/http://www.microsoft.com/whdc/archive/usbcompat.mspx?pf=true

That reminds me of something I came across before which I'll post in
case it is helpful. IIRC there are two ways to allow for both PS/2 and
legacy USB peripherals.

1. Don't have a real 8042 but get the firmware to trap accesses to ports
0x60 and 0x64, and have the firmware act as the 8042 would.

2. Have a real, physical, 8042, and have the PS/2 devices connected to
it; process Legacy USB in firmware and, when legacy mode is enabled,
have them place bytes from keyboard and mouse in the 8042 using commands
0xd2 and 0xd3.

http://aodfaq.wikidot.com/kbc-commands

I guess this would also need to trap 8042 port accesses so I am not sure
it would offer any advantages over option 1 except, perhaps, faster time
to market when USB was new.


In either case, OS software should be able to interact with ports 0x60
and 0x64 as if there was (a) a real 8042 and (b) PS/2 peripherals rather
than USB ones.


--
James Harris

[James Harris]

On 14/01/2017 07:49, Rod Pemberton wrote:

...

> That one also mentions a specification I don't recall seeing mentioned
> previously (link below). It has three diagrams of how the USB and
> legacy mouse and keyboard work. According to this, the emulation
> hardware must be disabled/enabled by software using a "transition method
> specified by the host controller manufacturer." So, I'm assuming OCHI,
> EHCI, UHCI, xHCI each must specify this method in their specifications.
>
> "USB PC Legacy Compatibility Specification"
> http://cscott.net/usb_dev/data/devclass/usb_le9.pdf

It also says, "6.1.2 Transition To Legacy Mode Support. There is no
requirement for legacy mode support to re-enumerate the USB on
transition to legacy mode support. This means that depending on
attach/detach operations that occurred during extrinsic support, USB
peripherals may not function after a return to legacy mode support. For
this reason, environments may want to perform the transition to legacy
mode support via a reboot and re-execution of POST."

What with this and what with the Microsoft document you linked, it
sounds as though reboot is the only portable way to restore USB legacy
support. Given the mention of POST perhaps even a warm boot may not be
enough.

--
James Harris

[s_dub...@yahoo.com]

Thanks,

I picked up 16GB stick, the smallest they carry. It has a
FAT32 filesystem on it according to strings found in the first
500k dump of it. No mbr at all, not surprising after thinking
about it -data only drive. Glad I didn't try one of these
first, nothing there to awaken further interest.

32 spt in the other mbr and vbr is a bit curious. No particular
reason for it being that small. I got to wondering what the
original st506 spec was, and found the oem manual online..

(OEM manual apr 1981) - 32 spt, 256 byte per sector, 612 tracks,
and 4 heads. 5mb formatted. 5 year lifespan.

The first st506 I had was 10mb, for cp/m-80 running on a z80.
Cp/m-80 could only address 8mb due to data structure limits,
so it was partitioned as 2 5mb drives.

I'd forgotten that sector size then was only 256 bytes.

Since there's 31 sectors of space between the mbr and vbr, and
the mbr relocates itself to 600h so that it then reads the vbr
to 0:7C00h and jumps to it, the new plan is to write the 32 spt
to 600h..4600h. 4600h..7C00h as stack space. The gain in space
of 31 sectors gives room to test and report things such as the
extended int 13h features and other 'states' before reading the
vbr.

Steve

[s_dub...@yahoo.com]

On Thursday, January 12, 2017 at 5:07:40 PM UTC-6, Mike Gonta wrote:
> s_dubrovich wrote:
> > So basically, I can treat the usb stick as a legacy hard drive,
> > a removable one that I can populate with test code from another
> > machine. And the legacy bios must be in effect for the mbr to load
> > the vbr and print to screen the load error.
>
> > According to the partition entry for the vbr (bootsector),
> > C,H,S = 0,1,1 so a head increment, i.e. a track size, is 4000h, as
> > that is the physical offset of the vbr. So a track size is 16k,
> > or 32d sectors in length, if I did that correctly.

A little update.. (mostly to change the prevalent thread for a second.)

> If the machine can boot from USB then the extended int 0x13
> instructions will be available. There is no need to play with CHS on
> media which has none anyways. In fact even a real floppy disk booted
> from a USB floppy drive will support the extended instructions.
>

Indeed, EDD Fns 42h, and 43h for int 13h are supported, good bye C,H,S

Btw, I tested C,H,S geometry this last weekend and was abit surprised that the volume is seen as 32 sectors per head, 2 heads per cylinder (!!). If more than 0..1 is given for a head value then the remainder over 0..1 is treated as a cylinder value and added separately to value given for cylinder. I checked that by writing test sectors to various C.H's then DD'ing the image and hexdump -ing to check address locations.

> > I think I'm going to have some fun with this..
>
> Too little too late, but it's still fun anyways.

Sounds a bit cryptic.. but how about 'fun' as in, an interpreter to play with and storage handled without a typical fat filesystem.

(I wonder how small an OS, such as an interpreter, can be.)

>
> > Now I'm wondering what to expect of GB sized usb mem sticks?
>
> Even a 1.44MB FAT12 image boots and runs just fine on the largest
> flash drive. And even though MS doesn't support FAT32 and exFAT on
> floppy disks they both boot and run just fine too, thank you.
>

DD on this version of Debian linux doesn't touch the MBR on the thumb drive and DD must be invoked under SU for permission to Read or Write.

>
> Mike Gonta
> look and see - many look but few see
>
> http://mikegonta.com

Steve

[Rod Pemberton]

On Fri, 13 Jan 2017 06:09:00 -0800 (PST)
"s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:

> Seems like there is more sleuthing to be done here.

This is slightly off-topic as it's not for 64-bit, but I recently tried
to create bootable USB stick. I had such a tough time that I created a
bootable CD-ROM. The CD-ROM went surprisingly well from Linux, once I
found the proper commands.

I have a number of actual bootable MS-DOS and Freedos floppy images
copied from an actual floppy. I used Linux 'dd' command to copy this to
the USB stick. The USB stick wouldn't boot. I copied the image in
from the stick and it was the same as the original. I repeated this
same process from DOS using John Fine's Partcopy. The results were the
same.

That's the short version of many failed attempts as I originally
attempted this by creating a brand new bootable floppy image entirely
from Linux. That's an entire other problem. That was my real goal,
not the USB stick. I just figured the stick would be faster than a
floppy ... Next time, if there is a next time, I'll use a real floppy
instead of USB stick.

Eventually, I decided to try a different bootable DOS image. To my
surprise, it booted. However, certain files were corrupt. I copied
the image in again, both in Linux and DOS, and it was identical to the
original, i.e., indicating no corruption.

At this point, I don't know if the problem is:

a) MS-DOS
b) BIOS emulation
c) hardware emulation, perhaps SMM
d) other BIOS translation issue

So, I've been intending to code a TSR .com which essentially re-formats
the disk with data markers or serial numbers after booting from it and
while under BIOS emulation, so that when I read the disk image back in
the disk under Linux or MS-DOS, I can detect any scrambling of sectors
or data corruption, etc. Maybe, there is an easier way?

The issue only seems to occur under BIOS emulation of the USB stick.
The BIOS attempts to emulate it as a hard disk, not a floppy. Why? I
don't know. It's a bootable floppy image without any partition.
Perhaps, I should've wiped the 0xAA55 signature? ...

At this point, I'm confused as to what is happening, and I may never
get back to it. I also now don't know if I ever correctly created a
bootable DOS image from Linux. Except for the DOS bootable floppy
image CD-ROM, this was a headache of an experiment.


Rod Pemberton
--
All the promises by Obama were illegal or temporary. Liberals should
stop shooting the messenger. Your anger is misplaced.

[James Harris]

On 31/10/2017 16:52, s_dub...@yahoo.com wrote:

...

> DD on this version of Debian linux doesn't touch the MBR on the thumb drive and DD must be invoked under SU for permission to Read or Write.

I am not sure of the context so this may already be obvious to you but
an MBR would only be visible on /dev/xda, not on /dev/xda1 which is a
volume.

--
James Harris

[s_dub...@yahoo.com]

AFAICT, a bootable usb stick acts like a drive 80h, unlike a CD_ROM that will
act like drive 00h, as that is part of the CD_ROM specification. So, perhaps
its a problem of a floppy OS expecting to boot on A: versus actually booting
on 80h. I can only guess how a USB Floppy Drive responds, its firmware may
re-vector int13h to its own handler. I know the USB Stick access requires 80h
drive designator for int 13h, and EDD int 13h services.

Steve

[s_dub...@yahoo.com]

No, it wasn't obvious to me, so thanks for pointing that out. Thxs.

Steve
> --
> James Harris

[Mike Gonta]

s_dubrovich wrote:
> AFAICT, a bootable usb stick acts like a drive 80h ...

... sometimes ...

> I know the USB Stick access requires 80h drive designator
> for int 13h,

Use either AH=0x08 int 0x13 - DISK - GET DRIVE PARAMETERS or
AH=0x48 int 0x13 - Extensions - GET DRIVE PARAMETERS to obtain
the BIOS designated drive ID (returned in DL) and do not assume that it
will be 0x00 for a floppy disk image.

> and EDD int 13h services.

Either one works just fine.
However, it's been my observation that if the PC can boot USB then
the extended services will be available (even booting an actual floppy disk
with a USB floppy drive).

[James Harris]

On 31/10/2017 23:04, Rod Pemberton wrote:
> On Fri, 13 Jan 2017 06:09:00 -0800 (PST)
> "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:
>
>> Seems like there is more sleuthing to be done here.
>
> This is slightly off-topic as it's not for 64-bit, but I recently tried
> to create bootable USB stick. I had such a tough time that I created a
> bootable CD-ROM. The CD-ROM went surprisingly well from Linux, once I
> found the proper commands.
>
> I have a number of actual bootable MS-DOS and Freedos floppy images
> copied from an actual floppy. I used Linux 'dd' command to copy this to
> the USB stick. The USB stick wouldn't boot. I copied the image in
> from the stick and it was the same as the original. I repeated this
> same process from DOS using John Fine's Partcopy. The results were the
> same.
>
> That's the short version of many failed attempts as I originally
> attempted this by creating a brand new bootable floppy image entirely
> from Linux. That's an entire other problem. That was my real goal,
> not the USB stick. I just figured the stick would be faster than a
> floppy ... Next time, if there is a next time, I'll use a real floppy
> instead of USB stick.

My guess - and I wouldn't put it much higher than that but the guess is
based on what others have said - is that a BIOS on bootup looks at a
potentially bootable flash memory to see whether it looks "legitimate".
If it is, it loads the first sector to 0x7c00 and starts it. The rest is
up to the sector's boot code.

But I am less clear as to how an OS detects a file system, especially if
it is a floppy FS like FAT12 which takes up only part of the medium.

At any rate, I just tried copying a floppy to a USB flash stick. It
worked as intended and appears as a file system but I am not sure
whether it is bootable or not. A machine I tried it on did not boot from
it but I don't have any USB flash which I know to be bootable to compare
it with.

>
> Eventually, I decided to try a different bootable DOS image. To my
> surprise, it booted. However, certain files were corrupt. I copied
> the image in again, both in Linux and DOS, and it was identical to the
> original, i.e., indicating no corruption.
>
> At this point, I don't know if the problem is:
>
> a) MS-DOS
> b) BIOS emulation
> c) hardware emulation, perhaps SMM
> d) other BIOS translation issue
>
> So, I've been intending to code a TSR .com which essentially re-formats
> the disk with data markers or serial numbers after booting from it and
> while under BIOS emulation, so that when I read the disk image back in
> the disk under Linux or MS-DOS, I can detect any scrambling of sectors
> or data corruption, etc. Maybe, there is an easier way?

Could it be the image wasn't written fully to the medium? Perhaps a
flush or sync or something might be needed.

>
> The issue only seems to occur under BIOS emulation of the USB stick.
> The BIOS attempts to emulate it as a hard disk, not a floppy. Why? I
> don't know. It's a bootable floppy image without any partition.
> Perhaps, I should've wiped the 0xAA55 signature? ...

The USB flash unit I wrote to appears to Windows as a 1.4Mbyte drive and
the few files I wrote to it are all readable.

>
> At this point, I'm confused as to what is happening, and I may never
> get back to it. I also now don't know if I ever correctly created a
> bootable DOS image from Linux. Except for the DOS bootable floppy
> image CD-ROM, this was a headache of an experiment.

--
James Harris

[Mike Gonta]

"James Harris" wrote:

> At any rate, I just tried copying a floppy to a USB flash stick. It worked
> as intended and appears as a file system but I am not sure whether it is
> bootable or not. A machine I tried it on did not boot from it but I don't
> have any USB flash which I know to be bootable to compare it with.

If it said:
"Remove disks or other media.
Press any key to restart"
(or something similar) it actually did boot in order to display the
error(?!)
USB Booting Secrets
https://board.flatassembler.net/topic.php?t=12389

[James Harris]

On 01/11/2017 21:47, Mike Gonta wrote:
> "James Harris" wrote:
>
>> At any rate, I just tried copying a floppy to a USB flash stick. It worked
>> as intended and appears as a file system but I am not sure whether it is
>> bootable or not. A machine I tried it on did not boot from it but I don't
>> have any USB flash which I know to be bootable to compare it with.
>
> If it said:
> "Remove disks or other media.
> Press any key to restart"
> (or something similar) it actually did boot in order to display the
> error(?!)
> USB Booting Secrets
> https://board.flatassembler.net/topic.php?t=12389

Thanks for the reminder. You are quite right. It seems it did boot after
all!

So there is now a floppy image on the first 2880 sectors of a USB flash
memory. It boots (as above). And Windows, at least, sees it as a
legitimate file system.

From what I've read, e.g.
http://wiki.osdev.org/USB_Mass_Storage_Class_Devices and the specs
linked thereon, there could be a lot of work going on underneath to
manage the USB bus and the flash memory unit attached thereto so the
BIOS is the key; it is choosing how to present the flash device to other
code.

I presume there could be variations in BIOS behaviour between different
machines but that most would provide a usable int 0x13 interface.

This has been a useful test. :-)


--
James Harris

[s_dub...@yahoo.com]

Thxs, so here is my test code to answer a couple of questions:
o the values returned from the function.
o if the boot signature is required by the Bios (yes). If it is absent from
the code at C=0,H=0,S=1 then than error is given (for my machine).
"No boot device available, press Enter key" so this is hard drive behavior.
(Answer for Rod)

The results are:
DRIVE NUMBER 0080h
DRIVE TYPE 0000h

NUMBER OF DRIVES 0002h
NUMBER OF HEADS 00FFh
SECTORS PER TRK 003Fh

So the results returned for NUMBER OF HEADS and SECTORS PER TRK do not fit well
with what I've seen as 2 HEADS per Cylinder, 32 SECTORS PER HEAD.

Logical Block use is straight forward, CHS is not.

So here is the test code used in place of the MBR:

Steve

------------

;; tboot.nsm Test code pertainng to use on a USB thumb-drive
;; G_DRV_PARMS: perloined from Mike Gonta see usenet alt.os.dev
;; NASM
;; 11.2.2017

[MAP ALL tboot.map]

CPU 686 ;; Pentium Pro, P2 class
BITS 16

cr EQU 0Dh
lf EQU 0Ah

org 7C00h ;; CS:IP == 0000h:7C00h

G_DRV_PARMS: ;; where is the stack?
CLC ;; set CF to NC
push dx
push ES
mov dl,80h
mov ah, 8
int 13h ;; get drive parameters
JC FN_ERR ;; if error, CF, quit with error msg.

mov [DRIVE_TYPE], bl
and cx, 3Fh ; maximum sector number
mov [SECTORS_PER_TRACK], cx
mov [NUMBER_OF_DRIVES], dl
movzx dx, dh ; maximum head number
add dx, 1
mov [NUMBER_OF_HEADS], dx
pop ES
pop dx
mov [DRIVE_NUMBER], dl

;; Print stored values as nnnnh

Prt_Values:
mov cx, 0
mov cl, [DRIVE_NUMBER]
call NOTIFY

mov cx, 0
mov cl, [DRIVE_TYPE]
call NOTIFY

mov cx, 0
mov cl, [NUMBER_OF_DRIVES]
call NOTIFY

mov cx, [SECTORS_PER_TRACK]
call NOTIFY

mov cx, [NUMBER_OF_HEADS]
call NOTIFY

;;---------------------------------------------------------
;; *** Fall into Pause, Quit by ctrl-alt-del ***

KB_Pause:
mov bx, msgSignOff ;; ctrl-alt-del to reboot
call pmsg

mov ah, 0
int 16h ;; pause for keypress, opportunity to reboot
;; int 19h - don't use, errors will confuse.
jmp KB_Pause ;; loop until ctrl-alt-del

FN_ERR:
push ax ;; holds error status
mov bx, msgErr
call pmsg
pop cs
call NOTIFY ;; print error value as nnnnh
jmp KB_Pause ;; to quit


;;---------------------------------------------------------
;;

NOTIFY:
pusha
;; call prt_str
call prt_CX
call prt_h
call prt_sp
popa

RET


;;---------------------------------------------------------
;; Print a string whose address is in SI, uses int 10h

prt_str:
cld ;; set forward direction
lodsb ;; DS:SI -> AL
mov ah, 0Eh
mov bx, word 0007h
prt_loop:
int 10h
lodsb
test al, al ;; null terminated str
jnz prt_loop

RET

;;---------------------------------------------------------
;;

prt_CX:
mov ax, cx ;; parameter passed in CX
printword: ;; print value in [ax] as 4 hex digits
push ax
mov al, ah
call printbyte
pop ax

printbyte: ;; print value in [al] as 2 hex digits
push ax
mov cl, 4
shr al, cl ;; shift al right 4 places
call printnibble ;; output upper nibble
pop ax ;; restore al (now we do lower nibble)

printnibble: ;; print value in low 4 bits of [al] as a hex digit
and al, 0fh ;; mask upper 4 bits
add al, 90h
daa
adc al, 40h
daa
call prt_chr
RET

;;---------------------------------------------------------
;;

prt_sp:
mov al, ' '
call prt_chr
RET

prt_h:
mov al, 'h'
call prt_chr
RET

prt_chr: ;; AL is preset with chr to print.
mov ah, 0Eh
mov bx, word 0007h
int 10h
RET

;;----------------------------------------------------------
;; uses BX for Ptr_to_str

pmsg:
push ES
pmsg_2:
mov al, [BX] ;; get next char from message

test al, al ;; Ck for zero terminator to str.
jz End_pmsg ;; if zero return

cmp al, '$' ;; cpm str terminator
je End_pmsg

mov CL, AL
call CONOUT ;; print it

inc BX
jmp pmsg_2 ;; next character and loop

End_pmsg:
pop ES

RET

;;----------------------------------------------------------
;; CONSOLE OUTPUT
;;----------------------------------------------------------
;;-------- console write--BIOS Fn 4 --------
;;
;; Send CL==Chr to console display, assume
;; 7bit ascii chr in CL, no filtering for Tab.
;;
;; RomBios: AH=0Eh, AL=char,BH=display-page(alpha modes)
;; BL=foreground color (graphics modes)

CONOUT:
push bx
push ax
mov al, cl

and al, 7Fh ;; 7 bit ascii only.

mov bx, 0
mov ah, 0Eh
int 10h ;; RomBios doesn't expand tabs.
pop ax
pop bx
RET


;;===============
;; DATA
;;===============

DRIVE_TYPE: db 0
NUMBER_OF_DRIVES: db 0
SECTORS_PER_TRACK: dw 0
NUMBER_OF_HEADS: dw 0
DRIVE_NUMBER: db 0


msgSignOff:
db cr,lf,'Press CTRL-ALT-DEL to reboot.',0
msgErr:
db cr,lf,'INT 13h fn 8 Errored: ',0

;;-----------------------------------------------------------------------------

PADD:
TIMES 510-($-$$) db 0h

;; DW 0 ;; test for no signature reaction, RESULT:
;; (1) "No boot device available, press Enter key to retry"

dw 0AA55h ;; MBR requires this at end of VBR boot sector otherwise:
;; 'Missing operating system'
;; *OR* if used instead of the MBR, less boot signature, then
;; (1)

;; -eof-

[Rod Pemberton]

On Wed, 1 Nov 2017 21:17:17 +0000
James Harris <james.h...@gmail.com> wrote:

> Could it be the image wasn't written fully to the medium? Perhaps a
> flush or sync or something might be needed.

I don't think that's it. I tried sync with dd in Linux before. I also
did this with DOS apps.

> The USB flash unit I wrote to appears to Windows as a 1.4Mbyte drive
> and the few files I wrote to it are all readable.

Both Linux and DOS show no corruption when not booted from it, even
immediately after displaying corruption when booted from it.

ISTM so far that it's some type of interaction between BIOS emulation
and DOS, or hardware/software bug when emulation is included, or that
it's booting with the wrong emulation, or perhaps wrong values in
the bios parameter block, etc.

I found a guy who had to tweak BPB values to get a USB image to boot,
but I'm not able to relocate the web page so far. I'll post the link
if I find it again.

According to the web page below, USB-HDD requires a partition, but
there is no partition table in the image. Maybe, it's reading garbage
for the partition so the translation is wrong? ... It won't boot as
USB-FDD, but I suspect that it need to.

The page also says USB-ZIP requires a specific geometry with 32 sectors
and 64 heads. Both these pages make me wonder if the floppy image
needs to have the geometry tweaked for USB somehow to boot as USB-FDD.

http://xed.ch/h/usbdrive.html

[Rod Pemberton]

Que? Did you mean James? ... If not, sorry, I lost track to what the
answer is for.

I may try out the posted code, though, perhaps on the weekend. One of
my thoughts as to why USB-FDD won't boot for the USB stick with a
floppy image was that the BPB values need adjustment. A while back, I
saw a web page a while back where someone had to modify values for a
USB stick to boot a Toshiba laptop from USB. I'm hoping to relocate
that page. So far, Google isn't spitting it out, but I'm good at
abusing Google to get what I want, again.

In addition to the corruption I'm seeing when booting the USB stick
with a floppy image, I've found that the USB-HDD emulation prevents any
reading or writing the first 63 sectors, up to 0x7e00 in the image,
i.e., hidden. This makes the image appear to start at 0x7e00.

So, at this point, my WAG (wild ass guess) is that I should be booting
via USB-FDD, not USB-HDD. So, USB-HDD booting the USB stick with a
floppy image is a fluke or bug, perhaps using bad data as a valid
partition, and the corruption may be due to wrong BPB values or
translation. And, the floppy image on the USB stick when booting as
USB-FDD doesn't boot because the BPB is incorrect, or something else.

I intend to look for more information on USB-HDD and USB-FDD via Google
when I get the time and feel like it, perhaps on the weekend.


Rod Pemberton
--
In the U.S., we've strongly encouraged everyone to stop smoking
cigarettes. Now that we've done so, we're allowing everyone to smoke
marijuana. What was the point of the former?

[s_dub...@yahoo.com]

It was in response to your:

"
The issue only seems to occur under BIOS emulation of the USB stick.
The BIOS attempts to emulate it as a hard disk, not a floppy. Why? I
don't know. It's a bootable floppy image without any partition.
Perhaps, I should've wiped the 0xAA55 signature? ...
"

If I don't have the boot signature in the first sector of the USB then
I get the RomBios error message. FYI.

The other point is: I choose USB boot from a list of boot options given
when F12 is pressed after a system reboot. The USB boot is treated as
a hard drive boot from the get-go. This is different from CD-ROM boot,
because apart of the early specs for CD-ROM is a format for floppy
emulation, I forget the details, but the point is the CD-ROM spec allows
for a floppy image boot.

Once the USB boots, that means the signature word is found is the 1st
sector, the the USB stick is seen as device 80h, the first hard drive,
in the int 13h calls. However, floppy based OSes think and expect that
they are on device 00h for int 13h internally so YMMV.

One version of CCP/M-86 I messed with expected 2 floppy drives: OS on A:
and apps on B: so it is locked to vintage hardware.

>
> I may try out the posted code, though, perhaps on the weekend. One of

nasm -@ tboot.mak

(contents of tboot.mak)
-f bin
-l tboot.lst
-o tboot.bin
-Z tboot.err
tboot.nsm

> my thoughts as to why USB-FDD won't boot for the USB stick with a
> floppy image was that the BPB values need adjustment. A while back, I

I don't think the USB RomBios checks for a BPB, just the boot signature.
None of my successful test code has a BPB.

> saw a web page a while back where someone had to modify values for a
> USB stick to boot a Toshiba laptop from USB. I'm hoping to relocate

I'm pretty sure that is related to an expectation that CS:IP is 07C0:0000h
at bootstrap time. Toshiba laptop, and Epson desktop vintage 286.

> that page. So far, Google isn't spitting it out, but I'm good at
> abusing Google to get what I want, again.
>
> In addition to the corruption I'm seeing when booting the USB stick
> with a floppy image, I've found that the USB-HDD emulation prevents any
> reading or writing the first 63 sectors, up to 0x7e00 in the image,
> i.e., hidden. This makes the image appear to start at 0x7e00.
>
> So, at this point, my WAG (wild ass guess) is that I should be booting
> via USB-FDD, not USB-HDD. So, USB-HDD booting the USB stick with a
> floppy image is a fluke or bug, perhaps using bad data as a valid
> partition, and the corruption may be due to wrong BPB values or
> translation. And, the floppy image on the USB stick when booting as
> USB-FDD doesn't boot because the BPB is incorrect, or something else.

More likely, the internal drive select in the OS or bootstrap code has
assumptions that don't match.

You should have success with the cd-rom. Or perhaps a USB-FDD as a
bootable device. I've had too many problems / inconsistencies with
RW cd-rom software and media.

Steve

[James Harris]

On 03/11/2017 03:38, Rod Pemberton wrote:

...

>
> According to the web page below, USB-HDD requires a partition, but
> there is no partition table in the image. Maybe, it's reading garbage
> for the partition so the translation is wrong? ... It won't boot as
> USB-FDD, but I suspect that it need to.
>
> The page also says USB-ZIP requires a specific geometry with 32 sectors
> and 64 heads. Both these pages make me wonder if the floppy image
> needs to have the geometry tweaked for USB somehow to boot as USB-FDD.
>
> http://xed.ch/h/usbdrive.html

It makes sense that USB-FDD and -HDD settings in the BIOS might tell it
to look for BPB and partition table, respectively. Of course, they
assume FAT and standard partitioning.

FWIW, my Toshiba laptop just has "USB" boot without specifying -FDD or
-HDD. Maybe the BIOS incudes code to detect the difference.

Another thought: hard drives may need a sector to return the IDENTIFY
response. Where would that be on USB memory and could its location
affect the offsets needed for other sector reads?


--
James Harris

[Rod Pemberton]

On Fri, 3 Nov 2017 06:00:59 -0700 (PDT)

"s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:

> On Thursday, November 2, 2017 at 10:43:06 PM UTC-5, Rod Pemberton
> wrote:
> > On Thu, 2 Nov 2017 08:34:15 -0700 (PDT)
> > "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:
> > > On Wednesday, November 1, 2017 at 4:46:19 PM UTC-5, Mike Gonta
> > > wrote:
> > > > "James Harris" wrote:

> > > Thxs, so here is my test code to answer a couple of questions:
> > > o the values returned from the function.
> > > o if the boot signature is required by the Bios (yes). If it is
> > > absent from the code at C=0,H=0,S=1 then than error is given (for
> > > my machine). "No boot device available, press Enter key" so this
> > > is hard drive behavior.
> > > (Answer for Rod)
> >
> > Que? Did you mean James? ... If not, sorry, I lost track to what
> > the answer is for.
>
> It was in response to your:

Oh, OK. (I'm going to assemble it now. Thanks.)

RP> The issue only seems to occur under BIOS emulation of the USB stick.
RP> The BIOS attempts to emulate it as a hard disk, not a floppy.
RP> Why? I don't know. It's a bootable floppy image without any
RP> partition. Perhaps, I should've wiped the 0xAA55 signature? ...

>
> If I don't have the boot signature in the first sector of the USB then
> I get the RomBios error message. FYI.

Neither USB-HDD nor USB-FDD options booted without the 0xAA55, but
USB-FDD wasn't booting the USB stick with floppy image anyway ...

> The other point is: I choose USB boot from a list of boot options
> given when F12 is pressed after a system reboot. The USB boot is
> treated as a hard drive boot from the get-go. This is different from
> CD-ROM boot, because apart of the early specs for CD-ROM is a format
> for floppy emulation, I forget the details, but the point is the
> CD-ROM spec allows for a floppy image boot.

Yes, on this machine, hardware circa 2009, assembled circa 2013, the
BBS menu (F12) has a bunch of boot options: Floppy, LS120, CDROM, ZIP,
Legacy LAN, Hard disk, bootable add-in cards (under Hard disk),
USB-FDD, USB-HDD, USB-ZIP, and USB-CDROM.

What options do your guys' machines have now? I.e., my machine is
getting somewhat older now.

> Once the USB boots, that means the signature word is found is the 1st
> sector, the the USB stick is seen as device 80h, the first hard drive,
> in the int 13h calls. However, floppy based OSes think and expect
> that they are on device 00h for int 13h internally so YMMV.

When USB-HDD - which I think is for hard disks on USB - boots the USB
stick with a floppy image (?), it comes up as drive A: in DOS, which
should be device 00h. Maybe, it would come up as C: with a hard disk
image? I'm not sure I have one of those to test with ... or which
would fit the USB stick capacity.

> You should have success with the cd-rom.

Yes, as mentioned, I had success there. I burned a CD-ROM with a DOS
floppy image that boots. I couldn't find the correct Linux commands at
first though, actually command (genisoimage) and correct parameters.
Once I found the command that seemed correct to me, I gave it a whirl,
and it worked. There were many web pages were the commands seemed very
dubious, incomplete, or used utilities I don't have installed.

[Rod Pemberton]

On Fri, 3 Nov 2017 06:00:59 -0700 (PDT)

"s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:

> On Thursday, November 2, 2017 at 10:43:06 PM UTC-5, Rod Pemberton
> wrote:
> > On Thu, 2 Nov 2017 08:34:15 -0700 (PDT)
> > "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:

> > > Thxs, so here is my test code to answer a couple of questions:
> > > o the values returned from the function.
> > > o if the boot signature is required by the Bios (yes). If it is
> > > absent from the code at C=0,H=0,S=1 then than error is given (for
> > > my machine). "No boot device available, press Enter key" so this
> > > is hard drive behavior.
> > > (Answer for Rod)
> >

I thanked you for the code, but I guess I should've thanked Mike too.
Thanks Mike.


If tboot.bin is booted from USB stick as USB-FDD, it's bypassed. GRUB
for Linux loads. I.e., it doesn't boot.

If tboot.bin is booted from USB stick as USB-HDD or as a Hard-disk, as
USB-HDD0, it boots and displays:

0080h 0000h 0003h 003Fh 0010h


You said that means:

drive number 0080h
drive type 0000h

number of drives 0003h
number of heads 003Fh
sectors per track 0010h

Do the heads and track seem sane? It is an older 64MB USB.


It's interesting that it's device number is 80h, as it comes up as A:
for DOS. B: and C: are also present. B: is my actual 3.5" floppy
(usually A:) and C: is a my 2GB CF memory card with IDE interface
adapter. My SSD for Linux is not visible, except to DOS FDISK. My WD
SATA hard drive with Win98/SE "died" (overheating) and has been removed.
That's the 2nd WD that has died now. The other was an IDE back in the
late '90's. I have no other HD failures since MFM era, only HDs by WD.


I decided to try a larger 32GB USB stick with tboot.bin. It already
had a DOS image on it. BIOS didn't boot tboot.bin at all, but booted
DOS!!!! It did so without a boot sector for it too. WTF. So, I
thought I wrote tboot.bin to /dev/sdc1 by mistake. I tried it again
to /dev/sdc. I also reread the first 512 to check. Same results.
Obviously, the BIOS is checking for certain code to boot instead of
just booting from the boot sector. So, I decided to wipe DOS from the
32GB USB stick.


After wiping DOS, it boots tboot.bin, and it gives something similar to
the results above.

(newer 32GB)

If tboot.bin is booted from USB stick as USB-FDD, it's bypassed. GRUB
for Linux loads. I.e., it doesn't boot. (Same as before.)

If tboot.bin is boot from USB stick as USB-HDD or under Hard-disk, as
USB-HDD0, it boots and displays:

0080h 0000h 0003h 003Fh 00FFh

You said that means:

drive number 0080h
drive type 0000h

number of drives 0003h
number of heads 003Fh
sectors per track 00FFh

So, the sectors per track changed from 0010h 64MB to 00FFh for 32GB.

On the 32GB stick, I've notice that the heads and track are switched as
compared to yours.


So far, USB-FDD doesn't like anything. USB-HDD reports 80h according
to tboot.bin, but comes up as A: under emulation, with my other DOS
drives correct as B: (floppy) and C: (IDE).

[s_dub...@yahoo.com]

On Saturday, November 4, 2017 at 4:12:33 PM UTC-5, Rod Pemberton wrote:
> On Fri, 3 Nov 2017 06:00:59 -0700 (PDT)
> "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:
>
> > On Thursday, November 2, 2017 at 10:43:06 PM UTC-5, Rod Pemberton
> > wrote:
> > > On Thu, 2 Nov 2017 08:34:15 -0700 (PDT)
> > > "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:
>
> > > > Thxs, so here is my test code to answer a couple of questions:
> > > > o the values returned from the function.
> > > > o if the boot signature is required by the Bios (yes). If it is
> > > > absent from the code at C=0,H=0,S=1 then than error is given (for
> > > > my machine). "No boot device available, press Enter key" so this
> > > > is hard drive behavior.
> > > > (Answer for Rod)
> > >
>
> I thanked you for the code, but I guess I should've thanked Mike too.
> Thanks Mike.

Yes, thanks Mike. You spurred the inquiry.

>
> If tboot.bin is booted from USB stick as USB-FDD, it's bypassed. GRUB
> for Linux loads. I.e., it doesn't boot.

I see you have the option to boot as USB-FDD. I don't. It's seen as a
HD device (sandisk) in the bios boot selection screen. Its 16 GB btw, but
I'm using a MBR from an old 8 mb ibm imation thumb drive because the
original MBR for the 16gb is for mswin4.1. I recognize the imation one
as a generic MBR circa fat16

> If tboot.bin is booted from USB stick as USB-HDD or as a Hard-disk, as
> USB-HDD0, it boots and displays:
>
> 0080h 0000h 0003h 003Fh 0010h
>
>
> You said that means:
>
> drive number 0080h
> drive type 0000h
>
> number of drives 0003h
> number of heads 003Fh
> sectors per track 0010h
>
> Do the heads and track seem sane? It is an older 64MB USB.
>

It could be sane for the function, I guess. The heads and spt do seem
reversed don't they.

But, the numbers I get don't seem sane for my write tests / inspect
resulting image. Those show 2 heads per cylinder, 32 sectors per
head (trk).

In the early days, the CMOS held a list of HD makes and parameters.
The HD installation software had you choose among them when setting
up a HD (either new install, or replacement). I get the impression
that assumptions are made by the RomBios in booting up in legacy mode,
makes sense.

>
> It's interesting that it's device number is 80h, as it comes up as A:
> for DOS. B: and C: are also present. B: is my actual 3.5" floppy

It could be your version of DOS. DOS does its own drive enumeration.

> (usually A:) and C: is a my 2GB CF memory card with IDE interface
> adapter. My SSD for Linux is not visible, except to DOS FDISK. My WD
> SATA hard drive with Win98/SE "died" (overheating) and has been removed.
> That's the 2nd WD that has died now. The other was an IDE back in the
> late '90's. I have no other HD failures since MFM era, only HDs by WD.
>
>
> I decided to try a larger 32GB USB stick with tboot.bin. It already
> had a DOS image on it. BIOS didn't boot tboot.bin at all, but booted
> DOS!!!! It did so without a boot sector for it too. WTF. So, I
> thought I wrote tboot.bin to /dev/sdc1 by mistake. I tried it again
> to /dev/sdc. I also reread the first 512 to check. Same results.
> Obviously, the BIOS is checking for certain code to boot instead of
> just booting from the boot sector. So, I decided to wipe DOS from the
> 32GB USB stick.
>
>
> After wiping DOS, it boots tboot.bin, and it gives something similar to
> the results above.

Here's my guess..
a. bios checks for boot signature
(no) error msg, quit
(yes) do b.
b. bios checks for BPB
(no) do c.
(yes) use BPB values to boot re: reserved sector, location of fats,
drive geometry, etc.

c. boot MBR of CHS == 0,0,1

>
> (newer 32GB)
>
> If tboot.bin is booted from USB stick as USB-FDD, it's bypassed. GRUB
> for Linux loads. I.e., it doesn't boot. (Same as before.)
>
> If tboot.bin is boot from USB stick as USB-HDD or under Hard-disk, as
> USB-HDD0, it boots and displays:
>
> 0080h 0000h 0003h 003Fh 00FFh
>
> You said that means:
>
> drive number 0080h
> drive type 0000h
>
> number of drives 0003h
> number of heads 003Fh
> sectors per track 00FFh
>
> So, the sectors per track changed from 0010h 64MB to 00FFh for 32GB.
>

Yes, as mentioned above, I'm using a 16gb stick.

> On the 32GB stick, I've notice that the heads and track are switched as
> compared to yours.

I 'pretty much' give up on the function:

mov dl,80h
mov ah, 8
int 13h ;; get drive parameters

As it doesn't give me meaningful information; either of actual thumb-drive
parameters nor of matching actual write-test/image results. The info it
gives is, at best, misleading. The EDD functions is what I'll be using.

>
> So far, USB-FDD doesn't like anything. USB-HDD reports 80h according
> to tboot.bin, but comes up as A: under emulation, with my other DOS
> drives correct as B: (floppy) and C: (IDE).
>

I more interested in your DOS boot effort. Can you check its BPB values
to see if they are standard? BTW, shouldn't DOS have been located to
CHS = 0,0,1 ?? If tboot.bin didn't overwrite it, then it was further on
in the diskette image, right? Where is it? CHS = 0,0,2 or CHS = 0,1,1?

Steve

[Rod Pemberton]

On Sun, 5 Nov 2017 09:06:25 -0800 (PST)
"s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:

> I more interested in your DOS boot effort. Can you check its BPB
> values to see if they are standard?

...

> BTW, shouldn't DOS have been
> located to CHS = 0,0,1 ?? If tboot.bin didn't overwrite it, then it
> was further on in the diskette image, right? Where is it? CHS =
> 0,0,2 or CHS = 0,1,1?

...


Well, at your prompting for info, I decided I should go over the images
I've been using. I've got six copied to Linux from dozens in my DOS
archive. It turns out that all of these on Linux are reported as a
floppy image, except for one. ... Guess which one that one is. :-(

Yes, the image I was using to boot the USB stick isn't a floppy image
at all. It's a floppy-size (1.44MB) hard-disk (Win XP) image, with a
partition (~2GB), and with the startsector at 63. So, selecting
USB-HDD to boot makes sense, now.

That also likely explains NOT being able to see tracks prior to 63 under
emulation. That probably, per your boot outline, also explains booting
from the BPB, instead of from the bootsector.

The strange thing is that the Linux FILE command thinks the image has a
Win XP MBR. Linux FILE also thinks my CF card has a Win XP MBR, but I
don't have Win XP ... I can only assume that the CF card was formatted
at the factory from Win XP, and I never overwrote it.

After an FDISK/MBR, my CF card no longer shows as Win XP from Linux.
My guess is that I copied the start of the CF card when creating the
"floppy" image, as the partition size seems to be the same size as the
CF card capacity.

At this point in time, I really don't know why I would've done that,
nor why I would've wanted a floppy-size hard-disk image. It's bizarre.
I really think I would've wanted a FAT32 hard-disk image, if had
decided I needed a hard-disk image. Maybe, I assumed the CF was
FAT32? Recently, I was having difficulty creating a bootable floppy
image on Linux. So, maybe, I was attempting to get anything to boot,
i.e., hard-disk image instead of floppy image.

Now that I know (and you do too...) that it wasn't a floppy image I was
using (Argh!), do you still want BPB and other information from the
floppy-sized, hard disk image, ~2GB partition, with Win XP MBR?

If not, I'm probably going to delete the image, as I don't want the Win
XP MBR to continue to "contaminate" and propagate to other bootable
devices or images.

Sigh, I guess it's time to start over with an actual floppy image.
It's amazing how little time it takes not programming/developing to
start making simple mistakes.

[Rod Pemberton]

On Sun, 5 Nov 2017 09:06:25 -0800 (PST)
"s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:

> I more interested in your DOS boot effort. Can you check its BPB
> values to see if they are standard? BTW, shouldn't DOS have been
> located to CHS = 0,0,1 ?? If tboot.bin didn't overwrite it, then it
> was further on in the diskette image, right? Where is it? CHS =
> 0,0,2 or CHS = 0,1,1?
>

Ok, instead of attempting to boot DOS, I decided to backtrack to just
tboot.bin, for a minute. Then, I'll give DOS a try again.

I've blanked the USB and rewrote tboot.bin. It boots as USB-HDD,
USB-ZIP, and as a hard disk as USB-HDD0. It doesn't boot as USB-FDD.

So, tboot.bin is being recognized as a hard disk image, I think.
Without the 0xAA55 signature, tboot doesn't boot under any option.

So, I've started over with the actual floppy images. :-) Sorry, I said
I have 6 floppy images, but I only have 5 on Linux. Another image is a
full size hard disk image.

Two floppy images boot with USB-HDD and USB-ZIP, but they can't find
COMMAND.COM or other DOS drives. One floppy image attempts to boot with
USB-HDD and USB-ZIP but hangs the machine. No reboot. Loss of USB
keyboard. One floppy image boots with USB-HDD and USB-ZIP, but it has
the data corruption issue I mentioned, originally with the non-floppy
image.

All the floppy images start with: eb 3c 90. They all have an 0xAA55
signature. The only differences are in the first 512 bytes is the
MSWIN4.1 or .....IHC field, and disk name field.

At this point, I have no idea what my BIOS is searching for, for the
USB-FDD option. Nothing works.

The USB-HDD option seems to boot anything with 0xAA55, but not
correctly for DOS, i.e., corruption, hang, unable to load COMMAND.COM
for floppy images, or corruption with the Win XP hard disk image.

As mentioned before, when I used the now known to be a hard-disk image,
I couldn't read/write to blocks prior to 63. I'm now assuming this is
because the of the BIOS emulation accessing the BPB and starting
emulation at the partition start, as you mentioned or suggested.

I just attempted the same experiment to rewrite the USB stick booted
from one of the actual floppy images (booted as USB-HDD). Recall, this
floppy image was showing some corruption under DOS and BIOS emulation
when booted. I was able to write/read starting at block zero from
DOS. The written image was random bytes created with /dev/urandom on
Linux and stored on an alternate drive. When re-read in Linux, the
entire image was correct except for a couple of low bytes were
changed. 0x1B was changed from 55h to 00h. 0x24 was changed from 6ch
to 00h. So, it would seem that the corruption in DOS might have
something to do with DOS, and not the BIOS emulation as the write was
correct, except for the two bytes. I'm not sure why/how those were
changed. I used John Fine's Partcopy which uses Int 13h services (for
the option I chose).


Summary:

a) unable to get USB-FDD to do anything ...
b) USB-HDD seems to boot "anything" with 0xAA55
c) if the booted image has a partition (or perhaps BPB), USB-HDD starts
emulation with start of the partition. Tracks prior to the partition
start are inaccessible via Int 13h.
d) Int 13h services wrote an entire image to the USB stick without
corruption, when booted from a floppy image via USB-HDD, except for two
bytes which were changed

I think I'll go look for information on USB-FDD and USB-HDD before I do
anything further.

[s_dub...@yahoo.com]

On Sunday, November 5, 2017 at 4:35:42 PM UTC-6, Rod Pemberton wrote:
> On Sun, 5 Nov 2017 09:06:25 -0800 (PST)
> "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:
>
> > I more interested in your DOS boot effort. Can you check its BPB
> > values to see if they are standard?
>
> ...
>
> > BTW, shouldn't DOS have been
> > located to CHS = 0,0,1 ?? If tboot.bin didn't overwrite it, then it
> > was further on in the diskette image, right? Where is it? CHS =
> > 0,0,2 or CHS = 0,1,1?
>
> ...
>
>
> Well, at your prompting for info, I decided I should go over the images
> I've been using. I've got six copied to Linux from dozens in my DOS
> archive. It turns out that all of these on Linux are reported as a
> floppy image, except for one. ... Guess which one that one is. :-(
>
> Yes, the image I was using to boot the USB stick isn't a floppy image
> at all. It's a floppy-size (1.44MB) hard-disk (Win XP) image, with a
> partition (~2GB), and with the startsector at 63. So, selecting
> USB-HDD to boot makes sense, now.
>
> That also likely explains NOT being able to see tracks prior to 63 under
> emulation. That probably, per your boot outline, also explains booting
> from the BPB, instead of from the bootsector.

Its conjecture. Repeatable tests would have to be done. I don't want to go there for time sake.

> The strange thing is that the Linux FILE command thinks the image has a
> Win XP MBR. Linux FILE also thinks my CF card has a Win XP MBR, but I
> don't have Win XP ... I can only assume that the CF card was formatted
> at the factory from Win XP, and I never overwrote it.

Yes, preformatted media, generally.

> After an FDISK/MBR, my CF card no longer shows as Win XP from Linux.
> My guess is that I copied the start of the CF card when creating the
> "floppy" image, as the partition size seems to be the same size as the
> CF card capacity.
>
> At this point in time, I really don't know why I would've done that,
> nor why I would've wanted a floppy-size hard-disk image. It's bizarre.
> I really think I would've wanted a FAT32 hard-disk image, if had
> decided I needed a hard-disk image. Maybe, I assumed the CF was
> FAT32? Recently, I was having difficulty creating a bootable floppy
> image on Linux. So, maybe, I was attempting to get anything to boot,
> i.e., hard-disk image instead of floppy image.
>
> Now that I know (and you do too...) that it wasn't a floppy image I was
> using (Argh!), do you still want BPB and other information from the
> floppy-sized, hard disk image, ~2GB partition, with Win XP MBR?

No.

> If not, I'm probably going to delete the image, as I don't want the Win
> XP MBR to continue to "contaminate" and propagate to other bootable
> devices or images.

Or clearly name it as such, you may want its MBR, VBR, and file directory
for study or comparison, later.

> Sigh, I guess it's time to start over with an actual floppy image.
> It's amazing how little time it takes not programming/developing to
> start making simple mistakes.

'I feel your pain'.

Steve

[s_dub...@yahoo.com]

On Sunday, November 5, 2017 at 6:30:35 PM UTC-6, Rod Pemberton wrote:
> On Sun, 5 Nov 2017 09:06:25 -0800 (PST)
> "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:
>
> > I more interested in your DOS boot effort. Can you check its BPB
> > values to see if they are standard? BTW, shouldn't DOS have been
> > located to CHS = 0,0,1 ?? If tboot.bin didn't overwrite it, then it
> > was further on in the diskette image, right? Where is it? CHS =
> > 0,0,2 or CHS = 0,1,1?
> >
>
> Ok, instead of attempting to boot DOS, I decided to backtrack to just
> tboot.bin, for a minute. Then, I'll give DOS a try again.
>
> I've blanked the USB and rewrote tboot.bin. It boots as USB-HDD,
> USB-ZIP, and as a hard disk as USB-HDD0. It doesn't boot as USB-FDD.

On the FDD test, was it located to sector 1? {CHS}={0,0,1}
On the HDD it should run there. (meaning it overwrote the MBR).
On the HDD it should run at the VBR as well.
If it was located at the MBR on a test, don't forget to restore the MBR
for another test.

Not booting on FDD is perplexing, something else is going on, like not
being located properly to 0,0,1

>
> So, tboot.bin is being recognized as a hard disk image, I think.
> Without the 0xAA55 signature, tboot doesn't boot under any option.

Without the signature..
The MBR looks for it in the bootable partitions' VBR. Its MBR coding.
The BIOS looks for it in the HDD's first sector, whether that being a MBR
or not.
Originally, the FDD didn't check for it, and it really shouldn't, but the
practice crept in over the years, so the behavior has to be checked to be
sure (cares/doesn't care). That's why I took notice when you talked of it
and tested my system, to be sure.

> So, I've started over with the actual floppy images. :-) Sorry, I said
> I have 6 floppy images, but I only have 5 on Linux. Another image is a
> full size hard disk image.
>
> Two floppy images boot with USB-HDD and USB-ZIP, but they can't find
> COMMAND.COM or other DOS drives. One floppy image attempts to boot with
> USB-HDD and USB-ZIP but hangs the machine. No reboot. Loss of USB
> keyboard. One floppy image boots with USB-HDD and USB-ZIP, but it has
> the data corruption issue I mentioned, originally with the non-floppy
> image.
>
> All the floppy images start with: eb 3c 90. They all have an 0xAA55
> signature. The only differences are in the first 512 bytes is the
> MSWIN4.1 or .....IHC field, and disk name field.
>
> At this point, I have no idea what my BIOS is searching for, for the
> USB-FDD option. Nothing works.
>
> The USB-HDD option seems to boot anything with 0xAA55, but not
> correctly for DOS, i.e., corruption, hang, unable to load COMMAND.COM
> for floppy images, or corruption with the Win XP hard disk image.
>
> As mentioned before, when I used the now known to be a hard-disk image,
> I couldn't read/write to blocks prior to 63. I'm now assuming this is
> because the of the BIOS emulation accessing the BPB and starting
> emulation at the partition start, as you mentioned or suggested.

It's conjecture. It could just as well be a mismash in drive geometries.
Like HDD CHS translation vs Floppy CHS, ie. reserved sector(s) vs reserved
Track(s) or even that meaning reserved Cylinder(s) by software or firmware.

'blocks prior to 63', well 63 SPT is a HDD geometry clue, of course,FDD
should be 18 SPT. Some software won't let you touch 'reserved' anything,
probably emulators as well. Typically Track 0 is reserved for the MBR or
untypically, the floppy bootstrap track. So, is '63' reserved track 0, or
maybe even reserved cylinder..

> I just attempted the same experiment to rewrite the USB stick booted
> from one of the actual floppy images (booted as USB-HDD). Recall, this
> floppy image was showing some corruption under DOS and BIOS emulation
> when booted. I was able to write/read starting at block zero from
> DOS. The written image was random bytes created with /dev/urandom on
> Linux and stored on an alternate drive. When re-read in Linux, the
> entire image was correct except for a couple of low bytes were
> changed. 0x1B was changed from 55h to 00h. 0x24 was changed from 6ch
> to 00h. So, it would seem that the corruption in DOS might have
> something to do with DOS, and not the BIOS emulation as the write was
> correct, except for the two bytes. I'm not sure why/how those were
> changed. I used John Fine's Partcopy which uses Int 13h services (for
> the option I chose).
>
>
> Summary:
>
> a) unable to get USB-FDD to do anything ...

o Except an errant HDD image.

> b) USB-HDD seems to boot "anything" with 0xAA55

o In the MBR position. Or, the VBR position with a valid MBR.

> c) if the booted image has a partition (or perhaps BPB), USB-HDD starts
> emulation with start of the partition. Tracks prior to the partition
> start are inaccessible via Int 13h.

o software safety lock, I guess.

> d) Int 13h services wrote an entire image to the USB stick without
> corruption, when booted from a floppy image via USB-HDD, except for two
> bytes which were changed
>
> I think I'll go look for information on USB-FDD and USB-HDD before I do
> anything further.
>

I understand enough about my own environs to proceed. I don't have the bios
boot option to specifically boot a USB stick as a FDD.

Thxs,

Steve

[Rod Pemberton]

On Mon, 6 Nov 2017 03:05:34 -0800 (PST)
"s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:

> On the FDD test, was it located to sector 1? {CHS}={0,0,1}

I was using Linux DD command. AIUI, this should write to the first
sector (0th):

dd if=tboot.bin of=/dev/sdc

Of course, it's possible that I used /dev/sdc1, but I don't think so,
as tboot.bin booted for USB-HDD. There was nothing else on the USB
stick below 1.44MB, i.e., zero'd.

> Not booting on FDD is perplexing, something else is going on, like not
> being located properly to 0,0,1

...

> Originally, the FDD didn't check for [0xAA55], and it really

> shouldn't, but the practice crept in over the years, so the behavior
> has to be checked to be sure (cares/doesn't care). That's why I took
> notice when you talked of it and tested my system, to be sure.

We may have discussed this in the past. The original IBM Tech Ref
manuals say 0xAA55 is not required for floppies.

This machine will correctly boot an actual floppy with or without the
0xAA55 signature. My last motherboard required 0xAA55 for floppies to
boot.

> 'blocks prior to 63',

The 63 (0x3f) you're referring to below are the heads.

The 63 I was referring to is the sector where DOS starts partitions by
default. Linux starts partition at 2048.

> well 63 SPT is a HDD geometry clue, of
> course,FDD should be 18 SPT.

Ok.

> Some software won't let you touch
> 'reserved' anything, probably emulators as well. Typically Track 0
> is reserved for the MBR or untypically, the floppy bootstrap track.

I'm not seeing hidden sectors with the actual floppy images, only with
the "errant" hard disk image that has a partition that starts at sector
63.

> So, is '63' reserved track 0, or maybe even reserved cylinder..

I do recall years ago some BIOS update code that installed to the start
of disks. Was that for BIOS IDE upgrades? So, that's an interesting
idea, but I don't think it's the case here.

> > a) unable to get USB-FDD to do anything ...
>
> o Except an errant HDD image.

Nothing works with USB-FDD so far.

The errant hard disk image booted with the USB-HDD option, not
USB-FDD.

I had considered that the BIOS might be checking for MSWIN4.1 signature,
but I tested an image with that. The others have the IHC modification
from Windows 98/SE.

> > b) USB-HDD seems to boot "anything" with 0xAA55
>
> o In the MBR position. Or, the VBR position with a valid MBR.

For the floppy images, the first sector or MBR has 0xAA55 just below
0x200, i.e., MBR. The "errant" hard disk image also has a signature
just below 0x8000, i.e., sector 63 the start of the partition, therefore
VBR/PBR. 0xAA55 is also found at a bunch of random high locations too
for the "errant" image.

> > c) if the booted image has a partition (or perhaps BPB), USB-HDD
> > starts emulation with start of the partition. Tracks prior to the
> > partition start are inaccessible via Int 13h.
>
> o software safety lock, I guess.

That would be interesting. Why would they do that? ...

I'm suspecting that whomever wrote the BIOS in this motherboard either
a) had difficulty figuring out how to detect bootable devices and did a
hack job, or b) there is a manual somewhere which documents some
changes of newer boot sequences, or c) what I'm expecting to happen and
work is an incorrect assumption.

So, another guess is the USB-FDD option is not for a USB stick with
floppy image, as I assumed. IIRC, wasn't there external floppy drives
available that were USB? ... I.e., maybe, the BIOS isn't designed to
work with USB sticks at all, but only with actual external hard disks
and external floppy disks for both options? ... I realized that I
jumped to the conclusion that these should work with USB sticks with
the appropriate images. Maybe, the BIOS just can't tell the difference?
I.e., between a USB stick and a physical drive.

Anyway, I still need to go search ... Right now, I'm fumbling around
in the dark. That always takes longer to reach an answer.


Rod Pemberton
--
Does the increase in pedestrian deaths correspond with the increase in
Millennials?

[James Harris]

To handle the USB bus the BIOS will have to jump through all sorts of
hardware-control hoops. And then it may have to use different command
sets on different types of device. Unless a flash memory and a physical
drive automatically respond to the same common commands then it seems
unlikely that the BIOS would fail to tell the difference.

>
> Anyway, I still need to go search ... Right now, I'm fumbling around
> in the dark. That always takes longer to reach an answer.

You might be able to copy your BIOS and run it under a debugger within
an emulator like Qemu so as to see exactly what it is doing.

Of if you get a bootsector perhaps you could boot a debugger and then
use it to see what the BIOS does with subsequent sector-read requests.

Some work to set up but at least then you'd have the tools to shed some
"light in the darkness"!

--
James Harris

[Rod Pemberton]

On Tue, 7 Nov 2017 08:38:09 +0000
James Harris <james.h...@gmail.com> wrote:

> Some work to set up but at least then you'd have the tools to shed
> some "light in the darkness"!
>

Well, I've found some info which everyone might be interested in
reading on what the BIOS requires for USB-FDD, USB-HDD, and USB-ZIP.
I'll start a new thread.

[s_dub...@yahoo.com]

On Monday, November 6, 2017 at 9:42:32 PM UTC-6, Rod Pemberton wrote:
> On Mon, 6 Nov 2017 03:05:34 -0800 (PST)
> "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:
>
> > On the FDD test, was it located to sector 1? {CHS}={0,0,1}
>
> I was using Linux DD command. AIUI, this should write to the first
> sector (0th):

Let's use 'block' or 'logical block' in that context. (more curves ahead)

>
> dd if=tboot.bin of=/dev/sdc
>

Yup.

> Of course, it's possible that I used /dev/sdc1, but I don't think so,
> as tboot.bin booted for USB-HDD. There was nothing else on the USB
> stick below 1.44MB, i.e., zero'd.
>
> > Not booting on FDD is perplexing, something else is going on, like not
> > being located properly to 0,0,1
>

In C,H,S, use there is not a sector 0. {C,H,S}={0,0,1} is the first sector
addressed in the CHS INT 13h functions, meaning the values supplied to
INT 13h. 'S' is the one value not zero based.

> ...
>
> > Originally, the FDD didn't check for [0xAA55], and it really
> > shouldn't, but the practice crept in over the years, so the behavior
> > has to be checked to be sure (cares/doesn't care). That's why I took
> > notice when you talked of it and tested my system, to be sure.
>
> We may have discussed this in the past. The original IBM Tech Ref
> manuals say 0xAA55 is not required for floppies.

We did discuss this in the past at length.

> This machine will correctly boot an actual floppy with or without the
> 0xAA55 signature. My last motherboard required 0xAA55 for floppies to
> boot.
>
> > 'blocks prior to 63',
>
> The 63 (0x3f) you're referring to below are the heads.

Maybe, I'm now more inclined to say no. (more curves ahead).

> The 63 I was referring to is the sector where DOS starts partitions by
> default. Linux starts partition at 2048.
>
> > well 63 SPT is a HDD geometry clue, of
> > course,FDD should be 18 SPT.
>
> Ok.
>
> > Some software won't let you touch
> > 'reserved' anything, probably emulators as well. Typically Track 0
> > is reserved for the MBR or untypically, the floppy bootstrap track.
>
> I'm not seeing hidden sectors with the actual floppy images, only with
> the "errant" hard disk image that has a partition that starts at sector
> 63.

How did you determine this, from the MBR originally?

> > So, is '63' reserved track 0, or maybe even reserved cylinder..
>
> I do recall years ago some BIOS update code that installed to the start
> of disks. Was that for BIOS IDE upgrades? So, that's an interesting
> idea, but I don't think it's the case here.

Yeah, the more I try to remember back that far.. vintage x286 into x386,
I seem to recall the installation software for installing a HDD wrote the
drive parameters to CMOS for INT 13h or INT 40h managed by the controller.
But that is an aside. Unless you want to dig up your notes on the CMOS
and go hunting.. Perhaps that part is also emulated in the legacy boot,
meaning the startup in real mode. Another channel of inquiry.

> > > a) unable to get USB-FDD to do anything ...
> >
> > o Except an errant HDD image.
>
> Nothing works with USB-FDD so far.
>
> The errant hard disk image booted with the USB-HDD option, not
> USB-FDD.

Ok, I had the wrong picture.

> I had considered that the BIOS might be checking for MSWIN4.1 signature,
> but I tested an image with that. The others have the IHC modification
> from Windows 98/SE.
>
> > > b) USB-HDD seems to boot "anything" with 0xAA55
> >
> > o In the MBR position. Or, the VBR position with a valid MBR.
>
> For the floppy images, the first sector or MBR has 0xAA55 just below
> 0x200, i.e., MBR. The "errant" hard disk image also has a signature
> just below 0x8000, i.e., sector 63 the start of the partition, therefore
> VBR/PBR. 0xAA55 is also found at a bunch of random high locations too
> for the "errant" image.
>

8000h/200h = 40h = 64d

It would be helpful to know what the original MBR indicated as the start
of the partition.

My MBR says my bootable partition begins a Logical Block 20h (32d sectors).
And the Block Count is abit shy of 32 mb. This is a MBR I got from an 8gb
thumb drive and copied over to this 16gb thumb drive (usb stick). The
original MBR then begins at Logical Block 0 and the VBR for fat12 dos was
at Logical Block 20h = 32 = 4000h. The MBR suited me (it is generic) the
VBR didn't (Looks to load system files which were non existent originally,
and is fat16.)

Typically Track 0 is the MBR boot track and Track 1 begins a partition.
Hence 32 SPT (better said: sectors under a HEAD). YMV. (curves?)

DD seems logical block oriented, with the convenience of BS=512 (Block
Size is a sector) as a default.

So since my partition begins at LB 20h, and my VBR is 1 block, the
following DD command to overwrite an old version of test code, with a new
version, keeping everything else equal, is:

# dd skip=1 if=tboot.bin of=/dev/sdb1

(note to whomever, replace 'sdb' with YOUR USB Thumb-drive device name!)

> > > c) if the booted image has a partition (or perhaps BPB), USB-HDD
> > > starts emulation with start of the partition. Tracks prior to the
> > > partition start are inaccessible via Int 13h.
> >
> > o software safety lock, I guess.
>
> That would be interesting. Why would they do that? ...

To keep user code from messing with 'outside the OS space' systems area.

> I'm suspecting that whomever wrote the BIOS in this motherboard either
> a) had difficulty figuring out how to detect bootable devices and did a
> hack job, or b) there is a manual somewhere which documents some
> changes of newer boot sequences, or c) what I'm expecting to happen and
> work is an incorrect assumption.
>
> So, another guess is the USB-FDD option is not for a USB stick with
> floppy image, as I assumed. IIRC, wasn't there external floppy drives
> available that were USB? ...

Yes.

> I.e., maybe, the BIOS isn't designed to
> work with USB sticks at all, but only with actual external hard disks
> and external floppy disks for both options? ... I realized that I
> jumped to the conclusion that these should work with USB sticks with
> the appropriate images. Maybe, the BIOS just can't tell the difference?
> I.e., between a USB stick and a physical drive.

You might as well argue about CD-ROM or DVD booting while you're at it.
But I think you know that there is a Hardware Abstraction Layer which
treats all these as Logical Block Devices.

> Anyway, I still need to go search ... Right now, I'm fumbling around
> in the dark. That always takes longer to reach an answer.
>

Do you have CMOS refs handy, am I correct about HDD geometry entries as
defaults?

Steve

[Rod Pemberton]

On Tue, 7 Nov 2017 14:55:58 -0800 (PST)
"s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:

> > I'm not seeing hidden sectors with the actual floppy images, only
> > with the "errant" hard disk image that has a partition that starts
> > at sector 63.
>
> How did you determine this, from the MBR originally?

No, not the MBR. I wrote a image of random bytes to the USB stick after
booting it. The USB was being emulated by BIOS for the booted image.
For the booted "errant" hard disk image, the random image was offset by
63 sectors from the start of the USB stick. For a booted floppy image,
the random image had no offset from the start of the USB stick.

Specifically, (AIR) I wrote the "errant" image to the USB stick from
Linux. I then copied an image of random bytes to another DOS drive (CF
w/IDE), which shows up as C:. I booted the image on the USB stick,
which shows up as A:. I then wrote the random image (on C:) to the USB
stick (A:) from DOS. I then read in the USB stick to an image in
Linux. The read in random image was shifted, i.e., started at sector
63, but was identical otherwise. This was found with hexdump -C. I
used dd to read in another image from 63 (skip=63) from the first read
in image, i.e., the random portion. The original random image and
offset random image from the USB stick compared the same (diff), except
for the missing part.

In other words, the BIOS emulation was hiding the first 63 sectors, and
writes to the partition, not the start of the USB stick, when booting
a hard-disk image. The pdf I found says this happens for USB-ZIP, and
that USB-HDD can select USB-ZIP booting instead of USB-HDD, if only one
partition is found, which was the case. I think that is what happened.

Later, I did the same thing with an actual floppy image. It read in
correctly from the start of the USB stick, except for two bytes
(zero'd, bad? ...). There was no offset in the random data in the read
in image of the USB stick.

> > For the floppy images, the first sector or MBR has 0xAA55 just below
> > 0x200, i.e., MBR. The "errant" hard disk image also has a signature
> > just below 0x8000, i.e., sector 63 the start of the partition,
> > therefore VBR/PBR. 0xAA55 is also found at a bunch of random high
> > locations too for the "errant" image.
> >
>
> 8000h/200h = 40h = 64d

Just below ...

Just like 0xAA55 is just below 0x200, i.e., 0x1FE.

> It would be helpful to know what the original MBR indicated as the
> start of the partition.

The Linux file command and fdisk -l on the image both report the
startsector as 63.

(I have code for DOS which reads BPB/EBPB, but it doesn't work with
images. DOS is flaky with non-emulated USB. You have to load special
drivers, which sometimes work, but not usually with a USB keyboard
and USB mouse. So, I'd need to pop in my AT keyboard w/PS/2 adapter
too. I also don't have my code working on Linux. And, I'd have to
re-read the code to familiarize myself with the BPB/EBPB structure(s),
as it was written some years ago. So, if you have some offsets, I
could just do a hexdump to grab values for you. Or, I could just post
a 512 byte hexdump or perhaps a few. You could look at the values you
want.)

> > > > c) if the booted image has a partition (or perhaps BPB), USB-HDD
> > > > starts emulation with start of the partition. Tracks prior to
> > > > the partition start are inaccessible via Int 13h.
> > >
> > > o software safety lock, I guess.
> >
> > That would be interesting. Why would they do that? ...
>
> To keep user code from messing with 'outside the OS space' systems
> area.
>

To me, that's a very interesting statement. Why are you making the
distinction that the "systems area" is "'outside the OS space'" and not
actually part of the OS proper? ...

Even when the machine has multiple OSes installed, there is usually one
primary OS that is in control of the region. So, I view the "systems
area", as you're calling it, as part of an OS, since the (primary) OS
controls what needs to be there for it to boot correctly. Therefore,
to me, it's part of the OS space, usually one, perhaps multiple,
sometimes.

Is this a holdover concept from another OS that you're familiar with,
perhaps CP/M?

> Do you have CMOS refs handy,

RBIL has a CMOS list, IIRC. I'm sure I can find one, if not.

> am I correct about HDD geometry entries as defaults?

I don't understand what you're asking about here.

Which geometry entries? What defaults? Are you referring to one of my
images or your image which you described? Or, was this something to do
with you asking about CMOS? CMOS hardware defaults? ...

[Rod Pemberton]

On Tue, 7 Nov 2017 23:20:37 -0500
Rod Pemberton <EmailN...@voenflacbe.cpm> wrote:

> On Tue, 7 Nov 2017 14:55:58 -0800 (PST)
> "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:

> > > I'm not seeing hidden sectors with the actual floppy images, only
> > > with the "errant" hard disk image that has a partition that starts
> > > at sector 63.
> >
> > How did you determine this, from the MBR originally?
>
> No, not the MBR. I wrote a image of random bytes to the USB stick
> after booting it. The USB was being emulated by BIOS for the booted
> image. For the booted "errant" hard disk image, the random image was
> offset by 63 sectors from the start of the USB stick. For a booted
> floppy image, the random image had no offset from the start of the
> USB stick.

FYI, I was attempting to find the "corruption" I was seeing after
booting. That was the reason I decided to write an image of random
bytes to the USB stick from DOS after booted under emulation. It was
then that I noticed that the written image didn't start at the
beginning of the USB stick, but was offset by 63 sectors. Once I
booted from a real floppy image, not the "errant" hard disk image, the
written image had no offset, and no data corruption, except for the two
corrupt bytes (zero'd).

My goal was to find out if the tracks were being written correctly, but
scrambled or switched around, i.e., generating the "corruption" that I
was seeing. I now know that the tracks are being written correctly.
So, the should be read correctly, therefore, the "corruption" of files
I'm seeing under DOS is somewhere else, and also not actual data
corruption on the USB stick.

[Scott Lurndal]

Rod Pemberton <EmailN...@voenflacbe.cpm> writes:
>On Tue, 7 Nov 2017 14:55:58 -0800 (PST)
>"s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:
>
>> > I'm not seeing hidden sectors with the actual floppy images, only
>> > with the "errant" hard disk image that has a partition that starts
>> > at sector 63.
>>
>> How did you determine this, from the MBR originally?
>
>No, not the MBR. I wrote a image of random bytes to the USB stick after
>booting it. The USB was being emulated by BIOS for the booted image.
>For the booted "errant" hard disk image, the random image was offset by
>63 sectors from the start of the USB stick. For a booted floppy image,
>the random image had no offset from the start of the USB stick.

The USB drive looks like a hard disk, not a floppy disk. The partition
table at the end of the MBR defines the first sector of the first
partition (which often is offset 63 sectors from the start of the device).

The BIOS will load 512-byte MBR into memory and transfer control to the
first byte of the MBR. Those ~450 bytes of code will typically read
the secondary bootstrap from the sector immediately following the MBR
and transfer control to that. That code will then load the boot loader
(NTLDR, LILO, GRUB) from the hard disk and transfer control to it. The
boot loader will subsequently load the operating system from one of the
partitions on the disk and transfer control to it. The operating system
will then transition from real-mode to protected mode, then will enable
paging and transition to long mode.

Here's an example of the primary bootstrap code in the first ~450 bytes
of the MBR:

#
# Master Boot Record
#

RELO_ADDR=0x600
BASE_ADDR=0x7c00
S2_SEG=0x9020
S2_ADDR=0x0000

#
# These values must match the offsets in geometry_info
#
SECTORS_PER_TRACK=0
MAXIMUM_HEADS=4
MAXIMUM_CYLS=8
SECTOR=10
HEAD=11
CYLINDER=12

STAGE2SECTOR=1
DVMM_SECTOR=5

.code16
.text

#
# These 512 bytes of code and data are loaded by the bios at 0x0000:0x7c00.
#
# Called with
# %dl Drive number booted from (00 = floppy A, 80 = hard disk C)
# %es:%di PnP Installation Check structure
#
.global start
start:
cli # Disable interrupts
xorw %ax, %ax # Clear %ax
movw %ax, %ss # Set stack segment
movw $BASE_ADDR, %sp # Set stack pointer

#
# Relocate the master boot record from the initial 0000:7c00
# address to 0000:0600 and transfer control to the newly relocated
# code.
#
movw %sp, %si # Pointer to starting byte to move
pushw %ax
popw %es # Set ES register to 0000
pushw %ax
popw %ds # Set DS register to 0000
sti # Enable interrupts
cld # Set direction forward
movw $RELO_ADDR, %di # Pointer to destination address
movw $0x100, %cx # Move 256 words
repz movsw # Move 512 bytes from 0000:7c00 to 0000:0600
ljmp $0x0, $RELO_ADDR+1f # Branch to relocated code
1:

#
# Save the drive number that we were loaded from.
#
movb %dl, (RELO_ADDR+drive_num)

#
# Get drive geometry.
#
pushw %dx
movb $0x8, %ah # Get drive information
movw $0x7c00, %di # Just in case
int $0x13 # Get geometry
jc read_error # Jump if error

#
# Convert the drive geometry from zero-based values to one-based values.
#
movw $(RELO_ADDR+geometry_info), %si
xorl %eax, %eax
movb %dh, %al # Maximum heads
incw %ax # Turn "max" into "count"
movl %eax, 4(%si) # Store
xorw %dx, %dx
movb %cl, %dl # Copy composite value
shlw $2, %dx # shift left twice
movb %ch, %al # Copy low 8 bits of max cyl
movb %dh, %ah # And the upper two bits
incw %ax # Turn "max" into "count"
movw %ax, 8(%si) # Store
xorw %ax, %ax
movb %dl, %al # Get max sector
shrb $2, %al # Normalize
movl %eax, (%si) # Save it

#
# Read in the second stage bootstrap
#
xorw %dx, %dx # Clear high order sector number
movw $STAGE2SECTOR, %ax # Low order sector number
movw $S2_SEG, %bx # Segment Address to read into
movw %bx, %es # Set segment register and
xorw %bx, %bx # clear the offset.
movw RELO_ADDR+s2sectors, %cx # Number of sectors to read
call readblocks # Fetch it
jc read_error # Bail on error

#
# Read in the Hypervisor, 32K at a time.
#
xorl %ecx, %ecx # Clear register
xorl %edi, %edi
movw RELO_ADDR+syssize, %di
shll $4, %edi # Convert from "clicks" to bytes
movw $STAGE2SECTOR, %ax # Stage2 sector #
addw RELO_ADDR+s2sectors, %ax # Add size of stage2 bootstrap
movw $0x1000, %bx # Segment address
movw %bx, %es # Set segment register

loop:
cmpl $0, %edi # Are we done?
je done # Yep.

cmpl $0x7fff, %edi # Do we have more than 1 segment left?
movw $0x7fff, %si
cmovge %si, %cx # If yes, read one segment
cmovl %di, %cx # If no, read the remainder

subl %ecx, %edi # Subtract the read amount off of the total
# We have to do this before we convert %cx
# to sectors.

addl $511, %ecx # 512-1
shrl $9, %ecx # Divide by 512 to get sectors
xorw %dx, %dx # clear high order sector number
xorw %bx, %bx # Clear offset
pushw %ax # Save sector offset
pushw %cx # Save sector count
call readblocks # Fetch it
jc read_error # Bail on error
popw %cx # Restore sector count
popw %ax # Restore sector offset

addw %cx, %ax # Increment the sector ptr by the # read
movw %es, %si
addw $0x800, %si # Increment %es to point to the next segment
movw %si, %es
jmp loop # repeat.
done:

#
# The BIOS uses a PIT timer (channel) zero to establish a 2-second
# timeout period after which it will turn off the floppy drive motor.
# Since the DVMM will re-purpose the PIT0 timer, we'll turn off
# the floppy motor here.
#
movw $0x3f2,%dx # Address of floppy controller
xorb %al, %al # Turn off floppy motor
outb %al, %dx # send the command

#
# Invoke stage2 bootstrap code
#
movw $(RELO_ADDR+missingos), %si # Message, if necessary
movw $S2_SEG, %bx # Stage 2 loader
movw %bx, %fs # Segment
movw $0x1fe, %di # 510 bytes into stage 2 loader is signature
cmpw $0xaa55, %fs:(%di) # Check for signature
jnz printmsg # If not there, print message

ljmp $S2_SEG, $S2_ADDR # Invoke secondary bootstrap

#
# Convert a Logical Block Address to a CHS address
#
# LBA - provided in AX:DX
# Cylinder is returned in global variable cylinder
# head head
# sector sector
#
# Returns:
# Carry set on error
# Carry clear on success
#
convert:
movw $(RELO_ADDR+geometry_info), %si # Pointer to geometry info
# cmpw %dx, SECTORS_PER_TRACK(%si) # Compare to sectors per track
# jg 1f # Branch if so

divw SECTORS_PER_TRACK(%si) # Divide %DX:%AX by sectors_per_track
incb %dl # Make one-relative
movb %dl, SECTOR(%si) # Sector to read
xorw %dx, %dx # Zero
divw MAXIMUM_HEADS(%si) # Divide by # heads
movb %dl, HEAD(%si) # Head to use
movw %ax, CYLINDER(%si) # Cylinder from which to read.
clc # Clear carry
ret # Return to caller
1:
stc # Set carry - LBA out of range
ret # return to caller

#
# Read a block into memory
#
# Disk Address is in %dx:%ax
# Memory Address to read into is %es:%bx
# Number of sectors to read in %cx
#
# Returns:
# Carry set on error
# Carry clear on success

readblocks:
movw %dx,(RELO_ADDR+next_sector+2) # save High order word
movw %ax,(RELO_ADDR+next_sector) # Low order word
movw %cx,(RELO_ADDR+sector_count) # Number of sectors to read

3:
call convert # Convert LBA to CHS
jc 2f # Failed. Bail.

movb %cl, %al # Number of sectors to read
movb $0x02, %ah # INT 0x13 AH=0x02 (READ SECTORS)
movw CYLINDER(%si), %dx # Get cylinder number
shlb $6, %dh # Shift left 6 bits
orb SECTOR(%si), %dh # Or in sector number
movw %dx, %cx # Copy
xchg %cl, %ch # CH=cyl lo, CL=cyl hi+sect
movb (RELO_ADDR+drive_num), %dl # Drive number
movb HEAD(%si), %dh # Head number
int $0x13 # Go do the IO
jc 1f # Branch if failure
ret

1:
testb $0xff, %al # Any sectors transferred?
jnz 9f # no, real read error

#
# This is a nasty hack. The SimNow cheetah BIOS returns 00 in AL
# even when it reads an entire track. This hack breaks if there is
# a real error!
#
movb $0x12, %al # HACK-COUGH-KLUDGE SimNow BIOS

9: movzbw %al, %dx # Setup for multiply
shlw $9, %dx # Multiply by 512
addw %dx, %bx # Bump start address by # read

movzbl %al, %edx # zero extend number sectors read
subw %dx, (RELO_ADDR+sector_count) # Decrement by # sectors read
addl %edx, (RELO_ADDR+next_sector) # Increment next sector address
movw (RELO_ADDR+next_sector+2), %dx # reload high-order word
movw (RELO_ADDR+next_sector), %ax # reload low-order word
movw (RELO_ADDR+sector_count), %cx # reload count of sectors to fetch

jmp 3b # and read the rest.

2:
stc # Indicate error
ret # and return.
geometry_error:
read_error:
movw $(RELO_ADDR+readerr), %si
#
# Print a message
#
# Message is in %si
# **THIS FUNCTION DOES NOT RETURN! **
#
printmsg:
lodsb
cmpb $0x00, %al # Terminate on zero byte
jz halt

pushw %si # Save
movw $0x7, %bx # Video Attribute
movb $0xe, %ah # Write TTY
int $0x10 # write byte to screen
popw %si # Restore
jmp printmsg # loop

halt:
jmp halt

errorloading:
.string "Error Loading OS"
missingos:
.string "Missing OS"
readerr:
.string "Read error"

geometry_info: # Geometry information
sectors: # Sectors per track
.long 0
heads: # Number of heads
.long 0
cylinders: # Number of cylinders
.word 0
sector_start: # Starting Sector #
.byte 0
head_start: # Starting Head #
.byte 0
cylinder_start: # Starting Cylinder #
.word 0
next_sector: # Next linear block number to read
.long 0
sector_count: # Count of sectors to read
.word 0
drive_num: # The drive number the BIOS loaded us from.
.byte 0

.org 497
#
# This byte is written by the boot/build.c program to contain
# the number of sectors in the secondary boot code.
#
s2sectors:
.byte 4 # Number of sectors of setup code
.word 0 # Root Flags
#
# This word is written by built/build.c to contain the number of
# bytes of system code divided by 16.
#
syssize:
.word 0 # System Size
.word 0 # Swap device
.word 0 # RAM size
.word 0 # SVGA mode
.word 0 # ROOT device
.word 0xAA55 # Boot sector signature.

[s_dub...@yahoo.com]

On Tuesday, November 7, 2017 at 10:19:16 PM UTC-6, Rod Pemberton wrote:
> On Tue, 7 Nov 2017 14:55:58 -0800 (PST)
> "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:
>
> > > I'm not seeing hidden sectors with the actual floppy images, only
> > > with the "errant" hard disk image that has a partition that starts
> > > at sector 63.
> >
> > How did you determine this, from the MBR originally?
>
> No, not the MBR. I wrote a image of random bytes to the USB stick after
> booting it. The USB was being emulated by BIOS for the booted image.
> For the booted "errant" hard disk image, the random image was offset by
> 63 sectors from the start of the USB stick. For a booted floppy image,
> the random image had no offset from the start of the USB stick.

Ok, but the MBR Partition Entry should show that the partition starts at
63 sectors from the start of the usb stick, just saying.

Yes, but my MBR bootable partition table entry shows that partition starts
at Logical Block 20h, 32d, just saying.

So, I posted after you, about what you found, but I hadn't seen your post
yet. And I agree with you that you seem to have matched the ZIP form, and
we now know about the rules involved, basically. And where the ZIP form is
and the conditions of when it comes into play.

> > It would be helpful to know what the original MBR indicated as the
> > start of the partition.
>
> The Linux file command and fdisk -l on the image both report the
> startsector as 63.
>
> (I have code for DOS which reads BPB/EBPB, but it doesn't work with
> images. DOS is flaky with non-emulated USB. You have to load special
> drivers, which sometimes work, but not usually with a USB keyboard
> and USB mouse. So, I'd need to pop in my AT keyboard w/PS/2 adapter
> too. I also don't have my code working on Linux. And, I'd have to
> re-read the code to familiarize myself with the BPB/EBPB structure(s),
> as it was written some years ago. So, if you have some offsets, I
> could just do a hexdump to grab values for you. Or, I could just post
> a 512 byte hexdump or perhaps a few. You could look at the values you
> want.)
>
> > > > > c) if the booted image has a partition (or perhaps BPB), USB-HDD
> > > > > starts emulation with start of the partition. Tracks prior to
> > > > > the partition start are inaccessible via Int 13h.
> > > >
> > > > o software safety lock, I guess.
> > >
> > > That would be interesting. Why would they do that? ...
> >
> > To keep user code from messing with 'outside the OS space' systems
> > area.
> >
>
> To me, that's a very interesting statement. Why are you making the
> distinction that the "systems area" is "'outside the OS space'" and not
> actually part of the OS proper? ...
>

Well the MBR sits before the OSes boot, say you have 4 active partition
table entries for 4 OS versions... Minix shouldn't touch xenix, or PCDOS
or OS/2 or vice versa. The MBR is outide their domain, the way I look at
it. The exception is a needed utility for each OS to unmark its partition table entry as bootable and mark another table entry as bootable. This is
done instead of a multiboot menu scheme and the code to service that hidden
in the boot track, for illustration.

> Even when the machine has multiple OSes installed, there is usually one
> primary OS that is in control of the region. So, I view the "systems
> area", as you're calling it, as part of an OS, since the (primary) OS
> controls what needs to be there for it to boot correctly. Therefore,
> to me, it's part of the OS space, usually one, perhaps multiple,
> sometimes.

That was msdos's attitude with their early-ish FDISK stomping over other
OS partitions.

> Is this a holdover concept from another OS that you're familiar with,
> perhaps CP/M?
>

No, but maintaining multiple OS partitions kinda brought the concept home.
CP/M-86, CCP/M-86, PCDOS or MSDOS partitions. -it just an aside, now we
have these USB HDD things, just plug in another.

> > Do you have CMOS refs handy,
>
> RBIL has a CMOS list, IIRC. I'm sure I can find one, if not.
>
> > am I correct about HDD geometry entries as defaults?
>
> I don't understand what you're asking about here.
>
> Which geometry entries? What defaults? Are you referring to one of my
> images or your image which you described? Or, was this something to do
> with you asking about CMOS? CMOS hardware defaults? ...

I'm wondering if the CMOS holds default values for HDD geometry for C,H,S,
whether there is a default HDD parameter table held in the CMOS in the
vintage 286-386 systems that is mimicked in the real mode bootstrap in
the modern machines. I hope that is clearer, its academic, not important.

Steve

[Scott Lurndal]

"s_dub...@yahoo.com" <s_dub...@yahoo.com> writes:
>
>
>I'm wondering if the CMOS holds default values for HDD geometry for C,H,S,
>whether there is a default HDD parameter table held in the CMOS in the
>vintage 286-386 systems that is mimicked in the real mode bootstrap in
>the modern machines. I hope that is clearer, its academic, not important.
>
>Steve

The out-of-print book "The Undocumented PC" describes the CMOS
configuration, if you can find a copy.

http://www.undocumentedpc.com/

[Rod Pemberton]

On Wed, 8 Nov 2017 10:04:33 -0800 (PST)
"s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:

> On Tuesday, November 7, 2017 at 10:19:16 PM UTC-6, Rod Pemberton
> wrote:

> > No, not the MBR. I wrote a image of random bytes to the USB stick
> > after booting it. The USB was being emulated by BIOS for the
> > booted image. For the booted "errant" hard disk image, the random
> > image was offset by 63 sectors from the start of the USB stick.
> > For a booted floppy image, the random image had no offset from the
> > start of the USB stick.
>
> Ok, but the MBR Partition Entry should show that the partition starts
> at 63 sectors from the start of the usb stick, just saying.

Yes, it does.

This is the cause of the offset for USB-ZIP emulation, since it starts
drive emulation at the partition start, i.e., sector 63, not sector 0.
CHS 0,0,1 is translated from sector 0 to sector 63.

> > > 8000h/200h = 40h = 64d
> > >
> > Just below ...
> >
> > Just like 0xAA55 is just below 0x200, i.e., 0x1FE.
> >
>
> Yes, but my MBR bootable partition table entry shows that partition
> starts at Logical Block 20h, 32d, just saying.
>

Ok, okay. I'll write them to a real floppy and see what's there.

Plan A. Write to floppy. Well, that didn't work out too well. The
"errant" image won't boot as a floppy, and my DOS code for displaying
BPBs and partitions only worked for FAT16 and FAT32 from real devices,
only for the active device ..., and not FAT12, and not images or files.

Plan B. I did a brute-force patch to one of my DOS apps which I wrote
that dumps the partitions and BPB for FAT16/FAT32, to read the first
sector from a file (partition table and/or FAT12 BPB) and the also 63rd
sector (offset 0x7E00, location of the PBR/BPB in the "errant" image).
Normally, I would compute the latter location, but ...


The floppy images report:

partition ("junk", i.e., code, no partitions)
heads 2
sectors 18
total sectors 2880
media descriptor 0xF0 (floppy)
FAT12


The "errant" WinXP floppy-sized hard disk image reports:

Win95 FAT16X (LBA) 0x0E
partition hst s 1,22,0 e 2,218,247 length 0x1F3C1
heads 3
sectors 42
total sectors 127937
media descriptor 0xF8 (hard disk)
FAT16

Total sectors and type matches with what the Linux FILE and FDISK
commands display for the image. Both of those say the starting sector
is 63 which also matches hst 1,22,0 (chs 0,1,22) = (0x3+1)x42+(22-1) =
63.

Note that the program displays all the BPB fields and partitions, but I
only listed what I thought was relevant. If there are other fields
you want, say so. Obviously, hst is head, sector, track, not chs for
cylinder, head, sector.

Of course, the partition size is far greater than the image size of
1.44MB, since this info was copied from a real partition of about 2GB.
The "errant" image info was copied from a Compact Flash (CF) memory
card with IDE adapter. My guess is that explains the BPB heads value
of three ... WTF, right? Maybe that explains your 0x20/32 also? Even
heads? IDK.


Unfortunately, nothing to do with the "errant" image explains the
corruption issue as I'm seeing that with the FAT12 images too.

> > > Do you have CMOS refs handy,
> >

> > [...]

>
> I'm wondering if the CMOS holds default values for HDD geometry for
> C,H,S, whether there is a default HDD parameter table held in the
> CMOS in the vintage 286-386 systems that is mimicked in the real mode
> bootstrap in the modern machines. I hope that is clearer, its
> academic, not important.
>

RBIL's CMOS.LST lists many CMOS locations with heads, cylinders,
sectors, in different locations, for various BIOSes. I'm not sure
which is which.

BTW, what happened to your website? I may have asked you that already.

[s_dub...@yahoo.com]

On Thursday, November 9, 2017 at 1:31:55 AM UTC-6, Rod Pemberton wrote:
> On Wed, 8 Nov 2017 10:04:33 -0800 (PST)
> "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:
>
> > On Tuesday, November 7, 2017 at 10:19:16 PM UTC-6, Rod Pemberton
> > wrote:
>
> > > No, not the MBR. I wrote a image of random bytes to the USB stick
> > > after booting it. The USB was being emulated by BIOS for the
> > > booted image. For the booted "errant" hard disk image, the random
> > > image was offset by 63 sectors from the start of the USB stick.
> > > For a booted floppy image, the random image had no offset from the
> > > start of the USB stick.
> >
> > Ok, but the MBR Partition Entry should show that the partition starts
> > at 63 sectors from the start of the usb stick, just saying.
>
> Yes, it does.
>
> This is the cause of the offset for USB-ZIP emulation, since it starts
> drive emulation at the partition start, i.e., sector 63, not sector 0.
> CHS 0,0,1 is translated from sector 0 to sector 63.
>

Ok, I get how it works.

No, that's enough.

> Obviously, hst is head, sector, track, not chs for
> cylinder, head, sector.
>
> Of course, the partition size is far greater than the image size of
> 1.44MB, since this info was copied from a real partition of about 2GB.
> The "errant" image info was copied from a Compact Flash (CF) memory
> card with IDE adapter. My guess is that explains the BPB heads value
> of three ... WTF, right? Maybe that explains your 0x20/32 also? Even
> heads? IDK.
>

My values comes from the MBR and the active partition table entries that
I copied to the 16gb usb thumb drive.

The int 13h 'get drive parameters' don't match what my write tests have
shown. My write test have shown a geometry of 32 sectors per head, only
2 heads per cylinder.

>
> Unfortunately, nothing to do with the "errant" image explains the
> corruption issue as I'm seeing that with the FAT12 images too.
>
> > > > Do you have CMOS refs handy,
> > >
> > > [...]
> >
> > I'm wondering if the CMOS holds default values for HDD geometry for
> > C,H,S, whether there is a default HDD parameter table held in the
> > CMOS in the vintage 286-386 systems that is mimicked in the real mode
> > bootstrap in the modern machines. I hope that is clearer, its
> > academic, not important.
> >
>
> RBIL's CMOS.LST lists many CMOS locations with heads, cylinders,
> sectors, in different locations, for various BIOSes. I'm not sure
> which is which.

I don't know where int 13 'get drive parameters' is getting values from.
It doesn't matter, I needn't depend on them. What's important is: don't
take the 'obvious' as obvious, I've learned.

>
> BTW, what happened to your website? I may have asked you that already.

hostoi.com was where the small c stuff was at. It expired after All
Thoughts Thinkith decided to 'protect me' from that nefarious portion
of the web which included its domain, and blocked access to it. Anon
web browsing let me view it but not manage it. Maybe this winter I'll
re-upload my local copy to somewhere..

[john]

> In article <ou1099$1qjt$1...@gioia.aioe.org>, EmailN...@voenflacbe.cpm says...

> The floppy images report:
>

Hi Rod

I stopped reading your thread after your initial post said you were giving up
but I noticed yesterday you were still working on it.

The thread has me a bit confused - as to what your problem is exactly?

I have some simple boot code here I wrote to get TIOS started that
boots from flash and plonks the machine into 32bit mode I may be able
to let you have a version of that if it would help.

To run it you need to format the flash drive first then overwrite sector 0
with my image. It's written in NASM. Its just a very basic x86 startup sector.
The rest of my boot sequence wouldn't be any use to you as its TIOS specific.

I'm a bit hesitant as there are tons of these around - hence I'm not sure
of your exact issue.

Let me know if I can help anyway.


--

john

=========================
http://johntech.co.uk
=========================

[Rod Pemberton]

On Fri, 10 Nov 2017 11:08:42 -0000
john <an...@example.com> wrote:

Welcome to the new the guys: John, Scott, ...

> The thread has me a bit confused - as to what your problem is exactly?

(Sorry, I thought I posted this a few days ago.)

The BBS boot menu options on this computer for booting USB (USB-FDD,
USB-HDD, USB-ZIP) do not appear to correctly boot a USB memory stick
which was written with a bootable 1.44MB floppy image of MS-DOS (v7.10
from Win98/SE). The USB-FDD, USB-HDD, and USB-ZIP options are intended
for physical devices, e.g., external USB floppy or external USB hard
disk or external USB ZIP drive, but they should boot USB memory sticks
too.

I.e., I can't simply copy a working, bootable MS-DOS image from a real
floppy disk and write it to a USB stick and it will boot DOS without
corruption, when accessed from DOS and emulated via the BBS menu
options USB-FDD, USB-HDD, or USB-ZIP.

The floppy drive USB boot option (USB-FDD) doesn't boot. The hard disk
USB boot option (USB-HDD) redirects to the ZIP drive (USB-ZIP). The
ZIP drive USB boot option (USB-ZIP) will boot certain DOS floppy images
from USB stick. However, the data on the USB stick appears to be
corrupt, but only when accessed from DOS on the booted USB stick and
only for files on the booted USB stick. The issue doesn't affect
non-emulated drives, nor does it affect the USB stick when read from
Linux, nor does it affect the booted USB stick when written to using
Int 13h functions from DOS, nor does it affect other drives.

Apparently, images or devices for USB-FDD, USB-HDD, USB-ZIP, must meet
certain constraints to boot correctly, according the pdf I posted a
link to.

Perhaps, I'll have better luck with a small hard disk image. I
believe the hard disk image I tried by mistake was redirected to
USB-ZIP from USB-HDD. It was showing corruption too. So, maybe, the
USB-ZIP emulation or BPB values or SMM or Int 25h/26h etc has a problem.

[john]

> In article <oua8a2$4tp$1...@gioia.aioe.org>, EmailN...@voenflacbe.cpm says...

>

>
> The BBS boot menu options on this computer for booting USB (USB-FDD,
> USB-HDD, USB-ZIP) do not appear to correctly boot a USB memory stick
> which was written with a bootable 1.44MB floppy image of MS-DOS (v7.10
> from Win98/SE).

OK first check you have that boot device correctly enabled in the BIOS
(Tell us the bios/ver No. and PC details/age if you still have issues)

I see you have linux so try this (I just did and it works here)
Locate and install unetbootin -
if you use partedmagic (old free version preferably)
unetbootin should be built in so boot that not your normal linux

In linux or partedMagix:
(copy anything off your stick want to keep)

First put the stick in and startup GPARTED
Delete all partions from the stick
Create a new MSDOS partition table (click "advanced" to double check the type)
Create a new fat32 primary taking the whole stick size and give it a label
Go to manage flags and select bootable
Mount the drive

Start Unetbootin
select "diskimage" and change ISO to Floppy
Put in the path/filename to your floppy.img

BE CAREFUL:
**** check the Type line is USB Drive and the drive is the right device ***

Click ok to copy the image
Reboot the machine and select the device from the bios boot menu
Windows98 will now boot from the USB stick to the A:\> prompt.

That works fine on my Sandisk 30GB ram stick - a bit wasteful but there you go.
At least you know a method that works and you can step through and change
things one at a time to suit yourself.

If you hit a snag with something you absolutely must have just list the changes
and your hardware/software versions and we can take it from there.

[Rod Pemberton]

On Thu, 9 Nov 2017 15:53:31 -0800 (PST)
"s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:

> > Unfortunately, nothing to do with the "errant" image explains the
> > corruption issue as I'm seeing that with the FAT12 images too.
> >

> [...]

Ok. I made another attempt. This time I attempted a hard disk image,
but I ran into a few issues. Fortunately, there was no apparently
obvious file corruption, like before, but I didn't use a floppy FAT12
image this time.

I managed to create a bootable USB stick from Linux for which I'm not
yet noticing any file corruption, at least for the DOS text
configuration files. Normal DOS executables seem to work too. More
invasive executables, e.g, to boot Linux or USB drivers or CD-ROM
drivers, which seem to hang ... I don't know if that means
file corruption, or if it's just a BIOS emulation issue, or
incompatibility of some sort.

It boots under USB-HDD, but as a floppy A:. So, it likely booted as
USB-ZIP again. The image has two partitions. The first is FAT16 with
MBR. The second was set to 1 to 63 as a hidden FAT12. I wanted
something not bootable, not recognizable by BIOS, and which fit into
1.44MB. Perhaps, there might've been a better choice than the low
sectors or the hidden FAT12 type. I might try a partition type other
than DOS or Linux, so the BIOS won't recognize it. Or, maybe, that's
the wrong thing. Maybe, it needs to be another FAT16? IDK...

So, the USB stick does not have a true hard disk image. It has a FAT16
PBR/VBR. The filesystem, however, is actually FAT12 as the Linux
utility mkfs.vfat didn't like the partition size for FAT16, i.e., too
small. There was no way to force it.

So, I might retry this again, later, as it seems the USB stick likely
booted without corruption. I'll probably make an image later that's
larger in size, perhaps 2.88MB instead of 1.44MB, or one which starts
at a higher sector (1024 or 2048), instead of sector 63. Apparently,
FAT16 needs more space for FATs. I guess I need to look up the
required for FAT16.

I might attempt this with the 2nd partition in a different location
too. I placed it low, i.e., sectors 1 to 63, to fit a floppy in size.
This reverse order of partitions might be an issue too, e.g., confusing
the BIOS. I'll probably re-size the partition/image smaller,
afterwards.

I couldn't figure out a way to create this in DOS, as the BIOS
emulation for USB stick as a hard disk must work first in order for the
DOS utilities to treat it as a hard disk.

[Benjamin David Lunt]

Hi Rod,

"Rod Pemberton" <EmailN...@voenflacbe.cpm> wrote in message
news:ov7muq$1p86$1...@gioia.aioe.org...

> On Thu, 9 Nov 2017 15:53:31 -0800 (PST)
> "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:
>
>> > Unfortunately, nothing to do with the "errant" image explains the
>> > corruption issue as I'm seeing that with the FAT12 images too.
>> >

[...]

> It boots under USB-HDD, but as a floppy A:. So, it likely booted as
> USB-ZIP again. The image has two partitions. The first is FAT16 with
> MBR.

Do you mean, there is a MBR at LBA 0 and then the first partition
starts at LBA n with a FAT16 BPB? Or do you mean that the first
partition starts at LBA n with a MBR which then points to LBA n+x
where LBA n+x has a FAT16 BPB?

Most likely, LBA 0 has a MBR which points to LBA n which has a
FAT16 BPB. Yes?

> The second was set to 1 to 63 as a hidden FAT12. I wanted
> something not bootable, not recognizable by BIOS, and which fit into
> 1.44MB. Perhaps, there might've been a better choice than the low
> sectors or the hidden FAT12 type. I might try a partition type other
> than DOS or Linux, so the BIOS won't recognize it. Or, maybe, that's
> the wrong thing. Maybe, it needs to be another FAT16? IDK...

I have found that, at least all the BIOSes I have tried, it doesn't
matter what the Sys ID field is, as long as it is non-zero and the
remaining fields are (somewhat) valid. The BIOS will load the active
partition and jump to it. Period.

> So, the USB stick does not have a true hard disk image. It has a FAT16
> PBR/VBR. The filesystem, however, is actually FAT12 as the Linux
> utility mkfs.vfat didn't like the partition size for FAT16, i.e., too
> small. There was no way to force it.
>
> So, I might retry this again, later, as it seems the USB stick likely
> booted without corruption. I'll probably make an image later that's
> larger in size, perhaps 2.88MB instead of 1.44MB, or one which starts
> at a higher sector (1024 or 2048), instead of sector 63. Apparently,
> FAT16 needs more space for FATs. I guess I need to look up the
> required for FAT16.

A true valid FAT16 partition must have at least 4085 clusters and
not more than 65524 clusters. Clusters, not sectors, so even if
there is a 1:1 ratio, one sector to a cluster, you still have to have
at least 4085+BPB+reserved+(FAT*count)+Root sectors to be valid.
This is probably why Linux didn't like the partition size.

A 2.88MB partition would probably be just about the right size,
on the small side, for a valid FAT 16 (1:1 ratio) partition.
(2.88MB = 5760 sectors)

> I might attempt this with the 2nd partition in a different location
> too. I placed it low, i.e., sectors 1 to 63, to fit a floppy in size.
> This reverse order of partitions might be an issue too, e.g., confusing
> the BIOS. I'll probably re-size the partition/image smaller,
> afterwards.
>
> I couldn't figure out a way to create this in DOS, as the BIOS
> emulation for USB stick as a hard disk must work first in order for the
> DOS utilities to treat it as a hard disk.

All the BIOSes I have tried, when HDD emulation was desired, would
require a valid MBR partition table with at least one valid entry.
They didn't check anything about the partition it pointed to, just
the partition entry itself. It would load the first sector of the
partition and boot it. (I did not check for a valid 0xAA55 sig, but
I bet it did this check after loading it.)

When a Floppy image emulation was desired, I could get only one
machine (BIOS) to boot it as a floppy. All the remaining would
boot it as a 1.44Meg HDD, or not boot at all due to the fact that
there was not a valid partition table.

Your comments (or at least someone's here on this group) are the
only time where I have heard that the BIOS would emulate the
partition as the whole drive. i.e.: if the partition was
from 63 to 12345, the BIOS would emulate the drive as 80h and
LBA 0 to LBA 12345-63. If you had more partition entries, these
would be drive 80h+n and LBA 0 (physically LBA 12346) to LBA x
(physically LBA 12346+x), another part of the same device.

Which, BTW, I think is a good practice for a BIOS. Just my
opinion though.

Change the size of your small partition to at least 5760 sectors
and you should be able to format it as a FAT 16 partition.

Oh, and none of the BIOSes I have allow me to choose how to
boot the USB device, such as USB-Floppy, USB-HDD, or USB-Zip,
like you have stated. All mine simply say "USB Device" or
name the device, gathered from the string descriptors of the
USB device.

<side note>
As a side note, to learn a little more, I am thinking (and
please don't quote me on this (smile), it is just a thought),
I am thinking of adding USB booting to Bochs. Right now, Bochs
will boot a HDD, Floppy, or CDROM. USB booting will be almost
identical to the three already included, except that now it
would give the option if specified. i.e.:

boot: usb, [auto|floppy|hdd|cdrom]

It should be quite simple to add, all I need to do is the
menu part within the BIOS, do any checks I wish to do (as
discussed within this thread), then hand over the remaining
back to the existing code, except use the file pointed to
by the USB line instead of the ATA or Floppy line.

Just a thought.
</side note>

Anyway, for those here in the States, I hope you had a
Happy (and filling) Thanksgiving. For those of you who
are not in the States, you missed out on some good eat'n :-)

Thanks everyone for at least there is still some OS
development related posts here in this group.

Ben

[Rod Pemberton]

On Thu, 23 Nov 2017 19:32:31 -0700
"Benjamin David Lunt" <zf...@fysnet.net> wrote:

> > It boots under USB-HDD, but as a floppy A:. So, it likely booted as
> > USB-ZIP again. The image has two partitions. The first is FAT16
> > with MBR.
>
> Do you mean, there is a MBR at LBA 0 and then the first partition
> starts at LBA n with a FAT16 BPB? Or do you mean that the first
> partition starts at LBA n with a MBR which then points to LBA n+x
> where LBA n+x has a FAT16 BPB?
>
> Most likely, LBA 0 has a MBR which points to LBA n which has a
> FAT16 BPB. Yes?

No. This was like a messed up hybrid since it wouldn't format FAT16 ...

a) That attempt: MBR with FAT16 partitions, FAT12 floppy boot code
instead of PBR, and a FAT12 file system.

The first sector has a MBR with two partitions. The first is marked as
type 'e' FAT16 LBA. The first partition has a floppy FAT12 boot record
and FAT12 file system. Yes, the floppy boot record that would normally
start at the beginning of the disk. Since USB-HDD is likely
redirecting to USB-ZIP, which starts emulation at the start of the
partition. So, it's probably booting the floppy boot code directly.


b) New attempt: MBR with FAT16 partitions, FAT16 PBR, FAT12 file system.

ms-sys (Linux util for writing various MBRs, PBRs, boot code, BPB data,
etc) says there are 4 sectors/cluster for this USB stick. I used an
option for ms-sys to force a FAT16 PBR. Same results. No apparent
corruption. USB-HDD boots as A:. I.e., probably, redirect to USB-ZIP.


c) Final attempt: MBR with FAT16 partitions, FAT16 PBR, FAT16 file
system.

To format as a FAT16 file system, mkfs.vfat (Linux util for FORMATing)
requires 16408 sectors in the partition (from 63 to 16470). That's
just over 8MB. Anything below that and it won't format the file system
as FAT16. It's dated 2012. Maybe, I need to update it? ... I thought
I read that FAT16 could be as small as 4MB.

Result: hangs.


I also tried partition type 4 and 6 instead of 'e'. I also tried a
couple of other MBR code options that ms-sys has. It can create MBRs
for DOS, NT, 98/98/ME, 2K/2K3/XP, Win7, syslinux. It can create floppy
boot code or PBRs for DOS FAT16, FreeDOS FAT16, DOS FAT32, FreeDOS
FAT32, and NT FAT32. It can do some other options, like zero the MBR,
set heads, write partition info to MBR. The last one seems to be for
FAT32.


So, my odd results so far:

USB-FDD - nothing boots

USB-ZIP - boots anything FAT12 but may be corrupt ...
-file corruption if using an actual FAT12 floppy image
-boots with no apparent corruption if MBR with FAT16 partitions, FAT12
boot code for PBR, FAT12 file system
-boots with no apparent corruption if MBR with FAT16 partitions, FAT16
PBR, FAT12 file system

USB-HDD
-suspect that this redirects to USB-ZIP most of the time
-hangs if MBR with FAT16 partitions, FAT16 PBR, FAT16 file system


That's it for tonight. Some other day, maybe.

I'll likely dump the BPB later. I see an f8 (floppy) in the hex dump of
the PBR, but I don't what field, if any, that I'm looking at. It might
be that the Linux util isn't writing f0 (hard disk) for the BPB due to
USB stick? ...

Sigh, I wish I could do this from DOS, but I have to get USB-HDD to
boot as C: (instead of A:), in order to have correct BIOS USB emulation
(DL=80h) to use DOS FDISK. DOS FDISK won't work with floppies or USB
sticks emulated as floppies. It's amazing how "painful" this slight
issue is. Ever hear of a patch?

[James Harris]

I have held off from commenting much on this thread as I have been
confused as to exactly what you are putting on the USB memory and,
frankly, it seems so complicated that I feel that if I asked you the
answer would be just as incomprehensible. ;-)

For example, you seem to say above that you've made a bootable USB stick
which is for Linux but which includes DOS executables. And then, it
boots under USB-HDD but as a floppy - and is likely seen as a USB-ZIP.
What??? You seem to have all three options which are apparently supposed
to be mutually exclusive happening at the same time! And on top of all
that, the USB stick has a FAT16 VBR which is really FAT12. Aargh!!!
Please don't explain; I'm sure that I would need so much info try to
follow it that that my memory circuits would explode!

Instead, I was going to suggest two things.

(1) If possible, use an image and a boot method which are consistent -
i.e. all floppy or all HDD. (I would ignore the ZIP option.)

(2) Use a boot sector which prints startup info such as the boot DL and
any relevant CHS geometry info you might get from the BIOS. That ought
to provide info to allow you to verify that what the BIOS believes is
going on is what you expect. You may have done this already with tboot
but I don't know whether you combined that with a consistent boot approach.


--
James Harris

[Rod Pemberton]

On Fri, 24 Nov 2017 16:19:07 +0000
James Harris <james.h...@gmail.com> wrote:

> I have held off from commenting much on this thread as I have been
> confused as to exactly what you are putting on the USB memory and,
> frankly, it seems so complicated that I feel that if I asked you the
> answer would be just as incomprehensible. ;-)

For the first 90% of my posts, I was using a standard FAT12 floppy
image. I have a large archive of these. They were created in MS-DOS
on a real floppy and copied onto my hard drives. I was working with a
few of these image. I was simply writing them, as-is, to USB sticks.
So, the USB stick had a real FAT12 floppy image created with MS-DOS.
The BIOS emulations for USB (USB-FDD, USB-HDD, USB-ZIP), either didn't
work with the USB stick, or if the image booted, was showing file
corruption of some mysterious sort.

> For example, you seem to say above that you've made a bootable USB
> stick which is for Linux but which includes DOS executables.

I made a DOS (MS-DOS v7.10) bootable USB stick from Linux, using Linux
utilities, containing DOS executables. Some of those executables can
load Linux from DOS, e.g., LINLD and LOADLIN.

> And then, it boots under USB-HDD but as a floppy - and is likely
> seen as a USB-ZIP. What???

Yes. From the .pdf which I posted a link to, USB-HDD falls back to
USB-ZIP, if the booted USB device only has one partition. That's
what I'm seeing this machine do, i.e., results of tboot. USB-HDD boots
as a hard disk, DL=80h. But, USB-ZIP and USB-FDD boot as floppy drives,
DL=00h. USB-ZIP is for ZIP floppy drives which require a partition.

> You seem to have all three options which are apparently supposed to
> be mutually exclusive happening at the same time!

ISTM, that you didn't follow what was required for the BIOS boot
options in the .pdf.

> And on top of all that, the USB stick has a FAT16 VBR which is
> really FAT12. Aargh!!!

This was for the other recent 10%, where I was attempting to create an
image with an MBR with FAT16 partitions, FAT16 VBR, and FAT16 file
system. I.e., a normal FAT16 hard disk image, but created from Linux.

However, the Linux utilities wouldn't allow a FAT16 file system,
because the partition was less than 8MB. So, I used a FAT12 file
system, at first, and installed FAT12 boot code for the VBR, which I
changed to FAT16 VBR later. These images - MBR with FAT16 partitions
and FAT12 filesystems - don't seem to have corruption so far.

My attempts with a normal FAT16 hard disk image, created from Linux,
hang. I.e., MBR with FAT16 partitions, FAT16 VBR, FAT16 filesystem.
This may be a limitation with the Linux utility, i.e., writing 0xf8
instead of 0xf0 into the BPB, but I don't have time to check this for a
few days ...

> (1) If possible, use an image and a boot method which are consistent
> - i.e. all floppy or all HDD. (I would ignore the ZIP option.)

You really can't ignore the ZIP option. USB-HDD falls back to USB-ZIP,
if the image only has a single partition. Two are required for USB-HDD.

> (2) Use a boot sector which prints startup info such as the boot DL
> and any relevant CHS geometry info you might get from the BIOS. That
> ought to provide info to allow you to verify that what the BIOS
> believes is going on is what you expect. You may have done this
> already with tboot but I don't know whether you combined that with a
> consistent boot approach.

Again, according to the .pdf, which matches what I've seen this
machine doing so far:

USB-FDD - no partition, DL=0h - boots as 1st floppy drive, A: in DOS
USB-ZIP - one partition, DL=0h - boots as 1st floppy, A: in DOS
USB-HDD - calls USB-ZIP if only one partition is found - if two
partitions, DL=80h - should boot as 1st hard drive, C: in DOS


Rod Pemberton
--
People who predict things have a tendency to be wrong, but that's just
another prediction.

[john]

> In article <ov80c1$5ds$1...@gioia.aioe.org>, zf...@fysnet.net says...

> Thanks everyone for at least there is still some OS
> development related posts here in this group.
>
> Ben
>
>

Hi Ben

I tend to lurk mostly but I'm always interested in the posts here.
I expect most OS developers do the same now and again.
And there are a couple of forums that are more active.

The biggest problem I'm having developing an OS is getting the
to boot correctly. I'm not interested in it as a PC
so dont care too much about the niceties. But still - what a mess.

Your Fysos book helped me get the thing up and running but it's
irritating to have to spend so much time just running bodges to
see where the ram is and so on.

It would be nice to find an X86 PC boot up toolkit that does all that
startup gubbins and drops it into the mode you want. I've had to waste
so much time just messing about that the OS looks like a little
side project by comparison.

(OK maybe a bit of an exageration there...)
But perhaps thats a worthwhile project for someone. I'd
pay good money for such a toolkit if it did the job right.

[Benjamin David Lunt]

"john" <an...@example.com> wrote in message
news:MPG.348612124...@news.virginmedia.com...
>
> Hi Ben

Hi,

> I tend to lurk mostly but I'm always interested in the posts here.
> I expect most OS developers do the same now and again.
> And there are a couple of forums that are more active.
>
> The biggest problem I'm having developing an OS is getting the
> to boot correctly. I'm not interested in it as a PC
> so dont care too much about the niceties. But still - what a mess.
>
> Your Fysos book helped me get the thing up and running but it's
> irritating to have to spend so much time just running bodges to
> see where the ram is and so on.

Thanks for the good word.

> It would be nice to find an X86 PC boot up toolkit that does all that
> startup gubbins and drops it into the mode you want. I've had to waste
> so much time just messing about that the OS looks like a little
> side project by comparison.
>
> (OK maybe a bit of an exageration there...)
> But perhaps thats a worthwhile project for someone. I'd
> pay good money for such a toolkit if it did the job right.

Depending on what you have in mind, GRUB does this for you.
It will boot the machine, get the memory map, and put you in
32-bit protected or 64-bit long mode.

https://www.gnu.org/software/grub/

If this isn't what you are looking for, there are a few other
choices.

What exactly are you looking for?

Ben

[john]

> In article <ovhejh$9l8$1...@gioia.aioe.org>, zf...@fysnet.net says...

>

> Depending on what you have in mind, GRUB does this for you.
> It will boot the machine, get the memory map, and put you in
> 32-bit protected or 64-bit long mode.
>
> https://www.gnu.org/software/grub/
>
> If this isn't what you are looking for, there are a few other
> choices.
>
> What exactly are you looking for?
>
> Ben

It was more of an off the cuff wish list - but it would be nice.
No - not grub - grub does a specific job..

I was thinking more of a boot toolkit for OS developers to startup
a PC and configure memory models and disp;lay memory maps
and IO info etc that would let you define the boot system and startup
X86-preconfigured from a menu of options.

You can then get on to develop an os from the perspective of
a memory model and config (flat/real/protected/pseudo8086 etc)

Just an idea is all.

[Rod Pemberton]

On Mon, 27 Nov 2017 23:12:37 -0000
john <an...@example.com> wrote:

> I was thinking more of a boot toolkit for OS developers to startup
> a PC and configure memory models and disp;lay memory maps
> and IO info etc that would let you define the boot system and startup
> X86-preconfigured from a menu of options.
>

This sounds like something Mike Gonta might do.

> You can then get on to develop an os from the perspective of
> a memory model and config (flat/real/protected/pseudo8086 etc)
>
> Just an idea is all.
>

I use Grub, but have you seen Coreboot's FILO?

Coreboot's FILO
https://www.coreboot.org/FILO

The only issue is it's intended to be burned into the BIOS, not used as
a standalone boot loader. Otherwise, it appears to be a miniature OS,
derived from Linux, with support for loading a BIOS image from a
variety of storage devices, and many file systems. With a bit of
work ...


So, what would be set up or available for your hypothetical pre-OS
development environment? What would be configurable? What file
systems would be supported? What drives would be supported etc?

1) A20 enabled
2) E820 memory map
3) processor mode choice: RM16, v86, PM16, PM32, LM64
4) IVT/IDT
5) GDT for PM
6) CS and DS selectors for PM
7) CR0 bits for PM
8) EFLAGS bits
9) CLI/STI
10) NMI disable/enable
11) PIC set/change
12) storage devices
13) filesystems
14) debugger
15) assembler
16) IDE
...


How would you set the processor mode etc for your OS, once it's
completed, if this pre-OS development environment is doing it for you?
Configuration script? Or, does the pre-OS development environment also
need to generate code to do that?


There are a number of older OS toolkits and near OS libraries out there:

OSLib
http://oslib.sourceforge.net/

OSKit (FreeBSD based)
http://www.cs.utah.edu/flux/oskit/

SDL
https://www.libsdl.org/

[James Harris]

On 26/11/2017 00:26, Rod Pemberton wrote:
> On Fri, 24 Nov 2017 16:19:07 +0000
> James Harris <james.h...@gmail.com> wrote:
>
>> I have held off from commenting much on this thread as I have been
>> confused as to exactly what you are putting on the USB memory and,
>> frankly, it seems so complicated that I feel that if I asked you the
>> answer would be just as incomprehensible. ;-)
>
> For the first 90% of my posts, I was using a standard FAT12 floppy
> image. I have a large archive of these. They were created in MS-DOS
> on a real floppy and copied onto my hard drives. I was working with a
> few of these image. I was simply writing them, as-is, to USB sticks.
> So, the USB stick had a real FAT12 floppy image created with MS-DOS.
> The BIOS emulations for USB (USB-FDD, USB-HDD, USB-ZIP), either didn't
> work with the USB stick, or if the image booted, was showing file
> corruption of some mysterious sort.

Could the file corruption be down to a mismatch of sectors per track and
tracks per cylinder? You would surely need a floppy image to boot as
USB-FDD in order for it to use the CHS geometry in the BPB. If it booted
as USB-HDD then it would get its geometry values from somewhere else and
so wouldn't match the layout.

>
>> For example, you seem to say above that you've made a bootable USB
>> stick which is for Linux but which includes DOS executables.
>
> I made a DOS (MS-DOS v7.10) bootable USB stick from Linux, using Linux
> utilities, containing DOS executables. Some of those executables can
> load Linux from DOS, e.g., LINLD and LOADLIN.

OK

>
>> And then, it boots under USB-HDD but as a floppy - and is likely
>> seen as a USB-ZIP. What???
>
> Yes. From the .pdf which I posted a link to, USB-HDD falls back to
> USB-ZIP, if the booted USB device only has one partition. That's
> what I'm seeing this machine do, i.e., results of tboot. USB-HDD boots
> as a hard disk, DL=80h. But, USB-ZIP and USB-FDD boot as floppy drives,
> DL=00h. USB-ZIP is for ZIP floppy drives which require a partition.

I saw that PDF but it seems incomplete. Isn't it unlikely that a BIOS
will choose USB-ZIP just because a disk image has only one partition?
_Many_ legitimate hard drive images would have just one partition and
yet should not boot as USB-ZIP. According to

http://www.win.tue.nl/~aeb/linux/zip/zip-1.html

the single partition on a ZIP image has to be the fourth.

>
>> You seem to have all three options which are apparently supposed to
>> be mutually exclusive happening at the same time!
>
> ISTM, that you didn't follow what was required for the BIOS boot
> options in the .pdf.
>
>> And on top of all that, the USB stick has a FAT16 VBR which is
>> really FAT12. Aargh!!!
>
> This was for the other recent 10%, where I was attempting to create an
> image with an MBR with FAT16 partitions, FAT16 VBR, and FAT16 file
> system. I.e., a normal FAT16 hard disk image, but created from Linux.
>
> However, the Linux utilities wouldn't allow a FAT16 file system,
> because the partition was less than 8MB. So, I used a FAT12 file
> system, at first, and installed FAT12 boot code for the VBR, which I
> changed to FAT16 VBR later. These images - MBR with FAT16 partitions
> and FAT12 filesystems - don't seem to have corruption so far.

What specifically did you change to make the FAT-12 VBR a FAT-16 one?

>
> My attempts with a normal FAT16 hard disk image, created from Linux,
> hang. I.e., MBR with FAT16 partitions, FAT16 VBR, FAT16 filesystem.
> This may be a limitation with the Linux utility, i.e., writing 0xf8
> instead of 0xf0 into the BPB, but I don't have time to check this for a
> few days ...
>
>> (1) If possible, use an image and a boot method which are consistent
>> - i.e. all floppy or all HDD. (I would ignore the ZIP option.)
>
> You really can't ignore the ZIP option. USB-HDD falls back to USB-ZIP,
> if the image only has a single partition. Two are required for USB-HDD.

Well, I don't think it's even feasible for a BIOS to "fall back" a
USB-HDD image to USB-ZIP because as far as the BIOS knows, the boot code
might use CHS addressing - and the CHS values would not be compatible
between the two types of image.

>
>> (2) Use a boot sector which prints startup info such as the boot DL
>> and any relevant CHS geometry info you might get from the BIOS. That
>> ought to provide info to allow you to verify that what the BIOS
>> believes is going on is what you expect. You may have done this
>> already with tboot but I don't know whether you combined that with a
>> consistent boot approach.
>
> Again, according to the .pdf, which matches what I've seen this
> machine doing so far:
>
> USB-FDD - no partition, DL=0h - boots as 1st floppy drive, A: in DOS
> USB-ZIP - one partition, DL=0h - boots as 1st floppy, A: in DOS
> USB-HDD - calls USB-ZIP if only one partition is found - if two
> partitions, DL=80h - should boot as 1st hard drive, C: in DOS

Have you had a floppy image boot with DL=0? I thought you said at one
point that you could not get that to work? If you did get it to work,
were you able to check that the CHS values the BIOS used were those
stored in the BPB? If they were not matched then that could account for
the corruption.


--
James Harris

[James Harris]

On 04/11/2017 21:13, Rod Pemberton wrote:
> On Fri, 3 Nov 2017 06:00:59 -0700 (PDT)
> "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:
>
>> On Thursday, November 2, 2017 at 10:43:06 PM UTC-5, Rod Pemberton
>> wrote:
>>> On Thu, 2 Nov 2017 08:34:15 -0700 (PDT)
>>> "s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:
>
>>>> Thxs, so here is my test code to answer a couple of questions:
>>>> o the values returned from the function.
>>>> o if the boot signature is required by the Bios (yes). If it is
>>>> absent from the code at C=0,H=0,S=1 then than error is given (for
>>>> my machine). "No boot device available, press Enter key" so this
>>>> is hard drive behavior.
>>>> (Answer for Rod)
>>>
>
> I thanked you for the code, but I guess I should've thanked Mike too.
> Thanks Mike.
>
>
> If tboot.bin is booted from USB stick as USB-FDD, it's bypassed. GRUB
> for Linux loads. I.e., it doesn't boot.

I'd be inclined to make a mega-simple floppy image with just tboot on
it. And you might want to change tboot to show what BIOS thinks the
sectors per track and tracks per cylinder values are for the DL value
the BIOS supplies. (IIRC the tboot code always reported HDD geometry
values even if booted as a floppy.) In other words, don't have GRUB
anywhere in the mix.

>
> If tboot.bin is booted from USB stick as USB-HDD or as a Hard-disk, as
> USB-HDD0, it boots and displays:
>
> 0080h 0000h 0003h 003Fh 0010h
>
>
> You said that means:
>
> drive number 0080h
> drive type 0000h
>
> number of drives 0003h
> number of heads 003Fh
> sectors per track 0010h
>
> Do the heads and track seem sane? It is an older 64MB USB.
>
>
> It's interesting that it's device number is 80h, as it comes up as A:
> for DOS.

That sounds as though DOS recognises it as a boot floppy but that the
BIOS saw it as a hard disk. That would be a recipe for failure and could
explain the apparent data corruption.

> B: and C: are also present. B: is my actual 3.5" floppy
> (usually A:) and C: is a my 2GB CF memory card with IDE interface
> adapter. My SSD for Linux is not visible, except to DOS FDISK. My WD
> SATA hard drive with Win98/SE "died" (overheating) and has been removed.
> That's the 2nd WD that has died now. The other was an IDE back in the
> late '90's. I have no other HD failures since MFM era, only HDs by WD.
>
>
> I decided to try a larger 32GB USB stick with tboot.bin. It already
> had a DOS image on it. BIOS didn't boot tboot.bin at all, but booted
> DOS!!!! It did so without a boot sector for it too. WTF. So, I
> thought I wrote tboot.bin to /dev/sdc1 by mistake. I tried it again
> to /dev/sdc. I also reread the first 512 to check. Same results.
> Obviously, the BIOS is checking for certain code to boot instead of
> just booting from the boot sector. So, I decided to wipe DOS from the
> 32GB USB stick.
>
>
> After wiping DOS, it boots tboot.bin, and it gives something similar to
> the results above.
>
> (newer 32GB)
>
> If tboot.bin is booted from USB stick as USB-FDD, it's bypassed. GRUB
> for Linux loads. I.e., it doesn't boot. (Same as before.)
>
> If tboot.bin is boot from USB stick as USB-HDD or under Hard-disk, as
> USB-HDD0, it boots and displays:
>
> 0080h 0000h 0003h 003Fh 00FFh
>
> You said that means:
>
> drive number 0080h
> drive type 0000h
>
> number of drives 0003h
> number of heads 003Fh
> sectors per track 00FFh
>
> So, the sectors per track changed from 0010h 64MB to 00FFh for 32GB.
>
> On the 32GB stick, I've notice that the heads and track are switched as
> compared to yours.
>
>
> So far, USB-FDD doesn't like anything. USB-HDD reports 80h according
> to tboot.bin, but comes up as A: under emulation, with my other DOS
> drives correct as B: (floppy) and C: (IDE).

If you started with a very simple floppy image you might be able to keep
tweaking and rebooting to find out what the BIOS uses to determine
whether to see it as floppy or as hard disk.

That may sound fiddly but I had to so something similar once when trying
to work out how my BIOS determined whether a boot sector was valid and
bootable or was garbage. IIRC if the first byte held 0 to 5 it assumed
garbage; the value had to be 6 or above. That might sound weird,
perhaps, but unless you are going to disassemble the BIOS, such fiddling
may be the only way to find out what the requirements are.

--
James Harris

[Rod Pemberton]

On Sun, 3 Dec 2017 15:19:27 +0000

James Harris <james.h...@gmail.com> wrote:

> On 26/11/2017 00:26, Rod Pemberton wrote:
> > On Fri, 24 Nov 2017 16:19:07 +0000
> > James Harris <james.h...@gmail.com> wrote:
> >

> >> And then, it boots under USB-HDD but as a floppy - and is likely
> >> seen as a USB-ZIP. What???
> >
> > Yes. From the .pdf which I posted a link to, USB-HDD falls back to
> > USB-ZIP, if the booted USB device only has one partition. That's
> > what I'm seeing this machine do, i.e., results of tboot. USB-HDD
> > boots as a hard disk, DL=80h. But, USB-ZIP and USB-FDD boot as
> > floppy drives, DL=00h. USB-ZIP is for ZIP floppy drives which
> > require a partition.
>
> I saw that PDF but it seems incomplete. Isn't it unlikely that a BIOS
> will choose USB-ZIP just because a disk image has only one partition?

I'm suspecting that my BIOS is actually checking for FAT12 ...

> _Many_ legitimate hard drive images would have just one partition and
> yet should not boot as USB-ZIP. According to
>
> http://www.win.tue.nl/~aeb/linux/zip/zip-1.html
>
> the single partition on a ZIP image has to be the fourth.

I've not looked for the ZIP standard yet. Thanks. I'll take a look
sometime, hopefully soon.

> >> You seem to have all three options which are apparently supposed to
> >> be mutually exclusive happening at the same time!
> >
> > ISTM, that you didn't follow what was required for the BIOS boot
> > options in the .pdf.
> >
> >> And on top of all that, the USB stick has a FAT16 VBR which is
> >> really FAT12. Aargh!!!
> >
> > This was for the other recent 10%, where I was attempting to create
> > an image with an MBR with FAT16 partitions, FAT16 VBR, and FAT16
> > file system. I.e., a normal FAT16 hard disk image, but created
> > from Linux.
> >
> > However, the Linux utilities wouldn't allow a FAT16 file system,
> > because the partition was less than 8MB. So, I used a FAT12 file
> > system, at first, and installed FAT12 boot code for the VBR, which I
> > changed to FAT16 VBR later. These images - MBR with FAT16
> > partitions and FAT12 filesystems - don't seem to have corruption so
> > far.
>
> What specifically did you change to make the FAT-12 VBR a FAT-16 one?
>

Linux has a utility called 'ms-sys' which can create a variety of MBR
and PBRs (i.e., VBR). I changed the option I used. I.e., I used option
-6 instead of option -1.

Man page and screenshot of
options:

http://ms-sys.sourceforge.net/

About the first half of the options in the screenshot are for PBRs.
About the second half are for MBRs.

> >> (1) If possible, use an image and a boot method which are
> >> consistent
> >> - i.e. all floppy or all HDD. (I would ignore the ZIP option.)
> >
> > You really can't ignore the ZIP option. USB-HDD falls back to
> > USB-ZIP, if the image only has a single partition. Two are
> > required for USB-HDD.
>
> Well, I don't think it's even feasible for a BIOS to "fall back" a
> USB-HDD image to USB-ZIP because as far as the BIOS knows, the boot
> code might use CHS addressing - and the CHS values would not be
> compatible between the two types of image.

...

> >
> >> (2) Use a boot sector which prints startup info such as the boot DL
> >> and any relevant CHS geometry info you might get from the BIOS.
> >> That ought to provide info to allow you to verify that what the
> >> BIOS believes is going on is what you expect. You may have done
> >> this already with tboot but I don't know whether you combined that
> >> with a consistent boot approach.
> >
> > Again, according to the .pdf, which matches what I've seen this
> > machine doing so far:
> >
> > USB-FDD - no partition, DL=0h - boots as 1st floppy drive, A: in DOS
> > USB-ZIP - one partition, DL=0h - boots as 1st floppy, A: in DOS
> > USB-HDD - calls USB-ZIP if only one partition is found - if two
> > partitions, DL=80h - should boot as 1st hard drive, C: in DOS
>
> Have you had a floppy image boot with DL=0?

DL=0 for USB-FDD? No. Nothing boots for USB-FDD. The description
above is what's supposed to happen according to the .pdf. The .pdf
says it must be a real floppy device, i.e., not a memory stick.

DL=0 for USB-ZIP? Yes, everything with FAT12 filesystem boots for
USB-ZIP. The botched hard disk image - with a FAT12 filesystem -
didn't show any noticeable corruption. The FAT12 floppy disk images
show corruption.

DL=80h for USB-HDD? Hard disk images hang (pure FAT16). (This may be
wrong BPB values due to Linux utilities.) FAT12 floppy images come up
as A: showing corruption, i.e., implying DL=0h or redirect from USB-HDD
to USB-ZIP as .pdf claims, (or perhaps BIOS possibly detecting FAT12).

> I thought you said at one
> point that you could not get that to work?
> If you did get it to work, were you able to check that the CHS values
> the BIOS used were those stored in the BPB?

Unfortunately, I've not checked the hard disk image BPB I created on
Linux, yet. Just doing other things ... As stated before, I saw an
0xf8 (floppy) in the hex dump, which I think should've been 0xf0 (hard
disk), but I'm not sure of the BPB locations from the dump.


Rod Pemberton
--
North Korea is the proof that Soviet Russia and Communist China were
wrong.

[Rod Pemberton]

On Sun, 3 Dec 2017 15:55:06 +0000
James Harris <james.h...@gmail.com> wrote:

> That may sound fiddly but I had to so something similar once when
> trying to work out how my BIOS determined whether a boot sector was
> valid and bootable or was garbage. IIRC if the first byte held 0 to 5
> it assumed garbage; the value had to be 6 or above.

https://groups.google.com/d/msg/comp.lang.asm.x86/65dzB0KKYhQ/bS_p8vFmhNAJ
https://groups.google.com/d/msg/comp.lang.asm.x86/pKDBv02P4cw/wiPHD8wQlh4J

[James Harris]

On 04/12/2017 01:37, Rod Pemberton wrote:
> On Sun, 3 Dec 2017 15:19:27 +0000
> James Harris <james.h...@gmail.com> wrote:
>
>> On 26/11/2017 00:26, Rod Pemberton wrote:
>>> On Fri, 24 Nov 2017 16:19:07 +0000
>>> James Harris <james.h...@gmail.com> wrote:
>>>
>
>>>> And then, it boots under USB-HDD but as a floppy - and is likely
>>>> seen as a USB-ZIP. What???
>>>
>>> Yes. From the .pdf which I posted a link to, USB-HDD falls back to
>>> USB-ZIP, if the booted USB device only has one partition. That's
>>> what I'm seeing this machine do, i.e., results of tboot. USB-HDD
>>> boots as a hard disk, DL=80h. But, USB-ZIP and USB-FDD boot as
>>> floppy drives, DL=00h. USB-ZIP is for ZIP floppy drives which
>>> require a partition.
>>
>> I saw that PDF but it seems incomplete. Isn't it unlikely that a BIOS
>> will choose USB-ZIP just because a disk image has only one partition?
>
> I'm suspecting that my BIOS is actually checking for FAT12 ...

I read that if a BIOS chooses USB-ZIP then it treats the first sector of
the partition as LBA 0, and prevents all BIOS-based access to prior
sectors - which may not be good for an OS developer. But a hard disk
image would provide the same space. Combining that with your comments
that USB-FDD won't work with USB memory it sounds as though a hard disk
image with a boot partition would be your only choice.

And there's this from a site I think you mentioned:

There is no standard for how a BIOS should 'decide' on how to map a USB
device. Different BIOSes use different decision trees. Some do not even
bother and just assume all USB storage devices are of one type (e.g.
HDD). Some older BIOSes assume all USB device are ZIP devices if they
are over 1.44MB in size - otherwise FDD. Some only do the ZIP
translation/adjustment if you use Int13h Standard CHS calls but do not
translate sector addresses if you call the Extended Int13h interrupt
routines!

http://www.rmprepusb.com/tutorials/diagnose-bios

That's an interesting utility. However, I am not sure it will change the
clustering used in the file system. And you will probably remember that
the FAT type is determined solely by the count of clusters:

"It is really quite simple how this works. The FAT type — one of FAT12,
FAT16, or FAT32 — is determined by the count of clusters on the volume
and nothing else."

That's from https://staff.washington.edu/dittrich/misc/fatgen103.pdf

In other words, just changing the VBR won't change the layout of the
partition; yet it might introduce corruption.

That makes sense. Given that all USB memory sticks will be much larger
than any floppy the BIOS writer may not have seen any need to include
such support.

>
> DL=0 for USB-ZIP? Yes, everything with FAT12 filesystem boots for
> USB-ZIP. The botched hard disk image - with a FAT12 filesystem -
> didn't show any noticeable corruption. The FAT12 floppy disk images
> show corruption.

I read in the RMPrep doc that USB-ZIP expects 64 heads per cylinder and
32 sectors per head. Perhaps that's the cause of the corruption - i.e.
MS-DOS is using CHS addressing and the values in the BPB (probably 2/18)
but the BIOS is using the fixed values of 64/32 for USB-ZIP.

>
> DL=80h for USB-HDD? Hard disk images hang (pure FAT16). (This may be
> wrong BPB values due to Linux utilities.) FAT12 floppy images come up
> as A: showing corruption, i.e., implying DL=0h or redirect from USB-HDD
> to USB-ZIP as .pdf claims, (or perhaps BIOS possibly detecting FAT12).
>
>> I thought you said at one
>> point that you could not get that to work?
>> If you did get it to work, were you able to check that the CHS values
>> the BIOS used were those stored in the BPB?
>
> Unfortunately, I've not checked the hard disk image BPB I created on
> Linux, yet. Just doing other things ... As stated before, I saw an
> 0xf8 (floppy) in the hex dump, which I think should've been 0xf0 (hard
> disk), but I'm not sure of the BPB locations from the dump.

It's a big topic and I've only read up on a bit of it but if you are
trying to set up a flash memory device the most compatible settings look
as though they are going to be doable under Unix or Windows or even
MS-DOS using the following setup.

* A hard-disk layout (with an MBR)
* A geometry of 255 heads per cylinder and 63 sectors per track
* A boot partition using FAT16
* A main partition
* MS-DOS (or whatever) in the boot partition

Is that how you read things?


--
James Harris

[James Harris]

On 04/12/2017 01:38, Rod Pemberton wrote:
> On Sun, 3 Dec 2017 15:55:06 +0000
> James Harris <james.h...@gmail.com> wrote:
>
>> That may sound fiddly but I had to so something similar once when
>> trying to work out how my BIOS determined whether a boot sector was
>> valid and bootable or was garbage. IIRC if the first byte held 0 to 5
>> it assumed garbage; the value had to be 6 or above.
>
> https://groups.google.com/d/msg/comp.lang.asm.x86/65dzB0KKYhQ/bS_p8vFmhNAJ
> https://groups.google.com/d/msg/comp.lang.asm.x86/pKDBv02P4cw/wiPHD8wQlh4J

Turns out that not all BIOSes use "greater than 6".

https://groups.google.com/d/msg/alt.os.development/XYa89ASBiDg/W0NB9wxSZPkJ


--
James Harris

[Rod Pemberton]

On Tue, 5 Dec 2017 06:44:11 +0000

James Harris <james.h...@gmail.com> wrote:

> On 04/12/2017 01:38, Rod Pemberton wrote:
> > On Sun, 3 Dec 2017 15:55:06 +0000
> > James Harris <james.h...@gmail.com> wrote:

> >> That may sound fiddly but I had to so something similar once when
> >> trying to work out how my BIOS determined whether a boot sector was
> >> valid and bootable or was garbage. IIRC if the first byte held 0
> >> to 5 it assumed garbage; the value had to be 6 or above.
> >
> > https://groups.google.com/d/msg/comp.lang.asm.x86/65dzB0KKYhQ/bS_p8vFmhNAJ
> > https://groups.google.com/d/msg/comp.lang.asm.x86/pKDBv02P4cw/wiPHD8wQlh4J
>
> Turns out that not all BIOSes use "greater than 6".
>
> https://groups.google.com/d/msg/alt.os.development/XYa89ASBiDg/W0NB9wxSZPkJ
>
>

I had a machine (died) that wouldn't boot floppies without 0xAA55, but
I didn't recall that anyone else had reported one too.

So, if the first sector is "blank," i.e., written entirely with the
same value, the floppy won't boot no matter the blanking value, because
0xAA55 is always missing.

So, the 0xAA55 check makes it so that a blank disk (of any value) won't
boot. I.e., the 0xAA55 check replaces the check for 6 or below as the
check for a blank disk.

The 0xAA55 check will also block many valid floppy boot disks from
booting, since the 0xAA55 signature technically isn't required for a
proper floppy boot image, e.g., CP/M, early DOS.

That's nifty, and probably works better, but technically, is not valid,
per the original manuals.

[Rod Pemberton]

On Tue, 5 Dec 2017 06:30:54 +0000

James Harris <james.h...@gmail.com> wrote:

> On 04/12/2017 01:37, Rod Pemberton wrote:
> > On Sun, 3 Dec 2017 15:19:27 +0000
> > James Harris <james.h...@gmail.com> wrote:

>>> [...]
>> [...]

> I read that if a BIOS chooses USB-ZIP then it treats the first sector
> of the partition as LBA 0, and prevents all BIOS-based access to

> prior sectors [...]

If that was on a.o.d., it was me in this thread or the other one. ...

> And you will probably remember that the FAT type is determined solely
> by the count of clusters:
>
> "It is really quite simple how this works. The FAT type — one of
> FAT12, FAT16, or FAT32 — is determined by the count of clusters on
> the volume and nothing else."
>
> That's from https://staff.washington.edu/dittrich/misc/fatgen103.pdf

No, I can't recall that, since I never read it. :-)

I only use DOS utilities, and now Linux, to create FAT file systems.

I haven't done anything OS related for the FAT file system. I never
got to the file system for my OS. I never needed to write any
utilities for FAT either. I do have some programs that reads the BPB,
partitions, etc and device info from DOS.

> In other words, just changing the VBR won't change the layout of the
> partition; yet it might introduce corruption.

I wasn't seeing any corruption with the botched hard disk image that
had partitions (partitions, FAT16 MBR, FAT12 file system, either floppy
boot code for PBR/VBR or valid FAT16 PBR/VBR).

I was seeing the corruption with real FAT12 floppy disk images (floppy
boot code for MBR, FAT12 file system).

A FAT16 hard disk image hangs so far (partitions, FAT16 MBR, FAT16
VBR/PBR, FAT16 file system). So, I don't know if it has corruption.

> >> Have you had a floppy image boot with DL=0?
> >
> > DL=0 for USB-FDD? No. Nothing boots for USB-FDD. The description
> > above is what's supposed to happen according to the .pdf. The .pdf
> > says it must be a real floppy device, i.e., not a memory stick.
>
> That makes sense. Given that all USB memory sticks will be much
> larger than any floppy the BIOS writer may not have seen any need to
> include such support.

The memory stick may be larger, but the image written might not be.

> > DL=0 for USB-ZIP? Yes, everything with FAT12 filesystem boots for
> > USB-ZIP. The botched hard disk image - with a FAT12 filesystem -
> > didn't show any noticeable corruption. The FAT12 floppy disk images
> > show corruption.
>
> I read in the RMPrep doc that USB-ZIP expects 64 heads per cylinder
> and 32 sectors per head. Perhaps that's the cause of the corruption -
> i.e. MS-DOS is using CHS addressing and the values in the BPB
> (probably 2/18) but the BIOS is using the fixed values of 64/32 for
> USB-ZIP.

...

> It's a big topic and I've only read up on a bit of it but if you are
> trying to set up a flash memory device the most compatible settings
> look as though they are going to be doable under Unix or Windows or
> even MS-DOS using the following setup.

Except for MS-DOS ... USB emulation for DOS is a "can of worms," which
was another reason why I was trying to get the USB stick to be emulated
by BIOS.

I know the DOS drivers I have for USB worked with my previous
motherboard, but I'm not sure about this one. There are no universal
USB drivers for DOS and no new USB drivers for DOS being written.
There are a few that work on multiple machines. However, USB drivers
for DOS usually cause USB keyboards and USB mice to be lost.

I might play around with that next though. If I one of the various DOS
drivers for USB work with either of my USB sticks and this motherboard,
I might not need the BIOS emulation to map the USB stick to a hard disk,
i.e., C: or D: etc in DOS, instead of to a floppy, i.e., A: or B:.
If I can get the USB stick to recognize as a hard disk in DOS, I might
be able to create a hard disk image on the USB stick from DOS using DOS
utilities. Then, I can compare images and find out what is different.

> * A hard-disk layout (with an MBR)
> * A geometry of 255 heads per cylinder and 63 sectors per track
> * A boot partition using FAT16
> * A main partition
> * MS-DOS (or whatever) in the boot partition
>
> Is that how you read things?
>

Well, two partitions if the .pdf is correct for USB-HDD.

It says either 255/63 or 64/32, claiming 64/32 boots more widely. I
summarized that in the other thread: "Info on the BIOS requirements for
USB-HDD, USB-FDD, and USB-ZIP booting."

[James Harris]

To be clear, the test in the linked post was for hard disks and under
one specific BIOS. It was not for floppies or for any other BIOS.


--
James Harris

[Rod Pemberton]

On Tue, 5 Dec 2017 08:37:28 +0000

Well, that makes far more sense.

The 0xAA55 is required for non-floppy bootable devices, e.g., hard
disk, network cards, etc.


The check for a zero byte seems odd though:

A) Why bother? It either has an 0xAA55 signature indicating it has
bootable code, or doesn't have the 0xAA55 signature which would
indicate it's blank or ready for re-use.

B) It's just as likely to be blanked with value 0xFF as 0x00.


And, now my recollection can go back to me being the only person
on a.o.d. reporting 0xAA55 being required to boot a floppy.

[s_dub...@yahoo.com]

We had a discussion of it back here:

https://groups.google.com/forum/#!searchin/alt.os.development/ST-01/alt.os.development/SdqQTiLZFLw/IEGiLeabjtEJ

..or search ST-01, but to recap, my situation was that the Seagate ST-01
scsi controller firmware revectors int 13h to int 40h at the time the option
rom firmware is installed in the POST, and that this caused CP/M-86, a
floppy OS, not to boot because the AA55h signature was absent. That is,
the ST-01 firmware checks for the signature on floppy as well as the HDD
bootsector.

Steve