Skip to main content
Home Forums Another IIci ROM hack Another IIci ROM hack
Thread

Another IIci ROM hack

Another IIci ROM hack Troubleshooting 1018 posts Jul 23, 2011 — Jan 30, 2014
Amen to that! :approve:

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 . . . :o)

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

We definitely need a PIRATE Emoticon! }:)
pirate.gifidk 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

8-) Icon/emoticon hackers rule too! ;)

For the Pirates of Silicon Valley, beige is beautiful! :o)

It'd show off the black patch better too!

Pirates do not wear beige.. >_>

Fine, but he keeps his red dot because he is a pirate. :p

pirate3.1.gif

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*

pirate3.0.gif

:lol: Gotta love 'em! Way 8-)
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! :approve:

68kMLA already rules the Mac World! [:D] ]'>

circa 1991! :o)

. . . I'm perpetually the outrider, the pentagonal peg in a round or square socketed world . . . :o)
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.

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 :)

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

You're cool as sh*t, mister. 8-)

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.

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.

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.

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!

Can't wait to see what happens, this is pretty much the holy grail of hacks to me. I've always wanted to change the start up sound.

Wait no longer :-)

It works!!! My code would have worked fine the first time if I hadn't accidentally commented that line out.


And for anyone without YouTube, you can at least hear it in action:

http://homepage.mac.com/macg3/SampledIIciStartupChime.mp3

The only limit holding me back from longer sounds is ROM space. That sound uses up about 31k of the 35k available, so to do anything much longer than that, we're going to have to look toward ROM expansion, which I believe Dennis Nedry did (right?). I suppose the other option would be to downsample a sound to 11 KHz to allow double the length, but then the sound quality starts to suffer.

I was never able to test the expanded ROM space, but I did provide the extra address lines to my larger ROM chips. I don't see any reason why it wouldn't work. If you have bigger ROM chips, I can tell you how to hook up these extra 2 address lines. We're basically limited to 2 extra address lines (4x storage space) because of the pins available on these sorts of ROMs. To go higher, we would have to make a special ROM SIMM instead of using the original locations on the logic board. Many additional address lines are available in the ROM SIMM slot.

The ROM SIMM Slot pinout for the IIci is here:

http://68kmla.org/wiki/Macintosh_IIci_RAM_and_ROM_Pathways

You can use a continuity tester to see how the address lines on the ROM chips are connected to the ROM SIMM slot. Then just use your ROM chip pinout to hook up the next two! I traced around the board and found more convenient spots to tap into these two address lines, but there's no reason why you couldn't solder wires directly from behind the SIMM slot to the extra address pins on your ROMs.

Ah, I see. Thanks for the info! Well, all the chips I have right now are the same size as the originals so I'll have to get some bigger ones. On the other hand, making a ROM SIMM sounds kind of fun too :) Decisions, decisions...

I'm going to try to get this in a usable state so others can try patching the IIci too. I'll host the necessary tools on my blog and link to it. I don't anticipate any copyright problems since the only code I'll be distributing is my own that just has to get patched over the existing ROM, but I'm not a lawyer so who knows...

That would be the coolest thing ever. :D

Here is my preliminary blog post with instructions on how to do it and the necessary ROM patches.

I may end up having to go into more detail on some of the steps, but it's a start! Again just to be clear, I don't want to break any rules on this site. I'm not distributing any copyrighted ROM images to anyone or turning this into dougg3's Mac ROM copying service; I'm just giving instructions on how people can patch their IIci ROM with whatever custom startup sound they can dream of :-)

Great hack!!

I couple years ago I discussed with someone about using the IIci ROM with an SE/30, like how the IIsi and IIfx ROMs can be used with the SE/30. The problem has always been the form-factor though since IIci's do not use a SIMM. How could a IIci ROM be transplanted to an SE/30 ROM? Any pointers on how to do it? I would be interested in helping out where I can.

3686878170_1b10d4e697_z.jpg.90a6ba74285b4ef34879fa91af58f89f.jpg


The way that Gamba and I did it was to read out the code from the IIci ROM chips and program it into PLCC32 chips. Then put those chips on a SIMM.

I desoldered the IIci's ROM chips and read the contents out with my chip programmer and programmed up a couple of sets of AT49F010, which I shipped to Gamba. He layed out and etched a ROM SIMM with the appropriate pads for the PLCC32 chips, and soldered them to the board.

Using an existing SE/30 ROM SIMM with PLCC32 chips won't work (e.g. desoldering old chips, soldering in new ones) because there's a change in pinout for the PLCC32 non-volatile memory chips between 512Kb capacity and 1 Mb capacity. The SE/30 ROMs which have PLCC32 chips use the 512Kb capacity chips and so have that pinout. The IIci code needs 1 Mb capacity chips and so if you solder them on the older ROM SIMM, the pins on the 1 Mb chips won't match the pads (signal name-wise) on the older ROM SIMM made for 512Kb chips.

I've laid out a ROM SIMM board which I could have manufactured, but I don't think I'd make my money back out of it. Also, I'm not sure whether to put all four chips on the same side of the board or not. That's how I have it laid out, but that makes it difficult to hand solder the pins of the adjacent chips. Alternatively, I could put two on each side of the board and well spread. The disadvantage to that is that if I went to a toaster oven soldering method, then I'd have the problem of components on two sides of the board.

So one design is good for hand soldering. The other design is good for toaster oven soldering.

This is actually a really opportune time for this topic to come up because I've been doing some thinking/work on making a ROM SIMM. tt, I was going to point out the ROM SIMM that trag and Gamba made, but trag beat me to it :-) I wonder if a IIci hacked ROM in an SE/30 could change its startup chime as well?

I ended up buying a 64-pin Apple ROM SIMM on eBay that had eight chips on it, each a 27C010, for a total of 1 megabyte of storage. It was for a Personal LaserWriter NT. I was going to desolder the chips from it and put in sockets. I was thinking that maybe it used that "chip select 1" or whatever on the ROM SIMM pinout, four chips per chip select line. Unfortunately, I failed to realize that the Personal LaserWriter NT has a 68000, which only has a 16-bit data bus. It was a bit of a gamble, and it didn't pay off. It did give me a physical specimen that fits the ROM SIMM slot though, so it wasn't a complete waste.

trag, I saw on Gamba's site the IIci ROM SIMM you worked with Gamba on, that's awesome! I didn't realize that you actually have a ROM SIMM laid out though! I'm actually very interested in a IIci ROM SIMM. It's a pain in the butt to change out the DIPs because they are below the hard drive/floppy drive carrier so you pretty much have to take everything out to get to them. Plus it theoretically could allow a larger ROM if I'm not mistaken. I think the biggest benefit is it makes it much easier to do something like hack the startup sound now that I know how to do it.

I have actually been laying out a board of my own for the IIci ROM SIMM. I'm not a hardware guy at all (which probably means my design is doomed to fail, lol). Aside from the struggles to connect all the address lines for all the chips together with only two layers, the biggest problem I've found is that the cheap PCB places (BatchPCB for example) only offer 63 mil thick boards, and the ROM SIMM is 47 mils thick. Is it possible to somehow file down the board near the bottom so it's only 47 mils thick there? It seems like that might have been what you and Gamba did on that SIMM?

I totally understand why it probably isn't worth the money to have it manufactured. It seems like it's just not cost effective at all for low quantities. Despite that, I'm still kind of interested in trying to make one with one of the cheap PCB places that put a bunch of board designs together and have them all manufactured. They seem fairly reasonably priced...it's the 63 mil thing that's mostly holding me back, I think.

P.S. I think I found a reasonably-priced copy of GttMFH2E on Amazon over the weekend! We'll see if it's legit!

8-o Wow! That place looks like it has VERY reasonable pricing! It could be just what the doctor ordered. Thanks for the link!
Ah yes, the Gamba/trag IIci hack...that's where I was inspired.

If there is a design out there to be made, I would be interested in putting down some cash to split the build. There are a few options out there for fabrication. Sounds like it could almost be a universal ROM package that could be used for different 68K macs for different reasons.

It would be awesome to have a PowerMac chime with a IIci ROM in an SE/30!!

. . . one design is good for hand soldering. The other design is good for toaster oven soldering.
Silly questions:

__Are you designing for a handmade ProtoPCB etching process again or for a fab house run . . . :?:

. . . if the former, I've got a couple of tricks I came up with for that process 20+ years ago. [;)] ]'>

__Are two different solder pastes available with a workable activation temperature differential? }:)

__Are two different solder pastes available with a workable activation temperature differential? }:)
I think he means through-hole vs SMT components since there are only components on one side of the board. Through-hole I am guessing might be better for this application since it would allow for the use of sockets unless there are SMT sockets for the chips that are used.

I have done one PCB design in the past, I can go about making one for this ROM SIMM (wouldn't be the most efficient for me to do it), it would be a reverse engineering from an actual ROM and based on the IIci design on Gamba's website. It would just need to be tweaked for a double sided board. I would just need some help with the selection of which chips to design the board around and have them programmed since I do not have the programming hardware.

mp.ls