Closed tin-nl closed 4 years ago
Thanks @tin-nl! As far as I can tell, the envelope-related changes here have no effect - you're starting from twice the value and decrementing it at twice the rate, but dividing the final result by 2 so the end result is the same. As I understand it, the correct way to implement the YM's envelope behaviour is with a 32-level volume table, so that we lose the divide-by-2 step (and non-envelope volumes would be multiplied by two instead). This would also deal with the remaining difference between the AY and YM - the YM's volume table has a steeper drop-off.
At that point, I'd be inclined to have the AY follow the same 32-level code path, and just have a 32-entry volume table where every value is repeated twice.
Yes, a correct 32 entry volume table should be the way to go (hence the „missing: proper YM volume tables (volume+envelope)“ part of the commit message). Do you happen to have one?
There are some at https://github.com/mamedev/mame/blob/master/src/devices/sound/ay8910.cpp#L637 which hopefully just need scaling to 0 - 0.33333. I think the source code to AY Emulator at https://bulba.untergrund.net/progr_e.htm has some too (which may turn out to be from the same source).
@gasman change to 32-entry volume tables done + YM volume table added - I ended up using sc68 measured volume table.
@gasman: is there any reason why the replayer starts the replay of a .psg file at offset 0x10 instead of 0x4 (https://github.com/demozoo/cowbell/blob/master/cowbell/ay_chip/psg_player.js#L10)? According to https://bulba.untergrund.net/PSGFormat.rar the data chunk starts right after the 4-byte header. The converted Enchanted Land tune misses 6 register writes due to this offset and starts with a "chirp".
@tin-nl The spec document is wrong - PSG files as seen in the wild have a 16 byte header. x128.txt in the same archive also backs this up ("these are old style PSG files, in other words there is no configuration data in the 16 byte header").
Up to now I had it in my head that the extra 12 bytes held the initial state of the AY/YM registers, but now I think about it, that may have been a mental leap on my part, based on the fact that they're almost always zero. Given that x128.txt calls it configuration data, maybe it was meant to be used for specifying AY vs YM, frequency and stereo mode all along...
@gasman ah, gotta love wrong docs :)
Example .psy file now has the correct header.
Thanks again! All merged as of d1b68a259d368a06748fabcb894a83cbdf679658 - I've also updated the other AY formats to accept the new ayMode option (except for VTX, which now selects AY or YM according to the file header) and added the rest of the options that were missing from the PSG player.
This adds support for YM characteristics (2MHz, different envelope depth+speed) to the PSG replay. This way .YM files (w/o digidrums, sid, synbuzzer) can be converted to .PSG and can be replayed properly-ish. It's proposed to use the ".PSY" extension for these files, since they won't play nice on AY emulators as .psg files.