Apple II Cassette port and Disk Transfers to/from other PCs

[James Davis]

Hi all, Jorge and Oliver, and everyone interested in a poor-man's ADT:

I get the impression, from reading the reverie in "What did an original Apple II sell for?" that it may be possible to use the Apple II Cassette port to do Disk Transfers to/from other PCs at a much higher rate than what is currently possible with ADT, if one reduces the resistance of the Cassette-Output resistor (R19 on an Apple II/II+ and R6 on an Apple IIe/Enhanced IIe).

Is this so?
And, is it just one way (on the output) or will it work both ways?
And, only with Apple II's and/or Mac's?
Or, will it work between Windows PC's and Apple II's, also?
And, at what (much higer) rate?

Also, could it be used as I/O into/out-of an RS232 TO USB adapter/converter?
Or, is this idea overkill and unnecessary?

I calculated that a resistance of 100.84 ohms in parallel with the 12 K-ohm Cassette-Output resistor would bring the total resistance down to 100 ohms, the same as the resistance to ground on the bottom side of the cassette output circuit, thus balancing the signal halfway between zero and five volts (0v~5v) DC. So, a 100~101 ohm, 1/4~1/2 watt, +/- 5%, resistance would probably work best to fairly balance the circuit.

Then, with the right software on both ends, one could do Apple Disk Transfers just as fast or faster than with an SSC/RS232 rig. Although, I did read that this all might be limited to 19 K-baud, because of the maximum speed of reading from and writing to floppy disks. But, with write verification, this might be increased or decreased in speed, depending on the media used (e.g., 5.25" floppies, 3.5" floppies, or Hard Disks).

What do you all think? Can it be done? And, Why or Why not?

James Davis

[Michael J. Mahon]

Post by James Davis
I get the impression, from reading the reverie in "What did an original
Apple II sell for?" that it may be possible to use the Apple II Cassette
port to do Disk Transfers to/from other PCs at a much higher rate than
what is currently possible with ADT, if one reduces the resistance of the
Cassette-Output resistor (R19 on an Apple II/II+ and R6 on an Apple IIe/Enhanced IIe).
Is this so?
And, is it just one way (on the output) or will it work both ways?
And, only with Apple II's and/or Mac's?
Or, will it work between Windows PC's and Apple II's, also?
And, at what (much higer) rate?

Changing the output level of the cassette port to line level from
microphone level has nothing to do with transfer speed--it's just a
convenience for those who do not have easy-to-use microphone inputs.

The highest reliable rates have been reported by datajerk (Egan), and are,
I believe, accurate.

Post by James Davis
Also, could it be used as I/O into/out-of an RS232 TO USB adapter/converter?
Or, is this idea overkill and unnecessary?

It's unnecessary, since the annunciators and pushbutton inputs have been
used for TTL-level RS-232 since the earliest days of the Apple II.

Post by James Davis
I calculated that a resistance of 100.84 ohms in parallel with the 12
K-ohm Cassette-Output resistor would bring the total resistance down to
100 ohms, the same as the resistance to ground on the bottom side of the
cassette output circuit, thus balancing the signal halfway between zero
and five volts (0v~5v) DC. So, a 100~101 ohm, 1/4~1/2 watt, +/- 5%,
resistance would probably work best to fairly balance the circuit.

Since audio signals are universally AC-coupled, DC balance is irrelevant.

Post by James Davis
Then, with the right software on both ends, one could do Apple Disk
Transfers just as fast or faster than with an SSC/RS232 rig. Although, I
did read that this all might be limited to 19 K-baud, because of the
maximum speed of reading from and writing to floppy disks. But, with
write verification, this might be increased or decreased in speed,
depending on the media used (e.g., 5.25" floppies, 3.5" floppies, or Hard Disks).
What do you all think? Can it be done? And, Why or Why not?

With an annunciator and a pushbutton input, bit-banging delivers a bit
every 8 cycles, or about 127k baud. With "framing" overhead, 117kbps is
attained in NadaNet.

The "toggling" behavior of the cassette output port complicates the sending
code somewhat, but something similar should be possible (once the high or
low state of the output is determined).

[James Davis]

Post by Michael J. Mahon
Changing the output level of the cassette port to line level from
microphone level has nothing to do with transfer speed--it's just a
convenience for those who do not have easy-to-use microphone inputs.
The highest reliable rates have been reported by datajerk (Egan), and are,
I believe, accurate.

Do you have a link for Egan's report?

Post by Michael J. Mahon
Since audio signals are universally AC-coupled, DC balance is irrelevant.

I don't understand. Why can't they be used digitally? Aren't the Cassette ports really digital on Apple II's?

Post by Michael J. Mahon
With an annunciator and a pushbutton input, bit-banging delivers a bit
every 8 cycles, or about 127k baud. With "framing" overhead, 117kbps is
attained in NadaNet.

I don't understand how NadaNet works. It's way over my head. Are you saying 127k baud--and with "framing" overhead, 117kbps--is obtainable using the game port, but not the cassette port?

Post by Michael J. Mahon
The "toggling" behavior of the cassette output port complicates the sending
code somewhat, but something similar should be possible (once the high or
low state of the output is determined).

I don't understand. Isn't "toggling" behavior digital behavior?

Why can't the Cassette I/O ports be used digitally? They don't always have to go to Audio jacks on other computers, or do they?

Really, I just want to know if ADT can be sped up using the Cassette I/O ports instead of the Game port or an SSC/RS232 connection, and if so, how? It would be nice if ADT via audio cables didn't take approximately 15~20 minutes for one 140KB diskette/image, but if they can be used digitally between Apple II's, like Jorge implies, then why couldn't they be used in a manner similar to, but instead of, the game port to communicate digitally?

[Michael 'AppleWin Debugger Dev']

Post by James Davis
Really, I just want to know if ADT can be sped up using the Cassette I/O ports instead of the Game port or an SSC/RS232 connection, and if so, how? It would be nice if ADT via audio cables didn't take approximately 15~20 minutes for one 140KB diskette/image,

Whoa, 15 minutes! No wonder you are asking for a speed up. That's a horrible wait time.

Has anyone played with "channel bonding"?
i.e. Sending data _simultaneously_ on both the RS232 _and_ Cassette port? Is the 6502 fast enough to capture both?

I know you asked for a "poor man's ADT" but is there a reason why you can't use a dedicated serial port ? That's what it was designed for. :-)

i.e. Transferring a DSK from my MBP (USB to 9-pin serial) to my //c takes about 1 to 2 minutes IIRC.

Which Apple 2 model(s) are you using BTW?

Post by James Davis
Could it be used as I/O into/out-of an RS232 TO USB adapter/converter?

Might as well just go the dedicated RS232 route at this point. An USB to RS232 adapter is pretty cheap. I bought one from Retro IIRC for $20.

http://retrofloppy.com/products.html#USBMAC

[James Davis]

Post by Michael 'AppleWin Debugger Dev'
Whoa, 15 minutes! No wonder you are asking for a speed up. That's a horrible wait time.

I haven't actually done it. I just read it somewhere. Someone said it takes 17 minutes. Probably here on CSA2, but if not, somewhere else online.

Post by Michael 'AppleWin Debugger Dev'
I know you asked for a "poor man's ADT" but is there a reason why you can't use a dedicated serial port ? That's what it was designed for. :-)

1. All my slots are full.
2. I don't have, nor do I want to spend money on an SSC; nor, any more money on Apple II stuff.

Post by Michael 'AppleWin Debugger Dev'
Which Apple 2 model(s) are you using BTW?

I have an enhanced IIe. (And a spare for parts if I ever need them.--NEVER WILL!)

Also, checkout "Apple II stuff I have for sale": https://groups.google.com/forum/#!topic/comp.sys.apple2.marketplace/sj2KiKimgOs

Post by Michael 'AppleWin Debugger Dev'
Might as well just go the dedicated RS232 route at this point.

See #2 above.

[Michael 'AppleWin Debugger Dev']

Ah, gotcha. Yeah full slots is a good motivator. :-)

[David Schmidt]

Post by James Davis

Post by Michael 'AppleWin Debugger Dev'
Whoa, 15 minutes! No wonder you are asking for a speed up. That's a horrible wait time.

I haven't actually done it. I just read it somewhere. Someone said it takes 17 minutes. Probably here on CSA2, but if not, somewhere else online.

It depends very much on the data on disk. A disk mostly full of zeroes
will take tens of seconds because it compresses so well. A pathological
disk will take... a while.

[Egan Ford]

Post by Michael 'AppleWin Debugger Dev'

Post by James Davis
Really, I just want to know if ADT can be sped up using the Cassette I/O ports instead of the Game port or an SSC/RS232 connection, and if so, how? It would be nice if ADT via audio cables didn't take approximately 15~20 minutes for one 140KB diskette/image,

Whoa, 15 minutes! No wonder you are asking for a speed up. That's a horrible wait time.

Try c2t (https://github.com/datajerk/c2t), the average time to write a
disk image via the cassette port is about 2.5 minutes (based on ~1500
games from virtualapple.org; see
https://github.com/datajerk/c2t/raw/master/article/article.pdf for details).

You cannot backup a disk however with c2t, it is just for writing disks.

[Michael J. Mahon]

This post might be inappropriate. Click to display it.

[Jorge]

Post by Michael J. Mahon
Check out Egan Ford's work. It uses the FSK coding that the cassette input
was designed for, while pushing it to 9600bps--more than seven times faster
than the built-in LOAD speed, but almost 12 times slower than a Super
Serial Card at 115kbps.

Something I've discovered is that if you feed a perfectly square wave into the cassette input what you're going to sample @ $C060 is not going to be square wave.

When $c030 high bit is set that's going to be sensed as twenty something µs longer and if it's zero it's going to be those same 20 something µs shorter.

This may not matter much @ 1333 bps, but if you are trying to push things to the limit it may well be something important to know.

An image is worth a thousand words:
https://imgur.com/a/K2IeH

[Jorge]

Post by Jorge
When $c030 high bit is set that's going to be sensed as twenty something µs longer and if it's zero it's going to be those same 20 something µs shorter.

Uffff, clear as mud and has a typo. Let's try again...

If you feed a perfectly square wave into the cassette input and poll $c060, the half cycles in which bit 7 is set are going to be twenty something µs longer, and the half cycles in which bit 7 is not set 20 something µs shorter.

An image is worth a thousand words:
https://imgur.com/a/K2IeH

[Jorge]

Post by Jorge

Post by Michael J. Mahon
Check out Egan Ford's work. It uses the FSK coding that the cassette input
was designed for, while pushing it to 9600bps--more than seven times faster
than the built-in LOAD speed, but almost 12 times slower than a Super
Serial Card at 115kbps.

When $c030 high bit is set that's going to be sensed as twenty something µs longer and if it's zero it's going to be those same 20 something µs shorter.
https://imgur.com/a/K2IeH

No comments? Nothing? Nobody? Not even a "you're talking complete bollocks!" ???

[Michael J. Mahon]

Post by Jorge

Post by Jorge

Post by Michael J. Mahon
Check out Egan Ford's work. It uses the FSK coding that the cassette input
was designed for, while pushing it to 9600bps--more than seven times faster
than the built-in LOAD speed, but almost 12 times slower than a Super
Serial Card at 115kbps.

Something I've discovered is that if you feed a perfectly square wave
to be square wave.
When $c030 high bit is set that's going to be sensed as twenty something
µs longer and if it's zero it's going to be those same 20 something µs shorter.
things to the limit it may well be something important to know.
https://imgur.com/a/K2IeH

No comments? Nothing? Nobody? Not even a "you're talking complete bollocks!" ???

Ok! ;-)

I'm not surprised that there's some asymmetry, since the circuit is
capacitively coupled. I'd also expect the asymmetry to change with signal
amplitude.

[Anthony Ortiz]

I think it's time someone developed an accelerator for the apple ii cassette port by golly; if we can send men to the moon...

[Michael J. Mahon]

Post by Anthony Ortiz
I think it's time someone developed an accelerator for the apple ii
cassette port by golly; if we can send men to the moon...

I'm sure we can do better. The trick will be keeping the signal balanced in
terms of positive and negative duty cycle, since it's AC-coupled and we
don't want the zero crossings to drift.

It would be a lot better if it were used as a bidirectional link, so error
recovery would be possible without ridiculous overhead.

[Ralf Kiefer]

Post by Anthony Ortiz
I think it's time someone developed an accelerator for the apple ii
cassette port by golly; if we can send men to the moon...

Your solution is avaible since years :-) Apple High Speed SCSI card
and a DAT recorder.

SCNR, Ralf

[Michael J. Mahon]

Post by Ralf Kiefer

Post by Anthony Ortiz
I think it's time someone developed an accelerator for the apple ii
cassette port by golly; if we can send men to the moon...

Your solution is avaible since years :-) Apple High Speed SCSI card
and a DAT recorder.
SCNR, Ralf

Now *there's* an expensive, obsolete solution! ;-)

[Jorge]

Post by Michael J. Mahon

Post by Jorge
No comments? Nothing? Nobody? Not even a "you're talking complete bollocks!" ???

Ok! ;-)
I'm not surprised that there's some asymmetry, since the circuit is
capacitively coupled. I'd also expect the asymmetry to change with signal
amplitude.

Hi Mr. Mahon,

I don't think the delay changes much with amplitude, once the opamp sees a signal of enough amplitude it will go straight into saturation. And for the 741 it takes twice as long to go from -5 to +5 (sensed as a 1) than it takes to go from +5 to 0 (sensed as a 0). Thus the delay.

I think that the trick to achieve hi speed *reliably* is 1st) to try to avoid DC bias in the input signal and 2nd) to know about these delays the 741 introduces.

I'm writing a cool "cassette-scope" program to see exactly in HGR the cassette input, it samples to the stack in an LDA $c060 PHA unrolled loop (1 sample every 7 cycles), I will post it here or in github asap. Is there a faster way to sample? If so please let me know!

Cheers,

[Michael J. Mahon]

Post by Jorge

Post by Michael J. Mahon

Post by Jorge
No comments? Nothing? Nobody? Not even a "you're talking complete bollocks!" ???

Ok! ;-)
I'm not surprised that there's some asymmetry, since the circuit is
capacitively coupled. I'd also expect the asymmetry to change with signal
amplitude.

Hi Mr. Mahon,
I don't think the delay changes much with amplitude, once the opamp sees
a signal of enough amplitude it will go straight into saturation. And for
the 741 it takes twice as long to go from -5 to +5 (sensed as a 1) than
it takes to go from +5 to 0 (sensed as a 0). Thus the delay.
I think that the trick to achieve hi speed *reliably* is 1st) to try to
avoid DC bias in the input signal and 2nd) to know about these delays the 741 introduces.
I'm writing a cool "cassette-scope" program to see exactly in HGR the
cassette input, it samples to the stack in an LDA $c060 PHA unrolled loop
(1 sample every 7 cycles), I will post it here or in github asap. Is
there a faster way to sample? If so please let me know!
Cheers,

I agree--saturation is saturation! But there may be a DC level shift
depending on the input current when overdriven, but, of course, this is not
an issue for square wave input.

The bigger issue is that there is no way to predict the "polarity" of the
signal, so Egan's short cycles could incur the "stretching" on either
half-cycle.

That suggests that a lead-in square wave should be used to determine which
half-cycle is stretched, and the decoder should adapt to the measured
polarity.

[Jorge]

Post by Michael J. Mahon
I agree--saturation is saturation! But there may be a DC level shift
depending on the input current when overdriven, but, of course, this is not
an issue for square wave input.

Short pulses coming after long ones tend to disappear/shrink because long (enough) pulses produce quite a DC shift.

Post by Michael J. Mahon
The bigger issue is that there is no way to predict the "polarity" of the
signal, so Egan's short cycles could incur the "stretching" on either
half-cycle.

The cassette out you can only toggle it and you never know, but the cassette input is not like that.

You can detect reversed polarity. Just send for example HI pulses and sample that and there you go. If you sense them as a LO you know the signal is inverted.

He could even correct the audio on the web browser side by fabricating it on the fly in javascript instead of feeding always the same (prebuilt) one.

Try the cassette-scope!

[Michael J. Mahon]

Post by Jorge

Post by Michael J. Mahon
I agree--saturation is saturation! But there may be a DC level shift
depending on the input current when overdriven, but, of course, this is not
an issue for square wave input.

Short pulses coming after long ones tend to disappear/shrink because long
(enough) pulses produce quite a DC shift.

Post by Michael J. Mahon
The bigger issue is that there is no way to predict the "polarity" of the
signal, so Egan's short cycles could incur the "stretching" on either
half-cycle.

The cassette out you can only toggle it and you never know, but the
cassette input is not like that.
You can detect reversed polarity. Just send for example HI pulses and
sample that and there you go. If you sense them as a LO you know the signal is inverted.
He could even correct the audio on the web browser side by fabricating it
on the fly in javascript instead of feeding always the same (prebuilt) one.
Try the cassette-scope!

Roger the asymmetric duty cycle issue (which is why Woz's coding scheme was
based on symmetric FSK).

The problem is that any audio channel cannot be trusted to preserve
"polarity" because the ear is insensitive to it. Even if the cassette
output port were polarity deterministic (like an annunciator), after the
signal is recorded and played back, there are no guarantees.

That's why it's best to incorporate a test signal prelude to allow
experimental determination of polarity or, more generally, to allow the
decoding machine to adapt to any asymmetry.

Until now, I had assumed symmetry, and Woz's coding is robust enough to be
insensitive to it!
Only when we begin to push the limits does the asymmetric opamp response
become significant.

[Jorge]

Post by Michael J. Mahon
Roger the asymmetric duty cycle issue (which is why Woz's coding scheme was
based on symmetric FSK).
The problem is that any audio channel cannot be trusted to preserve
"polarity" because the ear is insensitive to it. Even if the cassette
output port were polarity deterministic (like an annunciator), after the
signal is recorded and played back, there are no guarantees.
That's why it's best to incorporate a test signal prelude to allow
experimental determination of polarity or, more generally, to allow the
decoding machine to adapt to any asymmetry.
Until now, I had assumed symmetry, and Woz's coding is robust enough to be
insensitive to it!
Only when we begin to push the limits does the asymmetric opamp response
become significant.

Yep!

Here is a handy synthesizer I've made: apple2.duckdns.org/synth/

In the sampler:
H means max +amplitude
h means half max +amplitude
0 means zero
l means half max -amplitude
L means max -amplitude

That + the CASSETTE-SCOPE => hours of fun :-)

[barrym95838]

Post by Jorge

Post by Jorge
https://imgur.com/a/K2IeH

No comments? Nothing? Nobody? Not even a "you're talking complete bollocks!" ???
--
Jorge.

If you change that STA $C020 to an LDA $C020, does the scope pattern change at all?

Mike B.

[Michael J. Mahon]

Post by barrym95838

Post by Jorge

Post by Jorge
https://imgur.com/a/K2IeH

No comments? Nothing? Nobody? Not even a "you're talking complete bollocks!" ???
--
Jorge.

If you change that STA $C020 to an LDA $C020, does the scope pattern change at all?
Mike B.

It shouldn't. LDA abs and STA abs have exactly the same bus activity
(except for the R/W difference, which is irrelevant to the $C020 toggle).

[barrym95838]

Post by Michael J. Mahon

Post by barrym95838
If you change that STA $C020 to an LDA $C020, does the scope pattern change at all?
Mike B.

It shouldn't. LDA abs and STA abs have exactly the same bus activity
(except for the R/W difference, which is irrelevant to the $C020 toggle).
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Ah, true. I don't remember where I read it, but ISTR something about
a memory write operation doing a read immediately before writing, but
it appears that my own biological memory is faulty. Can I change my
question from LDA $C020 to INC $C020?

Mike B.

[Michael J. Mahon]

Post by barrym95838

Post by Michael J. Mahon

Post by barrym95838
If you change that STA $C020 to an LDA $C020, does the scope pattern change at all?
Mike B.

It shouldn't. LDA abs and STA abs have exactly the same bus activity
(except for the R/W difference, which is irrelevant to the $C020 toggle).
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Ah, true. I don't remember where I read it, but ISTR something about
a memory write operation doing a read immediately before writing, but
it appears that my own biological memory is faulty. Can I change my
question from LDA $C020 to INC $C020?
Mike B.

An indexed STA would have behaved as you thought, generating a single one
microsecond pulse at twice the frequency of the plain LDA/STA.

INC abs performs three accesses to the toggle, one microsecond apart. So it
inserts a one microsecond pulse two microseconds before each sustained
inversion.

Given the apparent response time, the short pulses are likely to appear as
"runts".

[Michael 'AppleWin Debugger Dev']

Post by Jorge

Post by Jorge
When $c030 high bit is set that's going to be sensed as twenty something µs longer and if it's zero it's going to be those same 20 something µs shorter.
https://imgur.com/a/K2IeH

No comments? Nothing? Nobody? Not even a "you're talking complete bollocks!" ???

Hold onto your hat :-) Some of us don't read this newsgroup everyday.

First, thanks for the oscilloscope pic!

As a strictly software guy I have a few questions:

- What hardware/software are you using for your oscilloscope.

- Precisely where are you making the physical connections to capture this on a 'scope ?

Thanks.

[Jorge]

Post by Michael 'AppleWin Debugger Dev'

Post by Jorge

Post by Jorge
When $c030 high bit is set that's going to be sensed as twenty something µs longer and if it's zero it's going to be those same 20 something µs shorter.
https://imgur.com/a/K2IeH

No comments? Nothing? Nobody? Not even a "you're talking complete bollocks!" ???

Hold onto your hat :-) Some of us don't read this newsgroup everyday.
First, thanks for the oscilloscope pic!
- What hardware/software are you using for your oscilloscope.
- Precisely where are you making the physical connections to capture this on a 'scope ?
Thanks.

Hi Michael "ADD",

I'm using an Apple II+ RFI with the cassette out connected to the cassette in and R19 shorted. The exact signals I'm peeking at are there in the footnotes of the pictures, here:

https://imgur.com/a/K2IeH

It is important to understand this: (Egan Ford, do you hear me?) : any pulses you sense with $c060 high bit set are going to appear to be ~20µs longer AND when low 20 µs shorter. IOW: feed a square wave and you won't sense it as square. Measure the pulses and on average HIs will be 20µs longer than LOs.

The reason is the way the 741 is connected to H14 (II/II+), and that it's working saturated as if it were a comparator, which is a no-no for opamps: opamps work best in the linear region.

Cheers,

[Egan Ford]

Post by Michael J. Mahon
Check out Egan Ford's work. It uses the FSK coding that the cassette input
was designed for, while pushing it to 9600bps--more than seven times faster
than the built-in LOAD speed, but almost 12 times slower than a Super
Serial Card at 115kbps.

Thanks for the mention.

Every attempt I have made to break the 9600 barrier has yielded less
than universal results--too much variability of Apple IIs and their
cassette ports.

And 9600 is not perfect.

My first attempt at 9600 (with your help) produced a solution that could
be played from any player, but only ~50% of NTSC Apple IIs could
process. My second attempt works universally across all NTSC Apple IIs
and emulators (first attempt did not work with emulators, something I
need for faster development), but only modern players can play the
half-cycle scheme. So far is appears this only impacts certain laptops
(Apple and non-Apple) from 2012 based on only 3 data points.

The most stable rate I have achieved is 8000 bps. This works with all
players and NTSC Apple IIs. And it is really not that much faster than
9600 when writing disks. Using Zork I as an example, at 8000 BPS the
total audio time is 2:51, and at 9600 BPS it is 2:38. The actual time
spent sending data @ 9600 is 1:25. The rest of the time is spent
decompressing (LZ77-Huffman) and writing to disk. c2t does not have the
higher speed disk code that ADTPro does. I suppose if that were
included the gap between 8000 and 9600 would be greater. Perhaps someday.

[Egan Ford]

Post by James Davis

Post by Michael J. Mahon
Changing the output level of the cassette port to line level from
microphone level has nothing to do with transfer speed--it's just a
convenience for those who do not have easy-to-use microphone inputs.
The highest reliable rates have been reported by datajerk (Egan), and are,
I believe, accurate.

Do you have a link for Egan's report?

https://github.com/datajerk/c2t/raw/master/article/article.pdf

[James Davis]

I should have said David (Schmidt) instead of Oliver (Schmidt) in the greeting above, or maybe I should just add David (Schmidt) to it, since both may be interested in this thread.

James Davis

[James Davis]

Hi All,

Thanks Michael P. (of AppleWin fame), for your contribution.
Thanks Michael J. Mahon, for the explanations.
Thanks Jorge, for the link.
Thanks Egan, for your contribution.

Turns out, I had already downloaded Egan's Article.pdf using the link in the other thread. I have not read all of it yet.

Egan,

Can your C2T be used between any Apple II and a Windows PC, connected with audio cables--Like ADT does, but faster--to do Apple Disk Image Transfers?

If not, do you think David Schmidt could use it to improve his ADT software?

If you guys could collaborate and make a better audio ADT, then all one would have to buy is a pair of audio cables.

Yours truly,

James Davis

P.S. Just because I am thanking everyone, does not mean the discussion is over.

[Jorge]

Hi James,

This is truly totally amazing: http://asciiexpress.net/diskserver/

That site above does what you want!

[Egan Ford]

Post by James Davis
Can your C2T be used between any Apple II and a Windows PC, connected with audio cables--Like ADT does, but faster--to do Apple Disk Image Transfers?

Yes, however only for writing disks, c2t does not support
reading/archiving disks, I use ADTPro for that.

Yes, it works with Windows (tested). There is a c2t-96h.exe binary on
the c2t github site you can download, just type:

c2t-96h diskname.dsk diskname.wav

Connect your audio cable, crank up the volume to max, insert disk, type
"LOAD", RETURN, then play the audio file.

Post by James Davis
If you guys could collaborate and make a better audio ADT, then all one would have to buy is a pair of audio cables.

Well for II+/IIe owners, yes. c2t is far from universal--I'm going to
guess it does not work for PAL machines at all or anything accelerated.
If the 6502 kHz is not 1023, then c2t will fail.

I wrote c2t because I wanted to know what a cassette port could do. It
later became my way to quickly test my (non-c2t) code on physical HW
without having to write a floppy or setup a 2nd system with a serial
port (I just use audio cable and phone).

Given CFA, A2Pi, Uthernet, etc... There seams to be a lot of options
out there for connectivity.

That all said, I'm open to any collaboration, time permitting. c2t and
all my other Apple stuff is 100% open source, and it can be used anyway
any see fit.

[David Schmidt]

https://knzl.de/poor-mans-adt/