misc/xtom3d: Implement PIU10 PCB board for Pump It Up hardware configuration

[987123879113]

PIU10 PCB images can be found here thanks to @icex2.

Combined with #12201 this allows the rest of the MK3-based Pump It Up games to be playable with working MP3 decoder audio and security chip implemented.

The PIU games are working with this PR but the games get into a tight loop decompressing PNGs and applying filters in libpng such that there is very long loading times at every load transition that loads new resources. The later games also generally don't run at 100% even when all of the sprites are are loaded due to all of the animated graphics the UI uses. In-game playing songs is ok depending on the song, but some songs that make heavy use of certain animated sprite effects can cause heavy lag spikes during the duration of the specific animation.

The pumpitup BIOS entry can be used to test all of the games that don't have a game entry yet.
./mame -w pumpitup -cdrom path/to/pump/game.cue

There's an optional dummy ROM entry to allow the CAT702 to be initialized using roms/pumpitup/cat702.bin for testing.

There are a lot of bootleg/hacked CDs out in the wild so it's hard to find the good ones. The bad ones can range from working (no lock chip cracked copies and/or versions that were rebuild as a single session instead of multisession CDs) to not working. The real CDs make use of CD-ROM XA and in the ISO9660 filesystem the directory records have XA extension data in the system use section, but the bad CDs include XA extension even in the file records and mscdex.exe is programmed to ignore anything with XA attribute mode 2 form 1 set so mscdex.exe ends up ignoring most of the files on the bad CDs.

This isn't needed for good CDs, but a 1 byte patch can be applied to the BIOS (piu10.u8 or board1_pumpitup_piu10_flash_u8 in nvram) to make mscdex.exe not ignore XA mode 2 form 1 file entries which allows even the bad CDs to work fine:
0x59dd7: 08 -> 00

I gave some sony/zn.cpp games a quick go to make sure the CAT702 change didn't break things, and also some Sys573 DDR games a check to make sure the mas3507d changes didn't break anything there either.

[987123879113]

intelfsh8_device and intelfsh16_device devices are separated in the header but intelfsh16_device devices were mixed in with the intelfsh8_device devices so I moved them into the intelfsh16_device group for consistency.

[cuavas]

Which part specifically upsets ZN1? I can see two changes here:

• Doing both input and output on the rising clock edge, while the existing class does output on the falling edge and input on the rising edge.
• Applying the initial S-box on select being asserted, rather than doing it on a falling clock edge when the bit counter is zero.

Does ZN1 depend on the S-box being reset when transferring multiple bytes without deasserting select in between, which PIU depends on the S-box not being reset in this situation?

[987123879113]

I can't tell you anything about what ZN1 games expect because I'm not working with ZN1 beyond testing to see if any changes were breaking on there.

I've written out the exact order of how the PIU works with the CAT702 device and it already breaks in the very first clock write if you work through the states using the original code's logic.

Assuming the first clock write is 0, then apply_sbox(initial_sbox) is called and it outputs the first result bit to the dataout callback which is not ok because no data has been written or applied yet. In this case, the real output bit that PIU expects to read can't be read until the start of the next loop but PIU is expecting to be able to read the output bit immediately at the end before looping again.

If you assume the first clock write should be 1 instead of 0 then there's a different problem. m_clock defaults to 1 so the first clock would be ignored, and even if it wasn't ignored it still hasn't written the data bit yet so the data bit won't be applied until the next loop, and it would also increase m_bit so apply_sbox(initial_sbox) wouldn't be applied on the first byte. So this also goes out of sync immediately here.

There's just a fundamental difference in how PIU wants to use the device (which imo is a pretty straight forward direct access usage) vs how the ZN1 is expecting to be able to use it via the PS1's SIO.

[cuavas]

Right, but will PIU tolerate something like:

void cat702_piu_device::write_select(int state)
{
	if (m_select != state)
	{
		if (!state)
		{
			m_state = 0xfc;
			m_bit = 0;
		}
		else
		{
			m_dataout_handler(1);
		}

		m_select = state;
	}
}

void cat702_piu_device::write_clock(int state)
{
	/*
	Pump It Up uses a CAT702 but accesses it directly and in a way that
	seems conflicting with how the ZN uses it through the PS1's SIO.

	This is the sequence performed with clock and data lines write and read data:
	write unkbit 0
	write unkbit 1
	write select 0
	loop for all bits that need to be transferred:
	    write clk = 0, data = x
	    write clk = x, data = 0/1
	    write clk = 1, data = x
	    read data
	write select 1

	Modifying the old code to work with PIU breaks ZN games.
	*/
	if (!state && m_clock && !m_select)
	{
		apply_sbox(initial_sbox);
	}

	if (state && !m_clock && !m_select)
	{
		// Compute the output and change the state
		if (!m_datain)
			apply_bit_sbox(m_bit);

		m_bit++;
		m_bit&=7;

		if (m_bit==0)
		{
			// Apply the initial sbox
			apply_sbox(initial_sbox);
		}

		m_dataout_handler(((m_state >> m_bit) & 1) != 0);
	}

	m_clock = state;
}

or does it depend on the S-box not being reset between consecutive byte transfers while select remains asserted?

[987123879113]

Doing something like that would just give completely different outputs. apply_sbox is completely mutating m_state based on the current value of m_state using the provided s-box so it's really just a full state mutation and can only happen at the one timing when m_bit is 0.

[cuavas]

Sorry, screwed up editing the code in the comment, and now I can’t work out what I was thinking.

One way or another, I suspect zn.cpp is depending on something wrong somewhere in the chain, even if it isn’t immediately clear what that is.