| | 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) |
... 20 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next | |
