Microstepping support for 100tpi disks: update: now with actual feature request

[auron]

Sorry this whole post is a bit lengthy because it already contains a private conversation...

The threads Commodore 8050 and We need to go deeper suggest mcrostepping is a solution to reading 100 TPI disks, so I PMed ZrX about the status. I'll copy the conversation with kind permission to reflect my current knowledge.

Hi ZrX,

I read your post about using a microstepping driver instead of the original
driver.
viewtopic.php?f=7&t=768&p=7509

Do you have any deeper documentation about that, and did it actually
improve anything?
Is the modified firmware for the kryoflux public?

The reason I'm asking is i have some old Commodore PET disks, presumably
written with an CBM 8050 or CBM 8250, and thus 100 tpi.
Microstepping seems to be the only solution with my 96tpi drive. Is 4 times
the resolution enough to hit the tracks would I need an even higher
microstepping factor, maybe 8 or 16?

And the answer by ZrX:

I have actually read few 100 tpi disks that were sent to me to test the microstepping modification with and was able to reconstruct two working Commodore format disk images from the data, so 4x is enough for that. I'd prefer to modify some drive with an actual 100 tpi stepper motor.

The drive I modified was one of the Panasonic models, and the microstepper driver I used is called EasyDriver. I tried the same with a Newtronics mech with the EasyDriver and also with a Pololu microstepper driver, but that didn't really work for some reason. Didn't test the Pololu on the Panasonic tho.

There are some issues with the Panasonic: Most drives do a self-test when powered up and Panasonic locks up if the test fails, so some functions of the drive need to be bypassed.

The modified firmware is also quite a hack, as it doesn't return the r/w-head back to track 0 at the end of the dump as DTC needs to be run four times to fully read the disk. And track 0 accuracy becomes somewhat random with the microstepper, so reading doesn't always start at the same position, requiring custom software to walk through all the data.

There have been internal discussions about how to maybe support microstepping, but no idea yet how to really work out the current issues.

My crazy ideas are currently the following:
To avoid changing the internal logic of the drive I'm about to create a plugin board with an Arduino Nano and an A4988 microstepping driver that would plug directly into the motor output of the floppy board and itself driving the motor.
I plan to use a simple voltage divider to read the current status from the four input lines and determine of it turns left or right issuing a microstep advance to the A4988.
The power would be provided by a Y-cable from the same source that powers the Floppy.
On bootup the nano would issue 4 microsteps for each detected step, so the drive firmware would ideally not notice any difference.
DTC, (or something else) could then turn on the 1/4 step mode, be it by serial console command or extra input line, or even manual pushbutton.

Advantages of going this route as I see them:
[*] No need to modify the drive, possibly breaking the alignment.
[*] would possibly work with quite a range of hardware
[*] The nano could translate the steps, so DTC would see the correct track- no big changes necessary to to elimiate "extra" tracks
[*] if DTC somehow integrates with this, track-alignment issues could be auto-detected and corrected. e.g. when hitting error tracks.

Trouble I see ahead:
[*] might have to insert two Mosfets to delay the powerup of the drive (+5V and +12V) until the nano is ready.
[*] Don't know if some drives already do microstepping. That would make detection much more complicated.
[*] Microstepping is probably not too exact, so I don't know about reproducability.
[*] as per ZrX, would need support by DTC to fully read the drive in high-res mode.

So, please hit me: I'm open to any thoughts.

Tobias

P.S.1: I wanted to upload my board schamatics, but seemingly i don't have quota for adding uploads.

P.S.2: A little semi-off topic:
The A4988 will be current limited to 330mA as that seems to be what the chip on the current board is delivering. I could not find any documentation on the A13421P chip used, but the internet links to an HA13421A chip by Hitachi which was designed for floppy drive use. Does anyone have more info on that?

[brightcaster]

This is a bit off topic, but I once had a few C64 disks that had been written with a completely misaligned 1541. I sacrificed a Panasonic ju475 for that and slightly loosened the two screws on the spindle mount, set the GUI to 30 retries and levered the spindle mount back and forth in the oblong holes with a small screwdriver until the boxes in the GUI turned green! I had to do that for every track again, since the position obviously changed a bit with every stepper movement.

I guess that this should work the same with 100tpi, if you have enough patience. If you are too far from the right point a T appears in the corresponding field of the GUI to indicate that you have landed on a neighboring track.

Of course that only makes sense if it's just a few floppies to transfer and you have a drive left over what you're willing to sacrifice for this purpose (as I never got the drive realigned after that)!

David

[auron]

I cannot rationally explain this, but I'm somehow totally afraid of loosing the alignment. Maybe, because my drive is currently in a working state, and the analog alignment disks are no longer produced (and I dont own one).
Most probably the amount of cash needed to buy one on ebay is way below the effort spent in designing extra hardware, but the latter is more fun

[auron]

Prototyping hour

https://imgur.com/vP1cwOJ
(could not upload here, sorry, "Message board quota" something)

Well, so I learned my flippy modded Panasonic JU-475-4 AKO already does half-steps internally (it does 2 steps per track), so with 4 Microsteps per step I can now adjust to approximately 1/8th of a track

I have not tried the 100TPI disks yet (did not write the arduino code for it yet), but I already can read some C64 disks that gave errors before. Either my drive is not well aligned, or the alignment on my old 1541 was off in the days.
Either way - realigning on the fly (only the tracks, obviously, but still)

To-do:
[*] Get rid of the cables and assemble a nice board
[*] Write code for 100TPI adjustment
[*] maybe add a nice little UI

If anyone is interested - I consider ordering a PCB, but only if maybe 4 people join, else a stripboard wil have to do.

[Rakki]

Quota fixed, feel free to add files now.

[auron]

OK, so here we go - attached is the current project: Schematics, KiCad files and Arduino code.
Use at your own risk. It works rather nicely for me, but please don't yell at me if it fries your drive, your home explodes or you accidentally create a black hole that swallows the Earth.

Please drop me a note if you use this, I would be very interested in hearing how it works for others.

Usage:
Connect to the Nanos COM port (e.g. with Putty) at 115200/8/n/1
It will display the current position as counted from controller, The calculated Go-To position and the actual position every half second. Mainly for debugging.

The controller position is rather arbitrary, as the plugin board has no way of knowing the real track, so it might be quite a while off, and even negative.
When resetting the nano at zero position it keeps track quite well.

Entering a number (positive or negative) followed by CR or LF on the serial port will set the offset in 1/4th of a step.
The values I use are mostly -4..+4. As my drive does two stepper motor steps per track, that equates to minus a half track to plus a half track (4 microsteps per controller step).
Note that the drive will recalibrate when seeking to the track0 sensor, so anything beyond that range is useless anyways and will just throw off the controller position printed (see above)

Entering t<number> followed by CR or LF will set the TPI.
e.g.
t100<LF> will set to 100TPI

the go-to microtrack is calculated as
round(<controller track>*4*96.0/<TPI>)+offset

The only use case I currently see for is for setting 100TPI emulation.

Currently I'm working on a complementary java program that dumps multiple versions of track 0 (offset -3..+3)x(dd0, dd1), and then tries to guess what the best values are by checking different formats and seeing which stream file compresses best.
Alternatively, I consider to just do 7 stream dumps of the whole disk and then mix and match the raw files that decode well to complete all tracks.
Goal would be to have a best effort fire-and-forget solution. Not sure if it's worth the effort though.


Cheers,
Tobias

[auron]

So, after playing with this for a while, I actually do have a real feature request:

Can I please have a switch, or config file, to somehow disable the fixed 83 track limit in Kryoflux DTC?
I checked (just a quick hack manually driving the floppy without kryoflux involved), and my drive happily accepts tracks far beyond that - it just won't go below track 0 as long as the flippy mod circuit is not activated.

It would make it so much easier for problematic disks to just dump the whole disk, or regions of it, at 1/8th track steps, and later pick the micro-tracks that decode.
I already had some disks, where only one of the microsteps would decode a track without errors, but the offset was different for the next track - I assume because I can only still read it if I exactly hit the original track as written, but the old drives were not too precise IIRC.
The way I currently do it is to dump the whole disk at 96 TPI with a microstepping offet determined by trial and error, and then re-dump failed tracks manually at 768 TPI, by starting DTC for tracks 0-32, then quickly change to my microstepping interface and enter an offset of 8*(failed track number -2) and not forget to quickly change that offset back to 0 before DTC finishes.
Not very satisfying, and quite error prone.
I could of course put the whole thing into a wrapper program, but it's an ugly hack non the less.

Thanks,
Tobi

[IFW]

So, after playing with this for a while, I actually do have a real feature request:

Can I please have a switch, or config file, to somehow disable the fixed 83 track limit in Kryoflux DTC?
I checked (just a quick hack manually driving the floppy without kryoflux involved), and my drive happily accepts tracks far beyond that - it just won't go below track 0 as long as the flippy mod circuit is not activated.

Thanks,
Tobi

I know this is an old request, but what limit would work?
Changing this is not trivial btw, but it is related to something else I am looking into...

[auron]

Thanks, this might still be useful, but the track limitation is really just a small piece of the puzzle now.
I used other hardware with open sourced firmware ( ) for my further tests.

To update this thread - I got reading the 100TPI 8250 disk working, but microstepping was too unreliable, so I had to replace the stepper motor and the whole positioning mechanics with a finer-threaded M2 screw. I now have something like 1270 hardware tpi only on full steps - minus the jiggle in my 3D printed parts. The positioning repeatability is really excellent though...
To answer the question: it's close to an inch to cover on the 5.25" disk surface, so 1270 seems a good choice.

Video of the modded drive at different virtual resolutions if anyone's interested.
https://www.youtube.com/shorts/XsVMFfoIXQY

There's a thread in german on the forum64 following my learning curve...

[auron]

And maybe to explain the ridiculously high track count: I'm aware most of these mini-tracks would be noise or repetitions of the data on track-center. The trouble during my tests was that I had to find track-center first, and sometimes use neighbour mini-tracks to decode correctly.
8250 format is also slightly different from the C64 GCR coding, using different speed zones and timings, and the tracks on the back were numbered differently as well. But that's a different feature request I guess