PDOS for Amiga

[kerravon]

Hi.

I have written a public domain (not GPL etc) C runtime library (called PDPCLIB) for 8086 and 80836 platforms including MSDOS, Windows, OS/2, Linux, plus mainframe operating systems (MVS, CMS, VSE). You can find that here:

http://pdos.sourceforge.net/

I am considering porting that to the Amiga. Preferably using 68000 instructions. But probably with 32-bit ints.

I have also written my own public domain operating system (called PDOS) which currently runs on 8086, 80386 and S/3X0 (mainframe). It is available at the same link above.

I would like to port that to the Amiga too.

I am interested in using GCC 3.2.3, as I have banged that into C90 shape already.

I am only interested in supporting the C90 language.

I'm not sure if it is technically possible (that's my question), but I was thinking I could start by having a FAT-16 disk (since I already have FAT code) and the "Pos" interface, which is a wrapper on the MSDOS API, and ELF modules, to try to get something operational ASAP.

But eventually I would like to support the normal Amiga file system (instead of FAT), and the AmigaDOS API (whatever that is, I'm not familiar with that), and the Amiga Hunk executable format. Some of this will be limited by availability of tools though, as I don't wish to write my own C compiler, assembler or linker.

The objective is for AmigaPDOS (or whatever it would be called) to be able to rebuild the kernel under AmigaPDOS, as well as being able to rebuild gcc-amiga-pdos.

Note - C90 = ISO C = C89 = ANSI C.

I would like to eventually be in a position where a "hello, world" program could be built on a standard AmigaDOS system, with any compiler (such as SAS/C), but using PDPCLIB as the C runtime library, so that the entire "hello, world" is public domain, and then have that program run unchanged on AmigaPDOS.

It would also be good if the 68000 emulator could address the entire 4 GiB of memory, but 64 MiB is in fact enough to run GCC 3.2.3. It only needs about 23 MiB to rebuild itself with full optimization.

Oh, I'm also not interested in graphics. I am hoping that the Amiga has the ability for an OS to write a character to the screen without needing some sort of graphics library.

Any guidance?

Thanks. Paul.

[roondar]

Sounds like a nice project!
I'm not an OS coder so can't help you there much, but I do know a few things about the Amiga Hardware.

And sadly, one thing you will not be able to do is create a text based screen. The Amiga's native chipsets only support bitplane based graphics using indexed colours. There are no text modes, so you'll have to emulate those yourself.

[kerravon]

Originally Posted by roondar

And sadly, one thing you will not be able to do is create a text based screen. The Amiga's native chipsets only support bitplane based graphics using indexed colours. There are no text modes, so you'll have to emulate those yourself.

Bummer.

However, I would be happy to drive a serial port instead, and rely on the user attaching some sort of VT100 terminal (emulated of course), or another computer, to the serial port prior to booting.

I basically have to do something like that for the mainframe version of PDOS too.

[Galahad/FLT]

You might want to rethink or rejig the name you've given your project.

PDOS exists under an entirely different guise on Amiga and it would be a shame for your project to fly under the radar because people wrongly assume its the other PDOS

[kerravon]

Originally Posted by Galahad/FLT

You might want to rethink or rejig the name you've given your project.

PDOS exists under an entirely different guise on Amiga and it would be a shame for your project to fly under the radar because people wrongly assume its the other PDOS

Ok, thanks. What's the other PDOS? Note that people only find out about PDOS when they type in "public domain OS" into google, wondering if anyone has already written one. There's unfortunately even another operating system called PDOS, and that actually got media attention so made it into Wikipedia.

I now have a specific question. I need to be able to read disk sectors. I assume that it is only possible for an operating system to do that if Kickstart is already loaded. What sort of interface did the very first publicly-released version of Kickstart provide to read disk sectors? I'm after clean 32-bit pointers.

And does the latest Kickstart still support that interface?

I know there is a freeware replacement for Kickstart. Does it provide the same interface above?

Thanks. Paul.

[jotd]

pdos (rob northen floppy disk code) can read disk sectors

and it doesnt need kickstart to be active.

[Bruce Abbott]

Originally Posted by kerravon

I'm also not interested in graphics. I am hoping that the Amiga has the ability for an OS to write a character to the screen without needing some sort of graphics library.

This implies you will be taking over the machine and not using any part of Amiga OS, in which case you will have to write a bit of code to translate characters into graphic patterns - just like you would on other machines that only have bitmap screens (eg. Atari ST).

But that's not all. Without the OS you will have to control all hardware at the lowest level, including video output, floppy drives etc. some of which is quite complicated on the Amiga because the custom hardware is not autonomous and requires a fair amount of assistance from the CPU. But don't despair - most games do this, so there is plenty of example code you can use.

I'm not sure if it is technically possible (that's my question), but I was thinking I could start by having a FAT-16 disk (since I already have FAT code) and the "Pos" interface, which is a wrapper on the MSDOS API, and ELF modules, to try to get something operational ASAP.

To get something going 'ASAP', I suggest using Amiga OS to handle the low level stuff. Disk drives are treated as block devices, so you can put anything on them. For text output you could open a custom screen and use graphic library functions or render directly to the bitmap. Other hardware such as the keyboard and serial port can also be accessed via their device drivers. The essential parts are in ROM, so they are available before the file system comes up.

But eventually I would like to support the normal Amiga file system (instead of FAT), and the AmigaDOS API (whatever that is, I'm not familiar with that), and the Amiga Hunk executable format. Some of this will be limited by availability of tools though, as I don't wish to write my own C compiler, assembler or linker.

To do this you definitely want to keep the OS alive, so you should do so from the start. You could create an interface to it that looks the same as other machines to your OS, but uses Amiga OS functions internally. Ideally it should be fully multitasking friendly, allowing users to run your OS in its own screen without upsetting other programs.

I suggest learning a bit about Amiga OS now, including exec devices and graphics, then dos when it comes to supporting the 'normal' Amiga file system.

The other alternative is to duplicate everything in your own code, which would be a lot of work and preclude running your OS in a multitasking environment. Only do this if you really want your OS to take over the whole machine.

64 MiB is in fact enough to run GCC 3.2.3. It only needs about 23 MiB to rebuild itself with full optimization.

Some of us have fast Amigas with 128MB or more, so it should quite be possible to do it on real hardware.

[Docent]

You should start from defining how you would like to run your os on Amiga.
First option is to take over the hardware and have full control of it. This means that, in order to run some of Amiga programs, you'll need to recreate a number of Amiga libraries, device drivers and generally AmigaOS structures. AmigaOS is a sort of modular micro kernel with well defined APIs, where common module types are libraries, devices and resources. In order to run even a simple AmigaOS console application (ie not using any ui elements) the minimum set of libs you'll need to provide is exec.library and dos.library plus a few devices (timer.device, console.device) and resources, but many programs require other libs and will not run without them.
To run most Amiga programs you'll at least need: exec.library, dos.library, graphics.library, layers.library, intuition.library, utility.library. You'll need also the following devices: console.device, input.device, keyboard.device, serial.device, trackdisk.device, timer.device and a number of resources like cia.resource, misc.resource, disk.resource etc. Recreating them is huge, time consuming task.

The second option is to run your os hosted ie on top of AmigaOS and provide file/memory/console emulation for your PDOS programs using AmigaOS. Later you can try to provide some sort of bridge to native Amiga libraries/devices to run native Amiga programs.
For your PDOS the second option is more real to accomplish. I'd start with porting your system to run hosted, test if any application you have source code for can be compiled and run on such system. Then try to add support for native Amiga programs.
As for the c standard library, it would be the easiest task - most of the code like string operations etc. will probably compile for Amiga as is. For file operations you will need dos.library. memory allocation - exec.library, console - console.device or graphics.library

[kerravon]

Originally Posted by Docent

First option is to take over the hardware and have full control of it. This means that, in order to run some of Amiga programs, you'll need to recreate a number of Amiga libraries, device drivers and generally AmigaOS structures.

Yes, I want to do this - but it will be a minimal implementation. Just enough to run C90 programs - and specifically C90 programs that have been built using PDPCLIB.

dos.library

Ok, thanks for the pointer.

I found this:

https://wiki.amigaos.net/wiki/Basic_...ut_Programming

BPTR myfilehandle = IDOS->Open(UBYTE* filename, LONG accessMode);

That looks doable to me.

PDPCLIB implements PDOS/386 (a 32-bit version of MSDOS, basically) with the use of Pos*() function calls, which you can see here (with some edits to avoid confusion):

C:\devel\pdos\pdpclib>grep Pos *.c
pdossupc.c: if (PosOpenFile(filename, 0, &handle)) *errind = 1;
pdossupc.c: if (PosCreatFile(filename, 0, &handle)) *errind = 1;
pdossupc.c: if (PosReadFile(handle, buf, len, &readbytes)) *errind = 1;
pdossupc.c: if (PosWriteFile(handle, buf, len, &writtenbytes)) *errind = 1;
pdossupc.c: return (PosMoveFilePointer(handle, offset, whence, &dummy));
pdossupc.c: PosCloseFile(handle);
pdossupc.c: PosDeleteFile(filename);
pdossupc.c: PosRenameFile(old, new);
pdossupc.c: *ptr = PosAllocMem(size, POS_LOC20);
pdossupc.c: PosFreeMem(ptr);
pdossupc.c: PosExec(cmd, env);
pdossupc.c: PosGetSystemDate(&year, &month, &day, &dow);
pdossupc.c: PosGetSystemTime(&hour, &minute, &second, &hundredths);
pdossupc.c: PosGetSystemDate(&year, &month, &day, &dow);
pdossupc.c: PosTerminate(retcode);
start.c: p = PosGetCommandLine();
start.c: __envptr = PosGetEnvBlock();

As you can see, there are only a small number of OS calls needed.

So basically for AmigaOS I need to replace PosOpenFile() with Open().

If I use the Open() from dos.library that comes with a recent version of AmigaOS, will the resulting executable actually work on the very first version of AmigaOS on the Amiga 1000?

I would like PDPCLIB to be able to be used with the standard dos.library, but I would also like to build my own mini dos.library with just Open() etc that PDPCLIB actually needs.

Regardless, when I have my executable that calls Open(), what does that executable actually look like? Is there some code linked in that does an INT like MSDOS, or is there a DLL reference like Windows uses, and the AmigaOS (or AmigaPDOS) loader will modify the executable to provide a pointer to the code that needs to be executed?

Thanks. Paul.

[kamelito]

It is for AmigaOS 4, if you wanna target AmigaOS classic you’ve to look there instead.
http://amigadev.elowar.com/

[hooverphonique]

I would suggest using a newer gcc if cross-compilation is ok, as they produce much better code..

[kerravon]

Originally Posted by kamelito

It is for AmigaOS 4, if you wanna target AmigaOS classic you’ve to look there instead.
http://amigadev.elowar.com/

Looks the same, except not referenced by a pointer:

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

file = Open( name, accessMode )
D0 D1 D2

BPTR Open(STRPTR, LONG)

And reading looks clean too:

actualLength = Read( file, buffer, length )
D0 D1 D2 D3

LONG Read(BPTR, void *, LONG)

Is there any reason I shouldn't be targeting AmigaOS classic?

Thanks. Paul.

[kerravon]

Originally Posted by hooverphonique

I would suggest using a newer gcc if cross-compilation is ok, as they produce much better code..

I'm not really interested in code quality. I've already put a huge effort into making GCC 3.2.3 C90-compliant. Chasing the latest (or different) compilers and different languages will be an exercise for someone else. I will have moved on to a different machine by then (e.g. VAX).

[roondar]

Originally Posted by kerravon

Is there any reason I shouldn't be targeting AmigaOS classic?

Thanks. Paul.

It depends on your target. If you want to predominantly target Motorola 68K based systems, then Amiga OS Classic (incl. 3.1.4) are the correct choice. If you want to predominantly target PPC based systems, then Amiga OS 4.0 is the correct choice.

However, in both scenarios I'd have a question: in what way is your OS an OS if it requires a pre-installed other OS? If you use the Kickstart functionality for stuff like reading files, etc you pretty much have to run the whole OS for that to correctly work in all circumstances. It's perhaps best pointed out here that Kickstart doesn't just contain a BIOS, but rather contains the actual micro kernel and a bunch of the OS's libraries etc. The traditional BIOS functionality from the PC doesn't exist as such in the Kickstart, it's all mixed in the with the Amiga OS.

Edit: when I reread the above, it dawned on me it may have sounded somewhat harsh. That wasn't the intention, I'm genuinely interested in your reasons for mixing the existing OS with your new OS. Is your goal merely PDS compatibility, or do you want to have your own OS without any of the Amiga OS getting in the way/being used?

[kerravon]

Originally Posted by Bruce Abbott

This implies you will be taking over the machine and not using any part of Amiga OS,

Yes, I will never load Amiga OS. I actually have an old Amiga 2000HD I think it is in my cupboard, but I never intend to get it out. I intend to use an emulator if emulators are good enough to do what I need.

in which case you will have to write a bit of code to translate characters into graphic patterns - just like you would on other machines that only have bitmap screens (eg. Atari ST).

Thanks for the info on Atari ST. In both cases then, I will read/write to a VT100/ANSI terminal attached to the serial port. I don't want to do anything with graphics.

But that's not all. Without the OS you will have to control all hardware at the lowest level, including video output, floppy drives etc. some of which is quite complicated on the Amiga because the custom hardware is not autonomous and requires a fair amount of assistance from the CPU. But don't despair - most games do this, so there is plenty of example code you can use.

With regard to controlling the floppy drive, is Kickstart the equivalent of the BIOS on an IBM PC? If so, I expect that to be available. Replacing the BIOS is a separate exercise.

To get something going 'ASAP', I suggest using Amiga OS to handle the low level stuff. Disk drives are treated as block devices, so you can put anything on them. For text output you could open a custom screen and use graphic library functions or render directly to the bitmap. Other hardware such as the keyboard and serial port can also be accessed via their device drivers. The essential parts are in ROM, so they are available before the file system comes up.

No, I don't want to use Amiga OS in this process. To get something ASAP I'm willing to abandon the Amiga API in favor of the Pos API and the Amiga filesystem in favor of the FAT-16 filesystem.

To do this you definitely want to keep the OS alive, so you should do so from the start. You could create an interface to it that looks the same as other machines to your OS, but uses Amiga OS functions internally. Ideally it should be fully multitasking friendly, allowing users to run your OS in its own screen without upsetting other programs.

I'm not planning on supporting multitasking. All I want to do is edit C code using micro-emacs and compile it and be able to rebuild GCC and PDOS. Then it's on to some other hardware I'm not familiar with.

I suggest learning a bit about Amiga OS now, including exec devices and graphics, then dos when it comes to supporting the 'normal' Amiga file system.

Yes, I'm doing that now. I'm just getting guidance on where to actually start, assuming what I want to do is even technically possible.

The other alternative is to duplicate everything in your own code, which would be a lot of work and preclude running your OS in a multitasking environment. Only do this if you really want your OS to take over the whole machine.

I managed to get GCC running on PDOS/3X0 in under 10,000 lines of code, using an alien (native) file system and executable format. I took some shortcuts to do that. I'm planning on taking a different approach with the Amiga, by bringing an existing file system with me.

Note that once the work had already been done to make GCC C90-compliant (which was done as a separate project), GCC is basically a glorified "hello, world".

[kerravon]

Originally Posted by roondar

It depends on your target. If you want to predominantly target Motorola 68K based systems, then Amiga OS Classic (incl. 3.1.4) are the correct choice. If you want to predominantly target PPC based systems, then Amiga OS 4.0 is the correct choice.

If I target 68K, will my 32-bit OS and 32-bit applications still work on PPC? If so, that's everything I want.

However, in both scenarios I'd have a question: in what way is your OS an OS if it requires a pre-installed other OS? If you use the Kickstart functionality for stuff like reading files, etc you pretty much have to run the whole OS for that to correctly work in all circumstances.

Good question. My understanding is that the Raspberry Pi comes with a BIOS on disk that gets loaded before the OS. I need to start somewhere. In the case of the say Amiga 500, Kickstart is in ROM, and I think it is quite legitimate to put in a floppy labeled "PDOS" and boot it and get a command prompt where you can type in "dir" and say "yep, that's an OS". Kickstart itself won't do a "dir".

It's perhaps best pointed out here that Kickstart doesn't just contain a BIOS, but rather contains the actual micro kernel and a bunch of the OS's libraries etc. The traditional BIOS functionality from the PC doesn't exist as such in the Kickstart, it's all mixed in the with the Amiga OS.

Perhaps I can be selective in which Kickstart functionality I use? Remembering that I'm making a beeline to get GCC to recompile itself, and that I already have code to read/write FAT, all I really need is a Kickstart function that reads a 512-byte sector from a disk. And even that can be replaced at a later date.

Edit: when I reread the above, it dawned on me it may have sounded somewhat harsh. That wasn't the intention,

Don't worry, I'm inoffensible. :-)

I'm genuinely interested in your reasons for mixing the existing OS with your new OS. Is your goal merely PDS compatibility, or do you want to have your own OS without any of the Amiga OS getting in the way/being used?

I only have a vague idea what I am trying to do, so I am after help creating a sensible goal.

But I bring to the table a C90-compliant GCC and a C90 C runtime library and an existing OS (around 30,000 lines of code).

So I have a solution in search of a problem. And part of the problem is that I have spent decades just coming to grips with the difference between PCs and mainframes. I ended up changing the (emulated) mainframe hardware so that I could have 32-bit addressing instead of just 31-bit (while still being compatible with 31-bit and even 24-bit). It's only just recently that I realized that a better goal was to spread PDOS to other hardware rather than the previous goal which was to add functionality to PDOS/386 to make it more of a Windows clone (still command-line though).

My exploration of different hardware will be tempered by whatever GCC 3.2.3 is able to target and what executable formats binutils is able to build.

When I've exhausted all 32-bit hardware supported by GCC 3.2.3 I will take an interest in later versions of GCC. Or slit my wrists, whatever I feel like doing when/if the time comes. :-) Or maybe I will then try writing my own C compiler or something, something public domain, to replace GCC, even if it is never as good. Or start with the assembler or linker. Or maybe go back to older versions of GCC if there are some 32-bit targets that have been dropped. They dropped i370 after GCC 3.4.6 too, but that is the target I have been using for about 2 decades. Bringing a free C compiler to the commercially-used mainframe environments was a ridiculously long process that even involved the invention of new (emulated) hardware (S/380). Yeah, that's another thing I could do also - work on a public domain emulator.

[kerravon]

Originally Posted by kerravon

Perhaps I can be selective in which Kickstart functionality I use?

And perhaps a suitable subset of standard Kickstart is available here?

https://en.wikipedia.org/wiki/Amiga_emulation

An AROS boot ROM can be used instead of Kickstart

[kerravon]

Originally Posted by kerravon

Good question. My understanding is that the Raspberry Pi comes with a BIOS on disk that gets loaded before the OS. I need to start somewhere. In the case of the say Amiga 500, Kickstart is in ROM, and I think it is quite legitimate to put in a floppy labeled "PDOS" and boot it and get a command prompt where you can type in "dir" and say "yep, that's an OS". Kickstart itself won't do a "dir".

Another piece of information. PDOS/386 has no device drivers. Nor does it make any attempt to directly manipulate the hard disk I/O port. It instead does an entire switch back to real mode in order to call the BIOS to read the hard disk, something that is only available in real mode. The BIOS provides a level of device independence, which is what I'm after. I'm not sure if PDOS/386 would boot from USB stick (hardware emulating a hard disk) if I directly manipulated the I/O ports.

Replacing the BIOS, including with a 32-bit version, is a separate exercise which I am unlikely to ever get involved in. And something that wasn't available when the 80386 first came out (which is what I'm really interested in - I want to go backwards and explore that).

[kamelito]

Originally Posted by kerravon

Looks the same, except not referenced by a pointer:

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

file = Open( name, accessMode )
D0 D1 D2

BPTR Open(STRPTR, LONG)

And reading looks clean too:

actualLength = Read( file, buffer, length )
D0 D1 D2 D3

LONG Read(BPTR, void *, LONG)

Is there any reason I shouldn't be targeting AmigaOS classic?

Thanks. Paul.

AmigaOS 4.x introduced Interfaces which are not present in AmigaOS 1.x to 3.x isn’t the classic the way to go?

[roondar]

Originally Posted by kerravon

If I target 68K, will my 32-bit OS and 32-bit applications still work on PPC? If so, that's everything I want.

As I understand it, the current OS 4.0 solution to this problem is to call an emulator to run the 68K application. I have no idea what happens if you want to run another OS this way.

Good question. My understanding is that the Raspberry Pi comes with a BIOS on disk that gets loaded before the OS. I need to start somewhere. In the case of the say Amiga 500, Kickstart is in ROM, and I think it is quite legitimate to put in a floppy labeled "PDOS" and boot it and get a command prompt where you can type in "dir" and say "yep, that's an OS". Kickstart itself won't do a "dir".

Right, I see what you mean. The issue I'm getting at here is more along the lines of 'how does Kickstart read tracks/sectors from disk for you".

Perhaps I can be selective in which Kickstart functionality I use? Remembering that I'm making a beeline to get GCC to recompile itself, and that I already have code to read/write FAT, all I really need is a Kickstart function that reads a 512-byte sector from a disk. And even that can be replaced at a later date.

Well, you can - to a point. You are not required to use all of Kickstart when booting from floppy. However, that might still not be as helpful as you'd hope.

Essentially, the issue as I understand it is that the trackdisk device in the Kickstart (which you'd need to use to read sectors from disk at the lowest supported level) is not built to be independent of the rest of the OS. Basically, the trackdisk device relies on the kernel for memory allocation and probably runs as a task under Exec as well. If you want to stay compatible with that, you might have to define areas of memory that you can't interact with. And that'll get tricky as one of the areas Exec requires to properly function is the interrupt vector table and secondly, Exec does not guarantee that memory it allocates will be at certain addresses (so the trackdisk.device can end up allocating buffers at essentially a random address).

Basically, the issue is that for the Amiga, the BIOS and the OS are essentially intertwined to a high degree and that there is no official way to bypass this and just say, read a sector from a disk. This is one of the reasons why many Amiga games and demos (those that ditched the OS) back in the day usually had their own, custom made, trackloader to read from disk.

Don't worry, I'm inoffensible. :-)

That's a useful attribute to have, but I'll still try to be friendly though