Would someone with a Quadra 700/900/950 be willing to test a program for me?

Interesting. This is a prototype and has some programmable logic on it that's probably a different from the final release.

I was super curious if your prototype's EASC chip would behave any differently, but honestly I think it's the same. I'm guessing that it's occasionally normal for that second interrupt to happen. Thanks again for testing that!

Please pardon my naivete, but what is all this for, exactly?

I'm trying to document Apple Sound Chip behavior on every 68k Mac. The main purpose is to help improve sound support in 68k Mac emulators. MAME, QEMU, and Snow all come to mind. I left Basilisk II out of that list because it just installs its own sound driver rather than emulating the ASC, so it's kind of cheating.

ASCTester is useful for this because documentation for the ASC and its various successors is sparse. I would say the community has learned a bunch of cool things from the leaked Quadra AV ROM/System 7.1 "SuperMario" source code, but the Sound Manager code is completely absent from it, so the sound chip is quite a bit more mysterious than most other topics. MAME, QEMU, and Snow have all run into challenges with sound emulation. This tool helps explain how the hardware really behaves.

This all started because I discovered that an emulated LC II in MAME would hang whenever I tried to play most sounds. I ended up going down a rabbit hole, finding the problem, and talking with Arbee about other unknowns related to the sound emulation. This led to the creation of ASCTester.

It could also potentially be useful for someone who has a machine with nonworking sound to help diagnose issues, but I'd probably have to tweak it into more of a pass/fail test than printing out a bunch of numbers.
 
I was looking over the results in the github and noticed you needed to verify readings with the new code on a number of machines. I have a number of the machines on that list. Would you like me to retest them for you? And if so which version of Asc would you like me to use?
 
Last edited:
Thanks for that kind offer @Callan! I’d say let’s hold off for now, but I will definitely take you up on it later. I found a small bug yesterday and I want to make a version 4 (maybe with some additional tests) before I ask for a bunch of re-tests.
 
I was super curious if your prototype's EASC chip would behave any differently, but honestly I think it's the same. I'm guessing that it's occasionally normal for that second interrupt to happen. Thanks again for testing that!

I am not surprised. This one was used by an Apple developer for a few years after it was made. The board on this one dates to about 6 months before the release, but the firmware is flashed to Terror F1 from July 1991 which is, from what I can tell, identical to the release version.

Here's a few pics of the logic board. There are some changes to the silk screen on the release, and programmable chips on this one have other info printed on them.
 

Attachments

  • IMG_5171 2.jpeg
    IMG_5171 2.jpeg
    4 MB · Views: 12
  • IMG_5077.jpeg
    IMG_5077.jpeg
    2.1 MB · Views: 10
  • IMG_5170.jpeg
    IMG_5170.jpeg
    2.5 MB · Views: 11
@dougg3 Your ASC Tester could be used to test the Cordyceps Power Macintosh boards (PM 5200, PM 6300 etc) because those mostly re-use Quadra 630 HW with the exception of the CPU.
I already implemented a basic emulation for those Macs in DingusPPC. The ROM code for playing the startup bong provides a couple of important insights into the ASC cell inside Prime Time II ASIC - the audio architecture of those machines resembles that of a Quadra 630/LC 475, namely:
- the analog side is implemented in the DFAC II ASIC that communicates with the sound cell inside Prime Time II via a high-speed serial interface not visible to SW
- the SW side is implemented using the extended ASC registers as well as the sound FIFO (SRAM) in the sound cell
- some DFAC II parameters can be additionally controlled over I2C interface

The said ROM code checks for ASC versions $B0 (Batman), $BB (Wombat) and $E0 (Elsie).
I'm not quite sure what are the differences between them. But it's obvious that Elsie provides two sound output channels.

The said ROM code provides two different sound playback routines: one for 8-bit samples and one for 16-bit samples.

That 2nd routine is used only when ASC version is $BB and $EE written to ASC Volume Control register at $806 could be read back.
The startup bong in the ROM of those machines will be expanded from 8-bit to 16-bit samples on the fly in the said routine and written to the FIFO registers at offsets $1000 and $1800.
Otherwise, the other routine is used that pushes sound data to the FIFO registers at offsets $0 and $400.

It would be very helpful if you would extend your test with the above information.

It would be also great if someone owning a Power Macintosh 5200/6300 etc could read out sound chip metrics so I could complete my emulation.
 
Back
Top