[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DSK to NIB Instruction
- Subject: Re: DSK to NIB Instruction
- From: Andy McFadden <fadden@fadden.com>
- Date: Mon, 10 Oct 2005 15:44:00 GMT
- Newsgroups: comp.sys.apple2
- Organization: faddenInternet, Inc.
- References: <eKW1f.1556$B14.1455@newssvr11.news.prodigy.com> <VZb2f.1720$Aw.30993@typhoon.sonic.net> <did70a$1qv7$1@merope.saaf.se> <didmu2$evg$1@unlnews.unl.edu> <didqc6$21gq$1@merope.saaf.se>
- Sender: Andy McFadden <fadden@adsl-209-204-141-120.sonic.net>
- User-agent: tin/1.4.7-20030322 ("Suggestions") (UNIX) (Linux/2.6.11-1.1369_FC4 (i686))
- Xref: g2news1.google.com comp.sys.apple2:6046
Paul Schlyter <pausch@saaf.se> wrote:
> This of course means that the nib image files aren't an accurate
> representation of the bits on the floppy. To become more accurate,
> nib files should really be a bit stream rather than a byte stream,
> where sync nibbles are stored as 10 instead of 8 bits. Of course
> all normal nibbles might then start at any bit within a byte, and
> the lowest-level processing of the nib file would be much slower
> (to read one nibble one would usually have to read two bytes from
> the nib file and then shift and mask these two bytes into the "nibble"
> byte one wanted to read).
It's actually much simpler than that. The timing on an Apple II is such
that you can detect which bytes are sync bytes, but not how large they
are, unless (a) you can identify your position with great accuracy and
(b) you can do the timing over a long series of sync bytes.
So unless you're confronted with a scheme that uses both 9-bit and 10-bit
bytes, all you need is one bit to say "it's a sync byte" and a per-disk
or per-track flag that says "9 bits" or "10 bits".
All nibble values have the high bit set, so you just store it with the
high bit clear if it's a sync byte.
With this, and a header that identifies the number of tracks and the
length of each track, we'd be in much better shape. The hard part here
is that we don't have source code for SST, which makes it hard to write
a tool that creates these disks without reinventing the wheel.
What we *do* have is Disk2FDI. The FDI format has the exact track length,
can identify 9-bit vs. 10-bit sync bytes, and so on. Converting raw .FDI
to .NIB is vaguely criminal. :-) There's also no "raw" format for 3.5"
media, so they always have to be converted to .dsk.
--
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/