[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Looking for "Ultima II" .nib images

Andy McFadden wrote:

Michael J. Mahon <mjmahon@aol.com> wrote:


But I also think that pushing for a new emulator-supported format
that handles less than 99.9% (100% is always a problem ;-) of all
protected disks isn't worth the effort.



You need:

 (1) Nibbles with self sync information.
  1a. You can clear the high bit on bytes > 8 bits, and
  1b. have a parallel bit map for 9 vs 10.

 (2) Track lengths.

 (3) Track synchronization.  Tracks should line up according to the index
  hole, and emulators can emulate the amount of data that passes when
  seeking the disk head.  (May actually want to specify whether the sync
  is index-based, like FDI, or just the result of a track-to-track seek,
  like something SST would generate.)


Of course, an Apple II has no way of knowing anything about the index
hole, so that info is icing on the cake.  Relative track sync is all
that matters to an Apple II.


 (4) Half tracks.  The disk head is large enough that you should be able
  to pick up quarter tracks by examining the adjacent half tracks.  (This
  would require byte-accurate sync if you were trying to examine both
  tracks simulataneously.  Might be easier to just read quarter tracks.
  You still need sync for it to be meaningful, because the tracks overlap
  so much, but it has a looser tolerance.)


Reading on quarter tracks, coupled with "weak bit" analysis, can be
used to determine the actual track alignments used in writing.  This
could be useful.


The .NIB format has none of the above.  The TrackStar .APP format has
track lengths and optional half tracks.  The raw FDI format does (1),
(2), and (3); I can't remember if it does half tracks.  A relatively
simple track read function on an Apple II could deliver (1a), (2), and
(4); getting (1b) and (3) are harder.


Stephen Thomas has written a *very* short, but sophisiticated, DPLL-type
track read routine that determines the length of mixed 8-, 9-, and
10-bit nibbles on the fly.  I'll ask him if he'd like to publish it.


In some respects (1b) is only interesting to emulators, and probably not
even all that interesting for them.  For a real disk, if you want your
nibble count to come out right, you need to add or remove leading 0s from
sync bytes (and possibly normal bytes) to stretch the track out, so it's
not really useful for making a copy of the original.


But this kind of bit stuffing to adjust track length (as opposed to
tweaking the disk speed) can interfere with some copy protection
schemes that look for nibble lengths as part of a signature.


In theory a track doesn't need to be an integral number of bytes.  This
is handled by raw FDI.  Probably not an interesting case.


Agreed.

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."