Author Topic: endian-ness...  (Read 7541 times)

Offline Barry Harris

  • dontbeabarry
  • *
  • Posts: 1785
  • Karma: +0/-65535
  • I'm Barry Harris and I like to f*** people over
endian-ness...
« on: November 22, 2011, 04:50:51 PM »
I've changed all the non-Windows specific code to use defined types rather than system, eg, INT8, UINT8, INT16, UINT16 etc.

Is there anything else that we should think about including that would make life easier for people porting FB Alpha to other platforms?

I'm currently doing a lot of work tidying drivers and fixing crashes, regressions and adding sound, and other little fixes. I'm most of the way through the Misc Pre 90s folder and already the program feels much more mature with the improved stability and functionality. I'll tackle the Misc Post 90s folder next, the misc drivers are the ones that get the least attention!

Anyway, with the work I've already done I'm interested in hearing from authors of ports to other platforms in order to hopefully continue to make their lives easier.
Account of Barry Harris; the traitor.
Send me an e-mail at barry@fbalpha.com letting me know how big of a piece of sh** I am.

Offline Barry Harris

  • dontbeabarry
  • *
  • Posts: 1785
  • Karma: +0/-65535
  • I'm Barry Harris and I like to f*** people over
Re: endian-ness...
« Reply #1 on: November 22, 2011, 04:51:50 PM »
And once I've eventually gone through all the drivers I'll go back through and improve/add savestates!  :biggrin:
Account of Barry Harris; the traitor.
Send me an e-mail at barry@fbalpha.com letting me know how big of a piece of sh** I am.

kev

  • Guest
Re: endian-ness...
« Reply #2 on: November 22, 2011, 05:59:14 PM »
Its a few versions behind but this one does have (almost) all drivers and cpu cores fixed for endian safeness, as in it will build and run on PC and 360/ps3.
http://code.google.com/p/fba360/source/browse/#svn%2Ftrunk

kev

  • Guest
Re: endian-ness...
« Reply #3 on: November 22, 2011, 05:59:43 PM »
And good work on the clean ups :)

Offline lantus

  • Expert
  • *****
  • Posts: 162
  • Karma: +32/-0
Re: endian-ness...
« Reply #4 on: November 23, 2011, 10:25:59 AM »
also take a look at my github going forward. The google code page was based on shuffle and is probably going to be shutdown at some point soon. 

thanks

Offline Barry Harris

  • dontbeabarry
  • *
  • Posts: 1785
  • Karma: +0/-65535
  • I'm Barry Harris and I like to f*** people over
Re: endian-ness...
« Reply #5 on: November 23, 2011, 03:06:19 PM »
I suppose the question is, with the cleanups done, and the castings now with UINT16, etc., are all the fixes necessary?

MAME casts in the same way and doesn't seem to need so many endian fixes - or is it doing something differently?
Account of Barry Harris; the traitor.
Send me an e-mail at barry@fbalpha.com letting me know how big of a piece of sh** I am.

Offline Barry Harris

  • dontbeabarry
  • *
  • Posts: 1785
  • Karma: +0/-65535
  • I'm Barry Harris and I like to f*** people over
Re: endian-ness...
« Reply #6 on: December 10, 2011, 04:08:03 AM »
I suppose the question is, with the cleanups done, and the castings now with UINT16, etc., are all the fixes necessary?

MAME casts in the same way and doesn't seem to need so many endian fixes - or is it doing something differently?

Anyone?
Account of Barry Harris; the traitor.
Send me an e-mail at barry@fbalpha.com letting me know how big of a piece of sh** I am.

kev

  • Guest
Re: endian-ness...
« Reply #7 on: December 11, 2011, 12:26:36 PM »
Mame has macros (at least it did have.. also this is off the top of my head so actual names will be different) along the lines of emulation_be_read_16 and emulation_le_read_16 for when an emulated game has a big or little endian CPU and needs to read memory values from the host machine.

So on a big endian cpu such as a power pc this gets defined as :
Code: [Select]
#define emulation_be_read_16(x) return ram[x];
but on an intel this would be defined as:
Code: [Select]
#define emulation_be_read_16(x) return ram[x]>>8||   ram[x]
and the other way around if it was emulation_le_read_16

(acutally thinking about it that might not be the right way around)

So looking at the xbox port (with the xbox specific parts removed we have something like this):

Code: [Select]

#ifdef LSB_FIRST  // just so this burn lib is still compilable under windows, etc
#define swapByte(i) (i)
#define swapWord(i) (i)
#define swapLong(i) (i)
#define swapLongLong(x) (x)
#else
#define swapByte(i)(i^1)  // might be needed for addresses (e.g. see some of the drivers that ^1 the address on reads)
#define swapWord(i)((((i) & 0xff) <<  8) | (((i) & 0xff00) >> 8))
#define swapLong(i) _byteswap_ulong(i) // swap intrinsics are faster on Xbox 360
#define swapLong(i) ((((i) & 0xFF000000) >> 24) | \
(((i) & 0x00FF0000) >> 8)  | \
(((i) & 0x0000FF00) << 8)  | \
(((i) & 0x000000FF) << 24) )
static inline uint64_t _byteswap_uint64(uint64_t x)
{
    union {
        uint64_t ll;
        struct {
           uint32_t l,h;
        } l;
    } r;
    r.l.l = swapLong (x);
    r.l.h = swapLong (x>>32);
    return r.ll;
}
#endif


typedef union {
#ifdef LSB_FIRST
  struct { uint8_t l,h,h2,h3; } b;
  struct { uint16_t l,h; } w;
#else
  struct { uint8_t h3,h2,h,l; } b;
  struct { uint16_t h,l; } w;
#endif
  uint32_t d;
}  PAIR;


Then we can just put all the word reads through the #defined macros (see the code for fbanext to see some examples)

Also its worth noting the union definition changes on BE vs LE platforms. That's important for the CPU cores.

« Last Edit: December 11, 2011, 02:33:20 PM by kev »

Offline Barry Harris

  • dontbeabarry
  • *
  • Posts: 1785
  • Karma: +0/-65535
  • I'm Barry Harris and I like to f*** people over
Re: endian-ness...
« Reply #8 on: December 11, 2011, 01:24:58 PM »
Thanks kev - I'll take a look at it some more when I've finished tidying drivers.
Account of Barry Harris; the traitor.
Send me an e-mail at barry@fbalpha.com letting me know how big of a piece of sh** I am.

kev

  • Guest
Re: endian-ness...
« Reply #9 on: December 11, 2011, 02:33:59 PM »
I will find some time to try and help when you get that far. At least I can run the code on the 360 to make sure the drivers work ok on big endian hardware.