assholes

[muta...@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.

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]

"muta...@gmail.com" <muta...@gmail.com> writes:
>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]

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]

On 07.06.2021 19:12, muta...@gmail.com wrote:

> 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]

On Mon, 07 Jun 2021 17:02:50 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:

> "muta...@gmail.com" <muta...@gmail.com> writes:

<off-topic now>

>> 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.
>

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.

[JJ]

On Mon, 7 Jun 2021 08:02:19 -0700 (PDT), muta...@gmail.com wrote:
> Who are these assholes that are invalidating
> legacy boot operating systems?

Those which aren't worth our time.

[Scott Lurndal]

Rod Pemberton <noe...@basdxcqvbe.com> writes:
>On Mon, 07 Jun 2021 17:02:50 GMT
>sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>> "muta...@gmail.com" <muta...@gmail.com> writes:
>
><off-topic now>
>
>>> 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.
>>
>
>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]

On Wednesday, June 9, 2021 at 12:49:23 AM UTC+10, Scott Lurndal wrote:

> 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]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Wednesday, June 9, 2021 at 12:49:23 AM UTC+10, Scott Lurndal wrote:
>
>> 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.

> No-one at all wants to run
>OS/2 or MSDOS or anything?

Only small handful of hobbyists.

>ie when their machine
>dies. They're forced to scavenge landfill?

Most are perfectly happy with QEMU or some other
simulation solution.

>
>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]

On Wednesday, June 9, 2021 at 10:48:28 AM UTC+10, Scott Lurndal wrote:

> >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]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Wednesday, June 9, 2021 at 10:48:28 AM UTC+10, Scott Lurndal wrote:
>
>> >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]

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]

> 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]

On Friday, June 11, 2021 at 10:01:56 AM UTC+10, Joe Monk wrote:

> > 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.

> Enabling the "old" ways is a massive pain,

What specifically is difficult?

> 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]

> 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]

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]

> > 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]

On Friday, June 11, 2021 at 8:51:19 PM UTC+10, Joe Monk wrote:

> > > 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]

> 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]

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]

> 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.

>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]

On Saturday, June 12, 2021 at 12:11:24 PM UTC+10, Joe Monk wrote:

> > 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.

> >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.

> 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]

> 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]

Here's an example: https://en.wikipedia.org/wiki/Altair_8800#/media/File:Altair_8800_and_Model_33_ASR_Teletype_.jpg

JOE

[muta...@gmail.com]

On Saturday, June 12, 2021 at 10:20:56 PM UTC+10, Joe Monk wrote:

> > 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.

> 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]

> 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.

>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]

On Sunday, June 13, 2021 at 3:31:45 PM UTC+10, Joe Monk wrote:

> > 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.

> 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.

> 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.

> >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:

> Sure sounds like part of a BIOS to me.

Wow. You're in a hole so you dig deeper.

> "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]

On 6/13/21 12:26 AM, muta...@gmail.com wrote:
> 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]

On Sunday, June 13, 2021 at 5:09:19 PM UTC+10, Grant Taylor wrote:

> > 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.

> 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.

> 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]

Grant Taylor <gta...@tnetconsulting.net> writes:
>On 6/13/21 12:26 AM, muta...@gmail.com wrote:
>> 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.

>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]

On 6/13/21 7:49 AM, Scott Lurndal wrote:
> 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.

> 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.

[Scott Lurndal]

Grant Taylor <gta...@tnetconsulting.net> writes:
>On 6/13/21 7:49 AM, Scott Lurndal wrote:
>> 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]

On 6/13/21 1:40 PM, Scott Lurndal wrote:
> 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.

[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... 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

[Rod Pemberton]

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?

[muta...@gmail.com]

On Monday, June 14, 2021 at 7:22:31 AM UTC+10, Joe Monk wrote:

> > 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]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Monday, June 14, 2021 at 7:22:31 AM UTC+10, Joe Monk wrote:
>
>> > 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]

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

[muta...@gmail.com]

On Tuesday, June 15, 2021 at 4:53:50 AM UTC+10, Rod Pemberton wrote:

> > 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:

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]

On Tuesday, June 15, 2021 at 8:17:25 AM UTC+10, muta...@gmail.com wrote:

> 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]

On Tuesday, June 15, 2021 at 8:45:26 AM UTC+10, muta...@gmail.com wrote:

> 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]

On 15.06.2021 00:54, muta...@gmail.com wrote:
[about INTx014...]

did you ever see that INT 00..1F are reserved for CPU exceptions ?
__
wolfgang

[muta...@gmail.com]

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]

On 15.06.2021 14:28, muta...@gmail.com wrote:

>> [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.

> 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. */

a well known documented alias for INT0x10 is INT0x6D

> 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