Apple //c smartport compact flash adapter
Robert Justice
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
mdj
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!
Wholly Mindless
> 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
Michael J. Mahon
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."
schmidtd
I'll take two, please. Keep it around a hundred bucks (a la CFFA) and
you'll sell quite a few.
Slor
wrote in news:h5t3k655td0s03h1o...@4ax.com:
>
> 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.
giorgio....@alice.it
<rjus...@internode.on.net> ha scritto:
Oh, yes. This is a very fine job!
2 card for me, thanks.
Ciao
Giorgio
Apple II and Apple III forever !!!
David Empson
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
Steven Hirsch
Put me down for two, please :-)
magnusfalkirk
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
Sean Fahey
> 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.
Sean Fahey
somewhere. He sells them, and/or he might point you to where he got
them.
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.
Eric Rucker
> I forgot to mention... Anthony Martino sourced DB19 connectors from
> somewhere. He sells them, and/or he might point you to where he got
> them.
>
>
> 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.
Michael J. Mahon
And it would be much more convenient for data interchange and backup
if it were an easily accessible SD card.
Wholly Mindless
> 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.
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
Sean Fahey
> 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.
Robert Justice
ciderpress would write the data to an SD card the same as a CF card. I
haven't tried, I think i will have a go soon to build a version with
an SD Card instead of a CF. I'll find out then for sure :-)
/Rob
Robert Justice
view with the smartport, it should not have changed.
Robert Justice
drive connector. The Smartport interface does not care about the drive
select that would be different on the internal connector.
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
Osgeld
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
Jerry
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
Michael J. Mahon
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.
Toinet
I own a IIc that I was about to sell and I have to admit that your
message makes me wonder whether it would be the good thing to do.
Nevertheless, thank you for that and keep up the good work.
A IIgs user,
Antoine
Sean Fahey
> 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. :)
Eric Rucker
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.
Warren Ernst
based storage cards in use in IIGS's and //e's, so it allows a user to
swap storage cards between all their machines easily.
I would seriously consider getting a //c because of this development,
but not if I had to use SD cards instead of CF.
-Warr
Eric Rucker
You can always get an SD to CF adapter...
Michael J. Mahon
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...
Steve Nickolas
> 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.
Eric Rucker
> 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...
than the actual flash chips inside of them, due to economies of scale.
Wholly Mindless
I have to admit that I would feel pretty strange with only 128m of my 4G SD
card used...
--
Wholly
Michael J. Mahon
Think of it as a $4 128MB card and it feels much better. ;-)
Mike Spurgeon
> Wholly Mindless wrote:
> 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.
Michael J. Mahon
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.
Slor
> 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.
David Empson
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
mdj
> Warren Ernst wrote:
> > The reason you go with CF is because there are already a lot of CF-
> > based storage cards in use in IIGS's and //e's, so it allows a user to
> > swap storage cards between all their machines easily.
>
> > I would seriously consider getting a //c because of this development,
> > but not if I had to use SD cards instead of CF.
>
> > -Warr
>
> > On Jan 28, 10:08 pm, Osgeld <osg...@cheesefactory.us> wrote:
>
> >>A) why CF? its outdated and overly complex for an apple, SD in SPI
> >>mode would overrun it no issue
>
> 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...
Has anyone attempted using a SD->CF converter module yet ? Price wise
they're getting to be cheaper than the larger SD cards.
mdj
> I'm confident it would work ok on the IIc+. From a timing point of
> view with the smartport, it should not have changed.
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
Payton Byrd
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.
Eric Rucker
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.
Wholly Mindless
> 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.
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
winston19842005
Mindless" <who...@whollymindless.com> wrote:
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.
apple
> Hi All,
>
> I have been working on building a compact flash adpater that uses the
> smartport interface via the external disk connector on the Apple //c.
Impressive project.. Any plans on ethernet tcp/ip via smartport?
Drew
> Hi All,
>
> I have been working on building a compact flash adpater that uses the
> smartport interface via the external disk connector on the Apple //c.
> 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
Kool i would definitely be interested in a couple. Nice Work!
Drew
Wholly Mindless
>
> 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.
>
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
joltenjoe
> It could be used internally by piggy backing on the existing internal
> drive connector. The Smartport interface does not care about the drive
> select that would be different on the internal connector.
>
> 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?
>
>
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.
sicklittlemonkey
> Is there a preference for either CF or SD card?
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.
Michael J. Mahon
> On Jan 29, 6:34 pm, Robert Justice <rjust...@internode.on.net> wrote:
>
>>Is there a preference for either CF or SD card?
>
>
> 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. ;-)
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.
winston...@yahoo.com
> winston19842005 wrote:
>
> > 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.
>
> 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.
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*)
;)
sicklittlemonkey
> 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?
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.
Robert Justice
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)
pitz
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.
Eric Rucker
> You've given me a good laugh reading your posts Wholly, thanks :-)
>
> 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 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.
Wholly Mindless
> 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*)
Futurama proves you fail. Bender has a 6502.
--
Wholly
Wholly Mindless
> 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.
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
schmidtd
Ah, but remember... one of Bender's "ancestors" is revealed to be
"Commodore LXIV" in The Honking.
Eric Rucker
> 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.
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.)
Patrick Schaefer
> 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
Wholly Mindless
> 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.)
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
Eric Rucker
> 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!
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.)
Michael J. Mahon
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. ;-)
a2retro
onboard MicroSD slot as a single external device. The processor on
this board is the ATMega644P and has a clock of 28.63636, so it was
easy just to divide that in half to match Rob's current
implementation.
Test machine used was a IIc+ and i persuaded a laser 800k drive to
loan me it's cable. :)
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
Delfs
> Hi All,
>
> 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
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
Delfs
> It could be used internally by piggy backing on the existing internal
> drive connector. The Smartport interface does not care about the drive
> select that would be different on the internal connector.
>
> 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.
>
>
>
> /Rob
Well I'm still not sure how you would hook one up on the inside, but I
think a standard 'dongle' package could hold the necessary circuit and
card, regardless fo type used. Personally I think that if the IDE
implementaiton is already covered then the rest are as well...
I have used 3 different SD to CF adapters on my CFFA card, all work
flawlessly. For that matter when I figured out that they make an CF
to IDE adapter, I have tried those as well, same results, excellent.
And when I got my first micro SD card, I slipped that into the SD
adapter and put that into the SD>CF adapter and it worked too. Ive
even used the adapter off of USB card readers, cause I like to torture
1s and 0s and just wanted to see how many conversions it can go
through. I think the answer was, a block device is a block device and
it was readily transparent to the host hardware, be it IDE, CFFA, or
what have you.
So my slotted Apple IIs have had a CFFA, a Focus and a TurboIDE with
CF, SD, MicroSD, 3.5" IDE, and 2.5" IDE using the file and partition
formats available to the originating hardware and have worked without
incident.
Long and short, I suspect this work will go far towards making a
CFFA2C adapter to allow the sealed II market (chuckles) to get mass
storage, regardless of the media.
Thankx,
Ed
Eric Rucker
Yes, the Liron card should work with this - the Liron card is an
implementation of the //c SmartPort on a card.
There are still advantages to putting devices inside the //c - the
biggest one being that the SmartPort is slow - but such approaches are
a pain to deal with - the best ones involve removing the CPU and MMU
from the motherboard, the card sitting in those sockets, and the CPU
and MMU being relocated to the card. If you do that, it won't work on
the IIc Plus (where you have to piggyback under the accelerator ASIC
rather than the CPU), and if you want users to be able to expand RAM
with that card, you either have to provide piggyback RAM, or provide
MemExp RAM if you're restricting yourself to MemExp //cs. (Myself, I
own a ROM 0 //c, so a MemExp card would be useless to me - I'd lose my
Z-RAM II, so I'd have no expansion RAM, and no Z80 - not that I use CP/
M much, but still, it's nice to have. That also means that piggyback
cards are in danger of feature creep, to prevent those problems.)
mdj
> Well I'm still not sure how you would hook one up on the inside, but I
> think a standard 'dongle' package could hold the necessary circuit and
> card, regardless fo type used. Personally I think that if the IDE
> implementaiton is already covered then the rest are as well...
There's a lot of ways to do it, but I don't personally see the
benefit. Speed is the obvious one, but anyone concerned about speed
can use Glen Bredon's ProCache to cancel out most of the performance
problems.
20kb/s is actually not too bad on an Apple II, and without the 'seek'
delays that go with rotational media a good solid 20kb/s ought to be
achievable.
Matt
Michael J. Mahon
FWIW, the CFFA, running on my 8MHz Zipped //e, delivers 44.4KB/sec
data bandwidth for BLOADs through BASIC.SYSTEM, so there's something
to be said for a bus connection. (BTW, transfer rate did not seem
to be strongly affected by acceleration, even with slot speed set to
"fast".)
mdj
> FWIW, the CFFA, running on my 8MHz Zipped //e, delivers 44.4KB/sec
> data bandwidth for BLOADs through BASIC.SYSTEM, so there's something
> to be said for a bus connection. (BTW, transfer rate did not seem
> to be strongly affected by acceleration, even with slot speed set to
> "fast".)
Interesting - sounds like there's a handshake between bytes that
limits its throughput.
The Rev C. SCSI (from memory, I think we did this once before) is
around 35kb/s on my accelerated IIe. I'd say they're both slow
compared to other options, and certainly slow compared to what's
achievable in a bus connected card.
My marketing skills aren't the best, but I'd guess the majority of
people wanting such a thing on a IIc would be more than satisfied with
SmartPort speeds. The 'power users' are already using IIe's or IIgs's
anyway.
Matt
Eric Rucker
> Interesting - sounds like there's a handshake between bytes that
> limits its throughput.
>
> The Rev C. SCSI (from memory, I think we did this once before) is
> around 35kb/s on my accelerated IIe. I'd say they're both slow
> compared to other options, and certainly slow compared to what's
> achievable in a bus connected card.
>
> My marketing skills aren't the best, but I'd guess the majority of
> people wanting such a thing on a IIc would be more than satisfied with
> SmartPort speeds. The 'power users' are already using IIe's or IIgs's
> anyway.
>
> Matt
Theoretical maximum transfer rate on a UniDisk 3.5 is 500 kb/s. (From
http://docs.info.apple.com/article.html?artnum=1307&coll=ap)
So, that's 62.5 kB/s.
However, that theoretical maximum can only be approached on a IIGS, I
believe. (Even the accelerated 8-bits will likely stay at 1 MHz the
whole time.) There's lots of SmartPort overhead to deal with, and the
8-bit machines will have to deal with that overhead, whereas a IIGS
can speed up to 2.8 MHz and go past all of that overhead, between
transfers.
Steven Hirsch
> FWIW, the CFFA, running on my 8MHz Zipped //e, delivers 44.4KB/sec
> data bandwidth for BLOADs through BASIC.SYSTEM, so there's something
> to be said for a bus connection. (BTW, transfer rate did not seem
> to be strongly affected by acceleration, even with slot speed set to
> "fast".)
IIRC, the ZipChip does not accelerate code running in expansion ROM. That was
the motivation behind my hack to the RamFast EPROM that copies a little loop
into the stack page to do block I/O. It was originally suggested by Drew
Vogan (RamFast designer) and seemed to make quite a significant improvement
over polled I/O.
Steve
David Empson
> On Feb 3, 7:02 pm, mdj <mdj....@gmail.com> wrote:
> > Interesting - sounds like there's a handshake between bytes that
> > limits its throughput.
> >
> > The Rev C. SCSI (from memory, I think we did this once before) is
> > around 35kb/s on my accelerated IIe. I'd say they're both slow
> > compared to other options, and certainly slow compared to what's
> > achievable in a bus connected card.
> >
> > My marketing skills aren't the best, but I'd guess the majority of
> > people wanting such a thing on a IIc would be more than satisfied with
> > SmartPort speeds. The 'power users' are already using IIe's or IIgs's
> > anyway.
>
> Theoretical maximum transfer rate on a UniDisk 3.5 is 500 kb/s. (From
> http://docs.info.apple.com/article.html?artnum=1307&coll=ap)
>
> So, that's 62.5 kB/s.
That's the raw data transfer rate to/from the disk surface.
The UniDisk 3.5 suffers from several bottlenecks:
1. SmartPort is fixed at 250 kbps (4 microseconds per bit), same as the
5.25" drives.
2. The disk controller requires all data transferred to have bit 7 set,
thus there are only 7 usable bits per byte. This reduces the transfer
rate for user data to 250 * 7/8 = 218.75 kbps.
3. The UniDisk 3.5 has a single IWM, which needs to switch between two
roles: exchanging data with the host, and accessing the drive mechanism.
This means it needs to do all transfers in two stages, using a very
small RAM buffer as a go-between. Since the drive interface is twice as
fast as SmartPort, this gives a 3/2 increase in transfer time, so the
effective data transfer rate is reduced by 2/3, thus 145.8 kbps.
4. The actual data format used on the 3.5" disk requires 6-and-2
encoding. Since SmartPort has already done a 7-and-1 encode/decode, this
is effectively another 1/7 drop in throughput, now down to 124.97 kbps.
5. Seek time to locate the appropriate track (variable).
6. Rotational latency for the desired sector to arrive under the head
(variable).
Ignoring seek and rotational latency, the theoretical maximum transfer
rate for user data to/from a UniDisk 3.5 is about 125 kbps, or 15.625
KB/s.
That's all without any overhead on the Apple II side of the interface.
> However, that theoretical maximum can only be approached on a IIGS, I
> believe.
Nope. The SmartPort and UniDisk 3.5 IWM switching and buffering have
exactly the same overhead on every Apple II model.
The IIgs is able to use an Apple 3.5 Drive, which has the same mechanism
as the UniDisk 3.5 but is able to be accessed by the computer at a raw
transfer rate of 500 kbps (still have 6-and-2 encoding overhead, seek
and rotational latency).
With good drivers (e.g. GS/OS, or ROM 3 firmware), the IIgs is able to
read from an Apple 3.5 Drive with 2:1 interleave twice as fast as it can
read from a UniDisk 3.5 with 4:1 interleave.
(2:1 interleave on a UniDisk 3.5 is horribly slow as it needs an entire
rotation per sector. 4:1 interleave on an Apple 3.5 Drive is just as
slow as the UniDisk due to having to wait for the sector to arrive.)
> (Even the accelerated 8-bits will likely stay at 1 MHz the
> whole time.) There's lots of SmartPort overhead to deal with, and the
> 8-bit machines will have to deal with that overhead, whereas a IIGS
> can speed up to 2.8 MHz and go past all of that overhead, between
> transfers.
Not significant. The data can't get through SmartPort and the UniDisk
internal buffer any faster, so the faster IIgs CPU is twiddling its
thumbs waiting for the next byte to be transferred.
The inter-block rotational delay is sufficient to cover any software
delays getting ready for the next block (at 4:1 interleave) on an 8-bit
Apple II, so the IIgs is just wasting CPU time if it is running in fast
mode.
--
David Empson
dem...@actrix.gen.nz
mdj
> IIRC, the ZipChip does not accelerate code running in expansion ROM. That was
> the motivation behind my hack to the RamFast EPROM that copies a little loop
> into the stack page to do block I/O. It was originally suggested by Drew
> Vogan (RamFast designer) and seemed to make quite a significant improvement
> over polled I/O.
That's a nice trick. No accelerator speeds up the $C800 space since it
could hold anything and change unpredictably.
SmartPort (in theory) suffers worse than others due to being dependant
on 1Mhz speed for IWM comms, then the fact that the "slowdown" timeout
is generalised to worst case.
In practice this would mean the validating the checksum is at least
somewhat impacted by the accelerator being slowed down, and possible
completely impacted, lowering the overall achievable "practical"
transfer rate.
I recall an issue of Nibble back in the day having reasonably
comprehensive disk benchmarks in a HD review which included the
CT-20c. That might shed some light on what can reasonably be expected.
Perhaps Robert could run some simple BLOAD time loops in an Applesoft
program....
Matt
Michael J. Mahon
I agree--it isn't a matter of how well it works, but that it
can be done at all. ;-)
Robert Justice
I created a basic program with 10 bload test,A$4000,L$4000, so 10 x
16K of data. This took 10.6 - 10.9 seconds. so my calculations make
this about 15KBytes/s. Not that fast, but its a start. This time was
from hitting the enter on the run, until the prompt came back. It
took 28.3s for writing, so this was considerably slower. I'll have to
have a look why this is so much slower. The internal floppy took 29.5
for reading, and 148 for writing.
Its interesting that smartport devices where only ever connected to
cards with the IWM on them. Looking at the original disk ii interface,
I don't see why this would not have supported smartport devices, as
they only use the normal timing as per a disk II drive. I suppose they
just used the iwm with the liron, as it needed to be a new card
because of the firmware rom to run the smartport,
Also, i wonder why they have not used the 2x mode available on the
iwm? Although, looking at the code in the iic, it does a good job of
decoding the packet as it comes in. If it where to run the interface
at double speed, then it would probably have to concentrate on reading
the data, and then decode it later. ( if it can read it fast enough)
/Rob
Michael J. Mahon
You're right--it's a big win to decode on the fly, and it saves
another buffer. This was a major speed win in ProDOS relative to
DOS.
You can separate out the data transfer rate from the fixed overhead
by timing BLOADs of different sizes--say, 16KB as you did, and also
8KB and 4KB sizes. Then plot the times vs. size and look at the slope
of the line and the intercept at zero size.
The inverse of the slope is the effective data transfer rate, and the
intercept is the fixed overhead for a BLOAD.
You'll also find it easier to do the timing if you print a beep
(chr$(7)) at the end of the test--it's easier to look at a watch
and listen for a beep than try to look at both the watch and the
prompt. ;-)
It's also handy to up the number of iterations so that the total
time for a test is on the order of a minute. Then if you read the
time to the nearest half-second, you have better than 1% accuracy.
mdj
> I ran some tests to see how the speed compared to all of this theory.
> I created a basic program with 10 bload test,A$4000,L$4000, so 10 x
> 16K of data. This took 10.6 - 10.9 seconds. so my calculations make
> this about 15KBytes/s. Not that fast, but its a start. This time was
> from hitting the enter on the run, until the prompt came back. It
> took 28.3s for writing, so this was considerably slower. I'll have to
> have a look why this is so much slower. The internal floppy took 29.5
> for reading, and 148 for writing.
That's about 75% of what you could reasonably expect for read speed,
so depending on buffering/handshaking between your smartport code and
the IDE bit banging to run the CF card you might be able to get a bit
more, or perhaps not. Do you have enough RAM on the uC to do a couple
of blocks of read-ahead? That might be a speed win. The write speed is
so much slower that it almost has to be somewhere in the IDE code ...
> Its interesting that smartport devices where only ever connected to
> cards with the IWM on them. Looking at the original disk ii interface,
> I don't see why this would not have supported smartport devices, as
> they only use the normal timing as per a disk II drive. I suppose they
> just used the iwm with the liron, as it needed to be a new card
> because of the firmware rom to run the smartport,
I've wondered that myself. A firmware card seems all that is required,
but perhaps there's fanout issues with the original Disk ][ controller
circuitry and they were worried about signal drive strength with
duodisks hanging off a chain of two unidisk 3.5's.
Then again, the Liron cards would have cost nothing to make in
quantity, and probably made it easier to justify the high price they
had at the time.
> Also, i wonder why they have not used the 2x mode available on the
> iwm? Although, looking at the code in the iic, it does a good job of
> decoding the packet as it comes in. If it where to run the interface
> at double speed, then it would probably have to concentrate on reading
> the data, and then decode it later. ( if it can read it fast enough)
2x mode is used for 3.5" drives, and if the Apple II was fast enough
to do it, you wouldn't need SmartPort at all :-) Of course the IIgs
does this, as does the IIc plus, which incidentally has a 2k RAM
buffer added for precisely this reason - it simply can't decode the
data on the fly at 1Mhz.
Apple made a hard drive for the Mac back in the day (HD20) that
probably used that mode, but that idea was discarded in favour of SCSI
across both Apple II and Mac lines. The data payloads of GUI
environments really did dictate faster IO solutions.
Matt
Hugh Hood
Count me among those guys who'll buy a least a couple of these if you bring
your product to market.
My use would be on the IIGS Smartport as supplemental storage.
One question -- will the flash card be swappable / removable while 'hot'?
It seems there are issues when IDE interfaces are mixed in, but as I've read
your description, I gather that IDE won't be involved. Am I mistaken?
BTW, nice nice work. Good for you.
Hugh Hood
Peltier Cedric
> Hi All,
>
> 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
Hi Rob !
Nice to see some interest into the smartport :)
I wrote an harddisk emulator for the smartport last year, and started an
USB adapter for the smartport some months ago.
This adapter is small enough to fit within an external 3"1/2 drive, or
even within the 2c itself.
As I'm not an hardware engineer, I managed to use available hardware to
lower the cost and still get good quality hardware.
Your work is impressive, I will stay tunned for more news :)
Slor
news:fd1d7ed1-4475-4f77...@x18g2000yqe.googlegroups.com:
--
James
http://www.ehostdirect.com
Reliable web hosting from $12/year.
BLuRry
Slor
news:10050569.1789.1337053399517.JavaMail.geo-discussion-forums@vbbgl4:
I hadn't until now - thanks. Looks like the PnP package is still "coming
soon" since January... Any updates on that or anyone now making them?
Looks like a good device at a decent price, assuming it works just as fine
on a IIc Plus.
Slor
news:XnsA0545B01...@69.16.185.252:
> Despite all prevention efforts, BLuRry <brendan...@gmail.com>
> wrote in
> news:10050569.1789.1337053399517.JavaMail.geo-discussion-
forums@vbbgl4:
>
>> Did you see the news on the Smart Port VHD project from Cedric?
>>
>> http://www.spvhd.org/
>>
>
> I hadn't until now - thanks. Looks like the PnP package is still
> "coming soon" since January... Any updates on that or anyone now
> making them? Looks like a good device at a decent price, assuming it
> works just as fine on a IIc Plus.
>
is.
Sean Fahey
> I hadn't until now - thanks. Looks like the PnP package is still "coming
> soon" since January... Any updates on that or anyone now making them?
> Looks like a good device at a decent price, assuming it works just as fine
> on a IIc Plus.
Antoine Vignau
Soldering and making take time, more than expected, that is why he is
not ready yet, especially since he is still improving his device. He
is a real perfectionnnniiiissssttt ;-)
The device software manager is also nearly done.
Antoine
Sean Fahey
> Soldering and making take time, more than expected, that is why he is
Steven Hirsch
On a related subject: Does anyone know first-hand whether Apple SmartPort
devices will work with a Laser 128? I'd love to able to use the SPVHD with my
128EX. The pinouts look compatible, but I'm not 100% sure of the firmware
support and a bit gun-shy about taking the "how lucky do you feel?" approach :-).
Antoine Vignau
As far as the Laser computers are concerned, I think I have one. I
will tell Cédric about it,
antoine