| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Reliable tape loader testing
From the other tape related thread, a point was raised about reliably testing a loader without needing to use a variety of tape decks.
The TapeTool utility that is included in the latest release includes the ability to add a constant or random variance to the pulse bytes in a TAP file: TapeTool 1.0.0.7
This should work on any TAP file of course. By running several passes on the same TAP file it's possible to apply cumulative variances to the tests.
I've prepared some example TAP files in this archive: https://drive.google.com/file/d/15qtoJx3e0hKtdE7sUUxBPdJ8deWfhy..
The original file "test.tap" has not been modified. The turbo portion uses a TAP file pulse byte values of $20 and $40. Note that this loader uses load time decompression of the blocks, which means the bandwidth on uncompressed data is actually faster than expected.
"tesp_p.tap" uses this to add a constant positive value of 7 to the tape file bytes:
copy /Y test.tap test_p.tap
TapeTool.exe d test_p.tap 7
"tesp_m.tap" uses this to add a constant positive value of 7 to the tape file bytes:
copy /Y test.tap test_m.tap
TapeTool.exe d test_m.tap -8
"tesp_r.tap" uses this to add a random variance of +/- 3 to the tape file bytes:
copy /Y test.tap test_r.tap
TapeTool.exe v test_r.tap 3
Note the TAP file byte length is not changed, only the pulse (edge) lengths represented by the bytes are changed.
These values are the largest reliable values I found under testing.
Random variance is the hardest for the kernal to deal with since the calibration code is more geared towards a tape deck that runs consistently faster or slower. A random variance of 3 seems to be the maximum supported without seeing a load error.
A constant -8 value, which makes the TAP file quicker to load due to much shorter pulses, also seems to be the minimum the kernal loader will cope with.
A constant 7 value, which makes the TAP file much slower to load, is the largest value my turbo seems to handle without a load error.
This is the approach I use when testing the reliability of the loader under emulation. It's substantially more reproducible that trying to us a real C2N.
Discuss :) |
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I did a small tool for testing my loaders which currently just adjusts the apparent tape speed. Was thinking about adding jitter, but at the time wasn't up to fixing a good normal distribution random function.
Ideally you'd want such a tool to more or less convert to wav, filter, and then back.
This might be feasible using already available tools like wavprg and sox.
I suspect the wav->prg direction might not be identical to how the datasette does it though. Also, the actual tape won't be modelled this way.
I guess I'll at least add jitter to my tool. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
I should mention that the VICE wobble settings can be used aswell :) Reminds me i need to add a constant offset setting too... |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Quote: I should mention that the VICE wobble settings can be used aswell :) Reminds me i need to add a constant offset setting too...
Oh wow, I've been using tape wobble 10 without even realising it. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
:) Thats infact why it was added - so people dont accidently make tape loaders that only work in the emulator. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Well now I know why I was seeing a bit more wobble than expected when the TAP file had no wobble. I put it down to bad lines and the enabled sprite. |
| |
Pex Mahoney Tufvesson
Registered: Sep 2003
Posts: 52 |
Now that I've got you tape experts' attention, bear with me a dumb question:
Would it be possible to "sync" a tape using motor on/off to get approximately the correct bytes loaded within a frame?
I mean, now I'm hearing talks about >10kB/s tape loading - and a disk based demo production today will mostly read sequential data from floppy anyhow.
So
1: would a multi part demo loader be possible by turning the tape motor off until the data is needed for the next part? Why haven't we seen this in the demoscene, yet? Or have we?
2: Could we use this motor control to adjust the tape loading speed to give us ~150 reliable bytes per frame, at a certain uninterruptible clock cycle cost, of course.
Any ideas? / Pex "Mahoney" Tufvesson |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
the motor can be turned on and off ofcourse, but the delays it introduces and the deviation between individual devices will be more than desired :) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: the motor can be turned on and off ofcourse, but the delays it introduces and the deviation between individual devices will be more than desired :)
probably, but I guess to some extent it might be (slowly) pulse width modulated, and the resulting speed could be measured |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Pex Mahoney Tufvessonnow I'm hearing talks about >10kB/s tape loading That's >10 kilobits per second, not bytes.
So...
Quoting Pex Mahoney Tufvessontape loading speed to give us ~150 reliable bytes per frame no. =) |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Maybe 15 bytes per frame at 50 Hz.
:) |
... 6 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
