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

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

nyder wrote:
> On Apr 27, 1:43 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> > Cedric Peltier wrote:
> > > Michael J. Mahon a �crit :
> > > > 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

> > > I was very impressed by your Apple crate II :)
> > Thanks!
> >
> > > I wondered if someone tryed to drive a disk II from the parallel port:
> > > your name blinked in my head, and now you confirm it ! ;) truely amazing.
> > I'm sure I'm not the only one considering a PC-implemented RWTS.  ;-)
> >
> > Around the time of 100MHz Pentiums, I thought it would be easy to
> > control a Disk ][, given just a power supply for the drive.  I thought
> > it would be easy to generate and sense pulses with, say, 50ns precision.
> >
> > I did some timing experiments with the parallel port and was amazed at
> > how slow it was.  If a PC were more like an Apple II, it would have been
> > trivial!  ;-)
> >
> > -michael
>
> How many different Pentiums did you try it on?    It's not the pentium
> that has the trouble, it's what chip that is used to control the
> parellel port.   I've heard of different projects asking for 486's
> before because of timing issues, but i've also heard of people using
> pentiums that worked, some of them didn't.   and from what i
> understood, it depended on what chip is controlling the parellel port.
There were three problems.

First, the "legacy I/O" is handled by a "super I/O" chip, which runs
the entire legacy system as if it were a PC AT.

Second, the Pentium uses a couple levels of caching, which introduces
significant timing nondeterminacy in comparison to, say, an Apple's
6502, where an instruction always takes exactly the same number of
cycles--you can depend on it.

Third, I was hoping for a solution that ran under Windows, perhaps by
disabling interrupts for short periods.  No such luck!  Windows is
always doing a hundred other things while I'm trying to keep time.  ;-)

> Not sure about your next of the woods, but 486's are hard to find for
> cheap here in seattle.   I've been trying to get my hands on one for
> years.   of course, i'm cheap and don't want to pay for one.  lol

I'm in the Seattle area, too, and I agree that the old 486s are long
gone...unless you get lucky at a garage sale.

> How about an old mac?   020, 030 mac, sure, no one wants to program
> for one, but those seem to be overly abundant, imo.
>
> Actually, I'm looking at my SGI Indy and wondering if it's usefull for
> something like that.  =)

Virtually all "modern" processors (with at least caches) are going to
present a difficult problem in producing accurate execution timing.

I suppose that if a processor is fast enough, with a sufficiently low-
latency interrupt system, it might be possible to synchronize everything
with high-resolution timer interrupts--but I doubt it, since interrupts
are treated by designers as low-frequency events, and must wait behind
pipelines and caches.

Of course, for an "embedded"-type processor, that is often not the case.

> Seems to me, making a pic or something to handle what is needed
> between the apple and modern pc is the only way to go.

That will certainly work--the FC5025 is proof of that.  But, of course,
such solutions are limited to disks that are not heavily copy-protected,
since those would require that significant amounts of 6502 code be
executed in a cycle-accurate manner, with cycle-accurate interactions
with the drive.  Nothing short of a hardware-emulated Apple II could
make that happen, at which point one might just as well use an Apple II!
;-)

> Sure, i know we are talking about hobbyist here, but that's quite a
> step easier I'd think then trying to find an old computer to just use
> it as a diskdrive.

If you have one in a closet, making it a disk drive is handier than
using it for a doorstop.  ;-)

It is interesting, though, considered the great numbers of them made,
that old PCs are now rarer than even older Apple II's.  Clearly the
Apple II users had a more personal relationship with their machines
than PC users did.

> And i'm wondering how you record the timing of the ports?   what tools
> do you use?   I'd love to do some test of some of the older computers
> if I'm able to.

I used an oscilloscope to watch what I could generate.  I was struck by
how amazingly slow it was compared to the (average) processor speed.

> But I do find this project very interesting and the chance to learn
> more about the hardware/insides of an apple, from some of you experts,
> just makes it that much better.

I think you'd wind up learning a lot more about the (very complex)
insides of a modern PC.  ;-)

-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."