[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CFFA for IIc and IIc+?
a2retro wrote:
To: Michael J. Mahon
Michael J. Mahon wrote:
Will have to consult the tech ref again. This also goes back to my
comment about giving something up (maybe ;-) ..
In a //c+ for example you have
slot 1 - serial 1
slot 2 - serial 2
slot 3 - 80 cols
slot 4 - mem expansion
slot 5 - 3.5 disk
slot 6 - 5.25 disk
slot 7 - mouse
the easiest place to get unused devsel like addresses is slot 4 upper 12
bytes as the 1st four are used for mem expansion. I would expect the
devsel i/o addresses at slot 3 to be unused but not the ROM space. I
doubt anyone uses both serial ports still but from my examination of the
serial code, the code is not duplicated per slot but intermixed across
both ROM locations for those slots.
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.
That frees up slot 4 for a flash disk. The ROM code could be modified
to boot from slot 4 either by default or if the built-in disk is not
ready. Perhaps the firmware could check an Apple key to boot from
the floppy, normally defaulting to the flash drive.
Since a 1MB card populated with 1980s-vintage 256K DRAMs was OK, I can't
imagine any power problems with modern components.
For the most past I agree with your assessment but it doesn't hurt to
conserve where possible. My main concern in this area was the possible
comms option - wireless is very power hungry. ;-)
I'm not too sanguine about an 802.11 Apple II...so that doesn't bother
me at all. Still, a few watts go a long way.
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. ;-)
The system still works with the internal drive taken out as it supports
external disks - you just can't boot from the external disk directly,
although there a few potential mods to fix that as well.
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. ;-)
While i think a case mod could provide a slicker external access to a SD
or CF card I don't think the implementation should depend in it. I will
try to make it an easily implementable option if possible (at least have
the connections available at the board level and leave the cutting to
someone else)
If done properly, the only cutting would be to about an inch of the
"L" bead under one of the case cooling slots, to allow an SD card to
penetrate the slot into a "push-release" socket mounted at a right
angle to the logic board. Similarly, an "activity" or rectangular
two-color read/write LED could be mounted in the same slot adjacent
to the SD card.
Of course, a mounting option for those who plan to leave the SD card
in the machine might also be popular.
Thanks for the feedback.
You're very welcome--it is a project that I'd love to see come
to fruition!
-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."