Discussion:
Gentlemen, 14+ kbps !
(too old to reply)
Jorge
2017-10-02 08:51:15 UTC
Permalink
Reliably, over the cassette in port, on a II+. I've got it working right now in a loop in front of me: 4.5s per HGR image.

And it's remarkably insensitive to the volume, anything above 40..50% is good to go.

:-)
--
Jorge.
Michael J. Mahon
2017-10-02 15:48:08 UTC
Permalink
Post by Jorge
Reliably, over the cassette in port, on a II+. I've got it working right
now in a loop in front of me: 4.5s per HGR image.
And it's remarkably insensitive to the volume, anything above 40..50% is good to go.
:-)
Excellent, Jorge!

How did you do it? (Code?)
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Jorge
2017-10-02 17:06:05 UTC
Permalink
Post by Michael J. Mahon
Excellent, Jorge!
How did you do it? (Code?)
In order to keep the DC bias under control, the encoding I've used is Manchester (see https://en.wikipedia.org/wiki/Manchester_code ), and also because it's very easy to decode quickly on the fly. I'm setting up a demo page. Will post the url asap. But in short, the trick was... to make the HI pulses 1 sample less than the LO pulses: LOs are 2 or 4 samples (*), but HIs are 1 or 3 (see the Manchester waveform picture @ the wikipedia). That's because of the 741 delay we've been talking about before, remember? You'll soon be able to see exactly what I mean in the demo page (hopefully, tomorrow). More so if you prepare and have an oscilloscope with the probes peeking at H14-4 (on a II/II+) and H14-7 (/CS). Oh, and it detects reversed polarity too.

(*) A sample lasts either 1/44100 or 1/48000 depending on the device the browser is running on.
--
Jorge.
Michael J. Mahon
2017-10-03 06:59:48 UTC
Permalink
Post by Jorge
Post by Michael J. Mahon
Excellent, Jorge!
How did you do it? (Code?)
In order to keep the DC bias under control, the encoding I've used is
Manchester (see https://en.wikipedia.org/wiki/Manchester_code ), and also
because it's very easy to decode quickly on the fly. I'm setting up a
demo page. Will post the url asap. But in short, the trick was... to make
the HI pulses 1 sample less than the LO pulses: LOs are 2 or 4 samples
wikipedia). That's because of the 741 delay we've been talking about
before, remember? You'll soon be able to see exactly what I mean in the
demo page (hopefully, tomorrow). More so if you prepare and have an
oscilloscope with the probes peeking at H14-4 (on a II/II+) and H14-7
(/CS). Oh, and it detects reversed polarity too.
(*) A sample lasts either 1/44100 or 1/48000 depending on the device the
browser is running on.
Very nice!

I'll have to think about this some more... ;-)
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Jorge
2017-10-03 09:19:25 UTC
Permalink
Post by Michael J. Mahon
Post by Jorge
In order to keep the DC bias under control, the encoding I've used is
Manchester (see https://en.wikipedia.org/wiki/Manchester_code ), and also
because it's very easy to decode quickly on the fly. I'm setting up a
demo page. Will post the url asap. But in short, the trick was... to make
the HI pulses 1 sample less than the LO pulses: LOs are 2 or 4 samples
wikipedia). That's because of the 741 delay we've been talking about
before, remember? You'll soon be able to see exactly what I mean in the
demo page (hopefully, tomorrow). More so if you prepare and have an
oscilloscope with the probes peeking at H14-4 (on a II/II+) and H14-7
(/CS). Oh, and it detects reversed polarity too.
(*) A sample lasts either 1/44100 or 1/48000 depending on the device the
browser is running on.
Very nice!
I'll have to think about this some more... ;-)
Yes please, do. As we say here, 4 eyes see more than two.
--
Jorge.
_█ͧͯ_͋█ͣ͂_͂_͆_͑█̽͆__ͧ̓█͆█ͥ̄_̽
2017-10-06 12:33:55 UTC
Permalink
On Monday, October 2, 2017 at 7:06:07 PM UTC+2, _█ͧͯ_͋█ͣ͂_͂_͆_͑█̽͆__ͧ̓█͆█ͥ̄_̽ wrote:
You'll soon be able to see exactly what I mean in the demo page (hopefully, tomorrow).

Gentleman,

Today is tomorrow!

apple2.duckdns.org/turbodemo/

Feel free to ask, steal, copy, and/or use in your projects, e.g. ADT, ADTPro or datajerk's disk server or whatever. And for Michael "MJM" to tinker for the joy of tinkering. I only ask for credit where credit is due: if you use it state clearly you stole the idea from me :-)

Skookum as frig!
--
Jorge.
David Schmidt
2017-10-06 14:04:29 UTC
Permalink
Post by Jorge
You'll soon be able to see exactly what I mean in the demo page (hopefully, tomorrow).
Gentleman,
Today is tomorrow!
apple2.duckdns.org/turbodemo/
Very nice. Maybe I was making assumptions, but... is it not
bi-directional? Is there code to send at that rate as well as receive?
Post by Jorge
Feel free to ask, steal, copy, and/or use in your projects, e.g. ADT, ADTPro or datajerk's disk server or whatever.
One constraint ADTPro has: it needs to be able to escape out of a
transfer during a send or a receive. So built into my re-engineered
audio routines is a poll for the escape key. So I'd either need to
build that into this capability too or use short enough bursts to
approximate the same thing.
_█ͧͯ_͋█ͣ͂_͂_͆_͑█̽͆__ͧ̓█͆█ͥ̄_̽
2017-10-06 14:20:12 UTC
Permalink
Post by David Schmidt
Post by Jorge
You'll soon be able to see exactly what I mean in the demo page (hopefully, tomorrow).
Gentleman,
Today is tomorrow!
apple2.duckdns.org/turbodemo/
Very nice. Maybe I was making assumptions, but... is it not
bi-directional? Is there code to send at that rate as well as receive?
I have not written the driver to send from the Apple II, but I think it's doable, why not?
Post by David Schmidt
Post by Jorge
Feel free to ask, steal, copy, and/or use in your projects, e.g. ADT, ADTPro or datajerk's disk server or whatever.
One constraint ADTPro has: it needs to be able to escape out of a
transfer during a send or a receive. So built into my re-engineered
audio routines is a poll for the escape key. So I'd either need to
build that into this capability too or use short enough bursts to
approximate the same thing.
Try pressing any key... or ESC ! :-)
--
Jorge.
David Schmidt
2017-10-06 14:23:52 UTC
Permalink
Post by _█ͧͯ_͋█ͣ͂_͂_͆_͑█̽͆__ͧ̓█͆█ͥ̄_̽
Post by David Schmidt
Post by Jorge
You'll soon be able to see exactly what I mean in the demo page (hopefully, tomorrow).
Gentleman,
Today is tomorrow!
apple2.duckdns.org/turbodemo/
Very nice. Maybe I was making assumptions, but... is it not
bi-directional? Is there code to send at that rate as well as receive?
I have not written the driver to send from the Apple II, but I think it's doable, why not?
Why not indeed.
Post by _█ͧͯ_͋█ͣ͂_͂_͆_͑█̽͆__ͧ̓█͆█ͥ̄_̽
Post by David Schmidt
Post by Jorge
Feel free to ask, steal, copy, and/or use in your projects, e.g. ADT, ADTPro or datajerk's disk server or whatever.
One constraint ADTPro has: it needs to be able to escape out of a
transfer during a send or a receive. So built into my re-engineered
audio routines is a poll for the escape key. So I'd either need to
build that into this capability too or use short enough bursts to
approximate the same thing.
Try pressing any key... or ESC ! :-)
Missed that - sounds good.
_█ͧͯ_͋█ͣ͂_͂_͆_͑█̽͆__ͧ̓█͆█ͥ̄_̽
2017-10-06 14:39:09 UTC
Permalink
Post by David Schmidt
Post by _█ͧͯ_͋█ͣ͂_͂_͆_͑█̽͆__ͧ̓█͆█ͥ̄_̽
I have not written the driver to send from the Apple II, but I think it's doable, why not?
Why not indeed.
Ahh, ok, I see. I've never used ADT to transfer diaks from the Apple II to the Mac, only from the Mac to the II. But don't worry that's easy. And the .js to decode it in the web page is easy too. So you could make ADT a web page ! That's even more cross-platform than java!
--
Jorge.
David Schmidt
2017-10-06 15:06:48 UTC
Permalink
Post by _█ͧͯ_͋█ͣ͂_͂_͆_͑█̽͆__ͧ̓█͆█ͥ̄_̽
Post by David Schmidt
Post by _█ͧͯ_͋█ͣ͂_͂_͆_͑█̽͆__ͧ̓█͆█ͥ̄_̽
I have not written the driver to send from the Apple II, but I think it's doable, why not?
Why not indeed.
Ahh, ok, I see. I've never used ADT to transfer diaks from the Apple II to the Mac, only from the Mac to the II. But don't worry that's easy. And the .js to decode it in the web page is easy too. So you could make ADT a web page ! That's even more cross-platform than java!
Holy crapmonkeys - we could host a DB in the cloud, and have r/w access
to a cloudy Asimov. With just disk images, the total data footprint
would be minimal. But only for Apples with audio ports. :-) It's
always something...
_█ͧͯ_͋█ͣ͂_͂_͆_͑█̽͆__ͧ̓█͆█ͥ̄_̽
2017-10-06 15:33:08 UTC
Permalink
Post by David Schmidt
But only for Apples with audio ports. :-) It's
always something...
Why only for Apples with audio ports? The audio out port can drive a serial input perfectly, you just have to tweak somewhat the audio signal, but it's quite easy.
--
Jorge.
James Davis
2017-10-06 19:11:18 UTC
Permalink
Post by Jorge
You'll soon be able to see exactly what I mean in the demo page (hopefully, tomorrow).
Gentleman,
Today is tomorrow!
apple2.duckdns.org/turbodemo/
Feel free to ask, steal, copy, and/or use in your projects, e.g. ADT, ADTPro or datajerk's disk server or whatever. And for Michael "MJM" to tinker for the joy of tinkering. I only ask for credit where credit is due: if you use it state clearly you stole the idea from me :-)
Skookum as frig!
--
Jorge.
I don't get it! What are we supposed to do with your webpage? It does nothing in my browser, Microsoft Internet Explorer.
_█ͧͯ_͋█ͣ͂_͂_͆_͑█̽͆__ͧ̓█͆█ͥ̄_̽
2017-10-06 19:18:41 UTC
Permalink
Post by James Davis
I don't get it! What are we supposed to do with your webpage? It does nothing in my browser, Microsoft Internet Explorer.
Use a real browser :-) Chrome or FireFox or Brave ! You need to have javascript enabled, too...
--
Jorge.
Anthony Ortiz
2017-10-06 19:27:58 UTC
Permalink
And make sure your anti-virus/malware and firewalls are disabled for the full experience!
̜̥̣̲ͭͥͩ̑J̼̙͙͋ͮ̈̿ͅͅͅO͖̖̳͐Ṛ̘̟͇̦̟ͅG̱͔͔̣͍̜͓̤͗ͨ̾͒̿ͧ̑͊Ḙ
2017-10-06 19:46:25 UTC
Permalink
Post by Anthony Ortiz
And make sure your anti-virus/malware and firewalls are disabled for the full experience!
Yeahhh ;-P
ǝƃɹoſ
2017-10-07 19:09:53 UTC
Permalink
Gentlemen,
Today is tomorrow!
apple2.duckdns.org/turbodemo/
The button "LOOP 4 EVER" now works, it randomly sends images in a loop, and reports the transfer speed:

Sample rate is 48000 sps
4 sent. Average xfer rate 1.8 kbyte/s (14786 bps)
--
Jorge.
ǝƃɹoſ
2017-10-08 11:08:33 UTC
Permalink
Post by ǝƃɹoſ
Gentlemen,
Today is tomorrow!
apple2.duckdns.org/turbodemo/
Sample rate is 48000 sps
4 sent. Average xfer rate 1.8 kbyte/s (14786 bps)
Now it works in both directions, the web page listens to the Apple II cassette output (you have to plug an other cable of course) and decodes that signal live on the fly. So if you press 1 on the Apple II the web page sends the 1st picture, 2 the 2nd etcetera.
--
Jorge.
Jorge
2017-10-10 08:19:32 UTC
Permalink
Post by ǝƃɹoſ
Now it works in both directions, the web page listens to the Apple II cassette output (you have to plug an other cable of course) and decodes that signal live on the fly. So if you press 1 on the Apple II the web page sends the 1st picture, 2 the 2nd etcetera.
The Apple II, one of first ever PCs in the world, can sample its cassette port every 6-7µs, but most modern PCs 40 years later can only do it every 1/44100/1e-6 ~= 22.68 µs, ¡toma ya!

=> I expect the bps to be proportionally slower in the Apple II -> Mac/PC direction.

On the plus side, now you can write the decoder in a high level language such as .js ( hats off to Brendan Eich ) and expect it to work flawlessly in realtime. OMG, there's an abyss between that and 6502 assembly. An abyss in terms of execution speed, plus an other abyss in ease of programming. Well worth the wait it has been, I would say.

Remember when every PC there was was incompatible with every other? Remember when even ones of the same brand were incompatible with each other? Today you can run the same .js on every computer in the world and it works. Amazing! Sooner or later it's going to be bye bye to OSs and vendor lock-in.

Remember when you used to drive somewhere else to meet, every so often, armed with a couple of boxes of blank mini floppies, to pirat^W share new software? The "user groups"... LOL. Now ~ everything is a click away in a matter of milli seconds. God bless the internet.

But I digress.
--
Jorge.
Egan Ford
2017-10-04 18:27:08 UTC
Permalink
Post by Michael J. Mahon
Post by Jorge
Reliably, over the cassette in port, on a II+. I've got it working right
now in a loop in front of me: 4.5s per HGR image.
And it's remarkably insensitive to the volume, anything above 40..50% is good to go.
:-)
Excellent, Jorge!
How did you do it? (Code?)
+1. Look forward to the code.
David Schmidt
2017-10-04 18:54:01 UTC
Permalink
Post by Michael J. Mahon
Post by Jorge
Reliably, over the cassette in port, on a II+. I've got it working right
now in a loop in front of me: 4.5s per HGR image.
And it's remarkably insensitive to the volume, anything above 40..50% is good to go.
:-)
Excellent, Jorge!
How did you do it? (Code?)
+1.  Look forward to the code.
+1. Waiting to steal <err> read the code.
Anthony Ortiz
2017-10-04 19:06:54 UTC
Permalink
Don't you whippersnappers have floppy drives that will run circles around your fancy schmancy pony-express-memory-invoking cassette interface? :P
James Davis
2017-10-04 19:20:47 UTC
Permalink
Post by Anthony Ortiz
Don't you whippersnappers have floppy drives that will run circles around your fancy schmancy pony-express-memory-invoking cassette interface? :P
I think they're looking for a way to speed up ADT via Audio.
.̣ͪJͭͮo̜̜̩͈͚͖̳͑͋̂r͕̝̤̹̈ͮ͌g̻̯̟͇̮̳̟͎ͪͨ̉̑e̘͒.̜͎̞̈
2017-10-04 19:16:27 UTC
Permalink
Post by David Schmidt
+1. Waiting to steal <err> read the code.
lol
Jorge
2017-10-02 17:31:51 UTC
Permalink
Post by Jorge
Reliably, over the cassette in port, on a II+. I've got it working right now in a loop in front of me: 4.5s per HGR image.
13569 bps @44100 sps
14769 bps @48000 sps

To be exact.
--
Jorge.
David Schmidt
2017-10-02 17:43:32 UTC
Permalink
Post by Jorge
Reliably, over the cassette in port, on a II+. I've got it working right now in a loop in front of me: 4.5s per HGR image.
What are the system constraints that would necessitate one rate vs. the
other?
Jorge
2017-10-02 18:01:46 UTC
Permalink
Post by David Schmidt
What are the system constraints that would necessitate one rate vs. the
other?
The decoder works perfectly well with the same audio played @ either 44100 or 48000, in one case it takes (slightly) longer than in the other, that's all.
Jorge
2017-10-03 09:33:07 UTC
Permalink
Most newer computers come with 82k or even 96k capable audio out devices. But given the slow response times of that 741 opamp I don't think it's going to be easy to squeeze much more from the cassette in port. But who knows? When a baud is just about 60µs, if you are able to shave say just 6µs it means ~2k bps more... which is a good thing!
--
Jorge.
Michael J. Mahon
2017-10-04 01:22:53 UTC
Permalink
Post by Jorge
Most newer computers come with 82k or even 96k capable audio out devices.
But given the slow response times of that 741 opamp I don't think it's
going to be easy to squeeze much more from the cassette in port. But who
knows? When a baud is just about 60µs, if you are able to shave say just
6µs it means ~2k bps more... which is a good thing!
Jorge, since the speed of the cassette input port is limited by the
unconventional usage of the 741, have you looked at its response to low
level square waves? If it is kept out of saturation, it should be
considerably faster.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Jorge
2017-10-04 09:12:55 UTC
Permalink
Post by Michael J. Mahon
Jorge, since the speed of the cassette input port is limited by the
unconventional usage of the 741, have you looked at its response to low
level square waves? If it is kept out of saturation, it should be
considerably faster.
I think that's very difficult (if not impossible) to do because the band in which the opamp is in the linear region is very narrow due to the high gain (84x IIANM), and also because due to the AC coupling the input signal the 741 sees is AC riding on a variable DC bias thus shifting up and down, most of the time out of that (very tiny) linear band.

Even if you could make that work (I don't think so), it would be extremely picky about the volume level which is not good at all.

I've got the demo almost ready... :-)
--
Jorge.
Michael J. Mahon
2017-10-04 16:28:24 UTC
Permalink
Post by Jorge
Post by Michael J. Mahon
Jorge, since the speed of the cassette input port is limited by the
unconventional usage of the 741, have you looked at its response to low
level square waves? If it is kept out of saturation, it should be
considerably faster.
I think that's very difficult (if not impossible) to do because the band
in which the opamp is in the linear region is very narrow due to the high
gain (84x IIANM), and also because due to the AC coupling the input
signal the 741 sees is AC riding on a variable DC bias thus shifting up
and down, most of the time out of that (very tiny) linear band.
Even if you could make that work (I don't think so), it would be
extremely picky about the volume level which is not good at all.
I've got the demo almost ready... :-)
The input to the 741 is a 2:1 attenuators, so the net gain is about 42. The
output is centered around 0 volts, so the negative swing is comparable to
the positive swing (quite unconventional for a digital input!). The digital
input would like, say, +4v for true, so an input drive at the cassette in
port would be about 100 millivolts for satisfactory operation in the linear
region. 120mv would drive the 741 to saturation and 80mv would be barely
sufficient, so level control within +/-20% is necessary, but achievable.

The time constant of the input circuit is about 2.4 milliseconds, so as
long as the input waveform is symmetrical around zero within about 500
microseconds, DC shift should be manageable.

Since you are set up with a 'scope for the experiment, try decreasing the
input level to the 100 millivolt level and see if the 741 output tracks the
input without any extra delay.

It may be that minimal external circuitry (a Schmitt trigger with an output
attenuator) would allow the data speed to increase significantly.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Michael J. Mahon
2017-10-04 17:32:30 UTC
Permalink
Post by Michael J. Mahon
Post by Jorge
Post by Michael J. Mahon
Jorge, since the speed of the cassette input port is limited by the
unconventional usage of the 741, have you looked at its response to low
level square waves? If it is kept out of saturation, it should be
considerably faster.
I think that's very difficult (if not impossible) to do because the band
in which the opamp is in the linear region is very narrow due to the high
gain (84x IIANM), and also because due to the AC coupling the input
signal the 741 sees is AC riding on a variable DC bias thus shifting up
and down, most of the time out of that (very tiny) linear band.
Even if you could make that work (I don't think so), it would be
extremely picky about the volume level which is not good at all.
I've got the demo almost ready... :-)
The input to the 741 is a 2:1 attenuators, so the net gain is about 42. The
output is centered around 0 volts, so the negative swing is comparable to
the positive swing (quite unconventional for a digital input!). The digital
input would like, say, +4v for true, so an input drive at the cassette in
port would be about 100 millivolts for satisfactory operation in the linear
region. 120mv would drive the 741 to saturation and 80mv would be barely
sufficient, so level control within +/-20% is necessary, but achievable.
The time constant of the input circuit is about 2.4 milliseconds, so as
long as the input waveform is symmetrical around zero within about 500
microseconds, DC shift should be manageable.
Since you are set up with a 'scope for the experiment, try decreasing the
input level to the 100 millivolt level and see if the 741 output tracks the
input without any extra delay.
It may be that minimal external circuitry (a Schmitt trigger with an output
attenuator) would allow the data speed to increase significantly.
Whoops...

Since the input is AC, and a 100mv positive excursion is needed, the
optimal input level would be 200mv peak-to-peak, not 100mv.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
.͖͖̦͎.̥̩ͯ͛͊.̦̲͉̄.̫̮ͮͅ.̽̃̽̓.̳͈͓.̂ͭͤ.͖ͅ.͎̪̍̓.͚͐̉ͤ
2017-10-04 19:35:04 UTC
Permalink
Post by Michael J. Mahon
Since you are set up with a 'scope for the experiment, try decreasing the
input level to the 100 millivolt level and see if the 741 output tracks the
input without any extra delay.
I will do, but tricky volume setting is a pain.
--
Jorge.
Michael J. Mahon
2017-10-04 21:33:35 UTC
Permalink
Post by .͖͖̦͎.̥̩ͯ͛͊.̦̲͉̄.̫̮ͮͅ.̽̃̽̓.̳͈͓.̂ͭͤ.͖ͅ.͎̪̍̓.͚͐̉ͤ
Post by Michael J. Mahon
Since you are set up with a 'scope for the experiment, try decreasing the
input level to the 100 millivolt level and see if the 741 output tracks the
input without any extra delay.
I will do, but tricky volume setting is a pain.
You could always throw in a 10:1 attenuator--say 10k to 1k, that should
make it pretty easy.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Bobbi
2017-10-04 21:51:50 UTC
Permalink
Mousetext in the username maybe?
Jorge
2017-10-11 18:43:45 UTC
Permalink
The input to the 741 is a 2:1 attenuator, so the net gain is about 42.
I'm looking now at the red book schematics and there's no divider there and the gain of the opamp is set to 19x ((220+12)/12)

The 1979 reference manual and the IIe schematics show a divider /2 followed by the opamp set to 84x gain.

Why on earth would anybody want to first halve a signal to then have to amplify it back twice as much?

One possible excuse would be to protect somewhat the 741 input with that new 12kΩ R in series.

But that additional R also doubles the high pass cutoff frequency, perhaps that's what they were after.

Who knows?
--
Jorge.
Jorge
2017-10-11 18:54:10 UTC
Permalink
Post by Jorge
But that additional R also doubles the high pass cutoff frequency
halves...
Michael J. Mahon
2017-10-11 21:10:50 UTC
Permalink
Post by Jorge
The input to the 741 is a 2:1 attenuator, so the net gain is about 42.
I'm looking now at the red book schematics and there's no divider there
and the gain of the opamp is set to 19x ((220+12)/12)
The 1979 reference manual and the IIe schematics show a divider /2
followed by the opamp set to 84x gain.
Why on earth would anybody want to first halve a signal to then have to
amplify it back twice as much?
One possible excuse would be to protect somewhat the 741 input with that
new 12kΩ R in series.
But that additional R also doubles the high pass cutoff frequency,
perhaps that's what they were after.
Who knows?
It's simply to cut the potential input level to provide some protection
from large signals, AC ground differences when plugging in, ESD, etc.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Jorge
2017-10-12 09:13:58 UTC
Permalink
Post by Michael J. Mahon
Post by Jorge
I'm looking now at the red book schematics and there's no divider there
and the gain of the opamp is set to 19x ((220+12)/12)
The 1979 reference manual and the IIe schematics show a divider /2
followed by the opamp set to 84x gain.
Why on earth would anybody want to first halve a signal to then have to
amplify it back twice as much?
One possible excuse would be to protect somewhat the 741 input with that
new 12kΩ R in series.
But that additional R also doubles the high pass cutoff frequency,
perhaps that's what they were after.
Who knows?
It's simply to cut the potential input level to provide some protection
from large signals, AC ground differences when plugging in, ESD, etc.
I'd have to check what the 741 delay is with 19x gain, in the older IIs.
--
Jorge.
Michael J. Mahon
2017-10-12 16:55:11 UTC
Permalink
Post by Jorge
Post by Michael J. Mahon
Post by Jorge
I'm looking now at the red book schematics and there's no divider there
and the gain of the opamp is set to 19x ((220+12)/12)
The 1979 reference manual and the IIe schematics show a divider /2
followed by the opamp set to 84x gain.
Why on earth would anybody want to first halve a signal to then have to
amplify it back twice as much?
One possible excuse would be to protect somewhat the 741 input with that
new 12kΩ R in series.
But that additional R also doubles the high pass cutoff frequency,
perhaps that's what they were after.
Who knows?
It's simply to cut the potential input level to provide some protection
from large signals, AC ground differences when plugging in, ESD, etc.
I'd have to check what the 741 delay is with 19x gain, in the older IIs.
Most likely, the input circuit was changed to improve both LOAD and
hardware (741) reliability.

Any change in frequency response would be negligible in this application.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Jorge
2017-10-12 18:11:18 UTC
Permalink
Post by Michael J. Mahon
Most likely, the input circuit was changed to improve both LOAD and
hardware (741) reliability.
The linear band in the older IIs with 19x gain is twice as much: 2*4/19 ~= .4v peak to peak. Perhaps they did not like that.
--
Jorge.
James Davis
2017-10-04 21:04:42 UTC
Permalink
On Monday, October 2, 2017 at 1:51:16 AM UTC-7, _█ͧͯ_͋█ͣ͂_͂_͆_͑█̽͆__ͧ̓█͆█ͥ̄_̽ wrote:

Hey Jorge,

All that crap around your name really messes up its display!--All kinds of black bars and weirdness.
Jorge
2017-10-11 09:12:01 UTC
Permalink
Post by Jorge
Reliably, over the cassette in port, on a II+. I've got it working right now in a loop in front of me: 4.5s per HGR image.
And it's remarkably insensitive to the volume, anything above 40..50% is good to go.
:-)
For the same price now it comes with an oscilloscope.

To see it click on "LISTEN". To freeze a frame/stop the scope click on it (on the scope "screen", not on the "LISTEN" button). To resume click again. The scope trigger mode is set to normal not auto, that means if there's no signal you won't see anything. It triggers on the rising edges of zero crossings.

http://apple2.duckdns.org/turbodemo
--
Jorge.
Jorge
2017-10-12 21:00:23 UTC
Permalink
The IP 50.196.28.193 should reload the page: you're using an old version of the turbodemo.
Jorge
2017-10-13 13:37:27 UTC
Permalink
75.170.79.245 : You should reload the page: you're using an old version of the turbodemo.
Jorge
2017-10-18 21:16:21 UTC
Permalink
Post by Jorge
Reliably, over the cassette in port, on a II+. I've got it working right now in a loop in front of me: 4.5s per HGR image.
And it's remarkably insensitive to the volume, anything above 40..50% is good to go.
:-)
The driver to send from the Apple II to another Apple II or to the web page, plus the .js decoder of the web page are working now, I will post the demo very soon: a ping pong of pictures between a II and a web browser or between two Apple IIs.

You just need two (mini) jack to jack cables and a 330Ω R to put in parallel with R19 (II/II+) or R6 (IIe) to rise the signal of the cassette out port from MIC level to line level.

This means that any web page can now talk AND listen to an Apple II @ 14+ kbps.
--
Jorge.
Egan Ford
2017-10-18 22:33:46 UTC
Permalink
Post by Jorge
Post by Jorge
Reliably, over the cassette in port, on a II+. I've got it working right now in a loop in front of me: 4.5s per HGR image.
And it's remarkably insensitive to the volume, anything above 40..50% is good to go.
:-)
The driver to send from the Apple II to another Apple II or to the web page, plus the .js decoder of the web page are working now, I will post the demo very soon: a ping pong of pictures between a II and a web browser or between two Apple IIs.
You just need two (mini) jack to jack cables and a 330Ω R to put in parallel with R19 (II/II+) or R6 (IIe) to rise the signal of the cassette out port from MIC level to line level.
Sweet. I looked into this before when I started my initial research in
2011 but there wasn't a seamless standard way for browser to record
audio (unsure if for privacy, or browsers makers just could not agree on
a standard).

Will this work with any browser? Any phone? And without prompting the
user?

Is there a way to rise MIC to Line level without modding the IIe?

Thanks.
r***@gmail.com
2017-10-19 02:19:47 UTC
Permalink
Egan alerted me to this thread. Completely unaware of Jorge's effort, at the same time I was working on a similar effort, and achieved 23kbps. See https://github.com/datajerk/c2t/issues/4#issuecomment-337772702 . I believe this is pushing the limit of what the poor 741 is physically capable of. One trick is that I'm using a band-limited approach to generating the signals, which has the nice property that it should be independent of the sample rate out (though, in fairness, I've only tested at 48kbps).

I'll also want to try out Jorge's approach when I get back to Recurse Center (which is where the IIe I'm using is).

Raph
Post by Egan Ford
Post by Jorge
Post by Jorge
Reliably, over the cassette in port, on a II+. I've got it working right now in a loop in front of me: 4.5s per HGR image.
And it's remarkably insensitive to the volume, anything above 40..50% is good to go.
:-)
The driver to send from the Apple II to another Apple II or to the web page, plus the .js decoder of the web page are working now, I will post the demo very soon: a ping pong of pictures between a II and a web browser or between two Apple IIs.
You just need two (mini) jack to jack cables and a 330Ω R to put in parallel with R19 (II/II+) or R6 (IIe) to rise the signal of the cassette out port from MIC level to line level.
Sweet. I looked into this before when I started my initial research in
2011 but there wasn't a seamless standard way for browser to record
audio (unsure if for privacy, or browsers makers just could not agree on
a standard).
Will this work with any browser? Any phone? And without prompting the
user?
Is there a way to rise MIC to Line level without modding the IIe?
Thanks.
Jorge
2017-10-19 04:35:24 UTC
Permalink
Post by r***@gmail.com
Egan alerted me to this thread. Completely unaware of Jorge's effort, at the same time I was working on a similar effort, and achieved 23kbps. See https://github.com/datajerk/c2t/issues/4#issuecomment-337772702 . I believe this is pushing the limit of what the poor 741 is physically capable of. One trick is that I'm using a band-limited approach to generating the signals, which has the nice property that it should be independent of the sample rate out (though, in fairness, I've only tested at 48kbps).
That's cool! Is it reliable? Is the volume setting critical? Where's the code please ?!?!?

The version 2 of my experiments using symbols more than doubles the bps: I get +29k bps @44100 and 32k bps @48000, but it still misses some bits sometimes, the timing of the decoder is very critical^W tricky, and the 741 slow (and asymmetric) response does not help with that.

At this rate of progress soon we'll manage to have ethernet thru the cassette port, lol.
--
Jorge.
Jorge
2017-10-19 04:44:46 UTC
Permalink
Post by Egan Ford
Sweet. I looked into this before when I started my initial research in
2011 but there wasn't a seamless standard way for browser to record
audio (unsure if for privacy, or browsers makers just could not agree on
a standard).
Yeah, the web 'standards' are permanently in flux...
Post by Egan Ford
Will this work with any browser? Any phone? And without prompting the
user?
In any ~ modern browser, yes. But it MUST ask the user for permission to listen, nobody wants a page to turn on your microphone without you knowing it.
Post by Egan Ford
Is there a way to rise MIC to Line level without modding the IIe?
Yes and no. You can pump up the Mac/PC preamplifier (see the ADT page) but that pumps up the noise too and in any case does not work/help with Apple II to Apple II comms.
--
Jorge.
James Davis
2017-10-19 08:03:57 UTC
Permalink
Post by Egan Ford
Is there a way to rise MIC to Line level without modding the IIe?
Yes! One could make their own cassette output jack setup in one of the plastic hole plugs on the back of the Apple IIe by drilling a hole in it and mounting the jack in it. Then solder a potentiometer/rheostat or a pair of resistors across it with wires going to the three jack points and to the three points on the motherboard where R6 and R9 are. Connect the three wires with probe-spring-hooks to the appropriate wires coming out the ends of the resistors R6 and R9. The potentiometer/rheostat or the new pair of resistors would then be like R6 and R9 are on the motherboard, but of maker/user controlled values. The potentiometer/rheostat would allow you to change where you tap into the voltage divider it creates, thus becoming a volume control for your new cassette output jack.

The only real (semi-permanent) modification this makes to the Apple IIe is the hole drilled into the (replaceable) plastic hole plug. The pot or resistors would be soldered to the back end of the new jack (inside the Apple IIe) or made to be a part of a special cable's plug (outside the Apple IIe).

You don't even need a jack/plug or a drilled hole cover if you make the mod on one end of the cable with its wires attaching similarly (with probe connectors) to the motherboard resistors. Just remove a hole cover and run the wire through it; or run the cable through one of the vent slots on the side of the Apple IIe case before you modify its one end inside the Apple IIe.

This should work for any Apple II that has the traditional case and cassette I/O ports. I don't know about other cases.
James Davis
2017-10-19 08:22:44 UTC
Permalink
Post by James Davis
Post by Egan Ford
Is there a way to rise MIC to Line level without modding the IIe?
Yes! One could make their own cassette output jack setup in one of the plastic hole plugs on the back of the Apple IIe by drilling a hole in it and mounting the jack in it. Then solder a potentiometer/rheostat or a pair of resistors across it with wires going to the three jack points and to the three points on the motherboard where R6 and R9 are. Connect the three wires with probe-spring-hooks to the appropriate wires coming out the ends of the resistors R6 and R9. The potentiometer/rheostat or the new pair of resistors would then be like R6 and R9 are on the motherboard, but of maker/user controlled values. The potentiometer/rheostat would allow you to change where you tap into the voltage divider it creates, thus becoming a volume control for your new cassette output jack.
The only real (semi-permanent) modification this makes to the Apple IIe is the hole drilled into the (replaceable) plastic hole plug. The pot or resistors would be soldered to the back end of the new jack (inside the Apple IIe) or made to be a part of a special cable's plug (outside the Apple IIe).
You don't even need a jack/plug or a drilled hole cover if you make the mod on one end of the cable with its wires attaching similarly (with probe connectors) to the motherboard resistors. Just remove a hole cover and run the wire through it; or run the cable through one of the vent slots on the side of the Apple IIe case before you modify its one end inside the Apple IIe.
This should work for any Apple II that has the traditional case and cassette I/O ports. I don't know about other cases.
P.S. Even easier: attach probes clips to a (100~330 ohm) resistor and shunt R6 only.
Jorge
2017-10-19 10:25:55 UTC
Permalink
Post by James Davis
P.S. Even easier: attach probes clips to a (100~330 ohm) resistor and shunt R6 only.
Yes, the only remaining question is, once all this cassette xfers thing is finished and settled, who is going to be the first to sell these in kits?

$$$!!!!! :-)
--
Jorge.
Egan Ford
2017-10-19 22:52:37 UTC
Permalink
Post by Jorge
Post by James Davis
P.S. Even easier: attach probes clips to a (100~330 ohm) resistor and shunt R6 only.
Yes, the only remaining question is, once all this cassette xfers thing is finished and settled, who is going to be the first to sell these in kits?
Is there nothing that could be produced outside the case? Inline to the
jacks?
James Davis
2017-10-20 07:36:03 UTC
Permalink
Post by Egan Ford
Post by Jorge
Post by James Davis
P.S. Even easier: attach probes clips to a (100~330 ohm) resistor and shunt R6 only.
Yes, the only remaining question is, once all this cassette xfers thing is finished and settled, who is going to be the first to sell these in kits?
Is there nothing that could be produced outside the case? Inline to the
jacks?
No. You have to shunt R6, which only has connection points on the top and bottom of the Apple IIe motherboard; and similarly for the Apple II/II+.
Jorge
2017-10-20 22:00:54 UTC
Permalink
Jorge, I was hoping to experiment with your code also, but it doesn't seem to be online anymore.
There are two copies online:

https://github.com/datajerk/Turbo-Cassette-for-the-Apple-II/
https://github.com/david-schmidt/Turbo-Cassette-for-the-Apple-II/
--
Jorge.
Loading...