Standard 5.25" drives have trouble reading the flip side of e.g. C64 disks. Please read our FAQ for an in-depth explanation of the problem. We are proud to present one-pass flippy dumping with KryoFlux. With a modified 5.25" drive you are able to read such disks without flipping the disk or adding a fake index signal. This tutorial was made by Robert McIntyre. Thanks for making it happen!
Part 1: http://www.youtube.com/watch?v=WcqluH7dEj4
Part 2: http://www.youtube.com/watch?v=wGxPGavShcE
Part 3: http://www.youtube.com/watch?v=aW65ynGGiFk
But is there any chance, that some drives exist, that can handle all needed head positions without modifying?
I'm just asking 'cause I think I got one.
It's an old drive made in GDR ( german democratic Republik ).
I just tried dumping both sides of a C64 Floppy disk and both Images work like charm in an emulator.
I'm interested in learning more about your drive; can you share the make/model number, and perhaps some pictures?
Also, to see if it's actually dumping both sides properly, please provide the command line that you're using, and the output of DTC for the first 5 or 6 tracks of each side (please use -l15 in the command line to get detailed output). We can take a look at it and determine if it's decoding things properly.
Another question, a 2N3904 should suffice in place of the 2N2222, right? Cause I've got lots of them around.
EDIT: One more thing that would be nice: an example command line for flippy dumping.
dtc -d1 -ftest.d64 -g2 -y -b-8 -i6 -l15
Result for the first few tracks:
-8.1: frev: 30834, drift: 0.062 us, tfer: 142108 B/s, rpm: 296.742
-8.1: base: 3.248 us [99.860%], band: 3.246 us, 6.497 us, 9.771 us
-8.1: CBM DOS: OK*, trk: 001, sec: 21, *T
-6.1: frev: 34417, drift: 0.125 us, tfer: 157103 B/s, rpm: 296.741
-6.1: base: 3.252 us [99.887%], band: 3.250 us, 6.504 us, 9.768 us
-6.1: CBM DOS: OK*, trk: 002, sec: 21, *T
-4.1: frev: 34539, drift: 0.083 us, tfer: 157860 B/s, rpm: 296.744
-4.1: base: 3.248 us [99.936%], band: 3.247 us, 6.495 us, 9.745 us
-4.1: CBM DOS: OK*, trk: 003, sec: 21, *T
-2.1: frev: 37060, drift: 0.104 us, tfer: 172400 B/s, rpm: 296.745
-2.1: base: 3.249 us [99.817%], band: 3.245 us, 6.498 us, 9.778 us
-2.1: CBM DOS: OK*, trk: 004, sec: 21, *T
00.0 : frev: 34547, drift: 0.083 us, tfer: 159009 B/s, rpm: 296.741
00.0 : base: 3.264 us [98.562%], band: 3.480 us?, 6.509 us, 9.791 us
00.0 : CBM DOS: OK, trk: 001, sec: 21
00.1: frev: 30833, drift: 0.166 us, tfer: 133697 B/s, rpm: 296.738
00.1: base: 3.251 us [99.891%], band: 3.247 us, 6.502 us, 9.767 us
00.1: CBM DOS: OK, trk: 005, sec: 21
02.0 : frev: 37628, drift: 0.042 us, tfer: 174854 B/s, rpm: 296.741
02.0 : base: 3.256 us [98.627%], band: 3.258 us, 6.511 us, 9.501 us?
02.0 : CBM DOS: OK, trk: 002, sec: 21
02.1: frev: 34420, drift: 0.187 us, tfer: 160568 B/s, rpm: 296.744
02.1: base: 3.245 us [99.902%], band: 3.250 us, 6.490 us, 9.759 us
02.1: CBM DOS: OK, trk: 006, sec: 21
04.0 : frev: 37168, drift: 0.770 us, tfer: 172400 B/s, rpm: 296.748
04.0 : base: 3.258 us [97.462%], band: 3.492 us?, 6.516 us, 9.513 us?
04.0 : CBM DOS: OK, trk: 003, sec: 21
04.1: frev: 34541, drift: 0.250 us, tfer: 160568 B/s, rpm: 296.745
04.1: base: 3.248 us [99.952%], band: 3.247 us, 6.496 us, 9.752 us
04.1: CBM DOS: OK, trk: 007, sec: 21
06.0 : frev: 37379, drift: 0.083 us, tfer: 173618 B/s, rpm: 296.745
06.0 : base: 3.255 us [98.571%], band: 3.235 us, 6.510 us, 9.496 us?
06.0 : CBM DOS: OK, trk: 004, sec: 21
06.1: frev: 37056, drift: 0.146 us, tfer: 172098 B/s, rpm: 296.746
06.1: base: 3.249 us [99.851%], band: 3.248 us, 6.498 us, 9.774 us
06.1: CBM DOS: OK, trk: 008, sec: 21
08.0 : frev: 37274, drift: 0.229 us, tfer: 173007 B/s, rpm: 296.742
08.0 : base: 3.259 us [98.625%], band: 3.259 us, 6.517 us, 9.508 us?
08.0 : CBM DOS: OK, trk: 005, sec: 21
Note the track numbers in square brackets, they show the logical track number where the drive's head really ended up. The number before the bracket shows where the dtc software wanted it to go. The asterisk means some kind of problem has occured; "*T" in particular means a track number mismatch.
So unless your game did not have any useful data on tracks 1-4 of the back side, it will fail to run correctly from the images you produced. The failure doesn't have to happen at once, it might happen at some point later in the game, e.g. during loading of some level beyond the first (which game is it by the way?)
@TeaRex - regarding the Teac FD-55GFR... I had high hopes for that drive, but it hasn't panned out yet. Here's a brief summary of what I found; I'll pull together a FAQ/analysis of every drive I've looked at, and post it, and we can add to it as people look at other drives.
First, you do need to remove some chassis to make it go to -8, and it involves taking the top disc-clamp arm assembly off, etc.. It's not too bad, but there's a good bit of grinding there.
Second, once the drive carriage assembly has the room to go to -8, you'll see that the carriage/head stepper metal ribbon has some issues. The way the clamping mechanism works, it doesn't give enough room for rotation in the negative direction, so it stops the head from going to -8 (I think I could get it to -5, or -6). The simplest fix for that would be to just slide the whole stepper back 2 tracks or so, and force it to zero in a position with more negative rotation available. Unfortunately, you can't get the stepper to go that far back. So, you need to rotate the takeoff pully on the stepper shaft to give a bit more room. This, of course, destroys the alignment, and requires a full realignment. But, it also makes the drive completely susceptible to being knocked out of alignment as soon as you bounce the head off an end stop.
And, in some of them, there's not enough room around the track 0 sensor itself to allow enough negative travel. So, to fix that, you have to grind some more, and shift the PCB (which has the track 0 sensor on it) as far to the back of the drive as possible. This, too, messes up the track 0 alignment, so you'll need to extend the end of the actuator with some card stock, etc., to make up for shifting the PCB/sensor, and carefully tweak the length of the addition to make the track 0 alignment right.
Whew! Ok, that's more than a brief summary, but there you go. I've got 6-7 of the most common drives, and looked at each one trying to figure out if it would work. I'll do a write-up of them all, and maybe it can be a sticky like the supported drives thread, and people can add their own experiences to it. It'll take me a day or two to get that done.
Oh, here's the command line that I use to dump flippies:
dtc.exe -p -fdumpdir\track_ -i0 -g2 -y -i6 -i2 -b-8 -l8 -t10
-p : force directory creation
-fdumpdir\track_ : create a directory for the disk, and name all the files "track_*"
-i0 : create stream files
-g2 : both sides of the disk
-y : flippy mode on side b
-i6 : CBM DOS format
-i2 : sets some preservation presets
-b-8 : track offset for side b
-l8 : limited output verbosity
-t10: 10 retries on errors
Then I remembered that many moons ago I had already added the transistor circuit to a trusty old Mitsumi/Newtronics D509V2 drive which comes right from my very first PC, a 386 that was already grimy and ancient when I I bought it in 1994. Of course the older kryoflux software didn't actually support the circuit so I had shelved it and forgotten about it.
Some more grinding and some re-alignment work was necessary (I moved seven times since I got it...) but now it works very well. Seems to read everything I throw at it: old and new, flippy and non-flippy Apple II, Atari 8-bit, Commodore, PC DD and HD disks, and even some Amiga stuff I wrote to 5.25" to test the ipf writing feature with this drive (I don't think there are any native 5.25" IPFs in the wild yet?)
The only odd thing is that disks *written* in it (from IPF) seem to be slightly unreliable when read (whether in the same drive or in another) around tracks 55-59, though using more revolutions (15 or so) will cure that. All the rest works well. Since I can't find any mechanical notches or bumps at that place, Could that have anything to do with the pre-compensation algorithm that dtc/kryoflux uses during writing? I've never yet had a drive that works really well at reading even ancient disks (many of which fail in other drives that I tried) but has trouble with writing specific tracks. I guess I will try writing a disk in it from the PC floppy controller...