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

On Jan 28, 8:48=A0am, Robert Justice <rjust...@internode.on.net> wrote:

Awesome!

> Details are in a quick write up at this link:http://www.users.on.net/~rju=
stice/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!

Robert Justice wrote:
> 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.

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

Despite all prevention efforts, Robert Justice <rjustice@internode.on.net> 
wrote in news:h5t3k655td0s03h1oni6kee870845k7po1@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.

Il Fri, 28 Jan 2011 09:48:53 +1100, Robert Justice
<rjustice@internode.on.net> ha scritto:

>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.
>
Oh, yes. This is a very fine job!
2 card for me, thanks.

Ciao

Giorgio
Apple II and Apple III forever !!!

Robert Justice <rjustice@internode.on.net> wrote:

> 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

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
dempson@actrix.gen.nz

On 01/27/2011 05:48 PM, Robert Justice wrote:
> 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

Put me down for two, please :-)

On Jan 27, 4:48=A0pm, Robert Justice <rjust...@internode.on.net> wrote:
> 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/~rju=
stice/SmartportCFA/SmartportCFA.htm
>
> Hope you guys find it interesting.
>
> regards
> Rob

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

On Jan 27, 4:48=A0pm, Robert Justice <rjust...@internode.on.net> wrote:

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

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.

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.

On Jan 28, 12:16=A0pm, Sean Fahey <a2...@hotmail.com> wrote:
> 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.
>
> https://ultimateapple2.com/catalogua2/index.php?main_page=3Dproduct_inf..=
..
>
> 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.

Eric Rucker wrote:
> On Jan 28, 12:16 pm, Sean Fahey <a2...@hotmail.com> wrote:
> 
>>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.
>>
>>https://ultimateapple2.com/catalogua2/index.php?main_page=product_inf...
>>
>>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.

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

On Jan 28, 3:17=A0pm, Eric Rucker <bhtoo...@gmail.com> wrote:

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

I agree with your thoughts Michael, i would have thought that
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

On Thu, 27 Jan 2011 17:23:00 -0800, "Michael J. Mahon"
<mjmahon@aol.com> wrote:

>Robert Justice wrote:
>> 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.
>
>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'm confident it would work ok on the IIc+. From a timing point of
view with the smartport, it should not have changed. 


On Fri, 28 Jan 2011 04:59:44 GMT, Slor <semaj@rols.ten> wrote:

>Despite all prevention efforts, Robert Justice <rjustice@internode.on.net> 
>wrote in news:h5t3k655td0s03h1oni6kee870845k7po1@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...

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?

And thanks for all of your positive comments.

/Rob 

On Jan 27, 4:48=A0pm, Robert Justice <rjust...@internode.on.net> wrote:
> 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/~rju=
stice/SmartportCFA/SmartportCFA.htm
>
> Hope you guys find it interesting.
>
> regards
> 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 =3D no go
D) awesome build

Sean Fahey <a2fan@hotmail.com> writes:

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

Robert Justice wrote:
> 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?

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.

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

Hi Robert,
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

On Jan 28, 11:34=A0pm, Robert Justice <rjust...@internode.on.net> wrote:

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

On Jan 29, 3:26=A0pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> Robert Justice wrote:
> > 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?
>
> 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. =A0;-)
>
> > And thanks for all of your positive comments.
>
> You're welcome! =A0This is a great advance for these "portable" machines.
>
> -michael
>
> NadaNet 3.1 for Apple II parallel computing!
> Home page: =A0http://home.comcast.net/~mjmahon/
>
> "The wastebasket is our most important design
> tool--and it's seriously underused."

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.

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=A0pm, 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

On Jan 29, 8:20=A0pm, Warren Ernst <wer...@gmail.com> 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=A0pm, 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

You can always get an SD to CF adapter...

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

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

On Sat, 29 Jan 2011, Michael J. Mahon wrote:

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

On Jan 29, 8:25=A0pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> 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. =A0;-)
>
> CF is clearly on its way out, as prices and availability show.
>
> And the connector itself is a nightmare of tiny pins...
It's actually to the point that, in bulk, microSD cards are cheaper
than the actual flash chips inside of them, due to economies of scale.

Despite all prevention efforts, Robert Justice
<rjustice@internode.on.net> wrote in
news:j967k6hqoi3p0tjk69r0kk5cpq3ipn0ti8@4ax.com: 

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

Toinet <antoine.vignau@laposte.net> wrote:

> Hi Robert,
> 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 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
dempson@actrix.gen.nz

On Jan 30, 11:25=A0am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> 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. =A0;-)
>
> 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.

On Jan 29, 3:15=A0pm, Robert Justice <rjust...@internode.on.net> wrote:
> 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

On Jan 29, 7:06=A0pm, Eric Rucker <bhtoo...@gmail.com> wrote:
> On Jan 29, 3:26=A0pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
>
>
>
>
>
>
>
>
> > Robert Justice wrote:
> > > It could be used internally by piggy backing on the existing internal
> > > drive connector. The Smartport interface does not care about the driv=
e
> > > 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 th=
e
> > > 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 ma=
y
> > > 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 yo=
u
> > > to test.
>
> > > Is there a preference for either CF or SD card?
>
> > 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. =A0;-)
>
> > > And thanks for all of your positive comments.
>
> > You're welcome! =A0This is a great advance for these "portable" machine=
s.
>
> > -michael
>
> > NadaNet 3.1 for Apple II parallel computing!
> > Home page: =A0http://home.comcast.net/~mjmahon/
>
> > "The wastebasket is our most important design
> > tool--and it's seriously underused."
>
> 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'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.

On Jan 30, 11:20=A0pm, Payton Byrd <plb...@gmail.com> wrote:
> On Jan 29, 7:06=A0pm, Eric Rucker <bhtoo...@gmail.com> wrote:
>
>
>
>
>
> > On Jan 29, 3:26=A0pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> > > Robert Justice wrote:
> > > > It could be used internally by piggy backing on the existing intern=
al
> > > > drive connector. The Smartport interface does not care about the dr=
ive
> > > > 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 bein=
g
> > > > 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 car=
d,
> > > > 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 t=
he
> > > > 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?
>
> > > 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. =A0;-)
>
> > > > And thanks for all of your positive comments.
>
> > > You're welcome! =A0This is a great advance for these "portable" machi=
nes.
>
> > > -michael
>
> > > NadaNet 3.1 for Apple II parallel computing!
> > > Home page: =A0http://home.comcast.net/~mjmahon/
>
> > > "The wastebasket is our most important design
> > > tool--and it's seriously underused."
>
> > 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'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. =A0I think keeping the medium consistent will allow
> users to get more value. =A0I 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.

On Jan 27, 2:48=A0pm, Robert Justice <rjust...@internode.on.net> wrote:
> 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?

On Jan 27, 10:48=A0pm, Robert Justice <rjust...@internode.on.net> wrote:
> 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/~rju=
stice/SmartportCFA/SmartportCFA.htm
>
> Hope you guys find it interesting.
>
> regards
> Rob

Kool i would definitely be interested in a couple. Nice Work!

Drew

On Jan 29, 12:34=A0am, Robert Justice <rjust...@internode.on.net> wrote:
> 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?
>
> And thanks for all of your positive comments.
>
> /Rob

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.

On Jan 29, 6:34=A0pm, 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. ;-)

Also, external first; an internal option later would be great.

Cheers,
Nick.

sicklittlemonkey wrote:
> 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.

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

On Feb 2, 7:52=A0pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> I've been looking at SD-->CF converters. =A0The compact ones (that would
> fit in a CFFA with the lid closed) are all CF Type II (thicker). =A0Will
> 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.

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)

On Feb 2, 6:25=A0am, Robert Justice <rjust...@internode.on.net> wrote:
> 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.
Out of curiosity, what license is the stuff that you've posted under?

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

I un-mothballed my XGS AVR and implemented Roberts project using it's
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

On Jan 27, 5:48=A0pm, Robert Justice <rjust...@internode.on.net> wrote:
> 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/~rju=
stice/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

On Jan 29, 12:34=A0am, Robert Justice <rjust...@internode.on.net> wrote:
> 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?
>
> And thanks for all of your positive comments.
>
> /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

On Feb 3, 6:58=A0am, Delfs <eeast...@gmail.com> wrote:
> On Jan 27, 5:48=A0pm, Robert Justice <rjust...@internode.on.net> wrote:
>
> > 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/~r=
justice/SmartportCFA/SmartportCFA.htm
>
> > Hope you guys find it interesting.
>
> > regards
> > Rob
>
> Wow, this is fantastic work. =A0We 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.) =A0As 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. =A0I 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. =A0Very Kewl as some might say.
>
> Thankx,
> Ed

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

On Feb 3, 10:12=A0pm, Delfs <eeast...@gmail.com> wrote:

> 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. =A0Personally 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

mdj wrote:
> On Feb 3, 10:12 pm, Delfs <eeast...@gmail.com> wrote:
> 
> 
>>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.

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

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

On Feb 4, 9:18=A0am, "Michael J. Mahon" <mjma...@aol.com> wrote:

> 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. =A0(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

On Feb 3, 7:02=A0pm, 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.
>
> Matt

Theoretical maximum transfer rate on a UniDisk 3.5 is 500 kb/s. (From
http://docs.info.apple.com/article.html?artnum=3D1307&coll=3Dap)

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.

On 02/03/2011 06:18 PM, Michael J. Mahon wrote:

> 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

Eric Rucker <bhtooefr@gmail.com> wrote:

> 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
dempson@actrix.gen.nz

On Feb 4, 12:10=A0pm, Steven Hirsch <snhir...@gmail.com> wrote:

> IIRC, the ZipChip does not accelerate code running in expansion ROM. =A0T=
hat was
> the motivation behind my hack to the RamFast EPROM that copies a little l=
oop
> into the stack page to do block I/O. =A0It was originally suggested by Dr=
ew
> Vogan (RamFast designer) and seemed to make quite a significant improveme=
nt
> 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

mdj wrote:
> On Feb 4, 9:18 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> 
> 
>>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.

I agree--it isn't a matter of how well it works, but that it
can be done at all.  ;-)

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

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

Robert Justice wrote:
> 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.
> 
> 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)

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.

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

On Feb 5, 5:03=A0pm, Robert Justice <rjust...@internode.on.net> wrote:
> 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 =A010.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. =A0It
> 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

Rob,

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

Le 27/01/2011 23:48, Robert Justice a �crit :
> 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 :)

Despite all prevention efforts, a2retro <rg.jones@rogers.com> wrote in 
news:fd1d7ed1-4475-4f77-9030-e5e53b00030a@x18g2000yqe.googlegroups.com:

> I un-mothballed my XGS AVR and implemented Roberts project using it's
> 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.
> 

Any news on this project?

-- 
James
http://www.ehostdirect.com
Reliable web hosting from $12/year.

Did you see the news on the Smart Port VHD project from Cedric?

http://www.spvhd.org/

-B

On Monday, May 14, 2012 2:05:53 PM UTC-5, Slor wrote:
> Despite all prevention efforts, a2retro <rg.jones@rogers.com> wrote in 
> news:fd1d7ed1-4475-4f77-9030-e5e53b00030a@x18g2000yqe.googlegroups.com:
> 
> > I un-mothballed my XGS AVR and implemented Roberts project using it's
> > 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.
> > 
> 
> Any news on this project?
> 
> -- 
> James
> http://www.ehostdirect.com
> Reliable web hosting from $12/year.

Despite all prevention efforts, BLuRry <brendan.robert@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.

-- 
James
http://www.ehostdirect.com
Reliable web hosting from $12/year.

Despite all prevention efforts, Slor <semaj@rols.ten> wrote in
news:XnsA0545B010FC23emuslor@69.16.185.252: 

> Despite all prevention efforts, BLuRry <brendan.robert@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.
> 

I dropped him an email, so I guess I'll find out what the current status 
is.

-- 
James
http://www.ehostdirect.com
Reliable web hosting from $12/year.

On Tuesday, May 15, 2012 7:56:19 AM UTC-5, Slor wrote:

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

Cedric replied back to me a few weeks ago, that he was very busy but was still trying to get the first batch of SPVHD drives done. They are apparently more labor-intensive than initially estimated. All the drives in the first batch are spoken for.

I met C=E9dric last Sunday.
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

On Tuesday, May 15, 2012 12:25:00 PM UTC-5, Antoine Vignau wrote:

> Soldering and making take time, more than expected, that is why he is

Don't you know how to solder? <LOL>

On 05/15/2012 10:02 AM, Sean Fahey wrote:
> On Tuesday, May 15, 2012 7:56:19 AM UTC-5, Slor wrote:
>
>> 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.
>
> Cedric replied back to me a few weeks ago, that he was very busy but was
> still trying to get the first batch of SPVHD drives done. They are
> apparently more labor-intensive than initially estimated. All the drives in
> the first batch are spoken for.

Worth waiting for, in my opinion.  It's the real deal.

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

On 15 mai, 23:21, Sean Fahey <a2...@hotmail.com> wrote:
> On Tuesday, May 15, 2012 12:25:00 PM UTC-5, Antoine Vignau wrote:
> > Soldering and making take time, more than expected, that is why he is
>
> Don't you know how to solder? <LOL>

Ahem, no ;-)

As far as the Laser computers are concerned, I think I have one. I
will tell C=E9dric about it,
antoine