Skip to content

Archive

Tag: tape

Spectacular Copy Turbo to Disk, SCT2D, a widely used tool for preserving turbotapes got another update. This time completely rewritten from scratch with support for several fastloaders and a built in head alignment.

You can find the tool at CSDB, http://csdb.dk/release/?id=147196

 
SDT2D Changelog:

v2.0. Written from scratch by SAILOR/TRIAD
* All functionality from earlier versions included.
* Fastsave I/O for 1541/1581/DolphinDos devices.
* Added support for JiffyDos.
* Built-in HeadAlign v1.1 by ENTHUSI/ONSLAUGHT. Press RESTORE during transfer
to restart and/or enter HeadAlign and RESTORE again to exit HeadAlign.
* Safe(slow) saveroutine using CHROUT for mass storage devices.
* Savespeed comparsion of a 180 blocks file (mm:ss):
IDE64 00:08
DolphinDos 00:13
SD2IEC+JiffyDos 00:18
1581 fast I/O 00:19
1541 fast I/O 00:27
SD2IEC 00:54
1581 slow 01:03
1541 slow 02:11

v1.2 by SAILOR of TRIAD
* Fastsave I/O for 1541 drives.

v1.1 by WACKEE of ARISE:
* Automatic replacing of invalid chars (,*?) before save [option].
* Accurate block size calculation.
* Proper handling of 0-byte files.
* Fixed resave on diskerror.
* Rename without space-fill.
* Tapeload with sound.
* Changed default settings.

v1.0 by SAILOR of TRIAD:
* Asks for disk change if file is larger than free blocks on disk.
* Resave option on diskerror.
* Option to rename file.
* Can use other devices than #8.
* Autotransfer mode option.
* Load error detection.

 

 

My friend Xiny6581 at the http://sidpreservation.6581.org/ asked me to take a deeper dive into a tape he had gotten for preservation.

You can read his findings on the tape at:The True Art of Data Archaeology, but we both felt there was more to find out on these tapes.

We came pretty quick to the conclusion the tapes were disk backups saved to a turbotape format. None of the current turbo transfer tools were able to identify the files, nor the format properly.

I made a tool to inspect the raw turbo-data on the tape. The files start with a standard turbo-tape header and the rest of the data is custom turbo-tape. With this information i made a tool which saved the raw data to disk.

 

After the turbo-tape header, a custom header follows with $02a1 bytes of data. The header has checksum(Yellow) and a name(Orange). The name is something you’d type in since it does not reflect the name of the disk. When restoring, the original program probably looked for “a bunch” of $02;s plus a sequence of $09,$08…$01,$00 and everything after those bytes is data.

Four consecutive files on the tape has the same name in the custom header why I came to the conclusion each disk was split into four files.

I was able to determine the size of the header by assuming the first block of data from the tape was from the lower tracks(sectors) of the disk. Therefor the bytes $01,$0a is a track/sector-link(lightblue) and the bytes $a9,$0a,$48,$a9,$00, which translates to LDA #$0A/PHA/LDA#$00, is programdata(lightgreen). This is how the data is structured on a disk.

Now i had found an offset for the disk data. I knew every $0100 bytes after the header corresponds to a sector on the disk. However, this was the easy part. I got pretty fast aware of the fact the sectors were in no logical order. After saving all data out, I had 9 backups of disks giving a total of 683*9(=6147) sectors that had to be puzzled together.

I started reconstructing the directory tracks. Track 18.0 holds the disk name and was found on all backups in the third file at position 0x11c1. It will also link to track 18.01 (hex $12,$01) which is the first block with filenames and track/sector links to the files.

One of the games was Flight Simulator II. Knowing that it is a full disk copy with the same placement of sectors(data) throughout the disk compared to the original game caught my interest. I made a tool which checksummed every block of $0100 bytes from the four files and compared it to every sector on the original disk. When there was a match, I knew which memorypositon in which file corresponded to a track/sector on the disk. After a match, the tool would not check the same sector twice.

I got out a fair amount of matches, not all though, since many sectors were empty and therefor matched multiple sectors. After running the same tool on another disk, Ultima II this time, it returned many identical matches with the first run. I knew i was on the right track(pun intended) and it looked like the layout was same for all disks.

With the result from the checksum runs on a couple of more disks I (roughly) knew the following:
File 1: Tracks 01-08
File 2: Tracks 09-16
File 3: Tracks 17-25
File 4: Tracks 26-35
The sectorlayout was not the same throughout the four files, but I could see a repetitive pattern which filled in some of the blanks after tweaking my tool a bit.

 
With the tables generated, and with the information in them, I wrote out the files to diskimages. Now I had 9 disks, with partially written data to them. I tried loading some files, but they often halted in the middle of loading since it hit an empty(zero-filled) sector telling the drive it is the last sector to load. There is no data written on those sectors either.

This is where I got ideas for another tool, and where I searched for partial matches from other releases found on CSDB. One disk was Summer Games and I knew it has a number of files which matches with the data written (and not yet written) to the diskimage.

My new tool would try to extract a file from the images I built. When it hit the track/sector links $00,$00 (i.e. empty sector) it would store the current track/sector and know which sector(and which track) was missing data. I also had pointed out the corresponding (complete) file and the tool searched/compared where identical data ended. From that offset it matched ($0100-2) of data from the four files which had not yet been written to disk.

When the data was identical, I got a visual feedback to confirm if the (next) track/sector link was within reasonable limits. I was able to verify it with the earlier information about which files held which tracks and if the sector links follows the pattern how a file gets written to disk (i.e. 01,11,02,12,03,13,04,14…).

 
With a couple more files from other games, and with my tool, I was able to reconstruct all track/sector data for all the 9 disks :).

 

However, we still don’t know which tool was used for this backup, if you have any information, please let me know.

 
 

 
A couple of pictures of my Load-IT by Mills. I assume its a late model since everything is combined into the same PCB. Other Load-IT datasettes i own have a separate PCB for the meter.

 


 


 


 

 

Spectacular Copy Turbo to Disk, SCT2D, has become a widely used tool for preserving turbo tapes. It was originally part of the “Spectacular Copy” suite by Stephan Senz. “Turbo to disk” was extracted and has undergone many improvements on the way.

Latest addon to the tool is a Fast I/O save routine for 1541-family drives.

You can find the tool at CSDB, http://csdb.dk/release/?id=144377

 
SDT2D Changelog:

v1.2 by SAILOR of TRIAD
* Fastsave I/O for 1541 drives.

v1.1 by WACKEE of ARISE:
* Automatic replacing of invalid chars (,*?) before save [option].
* Accurate block size calculation.
* Proper handling of 0-byte files.
* Fixed resave on diskerror.
* Rename without space-fill.
* Tapeload with sound.
* Changed default settings.

v1.0 by SAILOR of TRIAD:
* Asks for disk change if file is larger than free blocks on disk.
* Resave option on diskerror.
* Option to rename file.
* Can use other devices than #8.
* Autotransfer mode option.
* Load error detection.

 

 


Xiny6581 has made a speed comparsion between SCT2D v1.1 and v1.2. Make sure to read his excellent tutorial on preserving tapes at http://sidpreservation.6581.org/how-to-preserve-tapes/.