Discussion:
assholes
(too old to reply)
muta...@gmail.com
2021-06-07 15:02:19 UTC
Permalink
Who are these assholes that are invalidating
legacy boot operating systems?

I only need the equivalent of an 80386. Actually
I only need real mode and 32-bit PM.

These things are long out of being patented.

Is there a barrier to someone in Taiwan or pretty
much anywhere creating a new laptop that supports
BIOS (via CSM or whatever, I don't care) and PM32?

PDOS/386 development has now reached a point
that only bugs are remaining stopping it from being
viable for at least my main work. I've got a website now:

http://pdos.org

I'm still waiting for feedback as to whether the HD
image boots on real hardware (and then crashes
with a divide by zero error).

Now I'm ready to do battle with hardware folks.

I know I can buy an old PC that supports legacy
boot, but I want to buy a new one. Not just now,
but in another 20 years. So I want to "second
source" it or whatever. From someone who isn't
an asshole.

Thanks. Paul.
Scott Lurndal
2021-06-07 17:02:50 UTC
Permalink
Post by ***@gmail.com
Who are these assholes that are invalidating
legacy boot operating systems?
I only need the equivalent of an 80386. Actually
I only need real mode and 32-bit PM.
To quote Commander Spock:

The needs of the many outweigh the needs of the one.
muta...@gmail.com
2021-06-07 17:12:30 UTC
Permalink
Post by Scott Lurndal
Post by ***@gmail.com
Who are these assholes that are invalidating
legacy boot operating systems?
I only need the equivalent of an 80386. Actually
I only need real mode and 32-bit PM.
The needs of the many outweigh the needs of the one.
And Star Trek is complete crap compared to Blake's 7,
yet hardly anyone has heard of the latter.

It's the world that is at fault, not me.

BFN. Paul.
wolfgang kern
2021-06-08 04:08:36 UTC
Permalink
Post by ***@gmail.com
It's the world that is at fault, not me.
you never get that much power to change the world, so you
better take what's offered or end up in a rubber cell.
__
wolfgang
Rod Pemberton
2021-06-08 08:48:51 UTC
Permalink
On Mon, 07 Jun 2021 17:02:50 GMT
<off-topic now>
Post by Scott Lurndal
Post by ***@gmail.com
Who are these assholes that are invalidating
legacy boot operating systems?
I only need the equivalent of an 80386. Actually
I only need real mode and 32-bit PM.
The needs of the many outweigh the needs of the one.
Stop promoting socialism. It's a blatant failure. Capitalism works.
The Chinese have used capitalism with a pinch of mercantilism and
protectionism, authoritarian economic policies to improve capitalism's
efficiency, and some modern economic theories (e.g., Lewis, Mundell)
ignored by the rest of the world, to lift millions out of poverty.

There are 100 million or so dead in Russia due to socialism, as a result
of famine from socialist central government planning. And, another 100
million or so dead in China due to socialism, for the exact same reason.
Socialism caused the economic collapses of Venezuela, Wiemar Republic
(Germany), and Zimbabwe, among many others.

As a kid Star Trek was just a fun science-fiction and action show. As
an adult, it's clear that the Star Trek show was used to present and
promote false Utopian socialist ideology and dogma within United States
society in a form acceptable to Americans. E.g., in the Star
Trek universe, everyone is "equal" due to a cashless and wealth-less
society, a society with no hierarchies except for the military, a
society that is devoid of religion or other "anachronistic" beliefs, a
society where every human need, except for love, is fulfilled by
advanced scientific technology. I.e., centralized government military
control of society, a society where science, medicine, and technology
have eliminated the need for religion, technology heals all injuries and
disease, technology provides free food, clothing, products via
replicators, technology eliminates the need to work for anything except
for those in the military who must maintain the technology, everyone is
equally able due to technology even if they were born with
disabilities, and technology ensures that all time is available for
love or play or personal pursuits, etc. Of course, Star Trek also
showed us the future of humanity if it continues to pursue the course
of a religion free society which uses medicine, science, and technology
to create a more perfect Utopian socialist society: Borg.
--
With an absolute right, there is no such thing as nuance to an
argument. Go tell your favorite law professor.
Scott Lurndal
2021-06-08 14:49:20 UTC
Permalink
Post by Rod Pemberton
On Mon, 07 Jun 2021 17:02:50 GMT
<off-topic now>
Post by Scott Lurndal
Post by ***@gmail.com
Who are these assholes that are invalidating
legacy boot operating systems?
I only need the equivalent of an 80386. Actually
I only need real mode and 32-bit PM.
The needs of the many outweigh the needs of the one.
Stop promoting socialism. It's a blatant failure. Capitalism works.
Nobody is promoting socialism. Nobody wants real mode, so none
of the firmware vendors have bothered to include support for booting
real-mode code. It's that simple.

Off-topic rant deleted.
muta...@gmail.com
2021-06-08 22:51:04 UTC
Permalink
Nobody is promoting socialism. Nobody wants real mode, so none
of the firmware vendors have bothered to include support for booting
real-mode code. It's that simple.
There's no market at all? No-one at all wants to run
OS/2 or MSDOS or anything? ie when their machine
dies. They're forced to scavenge landfill?

What's wrong with providing CSM? Is it expensive for
them to do? Can I flash my own CSM?

Even if I flash the CSM, I still need the actual processor
to support real mode.

But what I would like is to be able to buy a new computer
with 80386+80387 chip, not necessarily from AMD/Intel,
with 4 GiB of RAM. NEC used to make CPUs. Amdahl
used to make S/390 computers too. I guess I would like
OEMs to return, if an OS is made available to them.

BFN. Paul.
Scott Lurndal
2021-06-09 00:48:26 UTC
Permalink
Post by ***@gmail.com
Nobody is promoting socialism. Nobody wants real mode, so none
of the firmware vendors have bothered to include support for booting
real-mode code. It's that simple.
There's no market at all?
None. Zilch.
Post by ***@gmail.com
No-one at all wants to run
OS/2 or MSDOS or anything?
Only small handful of hobbyists.
Post by ***@gmail.com
ie when their machine
dies. They're forced to scavenge landfill?
Most are perfectly happy with QEMU or some other
simulation solution.
Post by ***@gmail.com
What's wrong with providing CSM? Is it expensive for
them to do? Can I flash my own CSM?
Very expensive. Both in terms of engineering and in
terms of quality assurance and support.

Consider the billions of instructions that are executed
by the firmware before the bootstrap starts reading your
code - proprietary chip initialization, read the SPDs and
initialize the memory controller(s), train the PCI root
complex ports, scan the PCI segments and allocate physical
address space to each enabled BAR and initialize the
southbridge to direct the allocated physical addresses
to the appropriate PCI express root complexes, program
the PHYs for the network ports, initialize the voltage
regulators, read the SPI flash, setup SMM mode, initialize
UEFI, build the memory map (like E820) and convey it to
the boot loader (uboot, grub, etc) which reads the MBR
and loads the bootstrap program in real mode and transfers
control to it.
muta...@gmail.com
2021-06-10 06:29:05 UTC
Permalink
Post by ***@gmail.com
What's wrong with providing CSM? Is it expensive for
them to do? Can I flash my own CSM?
Very expensive. Both in terms of engineering and in
terms of quality assurance and support.
Consider the billions of instructions that are executed
by the firmware before the bootstrap starts reading your
code - proprietary chip initialization, read the SPDs and
initialize the memory controller(s), train the PCI root
complex ports, scan the PCI segments and allocate physical
address space to each enabled BAR and initialize the
southbridge to direct the allocated physical addresses
to the appropriate PCI express root complexes, program
the PHYs for the network ports, initialize the voltage
regulators, read the SPI flash, setup SMM mode, initialize
All that is happening anyway.
UEFI, build the memory map (like E820) and convey it to
Yes, they need to do that. Is that a problem?
the boot loader (uboot, grub, etc) which reads the MBR
and loads the bootstrap program in real mode and transfers
control to it.
Yes. Read one sector. So what?

I don't need a full "BIOS stack". I mainly need INT 13H to work.
If I need to write to 0xb8000 myself because they don't want
to provide INT 10H, I can probably work around that.

BFN. Paul.
Scott Lurndal
2021-06-10 14:07:44 UTC
Permalink
Post by ***@gmail.com
Post by ***@gmail.com
What's wrong with providing CSM? Is it expensive for
them to do? Can I flash my own CSM?
Very expensive. Both in terms of engineering and in
terms of quality assurance and support.
Consider the billions of instructions that are executed
by the firmware before the bootstrap starts reading your
code - proprietary chip initialization, read the SPDs and
initialize the memory controller(s), train the PCI root
complex ports, scan the PCI segments and allocate physical
address space to each enabled BAR and initialize the
southbridge to direct the allocated physical addresses
to the appropriate PCI express root complexes, program
the PHYs for the network ports, initialize the voltage
regulators, read the SPI flash, setup SMM mode, initialize
All that is happening anyway.
Not if you write your own firmware.
muta...@gmail.com
2021-06-10 22:28:49 UTC
Permalink
Post by Scott Lurndal
Post by ***@gmail.com
Post by ***@gmail.com
What's wrong with providing CSM? Is it expensive for
them to do? Can I flash my own CSM?
Very expensive. Both in terms of engineering and in
terms of quality assurance and support.
Consider the billions of instructions that are executed
by the firmware before the bootstrap starts reading your
code - proprietary chip initialization, read the SPDs and
initialize the memory controller(s), train the PCI root
complex ports, scan the PCI segments and allocate physical
address space to each enabled BAR and initialize the
southbridge to direct the allocated physical addresses
to the appropriate PCI express root complexes, program
the PHYs for the network ports, initialize the voltage
regulators, read the SPI flash, setup SMM mode, initialize
All that is happening anyway.
Not if you write your own firmware.
I'm talking about adding CSM to existing firmware.

Why is adding CSM difficult? Or are people just trying
to force upgrades?

BFN. Paul.
Joe Monk
2021-06-11 00:01:54 UTC
Permalink
Post by ***@gmail.com
I'm talking about adding CSM to existing firmware.
Why is adding CSM difficult? Or are people just trying
to force upgrades?
Because there are newer and better ways to do the same thing. Enabling the "old" ways is a massive pain, and people dont want to do that anymore.

Joe
muta...@gmail.com
2021-06-11 01:13:37 UTC
Permalink
Post by Joe Monk
Post by ***@gmail.com
I'm talking about adding CSM to existing firmware.
Why is adding CSM difficult? Or are people just trying
to force upgrades?
Because there are newer and better ways to do the same thing.
Sure. And z/Arch supports 64-bit instructions. It still
supports the S/360 instructions though.
Post by Joe Monk
Enabling the "old" ways is a massive pain,
What specifically is difficult?
Post by Joe Monk
and people dont want to do that anymore.
MOST people may not care, but modern computers
should be able to eat up the requirements of those
who still wish to run old OSes like OS/2. On the
processor, with no additional software required.
Any additional software can be inside the firmware.

BFN. Paul.
Joe Monk
2021-06-11 03:09:35 UTC
Permalink
Post by ***@gmail.com
Sure. And z/Arch supports 64-bit instructions. It still
supports the S/360 instructions though.
True, but z/arch doesnt support 360 I/O instructions, like SIO. So the comparison is not valid. Think of BIOS as 360/370 I/O and UEFI as XA and above I/O.

Joe
muta...@gmail.com
2021-06-11 04:32:31 UTC
Permalink
Post by Joe Monk
Post by ***@gmail.com
Sure. And z/Arch supports 64-bit instructions. It still
supports the S/360 instructions though.
True, but z/arch doesnt support 360 I/O instructions, like SIO. So the comparison is not valid. Think of BIOS as 360/370 I/O and UEFI as XA and above I/O.
The BIOS is an API, not just an instruction.

If a particular I/O port on the PC disappeared, so I
could no longer directly poll COM1, so be it.

But I still expect INT 14H to work.

And I don't care how that is implemented.

BFN. Paul.
Joe Monk
2021-06-11 10:51:18 UTC
Permalink
Post by ***@gmail.com
Post by Joe Monk
True, but z/arch doesnt support 360 I/O instructions, like SIO. So the comparison is not valid. Think of BIOS as 360/370 I/O and UEFI as XA and above I/O.
The BIOS is an API, not just an instruction.
If a particular I/O port on the PC disappeared, so I
could no longer directly poll COM1, so be it.
But I still expect INT 14H to work.
Right, but on z/arch INT 14h no longer exists.

Remember the whole process:

OS <> CPU <> Channel <> Controller <> Device

The API is for the CPU <> Channel (SIO/SSCH). Here the API has changed from SIO to SSCH with ORB (that's the difference between 370 mode and XA mode). So, the OS has to change in order to implement the new API, which is one of the many differences between MVS and MVS/XA and successors.

So, just as the API has changed on the mainframe, so has it also changed on the PC. UEFI still provides the functionality, but the API has changed ( C functions instead of hardware interrupts). Thus, Win10 now uses UEFI as its preference and forgets about directly calling interrupts to perform functions.

Joe
muta...@gmail.com
2021-06-11 11:46:48 UTC
Permalink
Post by Joe Monk
Post by ***@gmail.com
Post by Joe Monk
True, but z/arch doesnt support 360 I/O instructions, like SIO. So the comparison is not valid. Think of BIOS as 360/370 I/O and UEFI as XA and above I/O.
The BIOS is an API, not just an instruction.
If a particular I/O port on the PC disappeared, so I
could no longer directly poll COM1, so be it.
But I still expect INT 14H to work.
Right, but on z/arch INT 14h no longer exists.
The mainframe has no direct equivalent of INT 14H.
It is neither a supervisor instruction that has been
invalidated, nor is it a user SVC that has been
invalidated.

The mainframe probably needs a BIOS for use by
mainframe OSes to give OEMs like Amdahl more
flexibility.

BFN. Paul.
Joe Monk
2021-06-12 00:06:39 UTC
Permalink
Post by ***@gmail.com
The mainframe has no direct equivalent of INT 14H.
It is neither a supervisor instruction that has been
invalidated, nor is it a user SVC that has been
invalidated.
The fuck it doesnt. Thats what VTAM/TCAM and 37x5 controllers are for. VTAM/TCAM are the equivalent of int 14h and the 37x5 controller is the equivalent of a UART.

Joe
muta...@gmail.com
2021-06-12 01:28:25 UTC
Permalink
Post by Joe Monk
Post by ***@gmail.com
The mainframe has no direct equivalent of INT 14H.
It is neither a supervisor instruction that has been
invalidated, nor is it a user SVC that has been
invalidated.
The fuck it doesnt. Thats what VTAM/TCAM and 37x5
controllers are for. VTAM/TCAM are the equivalent of
int 14h and the 37x5 controller is the equivalent of a UART.
VTAM is not provided as part of the hardware. That's
why it's available to MVS programs but not
CMS/VSE/MUSICSP/PDOS3X0/Linux programs.

And we're missing an INT 13H on mainframes too.

BFN. Paul.
Joe Monk
2021-06-12 02:11:23 UTC
Permalink
Post by ***@gmail.com
VTAM is not provided as part of the hardware. That's
why it's available to MVS programs but not
CMS/VSE/MUSICSP/PDOS3X0/Linux programs.
You dont know what youre talking about. VTAM is available for those OS platforms as well. Its a program product just like it is on MVS.
Post by ***@gmail.com
And we're missing an INT 13H on mainframes too.
No we're not. EXCP with a channel program works just fine, the same as it does on an ancient PC. Here's the actual code from the BIOS for INT 13. It operates exactly the same as EXCP.

;-- INT 13 ----------------------------------
;DISKETTE I/O
; THIS INTERFACE PROVIDES ACCESS TO THE 5 1/4" DISKETTE DRIVES
;INPUT
; (AH)=0 RESET DISKETTE SYSTEM
; HARD RESET TO NEC, PREPARE COMMAND, RECAL REQD ON ALL DRIVES
; (AH)=1 READ THE STATUS OF THE SYSTEM INTO (AL)
; DISKETTE_STATUS FROM LAST OP'N IS USED
; REGISTERS FOR READ/WRITE/VERIFY/FORMAT
; (DL) - DRIVE NUMBER (0-3 ALLOWED, VALUE CHECKED)
; (DH) - HEAD NUMBER (0-1 ALLOWED, NOT VALUE CHECKED)
; (CH) - TRACK NUMBER (0-39, NOT VALUE CHECKED)
; (CL) - SECTOR NUMBER (1-8, NOT VALUE CHECKED)
; (AL) - NUMBER OF SECTORS ( MAX = 8, NOT VALUE CHECKED)
;
; (ES:BX) - ADDRESS OF BUFFER ( NOT REQUIRED FOR VERIFY)
;
; (AH)=2 READ THE DESIRED SECTORS INTO MEMORY
; (AH)=3 WRITE THE DESIRED SECTORS FROM MEMORY
; (AH)=4 VERIFY THE DESIRED SECTORS
; (AH)=5 FORMAT THE DESIRED TRACKS
; FOR THE FORMAT OPERATION, THE BUFFER POINTER (ES,BX) MUST
; POINT TO THE COLLECTION OF DESIRED ADDRESS FIELDS FOR THE
; TRACK. EACH FIELD IS COMPOSED OF 4 BYTES, (C,H,R,N), WHERE
; C = TRACK NUMBER, H=HEAD NUMBER, R = SECTOR NUMBER, N= NUMBER
; OF BYTES PER SECTOR (00=128, 01=256, 02=512, 03=1024,)
; THERE MUST BE ONE ENTRY FOR EVERY SECTOR ON THE TRACK.
; THIS INFORMATION IS USED TO FIND THE REQUESTED SECTOR DURING
; READ/WRITE ACCESS.
; DATA VARIABLE -- DISK_POINTER
; DOUBLE WORD POINTER TO THE CURRENT SET OF DISKETTE PARAMETERS
; OUTPUT
; AH = STATUS OF OPERATION
; STATUS BITS ARE DEFINED IN THE EQUATES FOR DISKETTE_STATUS
; VARIABLE IN THE DATA SEGMENT OF THIS MODULE
; CY = 0 SUCCESSFUL OPERATION (AH=0 ON RETURN)
; CY = 1 FAILED OPERATION (AH HAS ERROR REASON)
; FOR READ/WRITE/VERIFY
; DS,BX,DX,CH,CL PRESERVED
; AL = NUMBER OF SECTORS ACTUALLY READ
; ***** AL MAY NOT BE CORRECT IF TIME OUT ERROR OCCURS
; NOTE: IF AN ERROR IS REPORTED BY THE DISKETTE CODE, THE APPROPRIATE
; ACTION IS TO RESET THE DISKETTE, THEN RETRY THE OPERATION.
; ON READ ACCESSES, NO MOTOR START DELAY IS TAKEN, SO THAT
; THREE RETRIES ARE REQUIRED ON READS TO ENSURE THAT THE
; PROBLEM IS NOT DUE TO MOTOR START-UP.
;--------------------------------------------



Joe
muta...@gmail.com
2021-06-12 03:03:57 UTC
Permalink
Post by Joe Monk
Post by ***@gmail.com
VTAM is not provided as part of the hardware. That's
why it's available to MVS programs but not
CMS/VSE/MUSICSP/PDOS3X0/Linux programs.
You dont know what youre talking about. VTAM is available
for those OS platforms as well. Its a program product just like it is on MVS.
VTAM is available for PDOS/3X0?

Regardless, that makes it more the equivalent of a
driver than a BIOS. It's a driver for some network.
Post by Joe Monk
Post by ***@gmail.com
And we're missing an INT 13H on mainframes too.
No we're not. EXCP with a channel program works just
fine,
EXCP is not provided with the hardware either.
Post by Joe Monk
the same as it does on an ancient PC. Here's the actual code from
the BIOS for INT 13. It operates exactly the same as EXCP.
No. INT 13 comes with the hardware. If there was an
SVC 13 that worked on all IBM hardware, that would
be the equivalent of INT 13. The only thing you have
on IBM hardware is SIO/SSCH which is the equivalent
of OUT.

BFN. Paul.
Joe Monk
2021-06-12 12:20:54 UTC
Permalink
Post by ***@gmail.com
No. INT 13 comes with the hardware.
Says who?

Nothing says that a PC MoBo has to come with a BIOS. In fact, the first PCs, like the MITS ALTAIR 8080, didnt even have a bios. You had to flip switches on the front panel to set the starting address, which was a boot rom.

Even the vaunted APPLE II computer booted into ROM BASIC, which you could then jump into FP BASIC if you wanted.

Your concept of computing is very limited. Take the blinders off.

Joe
Joe Monk
2021-06-12 12:27:09 UTC
Permalink
Post by Joe Monk
Post by ***@gmail.com
No. INT 13 comes with the hardware.
Says who?
Nothing says that a PC MoBo has to come with a BIOS. In fact, the first PCs, like the MITS ALTAIR 8080, didnt even have a bios. You had to flip switches on the front panel to set the starting address, which was a boot rom.
Even the vaunted APPLE II computer booted into ROM BASIC, which you could then jump into FP BASIC if you wanted.
Your concept of computing is very limited. Take the blinders off.
Joe
Here's an example: Loading Image...

JOE
muta...@gmail.com
2021-06-13 00:14:29 UTC
Permalink
Post by Joe Monk
Post by ***@gmail.com
No. INT 13 comes with the hardware.
Says who?
Nothing says that a PC MoBo has to come with a BIOS.
And nothing says that it needs to support 8086 instructions
either. Or 80386 instructions. Or x64 instructions.

But someone decided to make a computer with an 8086
processor, and decided that the computer would allow
operating systems to boot by providing them with an
API - INT 13H, to read sectors from the disk.

That is a historical fact.

Other people, like the ones you mentioned, and like IBM,
decided against (or didn't think of it) providing a similar
BIOS.

I see no reason why a modern computer can't afford to
continue supporting this API. I don't even care if the
instructions are simulated, so long as when I have
finished using the BIOS I return to my supported mode
on the processor.
Post by Joe Monk
Your concept of computing is very limited. Take the blinders off.
It is my limited view that allowed me to see through
your bullshit that VTAM was the equivalent of a BIOS,
and that SIO was the equivalent of a BIOS.

BFN. Paul.
Joe Monk
2021-06-13 05:31:44 UTC
Permalink
Post by ***@gmail.com
I see no reason why a modern computer can't afford to
continue supporting this API. I don't even care if the
instructions are simulated, so long as when I have
finished using the BIOS I return to my supported mode
on the processor.
Well, the masses have decided they dont want that anymore. Particularly with its limits (there are hard drives now that are bigger than BIOS can support).

So, youve been overruled.
Post by ***@gmail.com
It is my limited view that allowed me to see through
your bullshit that VTAM was the equivalent of a BIOS,
and that SIO was the equivalent of a BIOS.
"Basic services performed by VTAM include:
• Establishing, controlling, and terminating access between the application programs and the terminals
• Moving data between application programs and the terminals
• Permitting application programs to share communication lines, communications controllers, and telecommunication terminals
• Permitting the telecommunication network to be monitored and altered
• Permitting the configuration of the telecommunication network to be changed while the network is being used"

Sure sounds like part of a BIOS to me.

"The CPU controls I/O operations by means of four I/O
instructions: START I/O, TEST I/O, HALT I/O, and TEST CHANNEL."

Sure sounds like part of a BIOS to me.

Joe
muta...@gmail.com
2021-06-13 06:26:31 UTC
Permalink
Post by Joe Monk
Post by ***@gmail.com
I see no reason why a modern computer can't afford to
continue supporting this API. I don't even care if the
instructions are simulated, so long as when I have
finished using the BIOS I return to my supported mode
on the processor.
Well, the masses have decided they dont want that anymore.
The masses have built their houses on sand.
Post by Joe Monk
Particularly with its limits (there are hard drives now that are bigger than BIOS can support).
That's fine. Doesn't mean you should stop supporting
things that are within the limits of the BIOS.
Post by Joe Monk
So, youve been overruled.
That's the great thing about software. There's no fascists
who can stop you from writing code. You can write an
entire operating system if necessary to bypass them.
So long as you have 27 years to spare, or know someone
who has 27 years to spare.
Post by Joe Monk
Post by ***@gmail.com
It is my limited view that allowed me to see through
your bullshit that VTAM was the equivalent of a BIOS,
and that SIO was the equivalent of a BIOS.
Sure sounds like part of a BIOS to me.
Wow. You're in a hole so you dig deeper.
Post by Joe Monk
"The CPU controls I/O operations by m>eans of four I/O
instructions: START I/O, TEST I/O, HALT I/O, and TEST CHANNEL."
Sure sounds like part of a BIOS to me.
And deeper and deeper. Good luck with that.

BFN. Paul.
Grant Taylor
2021-06-13 07:09:17 UTC
Permalink
That's fine. Doesn't mean you should stop supporting things that are
within the limits of the BIOS.
Unfortunately things that are outmoded /eventually/ become a burden to
maintain. BIOS or UEFI's BIOS compatibility mode has apparently become
a burden. As such, some manufacturers are no longer providing support
for that legacy.

Check to see if there is a 3rd party firmware for the board(s) you are
using. I could see a 3rd party firmware specializing in supporting
older BIOS support, especially if you're willing to pay something.

Or, vote with your wallet, and don't buy a system that doesn't have BIOS
or BIOS compatibility mode.
--
Grant. . . .
unix || die
muta...@gmail.com
2021-06-13 07:38:06 UTC
Permalink
Post by Grant Taylor
That's fine. Doesn't mean you should stop supporting things that are
within the limits of the BIOS.
Unfortunately things that are outmoded /eventually/ become a burden to
maintain. BIOS or UEFI's BIOS compatibility mode has apparently become
a burden. As such, some manufacturers are no longer providing support
for that legacy.
Yeah, the same thing happened with Borland's C compiler.
They decided there weren't enough customers to continue
supporting it (maybe just the OS/2 version, can't remember).
I can remember some guy (David Nugent) in AUST_C_HERE
saying that he wouldn't mind having as many customers as
Borland had for their OS/2 compiler!

Which is exactly right. If you can't be bothered doing it
yourself, at least have enough respect for your own damned
product to hand it off to someone else, or open source it
or something. The SAS/C for Amiga developers continued
fixing bugs in it even after the product was discontinued.
Some people have respect for software!!!

And I respect those people.
Post by Grant Taylor
Check to see if there is a 3rd party firmware for the board(s) you are
using. I could see a 3rd party firmware specializing in supporting
older BIOS support, especially if you're willing to pay something.
Yes, I'm willing to pay for that.
Post by Grant Taylor
Or, vote with your wallet, and don't buy a system that doesn't have BIOS
or BIOS compatibility mode.
Yes, I am happy to do that, so long as they EXIST and continue
to EXIST.

In actual fact, I just found out in the last 24 hours that some
BIOSes from some manufacturers will recognize multiple
USB sticks as hard disks when you plug in multiple ones at
boot time. That's exactly what I'm after. And I don't mind
paying more for that. Assuming the report is correct.

BFN. Paul.
Scott Lurndal
2021-06-13 13:49:11 UTC
Permalink
Post by Grant Taylor
That's fine. Doesn't mean you should stop supporting things that are
within the limits of the BIOS.
Unfortunately things that are outmoded /eventually/ become a burden to
maintain. BIOS or UEFI's BIOS compatibility mode has apparently become
a burden.
A _huge_ burden. For something nobody needs or uses any more.
Post by Grant Taylor
Check to see if there is a 3rd party firmware for the board(s) you are
using. I could see a 3rd party firmware specializing in supporting
older BIOS support, especially if you're willing to pay something.
Not very likely. There is too much proprietary content in the
firmware that the manufacturers don't document publically.
Grant Taylor
2021-06-13 16:26:54 UTC
Permalink
Post by Scott Lurndal
A _huge_ burden. For something nobody needs or uses any more.
I dislike absolutes. I think that Paul E. is evidence that at least one
person wants, thus needs.
Post by Scott Lurndal
Not very likely. There is too much proprietary content in the
firmware that the manufacturers don't document publically.
Probably.

I never subscribed to the 3rd party BIOS idea myself. But I know that
it used to be a thing. I have no idea what it's current state is.
--
Grant. . . .
unix || die
Scott Lurndal
2021-06-13 19:40:17 UTC
Permalink
Post by Grant Taylor
Post by Scott Lurndal
A _huge_ burden. For something nobody needs or uses any more.
I dislike absolutes. I think that Paul E. is evidence that at least one
person wants, thus needs.
The companies that build the computers make no money supporting such
users.
Grant Taylor
2021-06-13 19:52:11 UTC
Permalink
Post by Scott Lurndal
The companies that build the computers make no money supporting such
users.
Again, absolutes....

I think that Paul has indicated that he would buy a system. But one
person, or a few people, buying systems likely isn't enough for
companies to spend time building such systems.
--
Grant. . . .
unix || die
Joe Monk
2021-06-13 21:22:30 UTC
Permalink
I think that Paul has indicated that he would buy a system. But one
person, or a few people, buying systems likely isn't enough for
companies to spend time building such systems.
The average cost to write a BIOS for a motherboard is $25k EUR... The average cost to design/build a motherboard is around $100k EUR.

https://welldoneblog.fedevel.com/2012/11/23/how-much-a-custom-motherboard-design-development-costs/

Joe
muta...@gmail.com
2021-06-14 14:57:02 UTC
Permalink
Post by Joe Monk
I think that Paul has indicated that he would buy a system. But one
person, or a few people, buying systems likely isn't enough for
companies to spend time building such systems.
The average cost to write a BIOS for a motherboard is $25k EUR...
That's actually something I could afford to personally fund
if I had my heart set on it.

But it's still unclear to me why a lot of work would be required
for the handful of BIOS functions I want. Although my grand
plans for INT 14H would put a dampener on that.

I'm wondering if I would be better off moving to the Raspberry Pi
and doing emulation of both 80386 via Bochs and S/3X0 via
Hercules/380. That seems like a more "honest" setup.

BFN. Paul.
Scott Lurndal
2021-06-14 15:54:39 UTC
Permalink
Post by ***@gmail.com
Post by Joe Monk
I think that Paul has indicated that he would buy a system. But one
person, or a few people, buying systems likely isn't enough for
companies to spend time building such systems.
The average cost to write a BIOS for a motherboard is $25k EUR...
That's actually something I could afford to personally fund
if I had my heart set on it.
But it's still unclear to me why a lot of work would be required
for the handful of BIOS functions I want. Although my grand
plans for INT 14H would put a dampener on that.
https://www.cs.cmu.edu/~410/doc/minimal_boot.pdf

Snippets:

Memory initialization for Intel platforms differs widely from chipset to chipset.
The details about how to initialize the memory subsystem is considered
restricted collateral. It comes in two forms:

Documentation (Chipset BIOS Writer's Guide)

Memory initialization Reference Code (MRC)

The BIOS/Firmware Writer's Guide documents the minimal steps required to
initialize the memory subsystem as well as the boundaries/restrictions of the
subsystem. This is useful for vendors that choose to write the memory
initialization code themselves.

The MRC is distributed in different forms (depending on the owning Intel
division and the platform). Each form that may be available is a fully-
functioning implementation of the algorithm in the BIOS/Firmware Writer's
Guide. The MRC may be ported into any firmware stack with a minimal
amount of effort. Since the MRC supports all technologies and configurations
allowed on a platform, it is possible to trim down the MRC to fit a vendor's
design in a minimal amount of code space. This is the vendor's responsibility
and not directly supported by Intel.

...

PC-based memory configurations are based on removable memory modules
(DIMMs). These configurations are dynamically detectable through tiny
EPROM chips on the DIMMs. These chips contain specification-defined
information about the capability of the DRAM configuration on the DIMM
(Serial Presence Detect Data, or SPD data), and is readable through an I2C
interface. For chipsets that are intended to be used in PC-based systems and
support DIMMs, the MRC will usually have native SPD detection support
included. For non-PC-based systems, it may not be present. In these
configurations, it is required to hardcode the memory configuration or provide
access to the memory geometry information through any vendor-defined
mechanism. For memory-down designs, it may be necessary to generate
several bytes of SPD data based on the DRAM datasheets and the schematics
for the platform, and provide that to the MRC.
Rod Pemberton
2021-06-14 19:55:09 UTC
Permalink
On Mon, 14 Jun 2021 07:57:02 -0700 (PDT)
Post by ***@gmail.com
Post by Joe Monk
I think that Paul has indicated that he would buy a system. But
one person, or a few people, buying systems likely isn't enough
for companies to spend time building such systems.
The average cost to write a BIOS for a motherboard is $25k EUR...
That's actually something I could afford to personally fund
if I had my heart set on it.
But it's still unclear to me why a lot of work would be required
for the handful of BIOS functions I want. Although my grand
plans for INT 14H would put a dampener on that.
I'm wondering if I would be better off moving to the Raspberry Pi
and doing emulation of both 80386 via Bochs and S/3X0 via
Hercules/380. That seems like a more "honest" setup.
You could look at SeaBIOS, or Coreboot (aka LinuxBios), or OpenBIOS:

https://en.wikipedia.org/wiki/SeaBIOS
https://www.seabios.org/SeaBIOS

https://en.wikipedia.org/wiki/Coreboot
https://www.coreboot.org/

https://en.wikipedia.org/wiki/OpenBIOS
https://www.openbios.info/Welcome_to_OpenBIOS
--
What is hidden in the ground, when found, is hidden there again?
muta...@gmail.com
2021-06-14 22:17:24 UTC
Permalink
Post by ***@gmail.com
I'm wondering if I would be better off moving to the Raspberry Pi
and doing emulation of both 80386 via Bochs and S/3X0 via
Hercules/380. That seems like a more "honest" setup.
SeaBIOS as a Compatibility Support Module (CSM) for Unified Extensible Firmware Interface (UEFI) and Open Virtual Machine Firmware (OVMF)


That looks exactly what I want, isn't it?

So I just need to purchase a PC based on its ability to
be able to flash that. To get back an IBM-compatible PC.

I didn't see any mention of bluetooth. I'd like to give that
a try. Is it technically feasible to do an INT 14H and have
it talk bluetooth to my dumb phone to see what I've got?

And then maybe I have an an application running on my
wife's iphone that accepts bluetooth and gives me internet
access. Or is there a technical barrier to that?

Thanks. Paul.
muta...@gmail.com
2021-06-14 22:45:25 UTC
Permalink
Post by ***@gmail.com
So I just need to purchase a PC based on its ability to
be able to flash that. To get back an IBM-compatible PC.
BTW, the 2011 Macbook Pro that I have has done something
unusual, preventing it from booting PDOS/386 from USB
stick, despite the fact that it supposedly supports CSM.

If I find out what it is doing, I would be happy to have a
program that zaps my pdos.img to make it boot on
non-standard hardware.

I would also be happy to provide instructions on how to
add a BOOTX64.EFI to the image to make it work on
non-standard modern equipment.

But for now I'm going to hold out for a traditional BIOS
and see how far I get.

Actually, another thing with the bluetooth to my wife's
iphone. My understanding is that Apple restricts the
availability of software. But Bochs is one of the things
that is available. Could I have a COM1 on Bochs that
accesses the bluetooth connection?

Also, what is the situation with Chinese-made phones?
Do any of them bypass the Apple restrictions by having
their own OS that allows you to install any software
you want? I'm happy to replace my dumb phone with a
smart phone if it opens up a connection to my PC via
INT 14H. I guess I can get it all working under Bochs on
my PC first though. Just like my virtual modem. It would
be nice to move back to real hardware though.

In fact, one thing I could do is take my PDOS/386 hard
disk image on USB stick to other PCs and zap the BIOS
with software on that USB stick so that I can get INT 14H
back.

It sounds like I'm going to get some strange looks in the
future as I start asking people what BIOS/motherboard
they have.

BFN. Paul.
muta...@gmail.com
2021-06-14 22:54:25 UTC
Permalink
Post by ***@gmail.com
In fact, one thing I could do is take my PDOS/386 hard
disk image on USB stick to other PCs and zap the BIOS
with software on that USB stick so that I can get INT 14H
back.
Actually, this is the bottom line.

Given that I'm the one obeying the rules, by calling
INT 14H, I expect others to follow the rules. I don't
mind helping them.

In Fidonet there were people sending me non-standard
dates. I already had code (from someone else, Paul
Markham) that would auto-correct the dates, but I
instead preferred to run software that fully validated
it before passing it on to anyone else.

And then I would spend time finding out where the
software was that was putting out the invalid dates.

It turns out that it was mainly a problem of people
using a combination of BBS + tosser that was
causing the problem. It was OK if a BBS used a
non-standard date internally, but if you do that, you
need to combine it with a tosser that recognizes
that non-standard date and puts it into standard
format.

I can remember someone claiming I couldn't program
my way out of a paper bag because I couldn't even
handle dates. They were surprised that I had offered
to write software for the other person to run on their
system to correct the date.

One of these GNU project things, diffutils or something,
told me to update my C library to include the non-standard
header file, sys/types.h or something, but I refused, and
preferred to fork their non-standard software to make it
conform to C90 if they couldn't give a shit about
compliance themselves.

BFN. Paul.
wolfgang kern
2021-06-15 12:11:03 UTC
Permalink
On 15.06.2021 00:54, ***@gmail.com wrote:
[about INTx014...]

did you ever see that INT 00..1F are reserved for CPU exceptions ?
__
wolfgang
muta...@gmail.com
2021-06-15 12:28:23 UTC
Permalink
Post by wolfgang kern
[about INTx014...]
did you ever see that INT 00..1F are reserved for CPU exceptions ?
No, I didn't know that, but I presume you mean in
protected mode.

I used to do INT 13H etc in protected mode, and it would
be translated into an INT 13H in real mode, but Alica changed
the code so that it has this:

#define BIOS_INT_OFFSET 0x90 /* BIOS interrupt 0x10 is moved to 0xA0. */

She also copied the real mode interrupt vectors to match.
I'm not sure if she considered the option of subtracting
0x90 from the interrupt number when it reached the
real mode code instead.

I would ask her if Microsoft's goons hadn't got to her first.

BFN. Paul.
wolfgang kern
2021-06-15 12:50:13 UTC
Permalink
Post by ***@gmail.com
Post by wolfgang kern
[about INTx014...]
did you ever see that INT 00..1F are reserved for CPU exceptions ?
No, I didn't know that, but I presume you mean in
protected mode.
yes, but not only. Exceptions 0x0F..0x18 can occur in RM as well.
Post by ***@gmail.com
I used to do INT 13H etc in protected mode, and it would
be translated into an INT 13H in real mode, but Alica changed
#define BIOS_INT_OFFSET 0x90 /* BIOS interrupt 0x10 is moved to 0xA0. */
a well known documented alias for INT0x10 is INT0x6D
Post by ***@gmail.com
She also copied the real mode interrupt vectors to match.
I'm not sure if she considered the option of subtracting
0x90 from the interrupt number when it reached the
real mode code instead.
I would ask her if Microsoft's goons hadn't got to her first.
IRQs and INTs...(origin was IRQ0..7 at INT8 and IRQ8.. at INT7x)
I saw that as weird, so my IRQ_0..15 were remapped to INT_50..5F.

BUT my DOS-emulator trap all INT instructions and call my own
code for desired functions instead of BIOS INTs.
__
wolfgang

Rod Pemberton
2021-06-13 22:25:39 UTC
Permalink
On Sun, 13 Jun 2021 13:52:11 -0600
Post by Grant Taylor
Post by Scott Lurndal
The companies that build the computers make no money supporting such
users.
Again, absolutes....
I think that Paul has indicated that he would buy a system. But one
person, or a few people, buying systems likely isn't enough for
companies to spend time building such systems.
A small electronics firm I worked for decades ago sold about 1000 units
per month during their bad years, and maybe 4 times that during good
years. Employees were about 20 at the low, and 60 or so at the high.
Revenues were $3 million at the low, $12 million USD at the high.

Most of those units were sold to just cover their operating costs, or
provide sufficient working capital for their operating cycle. This
cash flow allowed them to operate for an entire year without shutting
down. They only sold a very small percentage of units at a profit.
They had a two-tier sales model, i.e., wholesale (at cost), factory
"retail" (for-profit). I don't know what their profit margins were for
the for-profit units, only that they sold a very high percentage of
total units at cost, according to the guys in the marketing department.

The two guys who owned the business were average, but making low six
figures, e.g., probably $120000 to $150000 USD a few decades ago.
That income was about 6 times their blue-collar workers wages, and
about 3 times their white-collar workers salaries. They kept their
white-collar to blue-collar employee ratio about 1:2. The owner's jobs
were no more difficult than any other person's, and no more difficult
than that of an average manager. They made more simply because they
were the owners.

The only people working for the business that needed specialized
knowledge were the electrical engineers, electronic technicians, and an
accountant. Other than that, just about anyone could pretty much do
any job in the company. It did help a tiny bit, when managers had
prior experience working for Fortune 500 companies as they brought in
some more advanced skills and technology, but that wasn't necessary, nor
critical, as long as the manager knew how to manage people. I.e., just
about anyone could run this business, as long as you made sure to hire
electronic engineers and technicians with both experience and
intelligence, and hired a good accountant. Human resources and taxes
were outsourced, although we did have an H.R. "manager" to file
employee paperwork, handle employee health issues, conflicts, etc.

The business was structured based on a very simple model:
sales/marketing, purchasing/accounts payable, shipping/receiving,
manufacturing, and engineering. Of course, a few people had jobs which
didn't fit into any of those large departments, but were necessary,
e.g., programmer, musician, graphic designer, technical writer, etc.
--
What is hidden in the ground, when found, is hidden there again?
JJ
2021-06-08 08:50:56 UTC
Permalink
Post by ***@gmail.com
Who are these assholes that are invalidating
legacy boot operating systems?
Those which aren't worth our time.
Continue reading on narkive:
Loading...