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

["mdj" <mdj.mdj@gmail.com>]

Michael J. Mahon wrote:

> > It would, however, look really really cool having a little box with a
> > PC connection + a 50 pin card edge connector sitting exposed on it's
> > top surface ;-)
>
> I have to admit, I really like that, too--and it pretty much eliminates
> the need to label the box for its function.  ;-)

:-) Except the hopefully unnecessary "Incredible Woz Machines Only"

> As a long-time hardware/software guy, I always look for an elegant
> software hack before turning into a solder slinger, but both domains
> have their rewards.  ;-)

Indeed. In an ideal world, we'd have both solutions.

> All legacy I/O in PCs is controlled through several layers of bus
> conversion, terminating in a virtual ISA bus running at original PC
> speed.  Not only is the ISA bus slow, there are lots of opportunities
> for contention and non-deterministic delays getting to it from the
> processor.

That's what I figured. Many devices manage something in the vicinity of
1mb/s on the parallel port, but this has been possible since the days
of the 386, where the legacy bus was not virtual.

> Needless to say, when I put a scope on the parallel port, I was
> quite disillusioned.  That's when I packed up my "trivial" design
> and moved on to other things...  ;-(
>
> > In any case, it might be worth checking out the throughput of
> > USB-Parallel dongles; these things might allow significantly higher
> > performance.
>
> Bandwidth, maybe--latency, never.  And deterministic timing--forget it!
> USB is a *network*, not a bus!

Yes. When there's good weather on the network, you might get away with
it, until somebody whips up a breeze by moving a mouse, printing a
document, etc.

> Anything you attach to USB must be "loosely coupled" on a scale of
> at least tens of microseconds.

That's true. It's a design concession I'd be prepared to make to have
something working. With some simple buffering, you could move the
timing dependent operations down to the PIC and avoid many of the
hassles. This would work with either a parallel port design or USB.

My main gripe with using USB directly is the need to write a driver for
the peripheral, where if you use legacy I/O you avoid that. I imagine
the USB capable PIC's out there provide a generic driver, which makes
the device look a serial port on the host.

This would make it impossible to directly interface the device to an
emulator, well, at least as a raw IWM device - you could add it via
smartport. Indeed, Smartport over USB would be an excellent design,
where we not attempting to copy protected disks.