XMAME 0.67.2



IRIX OVERVIEWS


This was tested on an SGI Octane.
  • Dual 225 MHz R10000 CPUs
  • IRIX 6.5.20, freshly installed
  • Installed EVERYTHING, including all freeware discs.
  • NO MIPSpro front-end license.
  • Used freeware gcc 3.2.x for compile

    PROBLEM #1

    src/unix/Makefile and snprintf.o

    EXPLANATION

    makefile.unix expressly says to add the -DHAVE_SNPRINTF in this makefile.
    The Makefile already has it. So that is not the problem.
    But with snprintf.o a requirement at the top of the Makefile, gcc tries to build it. Compile fails around line 202, 209.
    Fix is to take out snprintf.o requirement and not try compiling it.

    PROBLEM #2

    src/unix/video-drivers/xinput.c

    EXPLANATION

    Comment out the __sgi specific block. It references a nonexistent "input_ui_post" function (this is apparently fixed in newer versions of xmame!).

    PROBLEM #3

    src/cpu/tms34010/tms34010.c

    EXPLANATION

    The STATE defines become "__INTADDR__", which is just a warning until you try to link! If you don't care about this CPU's emulation (affects MK games...), just #define it to a constant number.

    PROBLEM #4

    linking

    EXPLANATION

    gcc could not link without a segmentation fault until I fixed the above problems. It's possible the MIPSpro cc would do it even without a front-end license...?


    PERFORMANCE OBSERVATIONS

    The freeware xmame 0.61.1, which I presume is compiled with MIPSpro, is at least 25% faster than an aggressively (mips4 ISA) compiled gcc 3.2.x executable.

    Having alot of cache (1 MByte!) is almost irrelevant. tmnt is somewhat anomalous in that it routinely fluctuates at the 55-60fps level, compared to my K6-2's 35-40fps, however all other games I've tested are roughly on-par with the K6-2 500. Even then it seems like you need a MIPSpro license to achieve that speed, as gcc just isn't as good so far. **NOTE: In all cases with gcc the executables are aggressively compiled for each CPU.

    This again points to xmame being very much CPU core-limited.

  • Adding 256 KB L2 cache between my K6-3+ 450 and K6-2 500 does result in almost a 200% speedup in some 68000-based games, but on kinst (R4600-based) and crusnusa (TMS34010-based) there is no difference.
  • The R10000 can complete up to 4 instructions per clock, which is at least double what the K6-2/K6-3 can, realistically, as we do not compile with MMX and all that. Coupled with the more efficient ISA, the 225 MHz R10000 is conceivably able to match the raw instruction rate of a 500 MHz K6-2. However, adding megabytes of L2 cache isn't going to boost it beyond, since xmame does not appear to be cache-limited.
  • This site explains that an R5000 at 180 MHz only gets about 8-9 fps on a neogeo game. Thisis a little under a third of what we expect on the R10K due to differences in instruction rate, and at least under half what we get on the 500 MHz K6-2.

    Back to the list of fixes