1541IDE
Current state
!!! Frozen !!!This project has been replaced by 1541IDE8. I keep it online as it still contains interesting information and ideas.
What is it - the original idea
The IDE-hard disk drive has 16 data lines and 7 control lines. 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 a hard disk drive !!!
Parallel loaders
Using the free A-port means that we cannot use a number of parallel speed loaders using this port (Speeddos, Dolphin-DOS etc.). On the other hand there exist some excellent serial speed loaders. 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 another 6522.
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 hard disk drive by accident anymore.
- Keeping the original 6522 configuration enables one to use the original floppy drive parallel to the hard disk drive. In this way we could have a convenient way to copy the contents of a floppy directly to the hard disk drive!
The Kernal
Whatever system we choose, we'll need a file system 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 address line 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 address lines and using A15 plus an inverter 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 around that relies 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 hard disk drive sector contains 512 bytes. So I decided to place two 1541-sectors on one hard disk drive-sector. The problem is that, when writing data to a hard disk drive sector, I have to write ALL 512 bytes. So saving one sector means I first have to read the according hard disk drive sector, then I have to replace the data of the according half and then I have to write these 512 bytes to the hard disk drive 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 hard disk drive. But this idea can be used in the beginning of the development.
- I swap two pages to the hard disk drive 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.
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 to the 6522 with free A-port and handling the IEC-bus as #2.Both the A-ports will be used to handle the data lines: port A of #1 will handle the data bits D0..7, port A of #2 will handle D8..15. Port B of #1 will handle the control lines:
* PB0 : address line A0
* PB1 : address line A1
* PB2 : address line 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-hard disk drive 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 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.15 and free.
The LPT interface
This idea is already working: 1541LPT: No more floppies anymore!. 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 hard disk drives means we need another file system. 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 ICs 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 realized for our system as well by adding a 74LS139. CA2 and CB2 will steer the AB-input lines 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 memory map
- 3) it has 48 bytes of RAM onboard, which can be used for a lot of purposes
- 4) I have several laying around :)
File system format
A proposal for a file system.Development
After some weeks I found out that the task to convert the original ROM into one using the new file system was impossible for the moment. So I decided to split up the development in several steps:- The hard disk drive 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 hard disk drives with at least 21 sectors/track can be used.
- Translate 1541-track/sector to IDE-track/head/sector so any hard disk drive can be used.
- The hard disk drive is treated as 16-bit device. Extra RAM needed! Should only affect the routines that address the hard disk drive 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-hard disk drive (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.
My ideas used in the steps
- The first step was writing the basic routines that should be used for addressing the hard disk drive 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 analyzing 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 hard disk drive 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: initialization of the disk controller
- $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: initialization of the disk controller
- $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 formatting 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 made me 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.
Not to be continued any more, please see 1541IDE8.
Having questions or comment? You want more Info?
You can email me here.