Another IIci ROM hack

[trag]

P.S. At long last my freaking DIP sockets are finally starting to loosen up. I thought I was going to destroy some of the pins on my EEPROMs when I was yanking them out with my cheapo DIP extractor tool.

You should have installed ZIF sockets...

Very cool hacking by the way.

[olePigeon]

AWESOME!!!

I have a IIci as well.

Edited: jt

[olePigeon]

Someone sticky this hack and put it on the front page. It is the coolest hack I've ever seen.

[Trash80toHP_Mini]

Copyright Warning!

DANGER, DANGER, Will Robinson!

Keep any requests for info in PM! Stickifying this is a BAD idea.

I'll have one of the other mods move it to the, 'bot-resistant, lounge too!

[olePigeon]

I'll grab my trenchcoat and meet you in the back alley.

[dougg3]

:-) You should have installed ZIF sockets...

Very cool hacking by the way.

Thanks! I considered them, but the ~$15 per socket price tag on DigiKey scared me away. On second thought it's really not that bad considering the convenience it adds...

Someone sticky this hack and put it on the front page. It is the coolest hack I've ever seen.

Gracias!

[dougg3]

I found the code that plays the LC III's startup chime and it did indeed reference the startup chime snd resource in a position-independent manner as I suspected. The code is a bit more complex than the IIci's code because it has several different code paths for different versions of the sound chip. In fact, if it finds the original sound chip from the IIci, it actually jumps to the old synthesized startup chime code! I also found some weird references to other snd resources that looked malformed -- a sampled sound with only 1 sample, and the high byte of the baseNote is 0xFE. and I didn't see anything about that in Inside Macintosh. It looks like the startup code goes to one of those weird sounds if yet a different sound chip version is found. I'm suspecting it's for the LC/LC II's startup chime, but I don't know for sure.

The good news, though, is that the sampled sound startup chime doesn't use RAM. So it should be possible to play a sampled sound without RAM. Once you get past all the complicated branching around for different sound chip versions, playing the sampled sound is pretty simple. The meat of the sound playing code is actually simpler than the IIci's synthesized sound code. You just sequentially write samples into a FIFO, and you check a register to see if there's room in the FIFO -- waiting until there's room. Hopefully that simple code is still possible with the IIci.

I wrote some test code to try to play the LC III startup chime on my IIci while booted into System 7.6 by directly accessing the sound chip registers, but it seems that the FIFO status registers act differently on different sound chips -- my program immediately hangs waiting for free space in the FIFO. If I ignore the status registers and write stuff on my own, I hear sound, but it is messed up and doesn't sound like the startup chime. I'm also wondering if the operating system is getting interrupts from the sound chip and resetting status flags before I get a chance to see them. My best bet might actually be to disassemble an old system file like from System 5 or 6 and see how it talks to the sound chip when it plays sounds.

Anyway, basically just wanted to say that sampled sounds will DEFINITELY be possible with the IIci, it's just a matter of figuring out how the sound chip wants me to talk to it!

[Trash80toHP_Mini]

We definitely need a PIRATE Emoticon!

I envy your high level of patience and your low level code hackin' acumen!

I'll just have to stick to the Block Diagram Level and make do w/rearranging chunks of hardware . . .
. . . kinda like playing Jenga.

Bits-n-Bytes are beyond me . . .

Way to go my code hackin' bro!

[dougg3]

Haha, thanks! I'm jealous of you hardware hackin' types! All the electronics knowledge is way beyond me, and I think it's impressive that you guys know all about it. I hear these terms like "bypass capacitor" and "AC coupling" and "TTL" and all this other crazy stuff and have no idea what any of it means! LOL.

[techknight]

like me pretty much. But i enjoy reading and working with you "code hacker/driver types" That I dont know much about.

Put the 2 brains together, we can make anything. I can make hardware, while you can make drivers

[Trash80toHP_Mini]

Amen to that!

I'm more of a "find the cubic to put the building blocks" from the diagrams kinda hacker. I do a little of this and a little of that, but don't really have the chops to be in either techno-camp.

My hat's off to both of you hackers . . .
. . . I'm perpetually the outrider, the pentagonal peg in a round or square socketed world . . .

Makin' connections, drawing parallels and takin'em off on tangents or wedgin'em into the cracks'd be more my kinda' thing.

[MacJunky]

We definitely need a PIRATE Emoticon!

pirate.gif (155 Bytes) Viewed 1244 times

idk how pirateish this is, there is not really much room for a hat/parrot even if you shifted it down and to the side.
Also have one in blue if the black is too much.

pirate2.gif (154 Bytes) Viewed 1244 times

[Trash80toHP_Mini]

Icon/emoticon hackers rule too!

For the Pirates of Silicon Valley, beige is beautiful!
It'd show off the black patch better too!

[MacJunky]

Pirates do not wear beige.. >_>
Fine, but he keeps his red dot because he is a pirate.

pirate3.0.gif (152 Bytes) Viewed 1233 times

pirate3.1.gif (154 Bytes) Viewed 1233 times

The upper eyepatch string looks a bit odd, but imo it looks worse if you try to make it thinner.. One might the strings at 90 degrees or something... *shrug*

[Trash80toHP_Mini]

Gotta love 'em! Way

[dougg3]

Good point techknight, we can take over the world!!!! Muahahahaha!

Haha, awesome icons! That would be a sweet Happy Mac icon to use on my IIci! (In black and white)

Back on page 1, bbraun pointed out that the Sound Driver section of Inside Macintosh: Volume II may be relevant. It is! It is!

I decided to take a step backward instead. I'm looking at a regular old Mac II ROM, because I believe it uses the exact same Apple Sound Chip that's found in the IIci. Plus, the ROM is smaller than the IIci's ROM so there's less searching involved. I located the Sound Driver in ROM, so IM: Volume II's reference may help me understand what the various functions are supposed to be doing. The book says that the sound driver is "Not in ROM", but I think it's talking about in the Mac 128k and 512k, long before the II came out.

I'm gonna figure this sucker out once and for all!

[Trash80toHP_Mini]

68kMLA already rules the Mac World!
circa 1991!

[techknight]

. . . I'm perpetually the outrider, the pentagonal peg in a round or square socketed world . . .

When I was a kid, I once watched a cartoon, it was called Darkwing Duck. You remind me of the character megavolt. He was a pentagonal peg in a square world.

[dougg3]

Eureka!

I have figured out how to play sampled sounds with the Apple Sound Chip. When I diassembled the Mac II's ROM sound driver, it helped me see how it controls the chip, but it didn't give me everything I needed. It appears that the Mac II's ROM sound driver is driven by a vertical blanking interrupt task that writes some samples into the ASC's FIFO every so often, so it doesn't use any of the FIFO status bits as far as I can tell. I could be wrong, though. I also tried disassembling an old system file, but I couldn't figure out how to find the Sound Manager in there, and I couldn't find anything writing directly into the ASC. Maybe it uses the sound driver to do its playback? No biggie though...

I started out by writing samples to the sound chip without worrying about the FIFO status bits. Instead I added some delay loops in my code to wait long enough to not fill the FIFO up completely, but not too long that the FIFO empties out completely. After a ton of trial and error compiling directly on the IIci to get the delays right, I finally found a decent combination and I was able to play the LC III & later/Performa/most Quadra series startup chime from a Mac program by writing directly to the chip. Unfortunately it would sometimes work and sometimes not -- sometimes the FIFO would end up draining, and I'd hear little crackles in the sound and stuff like that. I figured it was because of interrupts, but I wanted to get it working with the FIFO status bits rather than a cheesy time delay. The FIFO status bits are a more reliable way to tell when it's time to write more data to the chip--it'll signal when the FIFO is half empty, so you can fill it up again. Luckily the MAME/MESS project has some info on those bits.

At this point I was sick of waiting 2 minutes after every code change for the IIci to re-compile my app, so I set up my iMac G4 to do the compiling. The IIci could load the compiled program over AppleTalk quickly. Luckily my IIci has an Ethernet card This made it WAY simpler to experiment with the FIFO status bits. I got something that would sometimes work, and sometimes would hang waiting for the FIFO half-empty bit to come on (it never would). Like I said earlier, I am pretty sure this is because an interrupt is stealing the status bit from me sometimes. To test that theory, I disabled interrupts during my program, and BOOM! It worked! A perfect playback! I even took the sampled startup chime and repeated it 9 times to get a longer sound file. It played completely perfectly every time.

I am 99% sure that there is enough unused space in the IIci ROM to hold the sampled LC III startup chime! I'll see if I can make it work as a startup sound soon!

P.S. I remember Darkwing Duck! I was more into Ninja Turtles and the Nickelodeon shows like Doug and Rugrats though

[Trash80toHP_Mini]

[olePigeon]

Whoa! Are you saying you could implement a sampled startup sound into a IIci?

You're cool as sh*t, mister.

[techknight]

yup, i remember all those shows too now.

As far as playing sampled sounds, thats crazy. At least your able to control the sound chip.

Instead of disabling the interrupts, why dont you put a jump vector/hook in the VB interrupt? that way at least the computer responds while its running.

[Dennis Nedry]

The IIci can ordinarily play sampled sounds. dougg3 is cleverly making a direct hardware-level sampled sound player which can be injected into the IIci's ROM. The IIci doesn't probably have much interrupt activity yet when the startup sound plays, so it probably won't be an issue.

You are doing some very interesting stuff, dougg3. If you had a dedicated task that you wanted a IIci to do very efficiently, you could theoretically figure out the hardware and have a really zippy 100% ROM-based Mac with no operating system.

[dougg3]

Thanks guys! Yes olePigeon that's exactly what I'm saying techknight, I agree that I shouldn't disable interrupts if I were making an app other people will use...but if I were making an app I'd just use the sound manager instead. The reason I disabled interrupts was to prevent the normal Mac sound driver's interrupt from stealing the status bits from me, just so I could deduce how the chip works.

You're right Dennis Nedry--it would be possible to do some crazy stuff efficiently by directly writing to the chips...

Anyway, I refined the algorithm tonight. Now it's basically:

- Write into the FIFO until it's full
- Wait until the FIFO is half empty
- Lather, rinse, repeat until I'm out of samples

That seems to be how the original ASC was designed to be used, because that is the algorithm the status bits enable me to implement. I'm in the process of sticking it into the ROM and I should have a demo video ready tonight if all goes as planned!

It's shocking how few assembly instructions it takes. Makes me wonder why they didn't do it in the IIci

Edit: Arghhh! I put my new sound generator into the IIci ROM, and...nothing happened except the speaker clicked. The computer continued to boot just fine though, so I can't be too far off from making it work...I must be missing one of the initialization parameters that the system takes care of.

[dougg3]

BRAIN FART ALERT! BRAIN FART ALERT!

I accidentally had the line that loads the number of samples commented out. This was probably causing it to play a zero-length sound, or at least a REALLY short sound.

It's all because I'm using GNU binutils as my assembler, and it uses a different comment style than every other assembler (it uses /* C-style comments */ instead of a semicolon before the comment, along with a bunch of other wacky ideas like prefixing register names with a % sign). In my hurry to get the sound playing, I forgot to add an ending */ on one of my lines after changing the comment style over, and it commented out the entire next line, which happened to be the line that loads the number of sound samples. I thought I was going crazy!! I think that's the first time ever that too much code commenting has bitten me in the butt.

The ROM image correctly plays the sampled sound when I try it in MESS now, but I'm way too tired to take the IIci apart tonight. There's still a chance that MESS works and the actual hardware doesn't, but I bet it will work. Tomorrow (ummm, I mean later today) will be the day it happens!