PDOS for Amiga

[Thomas Richter]

Originally Posted by Thorham

So basically for AOS3+ you only have d0 and a0 to 'worry' about?

That assumes that you are only using binaries from these versions. Frankly, nowadays I don't worry about any registers including a0/d0 as ParseArgs() is doing the argument parsing for me, and it receives them through other channels.

[Thomas Richter]

Originally Posted by kerravon

Again, you wouldn't believe how many times I have heard that.

Once again: For legacy BCPL programs, special registers are to be populated in a way that is not documented. What is documented is RunCommand(). That - and not any register values - define the interface how a command is started. Actually, it is much worse. Not only have the registers be prepared correctly, also the stack frame has to be prepared, and in a particularly weird way as the BCPL stack grows from small addresses to large addresses. This is much more than "how to find out the right values".

Originally Posted by kerravon

Forget about my own function API for now. First things first. Getting an AmigaOS executable, built with PDPCLIB, to work on both AmigaOS and AmigaPDOS.

Then, to get that working, you need to use the AmigaDos interface to launch them. The interface is not defined by placing some magic values in particular registers. The interface is defined through a dos.library function.


Do you understand the difference between an interface and an implementation?

[Thorham]

Originally Posted by Thomas Richter

That assumes that you are only using binaries from these versions. Frankly, nowadays I don't worry about any registers including a0/d0 as ParseArgs() is doing the argument parsing for me, and it receives them through other channels.

Noice

[kerravon]

Originally Posted by Thomas Richter

Once again: For legacy BCPL programs, special registers are to be populated in a way that is not documented. What is documented is RunCommand(). That - and not any register values - define the interface how a command is started. Actually, it is much worse. Not only have the registers be prepared correctly, also the stack frame has to be prepared, and in a particularly weird way as the BCPL stack grows from small addresses to large addresses. This is much more than "how to find out the right values".

At the moment I am not inquiring how to SET UP the registers, I'm asking what an *application program* should do, when started, so that it can work on both AmigaOS and Tripos, not just AmigaOS.

But if the stack doesn't even grow the same way, then my main() can't even call printf() and work on both environments, so I'll have to abandon that.

Then, to get that working, you need to use the AmigaDos interface to launch them.

That depends on the exact AmigaOS executable I am executing. The executable I have in mind (ie PDPCLIB "hello world") only uses a handful of SysBase calls.

The interface is not defined by placing some magic values in particular registers.

I'm a C runtime library author with my own startup code. The interface is exactly defined by what registers I receive from the OS (AmigaOS or AmigaPDOS or Tripos or Atari TOS). It is up to me what I do then, working within the limits of what each OS can do, and whether I can even detect which of those OSes I am running under.

The interface is defined through a dos.library function.

I'm confused what you're saying there. Are you talking about a function in a dos.library file that is linked into the executable when it is called by the C library (e.g. SAS/C) or are you talking about the SysBase structures that lead to a DOSBase pointer if you follow the links?

Do you understand the difference between an interface and an implementation?

Perhaps not. Are you saying that I should be using the OpenLibrary() function provided by Commodore instead of writing my own? If so, sure, that makes sense, but I'm writing a partial clone, so I am cloning the functionality of AmigaOS, including writing my own OpenLibrary(0 function (that's effectively what I've done, but I didn't call it that).

[Thomas Richter]

Originally Posted by kerravon

At the moment I am not inquiring how to SET UP the registers, I'm asking what an *application program* should do, when started, so that it can work on both AmigaOS and Tripos, not just AmigaOS.

For an application program, the problem doesn't exist, not nowadays anymore. As an application program, you shouldn't depend on the legacy Tripos cruft. Problem is: This is a retro platform, and such programs exist, like it or not.


The problem exists as long as you want to start a binary, or load a binary for that matter. Again, the interface for loading the binary is LoadSeg(), another dos.library function. It does hunk loading much better and reliable than any program you can write, despite that it is a waste of time re-implementing things that are already present.

Originally Posted by kerravon

But if the stack doesn't even grow the same way, then my main() can't even call printf() and work on both environments, so I'll have to abandon that.

The environment is always the same, just that a BCPL program uses it in a different way. For a BCPL program, a1 is the stack pointer, and it is maintained through the functions in a5 and a6 that call a function and return from a function. What RunCommand() does is that it prepares an environment that is both going to work for BCPL and C.

Originally Posted by kerravon

That depends on the exact AmigaOS executable I am executing. The executable I have in mind (ie PDPCLIB "hello world") only uses a handful of SysBase calls.

Again, as long as these are *your* binaries you are starting, the interface is *up to you*. That is fine. However, as soon as you attempt to run any arbitrary AmigaDos binary, you need to build an AmigaDos enviroment for it, and that is done by RunCommand(). Same goes for loading them. As long as you want to load your binaries, use whatever format suits you. But if you want to load AmigaDos binaries, the interface is LoadSeg().

Originally Posted by kerravon

I'm a C runtime library author with my own startup code. The interface is exactly defined by what registers I receive from the OS (AmigaOS or AmigaPDOS or Tripos or Atari TOS).

That is the interface from AmigaOs to your program. This is usually taken care of by the compiler and the startup code it links to your code. No worries, that is taken care of. I am talking about the other interface, namely from your program to AmigaOs binaries. What you probably do not realize is that this interface is also defined through AmigaOs functions, and AmigaOs binaries expect to be started in a particular way, and this "particular way" is this function.

Originally Posted by kerravon

I'm confused what you're saying there. Are you talking about a function in a dos.library file that is linked into the executable when it is called by the C library (e.g. SAS/C) or are you talking about the SysBase structures that lead to a DOSBase pointer if you follow the links?

Amiga libraries are not statically linked to your binary (except through a stub function in amiga.lib, we had this before). I am talking about the problem of how to run from your code an AmigaOs binary. I do not know whether this is something you plan to do or not, but if you you, there is a function that does exactly that. Use this function, or you cannot safely start such binaries.

Originally Posted by kerravon

Perhaps not. Are you saying that I should be using the OpenLibrary() function provided by Commodore instead of writing my own?

Not in specific. The problem is much more general. The problem is "how does software work". An interface is a protocol by which different software programs interoperate. This protocol can be either defined by a series of "registers to be filled properly", but in this case, it is not. The interface for "call a binary" is RunCommand(), and the interface for "load a binary" is LoadSeg(). These interface functions exist because their implementation is opaque and may include features that are necessary, but not documented for some reason or another.



An implementation is a specific function that implements an interface, i.e. concrete code. That code, however, exists already, in dos.library. The reason why this is so particular important is that AmigaDos carries a lot of legacy cruft around, and if you want to be compatible, you better use the Os functions to do all this nonsense correctly that is not fully written down.

Originally Posted by kerravon

If so, sure, that makes sense, but I'm writing a partial clone, so I am cloning the functionality of AmigaOS, including writing my own OpenLibrary(0 function (that's effectively what I've done, but I didn't call it that).

Again, that is probably wasteful, but the waste matters little as long as that is only "within your own enviroment". I don't mind what happens in there. However, as soon as you attempt to open a system library with your own function, instead of the system function, you have a problem. As soon as you run a system binary with your own function, rather the system function, you have a problem. As soon as you load a system binary with your own function, rather than the system function, you have a problem.


Thus, if your VM stays "tight shut" to the host environment, all fine. As soon as it interferes with the surrounding world, it need to use the interfaces of this surrounding world instead of inventing or reimplementing them.

[kerravon]

Originally Posted by Thomas Richter

For an application program, the problem doesn't exist, not nowadays anymore. As an application program, you shouldn't depend on the legacy Tripos cruft. Problem is: This is a retro platform, and such programs exist, like it or not.

Tripos itself existed, and presumably didn't have all the AmigaOS functionality. So it would be interesting to port PDPCLIB to that interesting environment. I learned a shitload doing this 68000 work. AmigaOS using memory address 4 instead of doing a Trap blew my mind away. It gave me a concept I didn't have, despite programming for more than 3 decades.

The problem exists as long as you want to start a binary, or load a binary for that matter. Again, the interface for loading the binary is LoadSeg(), another dos.library function. It does hunk loading much better and reliable than any program you can write, despite that it is a waste of time re-implementing things that are already present.

I don't consider it to be a waste of time. The AmigaOS executables I wish to run will exist on my FAT-16 hard disk which is probably not a real disk but instead a large file on an Amiga filesystem. AmigaOS will not even know about it, and it has no ability to load it. I will load it myself.

The environment is always the same, just that a BCPL program uses it in a different way. For a BCPL program, a1 is the stack pointer, and it is maintained through the functions in a5 and a6 that call a function and return from a function. What RunCommand() does is that it prepares an environment that is both going to work for BCPL and C.

If the environment exists for both, I may as well just use the C interface I am currenly using. However, if I wish my executable to work on BOTH AmigaOS and Tripos, then I would be interested in knowing whether that was possible. Or whether there is no choice but to build a separate Tripos executable. Still 1986 here.

Again, as long as these are *your* binaries you are starting, the interface is *up to you*. That is fine.

Not quite. Yes, they will be my binaries (or other binaries that are aware of the just-invented D7). But the interface still needs to pay lip service to the AmigaOS interface, because I wish for my binaries to run on AmigaOS TOO.

However, as soon as you attempt to run any arbitrary AmigaDos binary, you need to build an AmigaDos enviroment for it, and that is done by RunCommand().

The problem is deeper than that. I can't run any arbitrary AmigaDOS binary at all. Unless it's just an assembler program that does the equivalent of return (7); Because I don't have control of address 4, and everyone else has (effectively) hardcoded that number instead of using the D7 interface.

Same goes for loading them. As long as you want to load your binaries, use whatever format suits you. But if you want to load AmigaDos binaries, the interface is LoadSeg().

No, I can't choose an arbitrary format, because I want my binaries to run on AmigaOS too. I wonder if someone else needs to step in to explain what I am saying, because we appear to have a disconnect.

That is the interface from AmigaOs to your program. This is usually taken care of by the compiler and the startup code it links to your code.

I'm the author of that startup code.

No worries, that is taken care of. I am talking about the other interface, namely from your program to AmigaOs binaries. What you probably do not realize is that this interface is also defined through AmigaOs functions, and AmigaOs binaries expect to be started in a particular way, and this "particular way" is this function.

I can gradually add all the functionality of the RunCommand() or whatever to set up a fully-operational environment, but it's fairly pointless because nothing will run unless it observes the D7 standard which was invented less than 24 hours ago.

Amiga libraries are not statically linked to your binary (except through a stub function in amiga.lib, we had this before). I am talking about the problem of how to run from your code an AmigaOs binary. I do not know whether this is something you plan to do or not, but if you you, there is a function that does exactly that. Use this function, or you cannot safely start such binaries.

No, AmigaOS will not be involved in the loading of the binaries that I run once AmigaPDOS is active.

Not in specific. The problem is much more general. The problem is "how does software work". An interface is a protocol by which different software programs interoperate. This protocol can be either defined by a series of "registers to be filled properly", but in this case, it is not. The interface for "call a binary" is RunCommand(), and the interface for "load a binary" is LoadSeg(). These interface functions exist because their implementation is opaque and may include features that are necessary, but not documented for some reason or another.

AmigaPDOS will not be doing either of those things. It's not possible to get RunCommand() to execute a binary on my FAT-16 emulated disk file. Unless I write RunCommand() myself. I will effectively have a mini-RunCommand. It will be good enough to run a PDPCLIB "hello world" program.

An implementation is a specific function that implements an interface, i.e. concrete code. That code, however, exists already, in dos.library. The reason why this is so particular important is that AmigaDos carries a lot of legacy cruft around, and if you want to be compatible, you better use the Os functions to do all this nonsense correctly that is not fully written down.

At the moment I'm only trying to be compatible with PDPCLIB-based AmigaOS executables. They don't rely on anything that isn't written down. We can negotiate other binaries later, but it's a complete non-starter if they don't respect D7.

Again, that is probably wasteful, but the waste matters little as long as that is only "within your own enviroment". I don't mind what happens in there. However, as soon as you attempt to open a system library with your own function, instead of the system function, you have a problem. As soon as you run a system binary with your own function, rather the system function, you have a problem. As soon as you load a system binary with your own function, rather than the system function, you have a problem.

None of these things even exist yet. To start with a dos.library will be able to be found, but again, only by people who respect D7. Address 4 is someone else's code, not mine.

Thus, if your VM stays "tight shut" to the host environment, all fine. As soon as it interferes with the surrounding world, it need to use the interfaces of this surrounding world instead of inventing or reimplementing them.

As far as I know, I am following all of the rules expected by AmigaOS. D7 is an extension (that only gets set and used when an executable detects (via D0 being 2 GiB or more) that it is in an AmigaPDOS environment, not AmigaOS), not a requirement.

[Thomas Richter]

Originally Posted by kerravon

Tripos itself existed, and presumably didn't have all the AmigaOS functionality.

AmigaDOS aka dos.library is essentially identical to Tripos, at least for Kickstart 1.3 and below. You will notice that the AmigaDos Manual from Bantam books is essentially a reprint of the Tripos manual, just with Tripos replaced by AmigaDos.

Originally Posted by kerravon

I don't consider it to be a waste of time. The AmigaOS executables I wish to run will exist on my FAT-16 hard disk which is probably not a real disk but instead a large file on an Amiga filesystem. AmigaOS will not even know about it, and it has no ability to load it. I will load it myself.

Why do you believe that? There is InternalLoadSeg() which takes, as a source, a call-back hook instead of reading from a file handler.

Originally Posted by kerravon

If the environment exists for both, I may as well just use the C interface I am currenly using. However, if I wish my executable to work on BOTH AmigaOS and Tripos, then I would be interested in knowing whether that was possible. Or whether there is no choice but to build a separate Tripos executable. Still 1986 here.

The dos.library back then was build in the Tripos environment, as it is in major parts written in BCPL, along with the console, the file system, the port handler, the shell, all the commands in C: and maybe some other stuff I forgot. All of this became C and assembler, a job that was mostly done in the "arp" project which CBM integrated.


Back in that time, you used the Metacomco BCPL compiler for it which depended on this environment. Not sure whether a copy of this still exists.


This is all not surprising as it seems - note again that the dos.library *is* Tripos (or, back then, was - it is different today) CBM was short of a file system/dos for its Amiga, and could not complete its own in time, so they just bought Tripos.

Originally Posted by kerravon

Not quite. Yes, they will be my binaries (or other binaries that are aware of the just-invented D7). But the interface still needs to pay lip service to the AmigaOS interface, because I wish for my binaries to run on AmigaOS TOO.

Why? And how, given that there is no MS-Dos interface.

Originally Posted by kerravon

AmigaPDOS will not be doing either of those things. It's not possible to get RunCommand() to execute a binary on my FAT-16 emulated disk file. Unless I write RunCommand() myself. I will effectively have a mini-RunCommand. It will be good enough to run a PDPCLIB "hello world" program.

RunCommand() does not require a file system. It requires a segment. A segment is a "loaded binary", something LoadSeg() (or InternalLoadSeg()) returns. InternalLoadSeg() does not require a file system either.

Originally Posted by kerravon

None of these things even exist yet. To start with a dos.library will be able to be found, but again, only by people who respect D7. Address 4 is someone else's code, not mine.

Note well, it is not only AmigaOs binaries that read from address 4, but pretty much everything else as well. System libraries, as well as other tasks running at the same time. This is a multitasking Os, after all.

[kerravon]

Originally Posted by Thomas Richter

Why do you believe that? There is InternalLoadSeg() which takes, as a source, a call-back hook instead of reading from a file handler.

Ok, so maybe it is possible then. But the moment I give control of my binary to AmigaOS, it will stop accessing the emulated FAT-16 disk I am using. And it defeats the purpose of writing an OS anyway.

Why? And how, given that there is no MS-Dos interface.

I want my OS to run on the 68000. So I just need a BIOS. I now know how to write a suitable BIOS. My "hello world" AmigaOS executable will call AmigaPDOS for AmigaOS services like Read(). AmigaPDOS will then call the BIOS (bios.c) to (effectively) request sector xxx of the emulated hard disk. bios.c will then use real AmigaOS as *its* BIOS, via a read() call again. AmigaOS will use its BIOS, Kickstart.

I don't need an MSDOS interface for this to work (although AmigaPDOS internally will use something similar to an MSDOS API, in preparation for MSDOS-like calls). Everything will look like MSDOS, and you will get a "C:\>" prompt and you can do "type config.sys" or whatever and all the executables will be called xxx.exe (no choice). But it will run D7-aware pure AmigaOS executables to start with.

Note well, it is not only AmigaOs binaries that read from address 4, but pretty much everything else as well. System libraries, as well as other tasks running at the same time. This is a multitasking Os, after all.

I will not be using or interfering with address 4. The SysBase that AmigaPDOS uses will be dependent on wherever bios.c gave it memory, which of course was returned by AmigaOS.

This might qualify as a VM, I'm not sure. I won't have access to address 4, so it's probably not a real VM. You can consider AmigaPDOS to just be an "unusual application". It is an OS sitting there waiting for a BIOS, and I've provided a suitable BIOS by simply leveraging off AmigaOS. Thanks to this new concept of not needing to intercept Traps, it should be possible for AmigaPDOS to technically appear (to AmigaOS) to be a "normal AmigaOS application".

[Docent]

Originally Posted by kerravon

Ok, so maybe it is possible then. But the moment I give control of my binary to AmigaOS, it will stop accessing the emulated FAT-16 disk I am using. And it defeats the purpose of writing an OS anyway.


I want my OS to run on the 68000. So I just need a BIOS. I now know how to write a suitable BIOS. My "hello world" AmigaOS executable will call AmigaPDOS for AmigaOS services like Read(). AmigaPDOS will then call the BIOS (bios.c) to (effectively) request sector xxx of the emulated hard disk. bios.c will then use real AmigaOS as *its* BIOS, via a read() call again. AmigaOS will use its BIOS, Kickstart.

So basically you want to implement your bios to run your PDOS and programs for it that are compatible with PDOS/msdos (at least at the source level) on top of AmigaOS to have access to hd/files etc. and other devices.
These programs will be kept in Amiga hunk format as you plan to load and run some of Amiga programs later. I assume that only console Amiga programs will be considered due to text only interface offered b PDOS.
This is some sort of running hosted - the method I described on at the beginning of this thread

I think that the best approach would be to make an Amiga console application (PDOSShell) that will present a console/Dos type shell in Amiga window. When someone enters a name at the prompt, PDOSShell checks if a program is for Amiga or PDOS and call LoadSeg for Amiga programs and your own hunk loader for PDOS ones. Then you will be able to offer Amiga environment, arranged by dos.library to run Amiga programs, redirecting their output to your window. Your PdosBase will be useless for Amiga programs but for PDOS ones you can present your PDosBase/API as you like in any register and form.
PDOSShell will take care of managing filebased fat pseudopartitions like c: etc. reading/writing from them, generally will handle BIOS interface call mapping and PDOS calls into Amiga equivalents as needed.
Actually, if I was going to implement it, I'd use a device like, for example, diskimage.device from Aminet to mount images and access them from both AmigaOS (via CrossDos filesystem) and PDOS side, or directly reading blocks via such device for PDOS fat implementation.

[kerravon]

Originally Posted by Thomas Richter

This can be either statically linked to the binary as form of a function library, or can be part of an external dynamic library programs open. This happened for the posix interface layer, for example, which is implemented through a library named iexemul.

First of all, I think I now understand this aspect of things. I previously didn't understand what you were saying. Sorry for taking so long! Let me see if I now have this right.

*At a later date* to *extend AmigaOS* (even if due to technical limitations the functionality only actually appears in AmigaPDOS), I should have a pos.library in the same linked list in ExecBase where I currently find dos.library. "Pos" is what I call my MSDOS-inspired API. It was also inspired by OS/2 which has functions like DosOpen(). Inspired by the word "Dos" I created "Pos" so as to not conflict, and provide an API that would be restricted to what an MSDOS INT 21H could handle.

The purpose of PDOS/3X0 is to run stock-standard MVS executables, rather than creating my own API.

The purpose of AmigaPDOS should be to run stock-standard AmigaOS executables, rather than creating my own API.

If I do create an extended API, that is fine as a separate exercise, but it should ideally fit in with the existing AmigaOS API, rather than having some pointer directly of SysBase or something like that. The AmigaOS way of adding extended functionality is to have a new .library accessible via OpenLibrary() which goes to a linked list off SysBase.

But let's forget about extensions for now, and focus on a subset of the actual AmigaOS API. ie applications should be able to do Read() which is documented.

Having said that, due to a technical quirk that doesn't exist in other environments like MVS and Windows, it is necessary to first extend the AmigaOS published API to introduce the concept of an *optional* SysBase override via D7.

Anyone who is interested in running under an alternative AmigaOS-compatible environment such as AmigaPDOS is expected to recompile their software after updating the startup code with about 10 lines of code. If no-one else is willing to cooperate with their startup code, so be it, AmigaPDOS will only ever be able to run PDPCLIB-based programs where the startup code has definitely been updated. The sort of AmigaOS executables I plan to run, such as GCC 3.2.3, will be linked with PDPCLIB, so there's one HUGE (3 MB executable, 400,000 lines of C code) application that is expected to work. I consider that to be a great technical achievement and will be happy to end my work there.

However, I would now like to consider spreading AmigaPDOS elsewhere, specifically the 80386 and x64 (ie a 64-bit version of it). The 80386 has a suitable BIOS to run AmigaPDOS too. An identical BIOS in fact.

Obviously all applications, plus the OS itself, will need to be recompiled to produce 80386 code. That's fine. I have a compiler available. But the applications will need to have a C runtime library available too, which is also fine, that's what the Amiga target is for, and fread() will call Read() and Read() (currently as 68000 assembler) will need to be rewritten in 80386 assembler, perhaps even doing an INT 22H (to separate it from MSDOS INT 21H), or, more likely it will be written in C code instead, to call a DOSBase->Read() function, since the interface is necessarily different due to different registers being used. It will all be hidden in Read(), and so long as everyone follows the rules, everything will be fine.

The SysBase will still be the same, still a linked list that contains "dos.library".

I can't see any reason why this can't run on the mainframe either, which also provides an identical BIOS.

The executable format for 80386 will probably be a.out, and the startup code is necessarily different as well, registers d0 and a0 do not exist, and in this case I think should make the interface a normal function call that expects 3 parameters, like this:

int amigaentry(unsigned long cmdlen, char *cmd, void *sysbase)

There is no choice but to provide the sysbase. There is no sensible address to hardcode. You certainly can't assume that "4" is going to be available.

With all this in place I can build and run the 80386 version of AmigaPDOS (and the applications that run under it, such as "hello, world") on my Windows box. A recompilation with vbcc should see it running just fine on the 68000 too. And the binaries that run under the 68000 version will also run fine on genuine AmigaOS.

Finally, I have the outlines for a different version of PDOS called PDOS-generic. This doesn't attempt to clone someone else (MVS, MSDOS, AmigaOS) API, but will introduce its own API. This API will be called osfunc(). All OS calls will be routed through that, and PDOS-generic will handle those requests. When running PDOS-generic executables on PDOS-generic on a 68000 machine, e.g. Atari, I will reuse the hunk format, since I already have code to handle that, and it's not very important, but I will change the magic cookie from 000003F3 to say 00000F3F to signify that it is not going to work under AmigaOS, because PDOS-generic does not call executables that expect this:

int amigaentry(unsigned long cmdlen, char *cmd, void *sysbase)

and especially not d0/a0/d7 being set.

PDOS-generic will alter the FAT format to take certain directory entry bits to signify things like "text" or "binary" depending on whether the file in question was written out using fopen "w" or "wb". It will also have an EBCDIC/ASCII indicator so that different character sets can be intermingled.

Sound like a plan? As far as I can tell, most of the code to do what I want for both AmigaPDOS and PDOS-generic (on all environments) is already written, I just need to piece it together.

[kerravon]

Originally Posted by Docent

So basically you want to implement your bios to run your PDOS and programs for it that are compatible with PDOS/msdos (at least at the source level) on top of AmigaOS to have access to hd/files etc. and other devices.

I believe that is correct.

These programs will be kept in Amiga hunk format as you plan to load and run some of Amiga programs later. I assume that only console Amiga programs will be considered due to text only interface offered b PDOS.

That is correct. I'm also hoping that if I do this:
osfunc(OS_PRINTF, 0, "\x1b[2J");
which will be translated into a standard Write() to AmigaOS Output() handle, that someone will have provided an ANSI terminal for me (micro-emacs, actually).

This is some sort of running hosted - the method I described on at the beginning of this thread

Ok, cool. It took me a while to come around to that. :-)

I think that the best approach would be to make an Amiga console application (PDOSShell) that will present a console/Dos type shell in Amiga window. When someone enters a name at the prompt, PDOSShell checks if a program is for Amiga or PDOS and call LoadSeg for Amiga programs and your own hunk loader for PDOS ones. Then you will be able to offer Amiga environment, arranged by dos.library to run Amiga programs, redirecting their output to your window. Your PdosBase will be useless for Amiga programs but for PDOS ones you can present your PDosBase/API as you like in any register and form.
PDOSShell will take care of managing filebased fat pseudopartitions like c: etc. reading/writing from them, generally will handle BIOS interface call mapping and PDOS calls into Amiga equivalents as needed.
Actually, if I was going to implement it, I'd use a device like, for example, diskimage.device from Aminet to mount images and access them from both AmigaOS (via CrossDos filesystem) and PDOS side, or directly reading blocks via such device for PDOS fat implementation.

Sounds good. I will just get the basic concept proven and then leave it to others to play around with. My BIOS will just be reading/writing to a flat file, although you will be able to provide any file you like for that, so it is limited by AmigaOS.

Basically you will go:
bios.exe AmigaPDOS.exe flatfile.dat

flatfile.dat will be accessed with Open(), Read(), Seek() (I think), which is what PDPCLIB will be using.

I don't know if you can simply point flatfile.dat to some sort of raw device.

[defor]

I ran through this whole discussion because, at the beginning, I thought OP wanted to create some tiny micro operating system (with a simple text console and a filesystem?) which would boot directly from the diskette on the Amiga, independent on AmigaOS. That OS would allow him to run his own programs (even built by his own ported C compiler?) which would use his own API to call his own OS functions.
It would be interesting. Implementing some simple filesystem (obviously own trackdisk reader is needed), keyboard input, text output, memory management, ...
I was a little skeptical because OP apparently thought that the Amiga had some "PC BIOS" available which already does it all. Yet I thought maybe he would program it himself.
I reckon it's a big big feat to implement it all.
Seems that nothing like that is planned. Honestly, I even don't know what is planned and what is the purpose of it all.

My question is: Maybe something like that already exists on the Amiga? Some micro OS booting from diskette, with documentation how to program for it. I remember that some trackmos (by Sanity? by Chaos?) contained a simple "OS" (I think demo Arte can crash into its console).

[kerravon]

Originally Posted by defor

Honestly, I even don't know what is planned and what is the purpose of it all.

You will have an OS that looks like MSDOS except it uses Amiga hunks. Two different APIs are planned - generic (osfunc) and standard AmigaOS. That means two different executable formats, so the magic cookie for generic will probably change from 000003F3 to 00000F3F. AmigaPDOS will be able to handle both executable formats. AmigaPDOS will be dependent on a "bios" for basic disk services. That is an independent product. When running on the Atari, the bios will need to be rebuilt, but AmigaPDOS will be binary identical. So if you wish to run an MSDOS-like system, you can run it on either the Amiga or the Atari and probably other 68000-based systems, just by recompiling the bios. The bios itself will have a generic version (along with potential standalone versions), dependent on the standard C library of the host (or in the case of AmigaOS, PDPCLIB can be used, since AmigaOS is a target already).

I'll probably develop "generic" first, since I can get that working on my Windows machine. And then a simple recompilation of the C code should activate it for AmigaOS. Unless I'm missing something.

[defor]

Originally Posted by kerravon

You will have an OS that looks like MSDOS except it uses Amiga hunks

Originally Posted by kerravon

AmigaPDOS will be dependent on a "bios" for basic disk services. That is an independent product.

Thank you for explanation.
Unfortunately it seems that it is of no use for me. I'm looking for something similar to what I described in my previous post. Something simple. Targeted for programmers who want to play with old Amigas in non-system way (direct access to custom registers) but who want to have an access to some filesystem on diskette (read/write files). Something, what I believe, many demoscene coders were tinkering with to simplify process of producing trackmos.

Honestly, I don't know what "BIOS" are you referring to ("independent product"). IMHO there is nothing like a BIOS. If your OS wants to access diskdrive and read a file data, you must either keep AmigaOS running, or write your own trackdisk loader (or use some existing one). Situation gets even worse if you want to allow your system to read from HDD. There might be some available code not dependent on AmigaOS which can read/write tracks, but I guess you must find such for every existing most popular HDD drivers on Amiga platform.
So it seems to me that your are likely talking about some "PDOS emulator" or "PDOS virtual machine" running on AmigaOS, using AmigaDOS to access existing Amiga filesystem (filesystems, in fact, because there are a lot of them). I don't understand why you want to use amiga hunks as your chosen format for executables, but whatever. I wish you good luck with your endeavour but it departs too much from what I am looking for.

[Bruce Abbott]

Originally Posted by kerravon

The purpose of AmigaPDOS should be to run stock-standard AmigaOS executables, rather than creating my own API...

That's silly. Amigas already have a perfectly good API for running Amiga executables. To run all 'stock-standard' Amiga executables under PDOS you would need to emulate the entirety of the Amiga OS API, which is pointless.

Anyone who is interested in running under an alternative AmigaOS-compatible environment such as AmigaPDOS is expected to recompile their software after updating the startup code with about 10 lines of code.

In that case you can ignore the requirements of BCPL programs, because nobody programs Amiga applications in it. But you also have to consider that most Amiga applications call many functions in Amiga OS, and expect to see the rich environment that it provides.

fread() will call Read() and Read() (currently as 68000 assembler) will need to be rewritten in 80386 assembler, perhaps even doing an INT 22H (to separate it from MSDOS INT 21H), or, more likely it will be written in C code instead, to call a DOSBase->Read() function, since the interface is necessarily different due to different registers being used...

Sound like a plan?

A plan, but not a great one.

I would do the minimum required to implement a 'generic' API, with such things as DOSbase or INT21 hidden inside a low level module that even your library code calls via the PDOS API. C knows nothing about DOSbase or INTs, so you should not be discussing them except in regards to the low level implementation of PDOS on different platforms. The API will only be valid for C source code that uses generic functions, because the machine code generated will be quite different depending on the host platform.

In short, your OS should be designed to provide exactly the same source code API on all platforms, and application code should compile for any host platform with no changes. To do that the code should be pure generic C with no references to platform specific stuff or analogs of such. The OS source should also be fully generic except for a small low level interface module to the host API.

[kerravon]

Originally Posted by defor

Honestly, I don't know what "BIOS" are you referring to ("independent product"). IMHO there is nothing like a BIOS.

There is now. You can see it here:

https://sourceforge.net/p/pdos/gitco...ter/tree/bios/

and it has been confirmed to run on AmigaOS.

If your OS wants to access diskdrive and read a file data, you must either keep AmigaOS running,

Correct, AmigaOS stays running.

Situation gets even worse if you want to allow your system to read from HDD.

That's between the BIOS and AmigaOS. Currently if AmigaOS provides the ability to access a raw hard disk via fopen(), then no further change is required. Otherwise, custom #ifdef will need to be put into bios.c to get it to call the appropriate AmigaOS function to get access to the HDD.

So it seems to me that your are likely talking about some "PDOS emulator" or "PDOS virtual machine" running on AmigaOS, using AmigaDOS to access existing Amiga filesystem (filesystems, in fact, because there are a lot of them).

I don't know whether you call it an emulator or virtual machine or neither. Executables will run at native speed, so I'm not sure that's an emulator. PDOS doesn't expect to have access to location 4 either, or any fixed address at all for that matter.

I don't understand why you want to use amiga hunks as your chosen format for executables

I already know how to produce them (type "pdmake -f makefile.ami" in PDPCLIB). Anything else requires research and potentially more software. They are eventually needed anyway to run AmigaOS executables. So no reason not to start supporting Amiga hunks right from the start. Anyway, it's a done deal. I've written a basic Amiga hunk loader. It's crude and incomplete, but it is already enough for "proof of concept".

Note that AmigaOS massively inspired this "generic PDOS". Couldn't have done it without AmigaOS and you guys helping me to understand how it works. Operating via fixed address 4 (and the need to relocate that address for my own use) was the breakthrough I needed. Before that I was stuck in "everything needs to be done via Trap or the OS needs to fill in DLL locations for the executable". I did know about the CVT in MVS, and I knew it was used for Unix calls, but I didn't make the connection that it could ALL be done via a fixed location.

[kerravon]

Originally Posted by Bruce Abbott

That's silly. Amigas already have a perfectly good API for running Amiga executables.

But the Atari doesn't. Nor does any other arbitrary 68000 machine.

To run all 'stock-standard' Amiga executables under PDOS you would need to emulate the entirety of the Amiga OS API, which is pointless.

My goal is only to run SOME stock-standard Amiga executables under PDOS, not ALL of them. E.g. GCC is a 3 MB executable. I bet I can get it to run under PDOS.

In that case you can ignore the requirements of BCPL programs, because nobody programs Amiga applications in it. But you also have to consider that most Amiga applications call many functions in Amiga OS, and expect to see the rich environment that it provides.

Sure. They're also not C90-compliant. My main interest is C90-compliant applications.

A plan, but not a great one.

I don't actually understand the difference between your plan and mine. Can you explain that?

I would do the minimum required to implement a 'generic' API, with such things as DOSbase or INT21 hidden inside a low level module that even your library code calls via the PDOS API. C knows nothing about DOSbase or INTs, so you should not be discussing them except in regards to the low level implementation of PDOS on different platforms. The API will only be valid for C source code that uses generic functions, because the machine code generated will be quite different depending on the host platform.

That's what I've got. A function called osfunc(). I'm currently using osfunc() to call the BIOS, but I'm thinking that I should rename that one to biosfunc() so that the PDOS-generic operation system can have an osfunc() itself, that receives request from applications, calls its own C90 library, which gets translated into a PosOpenFile() or whatever (this name is internal use only), which in turn reads a FAT hard disk by making biosfunc() calls.

In short, your OS should be designed to provide exactly the same source code API on all platforms, and application code should compile for any host platform with no changes. To do that the code should be pure generic C with no references to platform specific stuff or analogs of such. The OS source should also be fully generic except for a small low level interface module to the host API.

I'll take you one step further. Even the OS itself will be fully generic. The low level interface is the BIOS, a separate entity. See here:

https://sourceforge.net/p/pdos/gitco...ee/bios/bios.c

I'm open to suggestions on improvement, before I get too deep down the wrong path. But so far it's all working. On 3 completely different platforms.

[kerravon]

Originally Posted by kerravon

you guys helping me to understand how it works.

Also it was you guys who even explained the very purpose of a BIOS to me, to separate the hardware. Previously (in PDOS/386) I had mixed the replacement BIOS (including dealing with hardware interrupts) in with the OS. And on the mainframe there was no concept of a BIOS at all. I wondered why that was the case, but it never occurred to me that one should actually be written for it. Once again I mixed what was basically a BIOS in with the OS.

[kerravon]

Originally Posted by kerravon

That's what I've got. A function called osfunc(). I'm currently using osfunc() to call the BIOS, but I'm thinking that I should rename that one to biosfunc() so that the PDOS-generic operation system can have an osfunc() itself, that receives request from applications, calls its own C90 library,

I think I have it. You call osfunc() to do an OS_FREAD, ie you are requesting something from what you consider to be an "operating system" (others would call it "the bios"). But you can also export your OWN C library to those under you, and when you do that, you create your own internal function, own_osfunc() to receive such requests.

There could be a chain of 10 systems, all passing an OS_FREAD request up, until someone reads an actual physical hard disk. And there could be CPU switches along the way, ie 68000 to 80386, or just mode switches, e.g. 8086 to 80386 to x64.

[kerravon]

Originally Posted by kerravon

I think I have it. You call osfunc() to do an OS_FREAD, ie you are requesting something from what you consider to be an "operating system" (others would call it "the bios"). But you can also export your OWN C library to those under you, and when you do that, you create your own internal function, own_osfunc() to receive such requests.

I have revamped it again, and you can see the new suggestion here:

https://groups.google.com/g/alt.os.d.../c/D0PvjBFiNhY

in the second message (which you only seem to be able to see if you wait a while and then click down the bottom to refresh).