Hallo Robert,
> Even more interesting: "Ruud Baltissen has also
> started a project
> for converting an 1541 disk drive into an IDE controller."
>
> http://home.hccnet.nl/g.baltissen/ide.htm
The above project enables you to connect an IDE-drive to your C64. The one
meant for the 1541 you can find at:
http://home.hccnet.nl/g.baltissen/1541ide.htm
I just noticed that the info is a little bit outdated; it seems that the
upload i did yesterday evening went wrong. The main page says last update is
October, the update page mentions November 14th. I'll try again this
evening.
Here are the major changes. Is HTML but readable in text mode IMHO.
{FONT COLOR="#FF0000"}{B} Changed !!! {/B}{/FONT}
{B} {FONT COLOR="#3300FF"}The interface{/FONT} {/B} {br}
{FONT COLOR="#FF0000"}{B} Changed !!! {/B}{/FONT}
AFAIK all known versions of the 1540 and 1541 can be used. But the
boardcodes for the various ICs vary from version to version. Therefor I will
refer to the 6522 handling the floppydisk as #1 and the to the 6522 with
free A-port and handling the IEC-bus as #2.
{p}
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: {br}
- PB0 : addressline A0 {br}
- PB1 : addressline A1 {br}
- PB2 : addressline A2 {br}
- PB3 : LED {br}
- PB4 : write protect sensor {br}
- PB5 : future use {br}
- PB6 : IOWR {br}
- PB7 : IORD {br}
- CA1 : CS0 {br}
- CA2 : CS1 {br}
{p}
As you can see the original LED is still be used. The IDE-interface has its
pin to connect a LED to but this one will only light up when the HD is
active and therefor cannot be used to flash codes or whatever.
{p}
The original idea was to use a "write protect"-switch in the futere, just
one like the CMD-harddisk already has. I intended to use the CA1- or
CB1-input but then I found out these inputs cannot be read directly ie. they
are only good enough to trigger an interrupt. So I decided to use CA2 and
CB2 as outputs to drive the CSx-inputs of the harddisk. {br}
Advantage: I can keep on using the original routines concerning the use of
the write-protect sensor.
{p}
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.
{p} {br}
.........
{B} {FONT COLOR="#3300FF"}Current state{/FONT} {/B} {br}
After some weeks I found out that the task to convert the original ROM onto
one using the new filesystem was impossible for the moment. So I decided to
split up the devellopment in several steps:
{UL}
{LI} 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. {br}
Remark: only harddisks with at least 21 sectors/track can be used. {br}
{LI} Translate 1541-track/sector to IDE-track/head/sector so any harddisk
can be used.
{LI} The harddisk is treated as 16-bit device. Extra RAM needed! Should only
affect the routines that address the harddisk itself. {br}
{LI} 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. {br}
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...{br}
{LI} Implementing my own FS. {br}
{LI} Adding commands that enable us to handle things like "MD", "CD" and
"RD". This step could be parallel to the previous ones.
{/UL}
I finished the sources for step 1 but I am still busy with soldering the
cable, so testing has to wait for the moment.
{p} {br}
{B} {FONT COLOR="#3300FF"}My ideas used in the steps{/FONT} {/B} {br}
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: {br}
- track (2 bytes) {br}
- sector {br}
- head {br}
- number of sectors {br}
- pointer to area where to readfrom/write to {br}
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.
{p}
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.
{p}
{B}PortA2:{/B} {br}
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.
{p}
{B}PortB2:{/B} {br}
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.
{UL}
{LI} $F259: initialisation of the diskcontroller
{LI} $F35C: density is not needed anymore
{LI} $F385: no need to turn motor on for bump action
{LI} $F987: no need to turn motor on (main motor-on routine)
{LI} $F9ED: no need to turn motor off
{LI} $FAE0: no need to turn motor on for formatting
{/UL}
{p}
{B}PCR2:{/B} {br}
{UL}
{LI} $F259: initialisation of the diskcontroller
{LI} $F2BB: "Byte ready" is not used anymore
{/UL}
{p}
{B}Formatting{/B} {br}
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. {br}
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.
{p}
{B}Stepping the head{/B} {br}
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. {br}
Then I reasoned that when I know the number of steps, the direction and the
starting track, I could calculate the destination. {br}
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.
{p}
Then I bumped into a small problem. Telling to go to a specified track
immediatly 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. {br}
A bigger problem was the fact that the 1541 extracts the disk-ID from the
header. I have thought about changing all the code reffering to this ID but
then I decided it was much easier to read the BAM first before doing
anything else. {br}
The seven bytes mentioned above are used to store the info needed to emulate
"reading" the track and ID from the header.
{P}
{br}
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| http://Ruud.C64.org
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.1.