Jump to content

Another IIci ROM hack

Recommended Posts

  • Replies 1k
  • Created
  • Last Reply

Top Posters In This Topic

Yeah, I know....crazy prices! xx(


OK -- I'm pretty much home free at this point. I got MPW onto the IIci and wrote a simple 68k assembly program that takes my own sound definition and sends it to the same function that the startup and death chimes use.


So I can open my program with ResEdit, change the 32-byte sound definition (stored in a CODE resource), run the program, and it plays the sound! I should be able to use this tool to create some crazy sound combinations. They will definitely still sound synthesized, but it will still be cool to have something different! Then I can find some space and stick them into the ROM, and boom. New startup chime. 8-) Once I get it all working I'll do another YouTube video, and I'll figure out a way to get a ROM patch to Dennis Nedry and anyone else interested in hacking a IIci!


Right now my IIci's startup chime is the death chime arpeggio...it scares me every time I boot it up!

Link to post
Share on other sites

Very 8-)


Nice work, now all somebody needs to do is create a battery operated PIC/whatever based ROM emulator card!


What was that logic board level level serial comm setup called?




Might work for the PEx project too!


Put a DIP header on the top of the card and it'd be a general purpose development card. :o)

Link to post
Share on other sites

That's a cool idea! It would save me a ton of time when modifying the ROM, although I'd somehow need to have four of them (or one 32-bit one broken out into four 8-bit ones).


Do they make cables that can plug into DIP sockets or PLCC sockets or whatever else kinds of sockets might be used on various Mac ROMs? What kind of limitations are there on cable length before running into problems?


Googling for ROM emulator unfortunately finds a bunch of irrelevant stuff about Nintendo emulators. However if I google for EPROM emulator, I get several interesting results:






Looks like the second one answers my question about a cable that can plug into a DIP socket, and the third one answers my questions about a cable that can plug into a PLCC socket.


Wow. This stuff is EXPENSIVE!

Link to post
Share on other sites

:lol:Romulator was one of the code names we used back in '88 or '89 for the Font Emulator/Reader Project!


It was a dumb TTL Logic board with no MicroController on board. The two double sided boards inside the Sign Machine were bolted up to the (empty) Font cartridge and we used those same DIP Header Ribbon Cable Plugs to transfer the four SRAM IC's contents to the EPROM sockets on the Font Cartridges.Gates, Those two Cards and then an adapter card we needed to add on were straight TTL Logic, no MicroController at all! Cable drivers, bypass caps, 7 standard sockets and a ZIF Socket. Four were for the ribbon cables, three were for permanently placed SRAM ICs and one was placed in the ZIF socket for emulation mode and then removed for the ZIF socket to hold an EPROM for readback to a file on the PC's HDD.


The entire thing was connected by a leading a, straight, 8 bit Parallel Connection Ribbon Cable leading to an ISA Controller's connector, just like the ones on NatInt DI/O cards for the first rev. We needed to do a second rev of the ISA card and make the adapter for the Emulator Card's interface because my Hardware/Software partner told me it didn't make any difference where I put the power and ground lines. That's when I learned all about crosstalk! The second card interleaved power and ground with the signals on Ribbon Cable 50 Pin Centronics connectors I chose. The polarity was reversed from SCSI, on purpose, and the unit tested just fine on THREE 50' TelCo Twisted Pair Cables strung between the ISA card and the Emulation Unit!


After that little fiasco I started reading up on interfaces, cabling, connectors, capacitance and a lot of other hardware hackin' stuff besides crosstalk and antenna wave lengths . . .

. . . turns out I really shoulda' learned C over the course of the development too. ::)


Up to that point it was just a big graphic arts design and sign/craft project for me. I did the layout of the boards and handed off plots to my partner for markup and additional circuit notation for the next rev of the "graphic." I was able to cut silk screen stencils on my Sign Machine's 30" Drum Plotter if I weeded the AmberCut water based resist film VERY, VERY Carefully! I then pin registered the two screen printed runs of enamel ink resist on the surfaces of the Copper Clad FRP blanks, which went into Radio Shack etchant, then they went onto my bandsaw to cut the boards apart and then, finally, they went onto my drill press where I made about 64k tiny round holes through the little empty squares I'd laid out inside the rectangular copper pads!


It's too bad I lost all the leftover crap from that project in the great storage room fiasco, It sounds as if it might come in handy right about now!


Not really, a wire wrap board with a USB MicroController chiplet and a modern SRAM Package hooked up to the same kind of DIP Header cables would be a LOT easier!


The project was totally legal, whereas the Nintendo emulators were NOT. The copyright office had decided that there could be no copyrights on digital fonts because nobody can copyright the alphabet! They'd made the same determination when printing press companies tried to tie their press customers to their "copyrighted" set type fonts.


Adobe et al got the copyright office to extend copyright protection to the code that controlled the Digital Font's use. So, of course, the company that made the fonts we were emulating claimed that their cartridges contained copyrighted "code!" This was a bald faced lie, because the two of us had already cracked their font format and developed an interpreter to translate any Font for CorelDraw saved or exported as "Readable PostScript" (Type 2) and to translate and load any graphic exported from CorelDraw as the character "A" in a one letter "Font" containing up to 32k or 68k of polyline vector change DATA ONLY for loading into the Font Emulator inside the Sign Making Machines!


That was my very first "hack!" :approve:


I don't think I've ever told that entire twenty-something year old story anywhere!


Yours truly spec'd the entire project from first conception, BTW! }:)

Link to post
Share on other sites

I think you could use a microprocessor, if you hook it to the addressable bus directly instead of the nubus, and have a secondary stock ROM bank. What better place to tap into the processor bus, than the ROM slot? hehe.. just have to draw in a couple more chip select lines as you dont want the MCU address within ROMspace.


So, if you write a sample software, it could address and instruct the MCU to switch the machine over to backup ROM, while it flashes the active ROM, using a standard TSOP flash IC or something of the like.


Once the flash completes, the microcontroller could switch the active ROM back over to the flash IC, and then assert the RESET condition which will force a restart immediately after flashing. You need backup ROM like i mentioned, or the machine would probably fart at you when you suddenly "disconnected" ROM from the bus.


Or you could have a flash IC big enough to hold both ROMs, and the MCU could use an address line. When you go and flash the ROM, it will flash the unused section, and flip the active bit to point to the inactive section as active, and make the active section as inactive while the MCU asserts RESET. (toggling ROMspace).


multiple ways to do it i guess. But thats what i would do. use a flash memory control IC that is direct processor addressable so your software can access and control it, and be able to feed data in and out of the MCU IC to read the flash and write the flash while the system is up and running.


Or do it like modern computers, use the flash controller MCU to read out the flash during startup, and copy to its own shadow RAM, just perform this operation while RESET is asserted so it cannot try and boot.... therefore the machine actually runs its ROM from shadow RAM. So when you go to flash the new ROM, it doesnt affect anything. the MCU would need a memory access control layer, so when the system bus is in ROMspace, the chip knows how to translate this and point it to the shadow RAM. When the system bus directly asserts the MCU from its address location, it listens to the instructions for whatever, flash IC, read IC, etc.

Link to post
Share on other sites

Wow jt! That sounds like a cool project, at least from the bits that I can kind of understand. :) I have the opposite problem, I wish I had learned a little bit more about electrical engineering type stuff! Anyway, I'm a little curious, what is a sign making machine? Are you talking like the electronic reader boards they use when there's road construction going on, or what?


techknight: I like the ROM slot idea too! It has several advantages:


  • Others can take advantage of the hack without having to desolder the DIP ROMs (it was a pain in the butt, I'm frankly surprised I didn't rip up a pad even with the use of my vacuum desoldering gun)
  • It could add more ROM space than the standard 512k as mentioned by jt earlier.
  • It's more physically accessible, since the ROM SIMM slot is not underneath the drive bay like the DIP ROMs!


The only real disadvantage I can think of is a DIP type thing would be more reusable for future stuff. I guess one could make a SIMM to DIP adapter for that though! haha...


I think any of the approaches you mentioned would work great -- 2 flash chips or a flash chip and shadow RAM.


I also think it would be extremely cool to do this as a USB powered and controlled device with the use of a microcontroller plus a FTDI USB to UART type chip, or a microcontroller with USB support. From the software side of things, with some kind of a simple serial protocol it would be easy to make it work on Windows, Linux, and Mac. I would get a little paranoid about the device being powered over USB coming from a separate power supply than the IIci itself, though -- is there a way to prevent bad stuff from happening in that case, or is that impossible?


It would also be great if other than during programming, it could be powered only by the IIci's motherboard itself. So that way once you're done programming it over USB, you disconnect it and voila, it works every time you boot the Mac. I'm sure there's some kind of a limit on how much power can be supplied through the ROM SIMM slot, right? I wonder if the limit is enough.


Just my two cents from a hardware dummy! Burn me at the stake if I'm full of crap! ;)

Link to post
Share on other sites

< returns from woods with an armload of firewood . . . :o) >


< mod mode >


The 68kMLA is a place to LEARN/ASK questions from others for help when you're scratching your head and thinking: WTDickens do I do now!?!


The ONLY stupid question here is the one that doesn't get asked! :approve:


The mods will not tolerate any member belittling another for their "ignorance," which is the state of every comrade here, or we wouldn't have enlisted. That was the attitude during the Q&A sessions at the beginning of every monthly meeting of NYMUG, snickers from "know-it-all" types were were stomped immediately and HARD! Ignorance of the rules was not an excuse! The same holds true at LetterHead meets. (SignPainters who wish to learn from and share knowledge about the craft w/each other)


< /mod mode >


I haven't got anything even remotely similar to the EE chops of some of the members here, I'm self educated on the entire subject of electronics and computers and I've had a grand total of ONE adult ed night class on programming in Basic that I took with my (wonderful) ex on the neighborhood Middle School's TRS-80 Type IIIs.


What little I know comes from reading a LOT, asking LOTS of questions and obstinately researching ways to implement the, notoriously over the top, hack posssibilities I've suggested over the years . . .

. . . which were quite often termed totally IMPRACTICAL, if not IMPOSSIBLE! }:)

Dr. Bob and Eudimorphodon (now comrade Gorgonops AKA: EudiG) were my hackin' mentors over on 'fritter back in the day! :approve:

Thanks again for all your help along the way, comrade EudiG! :-*;):o)


As for my very first hack, I knew almost nothing about actually doing electronics when I came up with, and then suggested to my more knowledgeable friends, the notion of configuring RAM to "act like" the ROM on my font cartridges. I had a "standard," third generation, Vinyl Letter/Film Cutting and Paper Patterning Making Machine. When the MacSignMaker add-on package was released I jumped on it, simply because it was not from the company who sold the run-of-the-mill . . .

. . . if somewhat customized [;)]]'> . . . Drum Plotter/Workstation we were using.

I convinced my partner that if it didn't work as well as advertised, what really does . . . ::) . . . it would still pay for itself within a year just by computerizing the labor it took to transfer artwork/logos into the full size perforated paper patterns used in the painting process.


A year or two later, this rudimentary system was the key to the Font Emulator hardware's development process.


< swerves back on topic >


The most practical notions for a 68k USB interface I've come up with so far would be:

1) an external SCSI device

2) a card similar to the "pull the PGA CPU from its socket/moving it to the DOS on Mac Daughtercard's while installing" approach.


The former being a usable device across all SCSI equipped Macs, having readily available space, all required signals available for a ribbon cable tap, and a handy PSU connection for the ubiquitous Y Cable tap within any external drive housing and a well documented, clearly defined General Purpose, Industry Standard I/O Specification with stock PCB component availability.


The latter's most appealing quality would be its ALSO being the "perfect" spot for a multipurpose (clock multiplier enabled a/o Proc TYPE) CPU Swap Hack, Memory Hack & general I/O Hack prototyping board for '020, '030 & '040 based Macs.



Link to post
Share on other sites
techknight: I like the ROM slot idea too! /


I think any of the approaches you mentioned would work great -- 2 flash chips or a flash chip and shadow RAM.


I also think it would be extremely cool to do this as a USB powered and controlled device with the use of a microcontroller plus a FTDI USB to UART type chip, or a microcontroller with USB support. / I would get a little paranoid about the device being powered over USB coming from a separate power supply than the IIci itself, though /


It would also be great if other than during programming, it could be powered only by the IIci's motherboard itself.


You could do it over USB. the way the FTDI chips work, the USB power only powers the USB/RS232 circuit, while the IIci could power the rest, or you could also make a tap off the USB to power the rest, but i highly recommend against it, unless your going to program the mac in standby. you could use the DIP connections instead of the SIMM socket, its all the same system bus, just have to draw out the respective address/chip select lines.


You could use USB only, therefore the memory control MCU wouldnt need to be direct accessible through the system bus.


But what i was saying, you can give the memory controller MCU its own address for controlling it, and use peek/poke commands and program your ROM from within the Mac itself. But you can use both options.

Link to post
Share on other sites

Oh ok -- a sign making machine :-) I get it now. That does sound like a pretty nifty project you did. I think the most useful thing for me out of the external SCSI device category would be to somehow be able to mount a USB mass storage device as a SCSI drive. Would save me SO much time assuming PC Exchange can mount PC hard drives (I can't remember if it can...it's been so long--I just remember it could mount PC floppies)


Ah I see what you were saying techknight. I didn't realize you were talking about addressing the programming stuff from within the IIci itself. That sounds really cool! Although in the small time I've spent getting this custom startup chime stuff working, I've just about lost my mind waiting for MPW on the IIci to assemble a single, small .s file into a Mac program. I don't know how software developers in the 90's stayed sane! (Or did they?) ;) I think I'd go crazy waiting for stuff to assemble if I were modifying the ROM directly in the IIci. I guess that's why I was thinking of an external way to program it.


So...I promised I'd update when I got my own custom startup chime working. I believe I have found a safe place to put extra stuff in the ROM -- there's a huge 35k chunk of the ROM which is a repeating copyright notice, date, and some other ASCII characters. I'm assuming that it is what Apple left as the "default" for unused ROM space but who knows...anyway, it seems to work OK, so I went with it.


Without further adieu, I'd like to introduce you all to my IIci with a Super Mario Bros startup chime! I can finally back up all the talk with an actual custom startup chime!



(If there's anyone here who can't do YouTube and would like to see it, I'm open to hosting a suitable file format somewhere...)


It reboots immediately after the first Happy Mac because I don't have a PRAM battery installed -- I'm pretty sure that's why, anyway. It did that even without any ROM hacks.


Anyway, I grabbed the first few notes from the Super Mario Bros song online from some sheet music, and stuck it in the ROM! Thank you everyone for helping me get the info and motivation I've needed to get this sucker working. I'm using the wavetable synthesis mode of the Apple Sound Chip to play this sound, using the same functions that the original startup chime and the chime of death use. If it's possible to do a sampled startup chime on the IIci, I'd love to try to figure that out as well! The only restrictions I can think of are that at that point in the startup, there is no RAM, and thus I believe interrupts won't be able to work either since there's no stack. Not sure if that's a dealbreaker or if it even matters at all.


Fun stuff! I'll see if I can figure out a way to create a binary diff containing my changes from the stock ROM in case others want a Mario IIci!

Link to post
Share on other sites

The notion of using external SCSI is based upon:

it's a general purpose interface useful to connect ANY kind of device, not just mass storage . . . :approve:

the external HDD case makes a great powered hub chassis . . .

you might be able to get a second or third USB device to use a second or third SCSI ID . . .

the external case has a handy backplane for your external's external USB Connector . . .

a ZFP case gives you one honking big prototyping area . . .

it will easily house the largest Copper Clad FRP PCB blank that CrapShack is stocking ATM . . .


etc. }:)


edit: I'm ALMOST tempted to load Flash to see/hear this hack, but I still won't do it. How about posting just the Mario startup chime here?

Link to post
Share on other sites

The sound is there right at the beginning of the video -- although it is pretty faint because I recorded it on my phone.


I'll amplify it and make an MP3...


Unfortunately it won't let me upload an MP3 attachment, so here's a link:




Edit: The sound in that video was terribly faint. That's what I get for rushing to upload it at the last second before going to bed. I have deleted the first video and uploaded a new one with the amplified sound:



Is there any way a mod could change the link in my post above to this new link?


edit: done! jt

Edited by Guest
Link to post
Share on other sites

I reused the synthesizer. It's one function that both the death chime and the startup sound share. I actually call the function multiple times, once for each chord. I haven't yet figured out how to use the Apple Sound Chip in sampled mode, but I'm guessing it is possible...it might take your "bigger ROM" hack to be able to fit anything though. It appears the chip supports 22-ish and 44.1 KHz 8-bit sound.

Link to post
Share on other sites

Would it be of any help to inspect some Mac ROMs that have sampled startup sounds? I guess I'm not sure if they would have the same sound hardware or not, which could be a problem. I suppose you could find the address where the sampled sound starts in ROM and trace it back to some code and maybe get some clues.


I have a ROM dump of about every Mac ever made if you need any. I tried a few directly in my IIci. I know for sure there are others that are compatible, especially the IIfx, but I never found one with a sampled startup sound that worked.

Link to post
Share on other sites

I remember reading that the II series ROMs are compatible with each other to some extent. The IIci's sound synthesizer code actually checks the version register of the sound chip and writes differently to the volume register based on the version. I never did figure out exactly what it was doing.


Yeah, looking at the oldest possible Mac that has a sampled chime would probably be the best way to go. The chips are likely similar in behavior. I think I have a few ROM dumps as well, but do you have any idea as to what a good candidate Mac model would be? The address of the sampled chime would be a big help in that case, and I also have ROM maps of many models that might be able to help me out (included with MPW).


Very interesting that you tried other ROMs. I was curious how that would turn out!

Link to post
Share on other sites

Finding the address of the sound sample might not be too hard. When I ripped all of my lossless startup sounds, I did it by importing the entire ROM as a raw sound sample into an audio program, then adjusted things to the right settings (sample rate, bits, stereo/mono, etc) and cropped it. So I bet that the sound is stored at some very obvious starting address, like xxxx0000, which could be narrowed down significantly by trying to determine about where the sample starts in the audio program, then going back to the data and narrowing to an exact address.


I would recommend the Mac LC II or III ROM I think. They are the only 030s I am aware of that use a sampled startup sound. I'm not sure how much of an advantage it is for it to be an 030, but if an 040 is okay, I'm thinking that a Quadra 601 might be something else to try.

Link to post
Share on other sites

Ah, that's a good idea! I just tried that with Audacity. I do happen to have LC II and III ROM images. I found the LC III's sampled startup sound using that trick (8-bit unsigned, mono, 22254 Hz), but I'm not so sure about the LC II -- it's only a 512 KB ROM, so is it possible that one is still synthesized? I did find a little horn honk sound, but that sound is also in the LC III. I guess I could find out for sure by disassembling the LC II's ROM. Either way, the LC III should work, and I should be able to get a good idea of where the sound starts in the ROM from Audacity.


Apple's ROM maps for the LC II are interesting:


They have ORIGBOOTBEEP, ORIGBOOTBEEP6, and ORIGERRORBEEP1-4 which are located at the exact same offsets as they are in the IIci. Then there is also BOOTBEEP, BOOTBEEP6, and ERRORBEEP1-4 which are located way farther on in the ROM. It's almost like they left some of the II series code in there alone...interesting...did you try an LC II ROM in the IIci? I suppose I could do that too since it's not any bigger...


The LC III has all of the beep related labels that are in the LC II, as well as some other stuff like DOBEEP, BEEPERLOOP, BEEPMIXERPATCHRETURN, and BEEPMIXERDONE. I'd say those would be a good place for me to start. It's possible that they might have something to do with the sampled startup sound.


I don't think it matters that much if I look at an 040 instead of an 030, so I could take a look at those too if the LC III doesn't get me anywhere.

Link to post
Share on other sites

OK -- I listened to some of the chimes with Mactracker. It seems that the LC and LC II have the same startup chime (and it's the same as the startup chime for the Classic II). So I'm pretty sure the sampled startup chime coincides with having a ROM that's 1 MB or bigger.


I tried an LC II ROM image in my IIci just now, and nothing happened other than the fan turning on. So even though the ROM includes some of the sounds from the IIci, it apparently doesn't use them at all. Not all that surprising that it didn't work, but It's interesting that they left the old sounds in there...


The sampled sound in the LC III begins at offset 0xC67BE -- that's where the beginning of the 'snd ' header is. I went ahead and deciphered the header, and it's 31,178 samples long with a sample rate of about 22.254 KHz.


The LC III's ROM is mapped at 0x40800000. I didn't see any direct references to the sound header's address in the ROM, but that doesn't mean anything because addresses to most of the things in the IIci's ROM were loaded with a program-counter-relative offset. That would make sense because it makes the ROM position-independent in case they decided to map it elsewhere at the last second or whatever. I did find several references to the Apple Sound Chip's address, though, so that will give me some clues.


One thing that concerns me is that these Macs with larger ROMs have some soldered motherboard RAM. I'm hoping that the startup chime function isn't using RAM in these, because it might be more difficult to get it to work in the IIci. The IIci doesn't have any RAM set up when it plays the startup chime -- everything is passed around in registers, and it seems fairly standard that when you go to a subroutine, you put the address it should return to in A6 before jumping to it. I'm hoping that they did a similar thing in the LC III.


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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...