IECHost disk restore video update

As I had changed the interleave value used to write back tracks 1-17 in a more reliable way, here’s a video update about the process 🙂

DC2N5-LC PCBs ordered

This morning I sent the PCB design for DC2N5-LC to manufacturing. Including shipping and currency conversion they ended up being about 5 GBP each, which is more than what I’d have liked to pay. I guess inflation and weakness of the Pound Sterling make manufacturing more expensive but the latter might balance out for buyers paying in Euros or USD.

Stay tuned!

DC2N5-LC displays arrived

The displays I ordered for a second batch of DC2N5-LC devices arrived today. I was able to test them all successfully in my DC2N5-LC development board: compatible with my firmware and all healthy 🙂

In the next few days I will order some extra components and send the PCBs design to manufacturing. Since the first batch I managed to correct a PCB errata, therefore the DIY experience should be painless if you know how to read a silkscreen and you have experience soldering SMD components.

Visiload T6 support in TAPClean

A further Tx variant of Visiload has been discovered and provisionally named “Visiload T6”. The variant is used in “Spindizzy 64” (part of the “Five Star” compilation), provided by Paul.

Here’s a summary of the Visiload Tx variants that are known so far:

Type 1 (threshold : $1B6 clock cycles, TAP byte $37).
Type 2 (threshold : $1E6 clock cycles, TAP byte $3D).
Type 3 (threshold : $1F8 clock cycles, TAP byte $3F).
Type 4 (threshold : $243 clock cycles, TAP byte $48).
Type 5 (threshold : $291 clock cycles, TAP byte $52).
Type 6 (threshold : $159 clock cycles, TAP byte $2B).

As you can see, T6 could be referred to as T0 instead, due to the pulse read threshold value being lower than T1’s. As types have historically started at 1, I decided to name the new variant T6 instead so that all previously known variants can also keep their name. I might change this, depending on the feedback I get.

TAPClean 0.35-pre6 supports “Visiload T6”, including the correction of infamous oversized stop bits in turbo file headers 🙂

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

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.

TAPClean 0.34 released!

Ahead of a substantial change within the Visiload scanner, I decided to release TAPClean 0.34.

Not all binaries are available for all supported platforms, but that’s something I will work at in the next few days. Linux and Mac users can either compile the “v0_34” tag by themselves or wait for me to publish binaries for them.

The change to the Visiload scanner is quite substantial because the code now scans CBM files in order to extract initial loading parameters and supports multiple titles on the same tape image even when these use different parameters, including different threshold values.
Once I am finished with this change – I mainly need to replace a lot of legacy code – the Visiload scanner will be the blueprint for a truly comprehensive scanner, due to the support of tape compilations that contain heterogeneous loaders.

As example you can mix Visiload T1 and T2 with very different initial loading parameters on the same tape image and stash some Freeload in between: TAPClean is now able to recognize each part and decode its loading parameters seamlessly.

The initial implementation of the change is available by checking out the “HEAD” or “v0.35-pre1” tag of the code.

Happy days ahead 🙂

Thinking of a new feature in DC2N5-LC

As I was thinking of DC2N5-LC I came up with this idea that I could use the filename extractor not just while dumping tapes, but also when it comes to playback TAP files. Why would I want to do that?
Simply put: no IDX file would be required for TAP files with multiple games/software on them as DC2N5-LC would be in a position to scan a file from beginning to end in order to detect the start of a CBM ROM or Turbotape 250 Header.

How cool would that be? 🙂

In fact, IMHO an IDX file is indeed useful in all cases, including multi game collections, but it is really paramount for “zero counter”+”rewind tape to 000” scenarios where the rewind point does not coincide with a CBM ROM or Turbotape 250 Header: I cannot think of a way to automate the discovery of such rewind points.
On the contrary, for tape collections the discovery is rather simple so the use of an IDX file might be advantageous (e.g. when a single title spans multiple CBM files loaded in a sequence and the single bits should not be loaded separately), but not essential.

As an extreme example, the tape version of “Turrican II” for the Commodore 64 used to be tricky to play further once you lost all lives/continues in an upper level. If memory serves me correctly, in the latter scenario you had to zero the counter where you got a “GAME OVER” and rewind the tape drive to a value in the 9 hundreds, e.g. 958. It was a true gamble to assume that people were using the standard C2N for this purpose, and even so, that they were using a particular batch with a counter that was spinning at roughly the same speed as the one used for working out these hard-coded counter values.

Makes you wonder how the hell we survived the ’80s and ’90s 😛