Re: Hardware musings

["Michael J. Mahon" <mjmahon@aol.com>]

Ed Eastman wrote:
> Ed Eastman wrote:
>
> > PS. Here is a sample of what I would expect in the data file:
> >
> > Apple 2 Bit Stream format for the 5.25 bit copy replication of the 
> > disk II bit stream.  Note each track is pre-synchronized, the emulator 
> > or hardware would need to keep track of the spinning 'angle' and the 
> > track to track seek time for protected disks only.  (See LSB of 
> > FlagByte1.)
> >
> > Header section, 512 bytes:
> > 'Apple 2 Bit stream'
> > Rev#: two bytes
> > Image Checksum: 4 bytes  (algorithm TBD)
> > FlagByte0: 1 byte
> >    MSB = High = Write Protect
> >    LSB = Protected disk
> > other misc flags and bytes available as revisions are made
> >
> > Track table offset 32 (157 entries, one per possible track):
> >     0: two byte length, one byte checksum
> >  0.25: two byte length, one byte checksum
> >  0.50: two byte length, one byte checksum
> >  0.75: two byte length, one byte checksum
> >     1: two byte length, one byte checksum
> >  1.25: two byte length, one byte checksum
> >  1.50: two byte length, one byte checksum
> >  1.75: two byte length, one byte checksum
> >     2: two byte length, one byte checksum
> > ...
> >    38: two byte length, one byte checksum
> > 38.25: two byte length, one byte checksum
> > 38.50: two byte length, one byte checksum
> > 38.75: two byte length, one byte checksum
> >    39: two byte length, one byte checksum
> > 39.25: two byte length, one byte checksum
> > 39.50: two byte length, one byte checksum
> > 39.75: two byte length, one byte checksum
> >    40: two byte length, one byte checksum
> >
> > Offset 512bytes: Track 0 bit stream (always)
> > + Offset 6.25k: 2nd stored track bit stream
> > + Offset 6.25k: third stored track bit stream
> > ...
> > through the last stored track
> >
> > File length would vary depending on how many entries in the track table.
>
>
>
> And now that I have it written instead of in my head, I see a couple 
> improvements that could be made right away.  There could be a 'normal 
> flag and thus reduce the size of the necessary table.

But you know that there are some programs which appear to copy normally
but fail after some amount of game play.

It is not possible to know that a disk is "normal" except by doing
"sufficient" testing, which is beyond an algorithmic procedure.

It is always possible that a program tests for a condition which is
a "don't care" in a normal disk, but which is fully specified in the
"original" disk--in fact, this is a fairly sophisticated scheme of
copy-protection.  ;-)

For example, as a result of a small bug, RWTS fails to write the
third data epilog nibble completely, making it unreliable when read.
To compensate, RWTS does not check this nibble when reading.

But a protected program could use a modified RWTS that correctly
writes the nibble, and then fully checks it on reading.  Such a
disk appears to be completely "normal", yet is easily distinguished
from a disk written by a "normal" RWTS.

Another example is a "nibble count" track containing lots of random
nibbles, but also a short pattern of "magic" nibbles at a specific
rotational angle relative to another track.

Such a track could appear to have virtually any length--in fact, if
the nibbles were written in isolation with the rest of the track
written as 0's, then the track would appear to be *almost* completely
random--it would be easy to miss the short "magic" pattern in the
sea of random nibbles.

> Also use a binary table instead of a byte sized table.  Use a half a 
> byte or nibble to show tracks in storage.
>
> 1 0 1 0 would be track x, not 0.25, 0.5, not 0.75, etc.
>
> This way the length table and checksums could be reduced in size to the 
> actual number of tracks stored x3 bytes each.  This may also make room 
> for a larger checksum if desired by the image creator.

What exactly is the purpose of all the checksums?  Surely it isn't to
provide error detection of file corruption.  (One CRC would certainly
be sufficient for that purpose.)

> I also noted that unless quarter tracking on a spiral, no disk will have 
> tracks closer than .75 tracks away.  or a total of 48 tracks stored 
> assuming you used quarter tracking between 35 and 40.

And again, the problem is knowing when data is relevant and when it
isn't.

> It all gets a bit complicated.  Even if you assume only 36 tracks in use.
>
> I think there should also be a 'non standard' flag.  A bit for 40 
> tracks, a bit for half tracking, and an additional bit for quarter 
> tracking.  That way the track storage table can be managed.  Of course a 
> static mapping as suggested earlier may not save many bytes in the image 
> file, but most of the time it will be emulated A2s anyway.
>
> Well whomever writes the program to read a bit stream from an A2 
> diskette can save the data and make a table however they like.

Maybe I sholdn't worry too much about file size in this day and age, but
a 6x or so expansion over a normal image does seem a bit severe, and I
don't think there is any algorithmic way to be sure that any of those
bits can be ignored.

-michael

NadaNet networking for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

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