1541IDE8
What is it?
The main idea is connecting an IDE harddisk to a 1541 drive using a simple 8 bits interface.Related software
Jim Brain decided to produce some PCB's based on my 16-bits design. To make it easier for some software devellopers to find my software, I decided to place the links to the various sources on top of this page.1541IDE3
The Basic program in plain text
The sources of the ML part
1541IDE2
Images on harddisk, including floppy drive.
Images on harddisk, without floppy drive. Contains errors !!!
1541IDE1
Supports up to 128 GB harddisks.
Assembler
My freeware assembler.
History
In 1541IDE I wanted to add an IDE harddisk to 1541 drive using (an) extra 6522 ('s) or using a real 16 bits interface. I ran into two problems:- the needed hardware was more complex then I liked
- creating a file system for the whole
The IDE 8 bits interface
FYI, an IDE harddisk behaves like an Intel or Zilog IC: such an IC has address lines and chipselect lines like the 6522 for example. 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 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 part is used to generate the needed RD and WR signals out of PHI2, R/W and the chipselect signal coming from the onboard 74LS42. The other part is used to generate CS0 and CS1 out of address line A3 and again the chipselect 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 harddisk :( 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.
The schematic can be found here. The Eagle source here.
The advantages of an 8 bits interface
OK, only using 8 bits means you are throwing away half of the capacity of a drive. But having several x.x GigaBytes drives laying around just doing nothing, I thought I could afford it. And for those people who like numbers: an old 1.2 GB disk can store the equivalent of 3000 floppies.Only using 8 bits also solves the 512-bytes-sector problem. A Commodore sector contains 256 bytes of data, an harddisk sector 512 bytes. So two Commodore sectors fits in one harddisk sector one would say. But the problem is writing a harddisk sector; we have to write 512 bytes to the drive. This means we first have to read this harddisk sector in order to get the 256 of the second Commodore sector. Having read it, we now can write both the old and new Commodore sector to the harddisk again. However the main problem is: where to store these 512 bytes ??? We cannot make use of the original RAM because there are circumstances that all buffers are occupied and we still have to read those 512 bytes. The only solution would be: extra RAM.
File system
Having solved the problem of the hardware, I still was stuck with the problem of the file system. Some years ago I already proposed a file system and decided to use it as a base. The main feature of this file system is that it uses four bytes instead of the origanal two. These two represent track and sector, the four new ones the LBA value of a sector.Instead of beginning from scratch, I also decided to use the original Kernal as base. But not knowing much of the original Kernal and not having much time, things didn't go well. But then I got this idea: I'm going to use images first!
The idea is to store only D64 images on the harddisk. Or better, extended D64 images. As you know, the original 1541 disk has 35 tracks with a number of sectors ranging from 21 down to 17. Some programs enable you to format a disk up to 40 tracks and these extra sectors each contain 17 sectors. The original disk contains 683 sectors. Add these extra 85 sectors and you have 768 sectors. Or hexadecimal, $300 sectors. And using the number $300 will simplify calculations enormously.
Testing the idea: 1541IDE3
Could this idea be tested? The idea rose to write a small ML program that should run on the 1541 and a Basic program that should load and start it. Starting the PRG with RUN causes it to create an image of the floppy on the harddisk. It only asks for the number of the image. Important: as the PRG has no knowledge of the size of the disk, it is up to the user to check the number!.FYI: image 0 starts at sector 1, image 1 at sector 769, image 2 at sector 1537, etc. etc. etc. Sector = (image number - 1) * 768 + 1.
The Basic program in plain text
The sources of the ML part
It takes about 3 minutes to create an image and 4.5 to restore one. If you have a look at the ASM you'll see I only use the original 1541 routines. I'm convinced that things can be speeded up by using self written routines. A friend already suggested to read and store the raw data. Circumventing the GCR routines one could save the data of one track in just one turn! Creating an image would only be limited by the speed of stepping and setling the head.
Only using images: 1541IDE2
Prooven that the idea of images worked, the next step is to use the images themself. The project 1541LPT proofed that the Kernal can rewritten in such a way that when the data should be written to the actual floppy, it can be rerouted to the LPT port of a PC. And the same for reading data. If it can be done with a LPT port of a PC, then why not with an image on a connected harddisk?Why images anyway? The idea behind this is that I don't have to change any of the routines involving handling the files and sectors. If this works out fine, the next and last step is 1541IDE1; a 1541 with a file system capable of handling disks in the GigaByte size.
With the exception of the very first sector, the first $300 sectors are used for the directory of the disk. Each sector contains eight entries of 32 bytes each. An entry contains the name of the disk as found in the BAM plus some extra info. 768 sectors equal 6144 entries which on their turn represent about 1.2 GB (= 2.4 GB harddisk) of images. Using bigger harddisk means we have to reserve as many blocks of 768 sectors as needed.
The floppy will still be used. In the beginning the idea was to ommit it but the I realised i can use it for creating the images. And it also can be used in case of incompatibilities.
Extra ROM needed
In contrary to the previous project, I have to change the ROM. Luckily I can lean on the information gathered with 1541LPT: No more floppies anymore!. In this case I was able to squish everything in one 27128 EPROM. But unfortunately that won't work for this project as the 1541 has to handle the harddisk itself now. This means installing a 32kB 27256 EPROM in one or another way.Unfortunately pin 27 of the EPROM socket in a 1541-II is connected to pin 28 at both sides of the print. I solved this problem by desoldering the socket, cutting the two traces between pin 27 and 28, soldering a new socket and connecting pin 27 to address line A14 of the 6502.
Another solution is placing an extra socket between the original one and the EPROM, and connecting pin 27 of this extra socket to address line A14 of the 6502.
Extra RAM needed
As far as I can see now, some extra RAM is needed as well. At this very moment I need some extra RAM to store some variables like harddisk parameters, current image in use etc. but I also need RAM for loading harddisk sectors outside the normal proces like for reading the directory of the images.I simply piggybacked another 2 KB RAM IC on top of the original one. The OE and CE input of the IC I connected to output Q4 of the 74LS42. In this way I waist 1 KB of memory but it is far the most the quickest and easiest hack.
Discarding the floppy drive
An option in this part of the project is to discard the floppy drive. Not needing the GCR routines and therefor being able to free quite some RAM in the Stack area, no extra RAM is needed.As far as I can see at this moment enough space in the original Kernal can be freed as well so no extra ROM is needed.
1541IDE1: handling real harddisks
I'm already busy with rewriting the original 1541 Kernal so it can handle up to 128 GB harddisks (64 GB effective use of course). Removing al references to the mechanical drive and the non existsing second drive I was able to save over 3000 bytes. With a bit of luck this is enough to implement the various routines needed for handling subdirectories which means that everything fits in a standard 27128, thus no soldering needed.Not needing the GCR routines anymore also meant I could free that part of the Stack used by these routines. Enough to store the variables mentioned above, to double the original Stack and, most important at all, again no soldering needed!
New file system
To be able to handle xx GigaByte harddisk, another filesystem is needed. In 2001 I designed this one and the one I'm going to use looks like it.The main feature is that I'm not going to use two bytes for linking to a sector, the Track/Sector bytes, but four. Did the 2001 design use the four bytes Track/Sector/Head encoding, now I'm using the four bytes LBA one as it is much easier to use.
Copying great amount of data to the disk
Being able to handle, let's say, 4.3 GB of data is nice. But how are we going to put this amount of data on the harddisk?Two ideas:
- Connecting the harddisk directly to a PC
No further explanation needed I think. Two removable harddisk docking stations can do the trick. But we need a program to do the actual copying as Linux, Dos or Windows won't understand the layout of the disk.
- Using the hardware of 1541LPT
I already realized this project: 1541LPT: No more floppies anymore!; a project where the PC replaces your physical floppy disk drive. It only involves adding an extra 6522 and a 25 pin male D-connector. Up- and downloading images is now just a matter of connecting the 1541 to the LPT port of the PC and starting a program on the PC and the 1541.
Having questions or comment? You want more Info?
You can email me here.