Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
110 user(s) are online (69 user(s) are browsing Forums)

Members: 0
Guests: 110

more...

Support us!

Headlines

 
  Register To Post  

(1) 2 »
developing amiga 68000 clone
Just popping in
Just popping in


See User information
Hello.

I bought an Amiga 500 around 1988, and did some development on it using SAS/C.

I was expecting people to migrate from MSDOS to the Amiga, since it was the superior machine. That didn't happen. And I wanted to know why. After all, if everyone followed the C90 standard, everything should port.

So I have spent 3 decades working on PDOS/386 (see pdos.org) and then, inspired by the number 4 (ExecBase) on the Amiga, I created PDOS-generic - which is an extremely portable operating system written in C, just dependent on a suitable BIOS. And Linux (or any other operating system) are effectively a suitable BIOS. So is UEFI. And one day I will hopefully write a layer on top of the IBM PC BIOS to make it "suitable".

Anyway, this then led to me realizing that I could support executables from other OSes if they in turn were "suitable". Meaning that they call DLLs/shared libraries rather than doing interrupts/TRAPs. So I could support OS/2 for example.

The Amiga has a similar but different mechanism, and I want to prove that it is possible and see what it looks like.

So currently I am creating a "bios layer" for Linux 68000 that I can run using qemu-m68k which will then support running (perfectly valid) Amiga executables that follow the "D7 standard", and I will support two flavors - ones that access dos.library and ones that access a new msvcrt.library (inspired by Windows msvcrt.dll and mingw).

If anyone wants to get involved, please let me know. There is a linker, pdld, which has been updated to take Amiga Hunk object as input, and produce 68000 ELF as output, but it's still in development and qemu-m68k doesn't like the output currently (because it is LSB instead of MSB). Hopefully that will be resolved in a matter of hours (author is in Slovakia).

Go to top
Re: developing amiga 68000 clone
Home away from home
Home away from home


See User information
@kerravon

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

there is also a project called VAMOS that allows you run simple programs on Windows/Linux.

as your probably already know older stuff from 80’s requires chipset emulation, so VAMOS is limited to simple commands. Even stuff from 90’s need chipset emulation as well, late 90’s you get more system friendly programs, but fewer, with often bugs do lack of MMU on many 68K systems they were developed on. unless you have source code to 68K programs your not going to get anywhere sadly.

If you want to help out, ask around for source code, and start replacing Puala routines, with AHI Routines and fix the bugs in the software.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@LiveForItQuote:
This is what the JIT compiler and stubs do on AmigaOS4.1.

Apologies - I failed to clarify some of the goals.

Yes - I'm sure there are other solutions out there. But they're likely all copyrighted. I'm creating a public domain rival to them.

Quote:

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

And this was only implied by my original. I mentioned C90-compliant programs that used the "D7 standard" as seen here:

https://sourceforge.net/p/pdos/gitcode ... tree/pdpclib/amistart.asm

That defacto, but not de jure, requires you to have the source code and to recompile with PDPCLIB.

I am not expecting or attempting to run existing software. I am attempting to bring C90-compliant software (I have a whole toolchain, editor etc that are C90-compliant) across to the Amiga in such a manner that it still runs on a lightweight clone (like a 100k ELF executable).

I can't see a reason for it to not work, but I haven't definitively proven that this new scenario works. It's not the same as running OS/2 programs where I just satisfy functions in a DLL. I need to provide some Amiga structures and functions with different ABI for (valid) Amiga programs to see. I already have Motorola syntax assembler stubs for calling Write(), for example, but I will need the reverse of that now.

Go to top
Re: developing amiga 68000 clone
Not too shy to talk
Not too shy to talk


See User information
@kerravon

I was a little confused when I read the title. I thought you were developing an Amiga hardware clone with CPU. Or at least some clone of what may be an A500. But then you talk some OS called PDOS. And how AmigaDOS/TripOS didn't take over the world. Well MSDOS sucks but unfortunately being a bootstrap for Windows made it more popular.

So PDOS generic is like a hosted PDOS. Any reason D7 was chosen? And not an address register? Amiga DOS was peculiar as the API put all addresses into data registers. I suppose D7 would continue that trend.

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?

Go to top
Re: developing amiga 68000 clone
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@HypexQuote:
So PDOS generic is like a hosted PDOS.

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.

Quote:

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


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

https://eab.abime.net/showthread.php?p ... ight=execbase#post1469898

Quote:

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

Yes, it has been updated.

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

Quote:

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

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).

Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@joergQuote:
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.

Yeah - I'm not looking for an advantage. I'm just looking to take my tools with me wherever I go. I spent an awful lot of time getting an (emulated) EBCDIC ANSI X3.64 terminal to work on a mainframe so that I could run microemacs. Spanning decades.

Quote:

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.

Go to top
Re: developing amiga 68000 clone
Just can't stay away
Just can't stay away


See User information
@kerravon
Quote:
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.
AmigaOS doesn't even use 7-bit workarounds like <ESC>[ (0x1B 0x5B) for escape sequences (IIRC it's supported for output as well, but not for key input) but the 8 bit <CSI> (0x9B) sequences instead, for example for the cursor up/down/left/right keys for input, for output moving the cursor, changing foreground and background colours, etc.

Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@kerravon
Quote:
However, my ELF is not executing on qemu-m68k.

The technical issues in pdld have now been resolved, so my ELF works, and I am now in a position (I believe) to port PDPCLIB (my C library) to Linux 68000, and when that is working, create a mini Amiga clone that satisfies my desire to be able to develop C90 applications on an Amiga. The other tools (gcc/binutils/microemacs/etc) should all theoretically be able to be built already, to comply with the "D7 standard", so that it would be a self-hosting (under Linux 68k) ecosystem.

There is still some 68k assembler to be fleshed out too, such as setjmp/longjmp, but those will be easier to get operational once I have the above infrastructure in place to test them.

Go to top
Re: developing amiga 68000 clone
Quite a regular
Quite a regular


See User information
@kerravon
A simple explanation to your question "I was expecting people to migrate from MSDOS to the Amiga, since it was the superior machine."
Diskcopy A: B: this was the reason in Spain the success of MS-DOS, when the people can to have programs and games "free" from their schools, institutes, work and friends.
In Amiga there was "pirate paying" while in MS-DOS was "pirate free" nearby.

Go to top
Re: developing amiga 68000 clone
Not too shy to talk
Not too shy to talk


See User information
@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.

Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@HypexQuote:
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.

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.

Quote:

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.

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?

Quote:

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?

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.

Quote:

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.

I can confirm that it is NOT required - the technical issues were resolved. One of the header sizes was being set to an incorrect value.

Quote:

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.

In one aspect, that IS simplified. Restricting each program to reading text or binaries files and writing text or binary files means that each program can be C90-compliant, as reading/writing files is something within the scope of C90.

Quote:

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.

Yep, proven technology now.

Go to top
Re: developing amiga 68000 clone
Not too shy to talk
Not too shy to talk


See User information
@kerravonQuote:


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?


Generally that wouldn't be considered hosted as the OS would need to interface with any firmware. Unless there was a boot loader in between. But even then that usually acts as a middle man.

Quote:
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.


I wouldn't say that's cheating. I would interpret hosted as running on a full OS and usually loaded by hand. But unless you have driver sources for all drivers you need you cannot be expected to fully take over the hardware.

Modern UEFI is similar to Amiga ROM2.0+. With mouse and GUI. But in many ways surpassed a basic early startup menu.

You can make use of WinUAE or any UAE to emulate an Amiga so you don't need a physical machine all the time.

I can see what you mean by duplicating unnecessary work. A few years back I wrote a Linux chain loader for the newer AmigaOS4 machines that use a boot loader (called AmigaBoot) for menu between firmware and AmigaOS. Now I could have written a full boot loader that also presented submenus to chose from. But I would have need to write a ton more code and handle file loading myself as well the user needing to manually add it to the firmware menu as an option. I decided to make use of the existing menu loader, adding menu entries with a dedicated boot partition, and letting the boot loader load all the files in for me. I just needed to iterate through a list of files and it gave me freedom to support other compression formats.

Quote:
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.


Ok so $4 is also known as ABSEXECBASE. It's the only consistent address in the whole Amiga OS. What I don't know iss why the OS just didn't pass it in a register and avoid using a 68000 vector. But the OS does use it on reboot. So you just need to read the pointer at $4 and store it as ExecBase.

For arguments A0/D0 can be saved as well. But keep in mind it's just a string. Address and length. The C lib would read it and split it into an array of arg vectors. I've written ASM macros in the past that did this.

You could also access it from the process CLI structure. That would avoid relying on registers. But again it's just a string that needs splitting. Unlike what I read about /proc/pid/cmdline containing null bytes. That looked like a bad idea when I read it at first. Using a null terminator as delimiter in a string.

Quote:
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?


Do you need an alternative to ExecBase? Any program can read it from $4 (or 0x4) any time it likes. An alternative implies you are replacing it and I don't think you intend to rewrite an existing core kernel. You could save it or stack but it's always the same. Good idea to cache it as $4 is in chip RAM and incurs a slight penalty.

So, AmigaOS or the AmigaDOS startup code doesn't stack anything for you. The AmigaOS ABI doesn't work that way. All OS functions take parameters in registers. In this respect it's somewhat like a RISC ABI. The 68000 provides 8 data and almost 8 address registers for use. The OS uses them. The only main exception is Intuition hooks where message data for lists is pushed to stack. And some other esoteric functions. Plus most C compilers would use stack based calling conventions.

Quote:
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.


Okay I can understand that. Well, the kernel is there to provide all that, so you might as well use it. So you have two basic ways about it. You could create a boot disk that has boot code to boot strap PDOS. That allows you to take over instantly. But also be able to use OS to read in disk blocks. From your own file system. Of course, though nice for testing, not very practical relying on floppy.

The other way is for PDOS to be a shell. It simply runs as a command on startup and can take over that way. Cover disk menus also did this. The user can exit back DOS. Or run it independently. This would make use of Amiga filesystem and could be installed to a bootable partition at will. Either way this would be hosted but making use of core OS components. It is called PDOS and in this case AmigaPDOS so obviously a DOS interface and not entire OS replacement. It can customise a console to run inside a PDOS window.

So drivers. This would be the easy bit. Device drivers for most hardware are added by the OS from the Zorro card ROMs. Plug and play so to speak. You just need to know the device driver name. There is Exec name and DOS name. Reverse name look ups from DOS name to Exec name are convoluted for some reason. Unless you need to write directly to disk blocks you don't need it. DOS is enough to read files from and SYS: is always assigned as boot volume. The only concern is 68040 and up need CPU libraries or it can crash.

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. Standard Amiga binaries could be tested that way. But, the intention is for ELF binaries, so obviously this needs to executed by a PDOS shell. In that case you have full control over how PDOS passes itself. You will need an ELF loader as well. And I imagine a pass through for standard hunk binaries if that is supported. The user may be confused if running an Amiga binary doesn't work. But same user would be aware they are running in PDOS.

Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@HypexQuote:
So you just need to read the pointer at $4 and store it as ExecBase.

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

Do you need an alternative to ExecBase? Any program can read it from $4 (or 0x4) any time it likes. An alternative implies you are replacing it and I don't think you intend to rewrite an existing core kernel.
[/quote]
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:

[kerravon@paul-pinebook xxx]$ qemu-m68k ./bios.exe pdptest.exe "abc def"

bios starting
about to execute program with entry point C080202C
welcome to pdptest
main function is at C0802200
allocating 10 bytes
in callocmem
m1 is C0CC7008
allocating 20 bytes
in callocmem
m2 is C0CC8008
stack is around C07FFE70
printing arguments
argc = 4
arg 0 is <UNKNOWN>
arg 1 is <pdptest.exe>
arg 2 is <abc>
arg 3 is <def>
Segmentation fault (core dumped)
[kerravon@paul-pinebook xxx]$

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.

So that's the Amiga emulator.

Now on to PDOS-generic for the 68000 which could run under Amigados as an example ...

Quote:

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.

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).

Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@kerravonQuote:
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.

It took the whole day but it is now working, source and executables are published already.

Go to top
Re: developing amiga 68000 clone
Not too shy to talk
Not too shy to talk


See User information
@kerravon

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


Well, no it wouldn't, because Atari uses TOS.

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


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?

Quote:
Anyway, here is the current state:


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

Quote:
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.


For a function like printf() stack makes sense. Since it can have variable arguments. And C like to stack!

Indeed, when I compiled from C to ASM by hand, even though I was rewriting it myself in ASM I did it the "proper" C way and stacked all the function parameters.

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


For x86 it makes sense since it's pretty much a stack based architecture. The base 68000 has more GPRs to play with but x86 did catch up. If your code is mainly C this makes sense. Since C likes to use stack in its ABI.

Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


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

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.

However, I'm not against having a native Atari/Mac version of my Amiga emulator. It's not a lot of work to support a new platform (in PDPCLIB), but it's not a priority.

Quote:

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

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

Quote:

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'm not sure if you're misunderstanding because I'm not quite understanding the question. So let me just restate how things work.

First - I'm only interested in a very select number of Amiga functions:

[kerravon@paul-pinebook pdpclib]$ grep -i globl amisupa.asm | grep -v _
.globl Read
.globl Write
.globl Input
.globl Output
.globl AllocMem
.globl FreeMem
.globl Open
.globl Close
.globl Seek
.globl DateStamp
.globl DeleteFile
.globl Rename
[kerravon@paul-pinebook pdpclib]$


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 e.g. I need to provide my own Write function (since I am AmigaDOS now), and here it is:

.globl _Write
_Write:
link a6, #0
movem.l d1/d2/d3, -(sp)
jsr _c_Write
lea 12(sp), sp
unlk a6
rts


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


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.

But this fwrite is on Linux (could be another platform -
could even be a real Amiga - e.g. if you wanted it to
operate on FAT32 emulated disks), and this fwrite is
simply another flavor of PDPCLIB for the 68000
(currently I have the Amiga and Linux implemented in
the PDPCLIB C library - but there is no restriction on
adding others and it's not a lot of work).

So basically fwrite for a (perfectly valid, conforming)
Amiga program turns around and calls fwrite on the
host platform - normally Linux 68000 - and normally
that itself is indeed done via CPU emulation
(qemu-m68k - not qemu-system-m68k - it would take more
work to make the latter work).

Quote:

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

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.

There may be a way of retrieving that information, but
it hasn't been priority to find out how, and then
implement that. I was more interested in proving
concepts than making the world's best product.

My interest is in create a public domain base - from
which freeware or commercial products can be based on.
And proving what is technically possible.

I may choose to flesh out a public domain and/or
a commercial derivative personally, but I'm setting
things up so that at least nominally I am only one
actor. And doing either isn't really a priority at
the moment - I'm expecting to switch back to ARM32
and work on PdAndro again now.

Go to top
Re: developing amiga 68000 clone
Not too shy to talk
Not too shy to talk


See User information
@kerravon

Quote:
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.


Okay. It was just the ExecBase pointer at $4 was particular to AmigaOS. It in fact uses 68K reset vector. But not for resetting in the usual way. Since it points to Exec library and not a reset routine. The ROM being mapped in for CPU reset.

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


What I meant was that with PowerPC machines software was made for Mac. For example a PPC Linux CD was designed to boot on a Mac. Mac was the most common PPC desktop and it used OpenFirmware. So most bootable CDs, though not auto bootable, were made to work on Mac OpenFirmware. But OpenFirmware was used on most other PPC hardware in the CHRP standard. The AmigaOne PPC boards being an exception.

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


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. It does give you the chance to implement resource tracking above that as well.

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).


For a clone it would have an ExecBase jump table with lots of empty items.

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.

Quote:
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 I can see that, thanks for the example.

Quote:
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.


The simple answer is you can't because it doesn't exist.

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. I didn't know this was a standard thing for other OS. I just know AmigaDOS doesn't do that. And with ReadArgs() in OS2+ no one really needs iterate through any argv vectors unless they really want too.

A standard C lib does it so no one really thinks about it unless they are doing their own startup code.

Go to top
Re: developing amiga 68000 clone
Just popping in
Just popping in


See User information
@HypexQuote:
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.

By "passing it around" you mean - my mini-clone passes it to any executable it runs?

Yes, it already exists on the Amiga - but I don't want it in this case - otherwise my apps will invoke real AmigaDOS, not my mini-clone. And if you want that to happen, there's no point running my mini-clone at all.

I repeat though - there is limited (but not zero) use for running an Amiga clone on an Amiga itself.

Quote:

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.

That is an entire toolchain (gcc etc) - not just for the Amiga, but also targeting other environments. gcc 3.2.3 itself is 400,000 lines of C code. I consider that to be "much".

But yes - there is a limited audience who would be satisfied with just C90 applications. But note that what I am doing is trying to create a public domain "base"/fallback. The public has the tools required to fight their way out of their predicament without having to resort to writing machine code.

And yes - I acknowledge that there are other solutions - almost all copyrighted.

Quote:

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.

The Amiga C90-compliant programs that I am trying to run (all using PDPCLIB as the C library), have this code (from pdpclib/start.c):

library = (struct Library *)SysBase->LibList.lh_Head;
while (library != NULL)
{
if (strcmp(library->lib_Node.ln_Name, "dos.library") == 0)
{
DOSBase = library;
break;
}
library = (struct Library *)library->lib_Node.ln_Succ;
}


My mini-clone prepares that environment with this (from generic/amiextra.asm):

.globl _SysBase
_SysBase:
ds.b 378

dc.l _newdosbase



.globl _newdosbase
_newdosbase:
dc.l 0
nop
nop
nop
dc.l libname

libname: .ascii "dos.library"



It's that simple.

Which is why my executable is only 51k. Even when I add support for the missing functions ... this is all I have now ...

[kerravon@paul-pinebook generic]$ grep globl amiextra.asm
.globl _callami2
.globl _Output
.globl _Input
.globl _Write
.globl _AllocMem


but I will need ...

[kerravon@paul-pinebook pdpclib]$ grep globl amisupa.asm | grep -v _
.globl Read
.globl Write
.globl Input
.globl Output
.globl AllocMem
.globl FreeMem
.globl Open
.globl Close
.globl Seek
.globl DateStamp
.globl DeleteFile
.globl Rename
[kerravon@paul-pinebook pdpclib]$


it will probably only be an extra 1k in size.


Quote:

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.

Building the array isn't an issue - I already do that with the data in d0. But I need the program name - not included in d0 (as far as I can see) - if I am to put it in argv[0]. So there may be an Exec/Dos call to get that, but I haven't tried to find it, because it hasn't been priority to do that bit of work.

BTW - I actually changed my priorities - I still haven't gotten back to the ARM32 work, and also I've taken an interest in the Atari after all (one thing led to another and I got interested). I never know where I will be the next day!

Go to top
Re: developing amiga 68000 clone
Just can't stay away
Just can't stay away


See User information
@kerravon
Quote:
int c_Write(void *handle, void *buf, int len)
{
int rc;
rc = fwrite(buf, 1, len, handle);
return (rc);
}
That's wrong and wont work in all cases.
dos.library Write() is an unbuffered I/O function, while C library fwrite() is buffered.
If you want to use C fwrite() for dos Write() you'd have to use
int c_Write(void *handlevoid *bufint len)
{
int rc;
rc fwrite(buf1lenhandle);
fflush(handle);
return 
rc;
}
instead.

Additionally dos.library file handles can't be the same as a C library FILE handle, it's a different abstraction layer.
dos.library BPTR file pointers are more similar to the POSIX int filedes.

Go to top

  Register To Post
(1) 2 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project