Re: CFFA for IIc and IIc+?
- From: "Michael J. Mahon" <mjmahon@xxxxxxx>
- Date: Wed, 08 Apr 2009 12:49:25 -0700
a2retro wrote:
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.
I was hoping for a bank-switched ROM model that would open up space
for just about anything (as long as interrupts are disabled).
I like the idea of flash ROM that would permit easy updates by
running a program on the //c*.
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.
I obviously have a warm spot in my heart for the //c+(+), which pretty
much rules out tapping into the CPU pins (location, speed).
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 :)
The RAM expansion is quite useful--I'd hate to sacrifice it.
But then I also want a clock/calendar--almost required for a machine
with a large disk, just to keep versions straight.
With modern parts, space shouldn't be an issue.
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.
I don't know how much of the "slot" map is actually occupied in the
//c*, but RAM could be implemented like AUX RAM, which does not use
"slot" space, and a clock/calendar can be done using a "no-slot clock"
(phantom clock) protocol, so that won't use slot space either. The
actual pseudo-hard-disk will need slot space, but not much, since most
communication with it can be done with a protocol through a single byte
interface (kind of like the "Slinky" ;-).
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.
I agree that a ROM socket would be a good place to get the address
bus (at 1MHz).
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).
If you do your own I/O decoding, then the only requirement is that
nothing else in the machine is using the addresses you are using.
That should open up a lot of unused "slot" space.
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.
Since a 1MB card populated with 1980s-vintage 256K DRAMs was OK, I can't
imagine any power problems with modern components.
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?
No. I depend on swapping the card into a PC and using CiderPress to
move data back and forth, and to perform backups/restores in seconds.
CF cards are actually getting inconvenient, since so few machines have
built-in readers anymore. SD cards are the "sweet spot" for both price
and convenience.
Would you entertain case mods to enable outside access to the media?
A case mod like cutting a small slot seems just fine. It would be even
better to be able to slip an SD card in through one of the many case
slots on the top of the machine (though I realize that "clearing" a
part of a slot for this purpose is also a small "mod").
BTW, a micro-SD card is really too small to "swap"--and they can
get lost much too easily. I think of the micro-SD format more as
a semi-permanent installed device.
Forgo the internal drive?
That would be a problem, since that's the primary means of getting
"Apple II" data into and out of the machine. (I do occasionally
wish that my IIc++ 3/5" drive was MFM-capable, however. ;-)
Run external cables?
Only as a *last resort*.
7) Am I missing any important considerations?
I think you've touched all the bases!
---------------------
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+ :)
I'm not surprised! ;-)
-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."
.
- Follow-Ups:
- Re: CFFA for IIc and IIc+?
- From: a2retro
- Re: CFFA for IIc and IIc+?
- References:
- CFFA for IIc and IIc+?
- From: Michael J. Mahon
- Re: CFFA for IIc and IIc+?
- From: a2retro
- CFFA for IIc and IIc+?
- Prev by Date: Re: CFFA for IIc and IIc+?
- Next by Date: Re: CFFA for IIc and IIc+?
- Previous by thread: Re: CFFA for IIc and IIc+?
- Next by thread: Re: CFFA for IIc and IIc+?
- Index(es):
Relevant Pages
|
