Anybody aware of the description of a 19pin connector of an Apple 5.25 Disk Drive ?

[Peter Dassow]

Hi,

still looking for a description of the 19pin connector (each pin) of an
Apple 5.25" Disk Drive (A9M0107) .... where to find ?

Regards
Peter

[Mark Frischknecht]

GND      1 
GND      2
GND      3
GND      4
-12V     5
+5V      6 
+12V     7
+12V     8
EXTINT   9      
ACK    10
REQ      11
PH1      12
PH2      13
PH3      14
WREQ     15
(NC)     16
DRVEN    17
RDDATA   18 
WRDATA   19

[Peter Dassow]

Ok, thx, are these signals barely just signals from a floppy drive
shugart bus ? I mean can I take a non-Apple floppy disk drive like a
TEAC FD55A drive, and "wire" it in an appropriate way to a 19pin connector ?

[Michael J. Mahon]

Not at all.

They are signals from an Apple Disk ][, which has a much lower-level
interface than the SA390/SA400 from which the Disk ][ was derived by
throwing out the digital control circuitry of the standard product and
leaving only a simplified analog board.

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[Patrick Schaefer]

Am 05.05.2013 09:33 schrieb Peter Dassow:

> Ok, thx, are these signals barely just signals from a floppy drive
> shugart bus ?

Not at all. For the simple drives (Disk II, DuoDisk) these are control
signals similar to the Shugart bus. The main difference ist that Shugart
hat /Step, /Direction and /Track0 while Disk II directly controls the
four step motor phases.

For the more sophisticated drives (3,5", UniDisk and HD20) these lines
run a protocol called "Smartport". Here the step motor lines are used in
a SPI-like manner to communicate with the drive's internal controller.



Patrick

[Peter Dassow]

On 05.05.2013 10:39, Michael J. Mahon wrote:

>>
>> Ok, thx, are these signals barely just signals from a floppy drive
>> shugart bus ? I mean can I take a non-Apple floppy disk drive like a TEAC
>> FD55A drive, and "wire" it in an appropriate way to a 19pin connector ?
>
> Not at all.
>
> They are signals from an Apple Disk ][, which has a much lower-level
> interface than the SA390/SA400 from which the Disk ][ was derived by
> throwing out the digital control circuitry of the standard product and
> leaving only a simplified analog board.
>

I was not asking for a comparison of Shugart Bus vs Apple II Disk Drive Bus.
In 1985, I owned an "Apple II compatible", and I am 100% sure I didn't
own any original Apple II Disk Drive.
Instead, these Floppy Disk Drives were non Apple 3rd party ones.
And they all had only a Shugart Bus (34pin), the flat cables were wired
in a way it was compatible with the simple Apple Disk Controller (it was
not an "Erphi" or another more sophisticated one).
I have also seen already on Ebay some non-Apple Floppy Disk Drives with
a 19pin connector (with a flat cable, which seemed to be selfmade, it
was not a round cable with an encapsulated plug/connector).
My main goal was to make my own cable for my LC Apple IIe Card (not
really an Y-cable, instead just the floppy, and no, I do not need any
"chain" for more than one drive).
Guess I have to figure it out by myself, because nobody made this cable
before :-(

[Michael J. Mahon]

I thought you were confused about the level difference between PC floppy
drives and Apple floppy drives--and you are.

No "cable" can convert the Apple floppy interface to a standard floppy
interface.

In 1982, I converted two standard SA400's to be Disk ][ compatible. It
involved about six pages (single-spaced) of wiring changes to the
digital/analog board in the drive. I recall spending about three hours
modifying each board--lots of wire and solder!

The net effect of the extensive modifications was to disable virtually all
of the digital controller on the board, directly exposing the head stepper
motor phases and directly connecting to the write signal and the detected
head read signal.

Since the SA400 boards were built entirely of MSI TTL chips, all nodes of
the circuit were available for modification. Modern (!) floppy drives have
many fewer chips with higher integration levels, so it is unlikely that
such a modification would still be possible.

[Peter Dassow]

On 06.05.2013 03:11, Michael J. Mahon wrote:

>
> I thought you were confused about the level difference between PC floppy
> drives and Apple floppy drives--and you are.
>
> No "cable" can convert the Apple floppy interface to a standard floppy
> interface.
>
> In 1982, I converted two standard SA400's to be Disk ][ compatible. It
> involved about six pages (single-spaced) of wiring changes to the
> digital/analog board in the drive. I recall spending about three hours
> modifying each board--lots of wire and solder!
>
> The net effect of the extensive modifications was to disable virtually all
> of the digital controller on the board, directly exposing the head stepper
> motor phases and directly connecting to the write signal and the detected
> head read signal.
>
> Since the SA400 boards were built entirely of MSI TTL chips, all nodes of
> the circuit were available for modification. Modern (!) floppy drives have
> many fewer chips with higher integration levels, so it is unlikely that
> such a modification would still be possible.
>
> -michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
>

Ok, I got it, regardless of the fact that I really owned non-Apple
Floppy Disk Drives around 1985. May be these non-Apple Drives were still
compatible to these original ones, I can't check this now.
But this is almost unbelievable that nobody yet created a logic board
with an FPGA/whatever which converts the signals/creates the missing
signals. May be too much old drives are still available ...

[David Schmidt]

On 5/6/2013 2:17 AM, Peter Dassow wrote:
> Ok, I got it, regardless of the fact that I really owned non-Apple
> Floppy Disk Drives around 1985. May be these non-Apple Drives were still
> compatible to these original ones, I can't check this now.
> But this is almost unbelievable that nobody yet created a logic board
> with an FPGA/whatever which converts the signals/creates the missing
> signals. May be too much old drives are still available ...

Indeed, old drives are still plentiful and cheap, for the most part.
Though not everywhere in the world, of course. The function necessary
would be to duplicate the analog board that currently lives inside the
Disk II drive.

Several FGPA/whatever boards have been produced over the years to
interface to drives in various ways, not all having to do with the Apple II:

Kryoflux
FC-5025
HDDD

Experiments exist going the other direction, such as Mike Willegal's
USB-to-Disk II drive:
http://www.willegal.net/appleii/appleii-disk-int.htm

But the need/incentive to go from Disk II interface to some other kind
of floppy drive simply hasn't arisen.

[barrym95838]

>
> Ok, I got it, regardless of the fact that I really owned non-Apple
>
> Floppy Disk Drives around 1985. May be these non-Apple Drives were still
>
> compatible to these original ones, I can't check this now.
>
> But this is almost unbelievable that nobody yet created a logic board
>
> with an FPGA/whatever which converts the signals/creates the missing
>
> signals. May be too much old drives are still available ...

Hi, Peter

I believe that the Disk ][ was one of Woz' proudest moments. It is a marvel of simplicity, made possible by clever software timing loops that do all of the encoding, decoding, and seeking. The Apple ][ is unique among many of its contemporaries in that it was possible to disable interrupts with almost no side-effects, making this implementation feasible. The Ataris and Commodores needed smarter interface hardware, because they couldn't really afford to disable interrupts for any length of time without annoying the user in some way. The Apple system was primitive, but faster than most of its contemporaries ... credit Woz for that. It should have been cheaper too, but Apple was responding appropriately to supply and demand at that time.

My first disk drive for my ][+ was a cheaper clone called Lobo, which I bought in 1983. It was plug-compatible ... I know, I tried it on different systems with the official Disk ][ interface. My Franklin Ace has internal drives, but the fact that it can run DOS 3.3 unmodified tells me that it has a functionally identical interface as well.

Take care,

Mike

[Patrick Schaefer]

Am 06.05.2013 08:17 schrieb Peter Dassow:

> But this is almost unbelievable that nobody yet created a logic board
> with an FPGA/whatever which converts the signals/creates the missing
> signals. May be too much old drives are still available ...

You don't need a FPGA, the circuit is rather simple.

This is the schematic diagram of an Ehring FDC4
http://www.harrowalsh.de/Elektronik/APPLEBOX/Images/FDC4Schaltplan.jpg
and the conversion logic is the part on the right, between the 20pin and
34pin connector


Regards
Patrick

[Michael Black]

On Mon, 6 May 2013, David Schmidt wrote:

> On 5/6/2013 2:17 AM, Peter Dassow wrote:
>> Ok, I got it, regardless of the fact that I really owned non-Apple
>> Floppy Disk Drives around 1985. May be these non-Apple Drives were still
>> compatible to these original ones, I can't check this now.
>> But this is almost unbelievable that nobody yet created a logic board
>> with an FPGA/whatever which converts the signals/creates the missing
>> signals. May be too much old drives are still available ...
>
> Indeed, old drives are still plentiful and cheap, for the most part. Though
> not everywhere in the world, of course. The function necessary would be to
> duplicate the analog board that currently lives inside the Disk II drive.
>

Some of the issue now is that they've disappeared. It wasn't that long
ago that I was still regularly seeing computers on the sidewalk with the
5.25" drives. But it's been a while since that happened. They were so
common, I never bothered to collect a lot. So the only 5.25" drives I
have are the relative few that I did pull out of discarded computers, that
and the two drives I bought new in 1984 and a few years later at fairly
high prices. I seem to have more 3.5" drives than 5.25" lying around.

I'm sure thay are still out there, but not as easy as at one time.

Michael

[Michael J. Mahon]

And it can't do quarter-tracking... ;-)

[Michael J. Mahon]

And it must be pointed out that none of these "flux pattern capture"
devices actually emulates a Disk ][. They can only be used to enable a
non-Apple II machine to capture the data recorded on an Apple (or other)
diskette.

[Michael J. Mahon]

Yes, there were countless third-party Disk ][ compatible
drives--full-height and half-height. All had standard mechanisms and
distinctly non-standard electronics. They all had 20-pin ribbon cables, not
34.

And there is no way that a standard drive with standard controls can be
made to do the fractional track tricks that can be done with a Disk ][
compatible drive.

Although it is relatively easy to use an "adapter" to raise the semantic
level of an interface, it is not generally possible to use an adapter to
*lower* the level of an interface. When you add in the real-time nature of
the Disk ][ interface, it's game over.

[Phil Tubb]

On Monday, May 6, 2013 8:06:31 AM UTC-7, barrym95838 wrote:
> I believe that the Disk ][ was one of Woz' proudest moments. It is a marvel of simplicity, made possible by clever software timing loops that do all of the encoding, decoding, and seeking. The Apple ][ is unique among many of its contemporaries in that it was possible to disable interrupts with almost no side-effects, making this implementation feasible. The Ataris and Commodores needed smarter interface hardware, because they couldn't really afford to disable interrupts for any length of time without annoying the user in some way. The Apple system was primitive, but faster than most of its contemporaries ... credit Woz for that. It should have been cheaper too, but Apple was responding appropriately to supply and demand at that time.
>

Sorry, I have to disagree. While the Disk II design is very clever in terms of minimizing chip count, in every other respect it is unusually bad. Personally, I've designed professional duplication equipment for pretty much every floppy disk format ever developed, including a unit with the world record for copying speed. If you want to see a brilliant design, look at the Amiga disk controller.

Back in the day, Apple had reps that traveled around to visit companies, like mine, that made products for the Apple (in our case, music cards at that time). Our rep brought an early Disk II to show off. He read some files, and I asked him if this unit was broken. He was confused and wanted to know why I asked that. I told him, because it's incredibly slow... the slowest drive I've ever seen. And of course he responded that it was the fastest drive on the market. I read the same size files using a floppy drive on an IMSAI 8080, and it was many many times faster.

As it turns out, the Disk II design was vastly inferior to the prevailing designs of the day, except in a few specs. (1) it was a lot cheaper. That was good for Apple, but they sold it at a huge markup, so it wasn't much cheaper than the other designs (which at that time, were largely for S-100 systems like the Altair 8800 and IMSAI 8080 I just mentioned). (2) it sort of had more capacity. A lot of disk systems at the time used single-sided single-density recording, but everyone who made S-100 floppy systems was in the process of moving to single-sided double-density with the controller being capable of double-sided double-density (but double-sided drives weren't available yet). Once Apple switched from 13 to 16 sector, they had more storage per disk than the single-density systems which were then being phased out in the S-100 world. But the Apple formats had LESS storage than the double-density systems. (3) The Apple disks were arranged in 35 tracks (even though in S-100 systems disks with 40 tracks were coming out), and the recording heads had to "step" to the desired track in order to read or write it. On other designs, the time it took to step, say, 15 tracks was almost exactly 15 times what it took to step 1 track. On the Apple design, if the distance (number of tracks) you wanted to step was large, the controller could cut the step time down significantly. However, well-written operating systems are designed to keep files together so you rarely have to step more than one track; Apple's design couldn't step one or two tracks any faster than any other design. And this was the ONLY parameter that relates to speed that Apple improved compared to prevailing designs. It's pretty much the single most useless speed parameter to improve.

On top of that, the Apple design had a lot of disadvantages:

(1) Although it used group code recording, which was becoming common in the hard drive world but not in floppy disks, it used it at a very low density (which is why the S-100 system's less-efficient MFM encoding none-the-less gave more storage: because it was at a higher density). Apple couldn't increase the density easily with their design, unless they made an equal increase in processor and peripheral-bus speeds.

(2) The reason it was originally incredibly slow had to do with the software decoding; in other words, all the "stuff" that Apple moved from hardware to software in order to reduce the chip count. If you look at Wikipedia's article on "Apple DOS", you'll see that originally a track had the sectors written in this order: 0 7 14 6 13 5 12 4 11 3 10 2 9 1 8 15. This was done to give the software time to decode each sector after it was read. Let's say you want to read all the sectors on a track in order (a very common operation). In the very best case, with this arrangement sector 0 would just happen to be right there ready for you to read. In the same single rotation of the disk, you'd wait as sectors 7, 14, 6, 13, 5, 12, 4, 11, 3, 10, 2, and 9 go by, then you'd read sector 1. (Of course during this "waiting" the software would actually be decoding the raw data read from the disk for sector 0.) Then you'd wait while sectors 8 and 15 go by, and that's the end of the first spin... each spin takes 1/5th of a second. In the next spin, you'd wait while sectors 0, 7, 14, 6, 13, 5, 12, 4, 11, 3, and 10 go by, then read sector 2. Again, you'd be decoding sector 1 while these sectors go by. Then you'd wait while sectors 9, 1, 8, and 15 go by; that's the end of the second spin. You can see it's going to take a whole lot of rotations, at 1/5 second each, to read the track. In contrast, the hardware on S-100 systems of the day easily read all the sectors in one spin (best case); there was no need to allow sectors to pass by while the processor decoded the raw data because the floppy-controller chip could do that by itself. Worst case, the S-100 systems would JUST MISS sector 0 and have to wait one spin for it to come around (the same thing can happen to Apple as well), then use one spin to read every sector on the track.

(3) Adding to the slowness, the S-100 systems could use DMA to move the data from the disk controller into the computer's memory, leaving the computer free to run software. Best case, this means nearly zero computer time is used to read the disk; more commonly (back then), accessing DMA slows the processor down so it runs at half speed (this all depends on the design of the DMA system and the speed of the memory). The S-100 systems typically used interrupts to summon the processor whenever commands needed to be issued to the control circuitry, and as Mike mentioned this means if you turn interrupts off for too long it will take longer to read the disk. The Apple design not only didn't use DMA, and therefore wasted processor time simply moving the data from the card to the computer's memory, it also required software decoding of the data, another complete waste of processor capability compared to S-100 systems. Furthermore, Apple COULDN'T use DMA because, in order to save a single gate which would have cost a few cents, they messed up the Apple's DMA system rendering it almost completely useless. (Specifically, if you used DMA for more than a few memory cycles in a row, all the registers in the 6502 were scrambled... including the register telling the processor where it's at in the program being run. Had Apple including the inexpensive gate, DMA would have been usable with any number of cycles and never disrupted the processor's functions.)

(4) Like the double-density formats (MFM) everyone else was going to, Apple's GCR formats were very unreliable unless special circuitry is used to overcome certain technical difficulties. The S-100 systems featuring double-density had such circuitry; Apple never added it. (The most common method was called "write pre-compensation" which used subtle timing changes to create a more readable magnetic pattern. In our professional duplicators, used such circuitry not only for MFM formats, but for Apple formats as well... thus making disks made with our equipment much more readable on various drives than a disk written with an Apple. An Apple could read a disk written on the same drive fairly well, but not nearly as well as standard single-density systems and double-density systems with pre-comp; but readability really suffered when the drive reading the disk was at one end of the normal range in adjustments and the drive that wrote the disk was at the other end of the range.)

Bottom line, the Apple Disk II design was clever in that it had a low chip count and was cheap to manufacture, but it suffered very badly in all other respects compared to just using the regular FM/MFM design with the standard floppy controller chips. How anyone could claim it was faster than the S-100 floppy drives of the same period is beyond me... obviously they never tried them side-by-side.

[Michael Black]

On Mon, 6 May 2013, Phil Tubb wrote:


> As it turns out, the Disk II design was vastly inferior to the
> prevailing designs of the day, except in a few specs. (1) it was a lot
> cheaper. That was good for Apple, but they sold it at a huge markup, so
> it wasn't much cheaper than the other designs (which at that time, were
> largely for S-100 systems like the Altair 8800 and IMSAI 8080 I just
> mentioned).

I think a lot of the "Great Design" revolves around the simplicity. Take
things off the floppy drive, and then the actual controller becomes so
much simpler. That seems so contradictory. But it's just looked at by
itself.

If you look at 1977, then it was a good choice probably. I remember the
TTL level controllers in Byte. or the Ohio Scientific disk controller that
used a USART and plenty of other ICs to do the work, or even the first
wave of floppy disk controller ICs that still required lots of work.

But as you say, adding a floppy disk to the Apple II was not cheap, though
I'm not sure considering the cost of floppy drives if it wasn't somewhat
cheaper.

But, it didn't take long before there were better floppy disk controller
ICs. Less external circuitry needed and then later virtually none. That
shifts things. But Apple was stuck with their system, so everyone had to
buy Apple drives unless they were willing to modify the drive (and at the
time, I don't remember seeing anything about that, though I never really
read Apple specific magazines back then). The cost of the standard drives
dropped constantly, and then you could buy 3.5" drives that were cheap.

So the neat design was only valuable for a short period, after which it
became a liability.

I was given a Mac Plus in the fall of 1993, it had a bad connector to the
deflection yokes. Once I just soldered the wires, rather than using the
connector, it was fine.

But there I was with a free Mac Plus and only one floppy drive. A second
floppy drive would have cost quite a bit. I ended up with my first hard
drive because I couldn't live with one floppy drive and the hard drive
wasn't really that much more than a new 3.5" floppy drive from Apple.

I'd already bought a 3.5" floppy for about 80.00 in 1989, by 1993 they
were even cheaper, but because of the neat but non-standard drive, I
couldn't use one of those.

So yes, a neat initial design that cost Apple less ended up costing the
users more in the long run.

Michael

[barrym95838]

On Monday, May 6, 2013 4:09:01 PM UTC-7, Phil Tubb wrote:
>
> Sorry, I have to disagree. While the Disk II design is very clever in terms of minimizing chip count, in every other respect it is unusually bad. Personally, I've designed professional duplication equipment for pretty much every floppy disk format ever developed, including a unit with the world record for copying speed. If you want to see a brilliant design, look at the Amiga disk controller.
>

[...]

>
> Bottom line, the Apple Disk II design was clever in that it had a low chip count and was cheap to manufacture, but it suffered very badly in all other respects compared to just using the regular FM/MFM design with the standard floppy controller chips. How anyone could claim it was faster than the S-100 floppy drives of the same period is beyond me... obviously they never tried them side-by-side.

Oops, you're correct, Phil. I have no experience with S-100 designs; I was speaking from my limited TRS-80, Commodore, Atari, and Apple experiences. Since you clearly have at least an order of magnitude more knowledge than I on the subject, I humbly concede to the majority of your points.

Take care,

Mike

[barrym95838]

On Monday, May 6, 2013 4:09:01 PM UTC-7, Phil Tubb wrote:
>

[...]
> ... If you look at Wikipedia's article on "Apple DOS", you'll see that originally a track had the sectors written in this order: 0 7 14 6 13 5 12 4 11 3 10 2 9 1 8 15. This was done to give the software time to decode each sector after it was read. Let's say you want to read all the sectors on a track in order (a very common operation). In the very best case, with this arrangement sector 0 would just happen to be right there ready for you to read. In the same single rotation of the disk, you'd wait as sectors 7, 14, 6, 13, 5, 12, 4, 11, 3, 10, 2, and 9 go by, then you'd read sector 1. (Of course during this "waiting" the software would actually be decoding the raw data read from the disk for sector 0.) Then you'd wait while sectors 8 and 15 go by, and that's the end of the first spin... each spin takes 1/5th of a second. In the next spin, you'd wait while sectors 0, 7, 14, 6, 13, 5, 12, 4, 11, 3, and 10 go by, then read sector 2. Again, you'd be decoding sector 1 while these sectors go by. Then you'd wait while sectors 9, 1, 8, and 15 go by; that's the end of the second spin. You can see it's going to take a whole lot of rotations, at 1/5 second each, to read the track. In contrast, the hardware on S-100 systems of the day easily read all the sectors in one spin (best case); there was no need to allow sectors to pass by while the processor decoded the raw data because the floppy-controller chip could do that by itself. Worst case, the S-100 systems would JUST MISS sector 0 and have to wait one spin for it to come around (the same thing can happen to Apple as well), then use one spin to read every sector on the track.
>

The following is anecdotal, because I forgot where I read it.

You mentioned the staggering of sectors on individual tracks, allowing the next readable sector to appear just as the decoding of the previous was complete. One thing that I noticed was that DOS 3.3 seemed to boot-load more quickly than a standard BLOAD; I read that the boot tracks had been carefully interleaved for optimal throughput, but that standard files were stored with a simpler, slower ordering. Have any of you guys heard about this? Were there any DOS 3.3 RWTS mods that took advantage of this, improving performance? If I'm being foolishly naive, I'm prepared for the beating ;-)

Mike

[David Schmidt]

On 5/7/2013 9:33 PM, barrym95838 wrote:
> You mentioned the staggering of sectors on individual tracks, allowing the next readable sector to appear just as the decoding of the previous was complete. One thing that I noticed was that DOS 3.3 seemed to boot-load more quickly than a standard BLOAD; I read that the boot tracks had been carefully interleaved for optimal throughput, but that standard files were stored with a simpler, slower ordering. Have any of you guys heard about this? Were there any DOS 3.3 RWTS mods that took advantage of this, improving performance? If I'm being foolishly naive, I'm prepared for the beating ;-)

There are simpler and less efficient (in terms of disk utilization)
encoding schemes that are faster to decode - some "protection" schemes
took advantage of them to enable very fast load times. As long as you
don't need the complete theoretical capacity of the Disk II, it was a
great way to very quickly blink hi-res screens up once power is applied.

[John B. Matthews]

In article <d77fb4f6-5414-4cec...@googlegroups.com>,

barrym95838 <barry...@yahoo.com> wrote:

> You mentioned the staggering of sectors on individual tracks,
> allowing the next readable sector to appear just as the decoding of
> the previous was complete. One thing that I noticed was that DOS 3.3
> seemed to boot-load more quickly than a standard BLOAD; I read that
> the boot tracks had been carefully interleaved for optimal
> throughput, but that standard files were stored with a simpler,
> slower ordering. Have any of you guys heard about this? Were there
> any DOS 3.3 RWTS mods that took advantage of this, improving
> performance? If I'm being foolishly naive, I'm prepared for the
> beating ;-)

The utility described in the article "Living with a Language Card" from
"In Depth: All about DOS" leveraged the DOS stage two boot loader to
speed up loading a language card.

The source/code is on DOS In Depth D1:

<http://www.callapple.org/soft/ap2/indepth.html>

  B 040 FASTBOOT 3.3 CREATE.S
  B 006 FASTBOOT 3.3 CREATE

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[Antoine Vignau]

@ Mike: DOS 3.3 code boots a little bit faster because the code which puts it into memory simply loads from track 2 / sector 4 to track 0 / sector A-C (depending on the relocator code).

It is easier and faster to handle than files but there is no improved interleaving or whatever.

The main issue which DOS 3.3 vs other DOSes is the use of an intermediate buffer before data is put at the right place in memory.

Antoine

[Michael J. Mahon]

I think it's important not to compare Apples to oranges. ;-)

Pricing aside--since that's a market issue, not a technology issue--the
Disk ][ interface was a technical tour de force of cost reduction and
performance improvement relative to its competitors in the marketplace,
which were certainly not S-100 systems.

The elegance of the hardware-software tradeoffs and the state sequencer
data separator were, and still are, paragons of cross-domain design and
optimization.

I have never encountered any practical reliability issues with the
formatting and encoding methods, even with substandard media.

Finally, the huge contribution of a low-cost, relatively high performance
(c.f.: Commodore, Atari, TI, Radio Shack, etc.) disk subsystem to Apple's
bottom line played a big role in Apple's survival as a company.

[Peter Dassow]

On 06.05.2013 12:31, David Schmidt wrote:
> On 5/6/2013 2:17 AM, Peter Dassow wrote:

>> But this is almost unbelievable that nobody yet created a logic board
>> with an FPGA/whatever which converts the signals/creates the missing
>> signals. May be too much old drives are still available ...
>
> Indeed, old drives are still plentiful and cheap, for the most part.
> Though not everywhere in the world, of course. The function necessary
> would be to duplicate the analog board that currently lives inside the
> Disk II drive.
>

> [...]

> But the need/incentive to go from Disk II interface to some other kind
> of floppy drive simply hasn't arisen.

What's about this one ?
http://www.bootzero.com/HDDD_A2_v1.2/HDDD_A2v1.2_specifications.html

[David Schmidt]

Yes indeed, I mentioned that to you in both this thread (the next few
lines in the same message you quoted above) and the same thread you
started in c.s.m.vintage. But the HDDD isn't a simple cable - it is a
programmed processor that provides a very accurate mapping from Disk II
signals to a modern HD 3.5" floppy drive.

So - what about it? It's a brilliant piece of hardware and firmware.
It has a very interesting use case - making the arguably more-available
HD 3.5" floppy disks useable as direct replacements for 5.25" media.
Apple II software running on it can scarcely tell the difference. It's
compatible at a very low level. I think we'll eventually see all
spinning magnetic media go the way of the buggy whip, but HDDD
definitely buys some time.

It still doesn't help you use your TEAC FD55A, though. :-)

[Peter Dassow]

On 09.05.2013 01:14, David Schmidt wrote:

>>> [...]
>>> But the need/incentive to go from Disk II interface to some other kind
>>> of floppy drive simply hasn't arisen.
>>
>> What's about this one ?
>> http://www.bootzero.com/HDDD_A2_v1.2/HDDD_A2v1.2_specifications.html
>
> Yes indeed, I mentioned that to you in both this thread (the next few
> lines in the same message you quoted above) and the same thread you
> started in c.s.m.vintage.

Yes, you mentioned it, but without details. It's made for the Apple II
only, so it should have a particular importance.

> But the HDDD isn't a simple cable - it is a
> programmed processor that provides a very accurate mapping from Disk II
> signals to a modern HD 3.5" floppy drive.
>
> So - what about it? It's a brilliant piece of hardware and firmware. It
> has a very interesting use case - making the arguably more-available HD
> 3.5" floppy disks useable as direct replacements for 5.25" media. Apple
> II software running on it can scarcely tell the difference. It's
> compatible at a very low level. I think we'll eventually see all
> spinning magnetic media go the way of the buggy whip, but HDDD
> definitely buys some time.
>
> It still doesn't help you use your TEAC FD55A, though. :-)

May be it helps to connect a TEAC FD55G (which does not mean it results
in a "compatible" format but in the same size).
It's an option for me because in Europe I have no chance to get an Apple
5.25" Floppy Drive (A9M0107), and if I try to purchase it in the U.S.,
this will result in a long waiting period and a very high price
(shipping costs for one drive about $50 or more - far too expensive).
And I need it just to copy the content of a floppy image file back to a
media, because the Apple IIe card can't use image files.