Write .nib files back to disk
amauget
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
Jayson Smith
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" <ama...@hotmail.com> wrote in message
news:418d7040$0$18478$8fcf...@news.wanadoo.fr...
Andy McFadden
> 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 fad...@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/
Antony Mauget
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 !
"Andy McFadden" <fad...@fadden.com> a écrit dans le message de news:
fekjd.3939$_3.4...@typhoon.sonic.net...
Antony Mauget
Thank you for your explinations but I already know the *big* difference
between DSK and NIB files.
Now, I think, like Andy said in his reply, that the NIB images could be
transfer back to disk. I mean, in real Apple II world, there is no NIB or
DSK format ! Just physical disk and drive... By the way, if I take my two
DSK files and merging them in one NIB file on the emulator, it perfectly
works ! It means there is no lost data.
The real question is what is the process to make a NIB file. I just want to
reverse this process.
Antony
"Jayson Smith" <nospamratgu...@nospamplease.bellsouth.ihatespam.net>
a écrit dans le message de news:
ohfjd.47610$Tq1....@bignews1.bellsouth.net...
Mark Percival
>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
Andy McFadden
> 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.
Michael J. Mahon
>Mark Percival <markR...@syndicomm.com> 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/