Another IIci ROM hack

[bbraun]

I did take a look at Inside Macintosh: Sound (Apple seems to have PDFs of it -- google for site:developer.apple.com "IM: S"), but it is talking about the Mac toolbox, and I didn't see anything about talking directly to the sound chip.

IM Volume II's Sound Driver section may be relevant.

Although the toolbox routines are not available, the device driver should exist in ROM and you might be able to call it directly. Or at least look up where it resides, and see what it is doing. It's documented as being element 3 of the unit table.

 

[dougg3]

Awesome! The potential for this hack is unbelievable. I know it's just changing the startup sound, but I've always wanted to do that. I'm just not a left-brain person, so a lot of these concepts are just beyond me. Probably why I have a liberal arts degree.

I know, I always wanted to change it too! I guess that's why I'm so interested in this hack. It won't be very flexible as to what it can be changed to, but it was within my hardware hacking capabilities, so why not?

So, does the ROM have separate cords, then you modify the ROM to change which cord and how long it plays?

That's pretty much it! Here's a more detailed explanation: there's a function Apple wrote in the ROM that is used for playing sounds at startup. You can give it 1 to 4 notes to play, along with a few delay values. Once it plays the first note, it waits for how long you tell it to, and then starts playing the second note (but leaves the first note playing as well). Then it does the same with the third note, and so on. The delay between each note is the same, so you can't have a long delay between two notes and then a shorter delay between the next two. Then it will leave all the notes playing for some time, which is another parameter you can set. I guess you could chain multiple calls to this function together to play whatever you want -- that's how Apple plays the death chime which starts with a chord (first function call with a very small delay between notes) and then plays another arpeggio building up to a second chord (second function call, has a longer delay between notes so you can hear them one-by-one).

Out of curiosity, would it be possible to modify the ROM so that later generation G4 Macs could natively boot OS 9?

Unfortunately those newer Macs use all kinds of craziness like Open Firmware which I know pretty much nothing about. There are probably software limitations as well in the operating system, but who knows...anyway, that's beyond my technical knowledge. Sorry!

IM Volume II's Sound Driver section may be relevant.Although the toolbox routines are not available, the device driver should exist in ROM and you might be able to call it directly. Or at least look up where it resides, and see what it is doing. It's documented as being element 3 of the unit table.

I'll take a look -- thanks! I have a PDF of that edition, and I also have hardcopy books on the way -- I've turned into an old Mac development book freak!

I actually finally figured out what more of the sound data means thanks to a few pages from a book on wavetable synthesis thanks to Google Books and also the MAME source code which mentioned that the Apple Sound Chip interprets wavetable phases/increments in a binary fixed-point 9.15 format. The boot sound code is setting up the increment value for the next available voice each time a new note is played. That final piece of information cracked the code for me and I am pretty sure I now know how to choose what notes to tell it to play. I looked at the death chime arpeggio and calculated the sound frequencies, getting:

110 Hz, 137.5 Hz, 165 Hz, and 220.5 Hz.

That is pretty much dead on with an A major chord. As soon as I got almost exactly 110 on the first calculation, I knew I was in business. A2 is 110 Hz, C#3 is 138.6 Hz, E3 is 164.8 Hz, and A3 is 220 Hz.

Finding room to play more than one of these things in a row might be kind of tough, although I seem to recall the IIci's ROM has a picture stored in it somewhere, so I might be able to wipe out the hidden picture and put in some startup sound fun instead. We'll see! I might be able to hack my IIci to play the birthday song at startup or something goofy like that.

 

[Trash80toHP_Mini]

You firmware guys are talking way over my pay grade! It's all Greek . . . maybe even Sanscrit . . . to this old dog!

Silly KnuckleDraggerROMhardwareHacker™ questions: (Gots ROM emulator developer chops! Not too shabby for a B.A./Liberal Arts :lol: )

Is there a IIci ROM SIMM/DIMM available?

_____If so, can it address more ROM Memory Space than is implemented on the MoBo or SIMM/DIMM hardware?

The Portable has room in its memory map for gonzo ROM expansion . . . how about the IIci? :?:

-- I've turned into an old Mac development book freak!

Welcome to the club, doug! :approve:

< . . . decides to read up on the IIci in GttMFH2E . . . : >

 

[dougg3]

This thread with an interesting back-and-forth between Dennis Nedry and trag should answer #2

As for #1, the same thread shows that it's been done before by designing a custom SIMM, but as far as I know IIci ROM SIMMs are not readily available.

Haha yeah glad to be part of the classic Mac book club! I'd buy my own copy of GTTMFH but it's absolutely ridiculous how much it costs on all the used book websites.

 

[Trash80toHP_Mini]

:lol: It seems that I stuck my nose into that thread too! Thanks for the lead, I was heading to gamba to look for ROM PCB layouts . . . mostly because GttMFH appears to be AWOL, ATM. I'd vaguely remembered trag mentioning that he'd worked on a ROM SIMM with gamba, but I wasn't sure if it was a IIci or SE/30 assembly that I'd snagged from there.

TTFN

 

[Trash80toHP_Mini]

BINGO! [] ]'>

GttMFH2E[/b]"]The Macintosh IIci contains four 1 Mbit ROM ICs on the main logic board, forming a 32-bit-wide data bus and providing 512 KB of ROM. The Macintosh IIci also has a 64-pin SIMM socket for upgrading or expanding ROM.

[] ]'>

 

[dougg3]

Ah, yes. It would be really interesting to stick a sampled sound into extra ROM space obtained by using a big ROM SIMM and somehow play it. I know the ASC can do it. Anyway, that's an idea for a time far, far away! :beige:

 

[Trash80toHP_Mini]

Guide to the Macintosh Family Hardware [Paperback]

Apple Computer Inc. (Author)

Available from these sellers.

7 used from $117.33

8-o

 

[dougg3]

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. 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!

 

[Trash80toHP_Mini]

Very

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

 

[dougg3]

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:

http://www.sparetimegizmos.com/Hardware/EPROM_Emulator.htm

http://secure.transtronics.com/osc/product_info.php/cPath/56/products_id/329

http://www.emulation.com/catalog/off-the-shelf_solutions/emulator_tools/pal-eprom_emulator_adapters/

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!

 

[Trash80toHP_Mini]

: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! }

 

[techknight]

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.

 

[dougg3]

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!

 

[Trash80toHP_Mini]

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

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

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.

 

[techknight]

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.

 

[dougg3]

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!

 

[Trash80toHP_Mini]

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?

 

[techknight]

I cant hear anything in your video?

 

[dougg3]

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:

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

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