Re: .DSK images with 40 tracks?

[mjmahon@aol.com (Michael J. Mahon)]

In article <9307085f.0303130928.1c8b4e30@posting.google.com>,
steve@dosius.zzn.com (Dosius) writes:

>Holger Picker <pickerh@uni-muenster.de> wrote in message
>news:<Pine.A41.4.44.0303130010300.140132-100000@zivunix.uni-muenster.de>..
>
<snip>
>
>> how about introducing 40 track disk images to Dapple][ then? May I suggest
>> the following, please:
>> i) Implement a flag via the disk menu that allows to switch between a 35 and
>> a 40 track disk drive. Let's say it's called drive3540flag.
>> ii) Do a simple file size check to determine whether a .dsk (.do, .po) image
>> has got 35 ot 40 tracks and set up a second flag accordingly. Let's call
this
>> one disk3540flag.
>> iii) Put in a third flag that gets true whenever the disk drive _writes_ to
>> a track > 34. This is to convert a once 35 track disk image to a 40 track
>> disk image if necessary. Call this one write40.
>> iv) When storing a disk image, check a) the disk3540flag. Is it true, then
>> always store as a 40 track disk image. b) Otherwise if 'write40' is set,
>> also store the disk as a 40 track disk image. c) If neither is true, it's
>> still a good old fashioned .dsk 35 track image as before.
>> Perhaps we could see something like this in the next release of Dapple][?
>
>I'll try.  >35 track disks were not uncommon, if even Copy ][+ can do
>36 tracks.
>
>> 
>> Another thing I'd like to know: Is there a disk format somewhere used by
>> emulators which stores a disk as a 80 half-track disk image? (May be
>> compared to the .G64-format used by C64 emulators.) 
>
>Hm, not AFAIK... :\  But we can modify NIB to do that, even if we get
>512K disk images :\
>
>> The point is: even the
>> .nib format does not allow you to store programs that use half tracks as a
>> copy protection. A 80 half-track disk image could be used to store almost
>> everything ever put on a disk as a file for the emulators. 
>
>I know.  It would be real cool to have a disk format, 80 half tracks
>in NIB-6250 format, which could do anything a real disk ][ could do.

How, exactly, does .nib format deal with synchronized tracks?  Are
all .nib files stored in some canonical "synchronized" format, so that
the timing relationships of the track images are preserved?

Certainly, this would be necessary with any half-track format.  And
some "spiral" disks used quarter-tracking, so you might need 4x the
nibble space--512KB wouldn't be enough!

Perhaps some more elegant approach is called for--after all, valid
data cannot exist at the same angular position on adjacent half-
tracks.  This suggests that adjacent half-tracks could be "merged"
into a single "track image" with a little meta-data to say where the
half-track shift occurred.

A similar approach could be used for quarter-tracks, since I think
the experimental evidence was that even 3/4 track separation was
insufficient spacing for reliable data storage at the same angular
position.  So a single nibble-image of a track could hold all the
reliably readable information in four quarter-tracks, and meta-data
could describe where the "shifts" occurred in the track image.

Just discovering what parts of what tracks were meant to be
read with non-integral head positions is a bit sticky, since data
written to a track position could generally be read reliably with
a quarter-track error in head position, provided that the data was
written to a "clean" disk that had been bulk-erased before writing.

It would be an interesting program that could correctly determine
how each (fractional) track was meant to be read without actually
knowing how the program read it.  That could get you back to a
4x expansion over a .nib.  ;-(

<snip>
>
>> Of course, there would still be the problem of how to get the original disk
>> to the PC/Macintosh... I'm afraid, I don't know anything about that. All I
>> could do is to take care about an "accurate" disk emulation. Any ideas 
>> someone?
>
>I'm still trying to figure that out myself ;)
>
>If you have a IIgs and a Mac, you might be able to image a disk onto
>an 800K ProDOS disk, read it on the Mac and transfer it over to a DOS
>disk or to the Internet from there.  (I did do some file transfer with
>an 800K disk and Bernie ][ back in '99, BTW) :)

In a pinch, you could decompose an arbitrary disk into four 5.25"
disks, to be handled as separate .nib disks, with synchronization
all referenced to track 0, sector 0.

-michael

Check out amazing quality 8-bit Apple sound on my
Home page:  http://members.aol.com/MJMahon/