Skip to content

Archive

Category: Preservation

ZoomFloppy does not come with a case so I searched around and found one which was a pretty good fit. I found the case on eBay listed as “Type Z80” with measurements of 119x90x38mm and cost me €7 including shipping. The PCB is fastened with 7mm high standoffs, you need to drill holes into the case to match the holes on the PCB. Here are some pictures of the result.

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.

 
 

I got a bunch of disks for transferring. As a routine I do an ocular inspection and make sure the disks rotate before starting the transfer. The only problem was that these disks failed on both parts.

The disks came from a storage unit that had a water leak and the disks were soaked with a mix of water and concrete dust.
 


Stains of concrete dust. Trying to rotate the disks by hand made a grinding noise. Nothing you’d put in a drive.


The disks were warped since the cushion inside the jacket had gotten wet. No wonder these disks didn’t rotate.
 
 


I needed a new disk jacket and to be able to clean up the disks before i could start reading the contents. The disk jacket I got from a donor disk. I used antimagnetic scissors to cut open the disk jackets, both the donor and the disks that I wanted to preserve. The magnetic disk can be moved slightly off-center to gain more space at the top so it won’t be damaged while cutting open the jacket.

When removing the disk, do not touch the magnetic surface. A good tip is to wash your hands with dish-washing liquid to remove grease from your fingers before starting. The disk can be slid out without needing to touch the magnetic surface. You can give the magnetic disk a push by the center hub ring or by the outer edge.

When the magnetic disk is out, use your thumb and pointer finger to hold the disk by the center hub ring and the outer edge. Alternatively put a couple of fingers through the center hub ring. Again, avoid touching the magnetic surface.

 

I had the disk under running water to rinse the dust off. With a few drops of dish-washing liquid on the fingers of my other hand, I carefully cleaned the surface. I started from the center hole and moved straight out to the outer edge.

 


Let the disk air dry. Dry wiping is likely to damage the surface. On some stains (or mold!) I used 90% isopropyl alcohol with clean cotton.

 


After the disk had dried, it was inserted into the donor jacket and I was able to get a good read of the disk.
 
 

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/.
 

 

d2d64_3

I needed a program to transfer C64 disks to .d64 images with a good overview of the process, but more importantly, it had to be fast and with minimial interaction to be used for reading disks in large batches. I ended up making a modified version of Nibread which i decided to call d2d64 so it would not be mixed up with the original Nibread. Nibread is part of the Nibtools utilities by Pete Rittwage at the C64 Preservation Project (http://c64preservation.com/).

d2d64 should not be used for preserving originals, it is only for making backups of your unprotected disks.

 
d2d64 has a new UI with a progressbar and colors to indicate status. It saves the disk as a .d64, defaults to 35 tracks, uses errorinfo if appliciable and will not reset/bump between reads. It also has an option for creating filenames based on the A/B-side of a disk. All you need to do is press Enter between the disksides.
 


I made a video on youtube that shows the process of transferring a disk. The whole video is 41 seconds, including initializing drive, turning disk and reading two disksides. Reading one diskside takes about 15-18 seconds. Hardware is a 1571 with serial cable (-s: SRQ) and a Zoomfloppy. OS is Windows 10.

 

There are two versions of d2d64 available. First one is based on nibtools (with SRQ support) for xum1541/Zoomfloppy users. This is probably the one you want. The second one is an older version based on mnib(predecessor to nibtools) and should be used with XMP/XAP1541 cables(LPT-connected drives). You can scroll down to the “Short history” part of this post for a brief explanation on the hardware differences. The older version I made between 2007-2010 when Zoomfloppy was not available. I decided to include it here in case some of you (like me) still have their XA/XM1541 systems running.
 

Download:


 

If you want to preserve your originals, visit these links below:
Kryoflux: http://www.kryoflux.com/
nibtools: http://c64preservation.com/nibtools

 

Short history
The Commodore drives communicate with serial communication through a DIN-6 plug cable between the drive and computer. For faster speeds, a parallel cable evolved allowing 8-bits to travel in parallel. The drive parallelcable was not a previous standard, but a cable soldered directly to the second VIA-chip on the drive and then connected to the C64 Userport.
 

The 15×1 drives don’t have a standard communication port and therefor you need a special cable to hook the drive to a PC. Early software even transferred files and images through the V.24/RS232-serial protocol.
 

Later on(1992-) came the X1541-cables which provided multiple options to connect your drive to the PC. The drive was connected to the PC through the LPT-parallelport which required exact timing to work. There were incompatibilities with some motherboards which were circumvented by different versions of the 1541-cable. The drive parallelcable was also available for the X1541 cables and added a “P” to the name.

Even later came OpenCBM, based on CBM4Linux, making it possible to communicate with drives under Windows NT/2K/XP with XA/XM1541 cables.

You can read everything about the X1541-cables at Joe Forsters homepage: here
 


My x1541 breakout box from the early days. This connected to the LPT-parallelport on a PC and disk transfering was done in DOS. Old PC-hardware did not work properly with all x1541-cables so i needed a device for testing combinations and different low level components.
 


XMP1541 in the making…
 

USB to the rescue
The LPT-Parallelport became more and more obsolete when the PC hardware evolved. Lots of tinkering with timings and settings was also required to get it working.
 
Till Harbaum worked on an USB adapter called xu1541 until he lost interest in 2007. Nate Lawson, with Wolfgang Moser and Spiro Trikaliotis, continued the project and developed it even further. In early 2009 the xum1541(pronounced “zoom”) was introduced, a full speed USB device with support for parallel transfers. Best known xum1541 implementation is the Zoomfloppy. Today OpenCBM also supports the xum1541.

 
Read more on the following links:
xum1541: http://www.root.org/~nate/c64/xum1541/
Zoomfloppy: http://www.go4retro.com/products/zoomfloppy/

 


 

A collection of disk covers that I have acquired during the years, also known as “Cover Art”. Use arrow keys or mouse scrollwheel to navigate though the covers and press enter or klick on the picture for a larger version.

Most of these covers are photocopies and some of them have had a rough life in the snailmail process. Addresses have been removed due to privacy reasons.

Thanks to Tech for a huge amount of covers.

 

2015-10: Added 183 covers.
2016-02: Added 3 covers by Microboy

 


 

 


 

Information on how to build a VU-Sette.

Read more about the “VU-Sette” here: http://blog.worldofjani.com/?p=1127

 

The following articles/documentation have been used as information for this project:
64er 1985/10 p.xx (http://www.64er-online.de/download/1985/index.html)
Svenska Hemdator Nytt 1990-05 p.34 (http://www.selda.se/sub/hemdatornytt/1990_05/)
C2N/1530/1531 Service Manual Preliminary 314002-002 (1984 Oct).

 

 

The VU-Meter


The VU-Meter was pulled out from a “Precision Batterychecker mini” from ebay 😉

 

 

Prototype

An azimuth tape and Winter Games original was used for inspecting the signal.

 


…and more testing.

 

 

Circuit diagram for the VU-Sette.

I made a sketch with the information i had gathered. Connection points for “green” and “purple” can be found at the bottom of this page.

Component list:
IC1: LF356
R1 : 10 KOhm
C1 : 470uF
R2 : 62 Ohm 0,5W
Q1 : 2N3904
Speaker: 8 Ohm 0,5W

You might need to adjust the values to match the make and model of your VU-Meter/speaker. The speaker and the VU-Meter are independent of eachother. Either one can be left out if wanted.

 

Potentiometer R1 is for zero-adjusting the VU-Meter. The tape read-head signal and R1 must be adjusted to match. When the signal peaks, you want the VU-Meter be at the max position. You can use an original game, or a tape recorded with correct adjustment, to find the peak. Note that not all originals have a “good” recording signal to prevent duplicating.

The initial adjustment can be a bit tricky, but when it is done, you will only need to adjust the tape read-head when loading a tape.

I can think of some cases where you want to adjust the sensitivity further; for very bad/old tapes, or that the reference tape had a signal that was “too good” and you need to bring the level down a bit.

 

 


A Veroboard was used for the first build. I also needed to know much room there is inside the datasette for the pcb and VU-Meter. This version does not have the speaker.

 

 

PCB Layout


I ordered a few PCBs to test the concept. In retrospect, I would rather use solderpads for the speaker and for the VU-Meter. The VU-Meter would probably be able to hold the weight of the PCB and wouldn’t need any further mounting. The extra potentiometer snuck into the upper left corner can probably be left out, I wasn’t sure if there was a need for extra adjustment of the VU-Meter.

 

 

 

Assembly


A 22 mm hole for the VU-Meter was drilled 6 mm inwards from the junction.

 

 

Parts for the VU-Meter. The rightmost VU-Meter is from another batterytester i found on ebay. Both work with the VU-Sette, but the leftmost is easier to fit into the datasette.

 

 


VU-Meter with everything cluttered into the bottom left corner. 🙂

 

 


Fully assembled.

 

 

 


 

Finding the signal
The read-signal is amplified and filtered four times before leaving the datasette. Therefor the signal strength will be different depending on which stage you choose to tap the signal from. VU-Sette has been successfully implemented with the PCBs and connection points below. You might need to do some testing to find out which output stage is most suitable for your equipment. YMMW.

 

Datasette with one OP.Amp (PCB: 1530, 1531, NP-136H):


1530

1531

NP-136H

 

 

Datasette with one OP.Amp (PCB: CMR-001):


CMR-001

 

 

Datasette with two OP.Amps (PCB NP-090B):


NP-090B

 

 


 

 

 

 

I was making backups of old turbo-tapes to disk and noticed that the quality was very poor on some tapes. I have a LOAD-IT datasette with a signal meter. Problem with it was, that I could turn the knob (head alignment) 45 degrees and still have same two(lousy) bars on the meter. There was a need for something more accurate when adjusting the alignment to get the best signal while reading the tapes.

 

My solution was to implement an analogue VU-Meter to show the signal strength and a possibility to listen in on the signal to determine if its data or other information(music).
 
Update 2015-04
Information on how to build a VU-Sette : http://blog.worldofjani.com/?p=1477
 

 

vu-sette1
Down right, a 22 mm hole is drilled for the (obvious) VU-Meter.

 

vu-sette2
The VU-meter itself is from a batterytester, hence the text 🙂

 


In action

 

FinalTAP Result
A quick comparison with FinalTAP on two .tap images. Left tape has been read with “VU-Sette” and right tape with LOAD-IT. I tried several reads with LOAD-IT but the result was pretty much the same. There is nothing wrong with LOAD-IT, as long as you got a good signal on the recorded media.

In my case, “VU-Sette” allowed me to adjust the head more precisely and get out a (much)better read of the tape. For you who are not familiar with FinalTAP, its a tool for examining, cleaning and restoring digitized data cassette tapes (TAP files) for the Commodore 64 computer.

 

 

 


While making backups of some disks(Commodore 5,25 disks with a Zoomfloppy) I noticed that the reading error-rate was very high. The disks are from the mid 80;s but they can survive depending on how they have been stored and what not.

I could get a big variety of errors on totally different sectors while (re-)reading a disk. I cleaned the R/W head, disks, used different transfer-programs, speeds, copied disks to another media on the native system etc. (even had some ridiculous amounts of read retries) and yet nothing helped.

Another thing that was a bit concerning was the mylar coating (recording media) took some serious beating for every read. I could see on the surface where the R/W head had passed. Some disks even lost the coating, leaving a transparent plastic behind.

 


…condition after a couple of reads, Track 18 “visible” in the middle.

 

It was obvious that these disks didn’t have unlimited reads and with the varying read results I decided to gather some data.

To make a long story short… the disks are stored as image-files ( .d64) and include a separate block for the error-information. This is where I started looking.

First I made a tool to visualize the data and then I extended it to gather sectors from different disk images(same content) and combine them to as close to a whole image as possible.
d64eic1
Read # 1. Errors: 26

 

d64eic2
Read # 2. Errors: 10

 

d64eic3
Read #3. Errors: 10

 

d64eic4
Images 1 and 3 combined. Errors: 7

 

d64eic5
Images 1, 2 and 3 combined. Errors: 1

 

Combining the data from the three images resulted in an image with (just)one bad block.

 

 


 

Download:

Limitations:
* Version v1.0 does not support 40 track disks.