developing amiga 68000 clone

This is what the JIT compiler and stubs do on AmigaOS4.1.

unless you have source code to 68K programs your not going to get anywhere sadly.

So PDOS generic is like a hosted PDOS.

Any reason D7 was chosen? And not an address register?

It's strange your linker produces LSB ELFs. That might cause problems unless it's just a container. Does it produce MSB ELF now?

So it converts hunks now. Can 68K PDOS code be compiled to ELF directly or still in the works?

joerg wrote:@kerravon
Main problem is that there is next to no AmigaOS software running in a shell, nearly all uses a GUI.

Of course there are a few exceptions like the VIM editor, originally developed on AmigaOS, or S-Lang and ncurses based ports, for example the slrn usenet newsreader, mutt e-mail client and the w3m web browser, some of which I ported to AmigaOS 20-30 years ago, but there is no advantage using an AmigaOS port of any of them compared to the versions on other OSes.

One of the "problems" compared to MS-DOS is that AmigaOS uses ISO-8859 charsets (ISO-8859-1 on AmigaOS <= 3.9, default on AmigaOS 4.x is ISO-8859-15).
With the code page 437 charset used on MS-DOS it's much easier to create text/shell only software since you can "draw" lines/boxes/etc. with the chars 0xB0-0xDF creating a "GUI" in text-only mode, for example like the MS-DOS version of Norton Commander did.
With the ISO-8859 charsets used on AmigaOS that's not possible.

Oh - thanks for that insight! Maybe there needs to be ANSI escapes to draw such characters, and the terminal is required to put a "*" there if it doesn't support a particular box character.

It would be interesting to know if THIS was the show-stopper.

I don't do such box-drawing myself so didn't realize this could be an issue. I only do C90 plus ANSI X3.64 for microemacs, which doesn't draw boxes.

However, my ELF is not executing on qemu-m68k.

It can be, yes. But e.g. I have a version already that uses UEFI for x64 - is that considered to be hosted? Even when my executable is called bootx64.efi and the EFI shell is not used.

I was advised that D5 and above were "free":

However, my ELF is not executing on qemu-m68k. Is there a "note segment" required for Linux?

gccami is used to produce assembler. asami is used to convert that to Amiga hunk object code (no other choice I think). ldami will convert that into a hunk executable (only choice I think - maybe a.out too?). Or now, pdld will convert the Hunk object code into ELF (the only choice currently, but Hunk output is expected to be added in due course).

Hypex wrote:@kerravon

Quote:

It can be, yes. But e.g. I have a version already that uses UEFI for x64 - is that considered to be hosted? Even when my executable is called bootx64.efi and the EFI shell is not used.

Well I suppose it could be considered hosted if it relies on UEFI for its work and not for bootstrapping.

Quote:

I was advised that D5 and above were "free":

Okay I see, because of old BCPL ABI. Well that's only relevant if you're reliant on it being compatible with OS1.3 and below. Code can easily be backwards and forwards compatible. Assembler programs relied on A0/D0 containing the CLI arguments. As did C startup code populating argv/argc. This changed with DOS ReadArgs() as it didn't use A0/D0 as a source but they were stored elsewhere. However the convention was for them to be in both places in OS2 and above. That thread has lots of discussion.

Early OS commands used the BCPL interface. But it isn't needed for any code. Although it provided a direct interface to DOS in a quirky BCPL way any code can just open dos.library and call functions the normal way. However, I did find that functions like ReadArgs() made public in OS2, were actually existent in early forms and callable in BCPL but it wasn't publicly known.

In any case, if PDOS is an OS, this shouldn't matter. Except for PDOS bootstrapping itself under AmigaOS. But, will there be a PDOS, that simply uses DOS to bootstrap and then takes over? Like Linux would do. Or, will PDOS rely on the OS as a BIOS of sorts, so run hosted and need AmigaDOS underneath?

Quote:

However, my ELF is not executing on qemu-m68k. Is there a "note segment" required for Linux?

Not that I'm aware of. But, I haven't used m68k Linux either.

Quote:

gccami is used to produce assembler. asami is used to convert that to Amiga hunk object code (no other choice I think). ldami will convert that into a hunk executable (only choice I think - maybe a.out too?). Or now, pdld will convert the Hunk object code into ELF (the only choice currently, but Hunk output is expected to be added in due course).

That's a few layers there! Hopefully you can simplify that down the line.

But, compiling was always assembling parts, generating object code, then linking them all together into a final binary. Common object files were not stored as common HUNK but as a related format. And lots of libs were an archive of object files. So a final linker generating ELF is not unreasonable.

Ok, and what about an OS (e.g. PDOS/386 and MSDOS) that relies on the IBM PC BIOS to do its work? And what about an OS (e.g. z/PDOS) that relies on intelligent hardware (ie mainframe hardware) such that there isn't a lot of work to do to create a CCW to obtain data from a device?

Regardless of your answer to that, if you think using UEFI is "cheating", then there is no issue replacing the pseudo-bios layer that PDOS-generic relies on with direct access to hardware - ie partially (and pointlessly?) duplicating UEFI. I just haven't had a reason to do that (apparently?) pointless work. It hasn't been a priority. Right now my priority is to have a mini Amiga clone so that at long last I can actually test my Amiga executables without having to ask someone else to test them for me.

Ok, I was excited about this, as I don't like having to rely on registers at startup. However, I realized (incorrectly?) that in my case it doesn't matter. I need to get the number 4 (ExecBase) from somewhere (noting that the number will no longer be 4 when run under qemu-m68k Linux or Atari or whatever, so I can't see anything to be gained by switching to using ReadArgs. Note that I'm doing something similar for Linux itself - I don't get argc and argv from the stack - at least not as a first preference. I try /proc/pid/cmdline first instead - which normally always exists. That allows PDOS/386 to run certain Linux programs without needing to construct the odd stack.

I could put the (alternative to) the number 4 on the stack, which would allow standard C code to read it, but I would still need a flag of some sort to indicate that an alternative ExecBase has been provided. So the high bit in D0 seems to be as good as anything else, and I'm stuck with needing assembler code. Or does AmigaOS already put something on the stack that I could rely on and detect? Or any other technique?

All those scenarios are possible depending on what user requirements are. However, the one that I am more likely to code personally is the one that uses AmigaDOS as a glorified BIOS. Because I may not be able to access the hard disks from PDOS otherwise, because the hard disks may require device drivers that are no longer supported and that there is no source code for. Replacing that for every bit of hardware is not really something I wish to do. Perhaps if there was a user requirement and a user willing to pay for development of that. But for me as a hobbyist - unlikely.

So you just need to read the pointer at $4 and store it as ExecBase.

At this point, since you are still working on it, is how a PDOS binary will interface with PDOS. You could provide a PDOS library that all PDOS binaries open on startup.

I'll investigate the remaining things "tomorrow". Source is in sourceforge and those two executables are available as an attachment on the other forum I mentioned previously.

No, I can't do that, because absolute address 4 may not be available for me to use on an Atari etc etc.

When run on Atari, or Linux, I am "rewriting core kernel" - there is no alternative - the Amiga doesn't exist at all.

Anyway, here is the current state:

The standard - or indeed - definition - of PDOS-generic is that it takes a pointer on the stack to a list of functions such as printf. And that has been working for something like 6-12 months (can't remember - but could look it up) and those executables are available from pdos.org but until now I had no ability to personally test them.

If there was a reason to there could be an alternate interface, but that's what I use on all environments (e.g. 80386).

Hypex wrote:@kerravon
Are you using the Amiga and Exec as an m68k base standard?

Kinda like how Mac became the PowerPC de facto standard for PowerPC? With OpenFirmware.

That's one way about it. I thought that may make it hard though. You have to take every Exec function and then DOS as it happens I expect and write an Amiga Exec wrapper to Atari, or Mac, or any other 68K platform.

Or am I misunderstanding here?

I thought arg[0] was usually the binary filename?

I'm not 100% sure I understand the question - but if I am, the answer is "yes" - I am not interested in the Atari or Mac - I'm only interested in the Amiga - but I want to be able to run my Amiga software on those other platforms (Mac, Atari, Linux) - if that's all I have access to. Furthermore - I'm mainly interested in Linux being installed on the Mac/Atari hardware, such that the only thing I need to do is make sure that my "mini Amiga clone" runs under Linux 68000, with Linux being treated as a glorified BIOS.

I'm not familiar with that and I don't understand that.

I'm not sure if you're misunderstanding because I'm not quite understanding the question. So let me just restate how things work.

That's all I need in order to get basically any C90 program (that I have source code to) to run on an Amiga (real or my mini-clone).

That's all I need in order to get basically any C90 program (that I have source code to) to run on an Amiga (real or my mini-clone).

So you can see that an Amiga C program (which would normally use fwrite()) calls Write() and then my mini-clone (it's not really an emulator I think), simply turns around and calls fwrite again.

Yes, but I don't know how to retrieve that on an Amiga, so my Amiga executables in the startup code just set it to "UNKNOWN" - only the bit after the executable is passed in d0/a0 I believe.

Hypex wrote:@kerravon
It's likely because of the stacking of ExecBase on Amiga when it always exists. And depending on that. If you are only interested in Amiga 68K it's fine but looks redundant passing it around if the PDOS lib can just grab it itself.

Quote:

That's all I need in order to get basically any C90 program (that I have source code to) to run on an Amiga (real or my mini-clone).

That isn't too much.

But you also need DOSBase. Where is that opened from? Because if you only pass ExecBase then a mini clone will need to locate DOSBase. Which usually is a call to OpenLibrary(). Not such a problem on Amiga but something else will need a mechanism when it looks for DOS.

As per previous discussion all you have is a simple string and length of the whole command line passed in A0/D0. And some other place in the CLI object. If you want a nice array of vectors pointing to each argument and your program binary you have to build it yourself.

int c_Write(void *handle, void *buf, int len)
{
int rc;
rc = fwrite(buf, 1, len, handle);
return (rc);
}