Re: Hardware musings

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

Ed Eastman wrote:
> mdj wrote:
>
> > Personally I'm not interested in doing the project unless I can come up
> > with a way to access the disk at the nibblized level to handle copy
> > protection,
>
>
> I've put a bunch of thought into this myself.
>
> Lets see, 4us per bit, .2s per track = 50k bits +3% means we would need 
> about 6.25k per track, or 25 256 byte pages.  256k would be the most one 
> would need to hold a 40 track file of A2 nibbles.  Of course at the 
> front end you would want to place a table of all the tracks 0 through 40 
> including the  quarter tracks.  Each entry should have a track length (2 
> bytes) of formatted or 0 of not in use.  You could build the disk 
> sequentially starting with track 0, followed by the data from the next 
> viable track, etc.  The file would vary in length in 6.25k increments. 
> Standard disk image would be 36 track * 6.25k length + .25 header or 
> 231k  Plus or minus.

And then there is the 4x to save every quarter track (it might be where
the data is) and some way of associating the timing (angle) with each
bit (not so bad if you really store every bit, not every Woz machine
"nibble")--but you must also re-read each (fractional) track a few
times to discover which are the "hard" bits and which are "soft" bits
resulting from noise and too many consecutive 0's.

The full problem is pretty bad, compared to the "normal" case.

> SST would need to be rewritten to save data in this format.  Emulators 
> would probably also want to incorporate this new format.  Maybe make a 
> new extension of apple2 nibble or a2n?  How about .bst for bitstream?

Exactly.  The problem is functionally identical to the definition of a
new disk image format capable of representing *any* disk readable by
an Apple II (note that some of these disks may not be *writable* by an
Apple II).

> The hardware would need several things:
> - an asynchronous 4us timing circuit to 'rotate the disk' and point into 
> the track bit stream buffer for a read/write operation.
>
> - A latch to push/ pull bits to/ from the bit stream.
>
> - Have the bit read routing 'randomly' change the read more than 2 
> sequential 0s as 1s.  (if easy)

You can only do this if you have read the track multiple times to find
that those 1's you read weren't really "hard" data.

> - Have the write routine place the bits in the latch into the track bit 
> stream
>
> - Have a timing circuit emulate the timing of a track seek and set the 
> bit stream to the proper place.

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.

> So the device would work something like this:
>
> Timer advances at 4us rate (rotate disk bits)
>
> On Read or write command: Add timer + Mod tracklength + track offset = 
> bits to start reading.  Load bits into the latch as timer advances. 
> Clock them in until a read is requested or stop and 'latch' if you get 
> high bit to MSB, or just write the 8 bits into the stream at the proper 
> offset.
>
> On Track change command, recalculate track offset, add seek delay to 
> timer for 'synchronizing' the bit stream.
>
> Hardware should account for these asynchronous commands:
> Motor on/ off
> Stepper motor phase 0-4
> Rotate bits into latch on read
> Clear latch (even if a other operation is in progress)
> Write latch into bitstream
>
> Signals to send back:
> Latch MSB is 1
> Data in the latch

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

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