Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

com port

92 views
Skip to first unread message

muta...@gmail.com

unread,
Aug 1, 2022, 6:15:28 PM8/1/22
to
This could be a double post.

Bochs could be designed to point a com port
To a host file.

The pdos application could do fopen of com1 r+b

Pdos will dutifully translate that into reads and writes of the com port.

If the app does an fseek to an earlier position
an initialization of the com port could be
done which Bochs interprets as a rewind.

Pdos would then do reads to get to the right position.

Tape drives may behave similarly.

Is there some principle here?

It won't work if the com port is connected to another computer though.

Although maybe if dtr/dcd were manipulated it could.

JJ

unread,
Aug 2, 2022, 9:40:46 AM8/2/22
to
According to Bochs documentation (bochsrc.html), when a serial port is
configured as file mode, the specified file can only work as an output. It
can not work as an input (i.e. as a data source).

For both output and input, only raw, socket, and pipe modes should be used.

Also, serial port is not a seekable device. It's just a generic
communication device with no data-size related protocol. Thus, there is
concept of data position. There's no way to seek to specific data position,
or do a rewind. Such functionality/feature is for application level
implementation instead of hardware level implementation.

muta...@gmail.com

unread,
Aug 2, 2022, 3:45:54 PM8/2/22
to
You just described what currently happens.

I just described what could happen, including the ability to seek.

Is there a reason why my proposal wouldn't work?

Assuming my proposal would work,
does it provide a new conceptual model
for accessing external files?

Perhaps the simplest form of networking?

Scott Lurndal

unread,
Aug 2, 2022, 4:26:48 PM8/2/22
to
How, exactly, do you propose to handle seek on an
inherently ephemeral bitstream such as that produced
by serial receiver logic, whether it is a RS232C
UART or a 100Gb/s LAN?

muta...@gmail.com

unread,
Aug 2, 2022, 7:55:59 PM8/2/22
to
Are you talking about Bochs or a real serial port attached to perhaps a null modem cable to another computer?

The former I explained above already.

The latter I touched on above but I'm not certain about.

The latter would involve dropping dtr or dcd to rewind, but I'm not sure that is possible.

In both cases, rewinding a file is similar to a tape drive so there may be prior art.

Paul.

JJ

unread,
Aug 3, 2022, 10:59:45 AM8/3/22
to
On Tue, 2 Aug 2022 12:45:53 -0700 (PDT), muta...@gmail.com wrote:
>
> You just described what currently happens.
>
> I just described what could happen, including the ability to seek.
>
> Is there a reason why my proposal wouldn't work?
>
> Assuming my proposal would work,
> does it provide a new conceptual model
> for accessing external files?
>
> Perhaps the simplest form of networking?

To achieve what you want, there has to be an application at each endpoint.
The implementation can not be done only at one endpoint. There has to be at
least the server and the client part to communicate between endpoints, since
serial port has no concept of file size (and file pointer).

Serial port's lines/statuses are meant for handling the communication
between two serial port endpoints, which includes data flow. While they can
be used for application level communication, it would decrease the
communication handling capability. e.g. no way to know whether the other
endpoint is ready to receive data or not; or no way to interrupt and notify
the other endpoint that, the received data is corrupted and needs to be
resent.

Since `file` exists in application level implementation, anything related to
it should be implemented at application level rather than hardware level.
Hardware things have their own purposes for good reasons. Reusing them for
application things would decrease the hardware's basic capability and/or
performance. That should only be done if the two endpoints is connected
using only 3-wires cable, instead of the full e.g. 7-wires cable. It's not
wrong, but it should be avoided.

muta...@gmail.com

unread,
Aug 3, 2022, 6:36:29 PM8/3/22
to
Hi JJ. Thanks for your thoughtful response.

Do you think, with the benefit of hindsight, there should have been a
mechanism for what we now know as host file access?

The method above, abusing the hardware, is not the only
method I have used. My pdos-generic code is already capable of
this, but relies on a cooperative bios.

The hardware could also have been designed with
another wire if you think the existing wires cannot be
repurposed.

It's a good point that with a serial cable you could
have data corruption so ideally you want a crc and error
correction. When that is added do you end up
with SLIP/PPP?

Maybe this crude method, relying on error-free
communication, could be used while waiting for
SLIP/PPP to be implemented?

Paul.

JJ

unread,
Aug 4, 2022, 10:04:54 AM8/4/22
to
On Wed, 3 Aug 2022 15:36:27 -0700 (PDT), muta...@gmail.com wrote:
>
> Hi JJ. Thanks for your thoughtful response.
>
> Do you think, with the benefit of hindsight, there should have been a
> mechanism for what we now know as host file access?

It would be nice, but don't you think it's too late for that? Serial port is
now considered as a legacy (but not dead yet) communication port. It's no
longer in development and it's no longer widely used except in industrial
and business fields. What's your intended use case scenario for it, anyway?
Cause I could think that it's for a special use case only.

> The method above, abusing the hardware, is not the only
> method I have used. My pdos-generic code is already capable of
> this, but relies on a cooperative bios.

That's expected, since it's not part of the standard specification. Though,
BIOS modification is not actually required, since what's needed can be
implemented as a TSR/driver which hooks BIOS functions; unless you want it
to work even without an OS.

> The hardware could also have been designed with
> another wire if you think the existing wires cannot be
> repurposed.

Sure, why not. But all serial port pins are already used. The DCD and RI
pins are the only possible ones which can be repurposed for what you're
trying to achieve.

> It's a good point that with a serial cable you could
> have data corruption so ideally you want a crc and error
> correction. When that is added do you end up
> with SLIP/PPP?

It would be similar to it, at least for the error detection/correction part.

> Maybe this crude method, relying on error-free
> communication, could be used while waiting for
> SLIP/PPP to be implemented?
>
> Paul.

I think it's fine if it's just for a temporary solution. Otherwise it would
be naive to think that, users would use it in an ideal environment. Who
knows, one may use it in a factory/lab where it's plenty of electromagnetic
wave.

Scott Lurndal

unread,
Aug 4, 2022, 12:43:31 PM8/4/22
to
Although today, the factory or lab is far more likley to use gigabit ethernet
over shielded twisted pair or fiber.

muta...@gmail.com

unread,
Aug 4, 2022, 10:36:39 PM8/4/22
to
On Thursday, August 4, 2022 at 10:04:54 PM UTC+8, JJ wrote:
> On Wed, 3 Aug 2022 15:36:27 -0700 (PDT), muta...@gmail.com wrote:
> >
> > Hi JJ. Thanks for your thoughtful response.
> >
> > Do you think, with the benefit of hindsight, there should have been a
> > mechanism for what we now know as host file access?

> It would be nice, but don't you think it's too late for that?

No. I am trying to extract philosophy.

If you think this would be nice, then what
would you propose exactly?

And could this have been figured out decades ago?

Or was something missing?

At the same time you can solve the problem of
people in real life, for years, taking their chances
with line noise. Before error-correcting modems.
Does error-correction belong in modems or applications,
as happened in real life?

Or does it belong in the os?

If someone types:

rm -fr /scratch

And line noise of "enter" happens after
the "/", who failed to think things through?

> Serial port is
> now considered as a legacy (but not dead yet) communication port. It's no
> longer in development and it's no longer widely used except in industrial
> and business fields. What's your intended use case scenario for it, anyway?

Host file access is what I am after right now.

> Cause I could think that it's for a special use case only.

I'm more interested in the philosophy of
external communication.

> > The method above, abusing the hardware, is not the only
> > method I have used. My pdos-generic code is already capable of
> > this, but relies on a cooperative bios.
> That's expected, since it's not part of the standard specification. Though,
> BIOS modification is not actually required, since what's needed can be
> implemented as a TSR/driver which hooks BIOS functions; unless you want it
> to work even without an OS.

I'm interested in changing the bios specification.

Within the limits of the old computers.
Or close.

Specifically I am after fopen of 0x80

> > The hardware could also have been designed with
> > another wire if you think the existing wires cannot be
> > repurposed.
> Sure, why not. But all serial port pins are already used. The DCD and RI
> pins are the only possible ones which can be repurposed for what you're
> trying to achieve.

Well maybe that's exactly what should be specified.

> > It's a good point that with a serial cable you could
> > have data corruption so ideally you want a crc and error
> > correction. When that is added do you end up
> > with SLIP/PPP?
> It would be similar to it, at least for the error detection/correction part.
> > Maybe this crude method, relying on error-free
> > communication, could be used while waiting for
> > SLIP/PPP to be implemented?
> >
> > Paul.
> I think it's fine if it's just for a temporary solution. Otherwise it would
> be naive to think that, users would use it in an ideal environment. Who
> knows, one may use it in a factory/lab where it's plenty of electromagnetic
> wave.

Perhaps with error-correcting modems too.

JJ

unread,
Aug 5, 2022, 7:21:18 AM8/5/22
to
On Thu, 4 Aug 2022 19:36:38 -0700 (PDT), muta...@gmail.com wrote:
>
> If you think this would be nice, then what
> would you propose exactly?

I've already mentioned that. The protocol implementation should be in form
of sent/received data, instead of hardware signals. Again, it not wrong, but
there will be drawbacks.

> And could this have been figured out decades ago?
>
> Or was something missing?

I'm pretty sure hobbyists have done similar in the past, except that, they
aren't pushlished, or we haven't heard of it.

> Does error-correction belong in modems or applications,
> as happened in real life?

In modems, in terms of physical location (its ADC has a basic error
correction). And in application, in terms of concept.

> Or does it belong in the os?

It depends on the involved protocol. Hence, application implementation.

> If someone types:
>
> rm -fr /scratch
>
> And line noise of "enter" happens after
> the "/", who failed to think things through?

Error correction is not a 100% guarantee to be able to correct all errors.
There are times when it's simply overwhelmed by outside force. And that
includes implementations in current modern error correction algorithms. Even
NASA encounters data errors.

> I'm interested in changing the bios specification.
>
> Within the limits of the old computers.
> Or close.
>
> Specifically I am after fopen of 0x80

Well, from the OS'/firmware's point of view, a serial port is seen as a
device, instead of a file. Low level thinkering would be needed to change
that behavior. The question is, do you want to keep compatibility, or not?

muta...@gmail.com

unread,
Aug 5, 2022, 8:03:32 AM8/5/22
to
On Friday, August 5, 2022 at 7:21:18 PM UTC+8, JJ wrote:
> On Thu, 4 Aug 2022 19:36:38 -0700 (PDT), muta...@gmail.com wrote:
> >
> > If you think this would be nice, then what
> > would you propose exactly?
> I've already mentioned that. The protocol implementation should be in form
> of sent/received data, instead of hardware signals. Again, it not wrong, but
> there will be drawbacks.

I guess that's fair enough. Bochs could be
updated to handle that protocol.

> > And could this have been figured out decades ago?
> >
> > Or was something missing?
> I'm pretty sure hobbyists have done similar in the past, except that, they
> aren't pushlished, or we haven't heard of it.
> > Does error-correction belong in modems or applications,
> > as happened in real life?
> In modems, in terms of physical location (its ADC has a basic error
> correction). And in application, in terms of concept.

Modems don't cover potential line noise in
the serial cable. Doesn't the os make more sense?

> > Or does it belong in the os?
> It depends on the involved protocol. Hence, application implementation.

Can't the protocol go into the os and be
transparent to all apps in the same way
that writing to disk is? Is there some conceptual
difference between disks and serial ports?

> > If someone types:
> >
> > rm -fr /scratch
> >
> > And line noise of "enter" happens after
> > the "/", who failed to think things through?
> Error correction is not a 100% guarantee to be able to correct all errors.
> There are times when it's simply overwhelmed by outside force. And that
> includes implementations in current modern error correction algorithms. Even
> NASA encounters data errors.
> > I'm interested in changing the bios specification.
> >
> > Within the limits of the old computers.
> > Or close.
> >
> > Specifically I am after fopen of 0x80
> Well, from the OS'/firmware's point of view, a serial port is seen as a
> device, instead of a file. Low level thinkering would be needed to change
> that behavior. The question is, do you want to keep compatibility, or not?

What are my choices here?

And compatibility with what?

Scott Lurndal

unread,
Aug 5, 2022, 10:02:19 AM8/5/22
to
"muta...@gmail.com" <muta...@gmail.com> writes:
>On Friday, August 5, 2022 at 7:21:18 PM UTC+8, JJ wrote:
>> On Thu, 4 Aug 2022 19:36:38 -0700 (PDT), muta...@gmail.com wrote:
>> >
>> > If you think this would be nice, then what
>> > would you propose exactly?
>> I've already mentioned that. The protocol implementation should be in form
>> of sent/received data, instead of hardware signals. Again, it not wrong, but
>> there will be drawbacks.
>
>I guess that's fair enough. Bochs could be
>updated to handle that protocol.
>
>> > And could this have been figured out decades ago?
>> >
>> > Or was something missing?
>> I'm pretty sure hobbyists have done similar in the past, except that, they
>> aren't pushlished, or we haven't heard of it.
>> > Does error-correction belong in modems or applications,
>> > as happened in real life?
>> In modems, in terms of physical location (its ADC has a basic error
>> correction). And in application, in terms of concept.
>
>Modems don't cover potential line noise in
>the serial cable. Doesn't the os make more sense?

There has been fifty years of research on error correction
since the modem was developed.

https://www.researchgate.net/publication/293100129_Forward_error_correction_FEC_for_high-speed_serdes_link_system_of_25-28Gbs

The error correction applies to the received data when
parity or other integrity mechanisms indicate that the
data may not be correct on the receiver side.

JJ

unread,
Aug 6, 2022, 10:19:50 AM8/6/22
to
On Fri, 5 Aug 2022 05:03:31 -0700 (PDT), muta...@gmail.com wrote:
>
> Modems don't cover potential line noise in
> the serial cable. Doesn't the os make more sense?

Error correction can be implemented in any layer of protocol. Though most of
current protocol implementations only have error detection, rather than
error correction. Error correction requires more computing time, and won't
help much in most cases.

> Can't the protocol go into the os and be
> transparent to all apps in the same way
> that writing to disk is? Is there some conceptual
> difference between disks and serial ports?

It can be transparent. Just like iSCSI or NAS.

Serial port is a data transporter. Disk is a data container. Those are two
completely different thing.

Scott Lurndal

unread,
Aug 6, 2022, 11:19:51 AM8/6/22
to
JJ <jj4p...@outlook.com> writes:
>On Fri, 5 Aug 2022 05:03:31 -0700 (PDT), muta...@gmail.com wrote:
>>
>> Modems don't cover potential line noise in
>> the serial cable. Doesn't the os make more sense?
>
>Error correction can be implemented in any layer of protocol. Though most of
>current protocol implementations only have error detection, rather than
>error correction. Error correction requires more computing time, and won't
>help much in most cases.

Error correction techniques are required for modern high-speed serial
transmission (>100Gb ethernet, PCI express, Fiberchannel, et alia).

Protocols have a designed BER of 10^-12 (or better), which requires significant
error correction (such as forward error correction) to be built into
the hardware and protocols. FEC, checksums/CRCs and retransmission
are all used to protect and correct (or retransmit) data.

PCI Express 6.0, for example:

https://itigic.com/forward-error-correction-fec-features-in-pcie-6-0/

muta...@gmail.com

unread,
Aug 6, 2022, 11:00:22 PM8/6/22
to
On Saturday, August 6, 2022 at 10:19:50 PM UTC+8, JJ wrote:

> Serial port is a data transporter. Disk is a data container. Those are two
> completely different thing.

But with the benefit of hindsight, the data
transporter is sometimes a data container.

Maybe both com ports and disks should
be defined as having a dual nature.

Like electromagnetic radiation.

s_dub...@yahoo.com

unread,
Aug 9, 2022, 1:32:26 PM8/9/22
to
On Thursday, August 4, 2022 at 9:36:39 PM UTC-5, muta...@gmail.com wrote:
> On Thursday, August 4, 2022 at 10:04:54 PM UTC+8, JJ wrote:
> > On Wed, 3 Aug 2022 15:36:27 -0700 (PDT), muta...@gmail.com wrote:
> > >
> > > Hi JJ. Thanks for your thoughtful response.
> > >
> > > Do you think, with the benefit of hindsight, there should have been a
> > > mechanism for what we now know as host file access?
>
> > It would be nice, but don't you think it's too late for that?
> No. I am trying to extract philosophy.
>
> If you think this would be nice, then what
> would you propose exactly?
>
> And could this have been figured out decades ago?
>
> Or was something missing?
>
> At the same time you can solve the problem of
> people in real life, for years, taking their chances
> with line noise. Before error-correcting modems.
> Does error-correction belong in modems or applications,
> as happened in real life?
>
> Or does it belong in the os?

Here is where a driver for the device is useful. The OS should only get notification of device error.
The driver for the device would be the place to attempt error correction, at the least, return a fail status to the OS.

>
> If someone types:
>
> rm -fr /scratch
>
> And line noise of "enter" happens after
> the "/", who failed to think things through?

The shell. It's design fails to catch that and issue a warning and a confirm request, istm.
Your example uses the keyboard to communicate to the console through the 'shell'.
Very early on, before the ibm pc this was handled through the i8255, with the pc this changed.
reference note of modes of operation..
https://en.wikipedia.org/wiki/Intel_8255

The OS kernel should not have to deal with these low level details, a specific driver should handle it.
Same with error detection and attempted correction. It should be handled by the specific driver.

> > Serial port is
> > now considered as a legacy (but not dead yet) communication port. It's no
> > longer in development and it's no longer widely used except in industrial
> > and business fields. What's your intended use case scenario for it, anyway?

> Host file access is what I am after right now.

What is this 'Host'? Bochs? -- or are you calling your OS the host? -or- ?

> > Cause I could think that it's for a special use case only.
> I'm more interested in the philosophy of
> external communication.

You develop in C I think, so dig into the topic of streams.
-- It's likely you have, forgive me for being a dunce.
In addition to stdin, stdout, stderr, you could add stdtmp where stdtmp is a file already in an opened state, like the others, to catch COM1: input stream through the stdtmp driver.
The hard part is determining End Of Transmission.
Perhaps the stdtmp driver has a time-out function to catch EOT.
When the simplest protocol is the case, where COM1: just takes byte data, no control bytes are allowed to be embedded. The risk of errors is low if stored in memory, or a thumb-drive.
The risk is high if the device is slower than COM1: such as a floppy drive.
Early on, all devices were slow, so some form of transmission protocols were developed.
So think in terms a byte being converted into two bytes, each an ASCII nibble.
Prepend some ascii info and trailing check sum and you have a Intel .HEX record.
https://en.wikipedia.org/wiki/Intel_HEX

Since ASCII HEX restricts bytes into the printable range, bytes outside this range can be used for control.
For example, 07h aka byte value 7, where value 7 is not printable if handled by the console.
But causes the console to 'beep'.
The ASCII form of 07h is 30,37.
> > > The method above, abusing the hardware, is not the only
> > > method I have used. My pdos-generic code is already capable of
> > > this, but relies on a cooperative bios.
> > That's expected, since it's not part of the standard specification. Though,
> > BIOS modification is not actually required, since what's needed can be
> > implemented as a TSR/driver which hooks BIOS functions; unless you want it
> > to work even without an OS.
> I'm interested in changing the bios specification.
>
> Within the limits of the old computers.
> Or close.

Are you talking about IO.SYS or RomBios?
I'd say the IO.SYS is the walkway into the RomBios, perhaps the minimum io functions handler.

> Specifically I am after fopen of 0x80

At first glance I saw fopen port 80, the http port, but you have written 80h.

Steve

muta...@gmail.com

unread,
Aug 9, 2022, 3:52:09 PM8/9/22
to
On Wednesday, August 10, 2022 at 1:32:26 AM UTC+8, s_dub...@yahoo.com wrote:
> On Thursday, August 4, 2022 at 9:36:39 PM UTC-5, muta...@gmail.com wrote:
> > On Thursday, August 4, 2022 at 10:04:54 PM UTC+8, JJ wrote:
> > > On Wed, 3 Aug 2022 15:36:27 -0700 (PDT), muta...@gmail.com wrote:
> > > >
> > > > Hi JJ. Thanks for your thoughtful response.
> > > >
> > > > Do you think, with the benefit of hindsight, there should have been a
> > > > mechanism for what we now know as host file access?
> >
> > > It would be nice, but don't you think it's too late for that?
> > No. I am trying to extract philosophy.
> >
> > If you think this would be nice, then what
> > would you propose exactly?
> >
> > And could this have been figured out decades ago?
> >
> > Or was something missing?
> >
> > At the same time you can solve the problem of
> > people in real life, for years, taking their chances
> > with line noise. Before error-correcting modems.
> > Does error-correction belong in modems or applications,
> > as happened in real life?
> >
> > Or does it belong in the os?
> Here is where a driver for the device is useful. The OS should only get notification of device error.
> The driver for the device would be the place to attempt error correction, at the least, return a fail status to the OS.

Ok, good point. I don't really understand drivers.
So far in pdos I have not attempted or needed such a concept.

> >
> > If someone types:
> >
> > rm -fr /scratch
> >
> > And line noise of "enter" happens after
> > the "/", who failed to think things through?
> The shell. It's design fails to catch that and issue a warning and a confirm request, istm.
> Your example uses the keyboard to communicate to the console through the 'shell'.
> Very early on, before the ibm pc this was handled through the i8255, with the pc this changed.
> reference note of modes of operation..
> https://en.wikipedia.org/wiki/Intel_8255
>
> The OS kernel should not have to deal with these low level details, a specific driver should handle it.
> Same with error detection and attempted correction. It should be handled by the specific driver.

So for example, if an app does an fseek of a com
Port to an earlier position, what I want is for the com port
to be reset, which Bochs detects and does a rewind
of the host file, then reads done from the com port to
get to the right position. That is something that would go
into a driver?

> > > Serial port is
> > > now considered as a legacy (but not dead yet) communication port. It's no
> > > longer in development and it's no longer widely used except in industrial
> > > and business fields. What's your intended use case scenario for it, anyway?
>
> > Host file access is what I am after right now.
> What is this 'Host'? Bochs? -- or are you calling your OS the host? -or- ?

I am running pdos under Bochs on an Android phone.

Pdos is the guest os and the android is the host.

I thought this was standard terminology?

> > > Cause I could think that it's for a special use case only.
> > I'm more interested in the philosophy of
> > external communication.
> You develop in C I think, so dig into the topic of streams.
> -- It's likely you have, forgive me for being a dunce.
> In addition to stdin, stdout, stderr, you could add stdtmp where stdtmp is a file already in an opened state, like the others, to catch COM1: input stream through the stdtmp driver.

I don't have a problem at this level.
For the purposes of this conversation I am happy
to do an fopen of com1 r+b

> The hard part is determining End Of Transmission.

For normal com port usage I would rely on the
Bios timeout. When I am accessing a host file,
I expect Bochs to give a timeout at EOF.

> Perhaps the stdtmp driver has a time-out function to catch EOT.
> When the simplest protocol is the case, where COM1: just takes byte data, no control bytes are allowed to be embedded. The risk of errors is low if stored in memory, or a thumb-drive.
> The risk is high if the device is slower than COM1: such as a floppy drive.
> Early on, all devices were slow, so some form of transmission protocols were developed.
> So think in terms a byte being converted into two bytes, each an ASCII nibble.
> Prepend some ascii info and trailing check sum and you have a Intel .HEX record.
> https://en.wikipedia.org/wiki/Intel_HEX
>
> Since ASCII HEX restricts bytes into the printable range, bytes outside this range can be used for control.
> For example, 07h aka byte value 7, where value 7 is not printable if handled by the console.
> But causes the console to 'beep'.
> The ASCII form of 07h is 30,37.
> > > > The method above, abusing the hardware, is not the only
> > > > method I have used. My pdos-generic code is already capable of
> > > > this, but relies on a cooperative bios.
> > > That's expected, since it's not part of the standard specification. Though,
> > > BIOS modification is not actually required, since what's needed can be
> > > implemented as a TSR/driver which hooks BIOS functions; unless you want it
> > > to work even without an OS.
> > I'm interested in changing the bios specification.
> >
> > Within the limits of the old computers.
> > Or close.
> Are you talking about IO.SYS or RomBios?
> I'd say the IO.SYS is the walkway into the RomBios, perhaps the minimum io functions handler.

Either will do the job from the point of view
of the os. Which leads to another question. Someone said
that what I am calling an ideal bios or pseudo-bios
is actually a hardware abstraction layer.
Does that sound right?

> > Specifically I am after fopen of 0x80
> At first glance I saw fopen port 80, the http port, but you have written 80h.

The first hard disk. Being opened as a stream.
That's what I want the bios to provide.

The bios is just software, easily changed
to prove a concept. Especially with Bochs.

s_dub...@yahoo.com

unread,
Aug 12, 2022, 11:57:37 AM8/12/22
to
On Tuesday, August 9, 2022 at 2:52:09 PM UTC-5, muta...@gmail.com wrote:
> On Wednesday, August 10, 2022 at 1:32:26 AM UTC+8, s_dub...@yahoo.com wrote:
> > On Thursday, August 4, 2022 at 9:36:39 PM UTC-5, muta...@gmail.com wrote:
> > > On Thursday, August 4, 2022 at 10:04:54 PM UTC+8, JJ wrote:
> > > > On Wed, 3 Aug 2022 15:36:27 -0700 (PDT), muta...@gmail.com wrote:
> > > > >
> > > > > Hi JJ. Thanks for your thoughtful response.
> > > > >
> > > > > Do you think, with the benefit of hindsight, there should have been a
> > > > > mechanism for what we now know as host file access?
> > >
> > > > It would be nice, but don't you think it's too late for that?
> > > No. I am trying to extract philosophy.
> > >
> > > If you think this would be nice, then what
> > > would you propose exactly?
> > >
> > > And could this have been figured out decades ago?
> > >
> > > Or was something missing?
> > >
> > > At the same time you can solve the problem of
> > > people in real life, for years, taking their chances
> > > with line noise. Before error-correcting modems.
> > > Does error-correction belong in modems or applications,
> > > as happened in real life?
> > >
> > > Or does it belong in the os?
> > Here is where a driver for the device is useful. The OS should only get notification of device error.
> > The driver for the device would be the place to attempt error correction, at the least, return a fail status to the OS.
> Ok, good point. I don't really understand drivers.

Think 'Device Control'. A device driver is the controlling code for the device, that is, the device specific code.

> So far in pdos I have not attempted or needed such a concept.
> > >
> > > If someone types:
> > >
> > > rm -fr /scratch
> > >
> > > And line noise of "enter" happens after
> > > the "/", who failed to think things through?
> > The shell. It's design fails to catch that and issue a warning and a confirm request, istm.
> > Your example uses the keyboard to communicate to the console through the 'shell'.
> > Very early on, before the ibm pc this was handled through the i8255, with the pc this changed.
> > reference note of modes of operation..
> > https://en.wikipedia.org/wiki/Intel_8255
> >
> > The OS kernel should not have to deal with these low level details, a specific driver should handle it.
> > Same with error detection and attempted correction. It should be handled by the specific driver.
> So for example, if an app does an fseek of a com
> Port to an earlier position, what I want is for the com port
> to be reset, which Bochs detects and does a rewind
> of the host file, then reads done from the com port to
> get to the right position. That is something that would go
> into a driver?

Yes. Bochs has provided a driver for you.
From your description, Bochs is treating the COM: as a rewindable Mag Tape device, by chance.
Generally though, COM: has a device attached that is not rewindable.
A Modem, paper tape reader RDR:, paper tape punch PUN:, a console, provide a data stream that is not rewindable. (A limited cheat would be to write the input stream to a temporary file, and perform the seek on the temporary file. The temp file would need to be in fast memory, a huge ring buffer basically).

Each of these devices require code specific to the device, a device driver.

> > > > Serial port is
> > > > now considered as a legacy (but not dead yet) communication port. It's no
> > > > longer in development and it's no longer widely used except in industrial
> > > > and business fields. What's your intended use case scenario for it, anyway?
> >
> > > Host file access is what I am after right now.
> > What is this 'Host'? Bochs? -- or are you calling your OS the host? -or- ?
> I am running pdos under Bochs on an Android phone.
>
> Pdos is the guest os and the android is the host.
>
> I thought this was standard terminology?

It is, but I didn't see mention of Android.
I didn't know you could do what you're doing on the Android phone. Kudos to you!
From what I am envisioning, yes, but the existing RomBios is that.
The lowest level is dealing with i/o ports, each device has its range of i/o ports.
You can control a device directly by programming using the port addresses of the device, but this isn't done normally. The OEM, say Dell, engineers this assignment, which likely changes from model to model.
We are talking Legacy systems here. Query 'Southbridge' chip.
https://en.wikipedia.org › wiki › Southbridge_(computing)
https://www.computerhope.com/jargon/s/soutbrid.htm

The next level up, the RomBios, is the HAL and it provides the consistent way of access.
INT 10h functions for the display .
INT 16h functions for keyboard.
INT 13h functions for disk drive access & control/status. Sub-functions AH=41h, 42h, 43h for Extended Disk Drives ie. LB addressing.

The next level up is the Bios, which resides in the OS, IO.SYS if you will.
This part is most likely to change on porting the OS to different, non ibm, hardware platforms.

> > > Specifically I am after fopen of 0x80
> > At first glance I saw fopen port 80, the http port, but you have written 80h.
> The first hard disk. Being opened as a stream.
> That's what I want the bios to provide.
>
Ahh, you are after low-level access to the HD??
Likely it supports Logical Block addressing, Extended Disk Drive functions.
Check EDD supported thru int 13h fn 41h.
Fns 42h Read, 43h Write.

NOTE!! This is not safe to do. Any write changes would/could destroy the file system on the HD

I have used a thumbdrive for hobby os work. The host is linux debian.
I boot it thru USB boot option, which treats the thumbdrive as HD 80h.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
o /dev/sdb --verify this addresses the USB Thumb drive!
o /dev/sdb1 --if so, then this addresses the first partition.

o Tranfer image to Thumb Drive:

su
********

# dd bs=512 seek=1 if=hobby-os.bin of=/dev/sdb1

104+1 records in
104+1 records out
53681 bytes (54 kB) copied, 0.00825874 s, 6.5 MB/s

This discussion pertains to Real Mode programming, Protected Mode is a different thing.

Steve

muta...@gmail.com

unread,
Aug 12, 2022, 4:35:34 PM8/12/22
to
Hi Steve.

Thanks for your reply. Nearly there.

You seem to have called int 13h etc
a hal, and io.sys another bios.

Are Hal and bios synonyms?

Let me pose the question a different way.

UEFI is what? A bios?
It is callable functions, which is what
I want from my pseudo-bios

I only want a small conceptual change to UEFI

I believe UEFI has a function to access raw disks. By sector.

I want UEFI to access raw disks by bytes.

And I want the drive to be referenced by the string 0x80.

And I want the name of the API function to be called fopen.

So I would go uefi->fopen("0x80", "r+b");

Is the new UEFI a hal, a bios, a pseudo-bios,
all of those, or none of those?

Note that UEFI is in ROM, not part of
io.sys or equivalent, but would it make a difference if it was
on disk, provided by windows, instead of being in ROM?
Surely there is no logical distinction between two
Arbitrary storage types?

Thanks.

muta...@gmail.com

unread,
Aug 12, 2022, 4:45:25 PM8/12/22
to
On Friday, August 12, 2022 at 11:57:37 PM UTC+8, s_dub...@yahoo.com wrote:
And another thing, paper tape and punched cards, thanks
to Bochs, can effectively be, after an init, like the com port, be rewound
or robotically returned from the stacker, whiteout, glue and pulp can be
applied to the material, allowed to dry, and then printed over or repunched.

The fact that that is expensive and slow on real hardware,
does not make it impossible as a concept. I think devices should have a dual nature.



Joe Monk

unread,
Aug 13, 2022, 11:49:10 AM8/13/22
to

> > > Ok, good point. I don't really understand drivers.

You do, you just dont think you do.

MVS has channels.
Channels have control units
Control Units have devices.

MVS speaks to channels thru channel control words ("API")
Channels talk to devices thru control units ("drivers")
control units drive the devices.

MVS almost never speaks directly to the device. It always talks thru the API ("ccw") to the controller, which then speaks to the device.

Think of a 3270 terminal. Read Write Read Modified Write Erase. Those are all 3270 data stream commands. When MVS wants to talk to a terminal, it sends a read or write to the channel, which then speaks to the 3x74 control unit, and the 3x74 control unit sends then 3270 data stream to the end device.

In PC terms, think of a SCSI disk. There is no native support in BIOS for a SCSI disk. The SCSI controller driver hooks the bios interrupt, and puts itself first in the chain, so all the disk interrupts go thru the SCSI driver. If it is a SCSI command, then the driver will use the interface (ASPI?) to talk to the disk. Otherwise, the driver will simply jump to the routine in ROM.

Joe

Scott Lurndal

unread,
Aug 13, 2022, 6:27:47 PM8/13/22
to
"muta...@gmail.com" <muta...@gmail.com> writes:
>On Friday, August 12, 2022 at 11:57:37 PM UTC+8, s_dub...@yahoo.com wrot=

>You seem to have called int 13h etc
>a hal, and io.sys another bios.
>
>Are Hal and bios synonyms?

HAL is an acronym for Hardware Abstraction Layer.

BIOS is a member of the set of Hardware Abstraction Layers
along with EFI, UEFI et alia.


>
>And I want the drive to be referenced by the string 0x80.

And if you have 256 drives?

Isn't a Universally Unique Identifier a far more useful way
to reference a disk?

muta...@gmail.com

unread,
Aug 14, 2022, 1:28:30 AM8/14/22
to
On Sunday, August 14, 2022 at 6:27:47 AM UTC+8, Scott Lurndal wrote:
> "muta...@gmail.com" <muta...@gmail.com> writes:
> >On Friday, August 12, 2022 at 11:57:37 PM UTC+8, s_dub...@yahoo.com wrot=
> >You seem to have called int 13h etc
> >a hal, and io.sys another bios.
> >
> >Are Hal and bios synonyms?
> HAL is an acronym for Hardware Abstraction Layer.
>
> BIOS is a member of the set of Hardware Abstraction Layers
> along with EFI, UEFI et alia.

Thanks

> >And I want the drive to be referenced by the string 0x80.
> And if you have 256 drives?
>
> Isn't a Universally Unique Identifier a far more useful way
> to reference a disk?

Sure, such a scheme would be fine.

But I'm after something with not much more
than the actual bios from around 1985.

Maybe 10 or 20% overhead.

The function fopen needs to convert 0x80
into a byte which will then be automatically used
to populate register DL for the normal int 13h
calls.

It won't be a real full c library.

It will rely on the fact that the os doesn't
need such a thing.


Joe Monk

unread,
Aug 14, 2022, 11:33:23 AM8/14/22
to

> You seem to have called int 13h etc
> a hal, and io.sys another bios.
>
> Are Hal and bios synonyms?
>
No.

A bios is supplied by the hardware manufacturer. A HAL is part of the OS Kernel. Windows, for instance, will not run on a PC without a HAL.

UEFI is a bios replacement. That is why there are no legacy INT calls in it. It is a completely new method of dealing with the CPU and hardware on the motherboard. The big problem with bios is that it is only 16-bit.

Joe


muta...@gmail.com

unread,
Aug 15, 2022, 1:31:29 AM8/15/22
to
The big problem with UEFI is that it is 64 bit
when my os and compiler are 32 bit as they
have been for 3 decades.


Joe Monk

unread,
Aug 28, 2022, 9:57:57 PM8/28/22
to

> The big problem with UEFI is that it is 64 bit
> when my os and compiler are 32 bit as they
> have been for 3 decades.

No, there is 32 bit UEFI also.

Joe

muta...@gmail.com

unread,
Aug 29, 2022, 2:44:50 PM8/29/22
to
I believe it doesn't exist on most new machines.

So all software that transitioned from
bios to 32 bit UEFI has been obsoleted
as part of a scam.

Scott Lurndal

unread,
Aug 29, 2022, 2:55:15 PM8/29/22
to
Intel has been trying for decades to get rid of support
for 16-bit real mode, protected mode and linear 32-bit mode
in their processors. Next step will likely be a pin
that if connected to Vdd will start directly in long mode,
completely bypassing the real-mode startup crapola tapdance
as it bounces through protected mode, flat mode and finally
long mode. After that, they'll get rid of the pin and make
64-bit mode the default boot mode, with possibly a mechanism
to support legacy 32-bit applications. Just think, no more
TSS, no more GDT/LDT; yay!

This is just another step along that path, which is long
overdue.

James Harris

unread,
Dec 12, 2023, 3:12:32 PM12/12/23
to
Where the processor supports 32-bit as well as 64-bit modes, 64-bit UEFI
boot code can, after loading a 32-bit OS, switch to 32-bit mode and
start the OS.

IOW you can still use your 32-bit OS via 64-bit UEFI boot.


--
James Harris


Paul Edwards

unread,
Dec 19, 2023, 4:16:28 AM12/19/23
to
If I had made my OS do 32-bit UEFI calls instead of 16-bit
BIOS calls, as advertised, then all that work would have
been wasted. 16-bit BIOS was more resilient. ie not
requiring a rewrite as 64-bit UEFI caused.

BFN. Paul.

wolfgang kern

unread,
Dec 19, 2023, 5:50:26 AM12/19/23
to
On 19/12/2023 10:16, Paul Edwards wrote:

...
> > IOW you can still use your 32-bit OS via 64-bit UEFI boot.

> If I had made my OS do 32-bit UEFI calls instead of 16-bit
> BIOS calls, as advertised, then all that work would have
> been wasted. 16-bit BIOS was more resilient. ie not
> requiring a rewrite as 64-bit UEFI caused.

16bit BIOS unfortunately exists only on a few emulators now,
but nothing on real hardware anymore.

So we are forced to take the UEFI route, I could write startup code as
64bit and then load my old 32bit OS which can switch to LM64 and back.

But even encumbering I may rewrite the whole thing as 64 bit soon.
hope to live long enough to see it working.

__
wolfgang

Paul Edwards

unread,
Dec 19, 2023, 7:55:25 PM12/19/23
to
On 19/12/23 18:50, wolfgang kern wrote:
> On 19/12/2023 10:16, Paul Edwards wrote:
>
> ...
>> > IOW you can still use your 32-bit OS via 64-bit UEFI boot.
>
>> If I had made my OS do 32-bit UEFI calls instead of 16-bit
>> BIOS calls, as advertised, then all that work would have
>> been wasted. 16-bit BIOS was more resilient. ie not
>> requiring a rewrite as 64-bit UEFI caused.
>
> 16bit BIOS unfortunately exists only on a few emulators now,
> but nothing on real hardware anymore.

Not true.

And this is why you shouldn't make your life
dependent on a Microsoft/Intel/AMD conspiracy
to force unnecessary upgrades.

I am currently using a Lenovo Kaitian N80Z
with a Zhaoxin processor which I bought (new)
a few months ago.

The BIOS is in Chinese so I needed to get a
translation from a friend/ex-colleague, but
legacy boot is supported and PDOS/386 works
perfectly fine.

I do my development on Windows 2000 running
under Virtualbox under Kylin Linux. Even
when I was using Windows 10 I worked from
the command line precisely so that I could
move machines as required.

I'm currently looking at moving to ArcaOS
for my Win32 needs.

And I stick with Win32 for a reason - that's
the reason.

A wise man (Robert De Niro in "Heat") once said "Don't let yourself get
attached to anything you are not willing to walk out on in 30 seconds
flat if you feel the heat around the corner".

BFN. Paul.

wolfgang kern

unread,
Dec 19, 2023, 9:14:43 PM12/19/23
to
good for you, but non of my clients would accept such exotic hardware.
__
wolfgang
0 new messages