08875: specpls2 and clones, cpc464 and clones, others with a cassette device: Cassette input/output signal is inverted on systems other than Commodore's

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
08875	Media Support	Critical (emulation)	Always	Jun 19, 2024, 16:53	Jul 7, 2024, 18:41

Tester	ICEknight	View Status	Public	Platform	MAME (Official Binary)
Assigned To		Resolution	Open	OS	Windows 10/11 (64-bit)
Status [?]	Direction Needed			Driver
Version	0.266	Fixed in Version		Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	08875: specpls2 and clones, cpc464 and clones, others with a cassette device: Cassette input/output signal is inverted on systems other than Commodore's
Description	When loading audio cassettes, MAME seems to always invert the polarity of the signal. This is akin to what the Commodore Datasette did and it allows for these recordings to load correctly on systems that used it, such as the C64 and Vic-20. Other computers didn't require the signal to be inverted, but MAME seems to have this inversion applied globally, thus causing systems such as the ZX Spectrum, Amstrad CPC and MSX to fail loading any games which are polarity-dependant. Likewise, tape saving in MAME is always applying this inversion which should be only done on the few systems with Datasette support. This can be seen when comparing the waveform in any short Basic program recorded from MAME and real hardware (first motion in first pilot tone is down, first motion in second pilot tone is up, with MAME's recordings doing the opposite). Once this inversion is limited to those specific Commodore computers, any recordings that work on real hardware should load properly in MAME, which is not currently the case.
Steps To Reproduce	A good test case for this is the game Whopper Chase, which had both its MSX and Commodore 64 versions recorded on the same side of the tape. Can't link to games here so ask me for a recording if needed. - Load hb201p. - Try loading the first program in Whopper Chase side B (run"cas:" [enter]). - It will fail. - Load c64p - Try loading the second program in Whopper Chase side B (load [enter]). - It will succeed. This is due to the C64 requiring the inversion, which makes it load, but since other systems also do this inversion they won't succeed in loading whenever the loader may require a certain polarity. Expectedly, if you invert the original recording the MSX version will load and the C64 version will fail.
Additional Information
Github Commit

Flags	Verified with Original
Regression Version
Affected Sets / Systems	specpls2 and clones, cpc464 and clones, others with a cassette device

Attached Files	real hardware test.jpg (197,024 bytes) Jun 19, 2024, 16:54 Uploaded by ICEknight Test Basic program (real hardware)
	real hardware pilot 1.jpg (224,471 bytes) Jun 19, 2024, 16:55 Uploaded by ICEknight Pilot 1 (real hardware)
	real hardware pilot 2.jpg (219,352 bytes) Jun 19, 2024, 16:55 Uploaded by ICEknight Pilot 2 (real hardware)
	mame test.jpg (172,994 bytes) Jun 19, 2024, 16:55 Uploaded by ICEknight Test Basic program (MAME)
	mame pilot 1.jpg (206,099 bytes) Jun 19, 2024, 16:55 Uploaded by ICEknight Pilot 1 (MAME)
	mame pilot 2.jpg (189,537 bytes) Jun 19, 2024, 16:56 Uploaded by ICEknight Pilot 2 (MAME)
	zxmartian Spectrum48K_Direct.flac (834,727 bytes) Jul 7, 2024, 18:37 Uploaded by ICEknight ZX Spectrum 48K Issue 3 save (real hardware)
	spectrum plus 2 save.flac (1,210,010 bytes) Jul 7, 2024, 18:37 Uploaded by ICEknight ZX Spectrum +2 save (real hardware)
	zxmartian Plus2B_Direct.flac (696,255 bytes) Jul 7, 2024, 18:38 Uploaded by ICEknight ZX Spectrum +2B save (real hardware)

No.22197 Haze Senior Tester Jun 23, 2024, 11:49	yeah, a few of the speccy cassette protections rely on initial polarity IIRC ( lonewlf3 for example, which is why multiple reads have been left in ) even the existing speccy emulators seem to be highly inconsistent with these cases, each wanting slightly different dumps or failing at different points otherwise
No.22203 ICEknight Tester Jul 1, 2024, 15:27	Can this be marked as "confirmed" rather than "aknowledged"? I don't know how things could be more verified than a direct comparison with real hardware.
No.22206 Tafoid Administrator Jul 1, 2024, 18:46	"ACKNOWLEDGED", per definition, is a label denoting it is "good/important/valid/legitimate". We use it here for that reason and for whatever reason it cannot be confirmed due to lack of skill or knowledge of the behaviors outlined. I've changed it to DIRECTION NEEDED so that someone of the Dev Team who has the knowledge may be able to look at this.
No.22208 holub Tester Jul 2, 2024, 00:36	Presumably this is the cure: https://github.com/mamedev/mame/compare/master...holub:mame:spec-speaker
No.22209 ICEknight Tester Jul 2, 2024, 08:39 edited on: Jul 2, 2024, 10:05	Testing on specpls2 and, for the saved signal, yes. For the audio input, polarity is still read the same and the real recordings for those problematic games don't load.
No.22210 ICEknight Tester Jul 2, 2024, 09:08 edited on: Jul 2, 2024, 13:19	I've checked MAME's regular (non-cassette) sound output before and after the changes and, unlike the saved wave, it's always correct, so turns out there's indeed something in MAME's cassette handling that's deliberately inverting how the signal is saved/loaded (even though MAME's "audio monitor" sound wave looks normal). From what I've tested on the Spectrum, Amstrad, Commodore and MSX cores, this behavior should be the exception (for Commodore's Datasette-compatible systems and apparently the Spectrum 48K Issue 2) and be left as-is by default.
No.22218 ICEknight Tester Jul 7, 2024, 18:41 edited on: Jul 7, 2024, 21:10	Uploaded my 128K +2 real hardware recording along with Zxmartian's from his 48K Issue 3 and 128K +2B. All of them follow the same non-inverted pattern. He also confirmed that the cassette decks in those three models don't do any inversion while saving either.