Re: CFFA for IIc and IIc+?

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

a2retro wrote:
>  To: Michael J. Mahon
> Michael J. Mahon wrote:
>
> > Actually, I'd abandon the "Slinky" interface entirely and use a RAMWorks
> > interface.  The bank-switched model is more useful, since it can be
> > directly addressed instead of read through a register.  You can run code
> > from an AUX bank, for example.
> >
> > Once you have access to the address bus, you can easily implement the
> > RAMWorks interface, without any impact on slot addresses at all.
>
> Okay I guess thats something to think about.
>
> At this point I am guessing that the earlier memory interfaces for the 
> //c were based on that RAMWorks style interface? I will review some of 
> the docs on the earlier ramworks style memory cards. Any thoughts on why 
> Apple moved away from that type of interface when they designed the 
> memory expandable //c?.

I suspect that they didn't want to license the AE interface, or that
they were thinking about the possibility of plugging multiple "Slinky"
cards into a slotted machine.

Apple never built a RAMWorks-style memory card.

The AE design is, of course, not at all specific to the //c--it was a
widely available expansion AUX memory design for the //e.  The logic
for the RAMWorks design is quite simple, since the only state it has
is the bank register.

The Zip Chip design (licensed for the //c+) is fully compatible with
the RAMWorks design, and can cache its contents for full acceleration.
(The "Slinky" design does not permit caching, since it isn't addressed
directly.)

> This would also mean anyone who had their system setup to expect a //c 
> memory expansion option would have to change everything. Hopefully most 
> software that used extra memory in a //c had drivers to support both 
> memory models.

There was never any software for the Apple II that required a "Slinky"
memory expansion--they all supported RAMWorks, since it existed first
and was widely used.

> > It's hard to imagine my "laundry list" not fitting easily on a board
> > that could hold a megabyte of 256K DRAMs, and that didn't get in the
> > way of the internal drive.  I count an FPGA, a small flash RAM, an SRAM,
> > an SD card socket, a phantom clock "socket", plus a 3.3v regulator and
> > a few level-shifter packages.  ;-)
>
> True but my comment about removing the drive was to give an easily 
> accessible place to insert and remove a cf cards without a case mod, not 
> for use as extra circuit space.

I don't have a IIc out at the moment, but I just checked a IIc+, and the
top is covered with long slots that are just the tiniest bit to narrow
to pass an SD card.  And there is only a thin permeable membrane under
the case slots to prevent things from falling into the case.

It would only take a couple of passes with a file to widen about an
inch of the slot by 0.02" to freely pass an SD card to an internal
socket.  I haven't checked what's under there, but it's a pretty
large area covered with slots, so there are lots of possibilities.

Displacing the internal drive would provide an access hole and internal
volume entirely disproportionate to the size of an SD card and socket,
in my opinion.

-michael

******** Note new website URL ********

NadaNet and AppleCrate II 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."