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.
