Found a sound in Quadra 700/900 ROM, but can't extract.

[Trash80toHP_Mini]

I love this thread, great job, fascinating from a technical perspective and entertaining as well. :approve:

 

[Dennis Nedry]

To run this on your 630 and 475, make the following changes to the BootBeep control panel:

Change contents of 'mach' ID -4064 to 0xFFFF 0000

Open 'cdev' ID -4064 and change:

Address 0x14A from 0x000C 3550 to 0x000C 2722

Address 0x158 from 0x000B E2F0 to 0x000B D4C4

I don't know exactly what it does to store this in PRAM but it should at least let you try playing the sound. Also, I don't have a Centris / Quadra 610 nor the ROM file from one so I'm not sure if it has the extra sound or not. If we could get ahold of a good disassembler / assembler that updates addresses, we could probably update this control panel pretty easily to pick the right addresses based on the ROM checksum stored at ROM address 0.

These particular Macs have the easter egg image routine at the same spot as the Quadra 700, so that doesn't need to be modified. (Click the version number in BootBeep to see the image.) In Basilisk II, I get a black screen on these Macs that fades in and goes away with a mouse click. But you never know what might happen on the real hardware.

 

[Dennis Nedry]

I'm glad you're enjoying this Trash80. :beige: I think it's pretty fun too.

 

[dougg3]

Ahh...so we don't really have a way to play the 16-bit sound directly through the Quadra 700 because it only has 8-bit capability for playing sampled sounds (at least in OS 7.1)? Rats. That is cool though. I wonder if they are just sampling the compressed chime down to 8 bits in the IC, or if it actually plays as 16-bit through it.

I just checked and the Quadra/Centris 610 ROM also has the two sounds in the same spot you found it in the 630 and 475 ROMs.

Thanks for pointing out the changes necessary to the cdev! I was kind of dreading looking through the cdev code to find it. Yeah, I thought about the PRAM thing too -- I hope that spot in PRAM isn't used for anything else on other models. I'll try the modded control panel on those other machines as soon as I can.

 

[dougg3]

The LC 475 does not support the special compression mode. I *believe* it's playing the sound data as raw 8-bit unsigned samples, which is very staticy but you can still make out that there's sound data in it...

Clicking the version number causes the LC 475 to freeze.

Unfortunately I can't play with the LC 475 much more -- it's really annoying to boot because I have to use

to get the hard drive (160 MB Apple ROM Quantum ProDrive ELS) to work -- take off the cover and manually unpark the head during its self test. I'll check the Performa 630 next, and I'm not sure when I'll get to the Centris (it doesn't have a hard drive)
Edit: Exact same results with the Performa 630

 

[Dennis Nedry]

Well that's kinda sad to hear that those Macs aren't working with this.

I booted System 7.5.3 on the Quadra 700 and played the 16-bit sound file. It played fine and when I compared the recordings, I noticed some things:

- Sound control panel states 22.254 kHz, 8-bit sound output

- No visible extra resolution (i.e. 16-bit vs 8-bit) (may not be visible even if it exists, dunno)

- Visible differences from decoded version.

- decoded version played on Quadra sounds more noisy than BOTH BootBeep on Quadra and decoded version played directly (not through Quadra). I don't know what this means. It's a qualitative observation.

Gray line = original startup sound played via BootBeep on the Quadra, Black line = decoded 16-bit startup sound played through the Quadra.

 

[dougg3]

Hmmm. It's very possible that the Quadra 700 only supports playing 22.254 kHz, 8-bit samples when you feed it raw data so the Sound Manager is doing the necessary conversions. This would be similar to the IIci sound chip behavior. Could that explain the waveform difference and noise? Just an idea.

 

[Dennis Nedry]

That could be. I initially had the sound set to 22.254k and it played in the wrong tune when compared to BootBeep so I switched it to 22.050k and then it sounded right. You would think that both must be scaled up to 22.254k then.

I guess it depends on if the Mac scales the sound data to a set sample rate of 22.254k or if it actually scales the sample rate of the sound chip to the sound. Maybe the sound chip has its own clock oscillator that it can modify.

Interestingly, because the encoded sound is decoded directly inside the sound chip, and the chip seems to control its own buffering system (flags, internal shifting, etc), there must not be any intervention from any other part of the Mac to scale the sound data, at least in decompression mode. Does this mean that the sound chip runs at a sample rate "up to" 22.254 kHz, and that some command can specify a different rate? I bet that the commands that initialize the sound chip not only get it into decompression mode, but also tell it to run at 22.050kHz.

 

[Dennis Nedry]

That's quite strange that your LC 475 froze - it did not freeze for me in Basilisk II, the screen turned black and the mouse cursor faded from black back up to normal, then when I clicked the mouse, the whole thing went away. It was in 256 color mode 640x480 I think. You can try the image directly with the debugger instead of BootBeep to see if it still freezes:

G 4084F19C

According to this page, the LC 475 has the EASC chip just like the Q700:

http://support.apple.com/kb/TA32601

So it should be possible to decompress the sounds somehow. Most likely the EASC is not getting initialized properly (possible addressing difference) or the data is not coming from the right location.

The ROM I used for this was checksum 0xFF7439EE which I have documented as:

Macintosh LC 475, 575, Performa 475, 476, 575, 577, 578 or Quadra 605

Many of the chips have codenames: DFAC, Sporty, Batman... Then on the chip itself is the Apple part number. I'm pretty sure that the one we're looking for is Batman but I can only find the Sporty chip identified on the board. This chip is part S9236AK, apple part 34450113-A.

http://support.apple.com/kb/TA27980?viewlocale=en_US

When this article talks about "digital attenuators" in the Sporty chip, if they're controllable, that makes me wonder if they are responsible for the decompression response types that we figured out, and if so, the article mentions that they existed in the two "Sony ICs it replaces", which I believe refers to the original ASC, which 2 were used for stereo sound. This could potentially mean that hardware decompression is possible on older Macs.

Wouldn't it have been awesome to work at Apple back then and know what all of these code words and inside jokes meant?? Well maybe not under Steve Jobs' reign of terror!

 

[Dennis Nedry]

My god I had SUCH a hard time finding this PDF again:

http://developer.apple.com/legacy/mac/library/documentation/Hardware/Developer_Notes/Macintosh_CPUs-68K_Desktop/Mac_Quadra_700.pdf

This talks about the EASC and has diagrams as to how it's hooked up. Though this particular document does not mention "Batman", I believe that name refers to the EASC.

 

[dougg3]

Weird...I just don't know what to say about the freeze. I don't know what the color settings were during my tests, but the resolution was 640x480. The freeze was what prompted me to try the 630 so quickly, and it did the same thing. The lockup was definitely very hard on both Macs. Command-control-power key did nothing...

You're right about the 22.050/22.254 kHz thing. The Quadra 700's chip has to support SOME kind of 22.050 kHz playback, since that's the format of the compressed sound. For comparison, the LC 475's devnote says it only supports playback at 11k or 22k samples per second. (BTW, here's a link to save for reference to find all of them...sadly, the one for the original LC is broken and sends you to the LC 475 note) Figuring out this stuff is tough. From what I gather after looking at these dev notes compared to early info from Inside Macintosh and Guide to the Macintosh Family Hardware, Apple used to give more detailed hardware documentation for older machines, but then they started telling people to use their APIs and quit talking to the hardware directly, and with that, they quit giving the detailed info about the hardware. Makes sense from a compatibility standpoint, but sucks for people like us!

As for the LC 475/Performa 630 seemingly not supporting the compression algorithm, let's keep something in mind. The ROMs for all other models I've checked have the decompressed 8-bit version of the startup chime. Maybe they just cut that feature out of the sound chips used in the newer machines...otherwise you'd think they would have just used the compressed version instead. (Who knows with how things go on big projects like that though...I agree, that would be so cool to have worked at Apple back in the day with that stuff! That was totally my dream job growing up) Anyway, the LC 475 devnote I linked above seems to refer to an IC called PrimeTime that contains the sound control stuff, along with a lot of the other hardware. It also works with the DFAC II, which appears to be mostly sound input stuff. On the Quadra 630 devnote, they mention PrimeTime II and the DFAC II. Aha! So it's not a huge surprise that the LC 475 and Quadra 630 behave so similarly. Their sound ICs are closely related.

This page seems to indicate that the Quadra 700, Quadra 900, PowerBook 140, PowerBook 145B, and PowerBook 170 all have the same ROM checksum (and thus, likely, the same ROM). Maybe those models are the only ones with the required ASC support? I would be VERY curious to see (err...hear) if it worked on one of those PowerBooks.

Actually, the PowerBook 140 devnote is interesting and may have better EASC info than the Quadra 700 devnote. This might be somewhat of a missing link. Here's a quote...

Although the ASC has been enhanced, it remains plug compatible with the older ASC. The enhanced ASC no longer supports four voice synthesis (mono) or two-voice synthesis (stereo), but it does support the following features:

• record mode for sound input (together with the DFAC)
  
• hardware sample rate conversion
  
• real-time hardware decompression
  
• 8-bit final amplitude scaling registers
  
• 16-bit digital serial output
  
• 10-bit PWM (pulse-width-modulated) signal resolution at 44.1 kHz sample rate

So for a fact, they're saying the EASC doesn't support the four-voice mode that's used to generate the II-series startup chime/death chime. No big surprise there. The hardware sample rate conversion is interesting, and this also confirms the real-time hardware decompression capability Back to the 475, I'm starting to think they lied about the 475 actually having the EASC. My educated guess is they took only the subset of it that the Mac OS used and crammed it into a bigger chip with other stuff like floppy control and the VIA registers. I could be totally wrong though...

 

[zuiko21]

Wow! I've been very busy at work lately, and thus little time for hacks and/or following this interesting thread... but now I'm back to business! }

I'm still catching up with the new posts, but let me add something interesting... I'm currently "cleaning" my Q700, getting it ready for overclocking and recapping the PSU (it stunk -- literally). But I just noticed around the audio section a Philips TDA1543 IC. I know what it is! It's a pretty decent 16-bit stereo DAC fed by a serial input (I2S format) thus there might be a chance of real 16-bit audio output! The chip itself certainly supports a smaller number of bits per sample, but maybe whoever sends the serial PCM data can be hacked to supply the whole 16-bit numbers...

On the 22050 Hz support, I can't tell for sure; but playing such samples at the standard Mac rate of 22254 would be an error of less than 1 % -- a sixth of a semitone, in musical terms. Hardly noticeable, I'd say.

It's late now here and tomorrow I have many things to do... but I didn't want to go to bed without stirring the pot first

 

[Dennis Nedry]

Here is the hidden slide show in the Macintosh SE ROM, also blurred back to grayscale with 2x2 pixel motion blur.

 

[lighting]

This page seems to indicate that the Quadra 700, Quadra 900, PowerBook 140, PowerBook 145B, and PowerBook 170 all have the same ROM checksum (and thus, likely, the same ROM). Maybe those models are the only ones with the required ASC support? I would be VERY curious to see (err...hear) if it worked on one of those PowerBooks.

I can verify that the PowerBook 140 ROM is identical to the Q700 ROM. I dumped mine a while ago. Unfortunately, the computer itself has since died and fallen to pieces, so I can't test it on the actual hardware.

 

[Dennis Nedry]

Given that there's no uncompressed startup sound in this ROM, it must work. ;D

 

[Dennis Nedry]

Wouldn't it have been awesome to work at Apple back then and know what all of these code words and inside jokes meant?? Well maybe not under Steve Jobs' reign of terror!

Wait a minute - Steve Jobs was long gone when they built the Quadra 700.

 

[Lord Nightmare]

The actual encoding here is a Sony-designed ADPCM encoding called Bit-Rate Reduction ( http://en.wikipedia.org/wiki/Bit_Rate_Reduction ) designed originally for CD-XA but used on the Super Nintendo, Sony Playstation, and even the Philips CD-I to encode sample data.

Note that in hardware BRR is always calculated to saturate at +32767/-32768, and uses fixed point math for speed.

The "dead giveaway" to me that this is BRR is that "mode 1" uses 15/16ths of the previous sample.

The header packet format is:

76543210
||||\\\\__ "range" setting
||\\______ "filter" setting
\\________ unknown, unused here? (in cd-xa format one of these bits means LOOP and the other one means END I think? They're irrelevant for a fifo streamed format. It is possible that the lower of the 2 bits will select the fifth filter (filter #4) if set...)

First: take the current sample's nybble, leftshift it by 12; then rightshift it by the "range" setting.

Next, add the filtered values of the past 2 samples to the shifted sample, and clamp the result to the -32768 to 32767 range.

finally, output this resulting clamped sample, then store sample[-1] to sample[-2] and store the output sample to sample[-1]

The five filters are, on the playstation(aka psx) at least:

Filter 0: 0/64ths of sample[-1], 0/64ths of sample[-2]

Filter 1: 60/64ths of sample[-1], 0/64ths of sample[-2]

Filter 2: 115/64ths of sample[-1], -52/64ths of sample[-2]

Filter 3: 98/64ths of sample[-1], -55/64ths of sample[-2]

Filter 4: 122/64ths of sample[-1], -60/64ths of sample[-2]

The snes uses psx filters 0,1,4,3 as snes filters 0,1,2,3 respectively

The CD-I uses psx filters 0,1,2,3 as cd-i filters 0,1,2,3 respectively

(yes, I know technically the snes and cd-i came before the psx did, but psx has all 5 filters that the earlier ones used)

I whipped up a brr decoder using the first four filters that the playstation 1 uses and it seems to sound ok, though it is possible that filters 2 and 3 are wrong (and should be swapped around or swapped with filter 4, etc). I just tested this and this order the filters are in now is the only one which sounds correct. All other variant orderings of filters 2,3,4 sound badly distorted.

/* Apple(/Sony?) EASC BRR sample decoder, by Jonathan Gevaryahu AKA Lord Nightmare
* Using a bunch of code from psxAuthor's playstation emulator,
* which had been integrated with mame, in git.redump.net/mame/tree/src/emu/sound/spu.c around line 2851
* and a few lines from Dennis Nedry's decoder from 68kmla forums.
* The BRR sample format used here seems to be similar but not exactly the same as the
* format used on the SNES and PSX and CD-I etc;
* There is one format byte with the MODE and RANGE in it, but 14 packed-nybble sample bytes instead of 8
* The filters sound distorted unless they are in the order they are currently in, verified via testing.
*/

#include 

// globals
int xa_last[2] = { 0, 0 };

// filter coefficents are in 1/64ths
static const int filter_coef[5][2]=
{
{ 0,0 },
{ 60,0 },
{ 115,-52 },
{ 98,-55 },
{ 122,-60 },
};

static inline int clamp(const int v)
{
if (v<-32768) return -32768;
if (v>32767) return 32767;
return v;
}

void decode_xa_mono(const unsigned char flags, unsigned char *src, signed short *dp)
{
int i, shift, filter;
int l0=xa_last[0],
	l1=xa_last[1];
signed short d;
shift=flags&0xf,
filter=flags>>4;
int f0=filter_coef[filter][0],
	f1=filter_coef[filter][1];

for (i=0; i<28; i++)
{
	if ((i&1)==0)
		d=(src[i>>1]&0xf)<<12;
	else
		d=(src[i>>1]&0xf0)<<8;
	//fprintf(stderr, "shifted src sample %d: %04x; final: ", i, (d>>shift));
	d=clamp((d>>shift)+(((l0*f0)+(l1*f1)+32)>>6));
	//fprintf(stderr, "%04x\n", d);
	*dp++=d;
	l1=l0;
	l0=d;
}

xa_last[0]=l0;
xa_last[1]=l1;
}

int main(int argc, char **argv)
{
FILE *in, *out;
signed short decoded[28];
unsigned char packet[15];
int i;
in = fopen(argv[1], "rb");
if (!in) return 1;

out = fopen(argv[2], "wb");
if (!out) return 1;

while (fread(packet, 1, 15, in)) // Read in entire packets until EOF; this line borrowed from Dennis Nedry
{
	decode_xa_mono(packet[0], packet+1, decoded);
	//fprintf(stderr, "DEBUG: decoded pkt word 1: %04X\n", decoded[0]);
	for (i = 0; i < 28; i++)
	{
		fputc((unsigned char)(decoded[i]&0xFF), out);
		fputc((unsigned char)((decoded[i]>>&0xFF), out);
	}
}
return 0;
}

LN

 

[trag]

Very excellent work and information, LN. I have not been involved in the sound investigations, but I admire the work. Hopefully DN will be along to make use of it.

 

[Lord Nightmare]

Actually, R.Belmont pointed out that my information is not completely correct:

The EASC was designed to be able to decode CD-XA with any coefficients you wanted.

Sony's CD-XA standard (from 1988?) was the origin of the encoding known as BRR.

"FYI, the default XA coefficients in the EASC are 0x00, 0x00, 0x00, 0x3c, 0xcc, 0x73, 0xc9, 0x62. It says those are directly out of the CD-XA spec; I don't have the Yellow Book to know " - R. Belmont

Those coefficients (signed chars) correspond to the filter_coef[5][2] array in the code, coefficents [0][1], [0][0], [1][1], [1][0], [2][1], [2][0], [3][1], and [3][0] respectively. (the [4][0] and [4][1] entries are not used here)

See http://www.mess.org/mess/driver_info/easc for more info R. Belmont managed to dig up on the EASC; you can redefine the CD-XA/BRR coefficients by writing them to certain EASC registers, so you are not fixed with using the default set above.

LN

 

[dougg3]

Wow, that's good stuff. Thanks for all of that info Lord Nightmare and R.Belmont! It's exciting to see this mystery come to a close.

I'd like to point out a few things:

Then, depending on the compression type (0x0006 in this case), it writes a value into registers (ASC_BASE + $F08 and ASC_BASE + $F28) ($02 in this case, ORed with 0x80 to become $82 -- perhaps the $80 flag is a "compression enable" flag?) before using the exact same "dumb" "keep writing samples into the ASC being careful not to overflow the FIFO" algorithm that I had already traced out for uncompressed sampled sounds.

Based on the linked EASC information, I was completely right about bit 7 in those registers being the "compression enable" flag

Compression type 5 (mystery?) seems to load $81 into the ASC $F08 and $F28 registers, while compression type 6 (used by these sounds) loads $82 into those registers. Any other compression type would load plain $80 into them. So I have no idea what the lower 7 bits of those registers do, but they change based on the compression type supplied by the sound.

Also, after looking at the register info supplied, I can add that my disassembly of the ROM shows that the same default CD-XA coefficients R.Belmont listed are explicitly loaded into the EASC registers by the sound code before the chime is played.