Some new info: multiplying the (approximately timed) 45 seconds by 22254 samples/sec gives a figure close to a suspiciously round 1 MiB -- add the fact that the second and subsequent times the sample gets played, it's preceeded by a buzzing sound for a moment, not heard just after reset... :-/
So I did another experiment: right after the code and data previously flashed, I wrote several repetitions of a number sequence (0x05-0A-0F-15-1A-1F-25-2A-2F... you get the idea) which, if played by the sound hardware, would make a sawtooth waveform of about 440 Hz -- an easily spotted sound! I filled up to 256 kiB of ROM this way, reflashed and... it plays the sawtooth, right after the (distorted) sample 8-o Sounds more like 880 Hz, though. Some kinds of distortion could double the frequency of a single wave, indeed; but it's definitely playing fast: after discounting the picture data, the 256 kiB should play for roughly 10 seconds at 22 kHz, but it's doing like 5 s... It wouldn't surprise me if this unexpected speed comes from the lack of a proper initialization of the sound chip -- Yamaha's YM2149 sound chip had a clock speed doubling feature, maybe Apple's has something similar (and it's reset somewhere in the original ROM's code)?
But what really amazes me is the fact that Doug's known good code isn't stopping at the end of the sample... I've double checked that the four-byte header with the sample's length in big-endian format is properly formed in front of the sample, and its address correctly stated in the related LEA of the playing code -- unless Hex Fiend is cheating on me, of course :?: And no matter how hard I try scrutinizing doug's code, I can see no way it could fail doing the right amount of samples...
The only chance would be a mysterious change of D0/D1 values... I could only think of an interrupt, but I'm under the impression that, in the current state (ROM overlay mode, no available RAM, no stack and no propely loaded Interrupt Vectors!) such event would totally crash the computer xx( However, just in case, as soon as I get back home I'll add an interrupt-disable instruction to the code...
BTW: the tests were done with 20 MiB RAM, although in ROM overlay mode that should be irrelevant -- tried last night with NO installed RAM, exactly same results. No ADB devices were connected, nothing on the serial ports, no floppy drive (internal or external). This particular machine has a SCSI failure -- the chip itself (and its connections to the CPU) is fine, but DB2 line is not connected to the SCSI bus (internal or external).
So I did another experiment: right after the code and data previously flashed, I wrote several repetitions of a number sequence (0x05-0A-0F-15-1A-1F-25-2A-2F... you get the idea) which, if played by the sound hardware, would make a sawtooth waveform of about 440 Hz -- an easily spotted sound! I filled up to 256 kiB of ROM this way, reflashed and... it plays the sawtooth, right after the (distorted) sample 8-o Sounds more like 880 Hz, though. Some kinds of distortion could double the frequency of a single wave, indeed; but it's definitely playing fast: after discounting the picture data, the 256 kiB should play for roughly 10 seconds at 22 kHz, but it's doing like 5 s... It wouldn't surprise me if this unexpected speed comes from the lack of a proper initialization of the sound chip -- Yamaha's YM2149 sound chip had a clock speed doubling feature, maybe Apple's has something similar (and it's reset somewhere in the original ROM's code)?
But what really amazes me is the fact that Doug's known good code isn't stopping at the end of the sample... I've double checked that the four-byte header with the sample's length in big-endian format is properly formed in front of the sample, and its address correctly stated in the related LEA of the playing code -- unless Hex Fiend is cheating on me, of course :?: And no matter how hard I try scrutinizing doug's code, I can see no way it could fail doing the right amount of samples...
The only chance would be a mysterious change of D0/D1 values... I could only think of an interrupt, but I'm under the impression that, in the current state (ROM overlay mode, no available RAM, no stack and no propely loaded Interrupt Vectors!) such event would totally crash the computer xx( However, just in case, as soon as I get back home I'll add an interrupt-disable instruction to the code...
BTW: the tests were done with 20 MiB RAM, although in ROM overlay mode that should be irrelevant -- tried last night with NO installed RAM, exactly same results. No ADB devices were connected, nothing on the serial ports, no floppy drive (internal or external). This particular machine has a SCSI failure -- the chip itself (and its connections to the CPU) is fine, but DB2 line is not connected to the SCSI bus (internal or external).