Would someone with a Quadra 700/900/950 be willing to test a program for me?
- Thread starter dougg3
- Start date
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'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:
Attachments
@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.
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.
Interesting. On the Q630/LC580 (and the Q800 and Q605 generations) the startup bong is normal and System 7.1 acts completely normally, but 7.5.3+ force the 16-bit path, and the intended behavior there doesn't completely make sense yet. There's also usage of a couple of registers in the EASC range that don't exist on a real EASC.
Is there any manual that describes ASC/EASC registers? Everything I got so far is a commented assembly for the startup bong located in the Cordyceps ROM that reveals merely sound register names. Their layout can be partially guessed from the comments.
There are ERSes for ASC and EASC but they're much less helpful than you'd think, which is why ASCTester is necessary. Prior to the test program most of what I knew about them was from staring at IDA Pro.
Many thanks!
Those ERSes were helpful to spot differences between the original ASC, EASC and the sound cell inside the Prime Time II.
Below some notes I compiled from various sources:
ASC registers:
0x800 - chip version: 0xB0 - Batman, 0xBB - Wombat, 0xBC - Sonora, 0xE0 - Elsie0x802 - chip control, not chip overflow0x803 - FIFO control0x804 - FIFO interrupt control: cleared on reads, sets interrupts on writes0x806 - Volume control: bits 7-5 set sound volume, bits 3-1 must be writable for 16-bit sound playbackBatman registers:
0xF00 - write pointer A is a 16-bit register0xF02 - read pointer A is a 16-bit register0xF04 - src time increment A is a 16-bit register0xF06 - scale factor A is written as a 16-bit register0xF08 - FIFO control A: bit 7 controls sample rate conversion, bits 0-1 determine compression kind (0 - no compression, 1- CDXA 2:1, 2 - CDXA 4:1)0xF09 - interrupt control A: bit 0 masks sound interrupts for channel A0xF20 - write pointer B is a 16-bit register0xF22 - read pointer B is a 16-bit register0xF24 - src time increment B is a 16-bit register0xF26 - scale factor B is written as a 16-bit register0xF28 - FIFO control B: bit 7 controls sample rate conversion, bits 0-1 determine compression kind (0 - no compression, 1- CDXA 2:1, 2 - CDXA 4:1)0xF29 - interrupt control A: bit 0 masks sound interrupts for channel BThere is an undocumented register at offset
0xF2E that will be read in a loop in the boot beep code. That loop finishes when 0x2C is read from this register.Below the code that test whether 16-bit FIFO exists:
# ---------------------------------------------------------------------------# Extended sound HW identification.# ---------------------------------------------------------------------------fn_FFF04EA4: lisori r4, 0x50F14000 # load ASC base address li r6, 0 # initial return value lbz r5, 0x800(r4) # read ascVersion register cmpwi r5, 0xBB # is it Batman? bne l_FFF04EE4 # return 0 if it isn't li r6, 2 # assume return value of 2 (?) lbz r5, 0x806(r4) # save current value for ascVolControl li r7, 0xEE # stb r7, 0x806(r4) # write test value 0xEE to ascVolControl eieio # lbz r7, 0x806(r4) # read back ascVolControl cmpwi r7, 0xEE # does 0xEE stick? bne l_FFF04EE0 # return 2 if it doesn't li r6, 3 # otherwise, return 3l_FFF04EE0: stb r5, 0x806(r4) # restore previous value for ascVolControll_FFF04EE4: blr # return resultIf it does exists, the extended sound FIFO (16-bit samples) will be used. The offsets are:
0x1000 - extended sound FIFO A0x1800 - extended sound FIFO BSimilar threads
