YMZ280B 16-bit PCM still have swapped endianness

[akumanatt]

Currently, libvgm fetches samples in big-endian format: https://github.com/ValleyBell/libvgm/blob/8dcffa434ade3998bfbbece1478004cf437ccc80/emu/cores/ymz280b.c#L503 This was changed to be little-endian in upstream MAME over 8 years ago. This needs an investigation as Furnace is using the latest MAME core and will export samples in little-endian, causing broken noises in most VGM players.

[ValleyBell]

Ah yeah... endianess ... the topic that is a total mess in MAME.

Let's be honest - I don't know what endianess the actual chip uses, but I'm pretty sure MAME is not a good reference.

My reasons are:

• MAME often stores 16-bit ROMs as Little Endian, even for Big Endian systems. (just look at Model 2 sound ROMs)
• Their SCSP core reads 16-bit samples as Little Endian internally, even though they should be Big Endian. (see documentation of SCSP_poneSound)

Reasons for YMZ using Big Endian:

• YMF278B (OPL4) and YMF292 (SCSP) both use 16-bit Big Endian samples (for OPL4, reference is here)
• memory registers are sorted Big Endian (H/M/L)

I don't see any reason for it using Little Endian samples other than MAME's memory access optimizations.

But feel free to discuss this and convince me otherwise.

[akumanatt]

I see, but we don't have a real hardware to prove this. Maybe we can open an issue in MAME and see if people there can respond to this? I also want to know how the chip internally mixes the samples too as the current MAME core's output doesn't conform to 16-bit serial DAC output limitations.

The goal here is to find out what the real hardware actually accesses, I don't want to either break existing VGMs or make another hack around VGM export.

One more thing to note: the chip actually has an 8-bit data bus for external memory, but I still don't throw away the possibility of MAME flipping MA0 line somewhere...

[akumanatt]

Alright I'm closing this as fixing it will break bunch of existing VGMs and create more player version problems.

But anyway, here's my further investigation on this

The chip has 8-bit external memory data bus and there's an arcade system that uses 16-bit PCM, that system connects two 29F016 flash ROMs to it, which can be written by the main PPC 403GCX CPU https://github.com/mamedev/mame/blob/master/src/mame/drivers/firebeat.cpp There's no ROM dump for this, which suggests that the flash can start empty and be written by a software The hooked write function to the main memory map accepts only 8-bit of data, which means it's also 8-bit in function So this system writes 8-bit of samples at a time, so the endianness must be correctly emulated here

[ValleyBell]

Sorry that I didn't do any investigation by myself.

Just for reference: on vgmrips we do not have any YMZ VGMs with 16-bit samples. So nothing would break there. All it could break would be the existing exports from Furnace.