Ruud's Commodore Site: 1541IDE8 Home Email

1541IDE8




What is it?

The main idea is connecting an IDE hard disk drive (HDD) or Compact Flash card (CF) to a Commodore 1541 floppy drive using a simple 8 bits interface. The floppy drive can be used as well, if needed.
Upgrade 1: I designed a dedicated PCB for this project, more RAM and ROM but I dropped the floppy drive part.
Upgrade 2: I combined this idea with 1541LPT and 1541Arduino, resulting in one PCB for both projects.


Software

The sources are freeware. At this moment they are a work in progress so if you want them, just email me.


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-bit 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 also another try.

In 2024 I decided to revive this project with designing a new board. In short: it is a 1541-II board minus the floppy drive part but plus the 8-bit IDE interface. This board should fit in the original case.


Schematics, old





Theory, old

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 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
  • 2 Block select lines: CS0 and CS1
  • 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. So far I haven't found any use for CS1 at all. But I still decoded it, "just in case".

There are more lines on the IDE bus but they are only needed for very fast computers. For example: there is an interrupt line that becomes active every time the execution of a command has been finished. This may be very useful with a Pentium 300 MHz but I already found out that handling an interrupt by a C64 would cost much more time then just waiting for the BUSY flag to clear.

There is one other line I use but that 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 chooses 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. 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.

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.


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 real 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 and this simply means there is no memory left to store the extra floppy sector. The only solution would be: extra RAM. And that is what I liked to avoid at that time, just to keep things as simple as possible. But 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 wasn't able to handle the drive anymore, something I wasn't happy with. If the Power Cartridge uses hard coded calls or jumps to the ROM of the 1541, other programs or cartridges can 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.


The software

Rewriting this page in 2024 I found out that I hardly mentioned the software. I also found out that my version control sucked: I have a long way to go to find out what I did in the past.

The idea behind the very first versions was simple: remove the parts from the code that are not needed and move the still needed code so that we have one big free area that can be used to insert the new code needed for handling the IDE drive.
That worked out fine until I ran into the trouble with the KCS Power Cartridge I mentioned above. This lead to the idea to keep the original source as intact as possible and only to insert a jump to the new software that was situated in ROM part from $8000 to $BFFF. The trick was to place the new jump at such a place that most probably was not accessed by an external program. So far this idea worked because I hadn't any trouble anymore with the Power Cartridge and some other programs I found in the mean time.


New 2024 version

In 2024 I decided to revive this project but then as an-IDE-only project by creating an own PCB for it.


Schematics, new 2024 version






Hardware, new

Again: see it as a 1541-II board where all floppy drive related ICs have been removed but has instead the IDE inteface on the board itself.
The new board contains a 6502, running on 1 MHz again. I have thought of running it at an higher frequency but I had no idea if that could jeopardise the communication between the 1541 and the C64. Writing these lines I also became aware that another frequency will affect the JiffyDOS communication so I dropped this idea completely.

It contains two 6522s, like the original board. But the special IC that handled various signals for the floppy drive is missing. This means all I/O pins, except the one serving the LED, are not used anymore. I have thought about dropping this 6522 but, except driving the LED, its timers are used as well.
When testing the original design, I added a third 6522 with four 7-segments LED displays for debugging. The now not used I/O pins of this 6522 can now be used for that purpose.

The original board had 16 KB of (EP)ROM on board. By removing the socket/ROM I could cut a connection and by adding address line A14 I was able to handle 32 KB of ROM. Of course this board can handle the 27256 32 KB EPROM. FYI: I will use 27F256 or 27F512 EEPROMs, much faster to re-program.

The original board had 2 KB of RAM on board. By piggybacking another 2 KB SRAM on top of the original SRAM I was able to add another 1 KB of SRAM. That was needed to handle various variables needed to handle hard disk drives. For this new design I decide to use a 32 KB SRAM.

One idea I had then was adding a RTC to the original board but having these big 28 pins versions in mind, I didn't consider it feasable. But nowadays one can buy complete modules with a 5 pins interface for peanuts. Such a module only needs power, a reset, clock and data line. The first idea was to use two unused I/O pins of Floppy Drive 6522 but there is always a risk that a program, handling this 6522 directly for whatever reason, then messes up the RTC. Solution: use any unused CA2 or CB2 line. Risk: almost zero.

The old main IC to handle these ICs mentioned above was a 74LS42, a 4-to-10 decoder. Because of the two 6522s and the IDE circuit, not all 32 KB of RAM can be used as so and, to make a long story short, I decided to use a GAL. The GAL takes care of selecting the RAM, EPROM, the two 6522s and the IDE circuit.


Software, new

AFAIK the ROM used for the old 1541IDE8 should work on the new version as well, without any doubts or questions. What I will do is to look if I can optimise routines for having now a real drive-less system.


Hard disk drive vs. Compact Flash card

The PATA specifications, PATA is the official name for IDE, mention that an IDE device may work in 8-bit mode. So far I never found an HDD that could do that but I was informed that that should not be a proble for CF. Main reason: CF was used in digital cameras before SD cards took over. And the first digital cameras used 8-bit processors. In the past I tested some CF cards and they indeed accepted 8-bit mode. But I never did anything with it for a simple reason: in those days I owned two CF cards, they were only 32 MB and had no need to buy more. I used these two only to test the software I was working on because they were much more easy to handle than HDDs.
But nowadays I own more, some "even 4 GB big!". But let's face it, 4 GB is less than half of a halved 20 GB HDD. But the availibilty of much, much more RAM and this prooven existence of the 8-bit mode made me to reconsider if I should make full use of the capacity of a CF card. What does make me hesitate is the fact that when I must write a record to the CF card, it will take four times as long as writing a record in the old: reading 512 bytes plus writing them again aganst only writing 256 bytes.


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.


A PCB combining 1541IDE and 1541LPT / Arduino

I decided to to create a PCB that combines both projects, 1541-MDC, for a simple reason: one PCB that can be used for both project.





Having questions or comment? You want more information?
You can email me here.