Handle 50, 60 and 70 Hz VBL properly

[frno7]

Dan Dare III: The Escape by David Whittaker plays too slow.

[frno7]

Thanks for the report, @grazey! Which subtunes (1, 2 and/or 3) play too slow? They seem to be rated at 50 Hz by TC50. I’ve compared PSG play with Hatari, and both seem to play them similarly. Do you have a reference for the correct playing speed?

[grazey]

It's all 3 subtunes - compare against this video. https://youtu.be/ACv3R9478fk?si=ZhzmEhuiQ7sYDUnI 2:50 in. maybe something to do with 820a checks?

[frno7]

Thanks for the video reference, @grazey! Do all SNDH subtunes play at proper speed with Hatari, using SND Player (or some other SNDH player with Hatari)?

maybe something to do with 820a checks?

Address 0xff820a bit 1 for selection of 60 or 50 Hz screen frequency? Hmm. Reading any byte in the range 0xff8200–0xff82ff returns zero (implying 60 Hz for 0xff820a), and writing is ignored, by PSG play.

[frno7]

Fixed subtune 3.

...says the top entry of the SNDH archive? So, a Dan Dare III slowness malfunction was found and fixed? :-)

[grazey]

Yes, re-ripped from the game, fixed.

[benjihan]

Address 0xff820a bit 1 for selection of 60 or 50 Hz screen frequency? Hmm. Reading any byte in the range 0xff8200–0xff82ff returns zero (implying 60 Hz for 0xff820a), and writing is ignored, by PSG play.

Some replays (Whittakers, Daglish, Some of Mine and others) used indeed 820a and 8260 to correct the music speed, assuming it was played from the VBL.
Sometimes @grazey or I have fixed the files but there are still some them in the SNDH archive.

IIRC in sc68 I handle those replays by changing what ff8260 and ff820a returns depending on the replay rate declared in the file (50/60/70). I don't use the 'TC' / '!V' flag in sc68.

Other sndh files with timing issue (non exhaustive)

Those files play at different speed between sc68 and psgplay. It does not necessary mean psgplay is in the wrong but it is for at least some of them.

• ./Doclands/Transbeauce_Demo_2_Hidden.sndh
• ./Doclands/Docklands_Sid.sndh
• ./Brooke_Jas_C/Pac_Land.sndh
• ./Sonic/Aura.sndh
• ./Daglish_Ben/Supercars.sndh
• ./Daglish_Ben/Motorhead.sndh
• ./Flogel_Jan_Mrsic/Space_Station.sndh
• ./Flogel_Jan_Mrsic/Fireblaster.sndh
• ./Skinnybone/Trex_Warrior.sndh

[frno7]

IIRC in sc68 I handle those replays by changing what ff8260 and ff820a returns depending on the replay rate declared in the file (50/60/70).

Mmm, sounds reasonable. I just made a CF300588 repo for the GST C300588-001 shifter. So far it only handles the DMA sound shifter, but I do plan to include the video shifter as well. I’m in the process of refactoring all hardware parts of PSG play into modules, in separate repos.

I don't use the 'TC' / '!V' flag in sc68.

What does that mean, I don’t understand?

Those files play at different speed between sc68 and psgplay. It does not necessary mean psgplay is in the wrong but it is for at least some of them.

Oh, thanks for comparing speeds! How did you go about it? A script of some sort?

[benjihan]

What does that mean, I don’t understand?

The !VCC tag means that the clock source is the VBL. Logically only musics played from the VBL (!V) should be affected by the VBL rate. That mean SNDH using those replay routines should either be patched or use the !V tag instead of TC. In the real world things are more messy, They were many more such files in the past. sc68 ignores the clock source because usually musics that still use this kind of timing correction do use the tag anyway.

Oh, thanks for comparing speeds! How did you go about it? A script of some sort?

Only to find files with the word $8260. Then I did listen to them "manually." A script would be nice it could be use to find many more discrepancies (=problems) between simulations, and even may be the real thing.

[frno7]

Ah. There are 174 SNDH subtunes in the test suite to try with sc68 as well. :-)

% make -j TARGET_COMPILE=m68k-elf- test-sndh
  CC      test/dmapitch.o
  CC      test/maxamp.o
  CC      test/dmasint.o
  CC      test/sndhtimera.o
  CC      test/psgpitch.o
  CC      test/sndhtimerb.o
  CC      test/sndhtimerc.o
  CC      test/sndhtimerd.o
  CC      test/sndhtimervbl.o
  CC      test/tempo.o
  LD      test/sndhtimerb.elf
  LD      test/sndhtimervbl.elf
  LD      test/psgpitch.elf
  LD      test/sndhtimerb.sndh
  LD      test/sndhtimerc.elf
  LD      test/psgpitch.sndh
  LD      test/sndhtimervbl.sndh
  LD      test/sndhtimerc.sndh
  LD      test/sndhtimera.elf
  LD      test/sndhtimerd.elf
  LD      test/sndhtimera.sndh
  LD      test/maxamp.elf
  LD      test/dmapitch.elf
  LD      test/sndhtimerd.sndh
  LD      test/dmapitch.sndh
  LD      test/maxamp.sndh
  LD      test/tempo.elf
  LD      test/tempo.sndh
  LD      test/dmasint.elf
  LD      test/dmasint.sndh

[frno7]

@benjihan, by the way, the test suite is made to plug in any other kind of SNDH player, such as sc68 (or Hatari with suitable wrapper scripts), for comparisons with PSG play performance, curiosity, or any other reason. One can basically do make TARGET_COMPILE=m68k-elf- PSGPLAY_TEST=/path/to/sc68 report-psgpitch-1 to test and report performance on the first PSG pitch subtune. As can be seen from its printout,

  CC      test/psgpitch-verify.o
  CC      test/psgpitch.o
  LD      test/psgpitch.elf
  LD      test/psgpitch.sndh
  LD      test/psgpitch-verify
  TEST    test/psgpitch-1.wave
  GEN     test/psgpitch-1.report

it will compile a verificator program, then test/psgpitch.sndh which is the SNDH file for this test, then proceed to generate test/psgpitch-1.wave with whatever program it was given via the PSGPLAY_TEST parameter, and finally generate a performance report file, and display it:

path test/psgpitch-1.wave
name psgpitch
index 1
title PSG square wave A4 pitch standard A440 440 Hz
sample count 2690100 samples
sample duration 61.0 s
sample frequency 44100 Hz
tone clock 8010613 / 4 / 16 Hz
tone period 284 cycles
wave reference frequency 440.724747 Hz
wave period 100.062454 samples
wave frequency 440.724752 Hz
wave phase 18.000000 samples
wave zero crossing count 53769
wave zero crossing deviation max 0.809664 samples
wave error total count 0.031 samples
wave error total time 6.963e-07 s
wave error absolute frequency 0.000005 Hz
wave error relative frequency 1.14e-08
wave error relative tolerance 8.18e-07

The wave error relative tolerance is the measurement limit of the given length (61 seconds, in this case, longer durations improve measurement estimates). The SNDH player should always have its wave error relative frequency below this tolerance to be acceptable:

psgplay/test/psgpitch-verify.c

Lines 43 to 61 in 1bb7276

	const char *verify(const struct audio *audio, const struct options *options)
	{
	const struct test_wave_deviation wave_deviation =
	test_wave_deviation(audio);
	const struct test_wave_error error = test_wave_error(
	audio->format, wave_deviation, tone_frequency(options));
	verify_assert (audio_duration(audio->format) >= 60.0)
	return "sample duration";
	verify_assert (wave_deviation.deviation.maximum <= 1.8)
	return "wave deviation max";
	verify_assert (error.relative_frequency <=
	audio_relative_tolerance(audio->format))
	return "wave error relative frequency";
	return NULL;
	}

The MFP for sc68 can also, in principle, be trialed with for example cf68901/test/delaymode.pcs and cf68901/test/eventmode.pcs on its logical signal level (essentially the signal pins on the MFP circuitry). These correspond to what VHDL and Verilog people often call “testbenches”, and they can run as those as well, for example if one wants to compare the MFPs of MiSTery or Zest.