a20 line

[Paul Edwards]

I have a large program (GCC 3.2.3) that is
running fine on Bochs, but under another
emulator it is failing. I have tracked the
failure down to address wrapping at the
3 MiB mark, presumably due to the a20 line
not being enabled.

But I am enabling it, with this code:

a20e proc
a20e_ii:
in al, 064h
test al, 2
jnz a20e_ii
mov al, 0dfh
out 060h, al
ret
a20e endp

Is there something wrong with the code?

Thanks. Paul.

[Paul Edwards]

On Saturday, 21 July 2018 00:03:06 UTC+10, Paul Edwards wrote:

> under another emulator it is failing.

The failing emulator (ie where the
A20 line is not being enabled) is:

Oracle VM VirtualBox version 5.2.8 r121009.

BFN. Paul.

[Scott Lurndal]

enableA20:
call testA20 # Check if a20 is enabled
jnz 1f # Yes, done.

movw 0x2401,%ax # Enable A20 gate
int $0x15 # Call the BIOS

call testA20 # Check again,
jnz 1f # yes, done.

call flush_keyboard # Flush keyboard controller

movb $0xD1, %al # Command Write
outb %al, $0x64 # send to register
call flush_keyboard # Flush keyboard controller
movb $0xDF, %al # A20 On
outb %al, $0x60 # send to register
call flush_keyboard # Flush keyboard controller
#
# Some chips/motherboards also require enabling A20 via port 0x92.
# This needs to be done before checking if A20 is enabled.
#
inb $0x92, %al # Get current state
orb $0x02, %al # Set Fast A20 bit
andb $0xfe, %al # Clear reset bit, just in case
outb %al, $0x92 # Enable fast A20

call testA20 # Check if a20 is enabled
jnz 1f

lea noa20msg, %si # Load message
call print # and print it.

hlt
1:
ret

A20ADDR=0x200

testA20:
pushw %cx # Save caller's register
pushw %ax # Save caller's register
xorw %cx, %cx # Set %cx = 0
movw %cx, %fs # Load %FS = 0000
decw %cx # Set %cx = FFFF
movw %cx, %gs # Load %GS = FFFF
movw $0x4000, %cx # Loop 16K times as A20 enable can take a while
movw %fs:(A20ADDR), %ax # Fetch word at address 0x200
pushw %ax # Save it for later restore
1:
incw %ax # Bump it
movw %ax, %fs:(A20ADDR) # Store it back at 0x200
call iodelay # Wait one.
cmpw %gs:(A20ADDR+0x10), %ax # See if it appears at 0x100200
loope 1b # Issue the compare 16K times
# ZF = 1 if the same value appears at both
# ZF = 0 if different values at both

popw %fs:(A20ADDR) # Restore original value
popw %ax # Restore caller's register
popw %cx # Restore caller's register
ret

[Scott Lurndal]

flush_keyboard:
pushl %ecx # Save caller's reg
movl $100000, %ecx # Set maximum loop count for broken hdw
1:
decl %ecx # Count an interation
jz 3f # Exhausted interation count, bail.

call iodelay
inb $0x64, %al # Read 8042 status port
testb $1, %al # Is there data at port 60 for system?
jz 2f # No.

call iodelay
inb $0x60, %al # Read and discard byte
jmp 1b

2:
testb $2, %al # System data still pending?
jnz 1b # yes, loop

3:
popl %ecx
ret

[Rod Pemberton]

On Fri, 20 Jul 2018 07:03:04 -0700 (PDT)
Paul Edwards <muta...@gmail.com> wrote:

> I have a large program (GCC 3.2.3) that is
> running fine on Bochs, but under another
> emulator it is failing. I have tracked the
> failure down to address wrapping at the
> 3 MiB mark, presumably due to the a20 line
> not being enabled.

Presumably? From that, I'd assume it only emulates a PC with only 3MiB
or 4MiB of memory, e.g., not 4GB ... What memory size is the emulator
supposed to support? Do most limit to 16MB?

What do you mean by wrapping? If your segments' base address is 1MiB,
for zero virtual, then it will wrap to physical address 0 at 3MiB
virtual, if the emulated machine only has 4MiB of memory. Yes?

> But I am enabling it, with this code:
>

It's *mandatory* that A20 only be enabled or disabled in RM. According
to numerous Intel and AMD manuals, which I've cited here in the past
and can provide if needed, you can't enable or disable in PM or SMM.
So, I'm sure you're probably not doing that. I'm sure you're
only enabling A20 in RM. But, let's just start by making sure you're
not messing with A20 in PM, SMM, V86, nor unreal mode. Are you?
Some people seem to insist on doing so in unreal mode ...

> a20e proc
> a20e_ii:
> in al, 064h
> test al, 2
> jnz a20e_ii
> mov al, 0dfh
> out 060h, al
> ret
> a20e endp
>
> Is there something wrong with the code?
>

The part that's shown appears to be correct. However, the initial part
that I use seems to be missing:

mov al, 0d1h
out 64h, al

I also have the code wrapped in a cli/sti pair (not including the ret).


Rod Pemberton
--
As long as the UK continues to work with the EU, Brexit won't happen.
The first pawn sacrifice: Gibraltar. Set Gibraltar free.

[Paul Edwards]

On Saturday, 21 July 2018 00:46:47 UTC+10, Scott Lurndal wrote:

> movw 0x2401,%ax # Enable A20 gate
> int $0x15 # Call the BIOS

Thanks Scott. This bit of code did the trick!

BFN. Paul.

[Paul Edwards]

On Saturday, 21 July 2018 17:12:05 UTC+10, Rod Pemberton wrote:

> > emulator it is failing. I have tracked the
> > failure down to address wrapping at the
> > 3 MiB mark, presumably due to the a20 line
> > not being enabled.
>
> Presumably? From that, I'd assume it only emulates a PC with only 3MiB
> or 4MiB of memory, e.g., not 4GB ... What memory size is the emulator
> supposed to support? Do most limit to 16MB?

Currently the call that is being used to
determine how much ATL (above the 1 MiB
line) memory is available only returns
the first 16 MiB.

> What do you mean by wrapping?

Write to location 3 MiB and the location
2 MiB gets updated.

> If your segments' base address is 1MiB,
> for zero virtual, then it will wrap to physical address 0 at 3MiB
> virtual, if the emulated machine only has 4MiB of memory. Yes?

My base address is 0 for everything.

> > But I am enabling it, with this code:
>
> It's *mandatory* that A20 only be enabled or disabled in RM.

I'm doing it in RM, it is part of the
load (pload.com) process.

> The part that's shown appears to be correct. However, the initial part
> that I use seems to be missing:
>
> mov al, 0d1h
> out 64h, al

Ok, thanks.

> I also have the code wrapped in a cli/sti pair (not including the ret).

Ok.

BFN. Paul.

[Rod Pemberton]

The BIOS A20 enable function is not reliable for real hardware.

James Harris and I tested the A20 methods on various machines some
years back. The old a.o.d. wikispaces FAQ contains the data compiled
by me and James Harris. Our results are archived here:

https://web.archive.org/web/20111028034231/http://aodfaq.wikispaces.com:80/machine+characteristics

In summary, the BIOS interrupt method only worked for two out of eight
machines tested. The keyboard controller method (KBC) worked on eight
of eight machines. The fast P2/2 method (SCPA) worked on seven of eight
machines.

What this means is, that while the A20 BIOS method worked for your
emulation, you're going to need to use one or both of the other methods
(KBC or PS/2) once your OS is running on real hardware.

Also note that if you enable A20 by one method (KBC or PS/2), you must
disable A20 by the same method, as some motherboards implement each
independently of the other. If both are enabled, you must disable both.

Also note that OCHI and UHCI motherboards require a special,
non-standard, A20 gate pass-through sequence. This is recorded in the
appropriate specifications.

[Rod Pemberton]

On Sat, 21 Jul 2018 00:38:48 -0700 (PDT)
Paul Edwards <muta...@gmail.com> wrote:

> On Saturday, 21 July 2018 17:12:05 UTC+10, Rod Pemberton wrote:

> > What do you mean by wrapping?
>
> Write to location 3 MiB and the location
> 2 MiB gets updated.

An A20 wrap occurs at 1MB. An out of memory wrap or top of memory
wrap occurs somewhere above that, if the machine has more than 1MB.
I.e., it appears to me from your descriptions that this emulator only
supports a small amount of memory above 1MB, e.g., 4MB or 2MB. Does it
appear that way to you? ...

If it's not that, maybe your pointer code isn't working correctly?
Or, maybe your memory copy routine is faulty?

[Paul Edwards]

On Sunday, 22 July 2018 04:03:25 UTC+10, Rod Pemberton wrote:

> > > What do you mean by wrapping?
> >
> > Write to location 3 MiB and the location
> > 2 MiB gets updated.
>
> An A20 wrap occurs at 1MB. An out of memory wrap or top of memory
> wrap occurs somewhere above that, if the machine has more than 1MB.
> I.e., it appears to me from your descriptions that this emulator only
> supports a small amount of memory above 1MB, e.g., 4MB or 2MB. Does it
> appear that way to you? ...
>
> If it's not that, maybe your pointer code isn't working correctly?
> Or, maybe your memory copy routine is faulty?

I'm not sure I understand your question,
but in my OS I leave the 1 MiB to 2 MiB
region untouched, to allow for the
possibility of the A20 line not being
enabled. So I only start allocating
ATL memory at 2 MiB. This means that if
my command processor and application are
fairly small, both fitting in to 1 MiB,
then I will not go above 3 MiB which is
where the A20 address wrapping occurs
(again, but this time unavoidable).

Thanks for your other info about the
A20 line, I'll try switching technique.

BFN. Paul.

[Rod Pemberton]

On Sun, 22 Jul 2018 22:48:03 -0700 (PDT)
Paul Edwards <muta...@gmail.com> wrote:

> On Sunday, 22 July 2018 04:03:25 UTC+10, Rod Pemberton wrote:
>

> I'm not sure I understand your question,
> but in my OS I leave the 1 MiB to 2 MiB
> region untouched, to allow for the
> possibility of the A20 line not being
> enabled. So I only start allocating
> ATL memory at 2 MiB.

Ah, Ok.

After rereading your posts a few times, I just figured out why we're
talking at cross purposes ... (at bottom).

> This means that if
> my command processor and application are
> fairly small, both fitting in to 1 MiB,
> then I will not go above 3 MiB which is
> where the A20 address wrapping occurs
> (again, but this time unavoidable).
>

***IF*** entering PM with A20 disabled is valid, that should be fine, I
would think.

> Thanks for your other info about the
> A20 line, I'll try switching technique.
>

You're viewing the A20 line as an actual processor address line, like
on the early 8086 to 80486 processors. So, you're viewing memory - with
A20 DISABLED - as having "gaps" in memory above 1MB due to wrap every
other megabyte. I.e., from 1MB to 2MB wrapping to zero, but 2MB to 3MB
is present, 3MB to 4MB wrap to zero, 4MB to 5MB is present, etc. Yes?

I thought you were saying you had a wrap issue at 3 MiB with A20
ENABLED, where memory should be flat, no wraps or gaps ... So, this is
not a wrapping issue with A20 enabled, e.g., top of memory or coding
error, as I was thinking. I.e., I was thinking the emulator was
limited to 4 MiB or some such, and you were reaching the top of
physical memory at 3 MiB virtual, etc.

A20 probably still works that the way it historically did, i.e.,
linear memory gaps due to wrap when A20 is disabled. I've never checked
this. Nowadays, I don't think of A20 working as it would electrically
on a schematic. I usually think of A20 disabled as blocking all access
to memory above 1MB until A20 is enabled.

My question now is how are you accessing memory above 1MB physical? RM
segment:offset addressing only goes to 1MB+64KB+16. I.e., to load your
app to 2 MiB PM must be enabled (or a BIOS call using PM must be used)
or unreal mode (pop into PM and change hidden segments limits for RM).
Are you entering PM without A20 being enabled? Just a reminder, you
can't enable or disable A20 once in PM:

"When A20M# is sampled asserted in Protected mode, it causes
unpredictable processor operation. A20M# is only defined in Real Mode."

I'm not sure what effect, if any, that entering PM with A20
disabled has, or if that's also undefined or unpredictable.

One processor (Intel Atom) has an errata that says it has problems with
2MB/4MB pages when A20 is disabled (and some other conditions). Uh, ...
yeah. I would assume that A20 is enabled before entering PM prior to
enabling paging, usually. So, I'm not sure what is going on there.

The notes on the archived page show some machines have A20 enabled by
default after boot up, "Boot-Time A20". There is a 2001 Microsoft
specification that requires that A20 is always on, i.e., "Legacy-Free
Hardware and BIOS Requirements." And, I seem to recall that there is at
least one processor which automatically enables A20 upon entering PM,
but I can't seem to find it ...

Sorry about my confusion (or perhaps yours).

[Paul Edwards]

On Monday, 23 July 2018 18:37:22 UTC+10, Rod Pemberton wrote:

> on the early 8086 to 80486 processors. So, you're viewing memory - with
> A20 DISABLED - as having "gaps" in memory above 1MB due to wrap every
> other megabyte. I.e., from 1MB to 2MB wrapping to zero, but 2MB to 3MB
> is present, 3MB to 4MB wrap to zero, 4MB to 5MB is present, etc. Yes?

Yes, except 3 MiB to 4 MiB wraps to 2 MiB, not zero.

> My question now is how are you accessing memory above 1MB physical? RM
> segment:offset addressing only goes to 1MB+64KB+16. I.e., to load your
> app to 2 MiB PM must be enabled (or a BIOS call using PM must be used)
> or unreal mode (pop into PM and change hidden segments limits for RM).
> Are you entering PM without A20 being enabled? Just a reminder, you
> can't enable or disable A20 once in PM:

Correct. On *some* systems, I was entering
PM without A20 being enabled. So because of
the way I coded it, it worked to some
limited extent on those systems.

BFN. Paul.

[Paul Edwards]

On Saturday, 21 July 2018 17:12:05 UTC+10, Rod Pemberton wrote:

> mov al, 0d1h
> out 64h, al

Thanks Rod. I now have confirmation from
Alica that this solved the problem, so
I am going ahead with this solution instead.

BFN. Paul.

[Scott Lurndal]

Hi Paul,

If you look back at the code I posted, it tries all three mechanisms
(and tests the functioning of A20 after each try). This should work
on all platforms.

[Paul Edwards]

On Saturday, 21 July 2018 00:46:47 UTC+10, Scott Lurndal wrote:

> testA20:
> pushw %cx # Save caller's register
> pushw %ax # Save caller's register

Is anyone familiar with UNetBootin?

Alica has used UNetBootin to create a
bootable USB, but the A20 line is not
being enabled, despite implementing a
modified version of the above code
to work with tcc.

From reading the description of UNetBootin
it seems that it puts a floppy disk image
(which is what PDOS is) into memory to
execute. Therefor it must be doing some
sort of emulation. And it would seem that
it isn't emulating the A20 line properly,
as none of the above methods cause the
A20 to be enabled.

I am surprised that booting from USB is
doing this at all. I expected the PC to
directly boot the FAT boot sector then
IO.SYS, not having any other software
interfering. But it seems that UNetBootin
does interfere in the boot process.

Any idea what is happening?

Thanks. Paul.

[Alexei A. Frounze]

On Saturday, September 29, 2018 at 3:08:25 AM UTC-7, Paul Edwards wrote:
...

> Is anyone familiar with UNetBootin?

Nopes.

> Alica has used UNetBootin to create a
> bootable USB, but the A20 line is not
> being enabled, despite implementing a
> modified version of the above code
> to work with tcc.

...

> Any idea what is happening?

If they claim they can boot Linux, A20 must
be enablable by one of the many methods.
Have you tried them all?
BIOS function 0x2401 on int 0x15?
Keyboard method (ports 0x60, 0x64)?
PS/2 method (port 0x92)?
Perhaps, yet others?

Alex

[Paul Edwards]

On Saturday, 29 September 2018 21:16:02 UTC+10, Alexei A. Frounze wrote:

> Have you tried them all?
> BIOS function 0x2401 on int 0x15?
> Keyboard method (ports 0x60, 0x64)?
> PS/2 method (port 0x92)?

Yes, Scott's code does all 3 things,
and that's what Alica is using (a
modified version that works with
TASM).

> Perhaps, yet others?

We don't know of any others.

BFN. Paul.

[Alexei A. Frounze]

Um, how about you take FreeDOS and put it through
the same process. Will it be able to enable A20 in
e.g. himem.sys, cwsdpmi.exe and such?

Alex

[s_dub...@yahoo.com]

On Saturday, September 29, 2018 at 5:08:25 AM UTC-5, Paul Edwards wrote:
> On Saturday, 21 July 2018 00:46:47 UTC+10, Scott Lurndal wrote:
>
> > testA20:
> > pushw %cx # Save caller's register
> > pushw %ax # Save caller's register
>
> Is anyone familiar with UNetBootin?

No, but see:

https://github.com/unetbootin/unetbootin/wiki/howitworks

So it sounds like it installs a grubbish boot
system, parks the iso image, and goes on from
there. This is a high level foot-print on the
usb thumb-drive.

Isn't the A20 line enabled therefore, already?

>
> Alica has used UNetBootin to create a
> bootable USB, but the A20 line is not
> being enabled, despite implementing a
> modified version of the above code
> to work with tcc.
>
> From reading the description of UNetBootin
> it seems that it puts a floppy disk image
> (which is what PDOS is) into memory to
> execute. Therefor it must be doing some
> sort of emulation. And it would seem that
> it isn't emulating the A20 line properly,
> as none of the above methods cause the
> A20 to be enabled.

Your POV seems off. It places an iso image.
Early on in circa CDs that could mean a
floppy image as an iso, nowadays not??

>
> I am surprised that booting from USB is
> doing this at all. I expected the PC to
> directly boot the FAT boot sector then
> IO.SYS, not having any other software
> interfering.

It will (sort of).
o The usb boot option needs to be selected from
the bios setup screen, accessed (on this box)
by pressing F12 during a cold-boot or reboot.

o The usb thumb-drive is then seen as HD0, the
value of 80h to int 13h. This also means
that LBA=0=MBR sector. (floppy image not
expected, a HD image is).

o I've had C,H,S translation problems that I
side-stepped by using LBA access: int 13h,
AH=42h,43h

o The MBR determines where the VBR is. I use an
8mb MBR on a 16gb thumb-drive, the bootable
volume field says the volume is at LB 20h.

o I use a VBR placed at LB 20h that then boots
whatever is placed at LB 21h, and onward, into
RM at 0060:0000h. The VBR AA55h signature is
checked for by the MBR code.

o The usb boot selection is a legacy xn86 RM boot.

- Maybe a vintage dos 3.3, 4.1, 7, HD image with a
MBR and VBR would work if.. IIRC, one had to
boot off a floppy in A: before C: was
recognized, not sure when C: was the default
boot drive.

> But it seems that UNetBootin
> does interfere in the boot process.
>

Absolutely, it installs its own grub to boot
your iso image which must support that
enviornment re fat32 or equivalent tech.

Steve

[Paul Edwards]

On Sunday, 30 September 2018 03:11:35 UTC+10, s_dub...@yahoo.com wrote:

> So it sounds like it installs a grubbish boot
> system, parks the iso image, and goes on from
> there. This is a high level foot-print on the
> usb thumb-drive.

For a floppy disk it says:

"Upon bootup, memdisk will load the IMG file into memory, and boot from it."

How is it possible to boot from an
image in memory? The only way I can
see that working is:

1. The USB boot standard on the PC is
able to accept some memory reserved
for an emulated disk. Probably via
some BIOS call.

2. UNetBootin would need to be like
qemu and all the code on the memory
disk is routed through UNetBootin to
be interpreted and executed.

Either of those sound right?

Thanks. Paul.

[Rod Pemberton]

Nope. (Yeah, I'm not line wrapping at 45 chars ...)

In summary, DOS' HIMEM.sys uses over 15 different A20 enable methods,
mostly needed for older motherboards. There are also special A20
sequences for the USB host controllers. Then, there is the highly
unreliable BIOS method. So, there are probably about 20 different A20
enable methods.


First, remember that A20 via keyboard controller and A20 via PS/2
port operate separately. If you enable one, you must disable the same
one. If both, both. So, if you're checking for A20 being enabled via
the keyboard controller, but it was enabled by PS/2 port, you must also
check the PS/2 port, and vice-versa. Or, you could use some other
method for A20 detection, e.g., memory wrap-around, etc, to detect that
A20 is enabled.

Second, recall that USB controllers, have an "A20Gate Pass Through
Option bit." IIRC, this either allows or blocks A20 code sequences.
If blocked, I think the USB controller controls A20, not software, but
don't quote me on that. So, for A20 code pass through, UHCI and
OHCI /each/ have unique or special A20 code sequences to enable A20 that
must be used for the respective controller. These sequences are
different from the normal A20 enable sequences, i.e., non-standard.
See the respective manuals. I also posted them to a.o.d. years ago, but
they're hard to locate. I'm not sure if XHCI and EHCI have their own
unique A20 sequences or any A20 sequence.

Third, IIRC, HIMEM (XMS memory) also takes over A20 control, if you
have it installed and can show incorrect results for A20 state if you
check the keyboard controller or PS/2 port directly.

Fourth, if you're loading a memory manager or DOS extender, perhaps
VCPI, DPMI, EMM386, they usually take control of PM and drop you into
V86 mode, not RM. A20 is always supposed to be enabled when in PM and
hence A20 should be enabled for V86 mode. A20 is not supposed to be
disabled in PM due to processor bugs. This is cited in various
processor manuals, usually older 486 era. On most modern processors, it
shouldn't even be disable-able in PM, i.e., entering PM should force
A20 enabled.


Rod Pemberton
--
Bitcoin is a pump-and-dump scam driven by a perpetual Ponzi scheme.

[Rod Pemberton]

On Sun, 30 Sep 2018 02:16:12 -0400
Rod Pemberton <inv...@lkntrgzxc.com> wrote:

> On Sat, 29 Sep 2018 03:08:24 -0700 (PDT)
> Paul Edwards <muta...@gmail.com> wrote:

Also note that older machines /won't/ have a PS/2 port to read or write
to. I have one such older machine here (DX4-133Mhz). I.e., you can
enable A20 via the keyboard controller, but not via a PS/2 port. Code
for the PS/2 port will /hang/, if not carefully constructed to allow for
a non-existent port. This also implies you should attempt to enable
A20 via the slow keyboard controller prior to attempting to use the
PS/2 port to reduce the likelihood of such a situation.

> Third, IIRC, HIMEM (XMS memory) also takes over A20 control, if you
> have it installed and can show incorrect results for A20 state if you
> check the keyboard controller or PS/2 port directly.

I never found the correct way to check XMS for A20 state, but I've not
really read the XMS specifications.

[s_dub...@yahoo.com]

I'd rather not guess..

For (1), the usb boot standard (really the rombios, say phoenix specs) treats int13h calls to (for) HD-0 as calls re the usb (only if usb-boot is selected by the user). From there, it's a process of chain booting, like grub, only you're getting UNetBootin. Whatever that means -- I don't know what that means.

Me, for what I'm doing - hobby OSen fiddling, it's HD0 (as usb boot) with MBR,VBR,code, and no major setup environment. I can't boot dos 3.3 or cpm-86 this way because they're floppy oses expecting A: drive as default, not expecting HD booting. I could virtualize A:, B:, upon an area of the HD-0 (usb) rewrite cpm-86 or some such to work with that or do something different OR YOU could do it for your project!

(Which reminds me to ask you how you cope with floppy-less hardware for your project?).

For (2), doesn't sound like you are rid of UNetBootin, it provides some kind of environment for the image booting. What kinds of assumptions it makes, makes a difference, obviously.

Circa CD's (El Torino specification, iirc) the floppy image on CD boots similarly, but the CD is treated as A: so the bootsector logical C,H,S := 0,0,1 is loaded to 0000:7C00h and the bootstrap begins. A: is obviously Read Only medium, so in effect this is, at best, a chain boot to a larger environment. Recall the various Linux live-cd's? But, here also, CD boot had to be selected by the user.

All this is far a field from where I'm at, so I'll bow out, just wanted to pipe in to comment on booting from a usb as a hard drive medium simply as with a mbr,vbr, and your x86-32 bit code.

fwiw, I'm using a old dell 64-bit pc with debian linux for development and usb fiddling. '$ dd' is my friend! -for working with the usb.

Steve

[Paul Edwards]

On Monday, 1 October 2018 09:14:46 UTC+10, s_dub...@yahoo.com wrote:

> (Which reminds me to ask you how you
> cope with floppy-less hardware for
> your project?).

I'm not 100% sure I understand the issue
you speak of. When I run under Bochs, there
is a floppy disk present, but my boot
sequence is to start on the C drive, so
the floppy is never accessed.

So if real hardware doesn't have a floppy
disk, PDOS shouldn't care.

BTW, I thought MSDOS 3.3 could boot
from a hard disk, and I didn't know
it would barf if there were no floppy
drives present.

Thanks for the info on booting a USB
stick.

BFN. Paul.