Merging two worlds… with a disk drive

There’s always been a barrier between the Commodore 64 and the IBM-compatibles when it came to data transfer via disk.  Whereas the C64 would use 35 tracks with variable sectors on one side, the PC would use both sides with 40 tracks and fixed sectors.  This obviously led to one system not being able to read the disks from the other.

In a world where more and more people were having both a C64 and a PC (most of the time, the C64 at home and a PC at the office – we’re talking early 90s here), the only way to transfer data from one system to another was by using a direct port-to-port connection.  This meant of course that if  you wanted to have some texts you were working on at the office also at home on your C64, you had to bring your C64 to work as you had to connect it to the office PC.

This was obviously something no-one was going to do, so the UK based company “TIB” saw an opportunity to bring these two worlds together by means… of a disk drive.
Hang on, didn’t I just write that the disks on the C64 and the PC were incompatible?  Yes, but not on the 3.5” TIB drive called the “DD-001”.
This drive, made up of a slightly modified Citizen drive, came connected to a control unit.  This unit, consisting of an EPROM housing the driver software could be connected to your C64’s expansion port.
The initial drives came without a power supply and basically got their power via the expansion port… not a good idea as this meant peak currents of up to 1100 mA, whereas 500 mA is really the maximum for the port.   This caused intermittent failure of the drive and a strange humming noise out of the speaker…  TIB fixed this later on by providing an external power supply.

 

So, drive connected, you started up your C64 and you were greeted by a menu (if you had a disk in the drive, otherwise it would boot into the regular Basic).  Now you could copy text files from say your regular 1541 drive onto the disk in the DD-001 drive, put the 3.5” disk in your PC and load the text with Word… it worked perfectly.  Also the other way around was a breeze.  Simply save the text from your PC to the disk, put it in the DD-001 and hey presto, you could open it on your C64.  Finally, you really could exchange texts between the Commodore and PC world, without having to resort to direct interfaces between the two systems.

But was the data transfer fast?  Well, a quick test in which 202 blocks were saved/loaded made it clear that the drive was lightning fast – it did the job in under 5 seconds, something no other drive could do at that time – only the HD20 with JiffyDOS could come close.

  C64/1541 C64/1581 C64/HD20 C64/HD20 (JiffyDOS) C64/DD-001
202 Blocks (Load) 108 sec. 102 sec. 86 sec. 6 sec. 4.2 sec.
202 Blocks (Save) 188 sec. 71 sec. 73 sec. 25 sec. 5 sec.

So, it sounds all great, but were there any drawbacks?  Perhaps the biggest drawback was the fact that as the EPROM of the drive booted, it took roughly 8 Kbytes of the C64’s RAM, which caused applications such as Vizawrite to fail.  Geos didn’t even “see” the drive, so saving text from Geos to the drive was impossible.
The system also had to cope with the limitations of both the Commodore and PC world: filenames could not exceed 8 characters (a PC limitation) and you could not work with subdirectories on the disk (a C64 limitation).

On the other hand, you would really only use this drive as a means to an end, being the transfer of data between the two systems.  For all the regular save and load actions, you’re regular Commodore drive would do the job.

Pricewise, it was OK, as for roughly 150 Euro (calculated to today’s currency) you got the drive, control unit and a bunch of tools and software on disk.

Share This Post

DeliciousDiggGoogleStumbleuponRedditTechnoratiYahooBloggerMyspaceRSS

10 Responses to Merging two worlds… with a disk drive

  1. Pingback: Tweets that mention Merging two worlds… with a disk drive | A Commodore Geek's Blog -- Topsy.com

  2. Nice article. Do you know of any higher resolution pictures of the adapter board? I’d love to know what chips they chose to use. :)

  3. Robby "The C= guy"

    Hmmm… I’ll dig into the archives and see what I can pull out =)

  4. The two smaller ICs appear to be the same:

    GoldStar
    GD74LS00
    9128

    The square chip says:

    GoldStar
    GM82C765B PL
    9138 KOREA

    The EPROM reckons:

    JAPAN
    8B1 TD (struggled reading this line, may well be wrong)
    HN482764G-4

    And for good measure:
    TXC
    16.000
    32

    i haven’t opened the other TIB cartridge i have to confirm if they’re the same, but both are the earlier model with no PSU for the drive. Haven’t figured out how to open the drive housing yet. =-)

  5. Robby "The C= guy"

    Hi Jason,
    Thanks for providing this info!!
    Do you get that “humming” noise when you’re using your drive?
    Cheers,
    Robby

  6. A little bit, but i’m using a modified C128 power supply to drive the C64. i used to use one of them with a C64GS and the hum was far more pronounced.

  7. Thanks for the info TMR, LTNS.

    Is there any chance of getting a rom dump from this device?

  8. I think it would be a good move the explain the background of why the Drive 2001 is so fast compared to 1541 and even CMD HD. Connecting a drive to expansion port should always result in faster drive speed as using serial connection never can compete (see plus/4 and 1551 for instance).

    “The system also had to cope with the limitations of both the Commodore and PC world: filenames could not exceed 8 characters (a PC limitation) and you could not work with subdirectories on the disk (a C64 limitation).”

    Well, as disk drives for C64 are always computers on their own the missing subdirectories are not really a limitation of the C64 but were just not implemented into Drive 2001 (see 1581).

  9. Robby "The C= guy"

    Thanks for the additional info Steven! We’ve good a good discussion going here.
    Thanks for your contribution.

  10. >Thanks for your contribution.

    You’re welcome! :)

    —————————————–

    >We’ve good a good discussion going here.

    Yes, indeed. And there are two more points I didn’t think of yesterday:

    1. Using MFM encoding to store the data on disk (as DD-01 does) is much faster than GCR encoding like 1541 is using.

    2. I’m quite sure the DD-01 got much more RAM than a 1541, so that makes it faster, too.

Leave a Reply

Your email address will not be published. Required fields are marked *