Hi, > 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. > 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. 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. > 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. 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. Note that both approaches work at hardware level not int14h level, because modern operating systems use int14h services in bootloaders only if at all. take care, Gerd _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
