AROS Hits the Papers.

[falemagn]

I don't agree. You could split the ram in two sections using the MMU. The 68k programs would be put in one memory space and all accesses from 68k would be converted to little-endian and the accesses from x86 software to 68k modules as the 68k modules/programs would be in the "68k memory space" would simply convert the addresses.

Sorry, not possible.

Take, for instance, this case. We have a little-endian ULONG in memory, whose value is, say, 0x01020304, hence it's stored like this (values are in HEX, pipes divide bytes from one another, leftmost digit is the one at the lowest memory address):

Little endian 0x01020304:

|04|03|02|01|

Now say a 68k program wants to access that value, but for some reasons it will do it one byte at time, storing each one of those bytes in consecutive memory locations. Now, since it's doing a byte access to memory, there's presumably no need to do any byte swapping, or rather, it's simply impossible to do any byte swapping. Now, let's see what's the end result of this operation:

Big endian 0x04030201:

|04|03|02|01|

As you can see, the 68k program read the wrong value: it read 0x04030201 whilst it should have read 0x01020304.

OS4 has done that and it's the most portable solution to emulate 68k on x86 IMHO.

AOS4 (why do you people keep forgetting the 'A'?) has not done that at all, it doesn't do any byteswapping, it simply doesn't need to.

[falemagn]

Couldn't you force all emulation accesses to read longwords (rounded down to the nearest boundary) and bytewap, then use fairly simple logic to retreive the correct byte or word?

Eh... that would work in that specific case, not certainly in the general case: what if the data is NOT in litte-endian mode, but it's just text being copied from one memory location to another? You see, it doesn't work.

[falemagn]

If you have the x86 and the 68k data long-word aligned you could do it this way:

This is a requirement impossible to meet, there's no way to know the alignment of the data being accessed, since the processor doesn't know what _type_ that data is, the processor, virtual or not, just accesses some data of certain size as the program tells it, it doesn't know anything about the big picture.

|0A|0B|0C|0D| addresses-> 01,02,03,04

if I wanted to read the 2nd byte from the little endian ram zone the first thing I would do is to check what byte of the longword would it be part of...

if the byte is in the address from 01-04 it is part of the first longword, if the byte is in the address 05-08 etc...

so we read the address 02 and it's detected that it's part of the first longword, so we flip the bytes and we read 0C. If we read the third byte we read 0B, if we read the 4th, 0A. So now we have in the 680x0 memory area:
0D|0C|0B|0A

This is what Neko proposed, and I already explained why it wouldn't work.

-we have everything long-word aligned (more or less easy)

Nope, that's not easy at all, it's actually impossible.

Besides, even if everything were aligned to 4 bytes, it would simply not work anyway (again, think about text, or even about 2 WORDs being accessed as one LONG).

-edit-
I've read the other comment later...
"what if the data is NOT in litte-endian mode, but it's just text being copied from one memory location to another? You see, it doesn't work. "

mmm If I read a text in a little-endian machine, wouldn't it be stored this way?:

Original text: "THIS_IS_TEXT"

1st longword: SIHT
2nd longword: _SI_
3rd longword: TXET

Nope, not at all, it would still be stored like "THIS_IS_TEXT".

[falemagn]

That leaves me with only one idea (/doubt), using the 68k memory area as the guy who did executor (a mac emu). He used memory in the oposite order...

....TXET21

if we wanted to read the first two bytes we would only have to substract the offset of the address we want to access to the end of the memory to access to the right position.

If we wanted to access an entire word from the 3rd postition the cpu would read it correctly as the order of memory is opposite

mmm what do you think about this? The 68k emu may have to be changed...

but this should work...

To be honest, I've not understood what you're saying... any chance you could make it more clear? What do you mean with "offset of the address", for example?