i suspect that the machine used to dump this disk has dropped a lot of usb packets (had a lot of usb buffers underrun/overrun... ?)
Even without any analyser you can see that there is something wrong : have a look to the tracks file size qnx12_boot37.0.raw, qnx12_boot32.0.raw, qnx12_boot34.1.raw versus the others files.
also : qnx12_boot25.1.raw and qnx12_boot26.0.raw are missing...
The issue is not the disk itself, nor the drive, but the hardware/computer used to dump it.SomeGuy wrote: ↑Sun Apr 25, 2021 1:09 am I agree HxC does not seem to be liking these. It looks like there might be some minor damage, but it also feels like there might be some issue with the way the disks were mastered. At first I thought there might be copy protection. You might try a careful surface inspection, cleaning, and redump. Perhaps try reading with a 360k drive.
Did you manage to write back to floppy and test if it works? Unfortunately I don't hold the originals so I can't re-dump this. It was hard enough finding this dump as people don't want to share QNX for some reason
Unless the original owner replies to my re-dump request I fear this is the only copy we have access too.
https://www.mediafire.com/file/yd27z1p6 ... w.rar/file
The machine must have gone bonkers when dumping because of all the error messages. Each USB packet is serialised and DTC will complain when a packet is missing and mark the read as bad. So this dump must have taken ages with a dozen error messages per track.
I'd recommend you have the output piped to a log file so there's a record of each dump. Also, just checked, DTC will also spit out errors if you try to read the dump to convert it.
DTC even complains when the dump is "replayed" based on the raw files.
If you simply run the stream files through DTC (e.g. dtc -m1 -fdump/q* -k2 -i) you will see plenty of messages like these...:
00.0 : Bad stream position
00.0 : Read operation failed
62.0 : The streaming device reported a buffering error
62.0 : Read operation failed
The USB connection was poor or the drive electronics generated way too much noise.
In the latter case you should really set the density line for dumping to DD mode, e.g. -dd1
In the first case, make sure that you are not using a USB hub etc.
If we can get a good stream dump of the disks (ie you don't get any of the above errors for the tracks dumped), I am happy to take a look about writing them back to disk
Here is the zip with all the files. Copy protection was removed on these emulator images. (The KF dumps are original and un-modified)
The protection can be bypassed by modifying qnx12_boot.img in a hex editor.
Patch byte at 0x004a5a9, change from 0x74 to 0xEB
0x74 is a JZ instruction
0xEB is an unconditional JMP.
https://www.mediafire.com/file/4crkqj4e ... e.zip/file
In this case all tracks that are damaged (have missing data etc.) are apparently not used or you haven't used the program to it's fullest extent and not yet accessed data stored on these tracks.
Also, using something in emulation is vastly different than writing something to disk. In emulation you just present whatever you want to the program. It can come off a virtual floppy, memory save state etc. On a real floppy disk data is written differently than it's read back. E.g. pre-compensation is used to compensate for bit drift (timing changes) related to opposing forces (magnets) repelling each other. So if this is just about the protection track it can be anything. KF can write whatever needs to be written, but you probably need to pre-process the data in a way that after writing back it reads back as expected by the program.
Hope this helps.
Also note that the disks use an odd sector interleave.
BTW, that second DOSSYS disk is a complete ripped up mess in the SCP dumps, but the rest of the SCP dumps help confirm the decoded images are good.
So, with this much noise/damage/whatever the flux images can not be written "as is" to a real disk. In this case the lowest common denominator is ImageDisk format. Convert to ImageDisk, and then create fresh flux images based on the ImageDisk images.