[hercules-os380] 32-bit chips

[[e-mail] [hercules-os380]]

I am busy working on PDOS/386 and making
great progress. I have a question about
chips.

If we are rerunning computer history, is there
any need for both 80386 and S/390 instruction
sets? Can't everyone just use one or the other?
Did IBM patent their instructions or something
to inspire others to create their own instructions?

Regardless of that, I am interested in at what
point a cheap 80386 could have been made.
I'm just after 32-bit processing, as a replacement
for the 16-bit processing of the 8086. I don't
need virtual memory, I don't need memory
protection, I don't need v8086 mode, I don't
want segment registers, I just want a simple
version of the 80386, as near as possible to
being a drop-in replacement for the 8086.

Was there some technical barrier preventing
people from making such a CPU? Did Intel
have patents over the 8086 instruction set
preventing other manufacturers from
producing such a chip?

Thanks. Paul.

[[e-mail] [hercules-os380]]

(possible double-post, due to me this time)

Post by ***@yahoo.com.au [hercules-os380]
If we are rerunning computer history,

E.g. after a nuclear holocaust.

Post by ***@yahoo.com.au [hercules-os380]
want segment registers, I just want a simple
version of the 80386, as near as possible to
being a drop-in replacement for the 8086.

Also I expect software vendors to ship
both a 16-bit and 32-bit version of all
their software.

And we can assume that 50% of people
can afford an 80386 while the other 50%
can only afford an 8086.

And Bill Gates has created two versions
of MSDOS at the same time - one for
8086 and one for 80386.

That's actually partly my question - what
would a 32-bit MSDOS look like.

BFN. Paul.

[[e-mail] [hercules-os380]]

BTW, I've just realized something else.

I used to regularly check the price of memory
so that I could find out how much it would cost
to get a full 4 GiB of memory. E.g. the cost of
a car. And I used to dream of owning a
computer with fully populated memory.

Now I know what I was doing - we needed
computers to actually be shipped with 4 GiB
or more of memory to force computer
scientists to deal with the issue of what to
do when we ran out of 32 bits.

And I wanted them to show their cards first.
I wanted to see what the industry would
come up with before coming up with my
own version of how things should work.
I'm still formulating my version by the way,
so I don't have anything definitive yet.
E.g. I'm still struggling to try to answer
what impact, if any, the x64's decision to
not allow user-mode AMODE switching
has had compared to IBM's design which
allows it.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
E.g. I'm still struggling to try to answer
what impact, if any, the x64's decision to
not allow user-mode AMODE switching
has had compared to IBM's design which
allows it.

I'm inclined to say that in an ideal world,
the only AMODEs would be 16 (tiny
memory model only), 32 and 64, and an
application is compiled for one of those
only, and cannot do anything logical by
switching AMODEs, so there should be
no need for the application to do that.

The only exception I can see is when
a 64-bit program calls a 32-bit operating
system routine (not an SVC), and the
operating system hasn't been updated
to do a mode change itself, because it's
still a 32-bit operating system. But I
would write this off and say that the
32-bit operating system needs to be
minimally modified to allow access to
ATB memory, and to start the load
module in AM64, so the I/O routines
should be updated with a BSM at the
same time, rather than expecting every
application to do that.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

Just a question... the 8080 with the S-100 bus was far more popular at the
time intel introduced the 8086. Why are you trying to only encapsulate the
8086?

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

Joe

Post by ***@yahoo.com.au [hercules-os380]
(possible double-post, due to me this time)

Post by ***@yahoo.com.au [hercules-os380]
If we are rerunning computer history,

E.g. after a nuclear holocaust.

Post by ***@yahoo.com.au [hercules-os380]
want segment registers, I just want a simple
version of the 80386, as near as possible to
being a drop-in replacement for the 8086.

Also I expect software vendors to ship
both a 16-bit and 32-bit version of all
their software.
And we can assume that 50% of people
can afford an 80386 while the other 50%
can only afford an 8086.
And Bill Gates has created two versions
of MSDOS at the same time - one for
8086 and one for 80386.
That's actually partly my question - what
would a 32-bit MSDOS look like.
BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]
Just a question... the 8080 with the S-100 bus
was far more popular at the time intel introduced
the 8086. Why are you trying to only encapsulate
the 8086?

I don't really understand the question about
encapsulation. I'm trying to chart a path
through history that includes a cut-down
80386, and a version of MSDOS to run
on it. Everything will then revolve around
that.

The same as I chose to fix the C language
and then work everything else out around
that.

A bit like the Heisenberg uncertainty principle.
I'm trying to fix one thing and then see what
makes sense, with that as a given.

Note that trying to get C to work as best as
possible for MVS is what created MVS/380.
I had all this generated code, none of it
which was messing with the high 8 bits of
addresses that I could see, so I was
wondering what the barrier was to having
that code run as 31-bit.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

It appears to me that you are using x86 because the IBM PC made that
popular.

My point is that at the time of the introduction of the IBM PC, there were
already thousands of PCs running on the 8080, and running Microsoft Basic.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]
Just a question... the 8080 with the S-100 bus
was far more popular at the time intel introduced
the 8086. Why are you trying to only encapsulate
the 8086?

I don't really understand the question about
encapsulation. I'm trying to chart a path
through history that includes a cut-down
80386, and a version of MSDOS to run
on it. Everything will then revolve around
that.
The same as I chose to fix the C language
and then work everything else out around
that.
A bit like the Heisenberg uncertainty principle.
I'm trying to fix one thing and then see what
makes sense, with that as a given.
Note that trying to get C to work as best as
possible for MVS is what created MVS/380.
I had all this generated code, none of it
which was messing with the high 8 bits of
addresses that I could see, so I was
wondering what the barrier was to having
that code run as 31-bit.
BFN. Paul.

['Fernando M. Roxo da Motta' [e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]
It appears to me that you are using x86 because the IBM PC made that
popular.
My point is that at the time of the introduction of the IBM PC, there
were already thousands of PCs running on the 8080, and running
Microsoft Basic.

I think that most microcomputers were running on a Z80, a Motorola
microprocessor (e.g. 6502). That is a basically two instruction set
world. There were others less used, but important anyway, like the
MC68k, and TMS9900.

Post by Joe Monk ***@gmail.com [hercules-os380]
Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]
Just a question... the 8080 with the S-100 bus
was far more popular at the time intel introduced
the 8086. Why are you trying to only encapsulate
the 8086?

I don't really understand the question about
encapsulation. I'm trying to chart a path
through history that includes a cut-down
80386, and a version of MSDOS to run
on it. Everything will then revolve around
that.
The same as I chose to fix the C language
and then work everything else out around
that.
A bit like the Heisenberg uncertainty principle.
I'm trying to fix one thing and then see what
makes sense, with that as a given.
Note that trying to get C to work as best as
possible for MVS is what created MVS/380.
I had all this generated code, none of it
which was messing with the high 8 bits of
addresses that I could see, so I was
wondering what the barrier was to having
that code run as 31-bit.
BFN. Paul.

Roxo

--
---------------- Non luctari, ludare -------------------+ WYSIWYG
Fernando M. Roxo da Motta <***@roxo.org> | Editor?
Except where explicitly stated I speak on my own behalf.| VI !!
PU5RXO | I see text,
------------ Quis custodiet ipsos custodes?-------------+ I get text!

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]
It appears to me that you are using x86 because
the IBM PC made that popular.

I don't currently have the knowledge required
to question instruction sets themselves.
Instead, I have assumed that both the
S/390 and 80386 instruction sets were both
required and both perfect for 32-bit
processing, and then made everything else
revolve around that.

That is where we ended up with 32-bit
computing. The world settled on those
two instruction sets (and more recently
ARM popped up and I haven't spent
any time on that, still sorting out the
OSes that ran/run on S/390 and 80386).

So I want to know logically how we ended
up with such a mess with MSDOS only
being 16-bit instead of all software being
targeted to both 16-bit and 32-bit MSDOS.

BFN. Paul.

['Dave Wade' [e-mail] [hercules-os380]]

-----Original Message-----
Sent: 16 July 2018 03:19
Subject: Re: [hercules-os380] Re: 32-bit chips

Post by Joe Monk ***@gmail.com [hercules-os380]
It appears to me that you are using x86 because the IBM PC made that
popular.

I don't currently have the knowledge required to question instruction sets
themselves.
Instead, I have assumed that both the
S/390 and 80386 instruction sets were both required and both perfect for 32-
bit processing, and then made everything else revolve around that.
That is where we ended up with 32-bit
computing. The world settled on those
two instruction sets (and more recently
ARM popped up and I haven't spent
any time on that, still sorting out the
OSes that ran/run on S/390 and 80386).
So I want to know logically how we ended up with such a mess with MSDOS
only being 16-bit instead of all software being targeted to both 16-bit and 32-
bit MSDOS.
BFN. Paul.

Same reasons as we have VHS rather than BetaMax. OS/2 would have solved this, but being properly engineered it was hard to install.
Microsoft produced Windows/95 which was really a DOS extender and the rest is history.
ARM is interesting because as Steve Furber one of the founders of ARM explained when talking about the birth of ARM at a recent British Computing Society Computer Conservation Society group meeting.

"We realized that having a "nice" instruction set wasn't important, no one was going to write machine code"



Dave

------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[[e-mail] [hercules-os380]]

Post by 'Dave Wade' ***@gmail.com [hercules-os380]

So I want to know logically how we ended up with such a mess with MSDOS
only being 16-bit instead of all software being targeted to both 16-bit and 32-
bit MSDOS.

OS/2 would have solved this,

Solved it how? It didn't really provide a 32-bit
version of DOS, did it? It invented a new API.

Post by 'Dave Wade' ***@gmail.com [hercules-os380]
Microsoft produced Windows/95 which was
really a DOS extender

Wow, thanks for that nugget.

BFN. Paul.

['Dave Wade' [e-mail] [hercules-os380]]

-----Original Message-----
Sent: 16 July 2018 08:07
Subject: RE: [hercules-os380] Re: 32-bit chips

Post by 'Dave Wade' ***@gmail.com [hercules-os380]

So I want to know logically how we ended up with such a mess with
MSDOS only being 16-bit instead of all software being targeted to
both 16-bit and 32- bit MSDOS.

OS/2 would have solved this,

Solved it how? It didn't really provide a 32-bit version of DOS, did it? It
invented a new API.

If its not 16-bit then isn't it a new API?

Post by 'Dave Wade' ***@gmail.com [hercules-os380]
Microsoft produced Windows/95 which was really a DOS extender

Wow, thanks for that nugget.

Yes but it sold and was used. If its good enough for the job, and it was, then that’s what gets used..

BFN. Paul.

Dave

------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[[e-mail] [hercules-os380]]

Post by 'Dave Wade' ***@gmail.com [hercules-os380]

Solved it how? It didn't really provide a 32-bit version of DOS, did it? It
invented a new API.

If its not 16-bit then isn't it a new API?

Good question. That's exactly what I'm trying
to solve with PDOS/386. It is meant to be a
32-bit version of the 16-bit API. No changes
to the API unless technically required.

So below I have PosReadFile(). Applications
are encouraged to call PosReadFile() by
name, but the interrupt still works as well.

Note that this is just my initial cut. It hasn't
been peer-reviewed, but hopefully the
knowledgeable people here can do that.

It's a very fundamental question - if Bill
Gates had created a 32-bit MSDOS at
the same time as the 16-bit MSDOS,
then what would MSDOS application
programmers have coded so that their
software worked on both versions of
MSDOS?

BFN. Paul.



void PosReadFile(int fh, void *data, size_t bytes, size_t *readbytes)
{
union REGS regsin;
union REGS regsout;
struct SREGS sregs;

regsin.h.ah = 0x3f;
#ifdef __32BIT__
regsin.d.ebx = (unsigned int)fh;
regsin.d.ecx = (unsigned int)bytes;
regsin.d.edx = (unsigned int)data;
#else
regsin.x.bx = (unsigned int)fh;
regsin.x.cx = (unsigned int)bytes;
sregs.ds = FP_SEG(data);
regsin.x.dx = FP_OFF(data);
#endif
int86x(0x21, &regsin, &regsout, &sregs);
if (regsout.x.cflag)
{
*readbytes = 0;
}
else
{
#ifdef __32BIT__
*readbytes = regsout.d.eax;
#else
*readbytes = regsout.x.ax;
#endif
}
return;
}

[Joe Monk [e-mail] [hercules-os380]]

"It's a very fundamental question - if Bill
Gates had created a 32-bit MSDOS at
the same time as the 16-bit MSDOS,
then what would MSDOS application
programmers have coded so that their
software worked on both versions of
MSDOS?"

Tim Paterson wrote MS-DOS, not Bill Gates. At the time, they were
concentrated on the 8086 processor, which has slightly different
characteristics than the slower 8088.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by 'Dave Wade' ***@gmail.com [hercules-os380]

Solved it how? It didn't really provide a 32-bit version of DOS, did

it? It

Post by 'Dave Wade' ***@gmail.com [hercules-os380]

invented a new API.

If its not 16-bit then isn't it a new API?

Good question. That's exactly what I'm trying
to solve with PDOS/386. It is meant to be a
32-bit version of the 16-bit API. No changes
to the API unless technically required.
So below I have PosReadFile(). Applications
are encouraged to call PosReadFile() by
name, but the interrupt still works as well.
Note that this is just my initial cut. It hasn't
been peer-reviewed, but hopefully the
knowledgeable people here can do that.
It's a very fundamental question - if Bill
Gates had created a 32-bit MSDOS at
the same time as the 16-bit MSDOS,
then what would MSDOS application
programmers have coded so that their
software worked on both versions of
MSDOS?
BFN. Paul.
void PosReadFile(int fh, void *data, size_t bytes, size_t *readbytes)
{
union REGS regsin;
union REGS regsout;
struct SREGS sregs;
regsin.h.ah = 0x3f;
#ifdef __32BIT__
regsin.d.ebx = (unsigned int)fh;
regsin.d.ecx = (unsigned int)bytes;
regsin.d.edx = (unsigned int)data;
#else
regsin.x.bx = (unsigned int)fh;
regsin.x.cx = (unsigned int)bytes;
sregs.ds = FP_SEG(data);
regsin.x.dx = FP_OFF(data);
#endif
int86x(0x21, &regsin, &regsout, &sregs);
if (regsout.x.cflag)
{
*readbytes = 0;
}
else
{
#ifdef __32BIT__
*readbytes = regsout.d.eax;
#else
*readbytes = regsout.x.ax;
#endif
}
return;
}

[Joe Monk [e-mail] [hercules-os380]]

"It's a very fundamental question - if Bill
Gates had created a 32-bit MSDOS at
the same time as the 16-bit MSDOS,
then what would MSDOS application
programmers have coded so that their
software worked on both versions of
MSDOS?"

What you're forgetting is that DOS preceded Windows by a number of years.
There was no need (and no vision) for a 32-bit GUI at the time.

In fact, until Windows 98 SE, the "startup disks" were DOS. You boot and
ran the computer from them, without ever invoking windows. So, the computer
was booted by a 16-bit OS, and didn't go into 32-bit mode until Windows was
launched.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by 'Dave Wade' ***@gmail.com [hercules-os380]

Solved it how? It didn't really provide a 32-bit version of DOS, did

it? It

Post by 'Dave Wade' ***@gmail.com [hercules-os380]

invented a new API.

If its not 16-bit then isn't it a new API?

Good question. That's exactly what I'm trying
to solve with PDOS/386. It is meant to be a
32-bit version of the 16-bit API. No changes
to the API unless technically required.
So below I have PosReadFile(). Applications
are encouraged to call PosReadFile() by
name, but the interrupt still works as well.
Note that this is just my initial cut. It hasn't
been peer-reviewed, but hopefully the
knowledgeable people here can do that.
It's a very fundamental question - if Bill
Gates had created a 32-bit MSDOS at
the same time as the 16-bit MSDOS,
then what would MSDOS application
programmers have coded so that their
software worked on both versions of
MSDOS?
BFN. Paul.
void PosReadFile(int fh, void *data, size_t bytes, size_t *readbytes)
{
union REGS regsin;
union REGS regsout;
struct SREGS sregs;
regsin.h.ah = 0x3f;
#ifdef __32BIT__
regsin.d.ebx = (unsigned int)fh;
regsin.d.ecx = (unsigned int)bytes;
regsin.d.edx = (unsigned int)data;
#else
regsin.x.bx = (unsigned int)fh;
regsin.x.cx = (unsigned int)bytes;
sregs.ds = FP_SEG(data);
regsin.x.dx = FP_OFF(data);
#endif
int86x(0x21, &regsin, &regsout, &sregs);
if (regsout.x.cflag)
{
*readbytes = 0;
}
else
{
#ifdef __32BIT__
*readbytes = regsout.d.eax;
#else
*readbytes = regsout.x.ax;
#endif
}
return;
}

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
It's a very fundamental question - if Bill
Gates had created a 32-bit MSDOS at
the same time as the 16-bit MSDOS,
then what would MSDOS application
programmers have coded so that their
software worked on both versions of
MSDOS?"

What you're forgetting is that DOS preceded
Windows by a number of years. There was no
need (and no vision) for a 32-bit GUI at the time.

But if the need for the GUI had been delayed,
and people were clamoring for a 32-bit version
of plain MSDOS (no GUI), what would it look like?

I'm interested in filling in that hole in computer
history.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"I'm interested in filling in that hole in computer
history."

There's no hole. Windows 2.x was 16-bit along with DOS.

Windows 3.0 was the first GUI that could run 32-bit in 386 enhanced mode,
but it also ran in 16-bit, 286 protected mode.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
It's a very fundamental question - if Bill
Gates had created a 32-bit MSDOS at
the same time as the 16-bit MSDOS,
then what would MSDOS application
programmers have coded so that their
software worked on both versions of
MSDOS?"

What you're forgetting is that DOS preceded
Windows by a number of years. There was no
need (and no vision) for a 32-bit GUI at the time.

But if the need for the GUI had been delayed,
and people were clamoring for a 32-bit version
of plain MSDOS (no GUI), what would it look like?
I'm interested in filling in that hole in computer
history.
BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
I'm interested in filling in that hole in computer
history.

There's no hole. Windows 2.x was 16-bit along with DOS.

There is a hole. MSDOS never came in a 32-bit
flavor. Which is difficult for me, because normally
I just copy someone else's API. But this time
there is nothing to copy. Well, as far as possible
I can copy the 16-bit interface.

BTW, I've just released a dev snapshot (floppy
disk images) of PDOS/386 here:

https://sourceforge.net/projects/pdos/files/pdos/pdos-stage157.zip/download

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"There is a hole. MSDOS never came in a 32-bit
flavor."

Right, because there was NO NEED for it, and thus no hole.

When the leap was made from 16/32-bit hybrid in Windows to 32-bit only, DOS
was discontinued as the boot OS ... Windows NT didn't need it to boot.

The fact that you want a 32-bit MS-DOS today doesn't mean that there was a
hole back then.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
I'm interested in filling in that hole in computer
history.

There's no hole. Windows 2.x was 16-bit along with DOS.

There is a hole. MSDOS never came in a 32-bit
flavor. Which is difficult for me, because normally
I just copy someone else's API. But this time
there is nothing to copy. Well, as far as possible
I can copy the 16-bit interface.
BTW, I've just released a dev snapshot (floppy
https://sourceforge.net/projects/pdos/files/pdos/pdos-
stage157.zip/download
BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]
The fact that you want a 32-bit MS-DOS today
doesn't mean that there was a hole back then.

There was a hole, and to some extent it was
filled by DOS extenders. But as someone
else said (and I took to heart), "until DOS is
made 32-bit, DOS extenders are just a
kludge". That's the hole I want to fill. Also
it's the simplest 32-bit OS I can produce,
which is where I would like to start as far
as public domain operating systems go.

BFN. Paul.

['Bill Turner, WB4ALM' [e-mail] [hercules-os380]]

Paul, why do you want to redefine the world as seen only through the
eyes of MicroSoft and the "ms-dos/windows" operating systems?

There were (and still are) other operating systems and hardware
architectures that were far more powerful than that inflicted on the
world by the "IBM PC" and "Microsoft".

Those two "designs" have created many of the software/hardware problems
that have had to be corrected later on with weird addressing issues like
"segment registers", etc...
The trade press at the time did not help any, because the only articles
that were printed by the "big magazines" were often restricted to the
8080/8086/8088/80x26
hardware based environments.

Unfortunately, the basic design of the "IBM PC" was presented as the
"BEST" way to build a system, and Engineers that were to lazy to
research the issues, believed it.

And so a simple contractual statement like, "purchased licenses will be
verified against the production count of all computer systems
manufactured" prevented other operating systems from being presented to
the general public. After all, why would a manufacture purchase and
offer an alternate operating system when he is REQUIRED to purchase a
copy of "MS-DOS/or Windows" anyway for every machine they manufacture...

/s/ Bill Turner, wb4alm

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]
The fact that you want a 32-bit MS-DOS today
doesn't mean that there was a hole back then.

There was a hole, and to some extent it was
filled by DOS extenders. But as someone
else said (and I took to heart), "until DOS is
made 32-bit, DOS extenders are just a
kludge". That's the hole I want to fill. Also
it's the simplest 32-bit OS I can produce,
which is where I would like to start as far
as public domain operating systems go.
BFN. Paul.

[[e-mail] [hercules-os380]]

Post by 'Bill Turner, WB4ALM' ***@arrl.net [hercules-os380]
Paul, why do you want to redefine the world
as seen only through the eyes of MicroSoft
and the "ms-dos/windows" operating systems?

It is 80386+ chips that we are all using, for
better or for worse, and with that installed
hardware base I would like what is nearly
the only public domain operating system
in existence to take things one at a time
because I am not claiming to be very
knowledgeable about this. I learn by doing.

At the moment I am trying to do something
that should be relatively simple - take the
relatively simple 16-bit MSDOS and make
a 32-bit equivalent so that I don't have the
same memory constraints. Something
similar to MVS/380.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"At the moment I am trying to do something
that should be relatively simple - take the
relatively simple 16-bit MSDOS and make
a 32-bit equivalent so that I don't have the
same memory constraints. Something
similar to MVS/380."

Why dont you just take the FreeDOS source code and compile it for 32-bit?

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by 'Bill Turner, WB4ALM' ***@arrl.net [hercules-os380]
Paul, why do you want to redefine the world
as seen only through the eyes of MicroSoft
and the "ms-dos/windows" operating systems?

It is 80386+ chips that we are all using, for
better or for worse, and with that installed
hardware base I would like what is nearly
the only public domain operating system
in existence to take things one at a time
because I am not claiming to be very
knowledgeable about this. I learn by doing.
At the moment I am trying to do something
that should be relatively simple - take the
relatively simple 16-bit MSDOS and make
a 32-bit equivalent so that I don't have the
same memory constraints. Something
similar to MVS/380.
BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
At the moment I am trying to do something
that should be relatively simple - take the
relatively simple 16-bit MSDOS and make
a 32-bit equivalent so that I don't have the
same memory constraints. Something
similar to MVS/380.

Why dont you just take the FreeDOS source
code and compile it for 32-bit?

That's certainly the right sentiment.

I can't use FreeDOS because it is copyrighted,
and I'm after a public domain version. But I have
already written a 16-bit version of Freedos/MSDOS.
called PDOS/86 or PDOS-16.

What are you expectations as to what would
happen if I took the PDOS-16 code and
recompiled it with a 32-bit compiler?

And what would you suggest that PDOS
applications use as an interface so that
they work on both PDOS-16 and PDOS-32?

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
And what would you suggest that PDOS
applications use as an interface so that
they work on both PDOS-16 and PDOS-32?

Also, do you see the need for the equivalent
of GETMAIN LOC=24, and should this call
be back-ported to PDOS-16?

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
And what would you suggest that PDOS
applications use as an interface so that
they work on both PDOS-16 and PDOS-32?

And a future PDOS-64 too.

And the same question applies to MVS
programs going from 31/32-bit to 64-bit.
Can the API handle both?

Post by ***@yahoo.com.au [hercules-os380]
Also, do you see the need for the equivalent
of GETMAIN LOC=24, and should this call
be back-ported to PDOS-16?

And indeed, does SVC 120 only exist on
MVS 3.8j because of the realization of a
need for such an API on MVS/XA, and it
was backported?

In the same way that all my applications
on MVS 3.8j are dependent on a back-ported
SVC 120, it may be the case that my
16-bit DOS applications only work on
the updated PDOS-16, not real MSDOS.

BFN. Paul.

[Mike Schwab [e-mail] [hercules-os380]]

Here is the interface to replicate. https://en.wikipedia.org/wiki/Native_API

Post by ***@yahoo.com.au [hercules-os380]

Post by 'Bill Turner, WB4ALM' ***@arrl.net [hercules-os380]
Paul, why do you want to redefine the world
as seen only through the eyes of MicroSoft
and the "ms-dos/windows" operating systems?

It is 80386+ chips that we are all using, for
better or for worse, and with that installed
hardware base I would like what is nearly
the only public domain operating system
in existence to take things one at a time
because I am not claiming to be very
knowledgeable about this. I learn by doing.
At the moment I am trying to do something
that should be relatively simple - take the
relatively simple 16-bit MSDOS and make
a 32-bit equivalent so that I don't have the
same memory constraints. Something
similar to MVS/380.
BFN. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[[e-mail] [hercules-os380]]

Here is the interface to replicate. https://en.wikipedia.org/wiki/Native_API

No, that is not a general use API, and in
particular it is not MSDOS-compatible which
is my first port of call for the public domain
operating systems.

BFN. Paul.

[Mike Schwab [e-mail] [hercules-os380]]

16 big: DOS -> WIn95 -> Win ME

32 bit: Win NT -> WinXP -> Win 10

64 bit: Win XP -> -> Win 10

Post by Joe Monk ***@gmail.com [hercules-os380]
"There is a hole. MSDOS never came in a 32-bit
flavor."
Right, because there was NO NEED for it, and thus no hole.
When the leap was made from 16/32-bit hybrid in Windows to 32-bit only,
DOS was discontinued as the boot OS .... Windows NT didn't need it to boot.
The fact that you want a 32-bit MS-DOS today doesn't mean that there was a
hole back then..
Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
I'm interested in filling in that hole in computer
history.

There's no hole. Windows 2.x was 16-bit along with DOS.

There is a hole. MSDOS never came in a 32-bit
flavor. Which is difficult for me, because normally
I just copy someone else's API. But this time
there is nothing to copy. Well, as far as possible
I can copy the 16-bit interface.
BTW, I've just released a dev snapshot (floppy
https://sourceforge.net/projects/pdos/files/pdos/pdos-stage157.zip/download
BFN. Paul.

[Vince Coen [e-mail] [hercules-os380]]

First Microsoft did not create MSDOS as it was bought in to complete
with CPM which we distributed outside the USA.

Second it was release well prior to 80x86 chips in fact only 8080 and
Z80 was available so as a 8 / 16 bit (word) systems.

Third MS was developing having bought in Windows as v1.
Versions prior to v3 where unusable.
v3.0 was likewise but nowhere as bad and yes and as the European
Distributor for MS in the 70 and 80's we had the first samples of
executables from the programmers.

v3.1 was the first release that we issued to the rest of the world for
running on many brands of micro computers in the late 70's.

This worked with chips from 8080, 8086 and Z80A & B.

Yes, well before IBM bought out their PC!

Early 80386 had their problems hence the reason why companies like
Cromemco used the 68k chip sets as a option instead of Z80s.
They were not the only one!

Full 16 bit O/S's did not start appearing till much later with the
advent of Win 98 as 95 was a bit of a disaster but still an upgrade
from  v3.1 which has remained with MS in that every other version is a
bit of a test bed and not to useful.

Even for early Unix based systems did not really fully support the max
capacity of the chip sets for a few years at least until the C and
assembler developers starting issuing working 16 bit and later 32 bit
(etc) versions so that the Unix sources could be compiled and it was a
year or more before they could handle dual mode working.

Your memory is a wee bit short - history wise.


Vince

Vincent Coen
Formally MD - MPI (Microcomputer Products International) from 1975 to 1985.

Post by ***@yahoo.com.au [hercules-os380]

Post by 'Dave Wade' ***@gmail.com [hercules-os380]

Solved it how? It didn't really provide a 32-bit version of DOS,

did it? It

Post by 'Dave Wade' ***@gmail.com [hercules-os380]

invented a new API.

If its not 16-bit then isn't it a new API?

Good question. That's exactly what I'm trying
to solve with PDOS/386. It is meant to be a
32-bit version of the 16-bit API. No changes
to the API unless technically required.
So below I have PosReadFile(). Applications
are encouraged to call PosReadFile() by
name, but the interrupt still works as well.
Note that this is just my initial cut. It hasn't
been peer-reviewed, but hopefully the
knowledgeable people here can do that.
It's a very fundamental question - if Bill
Gates had created a 32-bit MSDOS at
the same time as the 16-bit MSDOS,
then what would MSDOS application
programmers have coded so that their
software worked on both versions of
MSDOS?

[[e-mail] [hercules-os380]]

Post by 'Dave Wade' ***@gmail.com [hercules-os380]
We realized that having a "nice" instruction set
wasn't important, no one was going to write
machine code

We should probably expand this thread to
include an overview of the whole computer
industry. Where we are now and what we
can do about it.

I would like to see hobbyists have a place
to contribute code to that isn't under a
license. There are people in the world
who are perfectly happy to make their
code public domain instead of virus
licensed, but there is nowhere for them
to do so. I would like to harness that
energy. I heard there was a time in the
computer world where *everything*
was public domain.

And I would like to see enterprises like
Computer Associates taking the public
domain code and converting into
commercial quality code that can
compete with IBM.

But there's probably more hobbyists
interested in x86 systems that they
actually own, so PDOS/386 would be
the best place to start rather than
PDOS/3x0 or MVS/380. But hopefully
success and concepts on PDOS/386
could breathe life into PDOS/3x0. And
concepts from MVS/380 and z/OS can
influence PDOS/386. Note that it already
has, which is why both PDOS/386 and
its applications run in the same flat
address space that MVS/380 has, no
use of segment registers. And now
the equivalent of GETMAIN has a LOC=20
to obtain BTL storage the same way as
MVS/XA et al, so that they can provide
storage to the BIOS services.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
I would like to see hobbyists have a place
to contribute code to that isn't under a
license.

Basically at the same time that MSDOS was
in widespread use, there should have been
a public domain rival being built by hobbyists.
Hobbyists were already contributing code to
other projects.

PDOS/386 is currently about 22,000 lines of
code and that includes LFN support (recently
added by Alica). But there is an additional
30,000 lines in PDPCLIB (that includes work
done on other platforms like MVS). PDOS/3x0
is 5000 lines.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
Basically at the same time that MSDOS was
in widespread use, there should have been
a public domain rival being built by hobbyists.

Did the writers of MSDOS have access to
an 8086 emulator in order to debug it? Or a
remote debugger?

PDOS/386 was developed and working on
real hardware for some time before I installed
an emulator (Bochs). I was lucky I never
experienced a bug that couldn't be solved
by adding printfs and rebooting a lot. Until
recently when my luck ran out, but
debugging at the assembler level under
Bochs was doable.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"Did the writers of MSDOS have access to
an 8086 emulator in order to debug it? Or a
remote debugger?"

You didn't read my earlier post. Tim Paterson worked for SCP (Seattle
Computer Products) and had his own 8086 real hardware. He wrote 86-DOS on
it, then when it was sold to Microsoft, he was hired by Microsoft.

All of 86-DOS/MS-DOS was written on real hardware, no emulators.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
Basically at the same time that MSDOS was
in widespread use, there should have been
a public domain rival being built by hobbyists.

Did the writers of MSDOS have access to
an 8086 emulator in order to debug it? Or a
remote debugger?
PDOS/386 was developed and working on
real hardware for some time before I installed
an emulator (Bochs). I was lucky I never
experienced a bug that couldn't be solved
by adding printfs and rebooting a lot. Until
recently when my luck ran out, but
debugging at the assembler level under
Bochs was doable.
BFN. Paul.

[Mike Schwab [e-mail] [hercules-os380]]

Intel created the 4004 and built up from there. CPM was running on
the 8080 and above. When the IBM PC came out you bought the DOS or
CPM/86 separate, ran in 20 bit addresses. Win 95 was just a different
user interface. Win NT went with a 32 bit O/S.

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]
It appears to me that you are using x86 because
the IBM PC made that popular.

I don't currently have the knowledge required
to question instruction sets themselves.
Instead, I have assumed that both the
S/390 and 80386 instruction sets were both
required and both perfect for 32-bit
processing, and then made everything else
revolve around that.
That is where we ended up with 32-bit
computing. The world settled on those
two instruction sets (and more recently
ARM popped up and I haven't spent
any time on that, still sorting out the
OSes that ran/run on S/390 and 80386).
So I want to know logically how we ended
up with such a mess with MSDOS only
being 16-bit instead of all software being
targeted to both 16-bit and 32-bit MSDOS.
BFN. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[Joe Monk [e-mail] [hercules-os380]]

"So I want to know logically how we ended
up with such a mess with MSDOS only
being 16-bit instead of all software being
targeted to both 16-bit and 32-bit MSDOS."

Ah. I see.

Well you need to look at the history of MS-DOS.

Early on, we had CP/M which was 8-bit and ran on the 8080. There was a
16-bit version under development for the then in development 8086, but
Digital Research was late in delivering.

Subsequently, when Intel announced the 8086, a company in Seattle ...
Seattle Computer Products, created a spin-off of 8-bit CP/M called 86-DOS.
86-DOS was 16-bit. Seattle Computer Products created 86-DOS to run on its
8086 computer kit. (If you compare a CP/M manual and an MS-DOS manual, you
will be stunned at the similarity of commands.)

Subsequently, when IBM approached Microsoft to write the OS for its then
secret IBM PC which used the 8088, MS went to SCP, whom it had already
licensed 86-DOS from, acquired the complete rights to 86-DOS, and also
hired the developer, Tim Paterson. Microsoft subsequently rebadged 86-DOS
as MS-DOS, and of course IBM PC DOS.

So, that's how it happened. A company in Seattle created a 16-bit spinoff
of CP/M, and that spinoff was sold to MS to become MS-DOS.

MS-DOS was never 32-bit. From Windows NT and up, there has been a 32-bit
DOS emulation, but it is integrated into Windows NT, it is not a separate,
standalone product as it was thru Windows 98 SE, where it could be booted
standalone from the OS.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]
It appears to me that you are using x86 because
the IBM PC made that popular.

I don't currently have the knowledge required
to question instruction sets themselves.
Instead, I have assumed that both the
S/390 and 80386 instruction sets were both
required and both perfect for 32-bit
processing, and then made everything else
revolve around that.
That is where we ended up with 32-bit
computing. The world settled on those
two instruction sets (and more recently
ARM popped up and I haven't spent
any time on that, still sorting out the
OSes that ran/run on S/390 and 80386).
So I want to know logically how we ended
up with such a mess with MSDOS only
being 16-bit instead of all software being
targeted to both 16-bit and 32-bit MSDOS.
BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

Well given that the S/390 instruction set predates the 80386 by about 20
years then I think you have the answer to that.

Joe

Post by ***@yahoo.com.au [hercules-os380]
I am busy working on PDOS/386 and making
great progress. I have a question about
chips.
If we are rerunning computer history, is there
any need for both 80386 and S/390 instruction
sets? Can't everyone just use one or the other?
Did IBM patent their instructions or something
to inspire others to create their own instructions?
Regardless of that, I am interested in at what
point a cheap 80386 could have been made.
I'm just after 32-bit processing, as a replacement
for the 16-bit processing of the 8086. I don't
need virtual memory, I don't need memory
protection, I don't need v8086 mode, I don't
want segment registers, I just want a simple
version of the 80386, as near as possible to
being a drop-in replacement for the 8086.
Was there some technical barrier preventing
people from making such a CPU? Did Intel
have patents over the 8086 instruction set
preventing other manufacturers from
producing such a chip?
Thanks. Paul.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]
Well given that the S/390 instruction set
predates the 80386 by about 20 years then
I think you have the answer to that.

I meant a suitable subset of the S/390
instruction set.

How many different instruction sets does
the world need?

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
How many different instruction sets does
the world need?

Back in the early eighties there was a Computer Age magazine. One of
their contests was to create a minimal program to calculate something.
Their theoretical computer has exactly one instruction - SUB A,B,C - the
contents of B were subtracted from A, stored back in A, and a zero
result branched to C. Reserved storage locations were used to signal
halt, etc.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
https://www.avg.com

[Joe Monk [e-mail] [hercules-os380]]

The point is that the instructions are the same. :)

Whats different is the execution. ADD is ADD after all, but AR is executed
differently on different hardware.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]
Well given that the S/390 instruction set
predates the 80386 by about 20 years then
I think you have the answer to that.

I meant a suitable subset of the S/390
instruction set.
How many different instruction sets does
the world need?
BFN. Paul.

[[e-mail] [hercules-os380]]

You seem to be totally ignorant of most of the history and evolution of computers in the 20th century, with "tunnel vision" you seem to only focus on the IBM PC and PC-DOS/MS-DOS and you know a little bit about IBM mainframes.


What about DEC-10 and DEC-20, a 36-bit architecture? What about Burroughs B5000-6700, a very different architecture with tagged memory and virtual memory at the segment level, and protection at the segment level?



What about all of the other computer architectures of the 1950s, 60s, 70s, 80s? and of course, these all had their own unique operating systems with their own personalities, etc.


There are many emulators of those older machines so you can actually load and run some of those old historically significant operating systems, to learn about those systems, study their source code, etc.


You seem to behave like a horse with blinkers on. You "see" only PC-DOS and the bizarre MVS/380 variant "kludge" that is in effect a recreation of OS/360 MFT, just with a bigger address space.


And why go to all that trouble, just to run code "above the line"? So you can run GCC? Ugh. Why not configure GCC as a cross-compiler, then run it on any modern platform (PC, Linux, Windows...) and generate code for your target platform, e.g. MVS 3.8, or MVS/ESA, or z/OS etc.?


Why do you think you have to run GCC "on" MVS?

[Joe Monk [e-mail] [hercules-os380]]

It is a noble endeavor to run GCC on MVS 3.8J. But the extremes which have
been gone to do it are ....

I would've re-written the GCC compiler to use work files instead of
kludging a memory model..

Joe

Post by ***@yahoo.com [hercules-os380]
You seem to be totally ignorant of most of the history and evolution of
computers in the 20th century, with "tunnel vision" you seem to only focus
on the IBM PC and PC-DOS/MS-DOS and you know a little bit about IBM
mainframes.
What about DEC-10 and DEC-20, a 36-bit architecture? What about Burroughs
B5000-6700, a very different architecture with tagged memory and virtual
memory at the segment level, and protection at the segment level?
What about all of the other computer architectures of the 1950s, 60s, 70s,
80s? and of course, these all had their own unique operating systems with
their own personalities, etc.
There are many emulators of those older machines so you can actually load
and run some of those old historically significant operating systems, to
learn about those systems, study their source code, etc.
You seem to behave like a horse with blinkers on. You "see" only PC-DOS
and the bizarre MVS/380 variant "kludge" that is in effect a recreation of
OS/360 MFT, just with a bigger address space.
And why go to all that trouble, just to run code "above the line"? So you
can run GCC? Ugh. Why not configure GCC as a cross-compiler, then run it
on any modern platform (PC, Linux, Windows...) and generate code for your
target platform, e.g. MVS 3.8, or MVS/ESA, or z/OS etc.?
Why do you think you have to run GCC "on" MVS?

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com [hercules-os380]
You seem to be totally ignorant of most of the
history and evolution of computers in the 20th
century, with "tunnel vision" you seem to only
focus on the IBM PC and PC-DOS/MS-DOS
and you know a little bit about IBM mainframes.

I know more about IBM mainframes than
MSDOS. I am currently learning MSDOS
by replacing it with both 16-bit and 32-bit
variations.

Post by ***@yahoo.com [hercules-os380]
What about DEC-10 and DEC-20, a 36-bit
architecture?

For better or for worse, my PC back in the
80s was x86-based, and I seek to replace
everything I was doing back then with a
public domain replacement.

In particular I had a message reader which
was fullscreen text rather than command
line or graphics, and I was perfectly happy
with that. I believe it worked by writing
directly to 0xb8000, and now all I want to
do is upgrade that to 32-bit so that I can
go back to operating like that without
running into memory restrictions.

Post by ***@yahoo.com [hercules-os380]
And why go to all that trouble, just to run code
"above the line"? So you can run GCC? Ugh.
Why not configure GCC as a cross-compiler,
then run it on any modern platform (PC, Linux,
Windows...) and generate code for your target
platform, e.g. MVS 3.8, or MVS/ESA, or z/OS etc.?

Because I want to produce and test a load
module that will work natively on z/OS.

And because I would like to see all my
software work natively on both 32-bit
MVS and 32-bit MSDOS. That includes
the message reader I mentioned. I'm
still not sure how to do that. ie have a
list of messages displayed directly to
0xb8000 and have the cursor keys
scroll down the list. I have MVS/380
APIs to control a joystick and display
graphics, but don't yet have anything
to draw and control fullscreen text.

BFN. Paul.