serial ports galore

[muta...@gmail.com]

INT 14H allows you to specify the port in DX.

http://www.ctyme.com/intr/rb-0811.htm

It starts at 0 = COM1, meaning 65535 = COM65536.

That's a shitload of theoretical COM ports the
manufacturer can provide.

Any reason why PDOS shouldn't just accept an
fopen("COM54321", "w+b");
and see what the port has to offer?

Does it make sense to match it to internet port
numbers, so I do an fopen("COM80") or COM81
to see if any HTML terminal is trying to connect
to me?

Or should I channel such things down COM1 and
send an ATinport=80 and ATA?

I guess the objective is to have a multi-line BBS
that still enables dial-out.

BFN. Paul.

[Joe Monk]

Remember, COM ports are tied to IRQs. IRQ3/4.

There are only 4 because thats all the 8250 UART could provide, and the 8259 PIC could only give up two IRQs.

If you use a driver, such as a digiboard, then it could handle more via software interrupt...

Joe

[muta...@gmail.com]

The BIOS manufacturer can provide as many devices
behind that interrupt as they want.

The normal INT 14H is polled anyway, for read.
Not sure if something depends on an interrupt
for the write. But the manufacturer can share an
interrupt or anything else they want to do.

BFN. Paul.

[wolfgang kern]

On 16.06.2021 12:31, muta...@gmail.com wrote:
> On Wednesday, June 16, 2021 at 8:19:19 PM UTC+10, Joe Monk wrote:
>> Remember, COM ports are tied to IRQs. IRQ3/4.
>>
>> There are only 4 because thats all the 8250 UART could provide, and the 8259 PIC could only give up two IRQs.
>>
>> If you use a driver, such as a digiboard, then it could handle more via software interrupt...

> The BIOS manufacturer can provide as many devices
> behind that interrupt as they want.

NO, because I/O-ports are real hardware and there are only four
port-addresses defined and reserved for COM1..4, windoze just fakes shared.

> The normal INT 14H is polled anyway, for read.
> Not sure if something depends on an interrupt
> for the write. But the manufacturer can share an
> interrupt or anything else they want to do.

NO, it seems you have not read anything about hardware so far.

INT 14h is/was an old BIOS function which almost nobody used.
the underlying IRQs (3/4/5/7/10/11 or APIC) mean real existing
ports were connected to PIC or APIC.
__
wolfgang

[muta...@gmail.com]

On Wednesday, June 16, 2021 at 9:04:59 PM UTC+10, wolfgang kern wrote:

> > The BIOS manufacturer can provide as many devices
> > behind that interrupt as they want.

> NO, because I/O-ports are real hardware and there are only four
> port-addresses defined and reserved for COM1..4, windoze just fakes shared.

Who says there are only four port address defined
for COM ports? How many I/O ports can an 80386
address anyway?

> > The normal INT 14H is polled anyway, for read.
> > Not sure if something depends on an interrupt
> > for the write. But the manufacturer can share an
> > interrupt or anything else they want to do.

> INT 14h is/was an old BIOS function which almost nobody used.

I'm reviving it and making it a centerpiece of my OS.

This creates the abstraction I desire. 65536 COM ports.
And if an 80386 can't address that many COM ports,
an 80386+ from Korea can.

BFN. Paul.

[Rod Pemberton]

On Wed, 16 Jun 2021 00:15:29 -0700 (PDT)
"muta...@gmail.com" <muta...@gmail.com> wrote:

> Any reason why PDOS shouldn't just accept an
> fopen("COM54321", "w+b");
> and see what the port has to offer?
>

Unix and C embraces the "everything is a file"
concept. It works fairly well. One exception
is where I noted previously in regards to the
format for specifying a particular device:

You: fopen("news.eternal-september.org:119", "w+");

Me: "I see nothing specifying the device you're connecting to."

Me: e.g., "A:" (or "C:\" etc for MS-DOS)

You: "The ":" in the name is an indication that it is a URL ..."

(It's also an indication of a DOS file path.)

--
What is hidden in the ground, when found, is hidden there again?

[Scott Lurndal]

Rod Pemberton <noe...@basdxcqvbe.com> writes:
>On Wed, 16 Jun 2021 00:15:29 -0700 (PDT)
>"muta...@gmail.com" <muta...@gmail.com> wrote:
>
>> Any reason why PDOS shouldn't just accept an
>> fopen("COM54321", "w+b");
>> and see what the port has to offer?
>>
>
>Unix and C embraces the "everything is a file"
>concept. It works fairly well. One exception
>is where I noted previously in regards to the
>format for specifying a particular device:
>
>You: fopen("news.eternal-september.org:119", "w+");
>
>Me: "I see nothing specifying the device you're connecting to."
>
>Me: e.g., "A:" (or "C:\" etc for MS-DOS)
>
>You: "The ":" in the name is an indication that it is a URL ..."
>

Actually, it's not, really.

A Universal Resource Identifier (URI, of which URL is a subset):

URI = scheme:[//authority]path[?query][#fragment]

That allows:

fopen("nntp://user:pa...@news.eternal-september.org/");

(scheme nntp implies port 119).

Now, even if such syntax were supported by fopen in your
faux C90-land, consider how you would use that file descriptor;
does the application need to handle the NNTP protocol, or does
your DOS operating system handle the NNTP protocol (and any
other URI scheme that you support such as HTTP, SMTP, POP,
IMAP etc et alia) on behalf of the application.

Then, consider if you are using HTML, will the application
be responsible for formatting and displaying the HTML, or
will you delegate that to your DOS. Do you want to support
full HTML5 (including entities, UTF-8, graphics, web assembly, javascript,
image display, video playback, et alia.). Just look at firefox
or chromium for what that level of complexity invariably leads
to.

[muta...@gmail.com]

On Thursday, June 17, 2021 at 4:30:03 AM UTC+10, Scott Lurndal wrote:

> Now, even if such syntax were supported by fopen in your
> faux C90-land, consider how you would use that file descriptor;
> does the application need to handle the NNTP protocol, or does
> your DOS operating system handle the NNTP protocol (and any
> other URI scheme that you support such as HTTP, SMTP, POP,
> IMAP etc et alia) on behalf of the application.

The application needs to handle it. I'm not sure how
it makes sense for a C library (with or without the aid
of the OS) to handle the internal protocol details of
random protocols. You wouldn't need fread() you would
need some sort of complicated non-C90 function that
retrieves tokenized data.

BFN. Paul.

[Joe Monk]

> The application needs to handle it. I'm not sure how
> it makes sense for a C library (with or without the aid
> of the OS) to handle the internal protocol details of
> random protocols. You wouldn't need fread() you would
> need some sort of complicated non-C90 function that
> retrieves tokenized data.

Which is why fopen, fread, etc are not suitable for URLs. That why we have the TCPIP library of functions and use Connect() for things like this.

Joe

[muta...@gmail.com]

No, I don't see why the connection and transmission of
data can't be done using standard fopen etc functions.

After that, parsing of data can be done with standard
C90 code/libraries too.

This is the problem. Someone has made it more
complicated than it needs to be. I wonder why.

BFN. Paul.

[Joe Monk]

mission of
> data can't be done using standard fopen etc functions.
>
> After that, parsing of data can be done with standard
> C90 code/libraries too.
>
> This is the problem. Someone has made it more
> complicated than it needs to be. I wonder why.
>
> BFN. Paul.

Yeah, no. Remember, after initial connection, the ports are shifted to temporal ports (i.e ports above 1024-65535). So, there is no guarantee you will get the same temporal port two times in a row.

Joe

[muta...@gmail.com]

On Thursday, June 17, 2021 at 11:21:25 PM UTC+10, Joe Monk wrote:

> > After that, parsing of data can be done with standard
> > C90 code/libraries too.
> >
> > This is the problem. Someone has made it more
> > complicated than it needs to be. I wonder why.

> Yeah, no. Remember, after initial connection, the ports are
> shifted to temporal ports (i.e ports above 1024-65535).
> So, there is no guarantee you will get the same temporal
> port two times in a row.

You seem to be one of the people deliberately making it
more complicated than necessary, to keep software in
the hands of the elite.

I have no idea what you are talking about.

What I do know is that from PDOS/386 I am able to connect
to my BBS. There is nothing complicated about it. The only
unusual thing is the use of XON to know when to switch from
read to write mode.

BFN. Paul.

[Joe Monk]

> You seem to be one of the people deliberately making it
> more complicated than necessary, to keep software in
> the hands of the elite.
>
> I have no idea what you are talking about.

https://en.wikipedia.org/wiki/Ephemeral_port

Its the mechanism that allows a server to handle multiple clients at the same time... There is nothing complicated about it.

Joe

[muta...@gmail.com]

It is complicated.

For now I'm only interested in one connection at a time
anyway (corresponding to one physical modem) and
non-multitasking systems.

If it turns out that it is necessary for even an *application*
to be burdened by a whole lot of TCP/IP shit just to cope
with incoming or outgoing glorified modem connections,
when multi-user/multitasking is involved, so be it.

But as far as I can tell, the simple case can be handled
by a simple fopen() with everything being C90-compliant,
except for the use of ESC and XON which are
character-set-specific. And the BBS doesn't even see
the XON. Even the BBS's OS doesn't see it. Although
maybe it should. It's unclear to me what the right thing
to do is.

BFN. Paul.

[Joe Monk]

> If it turns out that it is necessary for even an *application*
> to be burdened by a whole lot of TCP/IP shit just to cope
> with incoming or outgoing glorified modem connections,
> when multi-user/multitasking is involved, so be it.
>

NNTP is a TCP application. So it needs TCP/IP.

Joe

[muta...@gmail.com]

As far as I can tell, that is not true.

I am aiming to have a news reader that does:

fopen("nntp://eternal-september.org", "r+");

and then answers the various prompts using pure C90
functions.

I'm even going to have the above running in EBCDIC
using S/370 instructions and let the modem translate
into ASCII as Eternal September is expecting.

It is true that my modem will internally use TCP/IP
instead of dial tones, but I have no reason to care
about that. Nor do I care if TCP/IP gets replaced
by XYZ, or even back to dial tones. Or be entirely
bluetooth-based.

They have managed to make what is a glorified BBS
ridiculously complicated.

BFN. Paul.

[Joe Monk]

> > NNTP is a TCP application. So it needs TCP/IP.
> As far as I can tell, that is not true.
>
> I am aiming to have a news reader that does:
>
> fopen("nntp://eternal-september.org", "r+");
>

NNTP = TCP port 119. HTTP = TCP port 80. HTTPS = TCP port 443. SSH = TCP port 22. Telnet = TCP Port 23.

"NNTP is a text-based protocol and allows for the alternating exchange between client and server: Therefore, for every NNTP inquiry, an NNTP reply is expected. For this communication the IANA (Internet Assigned Numbers Authority) has provided TCP-Port 119, which in this case is solely reserved for the transfer protocol – a TCP/IP network such as the Internet is as a result the underlying basis for the information platform. The NNTP itself has access to the application layer and for this relies directly on the TCP protocol, which has the advantage of ensuring both a secure and reliable transfer of data."

https://www.ionos.com/digitalguide/server/know-how/nntp-network-news-transfer-protocol/

Joe

[muta...@gmail.com]

Yes, and it's all a scam.

It's just a normal BBS you can dial. I could have put the
exact same text out from my own BBS way back in the
90s when I was running a BBS.

No properly-written news reader should be able to tell
the difference whether their news server was my 1990s
BBS or Eternal September in 2021.

BFN. Paul.

[Joe Monk]

> It's just a normal BBS you can dial. I could have put the
> exact same text out from my own BBS way back in the
> 90s when I was running a BBS.

here's a place for you: https://www.reddit.com/r/bbs/

Joe

[muta...@gmail.com]

Thanks! I have made a post.

BFN. Paul.

[Rod Pemberton]

On Thu, 17 Jun 2021 15:09:48 -0700 (PDT)
"muta...@gmail.com" <muta...@gmail.com> wrote:

<snip>

> It is true that my modem will internally use TCP/IP

No.

A modem won't use TCP/IP for anything. You may
use the SLIP or PPP protocol for an IP connection.

[muta...@gmail.com]

On Friday, June 18, 2021 at 1:39:47 PM UTC+10, Rod Pemberton wrote:

> > It is true that my modem will internally use TCP/IP

> No.
>
> A modem won't use TCP/IP for anything. You may
> use the SLIP or PPP protocol for an IP connection.

Buy my modem then. It does TCP/IP. It's quite
bulky though, but the Japanese will make short
work of that.

BFN. Paul.

[Scott Lurndal]

Technically, NNTP can be carried by any underlying connection-oriented
lossless protocol.

[Joe Monk]

NNTP is also specified to be UTF-8, which is a superset of ASCII.

"This specification extends NNTP from US-ASCII [ANSI1986] to UTF-8
[RFC3629]. Except in the two areas discussed below, UTF-8 (which is
a superset of US-ASCII) is mandatory, and implementations MUST NOT
use any other encoding."

https://datatracker.ietf.org/doc/html/rfc3977

Joe

[muta...@gmail.com]

On Saturday, June 19, 2021 at 12:01:52 AM UTC+10, Joe Monk wrote:

> NNTP is also specified to be UTF-8, which is a superset of ASCII.
>
> "This specification extends NNTP from US-ASCII [ANSI1986] to UTF-8

I use the non-extended NNTP that predates UTF-8 even existing.

BFN. Paul.

[Joe Monk]

> I use the non-extended NNTP that predates UTF-8 even existing.

And I have a bridge in Brooklyn that needs a new owner.

Joe

[wolfgang kern]

On 19.06.2021 01:02, Joe Monk wrote:

>> I use the non-extended NNTP that predates UTF-8 even existing.

> And I have a bridge in Brooklyn that needs a new owner.

Oh yes, I'm a passionate abandoned bridge collector, LMFAO.
__
wolfgang