PDOS for Amiga

[meynaf]

Originally Posted by kerravon

PDOS is an operating system. I don't think it is correct to call it an "Amiga emulator". I do intend to have it support Amiga executables, but it can do that even on some other 68000 machine that has a BIOS (not necessarily the Atari).

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.

Originally Posted by kerravon

There are lots of hard disks on a mainframe. Yes, systems programmers have access to hard disks and can install whatever they want on there (so long as management doesn't stop them). They can then IPL off those disks. Obviously easier to do on a DR site. PDOS/3X0 post-dates my career as a mainframe systems programmer, so I do the same thing using a mainframe emulator (Hercules) instead.

Of course on an emulator you can do whatever you want. I was surprised a system that's usually taking a whole level of a building being the target of a custom made OS

Originally Posted by kerravon

Absolutely. That is my first step, and I have everything I need to do that already. My questions are about what comes after that, which is PDOS. I may still have some questions about PDPCLIB, but none at the moment.

Ok then, but perhaps the experience you'll get while implementing PDPCLIB will be useful for doing PDOS and might change your ideas about its design.

Originally Posted by kerravon

I want to write to memory address 4 to install my own Sysbase and handle requests from Amiga hunks myself.

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.

Originally Posted by kerravon

I realized something I would like to do. I don't know if AmigaOS supports FAT-16 and FAT-32 file systems with LFN support, but PDOS does. So I would like to treat AmigaOS as a "very big BIOS" (as you suggested) and get access to raw hard disks. These raw hard disks could then be transported to another machine that understands FAT.

There is software on the Amiga (such as CrossDos and Fat95) that supports FAT-16 and FAT-32, even with LFN support.

Originally Posted by kerravon

I have my own file system to support. I just need access to the hard disk, by sector, and PDOS will do the rest. That's what PDOS is designed to do.

New file systems can be added to AmigaOS, but if you don't want to do that then your only solution is the disk image file.

Originally Posted by kerravon

Sure. But you don't need an operating system at all if you only intend to read/write flat files. I do agree that flat files are useful if I only want to run in an emulated environment.

Flat files can be used on real hardware too. This is what i did with Mac emulator on my A1200.

Originally Posted by kerravon

On PDOS, without much work, there will be a SysBase. 80386 executables running under PDOS could start doing calls via SysBase. There is no reason why the SysBase interface should be restricted to 68000/Amiga. It's just as valid an interface as INT 21H or kernel32. The only problem is that address 4 may not be available. I think it might be used for 8086 interrupts. I really need executables to be flexible with that address. It should be provided as a parameter/register to executables I think. So I will need a modified AmigaOS 80386 executable. The startup code needs to be modified anyway, because of the different registers 80386 vs 68000, so I don't think that should be an issue.

Direct access of address 4 in system calls done in user programs isn't quite a good solution, even if it's just for 68000. As while Amiga won't stop you doing this, Atari ST will not let you access address 4, let alone writing to it. You'll get nice bus error leading to the display of two bombs on screen
(And you probably don't want to close the door to an ST implementation.)

I believe it would be simpler to use the trap interface instead. On 80x86 you would use some unused INT, on 68000 some available TRAP.

[Thomas Richter]

Originally Posted by kerravon

I want to write to memory address 4 to install my own Sysbase and handle requests from Amiga hunks myself.

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.

Originally Posted by kerravon

I realized something I would like to do. I don't know if AmigaOS supports FAT-16 and FAT-32 file systems with LFN support, but PDOS does.

AmigaOs (or rather, its Tripos subsystem) supports any file system that someone implements on top of its infrastructure, and certainly there are implementations of FAT on top of AmigaOs. The Os comes with CrossDos, which is a FAT implementation.

Originally Posted by kerravon

I have my own file system to support. I just need access to the hard disk, by sector, and PDOS will do the rest. That's what PDOS is designed to do.

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.


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.

[kerravon]

Amiga executables get the command length in d0 and the command buffer in a0.

I would like to pass SysBase (normally 4) in another register, e.g. d1.

Obviously only d1-aware executables will actually switch to that new base address. I can make PDPCLIB-based programs d1-aware.

For PDPCLIB-based programs to still work on standard AmigaOS, I cannot expect d1 to be set. It is a random value.

I was thinking that what I could do is see if d0 is more than 2 GiB. If it is above 2 GiB, then I will do two things:

1. Subtract 2 GiB from d0
2. Set SysBase to d1

Otherwise, SysBase will be set to 4.

That would give me the flexibility to run PDOS under AmigaOS and load and handle d1-aware Amiga executables (within PDOS).

Does that sound feasible?

Thanks. Paul.

[kerravon]

Originally Posted by meynaf

Direct access of address 4 in system calls done in user programs isn't quite a good solution, even if it's just for 68000. As while Amiga won't stop you doing this, Atari ST will not let you access address 4, let alone writing to it. You'll get nice bus error leading to the display of two bombs on screen

Can you explain why address 4 is inaccessible on the Atari ST? Remember that I would only be using the Atari BIOS, not the Atari OS.

Thanks. Paul.

[Thomas Richter]

Originally Posted by kerravon

Amiga executables get the command length in d0 and the command buffer in a0.

That is, in this generality, wrong. Amiga executables get their arguments in the buffer of their input stream. This is where the system function ReadArgs() gets them. The unparsed arguments are *also* in d0/a0, but the system argument parser does not get them from there.

Originally Posted by kerravon

I would like to pass SysBase (normally 4) in another register, e.g. d1.

A much more logical choice would be a6, but whatever it is, AmigaOs executables do not expect to find SysBase in any register, and thus have to pick them up from address 4. Actually, the whole procedure of starting AmigaOs executables is a bit delicate if you really want to be compatible because you would have to the Tripos services for it, that is, dos.library/RunCommand(). This sets up the right environment for all of them.

Originally Posted by kerravon

Does that sound feasible?

No, it sounds you need to learn a lot more about the Tripos legacy of AmigaOs. Starting an executable in an AmigaDos compatible way is a bit more involved, and I would always recommend going through the dos.library for it since it is aware of all the magic.

[kerravon]

Does this "VM" facility actually exist on the 68000? It sounds like something that would need a more modern processor.

[phx]

Originally Posted by kerravon

Amiga executables get the command length in d0 and the command buffer in a0.

Correct.

I would like to pass SysBase (normally 4) in another register, e.g. d1.

Obviously only d1-aware executables will actually switch to that new base address. I can make PDPCLIB-based programs d1-aware.

(...)
That would give me the flexibility to run PDOS under AmigaOS and load and handle d1-aware Amiga executables (within PDOS).

So what you are trying to achieve is to create executables, linked with PDPCLIB, that can run under both, AmigaOS and PDOS? Then all linked PDPCLIB functions must always include code to run under both options, which is determined at run-time?

Why would you want that? Wouldn't it be easier to define at compile-time that you are creating a PDOS-only executable? If you want PDOS to run under AmigaOS (which your last postings seem to imply) you could implement PDOS as another shared library (pdos.library), which is opened by the executable's startup code.

A similar solution already exists for POSIX functions under AmigaOS (ixemul.library).

EDIT: Reading Thomas' reply I probably didn't understand what you want... never mind.

[phx]

Originally Posted by kerravon

Can you explain why address 4 is inaccessible on the Atari ST?

Meynaf has probably more Atari exprience than me, but I seem to remember that the hardware mirrors the (first?) 8 bytes of the ROM at address 0, so the CPU find its reset vector there when switched on. So you cannot write to it.

[kerravon]

As discussed, the Atari BIOS is accessed via trap #13.

Would it have been just as good to access the BIOS functions via a fixed address in memory (similar to SysBase) or is there an advantage to doing a trap?

What's the underlying philosophy here?

Thanks. Paul.

[Thomas Richter]

Originally Posted by phx

Meynaf has probably more Atari exprience than me, but I seem to remember that the hardware mirrors the (first?) 8 bytes of the ROM at address 0, so the CPU find its reset vector there when switched on. So you cannot write to it.

There is more to it. Atari, unlike Amiga, does check the function codes for some memory regions, and chances are that the lower addresses are not writable (nor readable) for user function codes. At least the ST hardware was not user-visible, a bus error would result in any attempt to access them from user level.

[kerravon]

Originally Posted by phx

So what you are trying to achieve is to create executables, linked with PDPCLIB, that can run under both, AmigaOS and PDOS?

Correct.

Then all linked PDPCLIB functions must always include code to run under both options, which is determined at run-time?

I don't understand what you mean by "linked PDPCLIB functions". PDPCLIB is a C runtime library. Any C90 application linked with PDPCLIB will pick up the a5-aware startup code.

Why would you want that? Wouldn't it be easier to define at compile-time that you are creating a PDOS-only executable?

The executable would not be PDOS-only. The executable would be universal.

If you want PDOS to run under AmigaOS (which your last postings seem to imply)

Also Atari ST without Atari OS. But perhaps with different builds of PDOS. Jury's out on that.

you could implement PDOS as another shared library (pdos.library), which is opened by the executable's startup code.

No, this is miles away from what I want.

[Thomas Richter]

Originally Posted by kerravon

A Would it have been just as good to access the BIOS functions via a fixed address in memory (similar to SysBase) or is there an advantage to doing a trap?

The advantage of the trap is that it transfers the CPU to supervisor space, and thus the operating system code is run in supervisor space. From an Os design point of view, this makes a lot of sense as it may enable the Os to access protected resources, or run CPU instructions for maintaining the CPU itself. </br> </br> The Amiga did not work like that, everything was user code, except for a small part of the exec scheduler, and even user code could request to execute small functions in supervisor code. </br> </br> If you ask me, this was a very bad design decision at AmigaOs side and isolation between user code and supervisor code should have been done more carefully.

[kerravon]

Originally Posted by Thomas Richter

There is more to it. Atari, unlike Amiga, does check the function codes for some memory regions, and chances are that the lower addresses are not writable (nor readable) for user function codes. At least the ST hardware was not user-visible, a bus error would result in any attempt to access them from user level.

What is a (user) function code(s)? Also, if the 68000 differentiates between user-level and system-level, would it be possible to run everything at system-level and be able to read/write location 4?

[Thomas Richter]

Originally Posted by kerravon

Does this &quot;VM&quot; facility actually exist on the 68000? It sounds like something that would need a more modern processor.

"VM" is here meant in a figurative sense, not in the literal sense. No, the 68000 itself does not have the ability to isolate a VM properly (unlike its later follow-up processors). But that doesn't mean that something close to a virtualization isn't possible. As long as the caller of your (emulated) VM goes through a trap to receive services from an "operating system", it does not matter whether the service function that receives the trap is actually implementing an Os, or calls into the regular host operating system to receive services from there.

[kerravon]

Originally Posted by Thomas Richter

The advantage of the trap is that it transfers the CPU to supervisor space, and thus the operating system code is run in supervisor space.

What about if the SysBase-like BIOS functions simply did that trap themselves, to any trap number the BIOS-writer would like? Wouldn't this provide a more flexible solution, especially for environments where traps are unavailable for some reason?

[meynaf]

Originally Posted by kerravon

Can you explain why address 4 is inaccessible on the Atari ST? Remember that I would only be using the Atari BIOS, not the Atari OS.

It mirrors reset vector from ROM - which means it can not be altered in any manner. Also, being in low mem, it's protected from usermode access even when reading.
The hardware itself is made this way, software doesn't control it.

Originally Posted by kerravon

Does this "VM" facility actually exist on the 68000? It sounds like something that would need a more modern processor.

That depends how far you want to push it.

Originally Posted by kerravon

As discussed, the Atari BIOS is accessed via trap #13.

Would it have been just as good to access the BIOS functions via a fixed address in memory (similar to SysBase) or is there an advantage to doing a trap?

What's the underlying philosophy here?

I don't know if there's really a philosophy here, it's just a different way of doing. On the Amiga most of the OS runs in user mode, on the ST it runs in supervisor mode.

Originally Posted by kerravon

What is a (user) function code(s)? Also, if the 68000 differentiates between user-level and system-level, would it be possible to run everything at system-level and be able to read/write location 4?

See 68000 docs about FCx signal. The 68k family separates data from code (even though this was rarely effectively used) and the supervisor state is also present here.
Yes everything could run at system level but even though you could then read address 4, you still wouldn't be able to write it.

[kerravon]

Originally Posted by kerravon

What about if the SysBase-like BIOS functions simply did that trap themselves, to any trap number the BIOS-writer would like? Wouldn't this provide a more flexible solution, especially for environments where traps are unavailable for some reason?

And when the BIOS loads an OS, via the normal method (e.g. boot sector on IBM PC floppy), when the BIOS passes control to the OS/boot sector code, it could pass, in a register or on the stack, the address in memory where the SysBase-like BIOS functions are located.

Wouldn't this be a universal solution for all computers? Or at least, future ones?

[Thomas Richter]

Originally Posted by kerravon

And when the BIOS loads an OS, via the normal method (e.g. boot sector on IBM PC floppy), when the BIOS passes control to the OS/boot sector code, it could pass, in a register or on the stack, the address in memory where the SysBase-like BIOS functions are located.

Wouldn't this be a universal solution for all computers? Or at least, future ones?

I'm sorry, but I don't understand the goals here. Amiga doesn't have a Bios, and it wouldn't get one. A "bios" in that sense isn't necessary. There wouldn't be any "future" machines based on 68K since it is a dead platform. How an operating system implements its services is rather a matter of the operating system, and there is no "universally right way". There are many different ways to isolate system from user. The AmigaOs way is not a very good one (no isolation whatsoever). The x86 uses (software)-interrupts for the isolation. Atari ST on 68K uses traps, MacOs on 68K uses the line-A emulation. I don't even know what Linux does.

[Don_Adan]

For me PDOS on Amiga has two ways. First like Amix, second like EmuTOS.

[kerravon]

Originally Posted by Thomas Richter

I'm sorry, but I don't understand the goals here. Amiga doesn't have a Bios, and it wouldn't get one. A "bios" in that sense isn't necessary.

The goal is a clean PDOS for 80386, 68000 (both AmigaOS and Atari BIOS), and a clean BIOS interface for PDOS to talk to. AmigaOS providing the cleanest environment of the lot, since the BIOS calls would ideally not involve traps. The BIOS would consist of Commodore-documented calls to AmigaOS.

There wouldn't be any "future" machines based on 68K since it is a dead platform.

I'm talking about any processor, including ones that haven't been designed yet.

How an operating system implements its services is rather a matter of the operating system, and there is no "universally right way". There are many different ways to isolate system from user. The AmigaOs way is not a very good one (no isolation whatsoever).

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.

The x86 uses (software)-interrupts for the isolation.

That's fine. It's just that that should be outside the view of the application (by doing it AmigaOS-style). And the BIOS calls done by x86 operating systems should similarly be done AmigaOS-style, with the interrupt being done without the knowledge of the OS.

Atari ST on 68K uses traps,

Again, fine, so long as there is a SysBase-like interface that hides that.

MacOs on 68K uses the line-A emulation.

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