PDOS for Amiga

[kerravon]

Hi guys.

Just a quick update that I have released PDOS for the 80386 here: http://pdos.org

Thanks to suggestions in this (Amiga) group that the BIOS exists to isolate the OS from the hardware, I plan to remove the one place where there is direct hardware manipulation (enabling A20).

That is my vision for what 32-bit MSDOS should have looked like.

For AmigaPDOS it would look almost exactly the same, except it would be running 680x0 executables following the D7 standard.

One difference would be that there is no kernel32.dll, as those services are provided via SysBase.

Also I'm not clear about the msvcrt.dll. I'd like to make that a library chained to from SysBase, and each time a C90 subprogram gets executed, it would get a fresh copy of the DLL loaded to give it a C library. I believe there is an existing AmigaOS library that does something like this, but I would be providing my own version (at the level of AmigaPDOS, with an adjusted SysBase, I can't access any AmigaOS stuff without going through the mini-BIOS).

Note that the mini-BIOS is just a normal-looking C program running under AmigaOS, providing services to AmigaPDOS. I have proof of concept already running on the Amiga - see the "bios" subdirectory in the source.

Thanks again for the inspiration. It triggered a lot of activity and understanding.

I am training up (and paying) people to work on PDOS and I hope they will eventually get to the Amiga and the Atari and the mainframe. It's a slow process though.

[kerravon]

Hi everyone.

I'm not sure if anyone actually understood my "PDOS-generic" concept which was inspired by the people on this board.

The proof of concept is now available. A BIOS written in pure C90, an OS written in pure C90, so you can take the OS and applications written for it to any environment. It treats the existing OS as a glorified BIOS.

I have tested the Windows version, but not the Amiga version. Both are available from the bottom of http://pdos.org and if you just want to look at the technology to comment, you can see the PDOS-generic operating system source code here:

https://sourceforge.net/p/pdos/gitco...generic/pdos.c

So basically you get an MSDOS lookalike environment, but all the executables are 68020. The application executables are tiny, as they make use of an exported C library (exported by the OS).

I'm interested in any technical analysis.

Thanks.

[Locutus]

I don't really understand your PD goal document, which of those make them incompatible with say, MIT/BSD/Apache licensing?

[kerravon]

Originally Posted by Locutus

I don't really understand your PD goal document, which of those make them incompatible with say, MIT/BSD/Apache licensing?

The PDOS code is public domain, meaning you can use it in MIT etc projects. There are ZERO rules/conditions you need to follow when using/selling/modifying PDOS, so if you see a commercial opportunity - go for it.

If that doesn't answer your question, please be more specific.

[Locutus]

how does MIT or BSD license prevent one from modifying, reselling and not disclosing source code of your product?

As that's what i read is your stated aim.

[kerravon]

Originally Posted by Locutus

how does MIT or BSD license prevent one from modifying, reselling and not disclosing source code of your product?

As that's what i read is your stated aim.

All of those people deliberately went to the effort of writing the word "copyright", refusing to instead write the phrase "released to the public domain". That means they're trying to impose conditions that they know some people don't wish to follow. I don't know what their game is, and I don't want to know. You'll find out what their game is when they take you to court for failing to comply with their "implied" desires on what is unquestionably THEIR code as it has a friggin copyright notice plastered all over it. I'm not going to touch anything that someone is insisting they retain ownership of. I'm catering to the people who don't want any rules set by the code owners, because there are no code owners, other than "the public".

[Locutus]

That seems like an irrational reaction to what the BSD and MIT licenses actually say.

[kerravon]

Originally Posted by Locutus

That seems like an irrational reaction to what the BSD and MIT licenses actually say.

I cater for whatever percentage of the programming population meets your definition of "irrational". As far as I'm concerned, until someone releases code to the public domain, the job hasn't been done yet.

[Locutus]

I guess you'll find a niche, what kind of competitive use cases do you have in mind for PDOS and your C std library? I get the idea from the manifesto you are intending this to be commercially useful?

[kerravon]

Originally Posted by Locutus

I guess you'll find a niche, what kind of competitive use cases do you have in mind for PDOS and your C std library? I get the idea from the manifesto you are intending this to be commercially useful?

I'm not sure what the requirements are for embedded systems. And someone contacted me about wanting to use PDOS in some closed-source commercial robot application, but that project has yet to eventuate. The main thing I had in mind was simply that if you wish to develop an OS for any reason, there was no need to start from scratch - there was an unrestricted base you could start from. Nothing specific.

PDOS/386 is now able to drive a serial port and do zmodem file transfers (and the zmodem code is portable, so maybe it could be exercised on the Amiga too), and I'm basically planning on retreating to my BBS system that I used to run 25 years ago, but this time with public domain software, including the OS. Most of the components are in place already.

[Bruce Abbott]

Originally Posted by kerravon

I have tested the Windows version, but not the Amiga version. Both are available from the bottom of http://pdos.org

Doesn't work.

At this point it had used up ~30MB of FastRAM. I can't imagine how it could work on an MSDOS machine with that memory usage.

[kerravon]

Originally Posted by Bruce Abbott

Doesn't work.

Hi Bruce. Thanks for testing that. There was a bug in my fseek() implementation - I assumed that Seek() returned the new file position but it actually returns the old position. I've rebuilt - could you download and try again please?

At this point it had used up ~30MB of FastRAM. I can't imagine how it could work on an MSDOS machine with that memory usage.

It unconditionally allocates 28 MB of RAM (although it only needs 2 MB) because my goal is ultimately to run GCC 3.2.3 which uses about 23 MB to rebuild itself.

I'm not sure what you mean by an "MSDOS machine". It's a 32-bit application meant to run on machines like the 80386. It looks like MSDOS and it uses an MSDOS-like API.

[meynaf]

Originally Posted by Bruce Abbott

I can't imagine how it could work on an MSDOS machine with that memory usage.

Apparently it does not. It is MSDOS like but won't work on top of MSDOS itself. Doing this would require horrors such as DOS/4G.

Originally Posted by kerravon

There was a bug in my fseek() implementation - I assumed that Seek() returned the new file position but it actually returns the old position.

That looks weird to me - do you divide by the value returned by Seek ?
As the error above (80000005) is a division by zero.

Originally Posted by kerravon

It unconditionally allocates 28 MB of RAM (although it only needs 2 MB) because my goal is ultimately to run GCC 3.2.3 which uses about 23 MB to rebuild itself.

So it has no graphics, no sound, no multitask (etc) and it already uses 2 MB ?
I'm afraid there is something wrong somewhere.

[kerravon]

Originally Posted by meynaf

Apparently it does not. It is MSDOS like but won't work on top of MSDOS itself. Doing this would require horrors such as DOS/4G.

I don't know what the point is of running MSDOS under MSDOS, but if you were to run the Windows distribution under HX under MSDOS, it should work.

That looks weird to me - do you divide by the value returned by Seek ?
As the error above (80000005) is a division by zero.

I wasn't expecting the Seek to fail, so the VBR wasn't read, which meant that everything was 0 when it was time to do FAT calculations.

So it has no graphics, no sound, no multitask (etc) and it already uses 2 MB ?
I'm afraid there is something wrong somewhere.

The Amiga loader doesn't yet have the logic to only allocate memory actually required for the executable so it just allocates 1 MB for the executable. There are two executables loaded, the OS and the command processor.

It is proof of concept. My desire is to get to a point where I have a complete development system which would e.g. allow me to go to an Amiga, continue using what looks like MSDOS with no disruption, and be able to modify every component, including the compiler itself, and rebuild with full optimization. And as I said, it requires a bit over 20 MiB of memory for GCC to recompile itself.

Anyway, I'm currently waiting on someone to test http://pdos.org/temp4.zip

[kerravon]

Originally Posted by kerravon

Anyway, I'm currently waiting on someone to test http://pdos.org/temp4.zip

Someone has tested it (not sure if he wants to be named) and it is working on the Amiga as designed! Latest version is http://pdos.org/temp6.zip

[kerravon]

Oh, something I should mention.

In the POC I pass the C library and the OS API to the executable. But I am thinking I should do it similar to the Amiga and do an explicit open of some named library. The library doesn't necessarily need to exist on disk, it can be always-available-in-RAM.

So basically although I call this "MSDOS-like" it is actually Amiga-like in some respects too.

[kerravon]

I had another thought about where I am coming from.

When the Amiga came out, and was better value for money than the IBM PC, my expectation was that in a sane world, armed with a high level language, all applications should have simply been recompiled for the new machine, and the Amiga takes over the world.

That didn't happen. What was the barrier to that happening?

C90 is the high level language I would like to focus on to start with. I know that programs written in that could simply be recompiled for the Amiga. But people were using MSDOS extensions. Which ones, and why?

Now that I have PDOS/386 and PDOS-generic, I have discovered the following deviations from C90:

1. You need to be able to traverse directories. MSDOS used FAT, and some custom APIs that were FAT-focused. I now know that this can be implemented on the Amiga too.

2. Forget graphics - there needs to be a way to do full-screen editing. Micro-emacs has an ANSI flavor for that. MSDOS has an ANSI.SYS but it didn't provide for ANSI controls for keyboard. I think the Amiga has ANSI support (ie ESC [ 2 J works) for output, I'm not sure about input.

If we can sort this out, all we need is a time machine (*) and we can get the Amiga to take over the business world too!


(*) sold separately

[meynaf]

Originally Posted by kerravon

That didn't happen. What was the barrier to that happening?

Nothing technical at all. The reasons why it didn't happen were 100% marketing :
1. Buying IBM was considered "safe" as IBM wouldn't go bankrupt overnight, and they didn't truly protect their machine against cloning.
2. Commodore mismanaged.
That's all.

[kerravon]

Originally Posted by meynaf

Nothing technical at all. The reasons why it didn't happen were 100% marketing :
1. Buying IBM was considered "safe" as IBM wouldn't go bankrupt overnight, and they didn't truly protect their machine against cloning.
2. Commodore mismanaged.
That's all.

There was no guarantee the clones wouldn't go bankrupt overnight either. I expect the computer to be treated like a commodity item. So long as it is able to run the appropriate software - ie MSDOS software - at native (ie compiled for 68000) speed, it should have been a fast PC.

At the very least the 68000 MSDOS environment should EXIST.

[meynaf]

Originally Posted by kerravon

There was no guarantee the clones wouldn't go bankrupt overnight either.

For a single individual maybe, but all together certainly not.

Originally Posted by kerravon

I expect the computer to be treated like a commodity item. So long as it is able to run the appropriate software - ie MSDOS software - at native (ie compiled for 68000) speed, it should have been a fast PC.

But perhaps MSDOS software isn't appropriate.
Compiling it for 68000 isn't enough. MSDOS has nothing for graphics, sound, etc. It depends fully on PC/x86 architecture. So yes you can do something similar but that's all.

Originally Posted by kerravon

At the very least the 68000 MSDOS environment should EXIST.

Why ? We have much better already. MSDOS has no technical quality to justify it becoming a standard. It got dropped 20 years ago and for good reasons (for once).