Hi Gerd.

Thanks for your reply. Sorry for the delay, was swamped
with other things.

Currently I don't know what to recommend, because I
don't understand the other side of the INT 13H/14H,
only the OS side.

Well, the other side talks to the hardware,
and needs drivers to do so.  See src/hw

Surely one can write a serial driver which connects to a remote place
using some bluetooth protocol instead of talking to a 16550.  That'll
be *alot* of work though, you basically have to implement both
bluetooth stack and hardware driver.

I expected to assemble, rather than write, such a thing.
If not from the Linux source code, then FreeBSD or
ReactOS.

If for some reason (what would that be?) no-one has
abstracted bluetooth to have a clean interface that I
could have trivially reused, then I will put aside my
bluetooth dreams and switch to a different technology.
How about Wifi? Does that exist in a state usable for
my purposes?

Sure. For now, I want PDOS/386 to remain traditional.
When I have exhausted everything that is possible
via the BIOS, I will consider adding UEFI support.

If you want your firmware provide drivers to you for modern hardware you
are in a *much* better position with UEFI.

Well, on some/many/most modern machines there is
absolutely no other choice - the BIOS doesn't exist,
even as CSM.

There is a bluetooth
protocol specification for example, although I'm not sure how common it
is to find an actual uefi driver for bluetooth hardware in the firmware.
Talking to ethernet using the firmware-provided uefi driver shouldn't be
much of a problem though b/c network boot is a rather standard feature.

Ok, maybe in the medium term I should use a hardware
device, forget the name, that turns ethernet into Wifi.

So then the problem is reduced to me needing to provide
a BOOTX64.EFI that converts INT 14H into UEFI ethernet
calls.

But I'd like to transport all of that software, designed for
that environment, and change nothing at all, and have
it work on a new environment that includes Wifi, bluetooth
and maybe ethernet, and maybe infrared, and maybe
other things I don't know about, but make sense (at
some level) to be accessed via INT 14H.

Well.  In the server world it is rather common to provide access to the
serial line over the network for system management purposes.

One approach for that is to have a separate management controller (bmc),
and the serial port of the machine is linked to the management
controller instead of a D9 socket.  You can then connect to the bmc to
manage the machine, and one of the options available is to get serial
console access.

Ok, this would allow me to have a BBS.

But not allow me to have a "virtual modem" so that I can
dial out.

Another approach is to have a virtual 16550 provided by the firmware.
Accessing the virtual 16550 will trap into SMM mode where the firmware
emulates a serial device and allows to access the serial port remotely
over the network, roughly comparable to how qemu provides an virtual
16550 to virtual machines.

Ok, but in the case of qemu I have the same issue - at the end
of the day I want to drive a modem, so with qemu I can get it
to talk to a "virtual modem". If the firmware is providing the
serial to network conversion, I also need to stick in a virtual
modem there. And that's what I was hoping SeaBIOS would
allow me to do.

Note that both approaches work at hardware level not int14h level,
because modern operating systems use int14h services in bootloaders
only if at all.

My operating system, PDOS/386, may not be considered "modern",
even though it is in active development, but I do wish to use
INT 14H, as that was the traditional BIOS service provided, and I
wish to maintain contact with the original 80386 machines.

I expect a modern environment to have the CPU, memory etc
required to support this basic interface.

BFN. Paul.