Jump to content
cwilbar

SuperCard Pro check media failures

Recommended Posts

So for anyone interested, here are 2 index reads of a media test write.  I hit ignore on every error of the media test process.

The write was done with a TEAC FD-54B.  I've attached 2 index reads here, one read back with the FD-54B, and one read back with my Panasonic JU-465 (If I recall the model correctly).

If useful at all, I could do a media test on the Panasonic and do a read with the FD-54B.

 

I'll e-mail these to Jim as requested.

 

 

media_fail_read_with_pana.scp media_fail_read_with_54b.scp

Share this post


Link to post
Share on other sites
Posted (edited)

So, it seems that you should run to the trash can with your FD-54B drive in hand and deposit it.  :)

 

That drive is the issue, not the media.  You already confirmed that yourself by doing the media test with the same disk on a different drive, which passes.  There are some very severe and seemingly random drive speed issues with that drive.  You will never be able to use that drive for making images or copies of disks.  I loaded your files into SCP's editor/analyzer and clicked on the FLUX DISPLAY button to show the flux graphically.  You should see a straight line of flux data like this:

 

good.thumb.jpg.33b4e7bb6df3ae4d10101898d3f393b9.jpg

 

 

For some of those tracks that you had to ignore (and there were a lot of them!), they were like this:

 

fail1.thumb.jpg.44881e4ca4c6195d8fc04c151b629fa2.jpgfail2.thumb.jpg.50230a57c7f14b4eb5de66888095466b.jpgfail3.thumb.jpg.a4f6e9917165335e18b76a93d05fd835.jpgfail4.thumb.jpg.13a713a178c31b2475e7c3af5bf670f5.jpgfail5.thumb.jpg.efb6b4f3be6e14d4e298f01e501c23d9.jpg

 

These lines not being perfectly flat can only be caused by drive speed variations.  That CAN be caused by the disk being too tight in the jacket to be easily turned by the motor, but you would hear the disk making a loud "swoosh swoosh swoosh" sound as it spins.  I have seen this before with drives that are not properly powered (12V).  Maybe this drive uses more current for it's motor than the JU-475 does, or what your power supply can handle.  You could measure the 12V supply to the drive when the motor is spinning (with a disk in) and see if it is stable.

 

 

 

 

 

Edited by JimDrew

Share this post


Link to post
Share on other sites
Posted (edited)

So, what I need to do now is add an option that checks the drive speed variances vs. the flux data to determine when the problem is really media related or drive speed related.  Have you tried doing the drive speed test?

 

Edited by JimDrew

Share this post


Link to post
Share on other sites

I do not believe I had done the speed test, or if I did it was a quick spot check, and might have been fine at the time of testing.

 

On the non flat waveforms, were they present in both the pana and fd54 files.  While the FD did the writing, the 2 files represent an image taken with the FD54 and one taken with the JU465.

 

If the speed wavering happens in read and write, I'd suspect it would be worse in the fd54 read (as there could be variance from read and from write) vs the JU465 read which would only detect the write variances.

 

The enclosure the drive is in is an old Andatco box meant for 2 5.25" HH or 1 5.25" FH SCSI drive(s).  It is the same enclosure that is now powering the JU465.  I suppose the 12V could be noisy.  I could always try it on another supply.  If that doesn't change anything, then something is up with the motor control.  There are a number of Nichicon caps on the motor control PCB.  maybe they aren't up to snutff anymore ?

 

Share this post


Link to post
Share on other sites
Posted (edited)

I thought about this some more and then it dawned on me that I can use the index time vs. the bitcell times to determine the drive speed stability.

 

So, as a recap - you did the media test and it passed on the JU-475.  You then did the media test and it failed with the FD-54B drive.  You created image files of the failed disk with the JU-475 and the FD-54B drive.  Both of those image files have the exact same bad data.  The index time vs. bitcell time varies from a few hundred nanoseconds to just a couple of microseconds, well within the normal realm of drives.  The index time is the time that goes by from index to index (one rotation of the disk).  The bitcell times is the total amount of time of all of the bitcell times added together.  In a perfect world, the index time and bitcells time would be identicall.  So, I don't believe you have a speed problem after all.  This looks like something done electronically, like the drive electronics glitch during the write.  SuperCard Pro does everything on the board itself.  It doesn't actually need a USB device to spool flux data.  The USB is just used as a glorified serial port (it's actually a parallel to USB interface).  So, this is not a USB transfer error.  It could very well be that your caps are an issue, but I don't think it would be the caps on the motor unless this problem goes away when the drive has been on and working for awhile, then maybe the reads and writes would be normal.  There are lots of variables here, but my best guess after looking at this all again this evening is that something is bad in the write circuitry of the FD-54B drive.  Personally, I would not waste my time with the drive and find another one.  You could be chasing this problem forever and drive yourself nuts.  The JU-475 drives are the absolute best drives you can use for imaging *any* 5.25" disk format.  Don't let people try to sway you with myths about 48TPI drives reading "better" because the head is wider.  That is nonsense.  I get far better recovery out of 96TPI drives.

 

Edited by JimDrew

Share this post


Link to post
Share on other sites

I wouldn't concern myself with reads using a 96TPI drive too much.... but much prefer to write 48tpi disks using 48tpi drives.

 

I would imagine that there is no choice to do this when half tracks are involved (C64, Apple).... as you can't half track a 48tpi drive (correct ?).  In which case, I'd do a bulk erase and then a write with a 96tpi drive.

 

Interesting question (not related to my 'lazy' FD-54B).... can QD drives be used with SCP ?  Or will assumptions be made that a 96TPI drive is a 1.2M drive ?  (I think I have 4 different 96TPI QD drives (including an MPI 'big door' style drive like in the 810).

 

Thanks Jim !

 

-- Curt

 

Share this post


Link to post
Share on other sites

Any drive (including hard drives and tape drives) that uses a 34 pin interface and adheres to the floppy standard should work with SuperCard Pro.  I have 2.88MB 3.5" drives that I have successfully used.

 

  • Like 1

Share this post


Link to post
Share on other sites

Thats cool.  From a flux detection perspective, I think the only difference between QD and HD drives would be that QD drives will be running at 300RPM (vs 360RPM).

 

@JimDrew thanks for a terrific product.  I had a learning curve, and ran into two drive issues (a Toshiba 360K which worked great but went flaky and became unreliable, and the FD-54B TEAC which seems to be writing at a drifting speed/bit rate/etc...).  I will plan to try that TEAC on another power supply in case it is a power hungry drive that is sapping the old power supply in the Andatco enclsoure.... but I think it is most likely the drive.

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...