[Vampire] The AMIGA Future Is NOW! AROS!

[Iggy]

As you say there is no fatwah on somebody working on it. Not even need for fork or branch, just make it a separate cpu, e.g. i386be and x86_64be.

Sounds like a winner to me, Staf.
If I had the time, I'd try to resurrect the PPC port.
But neither AROS variant was originally focused on 68K applications.

Once up and running, the real work would have to commence.

[wawrzon]

If I had the time, I'd try to resurrect the PPC port.

yet you have time to engage in flamewars on forums. sam ppc target has built last time 26.02.15. it shouldnt be that hard to "resurrect", but if you ask me, i dont care.

But neither AROS variant was originally focused on 68K applications.

Once up and running, the real work would have to commence.

majority of amiga applications i tried work with aros anyway. so what is this comment supposed to mean?

[bloodline]

there was a project that tried to implement something like Petunia on X86 Aros but failed. I cannot remember name but found it on web. I could try to find it if you are interested, cannot say much how far it got

I attempted to create a 68k emulator which could integrate into AROS (and allow 68k programs to run as first class citizens), but I ran into two problems.
 
 Firstly, the (likely little endian) endianness of the host processor mean all multibyte memory access MUST be byte swapped, this means that host applications and 68k applications cannot share any data structures. Not a massive issue, but it did mean that all Host Operating system structures needed to have big endian equivalents in memory. I solved this by creating a set of classes which could be accessed like regular 68k exec style libraries for big endian data and via method calls for host endianness access. I planed from the beginning to deal with this.
 
 The second problem which didn't occur to me until I had actual built the software was the address space issue. 68k applications only have 32bit pointers, so live within 4gig... But any modern host processor will be 64bit, this is a bigger problem, as now all 68k applications need to live in a single 4gig memory allocation and simply cannot access any host structures which my well be anywhere in a potential 16 exbibytes of memory!
 
 These two things coupled with the fact that many (older) Amiga applications expect the Amiga Chipset to be present, mean that running AROS 68K on UAE in AROS is actually a more elegant solution.
 
 You can find a link to the project here:
 
 http://www.amiga.org/forums/showthread.php?t=72059

[psxphill]

Firstly, the (likely little endian) endianness of the host processor mean all multibyte memory access MUST be byte swapped, this means that host applications and 68k applications cannot share any data structures.

This is why you would use something like the amithlon gcc compiler to make a big endian x86/x64.

I've never seen an emulator that uses byte swapping. For a 32 bit cpu then 32 bit data that is aligned would be written natively & bytes are written by xor'ing the address with 3. Aligned words are written by xor'ing the address with 2. Unaligned data is handled with shifting.

The second problem which didn't occur to me until I had actual built the software was the address space issue. 68k applications only have 32bit pointers, so live within 4gig... But any modern host processor will be 64bit

It wouldn't be the end of the world to limit an application to only working within the first 4gb of ram if it loads a 68k library.

These two things coupled with the fact that many (older) Amiga applications expect the Amiga Chipset to be present,

A lot don't. Some packers write to colour registers to show progress, some programs wait for mice button presses. They can be handled with something a lot more light weight than uae.

[bloodline]

This is why you would use something like the amithlon gcc compiler to make a big endian x86/x64.

I've never seen an emulator that uses byte swapping. For a 32 bit cpu then 32 bit data that is aligned would be written natively & bytes are written by xor'ing the address with 3. Aligned words are written by xor'ing the address with 2. Unaligned data is handled with shifting.

The problem I have is that my software has no idea what the data size of 68k application's data structures actually are. I have found examples where data was written sequentially as bytes and then read back using long words. but as long as the 68k only sees big endian data and the host processor only sees native endian data everything works a treat. I planned to handle this from the start so this part works fine.

Remember a goal of my emulator was to allow the host processor and 68k emulated processor to exist in the same environment as the 68k emulators on AOS4 and MOS do.

It wouldn't be the end of the world to limit an application to only working within the first 4gb of ram if it loads a 68k library.

Again, you miss the problem. As soon as the host operating system can allocate memory above the 4gig limit of the 68k, then the 68k applications and the native applications are unable to share data structures (a fundamental requirement in AmigaOS).

Neither AOS4 or MOS run on 64bit CPUs so they don't have to worry about this issue... AROS run on modern x86 and ARM CPUs, both of which are 64bit, so I my emulator simply cannot assume it will be running on a system with 4gig or less of RAM.

A lot don't. Some packers write to colour registers to show progress, some programs wait for mice button presses. They can be handled with something a lot more light weight than uae.

If you read my original thread, you will see that I did reserve the custom chip address space for lightweight (i.e. not timing correct) hardware emulation, to increase compatibility.

The problem is that these three issues, make UAE a far more attractive option, especially since UAE now runs far faster on a modern 64bit CPU than any Amiga ever could.

 
On topic: The Vampire CPU is a super fun idea and it is very exciting to run AROS on it! By doing this one can optimise the OS for Vampire specific features.

[wawrzon]

you can still run 68k emu within 32bit aros target platform, like i386. at least the pointers are the same size for first, solution for 64bit can be then postponed.

but it turns again in highly theoretical utopic discussion. please stick to goals within reach for the time being. which is aros-m68k on vampire or stuff like that.

currently some support for the most active developer might be appropriate:
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=10523&forum=4&post_id=104849#forumpost104849

he delivered essential sppedups last weeks which also essentially affects m68k platforms.

[wawrzon]

one can optimise the OS for Vampire specific features.

we can optimize os as a whole. since nick last commits after wider aros/vampire discussion aros is actually usable on my a4000/060 and bearable with 040.

[psxphill]

The problem I have is that my software has no idea what the data size of 68k application's data structures actually are. I have found examples where data was written sequentially as bytes and then read back using long words.

You can't ever know, which is why you need to use the same endian all of the time. You can't change the endian of the 68k legacy code, so that leaves compiling your native code to use big endian. This was the path that amithlon went for when it added support for native code. It's the only workable solution.

we can optimize os as a whole. since nick last commits after wider aros/vampire discussion aros is actually usable on my a4000/060 and bearable with 040.

Hopefully more interest in AROS 68k will continue that to the point where it's usable on even an 020. I'm not sure that 68k compilers have had much love in a long time.

[wawrzon]

Hopefully more interest in AROS 68k will continue that to the point where it's usable on even an 020. I'm not sure that 68k compilers have had much love in a long time.

probably best amiga crosscompiler in a while and aros 68k backend candidate:

http://eab.abime.net/showthread.php?p=1163255&highlight=gcc6#post1163255

(available as source, so after its been tested changes can be merged into the 6.3.x diff, it can then even be built native for 68k, as aros compilers do)

[nicholas]

There was also this attempt at a Trance style 68k emulator for x86 AROS but it was never finished.

https://github.com/moggen/emumiga/blob/master/README