fluxengine
fluxengine copied to clipboard
davidgiven
Unable to read Victor 9000 disks
I have four original disks, two MS-DOS 1.25 and two CP/M 1.1. Fluxengine is unable to read data from any of them. I'm using a 5.25" 1.2MB 80 track drive. If I read the disks using a SuperCard Pro then I can somewhat extract data from the scp files using samdisk:
samdisk copy --scale 120 -c0-79 v9k-dos.scp v9k-dos.raw
The image produced from samdisk isn't perfect since I can't boot it in MAME, but it has been able to decode a lot more of the disk.
I've attached a log and the victor9k images.
Also if you want to convert the raw image from samdisk into a "triangular" MAME compatible image, a couple more steps are required. First is to use v9k-raw2img-fixed, and the second is to remove the last sector from the disk because of a bug in MAME.
v9k-raw2img-fixed.pl v9k-dos.raw v9k-dos.img
dd if=v9k-dos.img bs=512 count=1224 of=v9k-dos.mame
Emitting triangular images is the easy bit, and I've done that --- look in the victor9k branch.
Trying to decode the SCP file, the best I can do is to get 207 bad sectors. I think samdisk can do better than that, but it doesn't show any stats so I can't check how much. A quick look at the source shows it's using a very simple PLL for reading bits. I might try and copy that.
Not being able to read directly is another issue. Are you using GreaseWeazle or FluxEngine hardware?
$ fluxengine read victor9k -s v9k-flux/v9k-dos.scp --decoder.write_csv_to=out.csv --decoder.clock_interval_bias=-0.025
H.SS 01234567890123456789012345678901234567890123456789012345678901234567890123456789
0. 0 .X.......B.B...B..........B.......B..BB.....B.........B.........B...BB..........
0. 1 B...................................B...BB.BB.BB..........BBB..BBB.BBBBB....B.B.
0. 2 .......B........B.............B.....X......B.......B..B.B.B......B..B..B........
0. 3 B....B........B......B....B..B......B...B...B.......................B.B.B...B..B
0. 4 B....B..........B...............B.......B....B.B......BB.....B....B.B.B........B
0. 5 BBBB.B.............B...............BB.....B.....B........B.B......B.B.B..B..B...
0. 6 B..B........B..........................B..B....B....B.B.B.....B.................
0. 7 B..B...........B..............B....B.B......B.....B................B.B....B.B...
0. 8 B.BB......B....B.B.......................B............B.B..........B.......B....
0. 9 B.B.........................................B.B..B.......B.....B....B.B....B..BB
0.10 B..B....B.........B...B...B...X..B......B............B..B.........B.B.......B..B
0.11 B.............BB..B.......B...B.....B...B..B..B............B..B...B.B.B......B..
0.12 BBB..BBB.................BB.........B..........B.........B......B...B..XXXXXXXXX
0.13 ..BB...............BB.....B.......................X..B......XXXXXXXXXXXXXXXXXXXX
0.14 ...B.........B...........B..B...........B..B..BBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.15 B..................B...........B..B...XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.16 B.BB.......B......B........XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.17 B.BB.......B....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.18 B.BBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
I've successfully ported the samdisk PLL code, and the results are spectacular. Not perfect, but way better than my original code.
H.SS 01234567890123456789012345678901234567890123456789012345678901234567890123456789
0. 0 .X.......B........................B..BB.....B.........B.........................
0. 1 .........................................B................B..........B........B.
0. 2 .......B........B..................................B.............B.....B........
0. 3 ..............B......B....B..B..........................................B.......
0. 4 B...............................B............B.........B.....B........B.........
0. 5 B....B.............B...............B......B.....B..........B......B......B......
0. 6 B...........B..........................B............B.........B.................
0. 7 B.........................................................................B.....
0. 8 B.B.......B......B......................................B..........B............
0. 9 B.............................................B..B.............B...........B....
0.10 B.......B.............B.......X..B...................B......................B...
0.11 ...............B....................B...B..B....................................
0.12 B.....B..................................................B..........B..XXXXXXXXX
0.13 ....................B.............................X.........XXXXXXXXXXXXXXXXXXXX
0.14 .............B...........B..B..................BXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.15 ...............................B......XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.16 ...........B......B........XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.17 ...B............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.18 B...XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Good sectors: 1144/1520 (75%)
Missing sectors: 299/1520 (19%)
Bad sectors: 77/1520 (5%)
IMG: wrote 80 tracks, 1 sides, 612 kB total
Doesn't seem like it works any better.
H.SS 01234567890123456789012345678901234567890123456789012345678901234567890123456789
0. 0 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBXBBXXXBBBBBBBXB
0. 1 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX?B??XXXBBBBBBBXX
0. 2 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX?B?X?XXBBBBBXBXX
0. 3 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBXXBXXBXBBXXXXX
0. 4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBXBXXXXBBBXBXXXX
0. 5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 6 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX?XXXXXXXXBXXX
0. 7 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBX?XXXXBBXBXXXX
0. 8 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBXBXXXXBBBBXXXXB
0. 9 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBBBBXX??XXXXXXX
0.10 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXB?XBXXXXBXXXBBXX
0.11 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX?XXX?XXBXXXBBXXX
0.12 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXB?XBXXXXXXXXXXXX
Good sectors: 14/1040 (1%)
Missing sectors: 963/1040 (92%)
Bad sectors: 63/1040 (6%)
#350 has just fixed a GreaseWeazle client bug where the high density pin wasn't being set correctly. My drives seem to ignore this. PTAL?
Hm. I wonder if it's a termination issue? Were you using the same drive configuration on the Supercard Pro and on the FluxEngine? And could you try fluxengine test voltages and report the results, please?
Same drive, same cable. I just unplug it from the SCP and plug it into the FluxEngine.
Output voltages:
Both drives deselected
Logic 1 / 0: 0.49V / 5.00V
Drive 0 selected
Logic 1 / 0: 0.52V / 5.00V
Drive 1 selected
Logic 1 / 0: 0.52V / 5.00V
Drive 0 running
Logic 1 / 0: 0.51V / 5.00V
Drive 1 running
Logic 1 / 0: 0.52V / 5.00V
Input voltages:
Both drives deselected
Logic 1 / 0: 4.85V / 4.99V
Drive 0 selected
Logic 1 / 0: 0.07V / 4.86V
Drive 1 selected
Logic 1 / 0: 4.99V / 4.99V
Drive 0 running
Logic 1 / 0: 0.05V / 4.90V
Drive 1 running
Logic 1 / 0: 4.99V / 4.99V
Well, the levels look okay, which means I don't think it's a termination issue. Since you're getting something, but with a terrible signal that means that most of the data is garbage, this sounds like either a drive configuration issue or an electrical issue.
On the offchance that I also got the high density pin polarity inverted on the FluxEngine, could you try --flux_source.drive.high_density=0? Also could you check that the FDD is grounded to the FluxEngine board via one of the ground pins on the FDD connector being connected to a GND pin on the board?
Confirmed with the multimeter that all the grounds are tied to GND on the FluxEngine PCB. I did another rawread with fluxengine rawread -d v9k-msdos-125b.flux --flux_source.drive.high_density=0 and the results aren't any better.
So, I'm stumped. There's clearly something electrical wrong but I don't know what. I suppose it's possible that your drive happens to have some extra configuration pins --- what is it? Do you have the datasheet?
If there are electrical problems, why does the drive work fine in my PC and why does it work fine with my SuperCard Pro? It's a Sankyo YD-380 type 1711.
I mean, something electrical at my end. But I can't think what.
Hmm. I notice I forgot to ask the really dumb questions:
- is it just the Victor 9K disks which are problematic, or do other disks fail too?
- are you using the latest client and firmware (https://github.com/davidgiven/fluxengine/releases/tag/dev)?
I am working from the master branch. The dev tag is just a tag, not a branch, and dev points to a commit from 2021 May 8. I just downloaded the latest release file from Releases and flashed the firmware, did another read of the floppy, but I think it made things worse.
Tracks -> 1 2 3 4 5 6 7
H.SS 01234567890123456789012345678901234567890123456789012345678901234567890123456789
0. 0 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBBBBBXXBBBBBBBXB
0. 1 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBBBBXXBBBBBBBBXB
0. 2 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBXBXBXBBBBBBBBBX
0. 3 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBBXXBBBBBXXXX
0. 4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBXBBBXXBBBBBBBBX
0. 5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBBBBXBXX
0. 6 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBBXXBXXBXBXXX
0. 7 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBB?BBXBXBBBBXBXB
0. 8 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBB?BXXXBBBBBBBBB
0. 9 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBBBXXXBBBBXBXBBB
0.10 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBBXBXXXBBXBBBBXB
0.11 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBX?XBXXBXXBBBBBB
0.12 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBXBXXXXXXXXXXXX
Good sectors: 3/1040 (0%)
Missing sectors: 915/1040 (87%)
Bad sectors: 122/1040 (11%)
IMG: wrote 80 tracks, 1 sides, 520 kB total
I've really only tried to read the Victor disks. I have other tools for pretty much all the other floppies I encounter. The inability of converting to/from the .flux format to something like .scp makes me only try the fluxengine when none of my other options are working. The only reason I'm trying to get the fluxengine to read directly from the drive is because there's no way to convert .scp to .flux.
I dug out a 1.2MB floppy that someone had used to backup their PC, and just imaged it with both fluxengine and scp and attached them.
dev is updated on every push and the binaries in the releases updated automatically, so that should be the same version.
Re using SCP files: the FluxEngine client will read this natively. Just use -s something.scp instead of -s drive:0 or -s something.flux. If you actually want to do a conversion, do fluxengine rawwrite -s input.scp -d output.flux. It ought to write SCP files too, but that's not had a lot of exercise.
BTW, the flux file for that disk is showing a decent but not perfect side 1 read, and almost pure garbage for side 0. The SCP file is showing a perfect side 1 and about half garbage for side 0. It's weird that it's so much better than the Victor disk, and yet still so much worse than the SuperCard Pro read.
Also BTW, one of the things on my list is to implement a SuperCard Pro backend. It seems easy to interface to as it's just a USB serial device and there's simple code available (https://github.com/keirf/Disk-Utilities/blob/master/scp/scp.c). However, I don't have one and so I'd have to do it blind. Given that something appears to be wrong with your FluxEngine hardware, would you be interested in testing this?
Hi guys, I've been investigating Victor 9k files quite a bit over the past 2 weeks. I have identified that in mame, FluxEngine, and Samdisk there all appears to be a common disagreement with the hardware specification around the sector size for zone 4, tracks 48 and 49.
The specification lists tracks 38-48 inclusive as having 15 sectors per track. And then zone 5, tracks 49-59 as having 14. In all the implementations I can find everyone has made zone 4 as tracks 38-47 with 15 sectors and zone 5 as tracks 48-59 with 14. The differences are in tracks 48-49 having sector sizes that don't match the spec. You can see this in the FluxEngine code in the src/formats/victor9k.textpb. I've been playing with a branch that alters this disagreement back to the specification arrangement.
I'm trying to figure out if the bug was introduced somewhere and everyone copied each other's implementations, or if the original BIOS has a bug that everyone is faithfully reproducing. You can see the specification in the attached Victor 9000 Hardware Reference Manual.pdf on page 51 of the PDF (page number 51 in the original paper, it's 76 in my PDF reader). My theory is that when we're imaging the disk we're dropping one sector on track 48 and looking for one that's not there on track 49.
I just purchased a victor 9k that's being recapped right now. I have a greasewezel on order that should arrive in the next few days. I have about 8 victor disks I can try to image. The FluxEngine hardware was on backorder everywhere.
However, I don't have one and so I'd have to do it blind. Given that something appears to be wrong with your FluxEngine hardware, would you be interested in testing this?
I can probably setup a box outside my firewall with the SCP and a floppy drive on it and give you access temporarily. But if I can't get the fluxengine to work then I'm probably going to stop mentioning it on RetroBattlestations when people are looking for a way to image floppies. I was hoping to get the fluxengine to work since it's cheap, even if it's kind of a hassle to get it flashed. The fluxengine hardware is the most interesting part of your project, even with the lack of compatibility with the file formats.
Re using SCP files: the FluxEngine client will read this natively.
I have never had any luck with getting fluxengine to read scp files. It doesn't print any errors but the output is always garbage.
@pauldevine Yes, mame has a bug that the disk image needs to be one sector short. However that isn't the issue at hand here. The problem is that the fluxengine hardware is unable to read from the floppy drive.
Hi all - I've done quite a bit of playing with victor disks with a kryoflux and a greaseweazle - the problem seems to mostly be down to the fact that 80 track 5.25" drives can't deal with the short spaces between fluxes on the outer tracks (the rotation speed in a real victor is quite low on those). It's not a problem of the flux sampling hardware or software, I think the solution is to hack the drive speed (I've been halfway through modding a drive for a year, but lots of things keep getting in the way).
@drdpj If you look at the thread the problem with reading is there even with MFM encoded disks. When using the SuperCard Pro with the same drive it is able to read the Victor disks and I can decode them with samdisk. The drive speed is not the issue.
@FozzTexx Sorry, only came in at the bottom there prompted by someone over on stardot - I'm interested that you've managed it with the SCP, but it didn't look like you've managed complete images? I can get partial images with kryoflux and greaseweazle but known good disks still can't be completely imaged. Anyway, it seems like there's a couple of different issues at play here so I'll duck back out. If you'd like to join in a more general discussion over on stardot, the thread is here: https://stardot.org.uk/forums/viewtopic.php?f=45&t=23831 - there's not much for the v9000 out there these days
Just to answer my own unrelated question above, it turns out the manual is wrong. I read through the Victor floppy drive assembly posted at the linked stardot thread, and the mame / FluxEngine implementation of the track sizes is correct. It looks to me like a typo that got into the final build and then needed to be lived with as the disks already had that format. The specification in the manual doesn't match the actually assembly.
@pauldevine The number of sectors per track is in a table in the first sector of the floppy. Which tracks belong to which zones and the speed of the zones is also in the first sector of the floppy. It can be completely changed based on what's first read from the floppy, it's not hardcoded into ROM.
@FozzTexx I didn't know that. Do you have a reference? It sounds like both the encoder and decoder are going to have to understand this, and it's going to make things really awkward.
It's in the assembly source. I've been doing reverse engineering on the ROMs while working on my disk tools for creating and writing Victor disks and trying to get my two Victors working again. I need to make a blog post about all the work I've done and where I'm at but I've been so busy.
Let me know if you write something up, please? That's going to be really annoying to implement as it violates loads of abstraction layers.
Incidentally, regarding your issues with the FluxEngine hardware: I did have a thought, which is that your drive might be generating pulses too short for the hardware to pick up. I couldn't find a datasheet for it so I don't know the exact timing. There are a couple of potential easy fixes, the first of which is to simply try another drive if you have one. The other is to increase the clock rate on the board. If you're willing to brave the PSoC development kit and build your own I'd suggest increasing MASTER_CLK to 80MHz, or I can build a custom firmware.
It's the only working 1.2MB drive I have. The other one got damaged in shipping and the PCB was snapped and it seems to be multilayer so I haven't been able to fix it.
If you want to make a custom firmware for me to test with, I'm happy to flash it.
As to the zone tables being on the disk, it does make me wonder if it might open the door to formatting the disk in a way that doesn't require special hardware. The disk would still need to be GCR encoded and track zero would have to be the expected rate, but the rest of the disk could be configured to be a fixed rate with the same number of sectors on every track. Of course the only reason to do it would be to bootstrap a Victor when you have no media at all.
I've attached the new firmware. It increases the read data sample rate from 12MHz (83ns) to 64MHz (16ns). My 5.25" drive datasheet doesn't specify a length for a data pulse; my 3.5" drive says at least 150ns. I actually think this is a rather long shot but it's worth a try, and it's better being more sensitive anyway.
Don't suppose you have found the datasheet for your drive? I've had a hunt around and don't see it.
Re zone tables on the disk: track 0 on a Victor 9000 disk will show up at 714kHz on a 360rpm drive or 594kHz on a 300rpm drive (assuming I've done the arithmetic correctly). You can persuade a PC FDC to write arbitrary bit patterns if you configure it to emit a single huge FM sector, but not many support FM, and I think it tops out at 250kHz anyway. Maybe if you slowed the disk rotation speed down enough... firmware.zip
I'm trying to figure out if the bug was introduced somewhere and everyone copied each other's implementations, or if the original BIOS has a bug that everyone is faithfully reproducing. You can see the specification in the attached Victor 9000 Hardware Reference Manual.pdf on page 51 of the PDF (page number 51 in the original paper, it's 76 in my PDF reader). My theory is that when we're imaging the disk we're dropping one sector on track 48 and looking for one that's not there on track 49.
The "bug" is that the hardware reference manual is wrong: track 48 on side 0 is actually in zone 5 (14 sectors), not zone 4 (15 sectors) as the diagram shows. This has been tested/read from multiple victor disks. The diagram for side 1 in the hardware reference manual is also wrong: track 40 on side 1 is actually in zone 5, not zone 4.
Results are different, but not really better.
That's because that firmware image was garbage. Sorry. Try this one instead.
If you need any sample Victor 9k disk examples, I received my Greaseweazle and was able to make several disk images that seemed to read cleanly.
Tracks -> 1 2 3 4 5 6 7
H.SS 01234567890123456789012345678901234567890123456789012345678901234567890123456789
0. 0 ................................................................................
0. 1 ................................................................................
0. 2 ................................................................................
0. 3 ................................................................................
0. 4 ................................................................................
0. 5 ................................................................................
0. 6 ................................................................................
0. 7 ................................................................................
0. 8 ................................................................................
0. 9 ................................................................................
0.10 ................................................................................
0.11 ................................................................................
0.12 .......................................................................XXXXXXXXX
0.13 ............................................................XXXXXXXXXXXXXXXXXXXX
0.14 ................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.15 ......................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.16 ...........................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.17 ................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.18 ....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Good sectors: 1224/1520 (80%)
Missing sectors: 296/1520 (19%)
Bad sectors: 0/1520 (0%)
IMG: wrote 80 tracks, 1 sides, 612 kB total
@davidgiven earlier I noticed you mentioned you couldn't find a Datasheet for FozzTexx's drive. I dug around on google and found http://www.bitsavers.org/pdf/yeData/FDL-523006_RevC_YD-380_Service_Manual_Feb1985.pdf which looks like the right manual.
That's because that firmware image was garbage. Sorry. Try this one instead.
Not any better.
That's because that firmware image was garbage. Sorry. Try this one instead.
Not any better.
Hi FozzTexx, do you grounded every odd pin(1....33 Floppyconnector) at the PSoC5LP side? This can be detected with inspect: a noise floor bigger than 400 is a problem. Typical is a value of noise floor: 250
Btw. i'm a fan of your apple sider project. It works very well.
I found something.
Apparently some 5.25" drives have really strong pull-up resistors of 150 ohms. This requires buffering at the controller end to work properly. The GreaseWeazle has this, but the FluxEngine doesn't. I would have thought that the 'test voltages' command would have detected this --- the output low voltage of 0.5V looks fine --- but if there's a jumper setting on the drive to remove the termination resistors, that might be worth trying.
My Panasonic drives are fairly modern, for 5.25" drives, so it's possible they have bigger pullup resistors, which is why I don't have a problem.
There is a Beckman 899-3-150 resistor pack on it near the connector, so I swapped it out for a 899-3-1k, but it didn't help much.