[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



pitz a �crit :
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.

Before doing anything there is a point to clarify: at one step or another, we have to reproduce some features of the IWM (mainly serialize & unserialize), which is patented. Is this an issue ???