PDOS for Amiga

[meynaf]

Originally Posted by kerravon

I think the AmigaOS is near-perfect. To perform isolation, those functions in DOSBase simply need to invoke a trap. Commodore (or whoever) can do that whenever they feel like.

What happens actually is that whatever system component, or even end user applications, use some exec.library functions to get into supervisor mode. This in turn uses privilege violation exception to perform something looking like a trap.

Originally Posted by kerravon

I don't know what that is, but presumably it can be activated via a SysBase-like interface too.

Line-A is opcodes $Axxx which on the 68k all trap on a single vector.
MacOS 68k uses "xxx" above to give function number (and sometimes a few extra infos) for all its OS calls.
Atari ST also uses a few of these values for some graphical routines.

[kerravon]

There has been a suggestion from elsewhere that I am basically trying to implement UEFI on Amiga/Atari.

What do you think of the feasibility of implementing some UEFI-inspired wrapper instead of calling the exact Atari BIOS functions?

Note that I only want to use C90 data types, so I don't think I can use the exact UEFI functions.

And note that on the Amiga, the UEFI-inspired functions would simply call AmigaOS functions, no need for the actual Atari BIOS to be involved at all.

But when running on the Atari, the UEFI-inspired functions would indeed call the actual Atari BIOS trap #13, after appropriate manipulations.

[kerravon]

Originally Posted by phx

You should prefer the latter. A single amiga.asm with all stub functions will result in a single object file, which may add a lot of unused code to an executable when linked. Create object files for all individual OS-call stubs.

amiga.asm will only have the minimal set of assembler routines that PDPCLIB actually depends upon. I wish to have source in sourceforge, not a library.

Correct. You will need mot-syntax to assemble fd2pragma's output. MIT syntax ("std" in vasm) is rarely used on the Amiga, except as output of gcc.

Ok, I hope gcc 3.2.3 and binutils 2.14a can generate the mot syntax when the time comes.

Hmm... that may be a problem in fd2pragma when running on CR/LF line-ending hosts, like Windows. fopen() with "rb" or "wb" is definitely wrong, when dealing with text files. But fd2pragma can also output binaries, so you have to be careful.

I was able to circumvent the problem by stripping CR from the .fd file I was using. I also found that I could simply combine multiple .s files and vasm accepts it. That's really great.

BTW, sorry everyone for the delay in responding, I was reevaluating PDOS most of the night. :-)

[kerravon]

Originally Posted by Thomas Richter

Well, it would run on emulated Atari hardware, but that might be good enough. I do not quite know why you want to do what you want to do, so I cannot judge whether that is sufficient. My Amiga already has an operating system.

Well, if you ever need an operating system for a 68000, perhaps new hardware, you will have a public domain OS, known to work on the 68000, and you may convert that into a closed-source proprietary product or whatever you wish. You will also be able to develop it on your Amiga. This might have been more useful back in 1990, but basically I have not been willing to progress past 1990 when ISO approved ANSI C unchanged. Armed with a standardized language, I wanted to spread that language to every bit of hardware in existence, to create a universal language for computers. The main holdout for that was IBM mainframes, and there were situations where people were forced to program in other languages because management couldn't justify the cost of a commercial C compiler. GCC came close to supporting the S/370, but it has taken decades for me to come to grips with the difference between mainframes and PCs. The idea of a BIOS for even the mainframe is the latest instalment, approx 1 day old.

With the C language now on mainframes at zero cost, a large chunk of the task I set myself has been done. But just recently I realized that PDOS would work on other platforms besides 80386 too, so I altered my goal to spread both PDPCLIB and PDOS to other environments, to see what happened. And AmigaOS radically changed my thinking. An OS providing a list of functions to directly call. I want to redesign PDOS to do the same thing, except I'm going to make it actual C functions that can be directly called, not requiring assembler. I don't care about system vs user. I only care about getting C compiles to go through.

[kerravon]

Originally Posted by meynaf

I think you misunderstood me. I'm not calling PDOS an Amiga emulator. But you intend to run Amiga version of PDOS on an emulator. The point is, you don't really need an Amiga emulator, you could run PDOS on the host directly.

By "host" you mean something like an x64 Windows machine? I want PDOS to get some exercise running 68000 instructions.

You can't really do that and expect normal Amiga programs to run. What's located at address 4 is a big structure called ExecBase, it's not just a bunch of functions. Then from here there is a whole pack of libraries/devices/resources that can be opened and again give new structures and functions.

Depends what you mean by "normal". My PDPCLIB-based "hello, world" will look like a normal AmigaOS executable, with the only slight difference being an *extension* to enable the executable to use a different SysBase instead of the default of 4.

[kerravon]

Originally Posted by Thomas Richter

That wouldn't be (easily) possible on the Amiga. As soon as you write address 4, you kill the machine. There are some very convoluted and complicated tricks around it such as using the MMU, but whether that fits into your strategy I do not know. Note that address 4 is just below the 68000 autovectors, so on a typical 68K machine, you wouldn't want to touch this area in any case.

No, I won't overwrite address 4. I will just present an alternate SysBase to executables. Those that know how to detect it will run. Those that don't will execute the AmigaOS host and that is outside scope for me.

This can be either implemented by going through the exec function DoIO(), accessing a device driver, but that needs AmigaOs intact. Or, through a file emulating a harddisk, using Seek() and Read(), and that also needs the "dos.library" aka "Tripos". DoIO() you already have in the boot sector of the floppy. Read() you only have after dos.library has been initialized, which is done in the boot sector. In either case, you need a working AmigaOs.

Yes, I have no intention of running without AmigaOS anymore.

Note that AmigaOs does NOT execute code from the RDB (the MBR lookalike of Amiga). Thus, there is no classical boot sector in the PC sense on harddisks.

Ok, I don't need that for how I intend to run PDOS on the Amiga now. There will instead be a new AmigaOS executable that exports some BIOS-like functions, and executes the PDOS executable which will then call those BIOS-like functions.

[phx]

Originally Posted by kerravon

What do you think of the feasibility of implementing some UEFI-inspired wrapper instead of calling the exact Atari BIOS functions?

"UEFI-inspired" might be ok, although quite complex.

The idea of EFI is a bad one. It is driven by Intel/Microsoft and as such it is not focussed on being portable, but to restrict the computer owner's control of his own hardware and make it more difficult to do what you want with it. And it doesn't even solve all the problems of a BIOS.

The best firmware/BIOS solution was OpenFirmware. A truly open, portable and IEEE standardized one.

[meynaf]

Originally Posted by kerravon

Armed with a standardized language, I wanted to spread that language to every bit of hardware in existence, to create a universal language for computers.

That looks like a good way to go.
Yet i doubt C is the right language for doing that. It has its issues and while they can be worked around, it's not good if the goal is to be universal.
I'm working on something like this, but at a different level. I created my own asm language and API set, to build a VM. Every program using it then don't have to be altered to work on a new platform, only the VM has.

Originally Posted by kerravon

An OS providing a list of functions to directly call.

I can't see another good way of doing it.

Originally Posted by kerravon

By "host" you mean something like an x64 Windows machine? I want PDOS to get some exercise running 68000 instructions.

Yep. But if what you want to do is to execute 68000 instructions, of course you need the emulator.

Originally Posted by kerravon

Depends what you mean by "normal". My PDPCLIB-based "hello, world" will look like a normal AmigaOS executable, with the only slight difference being an *extension* to enable the executable to use a different SysBase instead of the default of 4.

What would that different SysBase contain then ?

[kerravon]

Originally Posted by meynaf

What would that different SysBase contain then ?

AmigaPDOS's version of SysBase. The same structure as AmigaOS, but just the minimal functions that it knows PDPCLIB is going to call it with.

[meynaf]

Originally Posted by kerravon

AmigaPDOS's version of SysBase. The same structure as AmigaOS, but just the minimal functions that it knows PDPCLIB is going to call it with.

But AmigaOS SysBase is actually ExecBase, the library structure of exec.library. And it contains quite a lot of information that PDPCLIB has no need for.

[kerravon]

Originally Posted by meynaf

But AmigaOS SysBase is actually ExecBase, the library structure of exec.library. And it contains quite a lot of information that PDPCLIB has no need for.

Yes, my version of ExecBase will only have what PDPCLIB needs to access. The rest will be filler.

[meynaf]

Originally Posted by kerravon

Yes, my version of ExecBase will only have what PDPCLIB needs to access. The rest will be filler.

Why respecting the original layout instead of having your own ? It's not as if traditional amiga programs would use it.

[kerravon]

Originally Posted by meynaf

Why respecting the original layout instead of having your own ? It's not as if traditional amiga programs would use it.

PDPCLIB programs will still run on standard AmigaOS, so they will be using the original layout, so I must conform to that.

Anyway, I've just written the startup assembler code for PDPCLIB for AmigaOS if anyone wants to comment on what I have so far.

***********************************************************************
* *
* This program written by Paul Edwards. *
* Released to the public domain *
* *
***********************************************************************
***********************************************************************
* *
* amistart - startup code for AmigaOS. *
* *
* This uses the Motorola syntax *
* *
* It saves the standard AmigaOS registers containing the command *
* buffer (a0) and command length (d0) as well as the AmigaPDOS *
* extension register (only visible if running AmigaPDOS) a6, *
* containing an alternative SysBase to use (only if d0 is greater *
* than or equal to 2 GiB, and in which case, 2 GiB should be *
* subtracted from d0 before use). *
* *
* All this manipulation is left for the C startup code to handle. *
* *
***********************************************************************
*
section "CODE",code
xref ___d0
xref ___a0
xref ___a6
xref ___start
xdef ___amistart
*
___amistart:
move.l d0,___d0
move.l a0,___a0
move.l a6,___a6
jsr ___start
rts

[phx]

When __start() is a C function I would pass __d0, __a0, __a6 as arguments on the stack and don't waste static memory:

        movem.l d0/a0/a6,-(sp)
        jsr     ___start

Then in C:

int __start(int cmdlen,char *cmdptr,void *pdosbase)

[meynaf]

Originally Posted by kerravon

PDPCLIB programs will still run on standard AmigaOS, so they will be using the original layout, so I must conform to that.

You don't need to. PDPCLIB will know if it runs under AmigaOS or not, from the value in D0. So it can adapt.

[kerravon]

Not sure if this is a show-stopper.

I have made minimal changes to get everything to compile and assemble, but I'm getting a stack of linker errors, e.g.

Error 21: stdio.o (CODE+0x41b0): Reference to undefined symbol __ieeecmpd


Any idea what those are?

Thanks. Paul.

[kerravon]

Originally Posted by meynaf

You don't need to. PDPCLIB will know if it runs under AmigaOS or not, from the value in D0. So it can adapt.

True, but if one day AmigaPDOS is running in a situation where it finally gets control of the machine, and can set SysBase to 4, it would be good if non-a6-aware applications that only use minimal Amiga functions such as Read() would start working on AmigaPDOS too.

I can actually implement AmigaPDOS on an artificial 68000 machine, via emulator. One day the machine may actually become real. I don't know what is required to build a real 68000 machine. It will need to have a BIOS of the type discussed previously, which is capable of driving a hard disk. The BIOS will also need another feature to say whether I am the main operating system so that I can know that I can set memory address 4 to my SysBase.

[kerravon]

Originally Posted by phx

When __start() is a C function I would pass __d0, __a0, __a6 as arguments on the stack and don't waste static memory:

        movem.l d0/a0/a6,-(sp)
        jsr     ___start

Then in C:

int __start(int cmdlen,char *cmdptr,void *pdosbase)

Thanks! I adopted a slight variation of that.

[meynaf]

Originally Posted by kerravon

Not sure if this is a show-stopper.

I have made minimal changes to get everything to compile and assemble, but I'm getting a stack of linker errors, e.g.

Error 21: stdio.o (CODE+0x41b0): Reference to undefined symbol __ieeecmpd


Any idea what those are?

Thanks. Paul.

This is linked to float stuff. You need to link with some floating-point .lib or something like that.
Personnally i would instead avoid using floats, but that's just me.

Originally Posted by kerravon

True, but if one day AmigaPDOS is running in a situation where it finally gets control of the machine, and can set SysBase to 4, it would be good if non-a6-aware applications that only use minimal Amiga functions such as Read() would start working on AmigaPDOS too.

That would be a good thing i suppose, but it might make things more complicated than it's worth.
As an example, Read() isn't as minimalistic as it looks. It's in dos.library, not in exec.library. So to access it, you not only have to provide the ExecBase structure, but also DosBase. Furthermore, even if some Read() is provided, the code may or may not work as it can not only read from files but also other peripherals as well (like the input from a console window). Besides, to Read() something you need some Open() as well and the path provided here of course uses the Amiga way of doing, not pc-dos/windows nor unix.

Originally Posted by kerravon

I can actually implement AmigaPDOS on an artificial 68000 machine, via emulator. One day the machine may actually become real. I don't know what is required to build a real 68000 machine. It will need to have a BIOS of the type discussed previously, which is capable of driving a hard disk. The BIOS will also need another feature to say whether I am the main operating system so that I can know that I can set memory address 4 to my SysBase.

You will rarely find a 68000 machine that allows writing to address 4. The Amiga is the only one that i know of. As normally it is the reset vector...

[phx]

Originally Posted by kerravon

Error 21: stdio.o (CODE+0x41b0): Reference to undefined symbol __ieeecmpd

Any idea what those are?

Your code does a floating point IEEE double precision comparison somewhere. As you probably didn't enable FPU-code generation in the compiler (which doesn't exist for plain 68000) you need soft-float support.

AmigaOS has soft-float support in the mathieee*.library, which most Amiga compilers would use. With vbcc you can alternatively link with the standalone soft-float linker library, msoft.lib (-lmsoft), which implements John R. Hauser's free IEC/IEEE Floating-point Artithmetic Package.