Discussion:
Gentlemen, 14+ kbps !
Add Reply
Jorge
2017-10-02 08:51:15 UTC
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
Post by David Schmidt
+1. Waiting to steal <err> read the code.
lol
Jorge
2017-10-02 17:31:51 UTC
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
Mousetext in the username maybe?
Jorge
2017-10-11 18:43:45 UTC
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
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
Reply
Permalink
Raw Message
75.170.79.245 : You should reload the page: you're using an old version of the turbodemo.
Loading...