PDOS for Amiga

[Thomas Richter]

Originally Posted by kerravon

As noted, both of those are licensed software. I am after code with absolutely no strings attached, ie an explicit public domain notice, and no following caveats.

Software (or every work you create) has a copyright attached to it, and if you create it, its yours. If you want to allow other people to use it, or its sources, you need to attach a license to it, even if the license says that you can do with it what you want. The closest to that is the BSD license - you probably haven't read it yet, it really doesn't say much.

In that sense, I do not quite understand what your problem with NetBSD is. It is certainly a much better operating system than MS-DOS ever was, and it is under the most liberal license (and most readable license) I am aware of.

[kerravon]

Originally Posted by Thomas Richter

Software (or every work you create) has a copyright attached to it, and if you create it, its yours. If you want to allow other people to use it, or its sources, you need to attach a license to it, even if the license says that you can do with it what you want.

No, you can also say "released to the public domain", meaning you are relinquishing your copyright, the same as happens 70 years after you die or whatever. And the same as code produced by the US government.

The closest to that is the BSD license - you probably haven't read it yet, it really doesn't say much.

Yes, I have read it, and I know very well that it doesn't say "released to the public domain", the most liberal thing you can do to relinquish all control.

In that sense, I do not quite understand what your problem with NetBSD is. It is certainly a much better operating system than MS-DOS ever was, and it is under the most liberal license (and most readable license) I am aware of.

There is a zero-clause BSD, which is as liberal as you can get without putting "released to the public domain" on it. But I'm holding out for the latter.

[Bruce Abbott]

Originally Posted by kerravon

So that I am not dependent on Commodore's
SysBase, and can add my own features to
AmigaPDOS, I was thinking that a6 should
point to an AmigaPDOS parameter block, and
the first element of that is a traditional
SysBase.

So SysBase is set and looks normal, but a new
set of API calls is opened up, via the second
element. I'm thinking the MSDOS API, like this:

ret = PosFindFirst(p, 0x10);

which will only do something sensible when
operating on an AmigaPDOS-controlled disk.

And to make things easier for the next person,
I'll have a reserved word after that.

Any flaw in this concept?

You need a lot more than just sysbase to interface your OS to Amiga OS, but if Amiga OS isn't there you don't want any of it. To make your code truly portable you should work at a higher level of abstraction, and keep all the messy system dependent stuff hidden below it.

If you are already using the MSDOS API then you could keep it and translate the INTs and parameter blocks to and from the form that Amiga OS needs, with that code kept in a separate module that just gets added when running on Amiga OS. Then if you want to run your OS on another platform you create a different module to suit that platform. IOW the system-specific module would emulate the MSDOS API at the source code level.

This might also be useful for porting MSDOS programs to other platforms, provided you have the source code and it uses only documented OS calls (no banging on the hardware).

It might even be possible to 'decompile' a DOS binary to C source code, then recompile it into 68k code that runs at native speed (unlike emulators which have to translate x86 machine code on the fly). I am thinking that if this could be done then the Amiga could have run MSDOS programs at speeds equal to or even faster than a PC back in 1985 - if only someone had thought of doing it this way.

[Bruce Abbott]

Originally Posted by kerravon

Yes, I have read it, and I know very well that it doesn't say "released to the public domain", the most liberal thing you can do to relinquish all control.

The problem with that is some jurisdictions do not allow relinquishing all control, or put it on shaky legal ground. A permissive license (some of which require no attribution) may give adopters better protection against legal challenges.

BTW if you are putting your code into the public domain you better make sure that every single line is either original code written by you or cribbed from another provable public domain source. Otherwise your declaration that the code is public domain is invalid.

[meynaf]

Originally Posted by Bruce Abbott

It might even be possible to 'decompile' a DOS binary to C source code, then recompile it into 68k code that runs at native speed (unlike emulators which have to translate x86 machine code on the fly). I am thinking that if this could be done then the Amiga could have run MSDOS programs at speeds equal to or even faster than a PC back in 1985 - if only someone had thought of doing it this way.

Alas it seems current decompilers are far from being able to produce a C source that can compile, let alone from a DOS binary.
Actually i'm not even able to disassemble (resource) x86 machine code and that's too bad because it's the first step to port games.

[kerravon]

Originally Posted by Bruce Abbott

You need a lot more than just sysbase to interface your OS to Amiga OS,

What do you mean?

but if Amiga OS isn't there you don't want any of it.

Not sure what you mean here either.

To make your code truly portable you should work at a higher level of abstraction, and keep all the messy system dependent stuff hidden below it.

I think that is what I have done already.

So here is the PosFindFirst() function I showed earlier. You can see it doing an INT 21H to access the appropriate MSDOS interrupt.

int PosFindFirst(char *pat, int attrib)
{
union REGS regsin;
union REGS regsout;
struct SREGS sregs;

regsin.h.ah = 0x4e;
regsin.x.cx = attrib;
#ifdef __32BIT__
regsin.d.edx = (int)pat;
#else
regsin.x.dx = FP_OFF(pat);
sregs.ds = FP_SEG(pat);
#endif
int86x(0x21, &regsin, &regsout, &sregs);
if (regsout.x.cflag)
{
return (regsout.x.ax);
}
else
{
return (0);
}
}

But on AmigaPDOS I would instead call SysBase->PosFindFirst(). Except there isn't such an element there. I could extend SysBase to include such an element, but then I would be fighting with Commodore.

That is why I proposed having a new variable, basically PdosBase, and that is what register A6 would point to when an executable starts. And PdosBase would also include a pointer to a replacement SysBase to use. Rather than A6 containing ONLY a replacement SysBase so that I am back to fighting with Commodore.

If you are already using the MSDOS API then you could keep it and translate the INTs and parameter blocks to and from the form that Amiga OS needs, with that code kept in a separate module that just gets added when running on Amiga OS. Then if you want to run your OS on another platform you create a different module to suit that platform. IOW the system-specific module would emulate the MSDOS API at the source code level.

I think that is what I have already done, but I have done it in a way that it requires source so that you don't have to kludge around the problem, you just compile natively.

This might also be useful for porting MSDOS programs to other platforms, provided you have the source code and it uses only documented OS calls (no banging on the hardware).

Sure, that's why I created the Pos() functions. And yes, I'm only supporting documented OS calls. And only a subset of them (so far, anyway). And the plan is to have micro-emacs writing an ANSI data stream (already working on the mainframe version of PDOS). Ideally the BIOS (or higher) will support the ANSI data stream (even if it means writing to the serial port and relying on an ANSI terminal to be attached).

It might even be possible to 'decompile' a DOS binary to C source code, then recompile it into 68k code that runs at native speed (unlike emulators which have to translate x86 machine code on the fly). I am thinking that if this could be done then the Amiga could have run MSDOS programs at speeds equal to or even faster than a PC back in 1985 - if only someone had thought of doing it this way.

I'm certainly interested in "what might have been". :-) I was around at that time (started working in 1986 when I was 18 years old) and I was simultaneously confronted with MSDOS, Amiga and MVS and I wondered why they were different.

They're all doing C90 now. :-) And will hopefully all be driving ANSI terminals, and it is ironic that MVS (well, my replacement, PDOS/3X0) would be the first to be doing that. At least on my version of micro-emacs.

[kerravon]

Originally Posted by Bruce Abbott

The problem with that is some jurisdictions do not allow relinquishing all control, or put it on shaky legal ground. A permissive license (some of which require no attribution) may give adopters better protection against legal challenges.

Yes, if you're worried about that, you STILL don't need to write the word "copyright", you know that you are dealing with the implicit copyright and trying to find a way to relinquish that, and if you're worried "public domain" isn't clear enough, then this is what I do in PDOS:

Version 0.9X, released YYYY-MM-DD
Written by Paul Edwards, mutazilah@gmail.com
Released to the public domain
You may use this entire package for any purpose whatsoever
without restriction, as discussed here:
http://creativecommons.org/publicdomain/zero/1.0/
That includes, but is not limited to, closed-source,
proprietary commercial products.

BTW if you are putting your code into the public domain you better make sure that every single line is either original code written by you or cribbed from another provable public domain source. Otherwise your declaration that the code is public domain is invalid.

This is true of a copyright notice too. Half of Linux could have been cribbed from someone who has access to Microsoft Windows source code. I don't personally know. I haven't looked at either. Maybe Microsoft hasn't looked either, and we'll only find out about it tomorrow.

[Thomas Richter]

Originally Posted by kerravon

Yes, if you're worried about that, you STILL don't need to write the word "copyright", you know that you are dealing with the implicit copyright and trying to find a way to relinquish that, and if you're worried "public domain" isn't clear enough, then this is what I do in PDOS:

Version 0.9X, released YYYY-MM-DD
Written by Paul Edwards, mutazilah@gmail.com
Released to the public domain
You may use this entire package for any purpose whatsoever
without restriction, as discussed here:
http://creativecommons.org/publicdomain/zero/1.0/
That includes, but is not limited to, closed-source,
proprietary commercial products.

Now, surprise, surprise. That *is* a license. Just another one. However, "creative commons" has many flavours, and with a statement that general, one cannot derive what you exactly mean. So state one of the creative common licences you can select from. Or pick another license that expresses the same intend, and has been setup with more care, like BSD.

Originally Posted by kerravon

This is true of a copyright notice too.

That is a license, and a declaration of origin. "Public domain" does not mean much. A clear statement what people are allowed to do with the code (such as the CC licenses, with precise selection of the terms) is much better.

Originally Posted by kerravon

Half of Linux could have been cribbed from someone who has access to Microsoft Windows source code.

Many parts of linux are contributed by commercial enterprises, including Microsoft. (Gasp!). Linux developers record who contributes what, so contributions are clear to trace, and it becomes aparent that developers had to agree with the license conditions of the code.

Originally Posted by kerravon

Maybe Microsoft hasn't looked either, and we'll only find out about it tomorrow.

Certainly "Microsoft did look". It's their right to look, as this is an open source Os. Its also their right to contribute under the license this was published, namely GPL, or to use it, under the same license.

[Thomas Richter]

Originally Posted by kerravon

But on AmigaPDOS I would instead call SysBase->PosFindFirst(). Except there isn't such an element there. I could extend SysBase to include such an element, but then I would be fighting with Commodore.

There isn't, because there shouldn't. AmigaOs is AmigaOs and not MS-Dos. In particular, exec does not deal with high-level file I/O. Dos does. And we have MatchFirst() and MatchNext() for pattern matching, if this is what you intend to do.



You can create, of course, your own library where you put such functions. System libraries are not up to you to extend.



Note that CBM died away a long long time ago.

[kerravon]

Originally Posted by Thomas Richter

Now, surprise, surprise. That *is* a license. Just another one.

Yes, but it only kicks in if you are not happy with the fact that it is public domain.

However, "creative commons" has many flavours, and with a statement that general, one cannot derive what you exactly mean. So state one of the creative common licences you can select from. Or pick another license that expresses the same intend, and has been setup with more care, like BSD.

I don't know what you are talking about. I gave a link to CC0 which has been set up with plenty of care.

That is a license, and a declaration of origin. "Public domain" does not mean much.

Yes it does, especially in America, which is my main target audience.

A clear statement what people are allowed to do with the code (such as the CC licenses, with precise selection of the terms) is much better.

That is there too!!!

Many parts of linux are contributed by commercial enterprises, including Microsoft. (Gasp!). Linux developers record who contributes what, so contributions are clear to trace, and it becomes aparent that developers had to agree with the license conditions of the code.

Yes, and that is exactly why I don't want to use that 68000 code that was recently posted until I receive an email from someone who ensures me that this is their code and that they are releasing it to the public domain. I'd rather do a 68020 compile until then.

Certainly "Microsoft did look". It's their right to look, as this is an open source Os. Its also their right to contribute under the license this was published, namely GPL, or to use it, under the same license.

And they have rights to not just look at my public domain code, but to use it in Windows itself if they wish, with no strings attached. Or someone else may wish to create a rival to Windows, and say "wow, FAT32 code from Alica - great stuff!".

[kerravon]

Originally Posted by Thomas Richter

There isn't, because there shouldn't. AmigaOs is AmigaOs and not MS-Dos. In particular, exec does not deal with high-level file I/O. Dos does.

I don't want to be bound by the AmigaOS paradigm. I want PosFindFirst() to work on AtariPDOS too. And I don't want to be bound by whatever Atari does either.

And we have MatchFirst() and MatchNext() for pattern matching, if this is what you intend to do.

Replacing all my calls to PosFindFirst() with a call to MatchFirst() so that the executable is more flexible on real AmigaOS is an exercise for someone else. I'm more interested in supporting the Atari. And the VAX. And ...

You can create, of course, your own library where you put such functions. System libraries are not up to you to extend.

Oh yes they are. :-) That's the great thing about being an OS vendor. Commodore can kiss my ass. Having said that, I am happy to negotiate. That's why I suggested making A6 support to a PDOS block, which contains room for a Commodore-controlled SysBase, and a PosBase, and a LinuxBase, and room for more such sets of rival APIs.

Note that CBM died away a long long time ago.

The year is 1986. Let's rewrite history by making Microsoft die away instead of Commodore, who produced a far superior machine/OS.

[Thomas Richter]

Originally Posted by kerravon

I don't want to be bound by the AmigaOS paradigm. I want PosFindFirst() to work on AtariPDOS too. And I don't want to be bound by whatever Atari does either.

You can work *with* the system, or *against* the system. In the latter case, you cannot use any service of the operating system, so providing hardware drivers would be up to you. You cannot patch "your own functions" into sysbase. If you want to provide your own functions, that's all fine, but they don't belong into an existing AmigaOs system library. They belong into your program - or if you want this to be come VM on top of AmigaOs, into some abstraction layer on top. AmigaOs provides libraries for this purpose, so writing an AmigaOs library seems to be a natural approach for that.



Just don't expect that you can clutter existing system libraries with your functions. This doesn't work. The interface of the system libraries is already set in stone and they don't require an extension for some MS-DOS abstraction.



Frankly, from what you say, I can only observe that you have no experience in Os design. That's ok, but you need to fix that if you want to follow your project.

Originally Posted by kerravon

Replacing all my calls to PosFindFirst() with a call to MatchFirst() so that the executable is more flexible on real AmigaOS is an exercise for someone else. I'm more interested in supporting the Atari. And the VAX. And ...

Then, why posting here?

Originally Posted by kerravon

Oh yes they are. :-) That's the great thing about being an OS vendor. Commodore can kiss my ass. Having said that, I am happy to negotiate. That's why I suggested making A6 support to a PDOS block, which contains room for a Commodore-controlled SysBase, and a PosBase, and a LinuxBase, and room for more such sets of rival APIs.

Once again, CBM does not control anything. CBM is dead, deceased, and is no more.

If you want your own "a6 world for PDOS support", then a natural way how to fit that into AmigaOs is to make your own library, and its a6 world is called a "library base".


You will not make run AmigaOs "on top" of anything you provide. AmigaOs does not run on an MS-DOS like layer. It has its own hardware abstraction, and it works quite different from MS-DOS.

Originally Posted by kerravon

The year is 1986. Let's rewrite history by making Microsoft die away instead of Commodore, who produced a far superior machine/OS.

Microsoft will not die away anytime soon, and Microsoft is smart enough to join their enemies instead of fighting them. They will certainly not go away due to some hobby project on an esentially dead hardware platform. I will certainly not stop you, but I won't hold my breath either.

[Thomas Richter]

Originally Posted by kerravon

Yes, but it only kicks in if you are not happy with the fact that it is public domain.

Really, I couldn't care less which license you slam on your code. I'm not in the position of telling you, and I'm not a target audience of it - I neither care about an MS-Dos layer because I don't need one. I'm stating the observation that "public domain" is not a well-defined term and you need to fix this if you want to convince anyone from using your sources.

Originally Posted by kerravon

Yes it does, especially in America, which is my main target audience.

I know this may be hard to accept, but the world consists of more countries than the US of A, even some them are located in America. So please accept that "public domain" does not mean as much as you probably assume it to mean.

Originally Posted by kerravon

Yes, and that is exactly why I don't want to use that 68000 code that was recently posted until I receive an email from someone who ensures me that this is their code and that they are releasing it to the public domain. I'd rather do a 68020 compile until then.

The algorithm provided there is an "out of the book" implementation of "Algorithm D", which you find in "Knuth Volume II, The Art of Programming, Numerical and Semi-numerical algorithms". If you don't want to use somebody else's code, implement algorithm D yourself. Or some other division algorithm, for example a simple bit-by-bit compare and shift algorithm. If you cannot do that, I somehow have my doubts that you will get very far with your project. This is elementary stuff.

[kerravon]

I have written code to load Amiga Hunks, in preparation for writing AmigaPDOS.

If anyone would like to test it out, you can get it here:

http://www.mutazilah.org/bios.zip

It's still crude, but I have tested it to the point where I have seen it go through all the hunk IDs.

See readme.txt

[kerravon]

Originally Posted by Thomas Richter

You can work *with* the system, or *against* the system.

I don't think I am doing either of those things.

In the latter case, you cannot use any service of the operating system, so providing hardware drivers would be up to you.

I can tell you for sure that I am not going to provide any hardware drivers. So if you believe there is only a binary choice available, then I am doing the former.

You cannot patch "your own functions" into sysbase.

Yes I can. It's totally up to me. :-)

If you want to provide your own functions, that's all fine, but they don't belong into an existing AmigaOs system library.

Sure, I'm willing to cooperate. That's why I suggested a PDOS block. I'm happy to negotiate the details of that.

They belong into your program

No, I don't want that. I want the program to call what is effectively an OS API. Implemented similarly to SysBase.

- or if you want this to be come VM on top of AmigaOs,

Depending on what you are calling a "VM", I may be doing this.

into some abstraction layer on top.

Yes, I am basically doing this. I have a new design for a BIOS.

AmigaOs provides libraries for this purpose, so writing an AmigaOs library seems to be a natural approach for that.

No. I don't wish to do this.

Just don't expect that you can clutter existing system libraries with your functions.

From the perspective of certain perfectly-valid AmigaOS applications, I can indeed clutter existing system libraries.

This doesn't work.

You wouldn't believe how many times I have heard that. S/380 exists.

The interface of the system libraries is already set in stone

Nope, I can change that at will, from the perspective of *certain* AmigaOS applications when running under AmigaPDOS.

and they don't require an extension for some MS-DOS abstraction.

I disagree. AmigaOS exactly needs an MSDOS abstraction. Optional of course, but it should exist.

Frankly, from what you say, I can only observe that you have no experience in Os design.

I have written an OS for S/3X0 and 80386. Doesn't that count? I agree I've never read anything about it though. I made it up myself.

That's ok, but you need to fix that if you want to follow your project.

Why do I need to fix something that already works? If you have suggestions for improvements, that's fine. But it already ***works***.

Then, why posting here?

I would like to have a 68000-based OS.

Once again, CBM does not control anything. CBM is dead, deceased, and is no more.

Again, my brain is still in 1986. I have unresolved issues. I want to know why it was Commodore who went bust instead of Microsoft, and whether anything could have been done to prevent that.

If you want your own "a6 world for PDOS support", then a natural way how to fit that into AmigaOs is to make your own library, and its a6 world is called a "library base".

No, I don't want that.

You will not make run AmigaOs "on top" of anything you provide. AmigaOs does not run on an MS-DOS like layer.

I didn't say it did. Not even AmigaPDOS will do that. Support the API, sure, but not on top of it. It will support some of the AmigaOS API too, but it doesn't interface to the AmigaOS API. There is a BIOS layer separating that.

It has its own hardware abstraction, and it works quite different from MS-DOS.

Sure. I'm not changing AmigaOS, I'm changing AmigaPDOS.

Microsoft will not die away anytime soon, and Microsoft is smart enough to join their enemies instead of fighting them. They will certainly not go away due to some hobby project on an esentially dead hardware platform. I will certainly not stop you, but I won't hold my breath either.

That's because you're thinking 2021 instead of 1986. If we go through a time warp, I'll be ready with AmigaPDOS, and encouraging Amiga developers to check a6, and encouraging MSDOS programmers to call PosOpenFile() instead of INT 21H so that their programs run on AmigaPDOS with just a recompilation to 68000.

[kerravon]

Originally Posted by Thomas Richter

Really, I couldn't care less which license you slam on your code. I'm not in the position of telling you, and I'm not a target audience of it - I neither care about an MS-Dos layer because I don't need one. I'm stating the observation that "public domain" is not a well-defined term and you need to fix this if you want to convince anyone from using your sources.

As I have said, it IS well-defined, that's what happens 70 years after you die. What do you actually think the copyright status of Macbeth is? GPL? REGARDLESS, I include CC0 as a fallback.

I know this may be hard to accept, but the world consists of more countries than the US of A, even some them are located in America. So please accept that "public domain" does not mean as much as you probably assume it to mean.

Yes, and I'm in one of those countries. But I want to make sure that the US is thoroughly covered.

The algorithm provided there is an "out of the book" implementation of "Algorithm D", which you find in "Knuth Volume II, The Art of Programming, Numerical and Semi-numerical algorithms". If you don't want to use somebody else's code, implement algorithm D yourself. Or some other division algorithm, for example a simple bit-by-bit compare and shift algorithm.

I would be happy to have a "simple" algorithm in C, but I don't know how to do that myself, and it is not my priority to learn that at this stage. For now I'll just do 68020 compiles.

If you cannot do that, I somehow have my doubts that you will get very far with your project.

Depends what you mean by "very far". I'm already running certain MVS executables under PDOS/3X0, 31-bit even, Its true that I don't have an OS on the 68000 YET.

This is elementary stuff.

Well it's currently above my head.

[Thorham]

Originally Posted by phx

This is from vbcc's clib:

...
        swap    d1
        mulu    d1,d2
        sub.l   d2,d0
        bhs     8$
        subq.w  #1,d3
        add.l   d1,d0
7$:     bhs.s   7$
8$:     moveq   #0,d1
        move.w  d3,d1
        swap    d3
        rol.l   d3,d0
        swap    d0
        exg     d0,d1
...

Isn't the bhs.s at label 7$ a potential infinite loop?

[Thomas Richter]

Originally Posted by kerravon

Yes I can. It's totally up to me. :-)

No, you cannot. If you believe you can, you haven't understood how Amiga libraries work. You can provide your own library.

Originally Posted by kerravon

Sure, I'm willing to cooperate. That's why I suggested a PDOS block. I'm happy to negotiate the details of that.

The details are "it is not going to happen". Please understand. If you want to provide a collection of functions, provide your library. I have my doubts anyone is willing to mess with ExecBase for system functionality that is mostly irrelevant.

Originally Posted by kerravon

No, I don't want that. I want the program to call what is effectively an OS API. Implemented similarly to SysBase.

An API is a library in AmigaOs terms.

Originally Posted by kerravon

Yes, I am basically doing this. I have a new design for a BIOS.

There is already a "Bios" for Amiga, it's called Kickstart, and it comes with a full collection of libraries and library-like objects hardware drivers need to run.

Originally Posted by kerravon

From the perspective of certain perfectly-valid AmigaOS applications, I can indeed clutter existing system libraries.

Nope. Again, if you believe you can, you haven't understood how they work.

Originally Posted by kerravon

I disagree. AmigaOS exactly needs an MSDOS abstraction. Optional of course, but it should exist.

Well, I won't stop you, but have my doubts. AmigaOs has a shell that is certainly wierd, but certainly better than MS-DOS COMMAND.EXE. There are zero programs that would depend on a self-made API, and there is no software for it either.

Originally Posted by kerravon

I have written an OS for S/3X0 and 80386. Doesn't that count?

Nope. Not as far as this target system goes. Amiga is a different beast, and it works quite differently. I really really suggest to get informed how AmigaOs operates. Read the RKRMs, Rom Kernel Reference Manuals. Start with the "Libraries" volume. You find it in the internet.

Originally Posted by kerravon

Why do I need to fix something that already works? If you have suggestions for improvements, that's fine. But it already ***works***.

Amiga already has an Os that works. For some definition of working. But it works well enough for most people.

Originally Posted by kerravon

Again, my brain is still in 1986. I have unresolved issues. I want to know why it was Commodore who went bust instead of Microsoft, and whether anything could have been done to prevent that.

Well, we don't have 1986, but 2021. If your brain is in 1986, that needs fixing. Not the Os. And reasons for CBM going bust were certainly not because Amiga had no MS-DOS layer. Actually, bridge-boards for Amigas existed, and they run MS-DOS on top of a 8086 or later processor. CBM also built IBM-compatible machines.

Originally Posted by kerravon

I didn't say it did. Not even AmigaPDOS will do that. Support the API, sure, but not on top of it. It will support some of the AmigaOS API too, but it doesn't interface to the AmigaOS API. There is a BIOS layer separating that.

Look, once again: You still don't understand how the system works. There is no Bios layer as on other systems. If you want to provide an "AmigaOs layer", then that is more than a single system library. It is "all the libraries devices and resources in ROM and those that are delivered as part of the workbench". You can either keep the system intact, and thus write your own library for some sort of MS-DOS layer lookalike, or you can try to implement AmigaOs all yourself. Actually, you may want to look into AROS, which is driven by people that essentially do that. It is essentially a several-man-year job to "replace AmigaOs", and it still doesn't work right.

Originally Posted by kerravon

That's because you're thinking 2021 instead of 1986.

Have you checked the calendar lately? Could it be that this is because we have 2021?

Originally Posted by kerravon

If we go through a time warp, I'll be ready with AmigaPDOS, and encouraging Amiga developers to check a6, and encouraging MSDOS programmers to call PosOpenFile() instead of INT 21H so that their programs run on AmigaPDOS with just a recompilation to 68000.

AmigaOs developers don't "check a6". They get SysBase through address 4. That's how it works. If you establish another API, this API will not able to run AmigaOs programs.

[kerravon]

Originally Posted by Thomas Richter

No, you cannot. If you believe you can, you haven't understood how Amiga libraries work. You can provide your own library.

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

The details are "it is not going to happen". Please understand. If you want to provide a collection of functions, provide your library. I have my doubts anyone is willing to mess with ExecBase for system functionality that is mostly irrelevant.

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

An API is a library in AmigaOs terms.

No, that's not what I want. The API will hang off a6.

There is already a "Bios" for Amiga, it's called Kickstart, and it comes with a full collection of libraries and library-like objects hardware drivers need to run.

No, that's not the BIOS I am using. See bios.c in bios.zip.

Nope. Again, if you believe you can, you haven't understood how they work.

No, you misunderstand my intentions.

Well, I won't stop you, but have my doubts. AmigaOs has a shell that is certainly wierd, but certainly better than MS-DOS COMMAND.EXE. There are zero programs that would depend on a self-made API, and there is no software for it either.

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

Nope. Not as far as this target system goes. Amiga is a different beast, and it works quite differently. I really really suggest to get informed how AmigaOs operates. Read the RKRMs, Rom Kernel Reference Manuals. Start with the "Libraries" volume. You find it in the internet.

No, what I am doing does not depend on that. It depends on a6.

Amiga already has an Os that works. For some definition of working. But it works well enough for most people.

And it will still be present, as a glorified BIOS to the BIOS.

Well, we don't have 1986, but 2021. If your brain is in 1986, that needs fixing.

Nope. I'm not budging from 1986 until I understand the problem in 1986.

Not the Os. And reasons for CBM going bust were certainly not because Amiga had no MS-DOS layer. Actually, bridge-boards for Amigas existed, and they run MS-DOS on top of a 8086 or later processor. CBM also built IBM-compatible machines.

No, none of those things are what I want. I want 68000 code.

Look, once again: You still don't understand how the system works.

No, you don't understand my proposal.

There is no Bios layer as on other systems.

There is now. See bios.c.

If you want to provide an "AmigaOs layer", then that is more than a single system library. It is "all the libraries devices and resources in ROM and those that are delivered as part of the workbench". You can either keep the system intact, and thus write your own library for some sort of MS-DOS layer lookalike, or you can try to implement AmigaOs all yourself. Actually, you may want to look into AROS, which is driven by people that essentially do that. It is essentially a several-man-year job to "replace AmigaOs", and it still doesn't work right.

No, I don't want to do any of those things.

Have you checked the calendar lately? Could it be that this is because we have 2021?

I think I've nearly understood 1986. As of today. When I was writing the Amiga Hunk loader and suddenly filled in all the gaps. See the copious comments. I think I'm there.

AmigaOs developers don't "check a6". They get SysBase through address 4. That's how it works.

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

If you establish another API, this API will not able to run AmigaOs programs.

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.

[kerravon]

Note that PDPCLIB is good enough already to do a "hello, world". Here's what the output (thanks Frank!) looks like:

pdptest.xxx abc xyz "12 34"

welcome to pdptest
main function is at 10057760
allocating 10 bytes
m1 is 10018CD0
allocating 20 bytes
m2 is 10019470
stack is around 10049498
printing arguments
argc = 4
arg 0 is <UNKNOWN>
arg 1 is <abc>
arg 2 is <xyz>
arg 3 is <12 34>


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