| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Vice 3.8 r45312 tape emulation problem?
I was experimenting with writing tapes on rh and Vice when I realized that the exact same program (a small basic code of two lines) produced two different signals.
The signal produced on rh was slightly longer than the signal produced by writing the TAP generated by Vice using a U2+.
I then tried to sample the signal on the C64 using a U2+ through the "capture save" function, therefore working directly on the signal produced by the C64 and not by the Datassette.
I immediately noticed a difference.
The "pilot CBM" generated by the C64 is:
$2F, $30, $2F, $2F, $30, $2F, $30, $2F, $30, $2F, $2F, $30, $2F, $30, $2F, $30, $2F, $2F, $30, $2F, $30, $30, $2F, $2F, $30, $2F, $30, $2F, $30, $2F, $2F, $30, $2F, $30, $2F, $30, $2F, $2F, $30, $2F, $30, $30, $2F, $2F, $30, $2F, $30, $2F, $30, $2F, $2F, $30, $2F, $30, $2F, $30, $2F, $2F, $30 , $2F, $30, $30, $2F, $2F, $30, $2F, $30, $2F, $30, $2F, $2F, $30, $2F, $30, $2F, $30, $2F, $2F, $30, $2F, $30, $30, $2F, $2F, $30, $2F, $30, $2F, $30, $2F, $2F, $30, $2F, $30, $2F, $30, $2F, $2F , $30, $2F, $30, $30, $2F, $2F while the one produced by Vice is a simple sequence of $2F. I don't know if there are other differences in the signals afterwards.
On Vice I have "Tape Speed Tuning", "Wobble Frequency" and "Wobble amplitude" all at zero.
Since in all the dumps I've seen the pilot is similar to the one found on my rh, I think Vice has a problem with TAP management.
Is it just my problem/am I doing something wrong, or should I fire a bug report? |
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
What do you mean is the problem? That there is a 8 cycle jitter on the tap from a real c64? It could even be much less jitter in the case the transition time is very close to the edge between $2f and $30. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Take this basic program:
10 PRINT "PIPPO"
20 GOTO 10 create a TAP with Vice and write it on tape with U2+.
Then type the same program on real C64 and save it to tape.
The first waveform you see in the image is the TAP created by Vice and the next two are the SAVE on a real machine.
Whether you convert these last two files, or capture the save directly from the C64, the "pilot" you find in the tap file is a mix of $2F/$30, while in the TAP created by Vice it is a fixed $2F.
In my opinion this is a SYMPTOM that there is something wrong with the management of the "frequencies".
 |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
What exactly is the problem here? No idea what this screenshot is trying to illustrate for that matter *shrug* |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: What exactly is the problem here? No idea what this screenshot is trying to illustrate for that matter *shrug*
The first waveform (the one at the top) is the TAP created by vice and saved to tape using the U2+.
The subsequent ones are created directly on a real C64.
TAP created by Vice "lasts less".
The TAP and the files created on a real machine if converted into TAP have different TAP values (compared to the one created by Vice).
In the past the "pilot cbm" was created correctly (by Vice): a sequence of $2F/$30 and not with just $2F like now.
In your opinion there are no problems? Is this okay? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: The first waveform (the one at the top) is the TAP created by vice and saved to tape using the U2+.
The subsequent ones are created directly on a real C64.
TAP created by Vice "lasts less".
The TAP and the files created on a real machine if converted into TAP have different TAP values (compared to the one created by Vice).
In the past the "pilot cbm" was created correctly (by Vice): a sequence of $2F/$30 and not with just $2F like now.
In your opinion there are no problems? Is this okay?
There are many potential sources of error in this test. Only the vice .tap has gone through U2+ writing for instance.
But, jittering between $2f and $30 is to be considered normal. From what I remember, the kernal tape routines use interrupts to write bits so you are going to have a couple of cycles of jitter on every bit. The .tap format is coarse in this respect, so if every bit happens to be rounded down you will loose up to 8 cycles for every bit written. If we say 4 cycles on average, that would give a difference in length of ~1%.
EDIT: ~1% for something only consisting of $2f/$30 pulses. Shorter pulses would yield a bigger difference but it may even out. I'm leaving that as an exercise to figure out :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Like TLR said, there are many sources of error here. The sampling done by the U2, for example - who knows what it does exactly, what error margin does it have, how does it quantize the values, etc.
Another problem here is comparing the data in the form of wav files - this can easily lead to wrong conclusions - since just a tiny bit of error per sample can add up to a significant difference in time overall. You should instead compare the number of pulses, and their individual (not accumulated) length, that will give you the right ideas |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Let's try it like this.
Using Derogee's program "Tape signal frequency counter" we can measure the frequency of the "pilot cbm" directly on the C64.
I have done several tests with this software by recording waveforms directly onto tape and it has always detected the frequencies correctly.
I would like to point out that we are using TAP FILES ONLY: no datasette was used for this test.
- TAP file generated by Vice
- TAP file obtained with the U2+ "capture save" option.
Frequency detected on the TAP created on the C64:
Frequency detected on the TAP created by Vice:
Now the same TAP files tested on Vice.
Tap created with Vice:
Tap created with C64:
On the file saved using the real Datasette the the measured frequency is exactly 2578hz (I have the screenshot but I avoid posting that too. Anyone can check by simply making a save and using the Derogee program). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Not sure what you are trying to demonstrate. Of course, if you already know the tap files are different, then you will get different numbers there.
In any case, your whole reasoning is based on the assumption that what the U2 produces contains no error at all and thus can serve as the reference - that is however pure speculation. It could be a bug in U2, or VICE, or both - or both are right because the non existing tap "specs" leave quite some room for interpretation (see https://vice-emu.sourceforge.io/vice_16.html#SEC393 )
This is the test prog i have used to fix some tap issues:
https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/tap..
would be interesting to see what the U2 makes out of it. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
If i can i run the test prgs on the U2.
However, using only the Derogee program, the C64 and a Datasette you get the same value as the TAP created by U2+.
Vice generates an increased value of 40hz. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Please lets not go in circles. That test program will tell more, it is cycle exact and writes defined values (unlike the kernal saver). (Another good test would be writing a stream of the same value and then see what U2 makes out of it) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
here is a quick test - there indeed was some subtle rounding error:
hitmen.c02.at/temp/gurken.tap
is that one more like what you expect?
<s>PS: where is that test program? cant find it on csdb</s>
ok found. the value seems to be really unstable though |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
These are the results obtained with the U2+ using the "capture save" function:
https://www.flavioweb.it/DaCondividere/204060.zip
From what I see they are as they should be.
If i check your "gurken test" i can see a frequency of 2596hz which is slightly higher than the 2575/2578hz I get from my files on RH.
Maybe it's this little difference that you identify as "rounding errors". |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
I cant even make out a proper value, it changes so often and never is stable before the pilot is over. As said before, it makes more sense to compare the actual tap files... could you share yours too? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
The results of the 204060 program show that the timing is spot-on for values dividable by 8, so yes, remaining differences should be purely related to rounding errors (better: quantization errors) |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Okay.
But my initial question remains:
why do I see results with U2+ and using real hardware while Vice gives others?
Are U2+ and Real Hardware wrong? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quantization errors. You might see a different result with another C64 or with another U2 for the same reason. What VICE produces is "too perfect" in a way, the quantization errors produced by sampling the signal do not exist there. Also the .tap spec do not really tell what to do with values that are not dividable by 8, should the values be truncated (that is what VICE does) or rounded (and if so, how?)? All of it is correct, but will produce different values in the .tap.
Plus using the pilot tone and that program isn't really a well working test setup. The value is so unstable and jumps around so much, i wouldn't interpret much into it. We'd need another test signal that is much longer, so the program would display a stable value. Or a better test program to begin with :)
I'd still like to see the tap you captured for that matter, is it really all that different? Or is the difference purely in the quantization noise now? That's what i would expect at least. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quoting chatGPZI'd still like to see the tap you captured for that matter, is it really all that different? Or is the difference purely in the quantization noise now? That's what i would expect at least.
The 2 programs i've captured are waveforms saved to tape directly from the C64. No TAP file was used for those two programs.
The only TAP file is the first waveform which was created by Vice and written with the U2+ to tape.
But I can also see the difference when sampling the C64 directly with the U2+.
U2+ is similar to C64 + Datasette. Vice is the worst (farthest from what I see using only RH, i.e. C64 + Datasette). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
WTF that contradicts what you posted before? You didn't actually save that basic prog on the C64 and captured that using U2? What is #8 about then? |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
#8 concerns the fact that it has been said that "who knows what it does exactly, what error margin does it have, how does it quantize the values, etc." in #7 alluding to the fact that it was U2 that had problems writing the file on Datasette (file which then generated the first waveform of the three posted in the Audacity screenshot).
I am saying from #1 that A TAP GENERATED BY VICE appears to use different frequencies than the signal CREATED ON RH BY THE C64 which I have measured by comparing waveforms, checking the TAP data extracted with the U2 and using the Derogee program.
Okay?
Vice -> tap -> datasette (even just Vice -> tap report different frequencies than C64 -> Datasette really...)
C64 -> datasette
Different frequencies. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
#3 literally states you compared the .tap saved on VICE and that saved on C64. Please provide it.
The only thing that will allow to actually find out what the problem is - or if there even is one (after my local fix) - is the captured .tap from the C64. (And not a random one, but using the provided example, so it can be compared exactly).
Speculating and repeating how VICE is wrong does not help at all.
I am getting strong Zibri vibes by now.
PS: "the frequencies" are pretty much right now in the tap produced by my local fix, the pilot is a 2F/30 soup just like you'd expect
PPS: did you even look at the tap i posted before? the pilot is *byte identical* to yours
committed my fix, build coming up soonish here: https://github.com/VICE-Team/svn-mirror/releases |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I'm not making any speculations.
I reported a simple fact: a program for c64 analyzing a standard save provides different values between rh and Vice for the same operations performed.
This is a fact, not speculation.
So I provided three data demonstrating this difference: the waveform extracted directly from Datasette, the frequency value reported by the tool and the TAPs extracted on RH compared with the one created by Vice.
I checked the test file you posted and I saw that the situation is more similar to the one I check on rh and I reported the frequency I get by analyzing its pilot, which is close to the one I get on rh and I specified that probably this variation is caused by the "rounding problems" you mention.
As soon as I can I will try your latest fix and report the results. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
And you can't post the file you produced in #3 because Zibri still has to give it to you? I don't get it. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
You really were traumatized by Zibri, huh? =)
No, don't worry, it has nothing to do with these files.
I didn't put them because I thought they were easy to reproduce: they are simple SAVEs made on Vice and RH.
Anyway, here they are (I also add the file for Audacity with the audio extracted from the datasette using the 1530USB cable):
File saved on real hardware:
https://www.flavioweb.it/DaCondividere/C64SaveTape.tap
File saved on Vice:
https://www.flavioweb.it/DaCondividere/ViceSaveTape.tap
Audio dump from my Datasette:
https://www.flavioweb.it/DaCondividere/PhasesAudioProject.zip |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:I didn't put them because I thought they were easy to reproduce: they are simple SAVEs made on Vice and RH.
Its about the exact test cases - the file you linked doesn't even match the first post for that matter, it looks like its captured on a slightly slower setup, there are even $31 pulses in the pilot. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I just tried your fix.
I can confirm that now the TAP is much more similar to what I get on RH.
I don't know if it's perfect: however it works better than before!
Here is the file I get now:
https://www.flavioweb.it/DaCondividere/ViceSaveTape-Fix.tap
I'll try to write it on tape with the U2 and compare it with the save on RH but I think it's already better than before.
If I find "strange things" I'll write everything here. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:I'll try to write it on tape with the U2 and compare it with the save on RH
That doesn't make a lot of sense (you are only factoring in U2 writing, and whatever tape-speed related effects, making it worse). To compare, you should directly capture from C64 the same file. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I have now recreated the TAP from my C64.
Now I can confidently say that your latest fix works 100% because, now, my machine and vice are 100% aligned!
When I started doing these tests, my 64 was slow and Vice was fast.
WTF!?!?
Now I see the frequency of the pilot as it should be, i.e. 2596hz exactly like in Vice!
This is the file saved directly from my 64:
https://www.flavioweb.it/DaCondividere/C64SaveTape2.tap |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Fine, case closed :) |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
@C0 Mach schnell zu! |
