Any help appreciated, first time posting. Feel like I've tried everything under the sun to get the "cassette in" on my Apple ][+ to fully work. I CAN get low fi files from http://asciiexpress.net/ to work, so the signal is getting to the Apple. On their site's README it says "If HIFI does not work for you, then it never will on that system, use 8KFI." That's a pretty vague stattement, but opens up a question. Has ANYONE gotten a ][+ to accept HIFI? My system won't accept 8KFI either. I've tried 2 new mini-jack cables - one recommended by a site for this purpose and the second claiming to handle HIFI. I bought a connector cleaning kit and gave it a treatment. I've tried downloading the files to my 2019 Apple iMac and tried multiple players - same results going through ALL levels of volume. LOW FI works, all others don't. I even tried using my iPHONE and an oold iPAD 3 as playing sources, all identical results. My ][+ has a language card for increased RAM, buit otherwise seems stock. I was told my old CRT monitor might be causing hum that could interfere, so I pulled that away from the system while I try - no luck. I've tried talking to an audio professional AND an engineer, both had suggestions, but nothing worked.
FIRST - has anyone EVER gotten a ][+ to accept HIFI or 8KFI?
SECOND - any other remedy suggestions?
Any help appreciated.
Thanks.
On my Apple II+ HiFi works fine using an old iPhone 6s, an old iPad and an Android Galaxy A20s. The cable I use is very short - only 12" and I made it myself using coaxial cable. On all devices I put the volume on MAX after I plug in the jack.
iPad.JPG
GalaxyA20s.JPG
I wouldn't advertise what computers I have. The length and type of the cable is not that important. But it is critical to use the maximum volume (amplitude) your device can provide.
Using an iPAD 3 trying HIFI will get me "ERROR." Trying 8KFI will get me CHKSUM ERROR"
Checked a LOFI just to make sure it works at all, and that does work fine.
I've tried max and steadily reduce 1 unit at a time until the ][+ doesn't respond. I've done that same method using website directly from 2 separate bowsers on my iMAC, tried downloading files and playing back using Firefox and Safari browsers, Quicktime, Audacity, always the same results.
Out of curiosity why wouldn't I mention the computer I'm asking the questions for?
It was not about you but about CVT. Anyway, try using another "player", check with your headphones which one can output higher volume. You may have to move up several volume controls -- one within a browser and one for the device's sound card.
Why wouldn't I show it? You think someone will come and steal it? (LOL)
This is not a Rev.0 Apple II and it's not worth more than $400 on a good day.
This may not help except to make you avoid giving this a second thought... But first, I have a quesiton... why do you care about the hi-fi or 8kfi signals if lo-fi works? The format for the data waveform comprised of 1kHz and 2kHz "bits" which is also about as lo-fi as lo-fi can be.
I've documented several observations regarding the asciiexpress.net files and getting them to work. What I've found is not unlike what you're experiencing one format works the others don't. But I'll also add, on any single system only one format to works. For some systems that's lo-fi works, others hi-fi. I've a fair bit of testing trying to understand why that is and I haven't found the answer. But I also haven't investigated on the II side beyond the input jacks.
I'm sure you're well aware of all the special restrictions on playing the audio. which means absolutely no audio enhancements (bass boose, dolby headphone, equalization, hearing protection, etc). This can be trickier than it sounds tho! For example Apple has audio enhancments in several places in the UI so things can get misseed. IIRC Andriod was easier to find in and disable all enhancements. Side comment: I've seen reports that some cables have issues with the jacks so that it's actually possible to short out singal to ground, testing will rule that out. I've had better luck with andriod phones than iphones (older 4S when the 3.5mm jack was still a thing).
The II documentation states the input signal should have a nominal level of 1Vpp which is below line level (ie inter-conponent singal level) and I've found if level of 1Vpp< signal level <1.8Vpp work well. I disagree with what some have said about max volume, I don't agree with that unless there's some ear safety attenuation in play. I say this because headphone levels can saturate the II's line in. Saturation isn't a problem with the sync tone. Data is much more sensitive to levels and saturation. I've found anywhere between 80% to 90% max will provide levels near 1.5Vpp work well.
I've documented several observations regarding the asciiexpress.net files and getting them to work. What I've found is not unlike what you're experiencing one format works the others don't. But I'll also add, on any single system only one format to works. For some systems that's lo-fi works, others hi-fi. I've a fair bit of testing trying to understand why that is and I haven't found Sthe answer.
A fine question. If I were only trying to get games from that site, there's no issue. Games on the site have LOFI as a choice. The system disks on the other hand don't have LOFI as an option. In other words all files under "DISKS" are not availble to me.
I'm sure you're well aware of all the special restrictions on playing the audio. which means absolutely no audio enhancements (bass boose, dolby headphone, equalization, hearing protection, etc). This can be trickier than it sounds tho! For example Apple has audio enhancments in several places in the UI so things can get misseed. IIRC Andriod was easier to find in and disable all enhancements. Side comment: I've seen reports that some cables have issues with the jacks so that it's actually possible to short out singal to ground, testing will rule that out. I've had better luck with andriod phones than iphones (older 4S when the 3.5mm jack was still a thing).
Solid points you made there. I'm not aware of any enhancements being made by my 2019 iMAC, but I'll look around. In the meantime I tried to use not only my iPHONE but an old iPAD 3 and none of those worked. Above in this thread someone DID get a II+ to use HIFI, so that gives me hope.
Saturation isn't a problem with the sync tone. Data is much more sensitive to levels and saturation.
I've tried max volume and steadily decreasing until the Apple no longer responds across all my testing methods. It's childish of me to say, but it's becoming a puzzle I just want the answer to. Why is someone else using an Apple II+ able to get HIFI to work? Regardless some great food for thought you've given me, and I thank you.
If one cannot load a game on HiFi under GAMES (https://asciiexpress.net/gameserver/), then it's also not possible to format a disk under DISKS (https://asciiexpress.net/diskserver/), because all disks are in HiFi. The author is trying to format a disk from the AsciiExpress site, which is why he is trying to get HiFi workinng. I know this, because he is a customer of mine and I have been unsuccessfully trying to help him format a disk through the audio port.
Details:
On the AsciiExpress site under GAMES there are two options: HiFi and LoFi. HiFi uses a sampling rate of 48000 Hz, while LoFi uses the much slower sampling rate of 11025 Hz. This is why LoFi takes 4 times longer than HiFi to load a game. The advantage of LoFi is that it can work over a much noisier line, while for HiFi you need a really good line. It’s the same thing as a modem – if you have a better line, you can transfer information at a much higher speed.
However, if the connection is good enough for the lower speed of LoFi, but it fails at the high speed of HiFi when it's not possible to format a disk, because disk formatting is only available at the HiFi speed. This is why under DISKS there is no LoFi option, only HiFi, and 8KFi, which is also at 48000 Hz.
CVT wrote:
Are you quite sure of that? A modem must operate at the exact same modulation and symbol rate as its counterpart on the other side of the line. To provide forwards and backwards compatibility, modems actively negotiate the speed that both will use. The cassette-in feature of the Apple II is strictly unidirectional, so no such negotiation can take place.
The description of the cassette interface is ~1500 baud FSK (a single cycle of 2 kHz denotes a zero bit, and a single cycle of 1 kHz denotes a one bit). To decode this modulation, the uA741 (acting as a comparator) detects each zero voltage crossing (positive to negative, or negative to positive) and the ROM routine polls that port in a loop to estimate the length of each cycle. Reading data at a different (higher or lower) speed would require using a different machine language reading routine, and different frequency symbols.
This doesn't have anything to do with the "sampling rate" or "fidelity" of an audio file.
Yes, I am sure of it. You can go to GAMES (https://www.asciiexpress.net/gameserver/), download both the HiFi and LoFi version of any game's WAV and compare them in Audacity. Take a look at their sampling rate and run time. You can also download a disk from DISKS (https://www.asciiexpress.net/diskserver/) and take a look at its WAV file in Audacity.
The fact that the author has a problem with the HiFi versions, while the LoFi versions work fine indicates that there is a problem with the signal quality on his Apple II+ machine. This is further supported by the fact that he gets an error when he tries any of the disks from the AsciiExpress site (https://www.asciiexpress.net/diskserver/), which in terms of run time and sampling rate are equivalent to the HiFi versions of the WAVs under GAMES.
The point I am trying to make is that if an Apple II has issues with a game under GAMES on HiFi, it will also have issues with any disk under DISKS.
IMG_2412.JPG
So bunch of things all in this post that I expect may be adding some confusion.... First sampling rate has no impact on playback time, sample at 22kHz or 11kHz they both wil play for an equal amount of time.
Looking at the data in the waveforms I think I'm understanding your comment about the difference with hi-fi is that it the writer includes the formatter which would mean more data, more delays for the format to process. But the game data and data transfer times are going to be equal.
As an example 4 seconds of 700Hz, then the sync, then 4 more seconds of 700Hz followed by the writer starting at 8s all seen here, not lo-fi on top, hi-fi on bottom:
high-lo @ 4 seconds.PNG
Then the disk writer starts at 0:08
hi-lo at 8seconds.PNG
So up to here we're 100% in sync, what happens next is where things change but that's because the data and actions change.
With the lo-fi the disk writer is sent over, and the disk writer is basically all that's really needed. The reason I say this is because all a format does is populate sectors with blank data and writes the TOC.
Who needs to wipe a sector before writing a sector if the sector will contain specific data anyway?
Continuning in a second post because I hate this editor and it does more harm than good when I'm writing thing out, half the time I can't even see the text at the bottom of a long message.... system is telling me something!
So here's where things change and the writers are transferred, the lo-fi writer (as mentioned) just writes tracks/sectors. The hi-fi will format then write tracks/sectors. So the data size for the writer vs format writer is different in addition the writer formatter needs to delay for the format to complete. In reality the format is wasted time, format zeros the disk and writes a TOC, but if we're transferring a disk image that's all included in the image data. If we're looking at bad disks, either the format or a write will fail at the same point so it's a wash how exactly the error is encountered.
If you look at the data transfer sizes, meaning filter out all the 770Hz tones after the writer or formatter/writer happens you'll likely find the hi-fi version is acutally shorter because the delays are built into the lo-fi transfer and in the hi-fi version data and delays are clearly different sections. The data is identical, the sampling rate means nothing becaue it doesn't mean something plays faster or slower just means more bits are pumped through for each second of audio and this is the audiable signal and time is constant, ie one second at 48kHz is also 1 second at 11.025kHz the data size is bigger, but that's not being transfered that's a playback data not tranfer data. There's is no difference in playback time as a result of sampling rate, period. The sampling rate is a fidelity thing.
Again, the point about hi-fi at 48kHz is really, and I mean really, pointless with this data. The casetted data encoding frequency does not exceed 2kHz and because of that Nyquist says we don't need anything higher than 4kHz and 11kHz has lots of extra margin. That all being said, yes a disk image of all 0's will take less time to transfer than a image full of 1's just because of frequency encoding.
I'm not fully understanding your posts, so can you bottom line what you think can be done to circumvent the problem? In other words, knowing what you now have proved, how can I get my Apple II+ to use HIFI or 8KFI? I was giving this some thought, and since a user above got HIFI to work on a II+, that leaves these possible problems:
- Bad or inssufficient 3.5mm cable. Unlikely because the 2 I just bought were brand new.
- Connection problem. Possible but unlikely. I've cleaned the old Apple connector and the 3 playing devices I've tried all seem to be working correctly. Still possible though.
- Something I'm doing when playing the signal back. I've tried across many methods and volume levels with no differing results. LOFI always works, HIFI and 8KFI do not.
- Something is simply WRONG with my Apple II+. Considering its age, even though it works for other purposes, probably the most likely culprit.
I've got a new idea to try. I own a higher quality audio interface, I just need to locate it. This means I could bypass the headphone computer connector. Maybe a better , possibly louder signal would do the trick. Worth a try. At this point I've invested days of testing into this and would love to find a reasonable answer/ solutionm so others could be spared my experience.
And thanks to everyone who's contributed to this thread. Your help is very much appreciated.
Skipper
So what happens around the 10.292 seconds mark in the air_cars.hi wav file? Looks like it's cruising along at 2 KHz and abrubtly switches to 5 KHz?
aircars.jpg
Assuming this is directed toward me, so that's data. I do understand what you're saying that basically in .001 (10.289 to 10.290) there are two cycles which would be 2kHz then the signal goes cray, and I agree that doesn't quite make sense. The 2kHz singal is the last bit being repeated but yeah I agree that doesn't look good.I took a closer look and it looks like 48kHz is not really correct becaues if you look at the end of the stream with both 48k and 11k you can see 11k has higher resolution which does not make sense! Looks like a bug with the the 48k sampling actually closer to 6kHz with the waveform generation. Nice catch!
The higher sample rate is on the top!!
yeah that's wrong.PNG
And to just follow up to that last one, while just looking at the waveform we can seee what is expected but also not the correct frequency.
I'd want to check this with some other tools becuse some other things about the hi-fi wave look odd....
frequency encoding.PNG
For what it's worth, here's a short program that pipes the cassette-in directly to the Apple speaker so you can hear exactly what signal the computer is receiving through the LM741.
capture595.png
Type in the program, then RUN it. When you feed audio into cassette-in, the signal will be reproduced through the Apple speaker. It's not pleasant listening, of course, but it will enable you to hear the effects of the volume control setting. On my Apple the audio is error-free when the source's volume is betwee 66% and 94%. There's some sort of flange-like distortion below 65% or above 95%. In my setup, the signal abruptly drops out below 58% volume.
This "tape monitor" doesn't give any objective measurements of signal quality, but sure helps to give a tangible feel for the whether the signal is getting through!
[Jeff D] - I didn't look at the very end of the files before, but now I see both the "hi" and "lo" files end with 10 cycles of 1 Khz. This doesn't seem unique to the "air_cars" game file either - I saw the same odd "shift to a much higer frequency" in frogger.hi.wav (which I had just randomly picked from the list eariler.) It also happens around the 10.2x seconds mark in that file.
No one is saying that sampling rate affects playback time in general. I am talking about the games on AsciiExpress specifically and as you can see the LoFi versions all have a sampling rate of 11.025 kHz and all have much longer playback time than the HiFi versions, which have a sampling rate of 48 kHz:
Playback.png
Obviously the HiFi files need the higher sampling rate, because at some point they switch to the higher baud rate. And with a higher baud rate, the playback time will be smaller, simply because the transmission is faster.
All audio files on the AsciiExpress site are created using c2t: https://github.com/datajerk/c2t
Notice the -8 and -f parameters below, which switch the sampling rate to 48 kHz and the maximum baud rate to 8000 bps and 9600 bps:
usage: c2t [-vh?]
c2t [-elp] input[.mon],[addr] ... [output.mon]
c2t {-1} [-cepr] input[.mon],[addr] ... [output.[aif[f]|wav[e]]]
c2t {-2} [-abcdef8pmqr] input[.mon],[addr] ... [output.[aif[f]|wav[e]]]
c2t [-n8] input.dsk ... [output.[aif[f]|wav[e]]]
-1 or -2 for Apple I or II tape format
-8 use 48k/8bit 8000 bps transfer (Apple II/II+/IIe 64K only)
Implies -2a. Negates -f and -d.
-a assembly autoload and run (Apple II/II+/IIe 64K only)
-b basic autoload and run (Apple II+/IIe 64K only)
Implies -2a.
-c compress data
-d use fast 44.1k/16bit transfer (Apple II/II+/IIe 64K only)
Implies -2a. Negates -f and -8. Use for burning CDs.
-e pad with $00 to end on page boundary
-f use faster 48k/8bit (9600 bps) transfer (Apple II/II+/IIe 64K only)
Implies -2a. Negates -8 and -d. Unreliable on some systems.
-h|? this help
-l long monitor format (24 bytes/line)
-m jump to monitor after autoload
-n do not format disks
-p pipe to stdout
-q parameters and data only (for use with custom client)
-r #, where # overrides the sample rate (e.g. -r 48000)
-t 10 second preamble (default 4) for real tape use
-v print version number and exit
[CVT] thanks for the pointer to the c2t code. I get it now, it's a boot-strap mechanism. The 48 KHz sample rate (HIFI) files only use the low speed cassette interface code in rom to load their own high speed decoder; once that's loaded the input file switches over to higher frequency signals (12 KHz for a 0 and 6 KHz for a 1) it also does some clever decompression to achieve a higher bit data rate (8000 to 9600 BPS - depending on the compression.)
The LOFI wav files are simply encoded at the 1333 BPS data rate the routines in the ROM can handle.
So, why won't hifi work on some machines? My guess is it depends on the frequency response of the components at the data-in port (assuming you've eliminated all the external factors like signal level and cabling.) There is a 741 op-amp, a 0.1 uF capacitor and a resistor divider in line with the signal; any or all of these components could be out of spec. Could also be noise on either the +5 or -5 power supplies (hard to tell from the schematic what kind of bypass caps are near the op-amp, and I don't have an apple II.) It would also appear the op-amp (operating as a comparator) is probably swinging +/- 4v or so and driving a 74LS251 input through a 12K series resistor. Going by the max ratings in the databook, the 'LS251 should be able to handle this, but replacing the part at H14 might not be unreasonable.
Good Luck!
Some very interesting updates, thanks Scott that program looks interesting.... will be fun to try.
With regard to the hi-fi stream I am still a bit confused just because the data didn't look quite right so a deeper look which was kinda fruitless, but I did discover the game server air cars hi-fi file wasn't created exactly as the dowload options suggets which is "hi-fi".
The hi-fi files appears to have been generated with 8k (-8) settings rather than hi-freq (-f) setting as I was expecting.
There are actually 3 48K stream formats, hi-freq (-f: hi-freq (is this hi-fi?)), 8k (-8: 8k ), and QR (-q : qr-code). I also confirmed 44.1k CD-audio does match what would be expected.
This is what the air cars hi-fi wav file data stream shows:
This shows frequencies of 12kHa and 6kHz for data bits.
The c2t source indicates this isn't a Hi-Fi file but a 8K file, not sure if/how this matters but is different than what the download options stated
The flags for generating the outputs for hi-fi (if hi-fi eqals hi-frequency) suggests this is a 8k file from the program arguments:
since we have a 0 frequency of 6000 vs 8000 this suggests fast is disabled, and because fast is diabled the -f option could not have been used.
air_cars hi-fi file was created as a 8k file rather than the hi-fi format as the gameserver page suggests. Important, not really just something noticed.
What I think is important after looking through the data is, using a any formater other than the lo-fi output, we are skating right on the boundry of minimum sampling frequency to data rate frequency for reliable reporduction of the data stream. The source of th analog wave form can produce a waveform from this data, that's not a problem. But as retro_tinker mentioned... because we've only a small window with the higher frequency rates any glitches in the audio stream coming in or propigating through the II circuit can be fatal. With the lower data rates as seen in the 11kHz stream each bit is on the ling for 6x longer which provides a ton of wiggle room when signals aren't great becuase there's more time for the circuit to detect the transitions. Any glitch in the signal because of RF interference, crappy ground or other problem can more easily cause corruption at the higer bit-rate frequencies and just basically disapper at the lower frequencies because of how the circuit is configured to work.
As the asciiexpress.net site mentions, cables are important and while they call out Monster cables I'm not sure Monster is in business any more. Most consumer cables are really crap with thin wires and maybe little shielding. I believe I saw CVT and someone else mention they do what I do, which is roll our own. Obvioulsy not what most do, but we can select good cable with several layers of shielding (foil and braided as seen in coax). The results really are night and day especially in environments with lot of RF noise.
I too want to test some of this new information out. Like skipper_matin said, and I agree, this is one of those things it would be nice to be able to explain in a way other than it just seems to be random and good luck!
On the AsciiExpress site, HiFi does not stand for "high frequency", but "high fidelity" and a sampling rate of 48 kHz, as opposed to 11.025 kHz for low fidelity. Both the -8 and -f parameters produce HiFi with a sampling frequency of 48 kHz. The only difference if that -8 sets the baud to 8000 bps, while -f sets it to 9600 bps.
To successfully produce a LoFi version of my ESP32 SoftCard's Interface program, I only used -2 and -b:
c2t-96h -2b ESP32NTSC,5FD0 ESP32NTSCLoFi.aif
This produced an audio file with a sampling rate of 11.025 kHz and a low baud of around 1200 bps (or 1333 bps) supported by the Apple II ROM, which skipper_martin was able to load successfully on his Apple II+.
Unfortunately this program does not allow me to produce a LoFi disk (an audio file which formats a floppy). If a .dsk or .po file is detected, it automatically switches to 48 kHz and 8000 bps.
Yes, James Sather discussed distortion and "cassette input wave shaping" around page 7-12 of Understanding The Apple II.
Major factors in its frequency response are the capacitor C10 and a voltage divider composed of R30 and R17. Rather than fine-tune those components, you can crudely boost its sensitivity to some frequencies by just bypassing resistor R30 with clip leads. (That's resistor R4 on an Apple //e)
Resistor R30 highlighted.png
This makes edge-detection demonstraby more sensitive, probably at the expense of increased jitter. It's a crude hack, but it's safe and easy to try.
IMG_1315.JPG
Referring back to that "tape monitor" program in my previous comment, this hack enables my Apple to read tape audio down at a volume setting of just 47%, compared with 58% without the hack. Since it's halving the resistance between the capacitor and the 0v supply, this hack probably favors higher frequencies because there's less impedance between the capacitor -- and because the comparator will drain faster.
Since the 1980s, I've used this hack on both Apple II and Apple //e motherboards -- it has the same effect on both. But I originally used it to help digitize speech and sound effects, not data, so I'm not prescribing it as any sort of "fix" for the issues above. But it seemed relevant to the discussion, especially after comments about sensitivity and frequency response.
Bypassing that resistor makes the opamp vulnerable to input signal amplitude above +-15V.
Wouldn't that be fine? The amp is configured as a comparitor (zero crossing) and either outputs 5 when negative input is >0V, -5 when input is <0V. The 741 can handle input voltages of +/-30V. I think it's also important to remember the the cassette input should be a line level input (ie magnitude less 2V) so... the risk should be pretty low for anyone connecting to a headphone jack. If your hooking this up to a 100W amplifier speaker out.... that could be a problem for reasons beyond the signal levels.
Wrong. The absolute maximum rating is +-15V exactly as I wrote. Operational maximum is +-13V. Do you think Woz put that resistor without reason?
https://www.ti.com/lit/ds/symlink/ua741.pdf?ts=1717258226668&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252Fde-de%252FUA741%252Fpart-details%252FUA741CP
LOL whoops, serves me right for looking at a data sheet at 1AM after a couple cocktails! I was looking at the datasheet for the Motorola MC741CP which is in the //e and unlike the moder TI part you shared Motorola includes both differential and common mode voltage, and I was looking at differential! Common mode Vin is also +/-15V. Also interesting the TI part lists its differential input at +/-15V where the Motorola is +/-30, but they are clearly two different circuits. In any event those values are still much greater than the correct input to the cassette port and neither should work correctly when input voltage exceeds supply voltages. (TI ratings note 4, Motorola ratings note 1)
I also noticed the TI datasheet includes slew rate is 0.5V/us and wonder if it's the similar in the motorola part....
At 48kHz the sample period ~28us so it should be fine, just throwing this out for its info:
Looking at the timing of the zero bit pulse at 12kHz with a 48kHz sampling rate the 0 pulse is a sawtooth wave: 0V, Vin, 0V, -Vin, 0V
48000 samples/second
1 (6000Hz) and 1 (12000Hz) samples.
48K samples 1 and 0.PNG
I also didn't read the bypass is a general purpose fix, Scott did say "safe and easy to try" which I read as for testing... he did offer this as a easy work around instead of tuning input filter response.
For anyone playing along at home (and can't read the schematic), on the //e these components being discussed are: C11, R4, R12, and the bypass would be applied across R4.
IIe cassette in circuit.PNG
Wrong, the TI datasheet also specifies max differential voltage of 30V. Since it has no polarity specified and is between the two differential inputs it is the same as +-30V. Despite different manufacturers these are interchangeable chips, like twins, not two different circuits as you claim.
Functionally similar I agree, interchangable sure but according to their datasheets they aren not the same, does that matter? Don't know the TI may be a better design too.
So I put a scope on the //e and found some interesting things and one was actually a surprise that I'd like to dig into deeper.
For my testing I put probes at the input side of C11, the negative input to the 741, the 741 output, and the mux output.
cassette probing.PNG
As expected the -Input is attenuated 50%, but I didn't really see any filtering, which kinda makes sense as an AC coupling cap and divider it should be high pass everything we care about.
While the inputs are flipped symetric in shape, the opamp output is not, this configured as a comparitor and the outputs are inverted so positive pulses are the result of the negative sections of the wave, and the negative is from positive input. The ouputput pules are not equal the postiive input to the opamp may be slighlty positive.
The circuit for me worked really well in game server at lo-fi an hi-fi settings.
Moving to disk mode I also had no problem with the hi-fi files, I did not check 8k because I did find something important.
Whlie testing the game server I found the phone output at levels >70% max would work great, this basically means the cassette imput was somewhere around 700mVpp, and my droid at 100% output was 1Vpp so no saturation.
Then I went to disk mode and tried ADTPro since the only disk I had available was my ADTPro disk I wouldn't be losing that! At 100% works great, but then dialed down the vloume to 70% and found something interesting when instadisk starts loading...
disk writer loading.PNG
Line 3 is the opamp output which clearly stays high during the entire diskwriter transfer! But everything up to that point is fine. After the diskwriter program finishes (9 second xfer) the signal recovers to a pont where the opamp can again send to pull to -5V. You can see in the capture, the opamp input maxes at 120mV, I belive the threshold for this system for "high" is closer to 140mV which is close, but also too low.
Very curiosus, and does explain why the main loader and load but then fail. This is where things get interesting because you can see the opamp output remains high during the instawriter transfer and recovers when that's complete... odd right?
Looking at the signals there it's clear the opamp wasn't quite able to respond at these lower input levels when the bit frequencies transition to 12kHz/8kHz, but does just fine at the slower frequencies:
opamp response to writer load.PNG
So I'm chainging my position on output level for my phone... originally I thought 80% was great but now I'll change that to 100% output. I still think saturation can be a factor, but with my phone it's headphone levels are low enough the cassette input doesn't saturate, and I think that's a result of the c2t outputs being at about 75-80% max output level. This was also done with stereo 3.5mm calble I got from amazon which I was expecting would fail but didn't so maybe they're pretty good. Here's the link:
Amazon.com: oldboytech 2 Pack AUX Cord, 3.5mm Audio Cable [4ft/1.2M, Hi-Fi Sound] Nylon Braided AUX Auxiliary Cable for Car Compatible with Stereos, Speaker, iPod iPad, Headphones and More(Grey) : Electronics
I may test this with ome other //es, the one I used was an earlier buid, first few weeks of 83 so it may be better than some later systems which were caught up in cost reductions... I can check a platinum and see if anything is different.
Yesterday when looking at this I had made a post I didn't share, and one of the things I had questioned was why are these waves using sin waves rather than square waves... this seemed important when dealing with the 12kHz pulses for 0 because as a sin wave it just becomes a 4 sample sawtooth wave (0,1,0,-1, (final 0 omitted becaue the leading value of the next sample starts at 0)) which depening on how fast the coparitor reacts I could see may be a problem. If instead it was 1,1,-1,-1 there's a quicker rise which should elminate any delay in the comparison.
Sine wave also seemed odd since the II is expecting pulses not pretty since waves.
While looking at the disk writer wave, it's clear the c2t author at some point shared the thought, the top is the ADTPro disk writer wave and the bottom is the air cars gameserver wave.
The diskwriter wave uses pulses instead of the sine waves.
disk writer 770 pulses vs game server.PNG
Yes, for disks the newer c2t-96h.exe tool produces a square wave, while the original c2t.exe still produces a sine wave.
Following up on my previous post, I located my device - a Focusrite Scarlet 2i2 which allows me to bypass my headphone jack on my 2019 iMAC. Didn't help, but was worth a try.
I think you mean triangle wave, not sawtooth. (A sawtooth or ramp has near-infinite slope at the end.) When that PCM data is played back, the DAC reconstruction filter turns it into a sinusoid. A real triangle wave has energy at frequencies over 24 kHz, which the filter blocks.
The slope magnitude (slew rate) of the sinusoid is highest at its zeros, when it is V_peak * 2π * freq, or for 12 kHz: V_peak * 0.075 V/µs.
So a signal level of +13.4 dBV would still fall under the 0.5 V/µs slew rate. I think we can confidently say that covers all line outputs or headphone outputs that might be used as the signal source.
But a dBV signal magnitude measurement has nothing to do with slew rate. Am I missing something.
btw: this thread is a great discussion in many respects...and it also shows how complicated something has become that used to be sooo simple.
Well, now it's a lot simpler for the user - you just plug in your phone, hit play and in less than 5 minutes it formats a bootable floppy with whatever you want on it. The underlying technology that provides this end-user simplicity is lot more complicated though and if it breaks, it’s harder to diagnose and fix.
It also gives an easy out for the purists, who don’t want any modern hardware in their Apple II, like floppy emulators or modern ProDOS cards.
LOL, yeah that's a great catch... .triangle.I was likely htinking about ohter things like where the loader sampling rate is documented and wondering if there could be a timing issue with some systems with hardware/software timing tolerances at the fast rate. I think we all agree it's not an unrealistic idea that signal timing, propigation and software handling could be an issue. But I don't know much about the loader routines and haven't had a chance to look.... just too busy with other things.
Thanks for explaining. I must have missed the formatting a disk, thinking this was about "loading a program" from the Cassette port...and I'm thinking, just get a WAV file of the program (or save a program to a WAV file) and load/save to a smartphone/computer.
Tried that using Quicktime and Audacity. No luck.
Would you show a short video of the things you are doing when faster versions fail, especially what is shown on the screen during these failing attempts and which version you are selecting from the web site. Remember -- volume to the max.
cassette_in_test2.mp4
I can indeed and thanks for asking! Much appreciated.
Can you do the following experiment: remove all cards (even the floppy controller) except the language card and try to load the first disk from https://www.asciiexpress.net/diskserver/ on HiFi. If any of the cards was causing the noise, you should make it all the way to the progress screen before you get an error. This screen is part of the custom loader.
Here is this same experiment on my Apple II+ with all cards removed, except for the Language card:
DiskHiFi.JPG
error.jpg
Well, it's not because of the cards. Without an oscilloscope, the only easy way to diagnose it is to get a hold of a second Apple II+ and start swapping things.
Yeah, I'm pretty convinced it's not a cable or playing device issue but something amiss on my Apple II+, that being said your new cards are working great! So much fun.
Thanks for all the help.
So now I see this is more a discussion on getting the WAV file(s) from Apple Disk Server to work in the creation of the "software" floppy disk on an Apple II whatever.
I compared the WAV signal output from an original Apple Othello disk to the Apple Disk Server and see there is a whole lot more going on than just "loading" a binary file from cassette or WAV audio output source. It also has to "load" code to call built-in ROM and/or DOS/Binary custom routines to initialize and write data to the floppy.
As noted earlier, the audio input level on the Apple II/II Plus/IIe is very sensitive and begs for a 1v peak-to-peak signal (or slightly higher). The rule of thumb is to play the audio (cassette tape of WAV file) and listen to it on a speaker or headphone. Crank the volume up as loud as possible but where it does not distort.
As CVT noted, without oscilloscope for measuring and seeing signal peak swing values, it becomes an art form of finese.
It was a real eye-opener for me when I compared "Othello" from the Apple Disk Server HIFI WAV file, input into Goldwave, an audio recording and editing software, and comparing it to the actual "Othello" WAV recording from the original Apple cassette tape loaded into Goldwave.
I can see the attraction to Apple Disk Server.
Wrong. Volume shoud be set to the max regardless of distortions. I am not convinced that this fancy iMac of the OP is not the source of trouble here. Distortions on headphones/speakers can be caused by speakers themselves The Apple is looking for the digital data only, not for quality sounding signal with the full audible frequency band, so distortions are irrelevant as long as they don't introduce additional zero crossings of the signal. That can be achieved by maximum volume.
Thanks!
Well, you never know the quality of a cable until you cut it, no matter how expensive or colorful it looks. This is why I made my own very short cable from a 50 Ohm coaxial, simply for the fact that its shielding is really good and thick. I also left the middle ring unconnected:
Jack.JPG
You might also want to eliminate the connection to the monitor as a possible source of the noise. Just carefully unplug the RCA video connector right after you type LOAD. Then hit RETURN, do the playback and connect it once the playback is complete to see if the result is the same.
Pages