c2t-96h fails, 8000 c2t works

[majick]

I've yet to produce a file from -96h (or any other 9600 file) that loads. Consistently all fail checksum and dump to monitor. I've tried this from multiple output devices, at various output levels, with the same result. I've tested this with my 65C02 and 6502, and with the full enhancement kit installed or not. Nothing seems to get 9600 to succeed.

I know the intent was for -96h to be quite a bit more compatible hardware-wise but I think I've got an outlier here. Anything that'd be useful for me to test or experiment with to narrow things down?

[majick]

I guess a little more detail might be slightly helpful:

master branch, as of c7f3d16

//e, both unenhanced and enhanced, barebones with nothing but OEM 80 column card and OEM disk II card. I'd have to crack it to get revisions, but considering it came unenhanced that means it's a little early.

No 9600 file from any source, mine or anyone else's, has succeeded, regardless of method of creation.

[datajerk]

9600 and 8000 should work on all apple 2s where one of them works. What breaks 9600 is the player. Some players do not like the 1/2 cycles used to get 9600. What are you using to play the audio?

[majick]

Two devices have been used as sources, with identical results: an iPhone 11 via lightning-to-1/8" adapter, and an iPad Air 4 via USB-C-to-1/8" adapter. Various pieces of software have been tried for playback on the off chance something clever was happening on the software side: VLC, FileBrowser PRO, Apple Files, and I think at one point we even took a crack at transcoding to FLAC, texting the file, and playing it out of the Messages client.

The DAC in the lightning-to-1/8" in particular is generally fairly well regarded although I don't know if it's well regarded for this particular purpose.

[datajerk]

Avoid transcoding, that will surly fail. Apple Files with iPhone X and lighting-to-1/8" I can confirm works; it's how I do testing. I will test again this weekend, perhaps something changed in the latest iOS.

[majick]

Just as a side note, and obviously orthogonal to this particular issue I'm running into: FLAC at 8000 works totally fine, amazingly enough.

The only reason we tried it at 9600 that time was to avoid Messages "helpfully" transcoding to AAC, which I had no idea it would do to a WAV when texted. On the off chance that Messages had a different playback code path it was one more thing to try.

[avolkov76]

@majick I realize it has been 2 years since, but perhaps you are still interested! Would you be willing to test out an experimental patch for the symmetric (non-96h) 9600 bps coding, used by "c2t -2af", on your affected or unaffected hardware? If so, please check https://github.com/avolkov76/c2t/tree/exp-1 . I committed the patch to this branch. I can also send you the prefab .wavs if you prefer that -- just let me know. Thank you!

[majick]

Hi there, @avolkov76 ! I'll be happy to test this branch out; I've got most of the send-side hardware still around and the //e is right where it's always been.

[avolkov76]

@majick Great, thank you for this! Are you able to build from source and test on your own? Or do you need instructions, or binaries, or prefab .wavs? I am not currently setup here to build Linux or Mac binaries, but MinGW binaries were committed to branch. Just let me know what you need, and I'll get it to you (or attach here).

If/when you get a "CHKSUM ERROR" and it dumps to Mon, it would be very helpful if you could do an Apple memory dump with "0.BFFFW" from Mon while recording the audio from the Cassette Out into whatever format. It will take several minutes to do a full dump.
Arguably the best test sample is tests/images/moon.partol. It is easier to analyze failures if we use the same image. You can produce a test .wav with "bin/c2t -2af tests/images/moon.patrol,801 moon-partol.a-9k.wav" ("bin\c2t" on Windows).

[majick]

Hi there! I remoted your fork, added a .gitignore so I could see what was going on, and built from your exp-1 branch at 44aa014 (trying both before and after my .gitignore local commit)
for macos aarch64. Results were as follows:

 flat  ~/src/c2t   exp-1-local  % ls -ltr bin
total 672
-rwxr-xr-x  1 majick  staff  161360 Mar 27 12:14 c2t
-rwxr-xr-x  1 majick  staff  178136 Mar 27 12:14 c2t-96h
 flat  ~/src/c2t   exp-1-local  % file bin/c2t
bin/c2t: Mach-O 64-bit executable arm64
 flat  ~/src/c2t   exp-1-local  % otool -L bin/c2t
bin/c2t:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
 flat  ~/src/c2t   exp-1-local  % uname -a
Darwin flat.in.nachomountain.com 24.3.0 Darwin Kernel Version 24.3.0: Thu Jan  2 20:23:36 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T8112 arm64

bin/c2t -2af tests/images/moon.patrol,801 moon-partol.a-9k.wav -- 15s data segment, Failed with:
LOADING TESTS/IMAGES/MOON.PATROL, ETA 15 SEC. ERROR

bin/c2t -2a tests/images/moon.patrol,801 moon-partol.a.wav -- 115s data segment, succeeded all the way to title screen (expected)
bin/c2t -8 tests/images/moon.patrol,801 moon-partol.a-8k.wav -- 18s data segment, succeeded all the way to title screen (expected)

quick tests with my own images and tests/images/zork.dsk all had the same result: failure at 9600 with the same crash output.

• MacBook Air M2 (2022)
• Direct headphone out (TRS) to RCA coaxial via single cable with no adapters
• 100% volume
• VLC as playback utility; similar results with quicklook player
• As close to stock hardware as possible, modulo modern disk controller cards and a gglabs z80 card
• US model Apple //e, enhancement kit installed (including the c02 ). No additional ROM mods, no board tweaks, no memory mods, no clock tweaks, OEM 128K/80col card. Possible touchups to board if Apple Rescue of Denver did it before sale; not inspected.
• no hardware reduced or bisected out of the test, just the full array of daily driver cards and drives.
• popped a bit of deoxit-like contact cleaner on the RCA socket back when I was testing this on upstream, no re-cleaning since then
  It'll take me a bit to get your dump out via Cass Out because as I mentioned, the cable I have is TRS and not TRRS. I've got a USB audio capture device with separate mic & head sockets, though, just need to dig it up. Once I do, I can add the dumpfile from the failed run.

Anyway, I'll see if I can't get you that dump later today.

[majick]

Attached, output WAVs from my build.

wavs.tar.gz

[avolkov76]

@majick Thanks for the .wavs. Something good came out of it: now I know for sure that .wav file writing on Windows needs a patch -- working on that. Your moon-partol.a-9k.wav works fine on my unenhanced IIe (didn't test with others; no need). Though it is unfortunate that our systems are not producing identical .wav files. Some piece of unused data is left uninitialized somewhere resulting in differences in audio stream.
A memory dump would be very helpful. But just from the error messages you get (it wasn't a "CHKSUM ERROR"), it looks like an incomplete read. There are a couple experiments we can do, if you are willing. Nothing too dangerous, I promise. ;)

I'll cook something experimental up, with more error prints so we can see what's happening. But the current leading theory is that your power supply's -5V output is off. There are two power pins on the cassette input 741 op-amp where we can get a measurement, as seen by the 741, if you have a voltmeter. A safer place to measure voltages is on the test-pads, on the mobo edge facing the keyboard, on the left. The left-most pad is -5V, with respect to the case, or to the right-most square pad, which is GND. Mine reads -5.06V right now. The +5V (third pad from left) on mine reads +4.98V. So few components actually use -5V on the IIe mobo that a defective supply can go unnoticed for a long time. And when I say "few", I mean one: the cassette input 741 op-amp, in stock configuration. ;) My IIe, with a Disk II controller, consumes just ~15ma of -5V.

[avolkov76]

Hi @majick ! Could you please tell me which 741 chip your IIe has installed? It is the 8-pin chip next to slot 7, grid A11. I unearthed a late IIe mobo here which exhibits symptoms similar to yours, to a lesser extent. This mobo has UA741CN chip installed instead of an LM741CN. I do not know the history behind the change. While all 741 chips are pin-compatible and mostly functionally-equivalent, they do have different electrical characteristics. This would not have mattered for 2KHz tape recordings. But at 9600, we are playing with very small timing margins: +/-4 cpu cycles.

I committed another experimental tweak to the exp-1 branch, which re-tunes the symmetric 9600 (c2t -2af) timing to the found UA741 chip. When you have a chance, could you please try it with the moon.patrol image? I've also added some ranging error messages so we can see which way your IIe's 741 is biased timing-wise. The additional code causes filename truncation in the "Loading" message. When you get an error, I think just a screenshot of the "800.86F 5010.5027" output in Mon would tell us a lot. Finding out just how much the timing must be shifted for 9600 to work on your IIe is valuable data!
Please note that only the "-2af" 9600bps coding was patched. No disk-related code was touched, so there is no need to try it.

[majick]

Hi! I was just about to go check PSU 5V voltages when I noticed your comment: Yep, it's a UA741TC (which TI's datasheet swears the LM741CN is equivalent to), but it might mean in the broad sense.) I'll pull your changes to exp-1 and let you know if that changes anything or if there's usable output.

[majick]

Result:

]LOAD
ERR
{hang} {^RESET}
]CALL-151

*800.86F 5010.5027

Output

[majick]

OH. I LOAD'ed it. Hang on...

Complete success upon actually loading it properly.