Hey that's a good clue. I'll have a look at revision history, perhaps we can track this down.
To your question - I did a clean Irix install - because chd images that are in circulation have a lot of stuff I don't want - mostly old nekoware and a bunch of software I don't use. Just like that new computer feeling
, just my preference.
I was able to accelerate mame with a bunch of optimisations that make sense for Irix but perhaps not so much for 100s of other (for me irrelevant) emulated systems. My first set of patches I've posted here (from a different machine as user o2o2o2 - don't ask!), were picked up by somebody in Mamedev and to their credit they included at least a few changes.
I've also implemented a disk cache (attached the patch if it's of interest) if you want to try it out. It definitely helps in my setup.
But the first thing to know is that you are unlikely to get anywhere close to real machine speed on present CPUs. Mame is woefully inefficient, by design, as the preference is for accuracy rather than performance. It also runs all machine emulation on a single thread (some blitting and housekeeping are done on separate threads though). In the case of mips3 emulation my hunch from profiling mame is that memory emulation slows everything down rather than CPU emulation on it's own, perhaps consuming as much as 40% of host CPU.
In any event, it's really a tradeoff between emulated CPU /memory (profiler shows this eats about 75% of host CPU) and I/O (~2-%). Consequently, performance gains you can get with Mame depend on what you want to do with the machine - if it's CPU, I think emulated R4400 (indy_) are probably a better bet, and you can bump up CPU clock in indy_indigo2.cpp:
// Note - this will probably mess up with the emulated real time clock.
// If you experience this, run ntp regularly via cron to correct time.
void ip24_state::indy_4020(machine_config &config)
{
constexpr uint32_t system_clock = 50'000'000; // you can change this down to 25'000'000
ip24(config, system_clock);
R4000BE(config, m_maincpu, 4 * system_clock); // Then change this up to 8 * system_clock
m_maincpu->set_system_clock(system_clock);
m_maincpu->set_icache_size(0x4000);
m_maincpu->set_dcache_size(0x4000);
m_maincpu->set_addrmap(AS_PROGRAM, &ip24_state::ip24_map);
}
If however you care more about disk i/o, you can bump up the wd33c93 (emulated scsi controller) clock from 10'000'000 to perhaps 20'000'000. I set it up like this as I use indies for CPU intensive things and indigo2 for disk (of course your mileage may vary depending on what you are hosting this on):
#define MY_FAST_SCSI_CLOCK 20'000'000
#define MY_SLOW_SCSI_CLOCK 5'000'000
// used for all indy variants - e.g. indy_4415, indy_5015
void ip24_state::wd33c93(device_t *device)
{
device->set_clock(MY_SLOW_SCSI_CLOCK);
downcast<wd33c93b_device *>(device)->irq_cb().set(m_ioc2, FUNC(ioc2_device::scsi0_int_w));
downcast<wd33c93b_device *>(device)->drq_cb().set(m_hpc3, FUNC(hpc3_device::scsi0_drq));
}
// used for indigo2_4415
void ip22_state::wd33c93_2(device_t *device)
{
device->set_clock(MY_FAST_SCSI_CLOCK);
downcast<wd33c93b_device *>(device)->irq_cb().set(m_ioc2, FUNC(ioc2_device::scsi1_int_w));
downcast<wd33c93b_device *>(device)->drq_cb().set(m_hpc3, FUNC(hpc3_device::scsi1_drq));
}
Unfortunately CHD created for indy_* wont run on indigo2_* - at least for me. Perhaps it's a difference in roms, don't know.
Another tip, once I got network going, I ditched mame gui altogether. It's really bad with mouse emulation. Instead, I connect via ssh and Xming (from windows machines) or Xnest from linux (if connecting from Windows, ake sure you spend a few bucks for
Xming 7.7 "website release" - well worth it as it supports OpenGL and also encourages Colin to continue development!!). EGL and some demos won't work, but to me that's not important. My command line (my executable is indy_indigo2_fast.exe, rest is standard mame options):
.\indy_indigo2_fast.exe indy_5015 -nodrc -nojoy -numprocessors 6 -video none -frameskip 10 -throttle -sleep -sound none -window -networkprovider taptun -hard1 irix65_5015.chd -gio64_gfx xl24
Note the
-video none instead of usual
-video bgfx . Not a huge difference, but it helps a little. I've found
-video opengl useful when running mame on a linux host and connecting to the linux host via RDP.
Another interesting topic for acceleration is DRC (dynamic recompiler). The DRC for mips is
unfortunately messed up and has been for a good while. It crashes some halfway through the boot process on a windows host, and while it doesn't crash as readily on linux and at first seems promising, ultimately slows right down to 7-9% emulation speed and evetually crashes. It's just not stable. It's also a bit of a dark art programming-wise so few people have the knowledge / familiarity with the code to fix it.
Anyway I'll see if I can track down the printf bug this weekend.
