Busy day on TAPClean development

Today I’ve spent quite some time making changes and rationalisations on TAPClean’s source code. I’ve also put down a number of entries in my TODO list, which all sound quite exciting and should keep me busy for a while!

I’d like to underline that most of the following points resulted from cooperation with other enthusiasts (as per credits). Without a synergy between all parties, most of the information I was exposed to could have been unreachable or taken years to gather, so my thanks go to Ziggy72 and SLC for their efforts in that sense.

  • “Firebird” uses a very clever mechanism to avoid trying all known Tx variants: it looks for a pattern in the first CBM Header, which it then uses to extract the pulse read threshold. Once that’s done, a single variant is searched for. Can we re-use this approach for e.g. “Alternative Software (DK) Tx” since T2 and T3 can be easily confused with the default read tolerance value? A similar approach could be used for “CHR”, “Visi”, “Ocean New”, and “Snakeload 5.0”. For backward compatibility: if no Tx pattern is found then the code should cycle through all Tx variants (Luigi)
  • There is no reason for which “Ocean New” and “Snakeload 5.0” T1 and T2 should not be handled by the same module, as it happens with all other scanners; otherwise there is way too much code duplication there (Luigi)
  • The loader known as “Alternative Software variant” and used by the “Graphic Adventure Creator” should be renamed to “Imagine/Incentive tape” and the loader used by games created with it, currently referred to as “Alternative Software tape”, should be renamed to “Graphic Adv Creator tape” (Ziggy72)
  • “U.S. Gold tape” was mastered with a tool called “Pro Cass” as found out by SLC who managed to get in touch with some ex-employees: the latter also confirmed that wrong checkbytes were embedded into some tapes in order to fool crackers. TAPClean could alert on this (Ziggy72)
  • “Cult tape” should be renamed to “Freeze Machine tape” (Ziggy72)
  • “FF Tape” stands for “Freeze Frame” (SLC) which later became “Freeze Machine” (Ziggy72)
  • “CHR” titles were mastered with a tool called “Mega-Save” (Ziggy72)
    In version 1.3, (C) 1984 Choice, each supported type is referred to as:

    • CHR T1 : Mega-Speed x9 (fastest)
    • CHR T2 : Ultra-Speed x7 (medium)
    • CHR T3 : Hyper-Speed x5 (slowest)
  • Titles using the “Alternative Software” loader were mastered by “The Graphic Adventure Creator”, in fact they are all text adventures with graphics (Ziggy72)
  • Consider the unification of “Hi-Tech” and “Virgin” if they appear to be mastered by the same program with different settings (Luigi)

As you can see, preservation only starts with making digital backups of media. What comes after that is something challenging but marvellous 🙂

Posted in Retrocomputing, Technical | Tagged , , , , , , | Leave a comment

TAPClean update: more rewrites

Contrarily to what I had anticipated when I said I’d be rewriting the CHR scanner next, I went on and rewrote the “Hi-Tech” and “Virgin” ones instead. These changes are now part of what I tagged as “v0_34_pre_2”, i.e. version 0.34-pre2.

From a structure perspective these loaders are essentially the same loader with different pulse durations, hence the scanners have essentially the very same code in TAPClean, which I intend to consolidate into a single module in order to prevent code duplication.

I’ll do some more research in order to verify whether the same tape masterer/code was used with different settings. Based on differences in the CBM part and main loader, I shall decide how to handle this one.

Posted in Retrocomputing, Technical | Tagged , , , , , , | Leave a comment

TAPClean stats update

Here’s a count of scanner modules currently available in TAPClean 0.34-pre1:

  • Legacy modules: 41
  • New modules: 34
  • Rewritten modules: 8

The list of legacy modules is still apparently long, but those modules that have been virtually left unchanged since the TAPClean project was forked are just a handful.

I guess the next module that I will rewrite from scratch is CHR, which is already almost completely in line with the new code anyway 🙂

Posted in Retrocomputing, Technical | Tagged , , , , , , | Leave a comment

TAPClean update for version 0.34-pre1

I decided to completely rewrite the scanner for the Burner tape loader today. The advantage from my perspective is the use of common and robust code that is easier to read and maintain: should I change the way I do one operation therein it would be trivial to propagate the change to all other scanners that are based on the same code.

From an end-user perspective not too much changes: the pilot train length is now displayed correctly. Before the rewrite it was off by 1 (shorter).

More rewrites to come soon. Happy days 🙂

Posted in Retrocomputing, Technical | Tagged , , , , , , , | Leave a comment

TAPClean 0.33 officially released

For updated binaries you might want to head to the project landing page on SourceForge.

That said, 0.34 is under development too. I am going to rewrite a few more scanners and implement a number of rationalizations in the short term.

Tommi will be pleased to know that in 0.34 I’ve added the “-reckless” option that re-allows a quite bad behavior I had removed, consisting in the fact that users will be able to clean tape images with errors, but not by default: In short, if a user is reckless then using the “-reckless” option might feel empowering. In order not to encourage the use of this option I decided not to explicitly suggest its use when the application refuses to clean a tape image with errors: it looks like a sensible choice to me.

In the long term I’d like to change the option parser and review some of the core functionality and a few ancillary functions.

I am also keen on looking into unrecognized formats should people feel keen to point these out.

The problem I am having at the moment is that I feel the need of a a go-to service where I can find a consolidated archive of raw tape images available for research, which is also the custodian of documentation about the formats I reverse engineer.
It should be possible to add to the archive and make queries such as: “retrieve the list of titles that use Bleepload”. It should then be possible to bulk-run two specific versions of TAPClean against each of these titles and get a textual diff of the reports generated by each of them for regression testing.
It would also be good to have the ability to auto-update information of each archived title by picking information from its own report, e.g. it should be possible to update the PETSCII filename of each archived title should the data extraction process for the CBM ROM Loader change in a way that allows extraction of the filename with escaped control sequences such as {DISABLE SHIFT+C=} {WHITE}. Just an example, but should give an idea of what would be nice to have, albeit it’s not really a “must have”.

Posted in Retrocomputing, Technical | Tagged , , , , , , , | Leave a comment

A few important fixes in TAPClean

I just finished putting in a few fixes in TAPClean, now at version 0.33-pre13.

Zoë reported an issue with a “Bleepload” title she had dumped and I was able to appreciate that the issue was only presenting itself on non-Windows systems, due to a different memory management there.
The root cause of the issue was a lack of memory boundary checks in the trailer pulse read loop. As I was at it, I looked for similar issues and found that there were, in fact, similar scenarios in which memory boundary checks were either absent or wrong, which led me to fixing them in: “Bleepload”, “Bleepload Special”, “Novaload F1”, “Novaload F2”, “Ocean”, “Rasterload”, “Snakeload 5.0 T1”, “Snakeload 5.0 T2”, “Snakeload 5.1”.

Subchrist, the author of “Final TAP”, had himself appreciated the possible consequences of unchecked memory boundaries and even noted them in the module for “Rasterload”:

/* this should take care of it... */
if(eof<tap.len) /* safety precaution, this was causing a crash.. */ {   while(tap.tmem[eof+1]>ft[RASTER].lp-tol && tap.tmem[eof+1]<ft[RASTER].lp+tol)
    eof++;
}

Unfortunately even the above precaution is not quite comprehensive as it should be something like (validate the memory read address before each read):

while(eofft[RASTER].lp-tol && tap.tmem[eof+1]<ft[RASTER].lp+tol)
  eof++;

Alas, the above mentioned modules have not yet been rewritten for consistency with new and more robust code, but is something on my TODO list for this year 🙂

BTW, the above checks in newly written (and re-written) modules read as per below:

/* Trace 'eof' to end of trailer (any value, both bit 1 and bit 0 pulses) */
h = 0;
while (eof < tap.len - 1 &&
    h++ < MAXTRAILER &&     readttbit(eof + 1, lp, sp, tp) >= 0)
  eof++;

Actually, a boundary check on pos = eof + 1 is already performed within readttbit(), which also deals with the “-skewadapt” option, but I had decided to keep one check in the trailer read-in loop for clarity as it’s a lightweight operation compared to the search itself.

I will provide binaries in a few days possibly through an official 0.33 release on Sourceforge.

Stay tuned!

Posted in Retrocomputing, Technical | Tagged , , , , , , | Leave a comment

Yet another little design improvement for Last Ninja 2, level 6

Here’s another of those little design choices that has bothered me for a while. Mind you, it’s just about a few pixels we’re talking about, yet it feels like it could look even better with very little effort 🙂

Posted in Pixel Design, Retrocomputing, Technical | Tagged , , , , , , , , | Leave a comment