I have been working on building a compact flash adpater that uses the
smartport interface via the external disk connector on the Apple //c.
I have hand wired a prototype and have this working so that i can boot
prodos from it.
The firmware in the AVR supports 4 partitions on the CF. I have also
used the dos.master games image and that works fine also.
Details are in a quick write up at this link:
http://www.users.on.net/~rjustice/SmartportCFA/SmartportCFA.htm
Hope you guys find it interesting.
regards
Rob
Awesome!
> Details are in a quick write up at this link:http://www.users.on.net/~rjustice/SmartportCFA/SmartportCFA.htm
>
> Hope you guys find it interesting.
That people here will find this interesting is the understatement of
the year so far mate!
I'm surprised the first response was a pre-order request.
--
Wholly
I certainly do!
On your web page, you say:
>Maybe then some way of switching between partitions may be needed, as
>it would be difficult to change the CF once installed. This would be
>fairly easy to implement as the Smartport calls are flexible enough to
>add some extra commands that would enable communication to the AVR from
>an apple based utility.
I would be quite satisfied with a small slot in the //c case for either
a CF card, or, preferably, an SD card.
Being able to deal with several partitions mapped as usual to slots &
drives is all I ever need.
I haven't tried it, but I'll bet that Ciderpress already handles
SD cards using a CFFA (implicit) partitioning scheme.
-michael
NadaNet 3.1 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."
I'll take two, please. Keep it around a hundred bucks (a la CFFA) and
you'll sell quite a few.
>
> I have been working on building a compact flash adpater that uses the
> smartport interface via the external disk connector on the Apple //c.
> I have hand wired a prototype and have this working so that i can boot
> prodos from it.
> The firmware in the AVR supports 4 partitions on the CF. I have also
> used the dos.master games image and that works fine also.
>
> Details are in a quick write up at this link:
> http://www.users.on.net/~rjustice/SmartportCFA/SmartportCFA.htm
>
Can I assume this would work on IIc+ as well? If so, mine may actually
make it out of the dust collection area of my office...
--
James
http://www.e-host-direct.com
Reliable web hosting from $12/year.
Oh, yes. This is a very fine job!
2 card for me, thanks.
Ciao
Giorgio
Apple II and Apple III forever !!!
Don't have time to read up on it at the moment, but count me impressed.
That's a very useful concept.
The SmartPort interface should also allow it to work on a IIgs (using
the built-in disk port), or on a Liron or Superdrive card.
Of course there are existing slot-based CF cards for those models, which
will be much faster due to not having to push data serially through the
SmartPort bus, or do 7-and-1 data encoding/decoding.
--
David Empson
dem...@actrix.gen.nz
Put me down for two, please :-)
Way to go! Glad to see someone doing this for the //c. Add me to list
of people wanting at least one of these.
Dean
> Hope you guys find it interesting.
Rob, if you need a UniDisk 3.5 for testing, I can furnish one... I've
got probably 20 or so in the garage.
It's nice to see someone giving the Apple //c some love. It's probably
the most neglected machine in the Apple II series.
https://ultimateapple2.com/catalogua2/index.php?main_page=product_info&cPath=1_5&products_id=6
For an internal option, this could be a great piggy-back project with
a RAM card (as a separate circuit). I think there are a couple mem
expansion cards that have been cloned already (and chip-reduced). Both
could fit easily onto one board. Wouldn't you just need a strap cable
to the internal drive port? The existing internal drive could then be
plugged in-series to the port.
I was under the impression that the internal port was hard-wired for
slot 6, drive 1, and not for SmartPort at all. So, if you want to go
internal, you have to desolder the disk port itself from the
motherboard, connect your board to the motherboard, and then put a new
one in that connects in line with the internal device. Or, do
something along the lines of piggybacking on the IWM, which requires
desoldering the IWM.
In any case, if you're on the same PCB as a RAM card, you could always
piggyback on the CPU and MMU, and pretend to be a slot card. That
won't work on a Plus, and will require jumpers to set the slot number
for a non-Plus - slot 7 in a ROM 255 or 0, slot 4 in a ROM 3 or 4 -
but it would work, it would even work in a ROM 255, and it could give
aux RAM instead of Slinky RAM.
My opinion, however, is that the best bet would be a small PCB with a
female connector on one side, a male connector on the other, a microSD
slot, and the smallest package of that microcontroller you can get,
stuck in a small plastic case that screws onto the back of the //c.
That way, it stays out of the way, and it works on everything. You'll
need it to support being the first device in the chain, though.
And it would be much more convenient for data interchange and backup
if it were an easily accessible SD card.
Consider this a second request for an external solution. Not all of us want
to rip into the innards - and we might have to move it to another machine
later.
--
Wholly
> I was under the impression that the internal port was hard-wired for
> slot 6, drive 1, and not for SmartPort at all. So, if you want to go
> internal, you have to desolder the disk port itself from the
> motherboard, connect your board to the motherboard, and then put a new
> one in that connects in line with the internal device. Or, do
> something along the lines of piggybacking on the IWM, which requires
> desoldering the IWM.
Yeah, I think we discussed this in IRC. An external solution would be
preferable.
/Rob
What wouldn't work, would be hooking an external smartport drive up.
This is because the smartport init method relies on the each drive in
the chain opening up a latch that stops one of the phase lines being
through connected to the next drive. As each drive in the chain
responds to the init packet, it through connects the phase line to the
next drive.
I could implement this behaviour if it is used as an external drive,
it would just need and extra i/o line.
I had a quick look inside my //c. If you were to use a micro SD card,
i believe it would fit through one of the slots in the back. There may
be enough room in the back to fit the board and run a ribbon cable to
the internal drive connector. Perhaps it could be made to detect if a
card is inserted, and if not, disable itself. That way an external
drive could be used if needed.
Thanks for the link to the connectors Sean, although i would need the
male version. I'll contact them and see if they are also available.
And i'll email you about the possibility of getting a unidisk from you
to test.
Is there a preference for either CF or SD card?
And thanks for all of your positive comments.
/Rob
A) why CF? its outdated and overly complex for an apple, SD in SPI
mode would overrun it no issue
B) why on a part that is not constantly available? and when is is,
cost more than a non ebay //c
C) internal = no go
D) awesome build
I bought some DB-19 connectors a few months ago from:
http://www.connectworld.net/cgi-bin/ccc/05MPartDB19.html
Decent pricing; I'm a satisfied customer.
--
Jerry awanderin at yahoo dot ca
SD cards are getting much more available than CF cards, and at
more competitive prices.
Micro SD cards are not very convenient for frequent insertion and
removal, and can get lost in a shag rug very easily. ;-)
> And thanks for all of your positive comments.
You're welcome! This is a great advance for these "portable" machines.
A IIgs user,
Antoine
> Is there a preference for either CF or SD card?
An external SD solution would probably be the most logical. I'd hate
to lose my external drives though -- I hate making copies of disks
with only one drive. :)
It depends on how the slot is implemented, although yes, they can get
lost easily.
(Some slots, you can easily grab the card with a fingernail and pull
it out.)
Even full SD would be better than CF, though.
I would seriously consider getting a //c because of this development,
but not if I had to use SD cards instead of CF.
-Warr
You can always get an SD to CF adapter...
But it is trivial to use CiderPress to make a volume copy
from CF <--> SD.
I'm actually hoping for an SD version of CFFA--an "SDFA" card. ;-)
CF is clearly on its way out, as prices and availability show.
And the connector itself is a nightmare of tiny pins...
> But it is trivial to use CiderPress to make a volume copy
> from CF <--> SD.
>
> I'm actually hoping for an SD version of CFFA--an "SDFA" card. ;-)
>
> CF is clearly on its way out, as prices and availability show.
>
> And the connector itself is a nightmare of tiny pins...
I myself would have more use for an "SDFA". I got plenty of Micro SD
cards and adaptors, and *one* CF.
-uso.
I have to admit that I would feel pretty strange with only 128m of my 4G SD
card used...
--
Wholly
Think of it as a $4 128MB card and it feels much better. ;-)
> Think of it as a $4 128MB card and it feels much better. ;-)
And this is the year when such things follow the price of hard drives to
the basement.
Current predictions call for both a DRAM and a flash glut toward
the middle to end of 2011, followed by a slow price recovery,
followed by higher prices a couple of years later.
> I'm confident it would work ok on the IIc+. From a timing point of
> view with the smartport, it should not have changed.
>
Cool - count me in as interested in one then. :)
--
James
http://www.e-host-direct.com
Reliable web hosting from $12/year.
A Smartport CF/SD adapter will certainly make a //c more useful by
giving it access to greater storage space (without having to resort to
rare SmartPort/SCSI adapters), but it won't be a speed demon.
I'd expect this adapter to be somewhat faster than a 5.25" drive or
UniDisk 3.5, due to elimination of rotational and seek latency,
buffering and IWM switching delays in the UniDisk 3.5, and 7-and-1
instead of 6-and-2 encoding in comparison to a 5.25" drive.
The raw data transfer rate of SmartPort is the same as the UniDisk 3.5:
theoretical limit is 7 bits every 32 microseconds, thus 27 kilobytes per
second, but there will be delays due to SmartPort protocol overhead,
which reduces the limit further (perhaps 25 KB/s is achievable).
A card in a slotted 1 MHz Apple II using a software loop can go somewhat
faster than that, an accelerated 8-bit Apple II (or any IIgs) could be
somewhat faster again (with the right drivers), and DMA-based cards can
go a lot faster.
The 3.5" drive in an Apple //c+, or an Apple 3.5 Drive on a //c+, IIgs,
or IIe with a SuperDrive card is about twice as fast as SmartPort (but
with seek and rotational latency), and a SuperDrive on a SuperDrive card
can be up to four times faster than SmartPort for reading.
Still, higher capacity than a floppy is a big plus.
--
David Empson
dem...@actrix.gen.nz
Has anyone attempted using a SD->CF converter module yet ? Price wise
they're getting to be cheaper than the larger SD cards.
I agree, something would have to be very marginal in your timing to
have problems with any SmartPort implementation, of which there are
many.
The IIc+ is probably largest portion of this devices "target market".
The only issue I see is that the IIc+ is rather dependent on having an
external 5.25" disk drive to run a lot of 8-bit software.
Are you considering implementing the hardware side of the SmartPort
bus arbitration protocol ? Gating the select lines (perhaps with a tri-
statable buffer) on PH0+PH2, or PH1+PH3 seems all that's required to
support 'dumb' devices being daisy chained off the end.
Allowing daisy chained SmartPort devices (less necessary IMO other
than for completeness) seems only to require gating the two phase
lines (I forget which) that signal a bus INIT, since IIRC smartport
devices respond to device INIT requests until they run out of devices/
partitions, then stop gating the phase lines so that the next
smartport device may see INIT.
Matt
I've thought about this a bit and I think the CF solution is best for
the Apple II as it is already widely accepted for CFFA and other IDE-
based solutions. I think keeping the medium consistent will allow
users to get more value. I could take my CF card that I use for my
normal A2 activities on my //e and IIgs and use that same card on
the //c without a problem that way.
The only reason CF is preferred is a combination of:
1. CF was cheaper than SD when the CFFA was designed
2. The Focus and MicroDrive were already existing products meant for
IDE hard drives
That's it. Quite a few other retrocomputing communities have gone SD
lately, because it's cheaper and simpler for them to implement. (Less
pins needed on the microcontroller means a cheaper microcontroller can
be used, and IIRC, the protocol is simpler, too.)
Not only that, but as I said before, there are SD to CF adapters. So,
you can take an SD card, stick it in a CF adapter, and then stick that
in your CFFA. (The Focus and MicroDrive are irrelevant to this
discussion, unless Rob decides to use one of those partition schemes,
instead of the CFFA partitioning that he's using now.)
But, the biggest dealbreaker with CF is that it's HUGE. On a slotted
II, that's no big deal, there's plenty of room. On a //c, it's far
easier to fit an SD card in there than a CF card. And, if this is
external, an SD card would allow it to be a box smaller than even
the //c RF Modulator, that could safely be attached to the //c
permanently without getting in the way, whereas a CF wouldn't.
That holds just fine until you realize that a CF full of GS/OS and //gs
development tools isn't a whole lot of fun on a //c.
(I feel sorry for Robert. Everyone is designing his product and he's
disappeared thinking that maybe it's time for the TI 99/4a project he was
thinking about)
--
Wholly
What project for the TI-99/4A? We have a CF adapter, and aren't arguing
about the media. Our issues in the past has been whether it should have
memory on-board (then 32k was added), then whether it should come with the
parallel port it had been designed with or a serial port (then a new model
with a serial port replacing the parallel port was released).
We even have some brave souls who've hooked it up using a SCSI to IDE
converter to a SCSI card so it can be used with the old expansion box. And a
couple who have IDE cards who have used it that way.
Impressive project.. Any plans on ethernet tcp/ip via smartport?
Kool i would definitely be interested in a couple. Nice Work!
Drew
I was kidding about the TI project, but not so much about the probably
enthusiastic dreams about a cool hack by almost everyone out here. Robert's
never said he will or will not do something "product-ish" with it but we've
all helped him design the non-existent product.
Personally, I'd like to hear more from him and less from us. Maybe Henry @
Reactive could talk him out of the design and code and turn it into a
product.
Sorry for pouring a little water on the fire, but let's let Prometheus enjoy
his smores.
--
Wholly
Is there a preference for either CF or SD card?
External with SD card. While I was able to get some CF cards fairly
cheaply, SD are much easier to find in smaller sized formats. They
have micro sd to SD converters if someone is keen on using those.
yanking apart the iic is not desirable but also, should it work on a
IIGS then being able to quickly move it from machine to machine is
highly desirable.
I vote for SD too.
It might increase your market if existing MicroDrive/CFFA owners (like
me) have to buy the SD adapter for both their //c _and_ IIgs. ;-)
Also, external first; an internal option later would be great.
Cheers,
Nick.
I've been looking at SD-->CF converters. The compact ones (that would
fit in a CFFA with the lid closed) are all CF Type II (thicker). Will
those work in the CFFA?
> Also, external first; an internal option later would be great.
Agree.
Ah, I see. Making a little joke at the expense of us TIers...
You just don't realize that we are gathering steam...
One day, maybe not in the too distant future - one day...
ALL YOUR BASE ARE BELONG TO US!
muahaha muahaha mua (*cough* *wheeze*)
;)
The CFFA manual says the socket is Type II.
Wikipedia says I & II are the same except for size & current.
So my infallible sources suggest "yes". ;-)
But I actually have Microdrives.
Cheers,
Nick.
I'm enjoying reading all of the comments. I'd like to see a proper
board made down the track, not sure if i'm going to do that or not.
There's a few things that need to be sorted out to finalize the design
first before the next step.
Matt, i agree with you comments about the second connector to allow
the pass through on the iic+. I hadn't really thought about that. I
believe that there is two lines that need to be controlled to the pass
through connector. I'll have to get another drive and do some testing
to verify my thoughts on this.
Not sure about the CF or SD, gee it has sparked some discussion. My
main thought was if you had a cffa, then you can just plug the CF from
it into your smartport adapter. But i do agree that they are getting
harder to find. Maybe we need to build something that has both on it,
maybe that would keep every one happy. :-) The SD to CF adapters are
around the 14-15 dollars on ebay, so maybe thats an easier option.
(assuming they work ok)
The only SD-CF adapter I know of which is Type I and fully encloses the SD card is the one from Minolta (an accessory for their old digital camera). It was expensive and hard-to-find, but I needed one back then for the same purpose as using SD cards in my Canon SLR which only accepts CF Type I:
https://picasaweb.google.com/pitz.wong/Posts#5569076576114692866
But nowadays, there are plenty of microSD -> CF Type I adapters that can be bought cheaply around the net.
> Matt, i agree with you comments about the second connector to allow
> the pass through on the iic+. I hadn't really thought about that. I
> believe that there is two lines that need to be controlled to the pass
> through connector. I'll have to get another drive and do some testing
> to verify my thoughts on this.
>
> Not sure about the CF or SD, gee it has sparked some discussion. My
> main thought was if you had a cffa, then you can just plug the CF from
> it into your smartport adapter. But i do agree that they are getting
> harder to find. Maybe we need to build something that has both on it,
> maybe that would keep every one happy. :-) The SD to CF adapters are
> around the 14-15 dollars on ebay, so maybe thats an easier option.
> (assuming they work ok)
The thing is, my main reason for wanting SD is actually related to
form factor, and both would be worse than CF. ;)
That said, while you could plug a CFFA's card into a CF-equipped card,
you could also plug this entire adapter into a Liron or a IIGS.
Futurama proves you fail. Bender has a 6502.
--
Wholly
I'm with Eric on this - both SD and CF is technically feasible, but it would
be nice to not make the device 2x larger just to have a cf connector.
Question - Does everyone have a CFFA with their CF on a leash outside of
their machine? Mine is inside, safe and sound with short wires to keep the
signals fast, with my monitor on top AND I'm terrified of bending pins.
--
Wholly
Ah, but remember... one of Bender's "ancestors" is revealed to be
"Commodore LXIV" in The Honking.
I don't have a CFFA, but my Focus's card is inside my GS, and even
though I could use CiderPress, I prefer to transfer files over the
network to my IIGS, to avoid the hassle of opening it up. (Although,
I'll probably stick it in a PC to fix the damaged System folder.)
> But nowadays, there are plenty of microSD -> CF Type I adapters
> that can be bought cheaply around the net.
Do these adapters fully implement a CF card, i.e. both memory and true
IDE mode? This would require a microcontroller inside that converts the
16 bit parallel bus into SPI and does the protocol conversion.
Today, CF is only used for professional systems. High-end cameras,
industrial data logging, high-speed applications. The advantages are
higher capacity (up to 128GB), higher reliability, higher transfer
rates, and compatibility to the IDE/ATA bus.
All this is not required for the Apple //c, so the consumer grade SD
card would be more suitable here.
But remember: the SD specification with its easy-to-use SPI mode goes up
to 2GB only. SD cards with 4, 8, 16GB are SDHC, not SD!
Patrick
That's generally how I use mine. But I don't think I have a machine with a
CF on it anymore. Although my netbook has two SD slots.
--
Wholly
I'm not finding anything that says that SDHC doesn't support SPI. I
believe there are protocol changes, but it's still SPI.
In any case, while SDHC support wouldn't be a bad idea, simply because
of how common SDHC cards are, it's not that relevant. Assuming that no
other drives are present (not even the internal 5.25,) you can only
have a maximum of 14 partitions on an 8-bit machine, and they'll all
either be ProDOS, Pascal, or CP/M partitions, which are limited to 32
MiB.
So, 448 MiB is the most space that a //c could theoretically even use,
and that's with unplugging the internal drive. 13 partitions, or 416
MiB, if you leave that plugged in. And, to be very safe, you also have
to assume that a second 5.25" drive is present, as well as two 3.5"
drives and a RAMdisk of some sort, so you've got 9 partitions, or 288
MiB as the safe maximum.
And, as Rob was using the CFFA partition standard, that puts an
additional constraint. The CFFA has two possible partition maps:
4 32 MiB partitions, 2 1 GiB partitions (it uses them in this order,
but if it reaches the end of the device before reaching the end of the
partitions, it will stop, and if necessary make the last partition it
was able to use smaller. Also, the 1 GiB partitions are only available
using the GS/OS driver)
8 32 MiB partitions (same rules as the 4+2)
While the CFFA partition standard is extremely simple, software is
written expecting either 4, 4+2, or 8 partitions on a CFFA-partitioned
device. Therefore, obeying that standard would be best, so now we're
at 256 MiB.
(By the way, if the 8 partition standard is used, support for both
partition maps is likely best, in case someone is sharing a SD card
between the //c and a CFFA-equipped IIGS with a SD to CF adapter. One
jumper or DIP switch, and then you prevent someone from stomping over
the first 128 MiB of their first HFS partition.)
Right--the prevalence of SD slots is a huge win for CiderPress
users. And CiderPress makes it a trivial operation to copy
the entire volume between SD and CF, making one a backup for
the other.
Frankly, CiderPress is so good that it makes getting a Windows
machine just as an Apple II peripheral a good idea. ;-)
Currently the only thing I see a problem with is that it will boot
from the internal 3.5 drive but doesn't recognize it after that.
Booting from the MicroSD works fine.
Glenn
Wow, this is fantastic work. We no longer have to consider opening
and hacking circuits inside the IIc to get mass storage. (Of course we
can, but it is more work.) As someone pointed out, the smartport
exists in other Apple IIs as well, so this could be used with a IIc+,
IIgs or possibly other slotted Apple IIs. I do not know if there is a
smartport adapter card, the liron card maybe? I think about any mass
storage available would be mappable to the smartport with the ground
breaking work done thus far. Very Kewl as some might say.
Thankx,
Ed