LisaList2

With ESFloppy now released and its creator having Twiggy interface details freshly in mind, there is no better time to ask AlexTheCat123 (and anyone else who might know) the following question:

How much effort would it take to make an adapter board that adapts a Twiggy drive to a PC-style 34-pin Shugart interface?

My guess from looking at the Twiggy connector is that you'd need a small microcontroller to do some of the work of generating the stepper motor signals and strobing MCLK at the appropriate speed.

My reason for wondering is because it seems like it would be nice to be able to plug a Greaseweazle, an Applesauce, or some other kind of flux reader into a Twiggy and take flux recordings of a Twiggy disk. People have tried to make flux recordings of Twiggy disks with ordinary floppy drives connected to one of these devices, but this approach is challenging owing to the odd track pitch in Twiggies. I think few people have considered this alternate approach because Twiggy drives are of course quite rare.

I am not certain if the R DATA that comes out of a Twiggy is more cooked, less cooked, or about the same as the data signal that comes over a Shugart interface.

I'm not super familiar with the Shugart interface, but yeah, I think the bulk of the work would be converting the DIR and STEP lines into stepper motor phase pulses and sending the drive motor speed values on PH0 (with MCLK as the shift clock) whenever we move across speed zone boundaries. And I guess you'd also need the microcontroller to periodically go through the different PH0/HDS combinations to get each of the status signals out on SNS (track 0, write protect, disk in place, and eject button latch). The only thing that I can think of (with my limited knowledge of the Shugart interface) that you'd not be able to get is an index pulse, but I bet you could modify the Greaseweazle firmware to not require this.

I have a Gotek (shugart interface) adapter for the Apple II Floppy interface (similar to the twiggy interface).

Here is the pinout:

        Apple II floppy interface <------------------> Gotek floppy interface
        (Internal 20pins / Ext DB-19)

PH0    (Int pin  2 / DB19 pin 11) <------------------> UART RX Pin (J4)
PH1    (Int pin  4 / DB19 pin 12) <------------------> UART TX Pin
PH2    (Int pin  6 / DB19 pin 13) <------------------> /DIR   (18)
PH3    (Int pin  8 / DB19 pin 14) <------------------> /STEP  (20)
/WREQ  (Int pin 10 / DB19 pin 15) <------------------> /WGATE (24)
SEL    (Int pin 12 / DB19 pin 16) <------------------> /SIDE1 (32)
/DRVEN (Int pin 14 / DB19 pin 17 or pin 9 *) <-------> /DS0   (10)
RD     (Int pin 16 / DB19 pin 18) <------------------> /RDATA (30)
WR     (Int pin 18 / DB19 pin 19) <------------------> /WDATA (22)
WRPROT (Int pin 20 / DB19 pin 10) <------------------> /WPT   (28)

Power :

VSS/GND (Int pins 1,3,5,7 /
                DB19 pins 1,2,3 ) <---------> Gotek VSS power input (Power pins 2, 3) +
                                              Gotek floppy interfaces pins 33, 27, 23, 21.

+5V     (Int pin 11 / DB19 pin 6) <---------> Gotek +5V power input (Power pin 1).

Quote from: Lisa2 on Yesterday at 01:03:11 PMI have a Gotek (shugart interface) adapter for the Apple II Floppy interface (similar to the twiggy interface).

Here is the pinout:

        Apple II floppy interface <------------------> Gotek floppy interface
        (Internal 20pins / Ext DB-19)

PH0    (Int pin  2 / DB19 pin 11) <------------------> UART RX Pin (J4)
PH1    (Int pin  4 / DB19 pin 12) <------------------> UART TX Pin
PH2    (Int pin  6 / DB19 pin 13) <------------------> /DIR  (18)
PH3    (Int pin  8 / DB19 pin 14) <------------------> /STEP  (20)
/WREQ  (Int pin 10 / DB19 pin 15) <------------------> /WGATE (24)
SEL    (Int pin 12 / DB19 pin 16) <------------------> /SIDE1 (32)
/DRVEN (Int pin 14 / DB19 pin 17 or pin 9 *) <-------> /DS0  (10)
RD    (Int pin 16 / DB19 pin 18) <------------------> /RDATA (30)
WR    (Int pin 18 / DB19 pin 19) <------------------> /WDATA (22)
WRPROT (Int pin 20 / DB19 pin 10) <------------------> /WPT  (28)

Power :

VSS/GND (Int pins 1,3,5,7 /
                DB19 pins 1,2,3 ) <---------> Gotek VSS power input (Power pins 2, 3) +
                                              Gotek floppy interfaces pins 33, 27, 23, 21.

+5V    (Int pin 11 / DB19 pin 6) <---------> Gotek +5V power input (Power pin 1).

This direct connection brings up a good point; you could always just reprogram the Greaseweazle/Applesauce to handle the phase lines and motor speed stuff internally instead of expecting it to put out stock Shugart signals and having an external microcontroller do all the conversion work.

The index pulse issue is the real challenge, I think. I should have known better --- it's Apple after all. Index pulses just aren't their thing, are they?

It might not be impossible; it just depends on the precision of the Twiggy's spindle speed control. If it's absolutely bang-on, like a watch, then the flux imager's control software can "fake" an index pulse (i.e. just basically guess where it should go), but you need to have measured the drive's rotational speed fairly precisely for this to work.

If speed control not so great (e.g. it's off from true by some percentage fraction), then we're in research territory basically. All flux imagers that I know seem to prefer an index pulse to, well, index the data they're flux-imaging with certainty. For the Applesauce imager, which like the name suggests is designed to image Apple disks, it's able to do without if you're trying to read data bytes from a disk with a mostly-readable, known format. But if you want to go beneath the format and the bytes and collect raw flux timings, as you need to do when you don't have a familiar format or when you're trying to defeat various copy protection schemes, then the imager needs to know your angular location on the disk. That's why you need a sync sensor mod to flux-image with the Applesauce. You could adapt one of these to a Twiggy drive and use the same gimmick, but I'm not in a rush to do that! Alternative approaches then include introducing something like autocorrelation for aligning multiple reads from the same track, and while it's not that radical a solution, it does leave us in research territory, as I said.

This aside, I'm also not in a big rush to introduce new custom firmware to the Greaseweazle. The Greaseweazle firmware and control software is good: it's stood the test of time and it's actively maintained and improved. I'd rather take advantage of all that ongoing work if I can. Some change may be necessary to handle zoned changes in rotational speed, but I might hope that it's easier to add this to the existing control software than to make an all-new stack on the same hardware.

But again, owing to the indexing problem, this thinking may all be fairly academic!

Maybe one last question for Twiggy experts. Suppose you try to read one of the tracks at the "wrong" RPM, if that's even possible: let's say that we read the innermost track at the same slower speed of the outermost track. Disk data may comes out wonky, but do you get signs of any signal at all or does it look distorted or blank? I'm wondering if it would be possible to flux image an entire Twiggy disk at a single rotational speed, which simplifies the control software side of things and may mean that (if you could magic up an index pulse somehow) you can use the stock Greaseweazle software.

Quote from: stepleton on Yesterday at 03:38:24 PMIt might not be impossible; it just depends on the precision of the Twiggy's spindle speed control. If it's absolutely bang-on, like a watch, then the flux imager's control software can "fake" an index pulse (i.e. just basically guess where it should go), but you need to have measured the drive's rotational speed fairly precisely for this to work.

I've never laid eyes on a real Twiggy drive, much less used one, but from what I've gathered in my research the speed control isn't all that great. Twiggy is basically identical to Sony in terms of disk encoding, except that there's a "track -1" speed calibration track and "speed sync bytes" before sector 0 on each track for calibrating the disk's rotational speed, and the fact that Twiggy needs any of this at all doesn't really bode well for the accuracy of its speed control.

Quote from: stepleton on Yesterday at 03:38:24 PMMaybe one last question for Twiggy experts. Suppose you try to read one of the tracks at the "wrong" RPM, if that's even possible: let's say that we read the outer track at the same slower speed of the inner track. Disk data may comes out wonky, but do you get signs of any signal at all or does it look distorted or blank? I'm wondering if it would be possible to flux image an entire Twiggy disk at a single rotational speed, which simplifies the control software side of things and may mean that (if you could magic up an index pulse somehow) you can use the stock Greaseweazle software.

Once again, no experience with real Twiggy drives, but the flux pulses would theoretically just come out faster or slower than they're supposed to but still be perfectly readable if you knew how fast or slow they're supposed to be coming. So instead of each bit being 2us wide, maybe it would be 1us wide or 3us wide depending on the speed of the disk.

Quote from: stepleton on Yesterday at 03:38:24 PMThe index pulse issue is the real challenge

The flywheel on the drive is easily accessed, so it would be easy to generate an index pulse using a reflective or inductive sensor.

QuoteSuppose you try to read one of the tracks at the "wrong" RPM, if that's even possible ... do you get signs of any signal at all or does it look distorted or blank? I'm wondering if it would be possible to flux image an entire Twiggy disk at a single rotational speed, which simplifies the control software side of things and may mean that (if you could magic up an index pulse somehow) you can use the stock Greaseweazle software.

Yes, one can read at the wrong RPM. When a bad sector is found when reading a Twiggy, BLU offers "read varying speed" and you can hear the speed change as you alter the value. On rare occasions a small offset in speed can make the bad sector readable. More than small offsets results in the FDC not being able to find anything, but there is still a bit stream.

I think one could read the whole disk at the median speed. To read disks faster, I considered using the PFG to alter the speed of the FDC to compensate for a fixed rotational speed to allow reading both sides without the speed change delay and figured the range was just barely enough. I figured there aren't enough Twiggies left to read to recover the development time for such a feature.

However, and just IMHO, I don't think preserving flux data from Twiggies is particularly valuable, as no Twiggy disks are known that use something other than the normal format. Flux data might help recover partial data from an unreadable sector, but I'd guess one would want amplitude data for that, not just timing. Regardless, if someone wants to obtain Twiggy flux data, I'd be happy to help.

The applesauce team have reported that they have imaged twiggy disks exactly as you surmised, reading at a constant RPM and "fixing" everything in post production.
The how-to was on their discord channel. I was just happy to hear it's possible, I have a twiggy disk that needs to be imaged.

Quote from: Jacexpo on Today at 12:02:53 AMThe applesauce team have reported that they have imaged twiggy disks

That's awesome (and a very impressive effort overall).

Although, I think stepleton was looking forward to the challenge, so we need to find something else for him to dig his teeth into... ideas?

I was aware of the Applesauce folks saying that they did that, and the software does have some provisions for it. (I actually have an Applesauce device myself.) I can't find a how-to doc on their discord at the moment, but I did see this when I search for "twiggy":

QuoteDisk Blitz
 —
17/03/2026, 17:49
I was working with Tony Diaz on connecting an AS up to a Twiggy drive, but he passed before the work was completed. It is possible to do. The imaging (and writing) of the Twiggy disk format is complete and in the app. The fast imager hack that I never shipped was the scavenging that it would do to find sectors on neighboring tracks due to the head misalignment problem.

Great minds think alike, I suppose; if I wanted to continue this project, I should probably get in touch with them. The topic had come up because the conversation turned to imaging Twiggy disks with PC hardware, where you see stuff like this:

QuoteLord Nightmare
 —
17/03/2026, 16:21
I don't have [a twiggy disk], i have like 6 of them, and I imaged them in the applesauce and it wasn't very pretty.
it MIGHT be doable in a 160track drive or even a 'deliberately loose head' 80 track drive where you image each track from steeping upward and then downward
since the head if it can shift about half a track due to the alignment screw being left slightly loose or having a rubber washer added between the screw and spindle to intentionally give it some 'play'...

Bitsavers' Al Kossow had earlier suggested, though, that you need to microstep with quite a high resolution if you want the best odds of getting data:

Quotebitsavers
 —
17/03/2026, 16:06
You are still %15 off even with a 200step motor. 62.5 tpi was just such a stupid number

So, noting the dates, I don't think the track pitch problem is solved yet. A Twiggy drive is probably still the best mechanism for flux-imaging Twiggy disks. There may not be many out there, but there could be a few where it's really important to the owner to get the data off, and having transitions really does help in desperate cases. (An analog recording would be even better, though you don't see this so much in the disk recovery community, maybe because it needs even more specialised equipment.) Lastly, there may not not be many: elsewhere in the thread, Al talks about potentially needing to image 1,000 of them.

I do like a challenge, but these days I actually have a different disk backup challenge to keep me busy. I was more inclined to ask now because Alex had just completed ESFloppy --- I thought it would be good to ask about the idea when it was fresh in more peoples' heads than usual. In other words: I'm unlikely to get to this soon.