PDOS for Amiga

[kerravon]

Originally Posted by kerravon

Note that I just realized that bios.exe may not work because opening/seeking/reading files hasn't been tested yet.

But if you recompile bios.c with your own C compiler/library, it might work.

[Thomas Richter]

Originally Posted by kerravon

No, you don't understand what I am trying to do.

First and foremost, I don't understand *why* you want to do that. MS-DOS is a mostly irrelevant "operating" system today, as is AmigaOs.

Originally Posted by kerravon

People who link with PDPCLIB will start messing with ExecBase without even knowing it, if I choose to implement my own ExecBase extensions (which I totally can).

If you want to create a link library, then that is also possibly fine. Note, however, that AmigaOs does not fill A6. Or rather, programs run through the shell will get a value in a6, but it is certainly not SysBase. Thus, you will need to provide a startup code, and this startup code will need to fetch SysBase from a6 because that's where you get system services from. For example, you will need to open dos.library to speak to the file system.


This is typically the startup code from the compiler (c.o for SAS/C).

Originally Posted by kerravon

That is not correct. All my MSDOS software will run on it after a simple recompile. Assuming you are running AmigaPDOS.

Not only recompilation. They would need to link to a compatibility layer which is aparently what you are preparing.

Originally Posted by kerravon

AmgaOS developers don't speak with one voice. Some of them check a6.

AmigaOs developers use the AmigaOs API, otherwise their programs would not run on AmigaOs, and the AmigaOs API does not fill A6 with SysBase.

Originally Posted by kerravon

The new API will be an ADDITION to SOME of the AmigaOS API, so, you are incorrect, it WILL run SOME AmigaOS programs. Specifically ones that abide by the a6 convention and use a very limited set of AmigaOS API calls.

Once again, in case you misunderstand: A6 already has a value. It is not SysBase, and it is not the base of any library you prepare. Of course you can deviate from the AmigaOs API, but then you would not be able to run AmigaOs programs. AmigaOs programs do not expect SysBase in a6, though some are expecting the BCPL "return from function" function in a6.

[kerravon]

Originally Posted by Thomas Richter

First and foremost, I don't understand *why* you want to do that. MS-DOS is a mostly irrelevant "operating" system today, as is AmigaOs.

My MSDOS programs will also run on a 64-bit z/Arch or x64 or any other environment once I port PDOS to it.

If you want to create a link library, then that is also possibly fine.

No, I don't want to do that.

Note, however, that AmigaOs does not fill A6.

Sure. That's why you need to run them under AmigaPDOS instead *depending* on what you want to do.

Or rather, programs run through the shell will get a value in a6, but it is certainly not SysBase.

Sure.

Thus, you will need to provide a startup code, and this startup code will need to fetch SysBase from a6 because that's where you get system services from.

Yes, I already have that.

For example, you will need to open dos.library to speak to the file system.

Yes, I already do that too. That is in fact the ONLY library I open.

This is typically the startup code from the compiler (c.o for SAS/C).

Your code didn't make it through, but it doesn't matter, my own code is working fine.

Not only recompilation. They would need to link to a compatibility layer

No, that is not correct. All they need to do is use the "right" C90 runtime library.

which is aparently what you are preparing.

I'm not sure we're on the same page, but I think we're getting there. :-)

AmigaOs developers

I'm one of those.

use the AmigaOs API,

Yes, I do too.

otherwise their programs would not run on AmigaOs,

My programs run just fine on AmigaOs.

and the AmigaOs API does not fill A6 with SysBase.

No, but AmigaPDOS does, which may not be "just as good", but it is "interesting".

Once again, in case you misunderstand: A6 already has a value.

If A6 already has a value, then I don't want to use A6. I need an unused (by AmigaOS - any version) register. Unused as far as any AmigaOS applications expecting a sensible value in there. If there are ANY AmigaOS applications inspecting A6 for ANY purpose, then I do NOT want to use A6 and can you please suggest a different register.

It is not SysBase,

It is when that exact same AmigaOS executable is running under AmigaPDOS.

and it is not the base of any library you prepare. Of course you can deviate from the AmigaOs API, but then you would not be able to run AmigaOs programs.

I wish to run a *subset* of *valid* AmigaOS programs.

AmigaOs programs do not expect SysBase in a6,

AmigaOs programs do not speak with one voice. SOME of them ACCEPT (not *expect*) SysBase in a6.

though some are expecting the BCPL "return from function" function in a6.

Ok, then sudden change of plan. Please suggest a different register that no-one else is expecting to be set to a sensible value.

[Thorham]

In AmigaOS a6 is used as the library base for library function calls, including those of the OS. When calling an OS function, d0, d1, a0 and a1 are assumed to be scratch registers, so don't depend on their value after the call.

That's all there's to it. Basically you can do what you want. Except when calling a library function (including the OS) you can use any registers for whatever you want.

[kerravon]

Originally Posted by Thomas Richter

If you want to create a link library, then that is also possibly fine.

Sorry, I might have answered this incorrectly. I wish to link MSDOS-API-using applications with some object code called pos.o. That can be put in a library instead of being a single object file if that would be more convenient to someone.

pos.o will contain functions like this:

int PosOpenFile(const char *name,
int mode,
int *handle)
{
return (SysBase->PosOpenFile(name, mode, handle));
}

Note that I'm going to do it that way to prove that it can be done, but later on I will change that to:

PosBase->PosOpenFile(name, mode, handle));

And yes, those MSDOS-API-using AmigaOS executables will crash and burn when run under AmigaOS, because there is no such function PosOpenFile there.

However, when that exact same AmigaOS executable is run under AmigaPDOS, it will work just fine.

For reference, the MSDOS and PDOS/386 version of PosOpenFile() are defined completely different from the AmigaPDOS version, but users of the program will not notice one iota of difference, and all versions (AmigaPDOS, PDOS/386, PDOS/86 and future PDOS/3X0-generic) will run at native speed after recompilation.

BFN. Paul.



int PosOpenFile(const char *name,
int mode,
int *handle)
{
union REGS regsin;
union REGS regsout;
struct SREGS sregs;

regsin.h.ah = 0x3d;
regsin.h.al = (unsigned char)mode;
#ifdef __32BIT__
regsin.d.edx = (unsigned int)name;
#else
sregs.ds = FP_SEG(name);
regsin.x.dx = FP_OFF(name);
#endif
int86x(0x21, &regsin, &regsout, &sregs);
#ifdef __32BIT__
if (regsout.x.cflag) return (regsout.d.eax);
*handle = regsout.d.eax;
#else
if (regsout.x.cflag) return (regsout.x.ax);
*handle = regsout.x.ax;
#endif
return (0);
}

[kerravon]

Originally Posted by Thorham

In AmigaOS a6 is used as the library base for library function calls, including those of the OS.

Ok, I think I should stay clear of that then. I don't want anything that is known to be used for something else.

When calling an OS function, d0, d1, a0 and a1 are assumed to be scratch registers, so don't depend on their value after the call.

That's all there's to it. Basically you can do what you want. Except when calling a library function (including the OS) you can use any registers for whatever you want.

My question is not regarding calling an OS function. It is what registers are expected to be set when an *application executable* is executed by AmigaOS (any version).

The only ones I know of are d0 and a0. Does anyone at all, ever, in history, ever expect any other registers to be set on entry to their executable? If so, which ones, so that I can avoid them to avoid confusion.

And if d0 and a0 are in fact the only ones actually in use, and all the other registers are free for me to use for my own (AmigaPDOS) purpose, then is there some register you would recommend, to "look the nicest" for my "alternate SysBase"?

[Thomas Richter]

Originally Posted by kerravon

The only ones I know of are d0 and a0. Does anyone at all, ever, in history, ever expect any other registers to be set on entry to their executable? If so, which ones, so that I can avoid them to avoid confusion.

There are, yes. This is all BPCL legacy, but there are certainly more registers. P=A1 is the pointer to the BCPL stack and points to local arguments upon entry. G=A2 is the pointer to the globvec of the called program. A3=L is a work-register that is used upon call and return. B=A4 is the base register and the entry point of the current function. S=A5 is the function pointer to the "call BCPL function". R=A6 is (as stated) the "return from function" function of BCPL. D0 is used to hold the stack increment in function calls, upon entry of a program it holds also the argument counter.


Note that for passing command line arguments, providing them in d0/a0 is not sufficient, any many (if not most) programs in C: do not bother with these registers and they receive command line arguments by other means.



D1-D4 are the first four arguments of a BPCL function call, and D5-D7 are work registers. Thus, as far as passing "secret startup code" to functions, everything from D5 up should be ok.



Note, however, that the protocol for starting an AmigaOs binary is not as simple as loading the command line to a0/d0. The right protocol is through dos.library/RunCommand(), and this function does not allow you to specify any register values to be passed to the called program. It takes the argument line provided, and passes that in an "appropriate" way that is irrelevant.


Thus, to repeat that again, you don't start AmigaOs binaries yourself. You let the dos.library do that, and dos does not provide a mechanism to populate any registers in a non-standard way.

Originally Posted by kerravon

And if d0 and a0 are in fact the only ones actually in use, and all the other registers are free for me to use for my own (AmigaPDOS) purpose, then is there some register you would recommend, to "look the nicest" for my "alternate SysBase"?

The nicest way is either to have this as a link-library and custom startup code of your own binaries, or a public library that is opened by the startup code of your binaries.



Also note that "SysBase" is a reserved name once you want to use any AmigaOs function, it is supposed to point to ExecBase, and only that. Once a program wants to call any function in exec.library, it would require this symbol, and exec requires a6 to be loaded with SysBase, the real one, and nothing else. So you shouldn't use that symbol, it is asking for trouble. PDosBase would be a better name anyhow.

[Thorham]

Originally Posted by kerravon

My question is not regarding calling an OS function. It is what registers are expected to be set when an *application executable* is executed by AmigaOS (any version).

The only ones I know of are d0 and a0. Does anyone at all, ever, in history, ever expect any other registers to be set on entry to their executable? If so, which ones, so that I can avoid them to avoid confusion.

As far as I know, none.

Originally Posted by kerravon

And if d0 and a0 are in fact the only ones actually in use, and all the other registers are free for me to use for my own (AmigaPDOS) purpose, then is there some register you would recommend, to "look the nicest" for my "alternate SysBase"?

Don't pick what looks best, pick what works best, and that depends on how your code works.

[Thomas Richter]

Originally Posted by Thorham

As far as I know, none.

See above, not correct.

[Thorham]

Originally Posted by Thomas Richter

See above, not correct.

That's a lot of registers. What should you do when your programs start?

[kerravon]

Originally Posted by Thomas Richter

Note that for passing command line arguments, providing them in d0/a0 is not sufficient, any many (if not most) programs in C: do not bother with these registers and they receive command line arguments by other means.

It boils down to what PDPCLIB does, not what other C libraries do. And PDPCLIB is going to restrict itself to whatever AmigaPDOS supports. They will grow together. d0/a0 are more convenient for me.

D1-D4 are the first four arguments of a BPCL function call, and D5-D7 are work registers. Thus, as far as passing "secret startup code" to functions, everything from D5 up should be ok.

Ok, I'm going to go with D7, so that Commodore can work their way up from D4 and I can work my way down from D7 and we'll see where we meet. 1986 remember. :-)

Note, however, that the protocol for starting an AmigaOs binary is not as simple as loading the command line to a0/d0. The right protocol is through dos.library/RunCommand(), and this function does not allow you to specify any register values to be passed to the called program. It takes the argument line provided, and passes that in an "appropriate" way that is irrelevant.

This is not relevant. It is AmigaPDOS that is responsible for setting d7 and a0 and d0, not any application.

Thus, to repeat that again, you don't start AmigaOs binaries yourself.

What do you mean "yourself"? AmigaPDOS exactly loads AmigaOS binaries, which is why I have just written an Amiga Hunk loader.

You let the dos.library do that, and dos does not provide a mechanism to populate any registers in a non-standard way.

My dos.library will populate d7. All you need to do is call the documented routine. Or for ease of implementation I may require you to call SysBase->PosExec() for now if you want to do that. But probably I will expect people to call system() and I expect that I will implement system() in PDPCLIB to use the proper AmigaOS call rather than PosExec(). I haven't reached that bridge yet though. It depends how difficult it is to "do properly". Not just in PDPCLIB but also the corresponding code in AmigaPDOS. So far in PDPCLIB I have done everything according to the AmigaOS specs, but that may change depending on how difficult it is, so doing a system() may cause a crash.

The nicest way is either to have this as a link-library and custom startup code of your own binaries, or a public library that is opened by the startup code of your binaries.

I have custom startup code in my own binaries. That's what PDPCLIB is. I'm not using any AmigaOS libraries to link with at all. I'm building AmigaOS executables on Windows.

Also note that "SysBase" is a reserved name once you want to use any AmigaOs function, it is supposed to point to ExecBase, and only that.

Mine does too.

Once a program wants to call any function in exec.library, it would require this symbol, and exec requires a6 to be loaded with SysBase, the real one, and nothing else.

I am not using exec.library.

So you shouldn't use that symbol, it is asking for trouble. PDosBase would be a better name anyhow.

PDosBase is a separate global variable. I have SysBase as well. Well, currently I *only* have SysBase.

[Thomas Richter]

Originally Posted by kerravon

What do you mean "yourself"? AmigaPDOS exactly loads AmigaOS binaries, which is why I have just written an Amiga Hunk loader.

Yes, and if you load a binary that is compiled for AmigaOs, and do not start it through RunCommand() (or the workbench interface, for that matter) chances are that it wouldn't work. As long as you start binaries designed for your API, everything might be fine. But then again, why encode them in the Tripos HUNK format (which is rather limited) and not use something saner, such as Elf?

[Thomas Richter]

Originally Posted by Thorham

That's a lot of registers. What should you do when your programs start?

I as a programmer? Well, nowadays, I wouldn't bother about all that stuff anymore. I would locate SysBase, then open dos.library, then call ReadArgs(). That doesn't require any arguments in any registers whatsoever.


These registers are all for the legacy Tripos nonsense, and they are used by the BCPL startup code of BCPL binaries that are still supposed to work.

[kerravon]

Originally Posted by Thomas Richter

Yes, and if you load a binary that is compiled for AmigaOs, and do not start it through RunCommand() (or the workbench interface, for that matter) chances are that it wouldn't work.

AmigaPDOS will directly invoke the binaries it loads, setting D0/A0/D7 along the way. It doesn't need a RunCommand() to even exist. That can be added later maybe, but it isn't very important.

As long as you start binaries designed for your API, everything might be fine.

It is a subset of the AmigaOS at this stage, not my own API. My own API comes later, as an *addition*.

But then again, why encode them in the Tripos HUNK format (which is rather limited) and not use something saner, such as Elf?

I want to run AmigaOS executables as they COULD have been written in 1986 if people had simply put in a harmless detect for D7.

[kerravon]

Originally Posted by Thomas Richter

I as a programmer? Well, nowadays, I wouldn't bother about all that stuff anymore. I would locate SysBase, then open dos.library, then call ReadArgs(). That doesn't require any arguments in any registers whatsoever.

These registers are all for the legacy Tripos nonsense, and they are used by the BCPL startup code of BCPL binaries that are still supposed to work.

I am interested in supporting this legacy Tripos stuff. Is it possible to write a "hello, world" program that works on both Tripos environments as well as AmigaOS? If so, what extra steps are required to add in Tripos support?

[Thomas Richter]

Originally Posted by kerravon

I am interested in supporting this legacy Tripos stuff. Is it possible to write a "hello, world" program that works on both Tripos environments as well as AmigaOS? If so, what extra steps are required to add in Tripos support?

*Sigh* Lauch the binary through RunCommand().

[Thomas Richter]

Originally Posted by kerravon

AmigaPDOS will directly invoke the binaries it loads, setting D0/A0/D7 along the way. It doesn't need a RunCommand() to even exist.

To avoid any doubt: This will not work. You cannot safely kick off an AmigaDos binary without AmigaDos functions. Things are considerably easier for workbench programs, but they don't get a command line in first place.

Originally Posted by kerravon

I want to run AmigaOS executables as they COULD have been written in 1986 if people had simply put in a harmless detect for D7.

You are looking from the completely wrong side at the interface you are trying to invent. Passing magic values through magic registers is not going to help you if you want some sort of compatibility with AmigaOs. You have your own function API. Well, fine enough. 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.

[kerravon]

Originally Posted by Thomas Richter

*Sigh* Lauch the binary through RunCommand().

No, I'm talking about the receiving end. An AmigaOS hunk being run under Tripos and receiving all those registers. Is it possible to detect that this is a Tripos environment and all those registers are available and should be used for something?

[kerravon]

Originally Posted by Thomas Richter

To avoid any doubt: This will not work.

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

You cannot safely kick off an AmigaDos binary without AmigaDos functions.

Well, you added the qualifier "safely" there. That may be true. It depends on exactly what you are doing. To start with, I wish to kick off a "hello world" AmigaOS binary that has been built with PDPCLIB.

You are looking from the completely wrong side at the interface you are trying to invent. Passing magic values through magic registers is not going to help you if you want some sort of compatibility with AmigaOs.

The executables I am building are totally compatible with AmigaOs.

You have your own function API.

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.

Well, fine enough. 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.

I will be statically linking pos.o when it is time to start invoking the MSDOS API.

[Thorham]

Originally Posted by Thomas Richter

These registers are all for the legacy Tripos nonsense, and they are used by the BCPL startup code of BCPL binaries that are still supposed to work.

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