[Vampire] The AMIGA Future Is NOW! AROS!

[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

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