Victor9k compatible drives

[Gary-Clark]

Writing disks for a Victor9k using a Greaseweazle V4 has failed with a TEAC FD-55GFR but works with a YE data YD-380B and a Mitsubishi MF-504C. Problems with the GFR have been verified with at least one other user.

OPTION: 612kB 80-track DSHD GCR IMG: read 80 tracks, 1 sides, 612 kB total from MS-DOS MS-BASIC Ver 2.1.img Measuring rotational speed... Using Greaseweazle GWB0B563A55976C01007009705 on COM6 Rotational period is 166.3ms (360.9rpm) 0.0: writing 166 ms in 62100 bytes 0.0: 199 ms in 74207 bytes 44 raw records, 22 raw sectors; 1.49us clock (671kHz) sectors: 0.0.0 0.0.1! 0.0.2! 0.0.3! 0.0.4! 0.0.5! 0.0.6 0.0.7 0.0.8! 0.0.9! 0.0.10! 0.0.11! 0.0.12! 0.0.13! 0.0.14? 0.0.15 0.0.16 0.0.17 0.0.18 9216 bytes decoded bad read

[davidgiven]

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).

[Gary-Clark]

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

[pauldevine]

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

[pauldevine]

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

[pauldevine]

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

[pauldevine]

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.

[davidgiven]

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.

[pauldevine]

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.

[pauldevine]

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.

[Gary-Clark]

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

[pauldevine]

Yes, it does.

[Gary-Clark]

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