Hello, First of all, I don't know of a solution to your problem. However, I'll try to make you understand why the methods you're trying won't work. First, you need to understand what a disk image is, and what a nibble image is. A disk image is 143360 bytes. This file contains what you might call the high-level representation of the contents of the disk. For example, on track 17, sector 0 of a disk image is the exact sequence of bytes a program would receive when telling DOS to read track 17, sector 0 of the disk. There are only the 256 bytes of actual data. There are no checksum bytes or other data which DOS uses to validate the sector. On an emulator which uses .dsk files, most likely every disk which is properly inserted is perfect. Since there are no checksums, the emulator probably has to generate them to satisfy DOS that the data is OK. A nibble file, on the other hand, contains more data. This type of file contains the raw, low-level contents of the disk. When DOS reads a sector, what it actually gets from the drive itself is this low-level contents. This data includes not only the 256 data bytes, but checksum and other data. Any time you get an I/O error, that is because DOS is unable to validate the data on the sector it is trying to read, because either the data itself or the validation information has been corrupted. The way many copy protection schemes work is to intentionally mess something up about the disk. This could be in one particular area, or the entire disk. But anyway, the point is that normal DOS can not read the disk, or at least it doesn't think it can. Something about the low-level data has been messed up. When a nibble file is converted to a .dsk file, all the checksum data is eliminated so the disk appears to be perfect. Therefore, when the protected program checks to make sure it's legit, the check fails as the disk looks perfect so it must be an illegally made copy. Even if you use nibble copiers on the disk image, they won't work for the simple reason that the original disk they're copying from is, for all practical purposes, a perfectly ordinary disk. So the copies won't be any good either. Even converting the copies back to nibble files won't make them good since the intentionally messed up information was lost in the original conversion and cannot now be restored. I found a program called nib2file for Prodos, but it only works one way, converting a disk into a nibble image. It can not convert a nibble image to a real disk. Hope this helps! Jayson. "amauget" wrote in message news:418d7040$0$18478$8fcfb975@news.wanadoo.fr... > Hi All ! > > I'm currently trying to write .nib (protected) image files back to 5"1/4 > disks. > I can't use the classic ADT solution that works only with .dsk files. > > I've read FAQs but unfortunately, don't find any method that works. Here are > the facts : > > First, I've tried to use convertors such as NIB2DSK.EXE. But the DSK files > aren't working. > Then, I've tried to copy the .nib to a .dsk using an emulator and various > copy programs (Locksmith 5.0, Disk Muncher, CopyII+ 7.0, ...). All fail. > Finaly, I've tried an interresting (but not working) solution : > - load the .nib file into an emulator, > - use SST (Saltine's Super Transcopy) to make 2 dsk files from one nib file, > - send the 2 dsk files (via ADTGS) to my Apple II GS > - use SST once again to write the 2 DSK onto 1 disk. > Once again, it fails. > > I'm stuck ! Have you got any clue before I'm going crazy ? > > Thanx > > Antony > > amauget wrote: > Finaly, I've tried an interresting (but not working) solution : > - load the .nib file into an emulator, > - use SST (Saltine's Super Transcopy) to make 2 dsk files from one nib file, > - send the 2 dsk files (via ADTGS) to my Apple II GS > - use SST once again to write the 2 DSK onto 1 disk. > Once again, it fails. That's the only approach I would have expected to work. In theory, if the nib data got carried successfully one way, it can go back the other way. In practice, the first time it was read, there were some nice self-sync bytes pointing the way, and the track didn't have a bunch of garbage bytes to pad it out to exactly 6656 bytes. So it's possible that it lost something in the translation going backwards. An easy way to test this would be to take the two DSK images you made in step two and immediately recombine them on the emulator into a new NIB file. if the new .nib doesn't work, then you know that splitting the original .nib into two pieces failed. -- Send mail to fadden@fadden.com (Andy McFadden) - http://www.fadden.com/ CD-Recordable FAQ - http://www.cdrfaq.org/ CiderPress Apple II archive utility for Windows - http://www.faddensoft.com/ Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/ On Sun, 7 Nov 2004, "Antony Mauget" wrote: >Andy, > >I don't give that point but I did what you say : merging the 2 DSK in one >NIB file on the emulateur perfectly works ! Antony, What you are trying to do, in theory, should work. However in practice, it doesn't. May years ago I spoke to Bob Colbert (aka Saltine) who wrote the program about this. He believes the problem is a bug in SST that prevents it from properly creating the two dsk files from the original .nib when done from an emulator. He had no resolution for this problem. Bottom line: Right now there is no software for the Apple II that allows creating a physical disk from a .nib file. Mark R. Percival - RTC Host - Syndicomm Online Apple II Forum "Midweek Madness!" Every Wednesday Night : 7:00 PM - 9:00 PM Pacific Time http://www.syndicomm.com Mark Percival wrote: > What you are trying to do, in theory, should work. However in > practice, it doesn't. May years ago I spoke to Bob Colbert (aka > Saltine) who wrote the program about this. He believes the problem is > a bug in SST that prevents it from properly creating the two dsk files > from the original .nib when done from an emulator. He had no > resolution for this problem. It looks like that much works though, since you can run it in and out of SST repeatedly in an emulator and have it work. Sounds like the problem is on the real Apple II side. It'd be interesting to look at the written tracks in a nibble editor to see if sectors are being lost or self-sync bytes aren't getting written. Or maybe the 6656-byte track length is getting propagated, and SST on the physical hardware can't manage to stuff all 6656 bytes onto the disk. -- Send mail to fadden@fadden.com (Andy McFadden) - http://www.fadden.com/ CD-Recordable FAQ - http://www.cdrfaq.org/ CiderPress Apple II archive utility for Windows - http://www.faddensoft.com/ Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/ Andy McFadden wrote: >Mark Percival wrote: >> What you are trying to do, in theory, should work. However in >> practice, it doesn't. May years ago I spoke to Bob Colbert (aka >> Saltine) who wrote the program about this. He believes the problem is >> a bug in SST that prevents it from properly creating the two dsk files >> from the original .nib when done from an emulator. He had no >> resolution for this problem. > >It looks like that much works though, since you can run it in and out of >SST repeatedly in an emulator and have it work. > >Sounds like the problem is on the real Apple II side. It'd be interesting >to look at the written tracks in a nibble editor to see if sectors are >being lost or self-sync bytes aren't getting written. Or maybe the >6656-byte track length is getting propagated, and SST on the physical >hardware can't manage to stuff all 6656 bytes onto the disk. I expect that SST doesn't verify that the rotational speed of the target disk will allow it to actually hold 6656 nibbles, and therefore overwrites part of the track on a fast drive. If that's the case, then setting a drive a little slow ought to make it work... -michael Check out parallel computing for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/