Re: [Vaporware alert!] Portable Apple II Clone Concept

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

mdj wrote:
> Michael J. Mahon wrote:
>
>
> > Designing a virtual Disk ][ that handles protection schemes just like
> > a real one would be quite a challenge--as would the data representation
> > of the image to load it up and the reading scheme to recover the exact
> > format of the protected disk in the first place!
>
>
> I agree that an optimal representation would be quite tricky, however I
> believe that a naive data model, which simply captures the bitstream or
> fluxstream, that passes under the read head, plus a table/index of what
> particular head positions these data streams exist at would be
> sufficient. If its resolution is sufficiently high as to match or
> exceed the maximum read rate of the Disk II/Apple II combination, then
> theoretically any disk that's readable can be represented.
>
> Of course, the 'tracks' of data would need to be represented
> synchronised, and 'played' back as such.
>
> The only holes I can see with such an appoach is the volume of data
> created in such a process, and it may be impossible to capture it at
> such a rate on an Apple II
>
> The data should however be readily compressible using a simple
> technique.
>
> To me, the logical data representation is the easy part. Implementing
> it in a useable way is the challenge.

I agree.  And part of the problem is that you may need to read
the disk with quarter-track resolution.  It is, unfortunately,
impossible to recognize what "valid data" is, so the only compression
that can safely be done is to fractional track data that is read
as nearly identical to adjacent reads.

And there is still a need to represent "soft" bits that were
written as "0" strings but are read as "random" data.

> It would be really nice if somebody would come up with an interface for
> a PC that can control a Disk II. It should be reasonably easy to
> connect direct to the drive and reconstruct the IWM in software, and a
> PC parallel port probably has enough I/O pins to handle the job.

I actually went down this path for a month or two a decade ago,
and the problem with any lof the "legacy" I/O ports on a PC is
that they are relatively slow.  I found that I could not read
a bit on the parallel port more often than about 1-2 microseconds,
which wasn't good enough resolution to do it all in software.

The Disk ][ controller samples the head signal at 2MHz, so that
would be fast enough to do whatever needs to be done.

> To be really hardcore, you could bypass the drive electronics and
> sample the read/write head with an ADC, capture a couple of seconds of
> data per possible disk head position, and use a software analysis to
> process the data. Using this approach, you could determine the exact
> data stream from the flux transitions, and the exact locations of
> 'real' tracks by comparing adjacent head position samples, which should
> show the same signal at lower strength, then be replaced by a new
> signal as you approach the next 'real' track. It'd be possible with
> this scheme to replicate any Apple II disk, regardless of how it'd been
> protected.

Yep, that's the level of analysis required to capture "what's on
the disk".

> Unfortunately I think the hardcore approach would be used by so few
> individuals that it wouldn't capture enough disk images to justify the
> effort of constructing it.
>
> A simple to build/cheap to buy interface however, that integrated into
> an emulator such that Copy II+ could be used to image the titles, might
> get enough attention to make it worth the effort.

It's always a cost-benefit tradeoff.  "Universal" solutions are
a bitch!

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

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