Re: Apple //c smartport compact flash adapter

[Eric Rucker <bhtooefr@gmail.com>]

On Jan 30, 11:20 pm, Payton Byrd <plb...@gmail.com> wrote:
> On Jan 29, 7:06 pm, Eric Rucker <bhtoo...@gmail.com> wrote:
>
>
>
>
>
> > On Jan 29, 3:26 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> > > Robert Justice wrote:
> > > > It could be used internally by piggy backing on the existing internal
> > > > drive connector. The Smartport interface does not care about the drive
> > > > select that would be different on the internal connector.
>
> > > > What wouldn't work, would be hooking an external smartport drive up.
> > > > This is because the smartport init method relies on the each drive in
> > > > the chain opening up a latch that stops one of the phase lines being
> > > > through connected to the next drive. As each drive in the chain
> > > > responds to the init packet, it through connects the phase line to the
> > > > next drive.
>
> > > > I could implement this behaviour if it is used as an external drive,
> > > > it would just need and extra i/o line.
>
> > > > I had a quick look inside my //c. If you were to use a micro SD card,
> > > > i believe it would fit through one of the slots in the back. There may
> > > > be enough room in the back to fit the board and run a ribbon cable to
> > > > the internal drive connector. Perhaps it could be made to detect if a
> > > > card is inserted, and if not, disable itself. That way an external
> > > > drive could be used if needed.
>
> > > > Thanks for the link to the connectors Sean, although i would need the
> > > > male version. I'll contact them and see if they are also available.
> > > > And i'll email you about the possibility of getting a unidisk from you
> > > > to test.
>
> > > > Is there a preference for either CF or SD card?
>
> > > SD cards are getting much more available than CF cards, and at
> > > more competitive prices.
>
> > > Micro SD cards are not very convenient for frequent insertion and
> > > removal, and can get lost in a shag rug very easily.  ;-)
>
> > > > And thanks for all of your positive comments.
>
> > > You're welcome!  This is a great advance for these "portable" machines.
>
> > > -michael
>
> > > NadaNet 3.1 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."
>
> > It depends on how the slot is implemented, although yes, they can get
> > lost easily.
>
> > (Some slots, you can easily grab the card with a fingernail and pull
> > it out.)
>
> > Even full SD would be better than CF, though.
>
> I've thought about this a bit and I think the CF solution is best for
> the Apple II as it is already widely accepted for CFFA and other IDE-
> based solutions.  I think keeping the medium consistent will allow
> users to get more value.  I could take my CF card that I use for my
> normal A2 activities on my //e and IIgs and use that same card on
> the //c without a problem that way.

The only reason CF is preferred is a combination of:

1. CF was cheaper than SD when the CFFA was designed
2. The Focus and MicroDrive were already existing products meant for
IDE hard drives

That's it. Quite a few other retrocomputing communities have gone SD
lately, because it's cheaper and simpler for them to implement. (Less
pins needed on the microcontroller means a cheaper microcontroller can
be used, and IIRC, the protocol is simpler, too.)

Not only that, but as I said before, there are SD to CF adapters. So,
you can take an SD card, stick it in a CF adapter, and then stick that
in your CFFA. (The Focus and MicroDrive are irrelevant to this
discussion, unless Rob decides to use one of those partition schemes,
instead of the CFFA partitioning that he's using now.)

But, the biggest dealbreaker with CF is that it's HUGE. On a slotted
II, that's no big deal, there's plenty of room. On a //c, it's far
easier to fit an SD card in there than a CF card. And, if this is
external, an SD card would allow it to be a box smaller than even
the //c RF Modulator, that could safely be attached to the //c
permanently without getting in the way, whereas a CF wouldn't.