Re: Upcoming project: virtual hard drive for //c and IIgs

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

Cedric Peltier wrote:
> Steven Hirsch a �crit :
> > Peltier Cedric wrote:
> >
> > > > There are plenty of examples out there showing how such a driver 
> > > > might be done for Linux.  Poke around for sio2pc (Atari) and 
> > > > Drivewire (Tandy CoCo).
> >
> > > Maybe a driver for the smartbus is possible under linux, but I don't 
> > > know if we could sample reliably a 250KHz serial line through even 
> > > modern PC I/O under a multitasking environnement (I will give it a 
> > > try) without a dedicated hardware. From my point of view, using such 
> > > dedicated hardware on a modern system look pointless for the task, 
> > > better to do a stand alone system from scratch interfacing the 
> > > smartbus to IDE or SD. I hope I exposed constraints clearly.
> >
> > I don't know enough about the smartbus protocol to speak 
> > authoritatively, but the parallel port hardware on more recent systems 
> > should be capable of 1Mhz. operation.  How tight are the timing 
> > margins?  Where can I find a timing diagram for the bus?
> >
> > If it could be done with a small amount of logic or FPGA, that would 
> > still be of interest to me.
> >
> > Steve
>
> I spent most of my time searching data, and what we could find is far to 
> be complete, some part are not documented at all, but this is no more an 
> issue now. Timing are not available under the form of diagrams, so far I 
> remember. They are required only for the two serial lines during data 
> exchanges, but signaling sequences diagrams are availables. 
> Nevertheless, I could give you all required informations in time.
>
> The timing is tight only from a 486 point of view where // port I/O 
> require more than 2us and the bits to receive are 4us width. Doing some 
> sort of software PLL with that is not so easy, and the frequency is too 
> high to use interrupt driven software.
> In the other direction we need to send pulses, 1 to 3us width is ok, 
> cycles are still 4us width, and the apple could manage some timing error 
> has it use PLL himself at each start of bytes.
>
> What have you in mind, some sort of buffering on the parallel port to 
> manage the serials lines using bit shifting ? This is actually the 
> bottleneck of the system. Such hardware could stay cheap enough I guess.

I appreciate the difficulty of what you have done.

Despite the fact that x86 processors have become blindingly fast,
the legacy I/O subsystem remains the same old legacy speed, and
the newer processors are almost impossible to program deterministically.

Over a decade ago, I started down the path of controlling a Disk ][
from the parallel port of a PC, and found that it required taking
over the system (since interrupts could not be tolerated).  Sampling
through the parallel port was just too slow to make it work without
adding a serial-in/parallel-out shift register.

-michael

NadaNet 3.0 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

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