bios code

[muta...@gmail.com]

All my recent code for the generic BIOS work is available here:

http://www.mutazilah.org/bios.zip

See readme.txt

BFN. Paul.

[muta...@gmail.com]

On Saturday, March 13, 2021 at 7:52:46 PM UTC+11, muta...@gmail.com wrote:
> All my recent code for the generic BIOS work is available here:

It's now available here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/bios/

and while you're there, we finally have a decent
(accepts spaces, instead of unmanageable-on-MVS
tabs) public domain, portable C90 code, version of
"make", called "pdmake", available here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdmake/

I suggest keeping all your makefiles compatible with that,
so that they can also be used with Borland "make".

Anyway, with regard to the BIOS code, my plan is to focus
on the C library, e.g. fopen/fread. Let's start with fopen.

A BIOS needs to export an fopen() for use by an OS.

An OS needs to export an fopen() for use by applications,
as well as importing the fopen() from the BIOS, as well as
implementing an actual fopen() that analyzes FAT directory
entries with LFN etc.

So the abstraction is:

osfunc.h:

void *FLAVOR(os_fopen)(char *fnm, char *mode);

And we can just stick with the OS, which is the difficult one.
Note that the OS itself needs to load ELF executables etc
which it will do with fopen() itself.

In stdio.c there will be an fopen() that calls FLAVOR(os_fopen)

This gets translated into implement_os_fopen().

Somewhere in os.c there will be an implement_os_fopen() that
analyzes the FAT file system.

When os.c needs BIOS services, it will execute import_os_fopen().

os.c will link with an osexp.c which contains export_os_fopen().

Requests from the app doing an fopen() will go to its own C
library which will then invoke FLAVOR(os_fopen) (like everyone
else does) which turns into an import_os_fopen() which gets
channeled into an osfunc_out(OS_FOPEN) call,
which finds its way up to an osfunc_in(OS_FOPEN) function in
the OS, which then calls export_os_fopen(), still in the OS, and then
directly call fopen() in the OS C library, which then goes into
implement_fopen() in the OS, which may entail doing calls to
import_os_fread() to access the raw hard disk (ie, a BIOS call).

How the BIOS implements that is irrelevant, but one simple,
portable implementation is to simply open a flat file that
represents a FAT hard disk, using someone else's C library.

All executables operate at native speed, even if flat files are
being used for disk access.

An OS should be able to do an fopen("::", "r+b"); to read/write
its boot disk. That should be a "known name" to all BIOSes.

The OS should be able to analyze its own boot disk, find a
config.sys, which contains entries such as:

fred.dat D
mary.dat E
0x1A0 F

which represent names that the BIOS will recognize, and the
drive letter the OS should assign to that raw disk.

Sound like a plan?

Thanks. Paul.

[muta...@gmail.com]

I have some more proposals for the "generic BIOS".

Similar to INT 15H AX=E820H, the OS should be able
to do an fopen("::ram", "r");

and fgets() returns lines that look like:

01000000,03000000
03100000,80000000

to find out the addresses in memory available to the OS.

Also fopen("::drives", "r");
would have fgets() return lines that could look like:

0x80
0x81
fred.dat

indicating the "known devices" that can be fopen'd with:
fopen("0x80", "r+b"); etc

I would also like to be able to access the boot drive with
fopen("::boot") so there needs to be some mechanism
for me to know which device was the boot drive, otherwise
it will appear twice.

Maybe fgets() could have:
0x80 boot

so I know I can skip it.

Note that I should also be able to boot from RAM, or
even some inaccessible device only seen via "::boot".

BFN. Paul.