Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Herrera64 ! (Registered 2021-12-01) You are not logged in 
CSDb User Forums


Forums > C64 Coding > Reliable tape loader testing
2021-11-23 15:35
Martin Piper

Registered: Nov 2007
Posts: 459
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....
 
2021-11-24 19:41
Groepaz

Registered: Dec 2001
Posts: 10165
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 :)
2021-11-24 20:28
tlr

Registered: Sep 2003
Posts: 1538
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
2021-11-25 01:17
Krill

Registered: Apr 2002
Posts: 2173
Quoting Pex Mahoney Tufvesson
now I'm hearing talks about >10kB/s tape loading
That's >10 kilobits per second, not bytes.

So...
Quoting Pex Mahoney Tufvesson
tape loading speed to give us ~150 reliable bytes per frame
no. =)
2021-11-25 07:08
Martin Piper

Registered: Nov 2007
Posts: 459
Maybe 15 bytes per frame at 50 Hz.
:)
2021-11-25 11:41
Krill

Registered: Apr 2002
Posts: 2173
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. =)
2021-11-25 12:45
Martin Piper

Registered: Nov 2007
Posts: 459
Or read the in whatever order and just plonk them in the correct place in memory.
2021-11-25 13:23
Krill

Registered: Apr 2002
Posts: 2173
Quoting Martin Piper
Or 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.)
2021-11-25 13:27
Groepaz

Registered: Dec 2001
Posts: 10165
Loading blocks in random order from tape surely is an interesting concept :)
2021-11-26 06:12
Martin Piper

Registered: Nov 2007
Posts: 459
Quote: Quoting Martin Piper
Or 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. :)
2021-11-26 06:13
Martin Piper

Registered: Nov 2007
Posts: 459
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
CentralperK/Patagonia
jicas
csabanw
Guests online: 44
Top Demos
1 Edge of Disgrace  (9.6)
2 Coma Light 13  (9.6)
3 Bromance  (9.6)
4 Uncensored  (9.6)
5 Memento Mori  (9.5)
6 Unboxed  (9.5)
7 Lunatico  (9.5)
8 Wonderland XII  (9.5)
9 Comaland 100%  (9.5)
10 Christmas Megademo  (9.5)
Top onefile Demos
1 Copper Booze  (9.6)
2 Daah, Those Acid Pil..  (9.5)
3 Dawnfall V1.1  (9.5)
4 Cityscape 2730  (9.5)
5 Lovecats  (9.5)
6 To Norah  (9.5)
7 Elite Code Mechanics  (9.4)
8 Barry Boomer - Trapp..  (9.4)
9 Offering  (9.4)
10 For Your Sprites Only  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Performers  (9.4)
3 Oxyron  (9.3)
4 Fossil  (9.3)
5 Crest  (9.3)
Top Original Suppliers
1 hedning  (9.7)
2 Derbyshire Ram  (9.4)
3 Irata  (9.3)
4 Baracuda  (9.3)
5 Jazzcat  (8.4)

Home - Disclaimer
Copyright © No Name 2001-2021
Page generated in: 0.124 sec.