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.