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.