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.
I have a new variation on this problem.
I have a Chromebook with seabios loaded.
But the Chromebook doesn't have a serial port.
I could get a USB to com port adapter.
But I would like seabios to drive this so that I can use int 14h in my os.
Is that something that exists or could be added?
Note that the Chromebook doesn't appear to have an Ethernet port either, so any solution using that won't work either.
Thanks. Paul.
On Friday, 6 August 2021, Paul Edwards mutazilah@gmail.com wrote:
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.
I have done further exploration and have a new proposal.
I found that USB to serial port adapters are not standardized.
So instead, what about adding NDIS to do USB tethering plus a tcpip stack to create a virtual modem that would allow you to do:
ATDnews.eternal-september:119
Then I could connect my Chromebook to my Android phone using the standard cable.
Would most of this be able to use existing code?
On Thursday, 15 September 2022, Paul Edwards mutazilah@gmail.com wrote:
I have a new variation on this problem.
I have a Chromebook with seabios loaded.
But the Chromebook doesn't have a serial port.
I could get a USB to com port adapter.
But I would like seabios to drive this so that I can use int 14h in my os.
Is that something that exists or could be added?
Note that the Chromebook doesn't appear to have an Ethernet port either, so any solution using that won't work either.
Thanks. Paul.
On Friday, 6 August 2021, Paul Edwards mutazilah@gmail.com wrote:
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.
Hi Paul,
Paul Edwards wrote:
I have a new variation on this problem.
I have a Chromebook with seabios loaded.
But the Chromebook doesn't have a serial port.
I could get a USB to com port adapter.
But I would like seabios to drive this so that I can use int 14h in my os.
Is that something that exists or could be added?
Maybe. Like Bluetooth, USB is also non-trivial. But SeaBIOS does already have USB infrastructure and does already implement something in principle similar to what you want for int 13h and USB storage devices - that's both precedent and a reference.
I found that USB to serial port adapters are not standardized.
That is true but there aren't all that many popular manufacturers of chips for such products, and if I understand correctly you can at least to some degree make recommendations on specific hardware to replicate the setup you're aiming for, so maybe it's okay to also pick one particular USB-to-serial chip and recommend products using that?
So instead, what about adding NDIS to do USB tethering plus a tcpip stack to create a virtual modem that would allow you to do:
Since SeaBIOS has no TCP/IP stack that would require far larger development effort, and introduce significant complexity to SeaBIOS for a very rare use case that so far only one person requests while at the same time not signalling readiness to provide long-term maintenance effort of source code - making it unlikely to manifest.
Would most of this be able to use existing code?
A USB-to-serial adapter would allow pretty good reuse.
I prefer the CP210x family of chips because the USB protocol and cost is sane (unlike FTDI, which fails massively on those points) and because they have always been very reliable for me, although e.g. CP2102N rev A01 chips have a whole bunch of serious errata.
If you pick a CP2102N-based product then make sure to get ones using revision A02 chips. (This will be hard to find out! But: Other manufacturers have other issues, sometimes even undocumented.)
Less complexity in SeaBIOS would probably only be achievable with a custom USB device.
I asked before about the broader picture of your project but never got much of an answer.
If it would be acceptable to provide instructions for programming some microcontroller development board to replicate your success as opposed to providing product recommendation for a particular USB-to-serial adapters then you could essentially make your own USB-to-serial adapter with firmware and thereby USB protocol optimized for the in-SeaBIOS use case.
That may sound like over-engineering but the BIOS environment is special enough that it could be a reasonable design, if outside parameters and requirements permit.
Hope this helps
//Peter
Hi Peter (Stuge).
Thanks for your reply.
I asked before about the broader picture of your project but never got much of an answer.
Let me start by answering this, noting that my goals are not set in stone, and have changed even recently.
First of all I don't want to rely on the internet. I am currently in the Philippines, and some people live outside of mobile phone coverage so have no internet. No phone lines either. There is grid electricity though.
Anyway, I'm not convinced that modems are dead, and even if they are, in the event of a nuclear war, they may exist again, and even if someone provides mathematical proof that that won't happen, I'm still interested in retrocomputing.
So I expect INT 14H, or some equivalent, to exist, to drive a modem. I expect the infrastructure to exist to dial BBSes and download files using zmodem. I am providing all of that infrastructure from the OS and application side, but expected the BIOS to take care of a portion of the work.
There should be a clear delineation of responsibilities.
That delineation has never been clear to me.
But now I have a proposal in proof of concept stage. An "ideal bios" or "pseudo bios" or "hardware abstraction layer". Not sure what the best terminology is. And it is designed to be ideal for C code.
Here is the fairly simple proof of concept:
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/generic/pdos.c
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/generic/bios.c
It has some similarity to UEFI, but it is designed to be a replacement for 80s/90s bioses, so I only want something like 30% extra code, at least in theory if someone implements it in assembler, and with implied restrictions.
In addition I am expecting the MBR code to be executed in PM32 by a modified or replaced SeaBIOS.
It is only recently that I bought a Chromebook and realized that my theoretical ideal bios could actually be a reality, as the Chromebook allows you to flash something on it, without even needing to play around with screws.
Note that if people wish to run PDOS on standard hardware with a standard BIOS, that can be accomplished with different code in the layer. Even a UEFI-only machine could be accommodated with an appropriate layer.
Since SeaBIOS has no TCP/IP stack that would require far larger development effort, and introduce significant complexity to SeaBIOS for a very rare use case that so far only one person requests while at the same time not signalling readiness to provide long-term maintenance effort of source code - making it unlikely to manifest.
I'm surprised that the TCP/IP stack can't be taken from some other project, and maintained by that other project.
If it would be acceptable to provide instructions for programming some microcontroller development board to replicate your success as opposed to providing product recommendation for a particular USB-to-serial adapters then you could essentially make your own USB-to-serial adapter with firmware and thereby USB protocol optimized for the in-SeaBIOS use case.
That's not a bad idea.
But I may simply move all the driver code into PDOS (which currently has no drivers, only using the BIOS), with a comment in the documentation that proper abstraction would be to move the code into SeaBIOS or equivalent.
Do you have any comment on the philosophy/abstraction/ interface, as that is the main driver?
Thanks. Paul.
-
Paul Edwards -
Peter Stuge