Discussion:
new direction
(too old to reply)
muta...@gmail.com
2021-03-06 19:40:34 UTC
Permalink
Work on porting PDOS to the Amiga and Atari
has exposed a new design for all computers,
or at least future computers, unless someone
can spot a flaw in it (maybe it has already been
invented anyway).

All computers will have a BIOS, even if that is
something like IO.SYS on PDOS/3X0 (basically
a BIOS created after-the-fact, and on hard disk).
When the BIOS loads the real operating system, or
even the first part of the operating system, like
a boot sector, and passes control to it, it will
pass an address in a register or on the stack.

This address will point to an array of BIOS
function pointers.

The OS will never do an interrupt, it will instead
call these BIOS functions. Whether the called
functions do an interrupt is beyond scope.

Whenever the OS loads and transfers control to
an application, it will provide in either a register or
the stack, a pointer to a similar array of function
pointers, but this time it will be OS functions rather
than BIOS functions.

Whether the OS functions do an interrupt
or not is beyond scope.

With this in place, I will be able to run PDOS as an
application under Windows, and PDOS applications,
and maybe even Windows applications, will be able
to run at full speed under PDOS with no virtualization
or emulation required. The BIOS that PDOS uses will
be implemented as normal calls to Windows, with a
single block of memory obtained from Windows, and
an ordinary disk file used as the "hard disk" (basically
the same as Bochs there).

And of course I can run on AmigaOS the same way.

Assuming I'm not missing something fundamental, the
next step would be to agree on a clean API for both
OS calls and BIOS calls, that would cover all 32-bit
environments known to man. Except perhaps CKD
disks. Clean for C90 programs. Plus C90 programs
that drive an ANSI terminal when they write to stdout.

With that basic paradigm in place, I would then be
able to adjust to actual computers in existence.

BFN. Paul.
Scott Lurndal
2021-03-06 21:55:24 UTC
Permalink
Post by ***@gmail.com
Work on porting PDOS to the Amiga and Atari
has exposed a new design for all computers,
or at least future computers, unless someone
can spot a flaw in it (maybe it has already been
invented anyway).
All computers will have a BIOS, even if that is
All computers (at least those you're likely to use) _have_ UEFI.

Which solves all the problems you posit, and a bunch more. Why reinvent
the wheel?
Rod Pemberton
2021-03-07 03:39:33 UTC
Permalink
On Sat, 06 Mar 2021 21:55:24 GMT
All computers ... _have_ UEFI.
So, do all modern motherboards have only UEFI support now? I haven't
updated since 2009. Or, do they also support legacy BIOS too? If they
don't support legacy BIOS, that's a serious problem. I.e., I don't
care if modern motherboards support UEFI, but if they don't support
BIOS, I can't migrate Linux, Windows 98/SE etc to them.
(at least those you're likely to use [have UEFI])
Some of the guys here, like Paul and James, are also developing for
much older computers, like 1980's era. James may be doing both modern
and old.
Which solves all the problems you posit, and a bunch more. Why
reinvent the wheel?
Yes, Paul basically described UEFI.
--
Diplomacy with dictators simply doesn't work.
muta...@gmail.com
2021-03-07 04:39:45 UTC
Permalink
Post by Rod Pemberton
On Sat, 06 Mar 2021 21:55:24 GMT
All computers ... _have_ UEFI.
Yes, Paul basically described UEFI.
Thanks guys for the pointer to UEFI. I have done some
investigation of that, and these functions look promising:

EFI_IMAGE_LOAD
EFI_DISK_READ/ReadDisk

But basically what I am looking to do is supplement
the Atari BIOS with the UEFI functions, or something
similar.

Here is the Atari BIOS function to read a disk sector:

long Rwabs(int rwflag, long buffer, int number, int recnr, int dev);

Asm:
move.w dev,-(sp)
move.w recnr,-(sp)
move.w number,-(sp)
move.l buffer,-(sp)
move.w rwflag,-(sp)
move.w #4,-(sp)
trap #13
add.l #14,sp

If we ignore the problem of the recnr (sector number) being
an "int" instead of "unsigned long", I basically want a
UEFI-like ReadDisk() function that would call the Rwabs
interrupt.

I also want to stick to a C90 interface, so I don't want the
UEFI parameters.

I'm also not thrilled with the UEFI parameters of data offset
rather than sector number. But in principle I'm willing to
restrict disks to 4 GiB in size on 32-bit systems, so I can
switch to data offset rather than sector start. Restricting
disks to 4 GiB will fix the issue with "space free" overflowing
an unsigned long.

So, should I go for a modified ReadDisk() function or should
I have a BosReadDisk() which is more under my control
or what?

Thanks. Paul.

Rod Pemberton
2021-03-07 03:37:24 UTC
Permalink
On Sat, 6 Mar 2021 11:40:34 -0800 (PST)
Post by ***@gmail.com
Work on porting PDOS to the Amiga and Atari
has exposed a new design for all computers,
or at least future computers, unless someone
can spot a flaw in it (maybe it has already been
invented anyway).
...
Post by ***@gmail.com
All computers will have a BIOS, even if that is
something like IO.SYS on PDOS/3X0 (basically
a BIOS created after-the-fact, and on hard disk).
When the BIOS loads the real operating system, or
even the first part of the operating system, like
a boot sector, and passes control to it, it will
pass an address in a register or on the stack.
This would really be a BIOS plus a boot loader.
Post by ***@gmail.com
This address will point to an array of BIOS
function pointers.
The OS will never do an interrupt, it will instead
call these BIOS functions. Whether the called
functions do an interrupt is beyond scope.
Whenever the OS loads and transfers control to
an application, it will provide in either a register or
the stack, a pointer to a similar array of function
pointers, but this time it will be OS functions rather
than BIOS functions.
Whether the OS functions do an interrupt
or not is beyond scope.
A Scott pointed out, a BIOS plus a boot loader plus
a function API basically recreates UEFI.

There is the BIOS32 service directory for
PCI, PNP etc which presented an API of functions.
--
Diplomacy with dictators simply doesn't work.
Loading...