Victor9k compatible drives about fluxengine HOT 12 OPEN

Can you run the analysis described in https://cowlark.com/fluxengine/doc/driveresponse.html and paste the image in? It's quite possible that the drive doesn't support pulse intervals short enough --- there are some examples of failing drives.

It's also worth trying to format a track on the disk up in the 70s, to see if that works any better (the intervals are longer).

from fluxengine.

Attempted and runs through but no PNG image file seems to be written.

C:\Program Files (x86)\Cowlark Technologies\FluxEngine>fluxengine analyse driveresponse --cylinder 0 --min-interval-us=0 --max-interval-us=3 --interval-step-us=.1 --write-img=c:\driveresponse.png -d drive:1

from fluxengine.

I stopped by to raise the same issue, I can see Gary beat me to it. @davidgiven for context, I have 4 drives, and the Teac 55-GFR is the only one that exhibits this difficulty in writing. Unfortunately there's 2 people who have this drive that are trying to write victor disks. I played around with the jumper settings last weekend, and was able to verify a set of jumpers that work reliably for reading. Unfortunately, the same setup that works for reading doesn't seem to work for writing. I get the same behavior Gary is reporting above. I just tried the diagnostics with two different media. What I believe is a double-sided double-density disk and one that I believe to be high density. I'm judging based on wether there's a hub ring or not. I ran each disk both with and without the --drive.high_density=0 flag. I wasn't sure if that would impact the test.

Here's the output
Double Density Media
./fluxengine analyse driveresponse --cylinder 0
--min-interval-us=0 --max-interval-us=15 --interval-step-us=.1
--write-img=driveresponse.png -d drive:1 --drive.high_density=0

Double Density Media
./fluxengine analyse driveresponse --cylinder 0
--min-interval-us=0 --max-interval-us=15 --interval-step-us=.1
--write-img=driveresponse.png -d drive:1

High Density Media
./fluxengine analyse driveresponse --cylinder 0
--min-interval-us=0 --max-interval-us=15 --interval-step-us=.1
--write-img=driveresponse.png -d drive:1 --drive.high_density=1

High Density Media
./fluxengine analyse driveresponse --cylinder 0
--min-interval-us=0 --max-interval-us=15 --interval-step-us=.1
--write-img=driveresponse.png -d drive:1

from fluxengine.

Ok, interesting debugging, I had always been trying to write with DD disks during my testing. Based on the graphs above I tried to write a HD disk for giggles, and it gets to track 44 before having any issues. Whereas the DD disk won't get past track 0. What's interesting is I tried with two HD media and two different source .img files and all variations get to track 44 before having trouble. I took an .img that I knew was bootable with only the contents of the first 40 tracks. After it errored out on the write I was able to take that disk and boot the Victor. So that's some progress. When I originally deduced the timing of these disks, I just went by trial and error. It's possible I have a slight divergence that's part of our problem.

43.0: writing 167 ms in 59186 bytes
43.0: 200 ms in 71039 bytes
37 raw records, 18 raw sectors; 1.90us clock (525kHz)
sectors: 43.0.0 43.0.1 43.0.2 43.0.3 43.0.4 43.0.5 43.0.6 43.0.7 43.0.8 43.0.9 43.0.10 43.0.11 43.0.12 43.0.13 43.0.14
7680 bytes decoded
44.0: writing 167 ms in 55830 bytes
44.0: 200 ms in 67801 bytes
36 raw records, 17 raw sectors; 1.91us clock (524kHz)
sectors: 44.0.0! 44.0.1! 44.0.2! 44.0.3! 44.0.4! 44.0.5! 44.0.6 44.0.7! 44.0.8 44.0.9? 44.0.10 44.0.11 44.0.12! 44.0.13! 44.0.14!
7168 bytes decoded
bad read
retrying; 5 retries remaining

from fluxengine.

Command that partially worked in case it's significant:
~/projects/fluxengine/fluxengine write victor9k --612 -d drive:1 -i MS-DOS\ 3.1\ for\ Victor.img --drive.high_density=1

from fluxengine.

I conducted a few more tests. I am able to write a Victor disk with the TEAC 55 drive using the AppleSauce. What's interesting is if I write a disk with a Panasonic drive on either the greaseweazle/fluxengine or AppleSauce, the Teac drive reads back that disk without errors.

Writer: Panasonic / AppleSauce or Fluxengine
Reader: Teac / Fluxengine
Works, can write with Panasonic and Fluxengine reads from the Teac without errors for all sectors.

If I take the same media and write the same image with the AppleSauce using the Teac drive. I get no errors from the AppleSauce while writing with the Teac, and I can boot the Victor with that disk. But when I try to read it back on the Teac in fluxengine it gives an error. So it only seems to have trouble digesting its own disks.

Writer: Teac / AppleSauce
Reader: Teac / Greaseweazle/Fluxengine
Doesn't work. It gives errors on a handful of sectors.

I just tired to read the same disk on the AppleSauce and interestingly it also gives errors.
Writer: Teac / AppleSauce,,
Reader: Teac / AppleSauce
Gives errors for 3 sectors, slightly smaller ratio to what I'm seeing with fluxengine.

I'm wondering, is it possible to disable the validation check when writing the disk? I know that's dodgy but it might just allow us to write a few to bootstrap a machine.

I uploaded a few fluxes from my testing here
https://drive.google.com/file/d/1cfIr5-zWqefIfM9bujgUOYLFcc3AG7W_/view?usp=sharing

The files with teac in the name were written on the teac, the files with pananosic in the name were written with the Panasonic and read on the teac.

from fluxengine.

Those drive graphs look fine, but I'd forgotten that there's an enforced limit of 2.0us on the lower bound (because the firmware doesn't cope will with intervals that are too small). Given the v9k clock is ~1.9us, I think that's too big. Unfortunately this is hardcoded, so you might want to try changing the number here:

        /* Write the test pattern. */

        if (interval >= 2.0)
        {

Set it to something like 1.0 and then experiment with --min-interval. But honestly I don't expect any problems here.

It is possible that this is a write precompensation issue --- FluxEngine doesn't have any, as it seems my drives don't need it and I could never make this work. If this is true I'd expect to see more errors for high track numbers than low track numbers, as the bits are physically closer together for the tracks close to the disk.

You can, BTW, use the --no-verify option on fluxengine write to prevent verification.

from fluxengine.

Thanks David, that's super helpful. I appreciate your insights. I tried to yolo writing a disk as-is with the --no-verify option just for giggles. I was able to almost boot with that disk. It made it 90% of the way through the boot process and then failed to load command.com. So whatever is off isn't by much. I'll give the code changes you suggest a whirl and see what I come up with.

from fluxengine.

Ok, I just tried
fluxengine write victor9k --612 -d drive:1 -i 3.1working.img --no-verify --drive.high_density=0

and the disk worked and was completely readable on the Victor with the TEAC 55 drive. I should have thought to add the density flag earlier.

from fluxengine.

Does the drive not run at 300 rpm with the --drive.high_density=0 ?

from fluxengine.

Yes, it does.

from fluxengine.

So writing on a TEAC FD55-GFR does appear to work but will not verify successfully.

from fluxengine.