use Caps0ff dump for srdarwin

[ghost]

use Caps0ff dump for srdarwin
handcraft MCU rom for srdarwinj like was done for other games in the driver so the old sim can be killed off, marked as BAD_DUMP
seems stable, although I had to boost the interleave.

NOTE, this game has never been emulated correctly - there was the following comment

---

The table below is hopefully correct thanks to Jose Miguel Morales Farreras,
but Boss #6 is uncomfirmed as correct.

if (m_i8751_value == 0x8000) m_i8751_return = 0xf580 + 0; /* Boss #1: Snake + Bees /
if (m_i8751_value == 0x8001) m_i8751_return = 0xf580 + 30; / Boss #2: 4 Corners /
if (m_i8751_value == 0x8002) m_i8751_return = 0xf580 + 26; / Boss #3: Clock /
if (m_i8751_value == 0x8003) m_i8751_return = 0xf580 + 2; / Boss #4: Pyramid /
if (m_i8751_value == 0x8004) m_i8751_return = 0xf580 + 6; / Boss #5: Snake + Head Combo /
if (m_i8751_value == 0x8005) m_i8751_return = 0xf580 + 24; / Boss #6: LED Panels /
if (m_i8751_value == 0x8006) m_i8751_return = 0xf580 + 28; / Boss #7: Dragon /
if (m_i8751_value == 0x8007) m_i8751_return = 0xf580 + 32; / Boss #8: Teleport /
if (m_i8751_value == 0x8008) m_i8751_return = 0xf580 + 38; / Boss #9: Octopus (Pincer) /
if (m_i8751_value == 0x8009) m_i8751_return = 0xf580 + 40; / Boss #10: Bird /
if (m_i8751_value == 0x800a) m_i8751_return = 0xf580 + 42; / End Game(bad address?) */

---

The value for Boss 6 was actually incorrect, the boss is meant to have 2 states, it was starting in the 2nd, skipping the first entirely; this even caused priority errors on the boss. With the real MCU values the boss works as it should.

[cuavas]

Thanks for this. Can you just change the call to ioport to a devfind member? We're trying to minimise inefficient runtime tagmap lookups.

[cuavas]

Can you please use a required_ioport or optional_ioport state member for this? Runtime tagmap lookups really hurt performance.

[ghost]

I could, but this isn't really my code, it's based on the code that's already there. The new function is a duplicate of the old one with different port handling.

[cuavas]

Just since I noticed it, can you nuke the trailing whitespace on this line so srcclean doesn't have to?

[ghost]

again I could, but isn't this the exact reason srcclean exists? requesting I make changes that we have an automated tool to make before release just seems overly pedantic for no gain.

[cuavas]

Just since this PR made me think about it, this is another case of using perfect interleave to get MCU communication to synchronise. It's usually the easiest way to get things to work reliably, and I've definitely done it enough times myself. However the performance can sometimes be improved by using synchronize barriers at carefully selected points (e.g. see the Taito SJ implementation).

Do we want to put the effort in to find sequence points and place barriers, or do we just want to keep going with perfect interleave for 8- and 16-bit systems? The performance impact isn't crippling on modern PCs - my 7-year-old notebook seems to handle perfect interleave just fine on these kinds of games. This isn't an issue for merging this PR, I'm really just wondering out loud about what our preferred approach should be.

[ghost]

The perfect interleave thing isn't ideal, but the problem with syncronizing at various points is that it pretty much always happens one operation too late, especially on reads, you can sync on a read, but that read still happens, the code gets synced after it. Due to the way things work, simply syncing when the data is written and ready doesn't always work either because it might be the the main cpu has the timeslice and executes the code before the sub-cpu even gets time to execute and request sync on the write.

There's already one thing in this driver set to 'perfect' for similar reasons so I just followed that.

I've encountered similar problems in other drivers, where by even putting a sync on every read / write doesn't work 100% of the time due to the above.