Searching \ for 'Diskette Controllers, Only Remotely PIC Related' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Diskette Controllers, Only Remotely PIC Related'.

Truncated match.
PICList Thread
'Diskette Controllers, Only Remotely PIC Related'
1997\07\09@205755 by Martin McCormick

flavicon
face
       As a learning exercise, I am trying to read the data on the hidden
sector of a copy-protected disk.  It is one of those schemes where the last
sector of a track has been marked bad and given an odd set of address marks
so that diskcopy and diskcomp, among common applications will not work.

       Is there any way to trick the controller in to reading the address
marks at the beginning of a sector?  One possible idea might be to tap in
to the serial data as it comes down the cable from the drive to the
controller.  This is where a PIC might come in handy for decoding the bit
stream.

       To share what I have learned so far, each track of a quad-density
1.4 meg floppy is composed of 18 sectors.  A cylinder is both sides of the
disk or 36 sectors.  The tracks on one side are called "head 0" and those
on the other side are head 1.  There are four bytes at the beginning
of each new sector that contain the cylinder, head, sector number, and a
byte that tells whether the sector contains 128, 512, or 1024 bytes.

       Dongles usually put an odd-numbered sector in a track to break the
diskcopy mechanism which is looking for 18 neatly-numbered consecutive
sectors.  It is also possible to change the head and cylinder values in the
address marks for the obscured sector such that one has a huge number of
combinations to try if the trial-and-error method is used.  Being able to
get a peek at the address marks of the next sector would allow one to at least
know what needed to be done next.

       So far, I know how to format a disk with an odd sector so I could
make a dongle if I wanted to, but I am trying to figure out a way to hack
the reading process to give me the raw disk data so as to avoid the possibility
of wearing out the disk by thousands of reads to the same portion while
trying all possible combinations.  Any ideas besides just giving up are
appreciated.

       Several weeks ago, the topic of using floppies as extra memory
for PIC's came up.  I think a PIC might do certain dedicated functions like
running the stepper or possibly decoding certain data, but the control
needed to run a disk controller is probably more suited to a full-fledged
CPU due to memory buffers and lookup tables.

       Again thanks for any ideas or hacks such as ports to look at or
buffers that might have the full sector, marks and all.  When this is all
over, I will know what makes a disk drive tick and I will have a clone of
the disk in question for backup purposes.

Martin McCormick

1997\07\10@032803 by Mike

flavicon
face
>        Again thanks for any ideas or hacks such as ports to look at or
>buffers that might have the full sector, marks and all.  When this is all
>over, I will know what makes a disk drive tick and I will have a clone of
>the disk in question for backup purposes.

Wouldn't it be easier to hack the program which reads the disk ?

I have an old 27C256 EPROM programmer which needed a 5 1/2" floppy, so the
EPROM programmer couldn't be copied. All I did was hack the program which
went to look for the floppy when it started. I no longer need the floppy
and can even retrieve the program from a network - as long as the hardware
is in the client system.

Rgds

Mike


Some say there is no magic but, all things begin with thought then it becomes
academic, then some poor slob works out a practical way to implement all that
theory, this is called Engineering - for most people another form of magic.
                                                                      Massen

1997\07\11@002915 by Mike Smith

flavicon
face
MikeS
<spam_OUTmikesmith_ozTakeThisOuTspamrelaymail.net>

----------
> From: Martin McCormick <.....martinKILLspamspam@spam@DC.CIS.OKSTATE.EDU>
> To: PICLISTspamKILLspamMITVMA.MIT.EDU
> Subject: Diskette Controllers, Only Remotely PIC Related
> Date: Thursday, 10 July 1997 09:49
>
>         As a learning exercise, I am trying to read the data on the
hidden
> sector of a copy-protected disk.  It is one of those schemes where the
last
> sector of a track has been marked bad and given an odd set of address
marks
> so that diskcopy and diskcomp, among common applications will not work.
>
>         Is there any way to trick the controller in to reading the
address
> marks at the beginning of a sector?  One possible idea might be to tap in
> to the serial data as it comes down the cable from the drive to the
> controller.  This is where a PIC might come in handy for decoding the bit
> stream.
>
>         To share what I have learned so far, each track of a quad-density
> 1.4 meg floppy is composed of 18 sectors.  A cylinder is both sides of
the
> disk or 36 sectors.  The tracks on one side are called "head 0" and those
> on the other side are head 1.  There are four bytes at the beginning
> of each new sector that contain the cylinder, head, sector number, and a
> byte that tells whether the sector contains 128, 512, or 1024 bytes.

Isn't there a track read / write command?  I think that's how the old
CopyWrit type programs got around some of them.  Then there were the ones
with a laser zap on a given track.  I dread the thought that companies are
still seriously using them or considering using them - they made life a
nuisance for legitimate users, and were no problem for pirates.  The hard
drive install system with the fixed location on the hard drive were a
nuisance too - and I doubt would work on compressed or NTFS drives.

>
>         Dongles usually put an odd-numbered sector in a track to break
the
> diskcopy mechanism which is looking for 18 neatly-numbered consecutive
> sectors.  It is also possible to change the head and cylinder values in
the
> address marks for the obscured sector such that one has a huge number of
> combinations to try if the trial-and-error method is used.  Being able to
> get a peek at the address marks of the next sector would allow one to at
least
> know what needed to be done next.
>
>         So far, I know how to format a disk with an odd sector so I could
> make a dongle if I wanted to, but I am trying to figure out a way to hack
> the reading process to give me the raw disk data so as to avoid the
possibility
> of wearing out the disk by thousands of reads to the same portion while
> trying all possible combinations.  Any ideas besides just giving up are
> appreciated.
>
>         Several weeks ago, the topic of using floppies as extra memory
> for PIC's came up.  I think a PIC might do certain dedicated functions
like
> running the stepper or possibly decoding certain data, but the control
> needed to run a disk controller is probably more suited to a full-fledged
> CPU due to memory buffers and lookup tables.

Use serial ROM - it'll end up being a lot easier to manipulate, and you
could still use some fancy coding to protect it.

MikeS
<.....mikesmith_ozKILLspamspam.....relaymail.net>

1997\07\11@181023 by David Jeffers

flavicon
face
Like you I have thought about using a disk drive with a PIC.. Look in
some old computer books on the mega-ton type IBM tube type.  What
thay did is chopped up the program into little pgm's and swapped them
along with data back and forth to the disk... or I mean drum.  I have
always liked the way Apple Computers did it on the Apple II .. they
literally yanked out the guts of a disk drive and let the CPU do the
controling of head etc.  Although it would be a noval project maybe
using a big serial EEPROM on a card that could be taken out and
saved like a disk....maybe the design could have several slots for
these cards...for copying etc....

David Jeffers
OSP Technologies, Inc.


{Quote hidden}

1997\07\11@182911 by Lee Jones
flavicon
face
> As a learning exercise,

I don't care why you're doing it.

> I am trying to read the data on the hidden sector of a
> copy-protected disk.  It is one of those schemes where the last
> sector of a track has been marked bad and given an odd set of
> address marks so that diskcopy and diskcomp, among common
> applications will not work.
>
> Is there any way to trick the controller in to reading the address
> marks at the beginning of a sector?

It's been years since I talked directly to a floppy disk controller.
As I recall, IBM used the NEC 765 FDC chip for the PC (thus casting
the functionality in "stone").

If I recall correctly, there are read track and write track functions.
Write track is used to format a floppy.  Read track loads everything
that passes under 1 head during 1 revolution into a buffer.  You can
then disect it to your hearts content.

> One possible idea might be to tap in to the serial data as it
> comes down the cable from the drive to the controller.

You could.  Again based on my memory, the data rates were 250Kbps
(double density) and 500Kbps (quad or high density) using an MFM
encoding.  Even if not MFM, the bit encoding was not esoteric.

Even at 20MHz, a mid-range PIC would be hard pressed to read
the data stream directly.  But you could add external hardware
to support the MFM decoding into octets.  Or use a Zilog 8530
SCC (serial communications controller) to do the MFM decode
and present the PIC with octets.

I think the FDC in read track is easiest.

> To share what I have learned so far,

This is all well documented in the old floppy disk controller IC
data sheets.  Western Digital had several models for 8"/5" and
5"-only.  3.5" high (aka quad) density is the same data rate as
8" high density.  Hardest part now is finding the old data sheets.
Mine are tucked away somewhere...

                                               Lee Jones

1997\07\12@232527 by Lee Jones

flavicon
face
>> Several weeks ago, the topic of using floppies as extra memory
>> for PIC's came up.

> Like you I have thought about using a disk drive with a PIC
> I have always liked the way Apple Computers did it on the
> Apple II .. they literally yanked out the guts of a disk
> drive and let the CPU do the controling of head etc.

The CPU may not have anything else to do when running the
Apple II's operating system.  But on real operating systems
with pre-emptive multitasking, tying up the CPU for the
duration of all I/O operations is criminal.

It's cheap -- not cost effective.

> Although it would be a noval project maybe using a big
> serial EEPROM on a card that could be taken out and saved
> like a disk....maybe the design could have several slots for
> these cards...for copying etc....

Sure sounds like you're describing PCMCIA.  Small, removable
card with non-volatile storage; multiple slots; etc.  Recall
that PCMCIA stands for PC _memory_ card industry association.

                                               Lee Jones

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...