# BIOS storage access through INT13H

The units at [drv/pc/int13hl.fs] and [drv/pc/int13hc.fs] implement a driver to
access the boot drive through the BIOS INT13H call. One is for LBA mode
(required for a partition deployment of Dusk) and the other is for CHS mode.

They implement "biossec@ ( sec buf -- )" and "biossec! ( sec buf -- )" as well as
the "bootsec@" wrapper for "biossec@" (for [doc/io/secld]).

They also implement a Drive structure around those calls, called "INT13hDrive",
but without depending on [doc/io/drive]. The idea is that this unit is needed
really early in the PC boot process and running on a really tight memory area.
One will want to load this unit, then [doc/io/secld], and only then bootstrap
the rest of the boot payload.

This driver is probably unreliable (it has to go in real mode and the process
for doing so is very very hairy. I'm not sure of how solid it is.) but will work
on all PCs until a better driver is activated.

## Overriding this drive

As we write above, this drive is unreliable and you'll want to use a proper one
as soon as possible, likely in your init.fs file. You could do something like:

  mynewdrive newfatfs bootfs!

and it *might* work, but sometimes it doesn't. For example, on some systems with
a AHCI controller, as soon as you enable AHCI, the BIOS stops working... but the
init.fs file that is being interpreted right now is hooked a FS that is hooked
to the INT13hDrive! As soon as it needs its next chunk, it will fail.

Instead what you can do is to sweep the INT13h from under your FS' nose by
copying its contents over the INT13hDrive struct. Here's an example with AHCI:

  needs drv/pc/ahci
  ahci$
  0 newahcidrive dup enable INT13hDrive AHCIDrive typesz cmove

This way, all active file cursors will immediately use the new drive and INT13h
won't ever be called again.
