1541IDE

Build an IDE-harddisk inside your 1541!


DISCLAIMER

  • All names with a copyright are acknowledged.
  • If the reader uses information from this document to write software or build hardware, then it is on his own account. I cannot be held responsible for blowing up your computer, mother-in-law or whatever; it will always be your own fault.
  • I'm not a sexist, with 'he' and 'him' I also mean 'she' and 'her'.


Copyrights

  • You may copy every bit on this page, including the source code, for NON-commercial use. I hope you enjoy it. If you use it, just give me at least some credit like "Stolen from Ruud" :-)


What is it - the original idea
The IDE-harddisk has 16 datalines and 7 controllines. Get rid of the floppy disk of your 1541 and you'll end up with two free 6522 ports. Add the unused A-port of the other 6522 and there you'll have the needed 23 lines.

The big advantage of the above proposal is that there is relatively less soldering to do then when building a real IDE-interface. But you still need to replace the Kernal and power supply.
The disadvantage is that, because you control the IDE-HD by software, your data-throughput is lower then with a real IDE-interface. FYI, with this data throughput I mean the dataflow from the onboard 6502 to the IDE-HD or vica versa, not the one from/to the C64 or other IEC-computer!
What every other disadvantages you can think of, don't forget that the biggest advantage still is the huge amount of data you can store on an harddisk !!!


Parallel loaders
Using the free A-port means that we cannot use a number of parallel speedloaders using this port (Speeddos, Dolphin-DOS etc.). On the other hand there exists some excellent serial speedloaders. IMHO it is a matter of making a patch for them.
For those die-hards who insist on having a parallel loader, IMHO one could add an extra 6522 to the system by piggybacking it on top of an other. You'll need an extra 74LS139 decoder to address it.


Additional ideas
I already mentioned to add an extra 6522 for people who need the parallel port. Why not add even a second extra 6522? In this way we solve two minor problems:

  • some people considered cutting the lines between the 6522 and the rest of the circuit as a bigger problem then installing an extra IC.
  • programs that address the original 6522(s) directly cannot mess up the harddisk by accident anymore.
Another advantage: maybe it is possible to use both the floppy drive and the harddisk together. In this way we could have a convenient way to copy the contents of a floppy directly to the harddisk!

Another idea is developing a circuit that contains a real IDE-interface plus space for the needed extra RAM and ROM. I'm working on this idea as well but to be honest, I think I favour the above idea as being the most simplest one of the two.


The Kernal
Whatever system we choose, we'll need a filesystem and software to handle it. The original 16 KB won't do. So we have to replace the original ROM(s) with a 27256. When dealing with a 1541-II, one only needs to replace the original (EP)ROM and to add addressline A14. When dealing with another type of drive, some more work has to be done like using a 24 pin -> 28 pin converter, adding the missing addresslines and using A15 plus an invertor for selecting this EPROM.

The main idea anyway is to use the original Kernal as much as possible. At the point the Kernal starts to address the hardware for the original floppy disk, we have to break in and JMP/JSR to our own routines. And these new routines will all be placed in the $8000-$BFFF part. So even obsolete original routines won't be overwritten. The reason for this is compatibility; there could be software are around relying on these routines so replacing them could lead to unexpected errors.


Extra RAM needed ???
During the first days of writing code I run into the following problem. A harddisk sector contains 512 bytes. So I decided to place two 1541-sectors on one harddisk-sector. The problem is that, when writing data to an harddisk sector, I have to write ALL 512 bytes. So saving one sector means I first have to read the according harddisksector, then I have to replace the data of the according half and then I have to write these 512 bytes to the harddisk again. The problem is: where do I store these extra 256 bytes???

There are three solutions:

  • I only use 256 bytes of every sector. Disadvantage: I loose 50% of the harddisk. But this idea can be used in the beginning of the development.
  • I swap two pages to the harddisk and use these pages as temporary store. After the action the pages are restored again. Disadvantage: time consuming.
  • I install extra RAM. A minimum of an extra 2 KB will do. I intend to keep this as minimum for all further developments. Disadvantage: more soldering needed.

      I already found out that, when using an harddisk, I must store more info then with a normal disk. Some variables used for GCR en/decoding can be used for this purpose. But the moment I want to be able to handle more then one IDE-device and/or partition, I'll surely need more RAM. So I decided to go for the extra RAM option.


      The original interface
      AFAIK all known versions of the 1540 and 1541 can be used. But the codes on the board for the various ICs vary from version to version. Therefore I will refer to the 6522 handling the floppy disk as #1 and the to the 6522 with free A-port and handling the IEC-bus as #2.

      Both the A-ports will be used to handle the datalines: port A of #1 will handle the databits D0..7, port A of #2 will handle D8..15. Port B of #1 will handle the controllines:
      * PB0 : addressline A0
      * PB1 : addressline A1
      * PB2 : addressline A2
      * PB3 : LED
      * PB4 : write protect sensor
      * PB5 : future use
      * PB6 : IOWR
      * PB7 : IORD
      * CA2 : CS0
      * CB2 : CS1

      As you can see the original LED is still be used. The IDE-interface has its own pin to connect a LED to but this one will only light up when the HD is active and therefore cannot be used to flash codes or whatever.

      The idea is to replace the original "write protect sensor " with a switch, just like the one CMD-harddisk already has. Advantage: I can keep on using the original routines handling the original write-protect sensor.

      When cutting lines, makes sure the one to the SO-input of the 6502 is cut as well. Then connect this input to +5V through a 10K resistor. We don't need it right now but the resistor enables us to use it in the future.


      The interface with extra 6522's
      The use of the pins is exactly as above with the exception of PB3 (the LED): in this case I will use the original PB3 to drive the LED because no alterations of the original circuit and software are needed.


      A real IDE interface
      I also designed and partly build a real interface based on the IDE interface I designed for the C64. The biggest advantage is that it is just a matter of placing of the PCB between the original board and and the 6502. The disadvantage is constructing the board, that is, by hand as I did. If you want to spend some money on making a real PCB, then that is a different matter. The design is made in EAGLE 4.11 and free.


      The LPT interface
      This idea is based on PC-Flop. PC-Flop didn't work out but the basic idea still can be used; we use an altered Kernal. The disadvantage of this idea is that you are stuck with a big PC alongside your 1541. The advantage is, at least for me, the development of software is easier. Handling large harddisks means we need another filesystem. But writing the software for it is another story. I feel that using this configuration I have more grip on the developing of the original idea. Things can be tested much more easily IMHO. And when things work out fine, I can port it to one of the other systems.


      Future expansions
      The 1541 has 2 KB of RAM onboard. By piggybacking some IC's you can enlarge this number. Extra RAM always comes in handy, certainly because one of my ideas is to let the HD equipped 1541 act as two or more 1541 drives. Read about it in the next section.

      In a PC one can connect two devices to one IDE-port. So why can't we? :)

      Modern PC's have at least two IDE-ports. This is something that can be realised for our system as well by adding a 74LS139. CA2 and CB2 will steer the AB-inputlines of this 139. Outputs Y0 and Y1 steer the CS0 and CS1 line of the first port and Y2/3 steer CS0/1 of the second port.
      Hmmm, what about using CA2 and CB2 of the other 6522 as well? We could end up with 16 devices in this way :)

      As CMD and our Czech friends do supply an RTC with their HD-system, I'm thinking of implementing one as well. I want to use the DS12887 for four reasons:

      • 1) it is used in the PC and therefore well known to many programmers
      • 2) it only uses 2 bytes of your memorymap
      • 3) it has 48 bytes of RAM onboard, which can be used for a lot of purposes
      • 4) I have several laying around :)
      Those people who are unfamiliar with the DS12887, it is the Dallas-version of the Motorola MC146818, the RTC used in PC's. The main difference is that the DS1287 is an stand-alone IC; you don't need an external battery/accu or crystal anymore. Of course all SW we develop must be able to run on a system without a RTC onboard. This can be realised by first checking if a RTC is onboard and if not, letting all routines concerning the RTC return a "not valid" value.


      Filesystem format
      A proposal for a filesystem.


      Current state

      !!! Froosen !!! I simply have to many projects. I first want to finish CBM-HD.

      After some weeks I found out that the task to convert the original ROM into one using the new filesystem was impossible for the moment. So I decided to split up the development in several steps:

      • The harddisk is treated as an 8-bit device and its tracks and sectors will be addressed directly as if it had the same size and structure as the original floppy. So we only are able to use 683 sectors.
        Remark: only harddisks with at least 21 sectors/track can be used.
      • Translate 1541-track/sector to IDE-track/head/sector so any harddisk can be used.
      • The harddisk is treated as 16-bit device. Extra RAM needed! Should only affect the routines that address the harddisk itself.
      • Expanding the size the partition from "1541" to one using 255 tracks and 255/256 sectors (= 16 MB). Means we have to expand the BAM in one or another way. Affects all the routines concerning the BAM.
        Question remains if I'm going to use my own 16 MB layout or the one used by the CMD-harddisk (copyrights ???). Have problems understanding the last one so...
      • Implementing my own FS.
      • Adding commands that enable us to handle things like "MD", "CD" and "RD". This step could be parallel to the previous ones.
      I finished the sources for step 1 but I am still busy with soldering the cable, so testing has to wait for the moment.


      My ideas used in the steps

      • The first step was writing the basic routines that should be used for addressing the harddisk and transferring bytes and sectors. I needed 7 bytes to store the following information:
        * track (2 bytes)
        * sector
        * head
        * number of sectors
        * pointer to area where to read from/write to
        I took the liberty to use the zeropage locations starting at $52 as these are in use fro the GCR routines and I was pretty sure I wouldn't need these anymore.

        The next step was finding the places where the registers PortA2, PortB2 and PCR2 were addressed and analysing the routines that performed the addressing. So where needed I changed the code at that place.

        PortA2:
        PortA2 is only used when actually transferring data from/to the floppy. I quickly found out that these routines could not be used for the harddisk so I replaced them with new ones. So there was no need to alter the code in the original ones anymore.

        PortB2:
        The routines for stepping the head and checking for the SYNC-mark are not used anymore. So there was no need IMHO to alter the code here.

        • $F259: initialisation of the diskcontroller
        • $F35C: density is not needed anymore
        • $F385: no need to turn motor on for bump action
        • $F987: no need to turn motor on (main motor-on routine)
        • $F9ED: no need to turn motor off
        • $FAE0: no need to turn motor on for formatting

        PCR2:

        • $F259: initialisation of the diskcontroller
        • $F2BB: "Byte ready" is not used anymore

        Formatting
        Formatting a "disk" is done by formatting track by track. The only thing I had to do is replacing the routine that takes care of formatting a track. FYI: The original routine starts at $FB0C and ends at $FD8B.
        The new routine shows I was lazy: instead of formating the normal number of sectors, I formatted 21 sectors on each track. The original 1541 fills the sectors with $01 bytes. AFAIK this is a bug but I saw no reason to fill the sectors with another value.

        Stepping the head
        This one costed me some sweat. The problem is that stepping the head is not one routine. It involves turning the motor on and checking how much tracks are going to be skipped. And if this number is large enough, the drive goes to fast stepping mode.
        Then I reasoned that when I know the number of steps, the direction and the starting track, I could calculate the destination.
        The next thing I found out was that when searching for a sector, the 1541 compares the header with the info it expects to find. Knowing this it was easy to make sure that the 1541 indeed would find it was looking for.

        Then I bumped into a small problem. Telling to go to a specified track immediately after powering on (like with LOAD"$",8), it first checks at what track the head is above by reading the header. As the HD-sectors don't have headers, I had to emulate this feature. Default the "head" of 1541IDE is above track 18 at power-on.
        A bigger problem was the fact that the 1541 extracts the disk-ID from the header. I have thought about changing all the code referring to this ID but then I decided it was much easier to read the BAM first before doing anything else.
        The seven bytes mentioned above are used to store the info needed to emulate "reading" the track and ID from the header.


      To be continued.....



      You can email me here.


      [Homepage]