Re: Hardware musings

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

Ed Eastman wrote:
> Michael J. Mahon wrote:
>
> > Ed Eastman wrote:
> >
> > > Lets see, 4us per bit, .2s per track = 50k bits +3% means we would 
> > > need about 6.25k per track, ...
> > > Of course at the front end you would want to place a table of all the 
> > > tracks 0 through 40 including the quarter tracks.
>
>
> > And then there is the 4x to save every quarter track
>
>
> Not necessarily.  Did you note the part about a table at the front 
> listing each track length?  The table would have an entry for each track 
> stored and most games we would have parameters to tell us which tracks 
> needed to be stored.  So if it was spiraling, the file may end up being 
> larger as one must capture the quarter track data as well and put it in 
> the image.  But you would not store tracks that contained no viable data.

The problem is that there is no algorithmic way of determining what is
"data" on a track, fractional or otherwise, since the track may be
written full of data (which may or may not look valid) just for the
purpose of containing one or more "magic" nibbles at certain rotational
angles in certain track positions.

Only by "observing" the action of the program can you determine what
condition(s) it is looking for.

> > That would also involve keeping track of the number of actual/emulated
> > Apple cycles that have elapsed between the seek phase changing and the
> > data latch being sampled.
>
>
> Yes,it would, that's the point of the counter and latch emulation.

OK...

> > Are you thinking about a more sophisticated version of the "virtual
> > disk" that would be attached to a real Apple II, or are you still
> > thinking of a drive external to a PC that would be accessed by
> > an emulator?  (This seems to switch around in this thread.)
>
>
> I am thinking that it would be an interface protocol for a disk II 
> emulation, whether it be developed in hardware for emulating a Disk II 
> for a real Apple, interfacing a disk Ii to a PC, or just using the an 
> image format capable of storing the bits form an Apple II 5.25 disk.
>
> What I have outlined here would allow you do what you were asking for: 
> "a way to access the disk at the nibblized level to handle copy 
> protection,"

I think it falls short (as I explain below).  I also suspect that
*every* reasonably space-efficient proposal can be defeated by *some*
disk format, and the remaining question is: How many protected titles
are you willing to *not* be able to represent?

> Thankx,
> Ed
>
> 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.

But what do you mean by "track length"?

Every track position will read a number of bits determined only by
the rotation rate of the disk.  Bits are either 0 or 1, not present
or absent.  There is no way of determining whether or not a track's
data is interpretable without understanding the algorithm used to
interpret it.

For unprotected disks, and many protected disks, that algorithm is
enough like RWTS that one can make reasonable guesses about "track
length", but for the general protected disk, that is not possible,
since the disk read routine(s) may be arbitrarily different from
RWTS.

-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."