Unbranded 5 1/4 inch floppy drive weirdness

[Crashedfiesta]

I've acquired a Torch Triple X and have been trying to use the floppy drive with a Greaseweazle to preserve the disks that came with it.

The drive itself has no branding but is a standard shugart interface set to drive 2. It works - or at least operates - with the Greaseweazle but I wasn't getting good results. I started trying to image some non important disks which work on their target machine but the streams were showing errors and large portions of the disks as unformatted. Unsurprisingly, these images didn't work when written to blank disks.

I tried with a different drive (which was a right pain in the backside to strip out of another machine) and the image files look perfect.

Back to the Torch drive and there is a mechanical arm that seems to be activated by a solenoid which bounces the arm up and down during read/write. If I disconnect the power to the solenoid and try reading a stream from a disk it comes out perfectly. So, what the heck is this bouncing arm and what is it supposed to do??



Video here.

I did wonder if it was some way of lifting the heads of the disk surface but there's already the mechanism there to do that so I'm at a loss as to what it's doing and whether by having the solenoid disconnected I'm damaging something or causing something else not to work properly. The other drive I tried is significantly simpler and doesn't have anything like this.

Any advice gratefully received!

Thanks!

 

[mark0x01]

Sounds like a head load arm, which is used to lift the heads of the diskette when not reading.
It usually loads the head once the motor starts and diskette is rotating, and removes it before motor stops again.

It is possible there is an issue with it or the behaviour might be able to be altered with the jumper settings.

 

[VeryVon]

Agree, head load. However you state there's already a mechanism there to do that?

If it turns out to be head load, and jumper options aren't available, the workaround is typically to wire motor enable to head load (e.g. something like pin 16 on the host side to 18 on the shugart, but check it for your particular setup)

p.s. are you using Greaseweazle or FluxEngine binaries?

 

[Crashedfiesta]

Agree, head load. However you state there's already a mechanism there to do that?

If it turns out to be head load, and jumper options aren't available, the workaround is typically to wire motor enable to head load (e.g. something like pin 16 on the host side to 18 on the shugart, but check it for your particular setup)

p.s. are you using Greaseweazle or FluxEngine binaries?

Yes, I think you're right, it is a head-load mechanism. I misunderstood what the other mechanical bits were doing in there as they were actually just part of the disk release mechanism from the front eject button - I haven't had too much experience with 5 1/4 inch drives!

I'm using the Greaseweazle software (command line) and HxC floppy emulator to look at the images I'm pulling off.

As it turns out this drive is actually an Epson SD540. I found that detail from the Torch Triple X sevice manual that is bzarrely available as a scanned PDF - not what I was expecting for such an obscure British workstation from 1986! And it also turns out that there's a guy on YT who has a video with this drive doing exactly the same as mine. It might be solved with a re-cap so I shall give that a try as I should have most of the caps needed in stock.

Cheers!

 

[syzygy]

Out of curiosity, I searched on the drive and found this video, which is likely the one you mention. The first part of the video and your video certainly do look like the same malfunction.

I don't wish to be too critical, and he does appear to fix the problem (or at least the recapping), but I wretched a bit with the twisting of the caps for removal. Maybe it is simply different than I do it and, as far as I know, that fellow has replaced 1000X the capacitors that I have. Specifically, I would get some flux and solder on the iron, heat the joint and pull up on the cap. The lead begin to slide up - then I clip and repeat. Using a needle nose pliers, the remaining lead fragments come out easily when you hit the other end with the heat.

Maybe I need to be corrected, but is that twisting how you folks do that?

In any event, please let us know how it works out for you.

 

[Crashedfiesta]

Out of curiosity, I searched on the drive and found this video, which is likely the one you mention. The first part of the video and your video certainly do look like the same malfunction.

I don't wish to be too critical, and he does appear to fix the problem (or at least the recapping), but I wretched a bit with the twisting of the caps for removal. Maybe it is simply different than I do it and, as far as I know, that fellow has replaced 1000X the capacitors that I have. Specifically, I would get some flux and solder on the iron, heat the joint and pull up on the cap. The lead begin to slide up - then I clip and repeat. Using a needle nose pliers, the remaining lead fragments come out easily when you hit the other end with the heat.

Maybe I need to be corrected, but is that twisting how you folks do that?

In any event, please let us know how it works out for you.

That's the one. It's not a cap removal technique I would personally use, although for SMD I'm happy to snip them off with side cutters parallel to the pad orientation.

For through hole caps I just add solder and break out the solder sucker.

I'll let everyone know if a recap fixes the issue. This could be that rare instance where it does fix a fault...

 

[Crashedfiesta]

Well, recapping solved the bouncy head load arm for sure.

But I'm still not getting successful writes to disk. I'm using scp as the file type with tracks 0-41 step 2 bitrate of 256. The image looks good now with nothing immediately obvious as wrong. But if I write the image to a disk the Cifer (my test subject) starts up, recognises the format type of the disk and then stops always at track 2 sector 9. Hmmm.

The documentation for the Greaseweazle software isn't great but I thought an scp file is a direct image so assuming my drive is now working OK, why would it not copy the flux correctly onto another disk?



The command I'm using in Greaseweazle is:

$ gw write cpmimage.scp tracks="c=0-39:step=2" --drive=2

Am I doing something wrong?

 

[VeryVon]

Just a suggestion, have you tried using FluxEngine instead? I find their documentation a bit more comprehensive than gw.

 

[Chuck(G)]

Head-load was pretty much the rule on 8" and an option on 5.25" drives. Hook the head-load to the motor control line (you should have a jumper for that).
When I programmed my first 5.25" (Micropolis) head-load drive back in 1977, I couldn't figure out why my writes were dicey. The idea is that it works like 8" drives do--you start the motor, wait a rev or two, load the head and then wait an appropriate (vendor-specified) head-settling time, do your track seek if necessary, allow the head to settle there and finally start the write process. My error was that I wasn't waiting long enough after the head-load. Reading, of course, will always work even if you don't wait for the head to settle because you retry read errors. But floppy writes aren't normally verified.

 

[Crashedfiesta]

So I have to admit that I only did a partial re-cap of the Epson drive as I didn't have all the caps. There are 3 on the bottom board that are non-polarised and I don't have anything like that, as well as some odd values (0.43uf at 50v) which I also didn't have.

It looks like I managed to replace the caps controlling the head loading but, and I'm taking a bit of a guess here, I think some of the ones I couldn't do have something to do with the write head. Looking at the track analyser in HxC the 'read' track stream looks nice and straight and coherent but the written track stream read back in is a bit more loose. I shall go away and try writing that image with the other drive I have that is actually in the Cifer and see if that works.

 

[Crashedfiesta]

Well, shoot. So I tried writing an image that I'd read on the Epson drive on the Cifer drive. Nope - track 2, sector 9 error.

I tried reading in the image from the original and writing it to a new disk, all on the Cifer floppy drive. And I get exactly the same error.

So, by my logic, I must be doing something wrong with the gw command line. Humph.

 

[Crashedfiesta]

Success! Sort of. I defined a disk format to match the Cifer in diskdefs and then read and wrote an IMG file based on that. And it worked! I can boot a copy of the master CP/M disk for my Cifer 1887.

But I'm still puzzled as to why a flux stream read and written back to a disk won't work and always fails with the same error...

 

[Chuck(G)]

Looking at your fourth image, I definitely see head bounce.

 

[Crashedfiesta]

Looking at your fourth image, I definitely see head bounce

Yeah, it certainly looks that way. I noticed that although the arm isn't bouncing and clicking anymore, the movement of it seems a bit inconsistent. Sometimes there's a definite 'click' as it de-activates and lifts the head fractionally at the end of a read/write and sometimes it doesn't seem to have moved at all. It makes me wonder if there are still tiny bounces going on.

But the weird thing is, I read the same CPM system disk on a totally different drive and wrote a copy of that stream to a new(ish) disk on that different drive and I got the same error at the same track and sector. And even more weird, it did exactly the same with other disks too on the same exact track and sector. I'm pretty baffled by it but relieved I managed to define a format for these disks in the diskdefs.cfg file so at least I can preserve .IMG files of the Cifer disks specifically.

 

[Chuck(G)]

What are you using to write those? A real floppy controller or an MCU imitation? Also, if your 5.25" drive is anything like my Teacs, you can simply remove the head-load solenoid assembly. It was an option and the mechanism lifts the head of the medium when not energized.

 

[Crashedfiesta]

What are you using to write those? A real floppy controller or an MCU imitation? Also, if your 5.25" drive is anything like my Teacs, you can simply remove the head-load solenoid assembly. It was an option and the mechanism lifts the head of the medium when not energized.

So I only have the greaseweazle for reading and writing 5.25 floppies. Unfortunately, I don't have a PC setup I can run Imagedisk on, otherwise I'd be having a go with that as per the Adrian's Digital Basement video. The results I'm getting from the writing are inconsistent at best. My workflow is basically this:

Use greaseweasle to read and save .scp file from a disk (to keep for myself as a 'master')
Use Hxc to check that the disk surface looks OK
Use Hxc to convert the scp to an IMD file (not IMG like I mentioned above)
Use gw to write IMD file to another disk

Using this method I managed to get a CPM disk copied that works on the target machine i.e. the Cifer 1887 CPM machine. But this doesn't always work, with the latest thing being a lock-up of the Cifer with no errors or indication of a crash. I wonder if the disk I was using for the write has gone bad. I only have a couple of spare disks and they have been doing a lot of writing/erasing as I've been trying to get my head around all this. If I try and write the .SCP stream data straight back to another disk though. it always fails on the target.

I will be looking to remove the head load arm from my Epson drive too as the operation of it is also wildly inconsistent.