#1913 Wrong default?

[Zibri]

This is not a real bug report, I even which to convey my compliments to whoever wrote the tape emulation because I can confirm it is accurate to the cpu cycle!

Here are my thoughts about the default settings:

In the tape settings I have noticed there is a setting called:
TAP v0 GAP Speed tuning.
The default is 1.
A program I wrote with very tight timings won't work if this is not 0.
The same program works on real hardware and with the same TAP file fed through a U2+.
What's the purpose of this?

Also:
While disk wobbling is widely used in protections, AFAIK, there is no tape protection that uses it.
I would suggest to put all settings to 0 and perhaps a simple flag for enabling "defects".
The reason: a few programs I am developing work flawlessly on real hardware and U2+ or on other emulators, even ancient ones like CCS64. But not on vice if I keep the default settings.
In this cases the users might thing that the tape emulation is wrong, instead it's perfect as far as I stressed it to the cpu cycle.

Also:
The azimuth simulation is way off:
On my real datassette (which is in a very bad shape) the wrong azimuth and wobbling strongly affect the reading but not as the "alignment error" in the settings.
Changing "alignment error" causes everything to break, even things that work on a badly aligned datassette.

[gpz]

A program I wrote with very tight timings won't work if this is not 0.
The same program works on real hardware and with the same TAP file fed through a U2+.

a) you should attach that program then, preferably with source, so we can reproduce the problem.
b) testing against another emulator is kindof pointless

What's the purpose of this?

Have a look at the documentation: Zero Gap Delay "Integer specifying the delay in cycles for a zero gap length in the tap. Mostly relevant for v0 .tap files which could not properly encode gaps > 255.". You should just not use this value in newly created files, use V1 if you require longer gaps. Making it 0 makes no sense at all, just omit the gap in that case.

"Speed tuning" is "Integer specifying the number of cycles added to each gap in a v0 tap file." 0 or 1 should make no difference in any practical application here - The tape and -reading alone will produce more error. I don't know why its 1, but this worked for about 3 decades or so, so i don't see a reason to "fix" this, unless someone comes up with a proper test case that shows that it actually makes a difference.

The reason: a few programs I am developing work flawlessly on real hardware and U2+ or on other emulators, even ancient ones like CCS64. But not on vice if I keep the default settings.

Again, you should attach the programs, preferably with source, so we can reproduce the problem, should there be one (And again testing against other emulators is pointless).

The azimuth simulation is way off

Yes it is. Doing it properly would be a huge effort for very little gain (it'd require emulating the physical tape on a very low level).

[Zibri]

[gpz]

r44317 contains some updates and tweaks to the related options and their defaults, see docs for details

[Zibri]