| |
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 :) |
|
... 6 posts hidden. Click here to view all posts....
|
| |
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.
:) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
As for the supposed actual question between the lines... :)
150 bytes per video frame is 7.5 KB/s, and that's around the raw sustained throughput modern IRQ loaders typically make with nothing else than loading going on.
In other words, getting 150 bytes per video frame from disk in a timely and reliable fashion while playing music and running effects is quite a feat with disk already.
Could be possible, though, but may require a special loader with custom disk format/file layout (d64 compatible, of course) specifically crafted for audio sample streaming.
This could mean things like buffering ahead a track's worth of data while loading the blocks out of order, then reassembling block order on the C-64 side during replay only, reducing block size a little (losing capacity) to just barely load any track in 3 revolutions, and - maybe most challenging - inventing a serial transfer routine that would be interleaved with sample replay and badline DMA (to reduce context-switching overhead while getting data from the drive as soon as possible).
Quite a challenge. =) |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Or read the in whatever order and just plonk them in the correct place in memory. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Martin PiperOr read the in whatever order and just plonk them in the correct place in memory. Sure, but determining the correct place is the difficult bit. Not so difficult if you have a fixed block order in a custom file system, and with reading a track ahead it may be as simple as interleave 1. All blocks of a track go to memory in strictly ascending, linear order: block index in memory equals sector number on track. :) (Still, that's one of the easier problems to solve.) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Loading blocks in random order from tape surely is an interesting concept :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Quote: Quoting Martin PiperOr read the in whatever order and just plonk them in the correct place in memory. Sure, but determining the correct place is the difficult bit. Not so difficult if you have a fixed block order in a custom file system, and with reading a track ahead it may be as simple as interleave 1. All blocks of a track go to memory in strictly ascending, linear order: block index in memory equals sector number on track. :) (Still, that's one of the easier problems to solve.)
Or use two bytes in each block for the destination memory address. :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Quote: Loading blocks in random order from tape surely is an interesting concept :)
Yeah, it's "free" because each block has its own checksum and load address baked in. |
| Previous - 1 | 2 - Next |
