1541IDE8
Current state
Work in progress, but low priority.What is it?
The main idea is connecting an IDE hard disk drive to a Commodore 1541 floppy drive using a simple 8 bits interface. The floppy drive can be used as well, if needed.Software
The sources are freeware. If you want them, just email me.Schematics
As image
Eagle source
History
In the past, around Christmas 1998, I got interested in connecting an IDE hard disk drive to my C64 in one or another way. The result was an interface of just eight common available cheap ICs, C64IDE. With some small changes you should be able to connect the interface to any other C= as well.But I soon found out that it was not 1541 compatible enough: too many games and utilities looked for various reasons for a real 1541 connected to the IEC bus. So the idea rose to use the interface in a 1541 to decrease the compatibility problem. But being more a hardware then a software guy, I discarded the idea.
In 2006 I decided to pay attention to this idea again. Here I ran into various problems. The first one was that there wasn't a well documented source code of the 1541 file system available. It turned out that I had to create the source code myself first.
In 1541IDE I wanted to add an IDE hard disk drive by means of either one or more extra 6522's for the bit-banging method or by using a real 16 bits interface. And again two, more or less, problems:
- extra 6522's: bit-banging turned out to be too slow to my taste
- 16 bits interface: the needed hardware was more complex then I liked
The most interesting thing of the IDE hard disk drive is that the command registers are only 8 bits wide. The data register is in fact the only 16 bits wide register. Technically seen there is no objection against only using eight bits of it. Already in 1999 I was thinking about using only an 8-bits interface but wasting half of the capacity of a disk in those days was almost a crime! But because more and more hard disk drives with a capacity of more then 10 GB became obsolete and free to get, I decide to give this idea another try.
Theory
There is no specific knowledge of the IDE bus needed to understand how my interface works. The IDE bus is based on the old MFM, RLL and ESDI HDDs. The idea rose to integrate the controller on the board in the PC with the onboard controller of the hard disk drive and to attach the resulting board to the hard disk drive. The only signals needed for the resulting board would be the same signals as those after decoding the complete ISA bus. These signals together form the IDE bus.The signals we need for our interface are:
- 8 data bits, D0..D7 (D8..D15 are not used and pulled high by a resistor array)
- 3 address lines, A0..A2
- 1 Register block select lines: CS0 (CS1 is not used)
- 2 Read/write lines, IOW and IOR
- the Reset line
Remark regarding CS0 and CS1: The IDE HDD has two blocks of eight registers each: the "Command Block Registers" and the "Control Block Registers". The first block is chosen by negating CS0, the second by negating CS1. But so far I haven't found any use for CS1 at all.
There is one other line I use but is not needed for the correct working of the interface itself: DASP. The function of this line is to blink a LED when the HD is executing a command or reading/writing data. For me it was quite helpful during debugging.
Some hard disk drives and quite some, if not all, Compact Flash cards are capable of telling the system to use an 8 bits data register. But I haven't found any xx GB hard disk drive yet with this feature and therefore I decided not to pay it any attention anymore.
The IDE 8 bits interface
Applying the right value to the address lines A0..2 and negating CS0 choose the correct register within the "Command Block Registers". Reading from or writing to a register is done by negating IOR or IOW, just like an Intel or Zilog IC. But where a 6522 has a PHI2 input for the timing and a R/W input for telling whether it is a Read or Write action, an Intel/Zilog IC has a RD and a WR input instead. One of these becoming (L) has the same effect on the IC as PHI2 becoming (H) for a 6522. Further either RD or WR becoming (L) tells the IC what action is needed.The main part of the interface is a 74LS139, dual 2-to-4 demultiplexer. One half is used to generate the needed RD and WR signals out of PHI2, R/W and the chip select signal coming from the onboard 74LS42.
In my original design the other half is used to generate CS0 and CS1 out of address line A3 and again the chip select signal coming from the onboard 74LS42. Not having found any use for CS1, this half can be used for other purposes.
My very first design blew up due to a faulty power supply. It didn't only fry the 1541 board but also a 6.4 GB hard disk drive :( That's why I decide to add two buffers, a 74LS245 for the data and a 74LS244 for the address lines and the reset signal. But I already have plans to build another 1541 with only a 74LS139 just to proof that a single chip interface can work as well.
The schematic can be found here. The Eagle source here.
Here is a photo of my self build interface:
The advantages of an 8 bits interface above the 16 bits one
Using only 8 bits means we are throwing away half of the capacity of a drive. But, as said before, having several x.x Gigabytes drives laying around just doing nothing at all, I thought I could afford it. And for those people who like numbers: an old 1.2 GB disk can store the equivalent of over 3000 1541 floppies, even when only used half.Only using 8 bits also solves the 512-bytes/sector problem. A Commodore floppy sector contains 256 bytes of data, a hard disk drive sector 512 bytes. So two Commodore floppy sectors fit in one HDD sector one would say. To read a floppy sector the whole HDD sector of 512 bytes has to be read. Ok, not such a problem, we only save those 256 bytes we really need.
The real problem is writing a floppy sector of 256 bytes: we have to write all 512 bytes of a HDD sector to the drive. This means we first have to read the HDD sector to obtain the 256 bytes of the second Commodore floppy sector as well. Having read the complete HDD sector, we now can write both the old and new Commodore floppy sector to the hard disk drive again. The whole process will cost valuable time: instead of writing one single C= sector we have to read two first and then write two again.
However the main problem is: where to store these extra 256 bytes of the second floppy sector ??? We could reserve a buffer for this purpose but that won't work always. There are circumstances that a program needs all available buffers minus the one reserved for disk operations. This simply means we have no memory left to store the extra floppy sector. The only solution would be: extra RAM. And that is what I like to avoid for the moment, just to keep things as simple as possible.
Remark: at the end I found out that, if I wanted to support some nice features, I couldn't do without extra RAM. See later...
Are there any disadvantages by only using 8 bits? Beside the capacity loss I ran into one only: it is possible to extract all kind of information from the drive itself, for example the number of LBA sectors. The problem is that this info is given in 16 bits format. And as my interface is only able to handle 8 bits.....
Using the floppy drive
I already mentioned the idea to combine a floppy drive and a hard disk drive. In the beginning I dropped this idea as I didn't see any advantages, especially because I knew for certain that I would need extra RAM and ROM. Extra RAM to store hard disk drive related parameters and extra ROM to store the new routines. And all this wasn't worth the trouble IMHO.But then I got this idea: the floppy drive could make my 1541IDE 99.99% compatible again! The idea is:
- copy the image to floppy
- switch to "floppy mode"
- do what you have to do
- switch to "hard disk drive mode" again
- copy the contents back to the hard disk drive (if needed).
Unfortunately this trick won't work with floppy disks with special copy protections like using halftracks. 1541IDE in "floppy mode" can work with these disks but cannot create images of them as the D64 format doesn't store information like halftracks and extended gaps. Therefore 1541IDE can never reproduce the original disk again.
But to make things clear: AFAIK there is no limitation in handling disks of this kind when in "floppy mode".
The idea was realized by inserting JMPs or JSRs in the original code there where needed. The JMPs and JSRs all point to the extra ROM in the $8000/$BFFF area.
The hardware
The IDE interface has been described above already. I already mentioned that extra RAM is needed. The most simple way is to piggyback another 2 KB RAM (6116, 2016 or equivalent) on top of the original one with the exceptions of pin 18 (CS) and 20 (OE). You have to solder these two pins to the same wire that is connected to pin 3 of IC4, a 74LS42. This configuration will let you only use 1 KB of the available 2 KB. For my needs it was more than enough. If you, for one or another reason need to, adding an AND gate that combines pin 3 and 4 of IC4 will give you the complete 2 KB range.I was able to fit all needed software in the original 16 KB by removing obsolete routines like the format and GCR routine. But then I discovered there was a price to pay: the KCS Power Cartridge weren't able to handle the drive anymore,something I wasn't happy with. If the Power Cartridge used hard coded calls or jumps to the ROM of the 1541, other programs or cartridges could do that as well.
The "floppy version" requires extra ROM anyway so I decided to go for it. But it depends on the type of 1541 how it is added. I installed 1541IDE in a brown 1541 and in a 1541-II.
In the brown 1541 I piggybacked a socket on top of the second RAM and wired it in such a way that it could contain a 27256 EPROM (or equivalent EEPROM). I used the two original 2364 sockets for the IDE interface.
The 1541-II already contains a 27128. Pin 27, needed for address line 14, is connected to pin 28. Unfortunately it is connected to pin 28 at both sides of the board. Now you have two options:
- desolder the original socket and cut both the connections.
- solder another socket on top of the original one but leave pin 27 free.
Now connect pin 27 of whatever option you used to address line 14 of the 6502.
Future plans
One problem is with 1541IDE is filling the HDD with data. The only possibility I have now is using copy programs to copy programs from another drive to this one. I have been busy using the onboard floppy but the first results were quite disappointing.Another idea to combine this project with 1541LPT and use the LPT interface to fill the hard disk with images. Still in progress.
As said before CompactFlash cards can be used as well. In contrary to HDDs, most CF cards support the data exchange using only 8 bits. Because of the extra RAM I now have, this made we think of using the full sector again but in combination with using FAT32 as file system. The advantage: any PC with a CF card interface can fill it with D64 files. The disadvantages: it will take more time to retrieve and write data and I have to find out how FAT32 works.
Bugs
Probably a lot :)You can email me here.