Closed Garrett-Bodley closed 7 months ago
Thanks for reporting! I can reproduce the issue.
If I try to generate an audio file using c2t-master/bin/c2t-96h
(the pre-compiled binary), it works, and I can load the audio file in my emulator. The Homebrew version generates some warnings, and the resulting audio file cannot be loaded. This is the output I get with Homebrew:
$ c2t-96h -n UtilityCity.dsk UtilityCity.aif
Reading UtilityCity.dsk, type disk, segment 1, start: 0x1000, length: 28672
Reading UtilityCity.dsk, type disk, segment 2, start: 0x1000, length: 28672
Reading UtilityCity.dsk, type disk, segment 3, start: 0x1000, length: 28672
Reading UtilityCity.dsk, type disk, segment 4, start: 0x1000, length: 28672
Reading UtilityCity.dsk, type disk, segment 5, start: 0x1000, length: 28672
Writing UtilityCity.aif as Apple II formatted aiff.
WARNING: simulated checksum failed: FF
WARNING: simulated inflate failed at 1000
Segment: 0, start: 0x6117, length: 12008, deflated: 58.12%, data time: 10.27, inflate time: 0.00
WARNING: simulated checksum failed: FF
WARNING: simulated inflate failed at 1000
Segment: 1, start: 0x5C2A, length: 13269, deflated: 53.72%, data time: 11.27, inflate time: 0.00
WARNING: simulated checksum failed: FF
WARNING: simulated inflate failed at 1000
Segment: 2, start: 0x62E5, length: 11546, deflated: 59.73%, data time: 9.86, inflate time: 0.00
WARNING: simulated checksum failed: FF
WARNING: simulated inflate failed at 1000
Segment: 3, start: 0x6C2A, length: 9173, deflated: 68.01%, data time: 7.90, inflate time: 0.00
WARNING: simulated checksum failed: FF
WARNING: simulated inflate failed at 1004
Segment: 4, start: 0x6601, length: 10750, deflated: 62.51%, data time: 9.19, inflate time: 0.00
Times: Data: 48.495417, Inflate: 0.000029, Audio: 93.898689, File: UtilityCity.dsk
Play List:
000.00 770Hz Preamble + Sync Bit
004.02 BASIC Header + 770Hz Preamble
008.02 BASIC Stub/Assembly 9600 BPS Code @ 1333 BPS
008.09 INSTA-DISK Code + DOS Load @ 9600 BPS
016.58 Load Segment @ 9600 BPS
026.62 Inflate + Write Delay (2000 Hz)
035.62 Load Segment @ 9600 BPS
046.65 Inflate + Write Delay (2000 Hz)
053.65 Load Segment @ 9600 BPS
063.27 Inflate + Write Delay (2000 Hz)
070.27 Load Segment @ 9600 BPS
077.94 Inflate + Write Delay (2000 Hz)
084.94 Load Segment @ 9600 BPS
093.90 Inflate + Exit
To load up and run on your Apple II, type:
LOAD
Those warnings shouldn't be there.
As the Homebrew formula for c2t
does nothing more than make clean
and make
, I suspect that the problem is the cc65
dependency: the c2t Readme says that cl65
v2.13.3 is needed, and Homebrew installs v2.18. Which version of cc65
have you installed?
Thanks for responding!
I'm on v.2.18 for cl65
% cl65 --version
cl65 V2.18 - N/A
% which cl65
/opt/homebrew/bin/cl65
FWIW the built-from-source c2t is being fed the same binary file as the homebrew c2t (a C program compiled with cl65 v2.18)
Yeah, I've tried building v0.997 with cc65 2.13.3, but without success. It seems that building the released v0.997 does not result in a good executable, but building from c2t master works. I've updated the formula accordingly. Please try brew update
and brew install c2t
.
I'm closing this as fixed. Please reopen if you still have issues with the c2t
formula.
Tested the new formula an a //e today and it works! Thanks for the quick resolution
Hello!
The binary that is installed via
brew install c2t
does not seem to work.When I download
c2t-master
and build from source the generated.wav
file works. I have access to a physical Apple //e and am callingLOAD
to transfer the program.When building from source all three of the following generate a working
.wav
file that loads a working program onto the Apple //e.The cassette load routine seems to work with the homebrew
.wav
file (I get two beeps from the machine), but the program I'm loading does not run.Comparing outputs
Homebrew output:
Built-from-source output:
SHA-1 of the homebrew binary:
SHA-1 of the binaries built from source:
Fat Binary
Both the fat binary of
c2t
and the ARM targetedc2t_arm
work on my machine.The homebrew version seems to be an ARM binary.