CRL loader

After Pawel contributed his tape backups of Vengaence, I decided to look at my notes about the CRL tape loader and attempt the implementation of a scanner for TAPClean.

Needless to say that processing the bulk of CRL turbo files is quite straighforward. The real challenge comes from two “edge” issues:

  1. as part of the initial synchronization mechanism some wide pulses are used, which often fall around the TAP value 0xFD but sometimes exceed 0xFF thus requiring a TAP v1 “long pulse” to encode: this is bad as TAPClean pretty much assumes long pulses to be silences;
  2. the last pulse of a turbo data block is almost always missing: this is bad because a data reconstruction is required, which involves some guess work.

The second point is not always terribly concerning as turbo blocks are loaded in page multiples and sometimes don’t use the whole last page, which therefore contains “padding data”: that’s very likely memory contents at the time the block was mastered to tape, which were not zeroed upfront. There might also be a pragmatic way to reconstruct the last bit of a data block, e.g. a missing pulse before silence always corresponds to bit 0 and the presence of an overstretched pulse corresponds to bit 1, but I shall go through a whole lot more tapes before I can find out whether that’s the case.

Another point is that details of CRL turbo files are not set within a corresponding header at the beginning of each turbo file, which is missing completely: they are part of a “load orchestrator” stored within the first turbo file. This is not so much an issue on its own, but it means that when multiple CRL titles are on the same tape side, e.g. Frankenstein, a strategy similar to the one I recently implemented for Visiload is required: the discovery of each title’s file chain has to occur.

After work today I wrote an initial implementation of the CRL scanner in TAPClean 0.35. It is by no means complete and it only supports one CRL title on a given tape side for the time being, but it is a good first step to get familiar with the peculiarities of the loader and the results of the mastering process, which IMHO are rather poor due to the format design and implementation.

Initial support for CRL tape loader in TAPClean by Luigi Di Fraia

Initial support for CRL tape loader in TAPClean

Thanks also go to Rob (Peepo) for dumping his CRL titles, which I had used to take my notes about the format. The two titles I used for my analysis are Dracula and Frankenstein by CRL.

This entry was posted in Retrocomputing, Technical and tagged , , , , , , , . Bookmark the permalink.

12 Responses to CRL loader

  1. pawelriversedge says:

    I’m very happy to see that you are upgrading TapClean. Actually my dump of Vengeance game is perhaps still not 100% good. Comparing Tom Cat’s EF3 software and MTap seems that second one mentioned is better. Tom Cat’s software doesn’t recognize very difficult tapes and the results of dumping are bad, especially if you are coming with CRL loader.

    Anyway. I’ve noticed that someone before me made a working .tap file of Vengeance game. It was preserved by a guy nicknamed Icon and he used… DC2N 🙂 There ar .dmp and .tap files available at

    Again it proves that DC2N is the best solution for dumping tapes!

    • luigidifraia says:

      DC2Ns are badass when it comes to 8-bit tape preservation: PET, VIC 20, Commodore 16/64, Spectrum, MSX, BBC Micro 🙂

    • Kim L says:

      Yep, like I wrote on June 18th about the EF3 dumps of Vengeance: “At the start of each CRL turbo block, there should be about five pulses of length approximately 0.002 seconds each (i.e. they are abnormally *long* pulses). In your tap files, there are in some cases _pauses_ present instead of pulses, and the length of those pauses is typically longer than the expected CRL pulses would be. Quite confusing.” And here’s my report on Lemon64 from Jun 22nd:

      • luigidifraia says:

        At the beginning of a CRL turbo file there are actually 10 pulses. The first 5 have a TAP value of approximately 0xFD and the subsequent pulses have a TAP value around 0xAD. The first 5 are pretty close to the maximum duration that can be encoded in a single TAP sample (8-bit unsigned), 0xFF. Due to tolerances, sometimes these pulses end up having too large a duration to fit in a TAP sample, hence they are encoded as long pulses (0x00 followed by 3 bytes for the duration itself – in PAL CPU clock cycles – not times 8). This fact is extremely unfortunate because long pulses are commonly thought as pauses (i.e. quiet gaps between files, if you wish) and often “beautified” into single longer pulses that make up for the whole duration. So the thing I would like to stress is that long pulses are not pauses, even if they are often identified with each other. Long pulses are pulses with a duration that is too long to fit in a single 8-bit TAP sample.

      • pawelriversedge says:

        Thanx for your report at Lemon64. Wonder if Tom Cat can update his tool 🙂

  2. Kim L says:

    Well, yes, I’ve always thought of the ‘$00 + 3 bytes’ notation in tap v1 as _silence_, but some recent discussions have made me slightly confused. It’s quite obvious and logical that C64 ROM-loader progs will load just fine e.g. in VICE if you replace all short pulses in a .tap with e.g. 0x00 0x78 0x01 0x00, all medium length pulses with e.g. 0x00 0x10 0x02 0x00 and all long pulses with e.g. 0x00 0xb0 0x02 0x00. But … none of the current tools I’m aware of would be able to take a .tap like that and recreate a waveform even vaguely resembling the waveform that the game publisher recorded onto the original audio tape. And I’m not sure if such a feature even would make any sense at all. Hmm … If we take an extreme example like the pause 0x00 0xff 0xff 0xff (17.0284 secs with PAL) … How does the signal behave during those 17 seconds? It starts off LOW, but at some point it has to go HIGH and finally dive LOW again at the very end. So is it … a) Something like ~8.5 secs LOW, then ~8.5 secs HIGH? b) Something like 17.0283 secs LOW, then 0.0001 secs HIGH? c) Something like 0.0001 secs LOW, then 17.0283 secs HIGH? … or what .. ?!? 🙂

    • luigidifraia says:

      > none of the current tools I’m aware of would be able to take a .tap like that and recreate a waveform even vaguely resembling the waveform that the game publisher recorded onto the original audio tape.

      Fair enough. I myself don’t look at 8-bit tapes from an audio perspective. Audio sampling is only very very rarely necessary in my experience (an estimated 0.6% of Commodore 64 tapes would require it) and I definitely don’t use audio for playback having created a number of TAP playback devices 🙂

      > How does the signal behave during those 17 seconds?

      I always go back to the basics when I get this sort of questions: A TAP sample (in TAP version 0 and 1) is defined as the time interval between two descending edges of a square wave (aka “pulse”). And IMHO that’s all we need to know. Yes, this can lead to the scenario for which the last pulse of a file and the first pulse of the next one cannot be acknowledged and that’s the reason that TAP sampling is reliable when files have a trailer sequence (even just one extra pulse after the last data pulse) and a lead-in one in case of silence gaps between two files.

      This is not really a problem when it comes to data pulses: in fact, the square wave for a data bit pulse could have a duty cycle different than 50% maybe because the write routines were taking a few less CPU cycles to prepare the first half-wave where the second half would take longer due to the fetching of the next bit/byte to write to tape.
      If you ever look at TAP v2 samples generated from Commodore 64 tapes (I’ve made quite a few while testing my DC2N devices), you’ll find that even for the CBM ROM Loader the duty cycle is not exactly 50% and that doesn’t matter as it’s the whole length of the pulse that is used to encode information, i.e. the time interval between two descending edges, as per TAP format design.

    • Tapex by SLC is able to create such TAP files, where every single pulse is in 0x00+3 more bytes notation. And more currently-existing tools wouldn’t have a problem with such files, e.g. WAV-PRG and Audiotap.
      Electrically, a signal cannot stay high or low for very long, so a very long pulse would be translated by an electrical device to something that starts low, then slowly goes to zero ans stays there for a while, then, shortly before the end of it, would slowly turn high then back to zero

  3. Kim L says:

    Yes, 5+5 pulses at the beginning of CRL turbo blocks is what I observed, too.

  4. Kim L says:

    > Fair enough. I myself don’t look at 8-bit tapes from an audio perspective.

    Yep, I guess it’s a bigger problem that TAPClean merges and rounds consecutive pauses like that, even if consecutive pulses each with length greater than $FF are uncommon and even if the example (replacing CBM ROM loader S/M/L pulses with pauses) I mentioned is an extreme case. I guess TAPClean would reduce a .tap like that to just a bunch of ‘$00 $ff $ff $ff’ + a shorter pause at the end.

    I tend to use audio sampling mainly for rescuing seemingly unreadable manhandled degraded homebrew compilation tapes, but I guess most people see original retail software as more important when preservation is concerned. Actually loading software by playing audio files has never interested me, though.

    And yes, technically it is true that only falling edges matter. 🙂

    • luigidifraia says:

      > Yep, I guess it’s a bigger problem that TAPClean merges and rounds consecutive pauses like that

      It is a problem, but TAPClean can be instructed to behave differently, e.g. for CRL files once I finish the cleaning support for these. A cleaned CRL file does not have to use long pulses either as these can be replaced with 0xFD.

      > I guess TAPClean would reduce a .tap like that to just a bunch of ‘$00 $ff $ff $ff’

      Probably. Even if it’s an extreme case, since you mentioned it, I’d also like to underline something here. Albeit VICE supports TAP files that consistently use long pulses (i.e. 0x00 followed by a 24-bit sample), even for data bits, the TAP format itself does not encourage such practice: 24-bit samples are meant for samples that do not fit into a single TAP byte.
      People could argue that the TAP format has been commonly extended in other ways too, to the extent that there are now a few TAP instances that do not follow a particular standard but mix and match features from Markus Brenners’ extension proposal and the original format defined by PHS.
      I would, benevolently, say that there is no standard around TAP files and this fact can haunt you if you’re trying to define what it means that your device or program “supports TAP files”.

      I would certainly encourage people to backup their tapes with a DC2N using its DMP format and keep the resulting DMP files. TAP files are still extremely good for consumption (i.e. emulation and playback on hardware) and each of them can be re-generated from the corresponding DMP file should the TAP format “interpretation” change over time. In fact, DMP files are platform agnostic, providing absolute time counts at the DC2N’s CPU frequency, usually 2MHz.

  5. Kim L says:

    Yep, capturing at an as high resolution as possible and saving the raw data is certainly the way to go.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s