Egan Ford

On Feb 6, 10:19*am, schmidtd <schmi...@my-deja.com> wrote:
> On Feb 5, 11:30*am, Egan Ford <dataj...@gmail.com> wrote:
>
> > 1. *Is there a CLI tool (with source, preferably POSIX) that will
> > convert unprotected NIB to DSK? *I've searched and have not found much
> > (with links that still exist). *BTW, is there a NIB format description
> > floating around anywhere?
>
> Looks like BLuRry took care of you there. *But what do you have an
> unprotected .NIB for in the first place?

Is it safe to assume that some .nibs floating around out there were
created just because that is the imaging format they used? Or should
the safe assumption be that .nib was used because nothing else would
work?

> No such assumption of any kind is made. *If they're not 143360,
> they're bad - or they're not an undecorated .dsk/.do/.po. *Like
> Brendan said, inspection usually will show you what the problem is.
> I've seen random garbage at the end of too-long images, and if they're
> short... zeroes are your only option.

Thanks.

BLuRry

You could look at the file size and see if it is a multiple of 35 -- anything not a multiple of 35 is a disk image of uneven size and should be thrownout. Take the file size and divide by 35, and that is the size of each track. Then make a ring buffer for each track, such that reading the end of the track jumps back to the start of the track. There's your disk emulation. :-D

The way that the computer reads a given track is to move the head until it finds sector headers for that track, and then it keeps reading until it finds the header for the given track/sector. After that it grabs the next chunk (the 6/2 encoded data) and then decodes the data. it is possible that your image has more junk inbetween the sectors -- or there is extra and/or repeated data at the end of each track.

If you scan for sector headers and inventory what is actually in the image,it might make more sense -- assuming that the disk uses the same sort of sector header format that Dos and Prodos use. Otherwise all bets are off and you have to roll your own deprotection scheme to translate it and gut thecustom RWTS in favor of your own. Or buy something nice for Antoine and he'll probably crack it. :-D

-b

schmidtd

On Feb 6, 12:27*pm, Egan Ford <dataj...@gmail.com> wrote:
> On Feb 6, 10:19*am, schmidtd <schmi...@my-deja.com> wrote:
>
> > On Feb 5, 11:30*am, Egan Ford <dataj...@gmail.com> wrote:
>
> > > 1. *Is there a CLI tool (with source, preferably POSIX) that will
> > > convert unprotected NIB to DSK? *I've searched and have not found much
> > > (with links that still exist). *BTW, is there a NIB format description
> > > floating around anywhere?
>
> > Looks like BLuRry took care of you there. *But what do you have an
> > unprotected .NIB for in the first place?
>
> Is it safe to assume that some .nibs floating around out there were
> created just because that is the imaging format they used? *Or should
> the safe assumption be that .nib was used because nothing else would
> work?

It is safe to assume that .NIBs were used in order to capture some
light forms of copy protection, or a volume identifier in DOS.
Otherwise, the much simpler .dsk/.do/.po would have sufficed. No one
would have gone through the trouble if it weren't required for some
reason or another. Oh, just occurring to me now: unprotected 13-
sector disks can be imaged using a .NIB. That might have happened if
they didn't have Linards' 13-sector ADT yet.

Antoine Vignau

On 6 fév, 18:47, BLuRry <brendan.rob...@gmail.com> wrote:
> If you scan for sector headers and inventory what is actually in the image, it might make more sense -- assuming that the disk uses the same sort ofsector header format that Dos and Prodos use. *Otherwise all bets are off and you have to roll your own deprotection scheme to translate it and gutthe custom RWTS in favor of your own. *Or buy something nice for Antoineand he'll probably crack it. *:-D
>
> -b

Miam miam, I am hungry but... I still have dozens of disks to crack
(Micro League Baseball, old Apple titles, Captain Crunch stuff,
Mandragore, Hold-Up, Faial, Calendar crafter...) Pfewwww, too many
things, too few time (ahem)

Antoine

Vladimir Ivanov

On Sun, 5 Feb 2012, Egan Ford wrote:

> BTW, is there a NIB format description floating around anywhere?

Perhaps, but it's dead simple - 35 tracks of 6656 bytes (6.5 KB) each.
Each byte represents "nibble" as read from the disk controller. Since this
size is bigger than real track, it also contains leftovers that at least
in the case of unprotected software should be harmless (they can be even
partial sector). Each track should be regarded as circular and there is no
guarantee how it will start (like, in the middle of a sector).

HTH.

BLuRry

Absolutely correct! Each track is just a circular buffer, but there's no specific size it really has to be -- it's just a certain size by convention because that's how it was originally implemented. As for what goes in eachtrack, it is really up to the format. The RWTS on the firmware is responsible for locating the header for a desired sector and translating the data,and that's where protection schemes start off (assuming they don't do anything funky like half or quarter tracks)

-B

Linards Ticmanis

On 02/06/2012 06:27 PM, Egan Ford wrote:

> Is it safe to assume that some .nibs floating around out there were
> created just because that is the imaging format they used?

Some yes, but not many. I think I've read somewhere that some very early
emulators (maybe up to 1993 or so?) used only NIB, both internally and
externally, so it is conceivable that some of the oldest disk images
were made in that format simply because it was the only one around at
that time.

After that time, almost all NIB images were made to preserve some (of
the simpler) copy protection schemes. Since NIB uses fixed track lengths
and doesn't distinguish between sync and non-sync bytes, it's very hard
to write back to real disks correctly, essentially requires manual
intervention.

As for volume numbers: DOS disks store them *inside* some block too, so
emulators that use DSK could use that byte to build the block headers
for the emulated drive to read, instead of defaulting to $FE. Doesn't
help with non-DOS disks though (that includes ProDOS disks), if the
volume number is important on those, NIB is the way to go. No idea why
nobody thought of putting in a one-byte volume number at the end of DSK
but since they didn't, things are as they are: DSK can't preserve volume
numbers on non-DOS disks, even when everything else is totally standard.

--
Linards Ticmanis

D Finnigan

Linards Ticmanis wrote:
>
> Doesn't
> help with non-DOS disks though (that includes ProDOS disks), if the
> volume number is important on those, NIB is the way to go.

Isn't it that ProDOS disks don't have a volume number?

Mark Stock

Egan Ford wrote:
> 1. Is there a CLI tool (with source, preferably POSIX) that will
> convert unprotected NIB to DSK? I've searched and have not found much
> (with links that still exist). BTW, is there a NIB format description
> floating around anywhere?
>
> 2. From time to time I encounter a DSK file that is not 143360 in
> length. Is the assumption that the rest of the file is zeros?
>
> Thanks.
>

Here's a program for item 2. I used this make some very old partial DSK
files somewhat to mostly usable again.
To build and use it:

make zerofill
/zerofill < undersized.dsk > therightsize.dsk

http://hoop-la.ca/apple2/src/zerofill.c

#include <stdio.h>

#define DISK_LENGTH 143360

int main(int argc, char * argv[])
{
int c;
int i;
int not_end_of_file;

not_end_of_file = 1;
for (i = 0; i < DISK_LENGTH; i++) {
if (not_end_of_file) {
c = getchar();
if (c == EOF) {
c = not_end_of_file = 0;
}
}
putchar(c);
}

return 0;
}

Egan Ford

On Feb 7, 6:17*pm, mmpho...@macgui.com (Mark Stock) wrote:
> Egan Ford wrote:
> > 1. *Is there a CLI tool (with source, preferably POSIX) that will
> > convert unprotected NIB to DSK? *I've searched and have not found much
> > (with links that still exist). *BTW, is there a NIB format description
> > floating around anywhere?
>
> > 2. *From time to time I encounter a DSK file that is not 143360 in
> > length. *Is the assumption that the rest of the file is zeros?
>
> > Thanks.
>
> Here's a program for item 2. *I used this make some very old partial DSK
> files somewhat to mostly usable again.
> To build and use it:
>
> make zerofill
> /zerofill < undersized.dsk > therightsize.dsk
>
> http://hoop-la.ca/apple2/src/zerofill.c
>
> #include <stdio.h>
>
> #define DISK_LENGTH 143360
>
> int main(int argc, char * argv[])
> {
> * * * * int c;
> * * * * int i;
> * * * * int not_end_of_file;
>
> * * * * not_end_of_file = 1;
> * * * * for (i = 0; i < DISK_LENGTH; i++) {
> * * * * * * * * if (not_end_of_file) {
> * * * * * * * * * * * * c = getchar();
> * * * * * * * * * * * * if (c == EOF) {
> * * * * * * * * * * * * * * * * c = not_end_of_file = 0;
> * * * * * * * * * * * * }
> * * * * * * * * }
> * * * * * * * * putchar(c);
> * * * * }
>
> * * * * return 0;
>
>
>
>
>
>
>
> }

Thanks.

Here is my perl version if any are interested.

my $dsk = shift;

if(-s $dsk < 143360) {
open(DSK,">>$dsk") || die("Cannot append to '$dsk'");
print DSK chr(0) x (143360 - (-s $dsk));
close DSK;
}

While I am at it, here is my .po to .do, quick and dirty, needs error
checking:

#include <stdio.h>

typedef struct s {
unsigned char bytes[256];
} sector;

typedef struct t {
sector sectors[16];
} track;

typedef struct d {
track tracks[35];
} disk;


int main(int argc, char **argv)
{
disk po;
FILE *ifp, *ofp;
int i,j,k;
unsigned int xref[]={0x0,0xE,0xD,0xC,0xB,0xA,
0x9,0x8,0x7,0x6,0x5,0x4,0x3,0x2,0x1,0xF};

if ((ifp = fopen(argv[1], "rb")) == NULL) {
fprintf(stderr,"Cannot read: %s\n\n",argv[1]);
return 1;
}

if ((ofp = fopen(argv[2], "w")) == NULL) {
fprintf(stderr,"Cannot write: %s\n\n",argv[2]);
return 1;
}

fread(&po, 143360, 1, ifp);

for(i=0;i<35;i++)
for(j=0;j<16;j++)
for(k=0;k<256;k++)

fprintf(ofp,"%c",po.tracks[i].sectors[xref[j]].bytes[k]);

return 0;
}