PDOS for Amiga

[phx]

Originally Posted by kerravon

https://en.wikipedia.org/wiki/AROS_R...erating_System

A workable AmigaOS Kickstart clone for the Motorola 68000 processor was released on March 31, 2011 as part of a programming bounty.

Perhaps this alternate kickstart can be hacked into an actual BIOS? It may even contain character to graphics conversion capability already?

It's a reengineered AmigaOS clone. So it does things the same like the original, just a bit slower. If you plan to run as an application under AmigaOS anyway, then there is no advantage. If you want to take over the system and write your own BIOS, you may be able to use its source text for reference when writing drivers. Although, there may be better sources for the information you need.

Originally Posted by kerravon

Ok, I don't want that. I would instead like a separately-built PDOS and applications for the PPC.

I took a look at GCC 3.2.3 and there is a target called "rs6000". Do you think that would produce code that will run on these newer flavors of Amiga hardware? I'm still talking about 32-bit of course.

Yes. IBM RS6000 is a PPC workstation (Openfirmware based). But that doesn't matter. You only want it to output PPC code, which it perfectly does.

Just note that without AmigaOS such PPC hardware is no Amiga at all. It has no Amiga hardware. It is a UBoot- or OpenFirmware based PPC-board with standard components. You will boot with the firmware, which in fact is comparable to a BIOS.

Originally Posted by kerravon

Ok, so this function Read():

http://amigadev.elowar.com/read/ADCD.../node02E0.html

would have resided in amiga.lib?

As Thomas wrote, modern AmigaOS compilers can call shared library functions directly (by inlining a

jsr -offset(a6)

call to the function's library vector offset.
This is probably nothing the m68k backend of your compiler can generate, so you will need a linker library with a small assembler stub function to do these calls (amiga.lib).

I think I would like to revive that, to be able to build PDPCLIB (and thus GCC etc) according to the official docs of the Amiga 1000, and have the source still work in newer 68k environments.

If you run as an application under AmigaOS you will be safe. The basic OS functions, which you will use, never changed in later OS releases (would be very bad if they did).
If you want to take over the system, then you need to be prepared for all kinds of M68k CPUs (68000 up to 68060), FPUs and MMUs, countless expansion boards and memory layouts. But I guess this is no longer an option for you, as you want to access a hard disk, and you don't even know which IDE or SCSI chip the controller board uses!

[kerravon]

Originally Posted by Thomas Richter

SysBase = *((struct ExecBase **)(4L));

Great! I think that's everything I need. I think I'm looking at under 200 lines of C code to be added to PDPCLIB. Plus under 100 lines of assembler to implement setjmp/longjmp.

Then I need maybe 100 lines of header files to contain structures like ExecBase. I only need to populate the fields I'm actually interested in, and will have "filler" for the rest. These structures would be provided by the OS (AmigaPDOS) rather than PDPCLIB.

AmigaPDOS also needs to provide amiga.lib containing Read() etc. I think that is the only library I need to actually provide. That's probably 200 lines of code.

Does the DOSBase global variable belong in PDPCLIB or amiga.lib? ie do existing C compilers put the variable in their C library or does Commodore provide it in some *.library (for the first Amiga 1000)?

The first step would be to get the above running under some existing C compiler such as SAS/C, assuming SAS/C allows you to bypass their own header files and libraries. Then a "hello, world" will start working. It is this "hello, world" that I want to run on AmigaPDOS in the medium term, but not the short term.

That would be the end of my involvement with AmigaOS and SAS/C.

Then I would want GCC 3.2.3 for 68000 to be compiled as a cross-compiler on my Windows machine.

Then GCC will start producing 68000 assembler, which looks like this:

cmp%.w %0,%1
fpmove%.l %x1,%x0

I don't know if that is the same format that SAS/C accepts, but it's not that important, as the next step is to build binutils, possibly version 2.14a, as that is what I am currently using to produce executables for PDOS/386. It looks to me like it can produce a.out format executables for 68000. a.out is a format PDOS can already handle. I don't see support for Amiga "hunk" format.

I can modify PDOS to start putting a structure pointer into memory location 4, to make it AmigaOS-like. Accepting OS calls via location 4 instead of INT 21H shouldn't be a big deal. I will not have a switch between application mode and OS mode, everything will run in OS mode, in a single memory space. If a suitable BIOS is available, I'm hopefully looking at 500 lines of C code to be added. I'll keep interrupts disabled so that I don't need much/any 68000 assembler.

Assuming a IBM-PC-style BIOS is available (instead of Kickstart), it will need to have the ability to load the first (boot) sector from a FAT-formatted floppy, which will need to be written in 68000 assembler. Or an MBR plus boot sector from a hard disk.

This will then load the loader (IO.SYS), which needs to be located in consecutive sectors. It is 18k in size.

This then loads the kernel (MSDOS.SYS), which can be located anywhere in the root directory and is about 100k in size.

Then I will be running Amiga programs, just not in Amiga hunk format.

Then in the medium term I can add Amiga hunk format to what PDOS supports. Currently it supports ELF and a.out and Windows executable formats. So then the "hello, world" I described above will immediately start working.

In the longer term, hopefully someone will update binutils to make it produce Amiga hunk format. Or provide an independent assembler and linker. These may even already exist. They need to be restricted to just use Read etc that AmigaPDOS actually supports.

Also in the longer term, support for the Amiga file system can be added to AmigaPDOS, including Amiga-style hard disks which presumably require a different MBR too. Or maybe this bit won't be technically possible?

Anything I've missed?

Thanks. Paul.

[Thomas Richter]

Originally Posted by kerravon

Does the DOSBase global variable belong in PDPCLIB or amiga.lib?

It is an external reference amiga.lib depends upon (an "xref" for the fans of assembler), and something the binary has to provide. Thus, typically, the symbol is provided by the compiler startup code ("c.o"), there filled in, and picked up by the amiga.lib for performing the system call. The amiga.lib is part of the AmigaOs SDK, even though it is rarely needed nowadays.

Originally Posted by kerravon

Then GCC will start producing 68000 assembler, which looks like this:

cmp%.w %0,%1
fpmove%.l %x1,%x0

I don't know if that is the same format that SAS/C accepts,

SAS/C is a C compiler, but it is accompanied by asm, a 68K assembler. It accepts "mot" syntax, that is the syntax that is described by motorola in the "Family guide". Be warned, the arguments of "cmp" are the other way around, i.e. "cmp" is as "sub", with the target at the right-hand.

Originally Posted by kerravon

Also in the longer term, support for the Amiga file system can be added to AmigaPDOS, including Amiga-style hard disks which presumably require a different MBR too. Or maybe this bit won't be technically possible?

I don't think why it wouldn't, after all, Linux also has support for affs, and RDB, the "Amiga variant of MBR".

Originally Posted by kerravon

Anything I've missed?

All the details, of course, and this sounds more like a work plan for the next years to come, of course...

[Bruce Abbott]

Originally Posted by kerravon

I can modify PDOS to start putting a structure pointer into memory location 4, to make it AmigaOS-like. Accepting OS calls via location 4 instead of INT 21H shouldn't be a big deal.

I'll keep interrupts disabled so that I don't need much/any 68000 assembler.

I'm afraid it will be a lot more work than you think. Amiga OS is nothing like a PC BIOS. Different function calls, different structures, different ways of doing things. You cannot disable interrupts for very long and expect the system to work properly!

On the up side though, you should not need any assembler if you only use OS functions.

[kerravon]

Originally Posted by Bruce Abbott

I'm afraid it will be a lot more work than you think. Amiga OS is nothing like a PC BIOS. Different function calls, different structures, different ways of doing things. You cannot disable interrupts for very long and expect the system to work properly!

On the up side though, you should not need any assembler if you only use OS functions.

I'm not talking about Amiga OS, I'm talking about Amiga PDOS. For what reason can I not keep interrupts disabled on Amiga PDOS?

Also, even if I do enable interrupts, how many different interrupts will the hardware generate? Is it just the timer interrupt? And I would actually expect that to have a default handler in the new BIOS. Right? I don't think the BIOS can have a requirement for the operating system to take ownership of interrupts by a particular point.

[kerravon]

Originally Posted by Thomas Richter

SAS/C is a C compiler, but it is accompanied by asm, a 68K assembler. It accepts "mot" syntax, that is the syntax that is described by motorola in the "Family guide". Be warned, the arguments of "cmp" are the other way around, i.e. "cmp" is as "sub", with the target at the right-hand.

It looks to me like GCC 3.2.3 supports Motorola format. From m68k.md:

#ifdef MOTOROLA #ifdef SGS /* Many SGS assemblers croak on size specifiers for constants. */ return "lea 0,%0"; #else return "lea 0.w,%0"; #endif #else return "lea 0:w,%0"; #endif

All the details, of course, and this sounds more like a work plan for the next years to come, of course...

I think I should be able to make the required changes to get a 100% public domain "hello, world" up and running fairly quickly.

Is there anyone interested in assisting with this initial task? No coding is required. I will provide approx 16 68000 assembler files that need to be assembled and linked by an AmigaOS assembler and linker, and then run on AmigaOS.

If you can tell me the command required to assemble a file, and to link 16 object files, I will write a simple script.

It will probably take a number of iterations before it works.

I will do the development in public to give people (anyone) an opportunity to point out any problem they can see.

I don't care if AmigaOS is being run emulated or on real hardware, and I don't care if the assembler and linker being used are commercial or freeware.

Actually, I'm happy to start doing this with the RS6000 target, instead of 68000, if someone is willing to assist with assembling and testing that.

The RS6000 target produces assembler that looks like this:

{andil.|andi.} %0,%1,0xff
{cau|addis} %0,%1,ha16(%2)

So your assembler will need to be able to cope with that.

Thanks. Paul.

[phx]

Originally Posted by kerravon

I'm not talking about Amiga OS, I'm talking about Amiga PDOS. For what reason can I not keep interrupts disabled on Amiga PDOS?

If you choose to run PDOS under AmigaOS then you can't, as disabling interrupts kills AmigaOS.

[phx]

Originally Posted by kerravon

Is there anyone interested in assisting with this initial task? No coding is required. I will provide approx 16 68000 assembler files that need to be assembled and linked by an AmigaOS assembler and linker, and then run on AmigaOS.

You can easily do that yourself. There are cross assemblers (and linkers) which produce AmigaOS executables. You may try this one:
http://sun.hasenbraten.de/vasm/
Build it with

make CPU=m68k SYNTAX=std

and it should be able to consume GCC assembler output, with option -gas. Use option -Fhunk for hunk-format object files and -Fhunkexe for hunk format executables. It's all free and portable ISO-C99 source.

If you need a portable cross linker:
http://sun.hasenbraten.de/vlink/
Build it with "make". Option -bamigahunk outputs hunk-format. All C99.

The RS6000 target produces assembler that looks like this:

{andil.|andi.} %0,%1,0xff
{cau|addis} %0,%1,ha16(%2)

The PPC instruction set certainly has no mnemonics with '{' or '|' in it.
And "ha16" is usually written as "@ha, attached to label, to select 16-bit halfword relocation of the MSW.

[kerravon]

Originally Posted by phx

If you choose to run PDOS under AmigaOS then you can't, as disabling interrupts kills AmigaOS.

No, I do not intend to run PDOS under AmigaOS. I'd rather wait until a BIOS is available. If there is no BIOS available, I'll try my luck with different hardware, such as the VAX.

Even if there is no BIOS available, I'd still like to get PDPCLIB ported to both 68000 and RS6000 flavors of AmigaOS before I move on though.

Also, I realized something else - I'm happy to send C code instead of 68000 assembler files if someone would like to build PDPCLIB for the Amiga with their current C compiler. I could then delay the building of the GCC cross-compiler for Windows until I know PDPCLIB can be made to work. The C code can be downloaded from Sourceforge as a snapshot, or "git" can be used.

[phx]

Originally Posted by kerravon

No, I do not intend to run PDOS under AmigaOS. I'd rather wait until a BIOS is available.

Ok. I guess this will take a very long time.

EDIT: BTW, if you want to target an 68k system with PDOS, the Atari ST may be more suitable. It even has a BIOS, and no multitasking OS.

Even if there is no BIOS available, I'd still like to get PDPCLIB ported to both 68000 and RS6000 flavors of AmigaOS before I move on though.

That should be easy, as soon as you add the I/O and timer calls from AmigaOS to PDPCLIB.

Also, I realized something else - I'm happy to send C code instead of 68000 assembler files if someone would like to build PDPCLIB for the Amiga with their current C compiler.

But, as I understand you didn't port it to AmigaOS yet. So why would you want somebody to try compiling it?

[kerravon]

Originally Posted by phx

EDIT: BTW, if you want to target an 68k system with PDOS, the Atari ST may be more suitable. It even has a BIOS, and no multitasking OS.

Thanks for the tip. Now that I realize the BIOS is the limitation. I'll search out a group.

That should be easy, as soon as you add the I/O and timer calls from AmigaOS to PDPCLIB.

By "timer call", you mean get the current time?

But, as I understand you didn't port it to AmigaOS yet. So why would you want somebody to try compiling it?

If I know someone is willing to compile, or at least test it (now that I seem to have a cross-assembler and linker, still checking that out), I can begin work on making the AmigaOS mods to PDPCLIB.

[phx]

Originally Posted by kerravon

By "timer call", you mean get the current time?

Yes.
BTW, not all Amigas have an RTC chip. But I guess a wrong time doesn't matter, as long as you get any time.

If I know someone is willing to compile, or at least test it (now that I seem to have a cross-assembler and linker, still checking that out), I can begin work on making the AmigaOS mods to PDPCLIB.

Fair enough. You may contact me by email and I will try it. I also have an ANSI-C testsuite, which we use for our own compiler.
(If you don't find my email address, e.g. in the vasm doc, drop me a private message on EAB.)

[kerravon]

Originally Posted by kerravon

Assuming a IBM-PC-style BIOS is available (instead of Kickstart), it will need to have the ability to load the first (boot) sector from a FAT-formatted floppy, which will need to be written in 68000 assembler. Or an MBR plus boot sector from a hard disk.

This will then load the loader (IO.SYS), which needs to be located in consecutive sectors. It is 18k in size.

This then loads the kernel (MSDOS.SYS), which can be located anywhere in the root directory and is about 100k in size.

It occurred to me that the BIOS could be on the disk as IO.SYS, and after loading itself into memory, it then loads the OS under a fixed name from the same disk. I believe this is what the Raspberry Pi does.

Also thanks to Volker pointing me to his website, I am going to start by using his C compiler as well, instead of GCC. I believe I have successfully built the compiler, assembler and linker from his website on my Windows box using gcc from Cygwin.

[kerravon]

Originally Posted by Thomas Richter

There is nothing linked. The executable just retrieves the library pointer, and in that library is an array of functions, one of which is Read(). In old times, there was still a set of "stub functions" in amiga.lib which called through the function pointer array of the library,

Did amiga.lib exist in the first release of the Amiga SDK issued after the Amiga 1000 was released?

In order to execute Read(), were you nominally required to
#include <clib/dos_protos.h>
(and did that exist in the first SDK?)

I'm thinking that I would like to have the above header file, but make it:

#define Read(a, b, c) DOSBase->Read(a,b,c)

rather than having a normal prototype and a real function.

It would be transparent to any application that was following the rules.

Is there anything wrong with that approach?

Thanks. Paul.

[kerravon]

Rather than use gcc 3.2.3 with the 68000 target, I'd like to try Volker's C compiler instead.

I'd prefer to execute the compiler directly, not requiring vc with a config file. And just generate the assembler file. That's how I run gcc too. I get these errors:

vbccm68k -gas -I . -I ../src -S -o amistrt.s amistrt.c
error 5: Unknown Flag <-S>

vbccm68k -gas -I . -I ../src -o amistrt.s amistrt.c
error 3: Flag <-o> needs string

Anyone know what parameters are required? I'd rather generate .s than .asm because .s are temporary assembler files in PDPCLIB, while .asm is genuine source code.

Thanks. Paul.

[phx]

Originally Posted by kerravon

Did amiga.lib exist in the first release of the Amiga SDK issued after the Amiga 1000 was released?

I think so. Although many compilers already provided their own amiga.lib (with the same functionality).

In order to execute Read(), were you nominally required to
#include <clib/dos_protos.h>

Yes. It defines the prototypes for the dos.library functions as well as the data types and structures used in the calls.

(and did that exist in the first SDK?)

No. The first SDK was long before C90 existed. So it wasn't that common to use prototypes for functions you call. The Kickstart 1.3 SDK was still missing them.

I'm thinking that I would like to have the above header file, but make it:

#define Read(a, b, c) DOSBase->Read(a,b,c)

That wouldn't work. There is no "Read" in the DOSBase structure. If want to know the details: Every shared library has a Base structure, like DOSBase, which stores some, mostly internal, data for the library. Invisible for C there is a jump-table in front of this structure in memory. For example at offset -42 relative to DOSBase you will find the vector "jmp ReadFunctionInROM", which jumps to the actual Read() function which is valid for your current OS version. Each vector has 6 bytes (jmp-instruction and 32-bit destination address). That's where amiga.lib comes into play. It defines assembler stub functions like:

        xref    _DOSBase

        xdef    _Read
_Read:
        movem.l d2-d3/a6,-(sp)
        movem.l 16(sp),d1-d3
        move.l  _DOSBase,a6
        jsr     -42(a6)
        movem.l (sp)+,d2-d3/a6
        rts

Which saves/restores non-volatile registers for the function call (d2, d3, a6), loads the C arguments from stack into the required registers for the Read() function, and finally calls its vector relative to DOSBase in register a6.

Originally Posted by kerravon

vbccm68k -gas -I . -I ../src -S -o amistrt.s amistrt.c
error 5: Unknown Flag <-S>

-S is a frontend option for vc to generate assembler code. The compiler itself always generates assembler output. So not needed here.

vbccm68k -gas -I . -I ../src -o amistrt.s amistrt.c
error 3: Flag <-o> needs string

That would be the frontend syntax again. The option in the compiler is different. It is "-o=name". Also note that you may want to enable optimisations at some point (-O=991 would be -O1 from the frontend, refer to the documentation for all optimiser flags).

[kerravon]

Originally Posted by phx

No. The first SDK was long before C90 existed. So it wasn't that common to use prototypes for functions you call. The Kickstart 1.3 SDK was still missing them.

Ok, good point! My interest is all 32-bit environments and C90. Both things needed to happen. So I'd like to "explore the world of computers" armed with these 2 things. So I'm happy to only support a version of AmigaDOS that actually supported C90. I'm also happy to wait until there is sufficient memory available so that I don't need to support virtual memory to do my tasks.

That wouldn't work. There is no "Read" in the DOSBase structure. If want to know the details: Every shared library has a Base structure, like DOSBase, which stores some, mostly internal, data for the library. Invisible for C there is a jump-table in front of this structure in memory. For example at offset -42 relative to DOSBase you will find the vector "jmp ReadFunctionInROM", which jumps to the actual Read() function which is valid for your current OS version. Each vector has 6 bytes (jmp-instruction and 32-bit destination address). That's where amiga.lib comes into play. It defines assembler stub functions like:

jsr -42(a6)

Ok, thanks. Can I have a:

#define Read(a,b,c) (int (*)())((char *)DOSBase - 40)(a,b,c)

Also, is there a way of deriving these offsets from this:

http://amigadev.elowar.com/read/ADCD.../node0075.html

I don't know how to convert:

LIBENT Read

into offset 42. No matter which direction I count from.

The option in the compiler is different. It is "-o=name".

Thanks. Working now.

[Thomas Richter]

Originally Posted by kerravon

Ok, thanks. Can I have a:

#define Read(a,b,c) (int (*)())((char *)DOSBase - 40)(a,b,c)

Trust your compiler vendor. Every amiga-aware compiler comes with a file

<pragmas/dos_pragmas.h>

which defines Read() in a way that is most convenient for the compiler. Do not roll your own, somebody else did that already for you.

Originally Posted by kerravon

I don't know how to convert:

LIBENT Read

into offset 42. No matter which direction I count from.

You don't. Your compiler vendor does that for you. Practially, every library comes with a ".fd" file which describes the entry points to the library, and every compiler comes with an "FD2Pragma" type program which creates the compiler-specific pragma file. Actually, there is an FD2Pragma in Aminet which supports most Amiga compilers. But, as said, that was already done for the dos.library, so you don't need to do that for you.


Just a matter of warning: If your program runs from the boot block of the disk, then there will be no dos.library at that point. It is rather initialized by the boot block.

[phx]

Originally Posted by kerravon

Ok, thanks. Can I have a:

#define Read(a,b,c) (int (*)())((char *)DOSBase - 40)(a,b,c)

No. All AmigaOS shared library functions require arguments in specific CPU registers. Not on the stack.
Passing arguments in registers is compiler specific. And your syntax was wrong. Maybe something like:

#define Read(a,b,c) ((int (*)(__reg("d1")int, __reg("d2")int, __reg("d3")int))(*(char **)((char *)DOSBase-40)))(a,b,c)

__reg is vbcc specific. On some older gcc/68k backends the equivalent would be __asm.

http://amigadev.elowar.com/read/ADCD.../node0075.html

I don't know how to convert:

LIBENT Read

into offset 42. No matter which direction I count from.

This is standard mot-syntax source with a macro. If you look closer you see that vsize is the vector size (6 bytes) and that the first four vectors in a shared library are always reserved. So the count starts at -30 for Open.

Usually you will use FD files (dos_lib.fd), which define the the offset and register arguments of library functions. These FD files can be used as input for tools like fd2pragma, which can generate anything you need. From assembler stub functions over compler-specific inline code to a complete linker library. Portable source is here: http://phoenix.owl.de/fd2pragma.tar.gz

[phx]

Originally Posted by Thomas Richter

<pragmas/dos_pragmas.h>

which defines Read() in a way that is most convenient for the compiler.

Just as a note, in case anybody else is reading this: I would not recommend to include compiler specific headers, like <pragmas/...>, <inline/...>, or whatever they are called. Use

<proto/libname.h>

and your compiler vendor will guarantee to include the optimal pragma/inline solution.