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

Re: CFFA for IIc and IIc+?

 To: Michael J. Mahon
Michael J. Mahon wrote:

Subject says it all...

I'd be delighted to have a CFFA for my IIc++.  It would make it a very
compact and attractive solution for desktop Apple II computing in a
confined space.

In fact, the talk about the Carte Blanche opens the possibility of
providing the IIc machines with an internal "slot" for what-have-you.

Of course, if the card were installed *inside* a machine, it would be
even more useful for it to be programmable by a program running
on the host Apple II itself (that is, without any "development
environment" for the card running on another machine).

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


Hi Michael,

you probably already know, I have been actively working (at my own
snails pace :) on something like this for some time now. Please
allow me to share some of my observations and perhaps now is as good a
time as any to get some community feedback? Here are a few items to
start the discussion.

1) One of the challenges that percolates to the surface pretty
quickly is that all peripheral i/o code is in a single ROM (16 or 32K). There is not too much free space to be had in these ROMS from what I understand. This in turn causes one to consider what might you have to give up in favor of this new found capability? Both in ROM space, loss of built in hardware and software compatibility issues if that ROM space is re-purposed for new hardware? 

Most the 3rd party internal //c add-ons were memory or co-processor
related afaik, not requiring any ROM mods.  I am pretty sure adding
support for mass storage will require some ROM mods. Not insurmountable
but not easily discounted either.

I have also thought it would be nice to be able to default to the
original ROM image in a worst case scenario if the technology used to
emulate the ROM got botched during programming for example. Being able
to update that ROM replacement from the //c would also be desirable.

2) Support for various //c models... where do you start? � my own
initial inclination was to only support the //c models that have a
memory expansion bus. Of course it's not too hard to stretch the design
to support the older models .. Just more flavors with additional board
space and hardware.

3) While I am on the subject of the memory expansion bus, lets not throw
the baby out with the bath water. I felt early on, I wanted to include what I was possibly replacing since there is only room for one card at a time. Would someone want to leave out the 1MB Memory card they have grown used to in favor of a CF/SDCard? This is why I started with emulating the 1MB memory card when I started my project. (I know CB has 512KB of SRAM which is a good thing :) 

4) Register map: The memory expandable //c only supports 4 hardware i/o
addresses which were mapped to the slinky card interface. The additional
address lines (a2 and a3) are available elsewhere depending on which
sub model you look at.

The //c+ does have the missing address lines available on a sub
connector located near the memory expansion connector although I would
favor tapping a ROM socket as this would work for both ME //c's. The
original //c's taps the addresses from the cpu socket.  My intention
was to bring the ROM onboard to gain the required address lines as well
as provide the update mechanism to refresh the ROM image.

It has been my desire from almost the beginning to hopefully support
multiple peripherals simultaneously on one card. While I believe it is doable, I haven't gotten far enough down that road to know how many things can live in one slot (given the 16 i/o address constraint). 

5) Available Power compared to other Apple II models: I could not find a
reference to what the available power is at the memory connector. Finding low power devices has been something I have activly kept in mind. I have also made an assumption that a SDcard would be preferable to a CF card for disk storage from both a power consumption and a physical board space aspect. Still considering whether to use a regular SDCard vs MicroSD card socket. 

6) Accessibility to the card and peripherals:  When looking at the
physical aspects of an implementation the following questions also come
to mind.
   Are you willing to crack the case open every time you want to swap
out a CF or SDCard?
   Would you entertain case mods to enable outside access to the media?
   Forgo the internal drive?
   Run external cables?

7) Am I missing any important considerations?

---------------------
All feedback on my comments/assumptions is welcome. I too am
very excited about the possibilities a Carte Blanche brings to the
table. While I still plan to persue a dedicated ram/disk/comm card for the //c family, you can bet I have already started thinking about how to stuff a CB in my //c+ :) 

Glenn