Re: Hardware musings

[Ed Eastman <noone@nowhere.net>]

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.

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

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

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.