You know how sometimes, every step of progress comes with a new problem to overcome, and the cycle just keeps repeating, until you're close to losing your mind? This is pretty much what happened during the holidays, when I tried to test my dumps of Cruise Chaser Blassty for PC-98 on real hardware.

First signs of trouble came with the disk format: 2DD is quite rare for this system, perhaps even moreso in 5.25" form-factor. Luckily, I found a bunch of DD disks from my stash, which comprises boxes of 3.5" disks some blessed individual left at a recycling shop's take-for-free corner, and stacks of 5.25" disks I got as part of a trade for all my PAL SNES games, for a trunk full of C64 stuff. I'm not quite sure why, but I had massive trouble writing a clean DD disk, without at least one sector being bad when I dumped the disk I had written. Are these things just older than HD ones; more prone to fine dirt causing read issues due to something in their construction; or am I just getting unlucky? Anyway, I managed to get there eventually, and produced clean backups in both form-factors.

The next step was to try the disks on both my PC-9801VX (5.25") and PC-9821CS2 (3.5"), to see if cpu generation or other specs matter for getting the game to run properly. I started by putting Disk A in my VX, and watched as the drive heads engaged with the first track. The solenoid clicked a few times around that area, after which the heads moved all the way to the center... and stopped, leaving me with a black screen.💧

Curiously, this exact sequence repeated on the CS2, letting me conclude the drives probably aren't the issue. The problem with that though was, when I tried reading the original disks next, I got -- quite contrary to what I was expecting -- the same exact result.💦 This put the drives back on the list of possible culprits, and even worse, suggested the originals might be faulty.😬 So, which one is it going to be: the dumps, the drives, or the originals? Or all of the above?😵

Time to go look at the dumps to see if there's anything peculiar there: Well now, that is one formidable-looking protection scheme, but the dump itself looks fine. One piece of weirdness though was, I noticed some details changed based on which format the images were in: SCP showed 28 bad sectors on Side 0, whereas HFE showed 33. In the same vein, looking at Track 79.1, with the overlapping sectors (or whatever this bloodbath of a pattern is called), I noticed some CRC values were CFCF in one format, and 0101 in another. Hoo boy, I wonder if a flux reader can even replicate...whatever this is I'm looking at?

(I guess it's possible all this variance is caused by the software interpretating data in these different formats differently, whereas what gets written on the disk is more or less the same... Right? Honestly I have no idea how this stuff works on a super technical level, so don't take these musings to suggest I know what I'm talking about.) To cap things off, conspicuously there, above all the red carnage, was my nemesis, which had me pulling my hair out with Star Cruiser some time ago: the short blue line indicating the index pulse, which you absolutely do not want to have over protection areas, as it can totally mess up the writes on those complicated sections. Luckily for me, I had been to this rodeo before, so I Shifted the track using HxC's editing tools, so that the index pulse moved over the gap on the left, where it poses to cause the least harm. HFE v3 seemed to produce the closest match to what I saw in the SCP pie charts, so let's go with that. Yay, that seems to have done the trick on my CS2. The drive head read the red carnage, then moved back toward the beginning, and started loading the game from there. Fascinating to witness a copy-protection scheme in action: a round-trip to the "outside of spec" final tracks of the disk, to prevent naughty people from copying that floppy.😳 At this point I thought I had figured it all out. However, to my shock, this fixed dump didn't improve things on my VX, whose Drive 1 still got stuck at the same spot. What in tarnation...

I guess it's time to take out the drives, and hook them up to my DOS machine for some testing, using my trusted diagnostics tool, IMD: Oh wow, while this drive reads fine through tracks 0-73, the top head actually starts getting misaligned from that point onward, to the point where it fails to catch all of the sectors on those last few extra tracks. Well then, let's just unscrew it a bit to find the optimal position, and... uhhhh, why are the screws hidden under a pcb? 😵💦 At this point I was about to scream, but it turns out the design isn't quite as user-hostile as it looks. I figured out that if you seek to the utmost extreme, around track 82 or so, you get the screws visible just enough to turn them from an angle. But man, imagine if that *wasn't* the case. 1mm difference would've made this model de facto unserviceable. Weirdly enough, no position I put the head in managed to find the number of sectors I was aiming for (18). The only thing that made the numbers tick up was pressing the head down a bit with my finger. Wait a minute... Most drives have an adjustable spring for this purpose, but this one is conspicuously lacking one. So how in the heck does it do it? Let's all recall the day we got our first FD-1155D. Something metally rattling inside -- it's the square-shaped cover for the top head, which ostensibly serves no purpose, apart from falling off, and threatening to slice up your disks if it manages to make its way to the window. Could it be that this thing actually provides a little bit of extra weight, the final oompf needed to read the last tracks properly? I have no idea if this is documented anywhere, or if the difference in pressure from top is enough to cause issues on all/most/many units of this model. However, I will gladly accept all Nobels and prizes of lesser prestige offered to me for the discovery.

What's most interesting to me personally is, I could see myself using these drives for years without noticing this issue, because so few software use the last tracks for anything. In fact, that's exactly what happened.🤣 Even dumping disks has worked without a hitch, thanks to flux file formats storing multiple revolutions, which allows for the partly bad reads to complement each other to form a perfect image of the data, in the final stage of analysis.

Update: When I tested my second FD-1155D in IMD, it didn't seem to have this problem. Maybe the top head needs to be cleaned (=lifted up slightly) x times for the problem to start developing? Let's hold off on that Nobel until we do more research, i.e. get to test more units.

Having no clue where I stored my head covers, which fell off many moons ago, it was time to come up with a replacement. Oh hey, these washers I have lying around seem to be just the right size. Let's put them on my cocaine kitchen scale, and see how many I need to stack up: Based on my testing, ten grams seems about right to fix the issue. Now let's attach them together using double-sided tape, and plant our stack on the top head: Voilà -- perfection! And how do the numbers look? Eeeeexcellent... 👏

And now, the final step: How does the VX like this setup? We did it boys! Well, to add a little shade on our accomplishment, the color red seems to have taken a day off, but I'll let that slide for now -- technically, it's in perfect congruance with the theme of this article: every step introducing a new issue for me to overcome, which I somehow managed to do (up to this point), and lived to tell the tale. I'd honestly expected a story like this to end with the original disks being busted, the drives being unrepairable, or something equally nasty, like an explosion of some kind?

Yet, as usual, Old Krug abides.

PS. I've added the fixed hfe on IA, with cracked d88's hopefully coming next, now that I'm able to load the disks on real hardware. Happy cruising and chasing (and of course, blassting) into 2025 🚀🌈

<- BACK TO MAIN PAGE