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

[pitz <pitz.wong@gmail.com>]

On Apr 26, 3:12 pm, Cedric Peltier <pced...@hotmail.com> 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'm definitely interested.  It's actually capturing the necessary
timings that would be of most interest (and most difficult).  Once we
know that, the port pins can be interfaced with whatever hardware the
engineers in this newsgroup can come up with.  If the PC parallel port
is not fast enough to keep up with the necessary timings, they'll find
a different way of interfacing with it.  A hardware serializer/
deserializer into a USB interface with the right driver could even be
doable.