CBMSTUFF FORUM

Full Version: Trouble with very odd 3.5" format
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hi,

I'm trying to image 3.5" floppies from a Tandy Portable Disk Drive (TPDD). It is an odd drive made by Brother for knitting machines that has an RS232 interface. The drive comes in two variations, the TPDD1 stores 100K on a single sided 3.5" DD disk and the TPDD2 stores a whopping 200K. I formatted a new 3.5" DS/DD disk on a TRS-80 Model 100 with an TDPP1. Then I wrote a few files to the disk and made sure I could read them back. So, I know I have a good source disk.

I then make a flux copy with disk type set to 'IBM 1.44', Copy Mode to 'Index'. If I tried to use and analyzer to look at the data from Head 0 it was fine but if I tried Head 1 the SCP software would crash with an 'Error 9 subscript out of range'. (I'm 90% sure that was the error anyhow.)

I then used the SCP to erase the disk, formatted it again on the TRS-80 Model 100 with the TPDD1 and wrote a few files to it.  I then imaged this with the same settings. I can use the Analyzer on this image file without it crashing so I'm guessing the garbage it was reading form the new/raw disk from Head 1 was throwing things off and after erasing it with the SCP it was now reading all zeros which is OK because the TPDD1 only reads the bottom, Head 0, of the disk.

But even though the image was better it still does not work when written back to another new 3.5" DS/DD disk that I first erased on the SCP. 

The drive is not a normal 3.5" drive. It uses a 6800 based MCU (RAM/ROM/UART built in) and a few other chips plus a very simple mechanism. It is also FM encoded. When researching how the thing worked I did stumble across a flux copier project, that I had never heard of before (Flux Engine), that says it can copy these disks with a standard PC drive so I'm guessing a flux copy is not impossible but rather it is just an odd duck and I don't have the SCP software set correctly.

Any help as to other things to try, other settings, etc. would be appreciated. The image I made of the working disk formatted on the TPPD1 is attached.
I have several of the Disk Drive 1 and Disk Drive 2 drives for the Tandy 100/102 computer (and I have several of each of those computers as well). I know that drives were used for knitting machines because they are just simple serial devices. I have these setups so I could emulate the drive with my uDrive product.

These disks can be imaged just fine with SuperCard Pro using 720K disk format. You can read/write the files using HxC. Flux is flux. These are index'd disks.

You could send me your image files (original disk, and an image of the disk you wrote back) to data @ cbmstuff.com. I can look at the images and tell you what the problem is. I would definitely be interested in any image file that generates any type of error message!
(09-30-2020, 06:31 PM)admin Wrote: [ -> ]These disks can be imaged just fine with SuperCard Pro using 720K disk format.  You can read/write the files using HxC.  Flux is flux.  These are index'd disks.

You could send me your image files (original disk, and an image of the disk you wrote back) to data @ cbmstuff.com.  I can look at the images and tell you what the problem is.  I would definitely be interested in any image file that generates any type of error message!

I'm still having trouble so I decided to go back to a known working Amiga WB 1.3 disk to make sure my drive and SCP were working properly. I had some interesting results.

WB1.3 imaged to ADF work fine in Amiga Forever
WB1.3 imaged to SCP does not work in Amiga Forever
WB1.3 imaged as ADF then converted to SCP with HXC works in Amiga Forever

So, perhaps something is wrong with my 3.5" drive that imaging to an ADF sorts out (I did have it set to 2 passes). 
I'll email you the files.

Thanks!
(10-01-2020, 05:21 AM)Jeff_Birt Wrote: [ -> ]So, perhaps something is wrong with my 3.5" drive that imaging to an ADF sorts out (I did have it set to 2 passes). 

After playing with the visualization tools in SCP and HXC it is apparent that my 3.5" drive is unhappy. It was most evident by this disk view image from HXC. When looking at the bit cell timing I can see that the first few tracks are wavy as well. This 'Pac man' effect makes me think there is an issue with the index sensor perhaps?
Just to complete the thought for anyone with a similar issue reading this in the future. I suspect the short red line shown from 0 in the SCP bit cell visualization is the 'Pac Man effect' as shown above.
That short red line is due to the drive not outputting data AT ALL during the start of the rotation.  So, that is a drive issue for sure!

I will say that for standard Amiga formatted disks you have to use SPLICE mode, and that does not work very well for generating working disks.  This is why I added the .adf salvage option.  AmigaDOS does not use the INDEX pulse for starting/stopping tracks.  I was not aware that AmigaForever supported .scp images.  I know that FS-UAE and WinUAE support .scp images, and SPLICE images of standard AmigaDOS disks do work with those.  Almost all commercially produced disks can be imaged using INDEX mode, but any data disks would have to be imaged with SPLICE mode.

None of that will of course fix your drive.  Smile
(10-01-2020, 10:16 AM)admin Wrote: [ -> ]That short red line is due to the drive not outputting data AT ALL during the start of the rotation.  So, that is a drive issue for sure!

None of that will of course fix your drive.  Smile

Well, it is not the drive. I have tried three drives now, different types of 3.5" disks, Amiga, IBM 1.44MB, etc. All of them show the 'PacMan effect' only on head 0 if I create an SCP. Just for the heck of it I tried a different ribbon cable and different USB cable neither of which had any effect, which I did not think they would.

Also just for grins I uninstalled and reinstalled the SCP software old version was 2.20 and new version is the same. This also had ne effect.

I'm still confused as to why if it is a drive or other HW problem it would work in splice mode/making ADFs. If the drive was not outputting data at the start of each track from head 0 then the mode splice/index would not make any difference I would guess because missing data is missing data.

If making SCPs from 3.5" disks is working for everyone else then it has to be my board I guess.
INDEX mode uses a single revolution (always), so if the drive is not outputting data (which is the only way you can get the red line) then you will always be missing data from the beginning of every revolution.  SPLICE mode uses 2 or more revolutions (always), so you could lose the beginning of the first revolution and subsequent revolutions would still have valid data and thus work in WinUAE.  The .adf conversion uses the SPLICE mode.

The red line is caused when data is not immediately flowing from the drive to the SuperCard Pro board.  This can be caused by the drive itself or the power supply.  I have never seen a case where the issue was with the board because this is the flow of the data from the drive itself. When no data is coming from the read head, the captures are 0 length (red).

If the issue is with the motor spin up (which is typically when you see this as a drive problem) reads that are started while the drive motor is already running would not show this issue.  You could use the editor/analyzer to read a track and then while the drive is still spinning read it again and then look at the flux display to see if there is the red line.

Short of damaging the SuperCard Pro board (plugging in an Amiga drive or reversing the cable), I don't think there is anyway possible for the board itself to generate the red line.  In all cases where this has been reported, it has been the drive(s), but I guess anything is possible this year!
Something is really screwy Smile

I just tried using my bench power supply for the drive(s). All the drives I have tested draw about 230ma. Getting the same results. Using the analyzer I can see that Track 0 head 0 is always OK, never a read line. Any track above 0 on head zero I get the red line.

For giggles I reflashed the FW (1.2 to 1.2 w/1.1 HW). Of course no difference.

Out of desperation I grab my laptop and install the SCP software on it. Using the analyzer I no longer see the read lines on head 0! What the...So, I do a full image and it is PERFECT! I uninstalled SCP from the desktop, removed the install folder from Program Files, rebooted, re-installed SCP on desktop, rebooted and...the same problem. On any track >0 and head 0 always starts with a red line.


So, we know the SCP board is OK, the drive is OK, the cables are OK, etc. What in the world on the PC itself can cause this? Obviously I installed the same version of the SCP software on both the laptop and desktop.  I tried using the FTDI CDM to to remove the driver and let Windows reinstall it and still have the same problem. Tried the laptop again and it works fine on the laptop. 

I'm at a loss to understand what can be happening on my desktop to cause this problem but at least I can use the laptop to get a few disks imaged for now.
Did you try a different USB port? This would seem to indicate that there is a USB problem. I did add a USB test in the latest SuperCard Pro software. Have you tried running it? You can find in the editor/analyzer program, under the Misc.Options pull-down menu.
Pages: 1 2