Hallo allemaal,
You can please me with an opinion or comments on an idea. For Steve, is this
interesting enough for C=hacking? (there is more on this subject then what you
can read here)
As you know, I succeeded in connecting a IDE-HD to a C64. The biggest
problem was writing the file handling system. The huge amount of work
involved was one of the reasons I stopped any further development. Another
reason was that I discovered that there was a much easier way to connect an
"harddisk" to the 1541 and the only needed hardware is a piece of cable, a 25
pins male D-connector and a PC (IMHO 386, maybe 286 will do).
All data coming from/going to a floppydisk plus the signals to steer the
mechanics and some other minor functions go thru one single 6522 (UC2).
PA0..7 (pin 2..9, bidir.): used to transfer data
CB1 (pin 18, in): not used
CB2 (pin 19, out): direction of the data (H: read, L: write)
PB0..1 (pin 10..11, out): lines to steer the steppingmotor
PB2 (pin 12, out): motor on/off
PB3 (pin 13, out): LED
PB4 (pin 14, in): write-protectionn detector
PB5..6 (pin 15..16, out): lines to select density
PB7 (pin 17, in): synchronisation-byte detected
CA1 (pin 40, in): Byte Ready
CA2 (pin 39, out): disable Byte Ready
PB5 and PB6 fix the distance between pulses used to write/read single bits
to/from a floppy. The distance varies from 3.25 to 4 uSec.
A counter counts these pulses and activates the "Byte Ready" signal every 8
pulses. This is the signal which tells the processor a byte has been
written/read. This signal is also connected to the SO-input of the 6502.
10 or more 1 bits in a row form a "Synchronisation byte" (Sync). The moment
a Sync is detected during reading, the "Byte Ready" stops counting. The
very first 0 bit read from the floppy disactivates the Sync-signal and
starts the counter.
CA2 disables the "Byte Ready" signal. To be honest, I have no idea why it
needs to be disactivated from time to time. When anybody knows, please tell
me.
IMHO the other lines don't need further comment.
My idea is to disconnect the above pins (except PB3) and to connect them to
the LPT-port of an PC.
6522 LPT
Name Meaning pin name pin
---- ------- --- ---------- ---
PA0 2 D0 2
. .
. .
PA7 9 D7 9
CA1 BRDY 40 Strobe 1 (O)
PB7 SYNC 17 Auto feed 14 (O)
PB4 WPE 14 Initialise 16 (O)
PB0 Stp1 10 Select 13 (I)
PB1 Stp0 11 Paper out 12 (I)
PB2 Mtr 12 Acknowl. 10 (I)
CB2 Mode 19 Busy 11 (I)
CA2 SOE 19 Error 15 (I)
As you can see, PB5 and PB6 are NOT connected because, IMHO, they are not
needed. I know some programs change the density during writing a track as a
protection. Copy programs not knowing of this change will read errorous
bytes because bits are read double or skipped. But the fact remains that
even these protected programs must present the data to port A where we can
read it. When neede we present the same data to port A and the program only
can think that it is the original data.
OK, I can dream up two schemes which could detect the fact that I'm faking the
read/write proces but I count on the simple fact that programmers did not
consider the fact that someone was hacking the drive itself. Further
comment is welcome.
The rest of the idea is obvious: the PC now must emulate the parts we
"removed"; it must read the data send by the 6522 and store it, and it must
send stored data to the 6522 as if it was coming from a real floppy. Timing
is important but not critical. A complete byte takes 26-30 uSec. The
routine to read a byte needs 20 cycles for a loop (see $F4D4). IMHO a PC
must be able do deliver a byte in 26 uSec. Writing a byte costs 20 cycles
as well (see $F5BF).
By monitoring PB0 and PB1 the PC will know when "to change track". The real
drive needs a lot of mSec so the PC can take its time to fill a block RAM
(IMHO only 8KB) with the data of that track. My idea is anyway to let a
drive think that, after powering up or "changing" the floppy, the head is
above track 18.
I have much more facts, data and ideas on this subject but I think there is
already enough to discuss about for the moment.
Groetjes, Ruud
-
This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tcm.hut.fi.
Archive generated by hypermail 2.1.1.