[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:


I was hoping for a bank-switched ROM model that would open up space
for just about anything (as long as interrupts are disabled).
Will have to investigate the current bank switch model to see if it is extensible. 



But then I also want a clock/calendar--almost required for a machine
with a large disk, just to keep versions straight.
Relocating the original ROM to the card would allow existing NSC sockets to be utilized. Then a short cable from the original ROM socket to the card would be in order. 



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 Apple //c memory expansion (which is slinky compatible) uses 4 i/o addresses. I already have my 1MB memory card design working for the //c (Still have a glitch when installed in the //c+ but I think i found a tech note that might help). Up to 16MB could potentially be supported with some changes to the ROM. My plan is to initially go with 1MB of fast low power SRAM. (I do plan to experiment with NVSRAM and PSRAM) 


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.
With the //c you have to do your own i/o decoding anyway - there is no devsel like signal for the memory expansion interface. 

> That should open up a lot of unused "slot" space.
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. 



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. ;-) 



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


7) Am I missing any important considerations?

I think you've touched all the bases!


Thanks for the feedback.




Glenn