There are some great source level debuggers for the Mac, but all of them are programs that depend on the toolbox to interact with you and draw stuff on the screen to help you figure out what’s going wrong.  When your program is really in dire straits, and has taken the operating system down with it,  there is no substitute for a debugger that doesn’t need a working operating system.  For the pre-OSX Macintosh, this was usually Macsbug.  Macsbug was great, because it was so simple.  It didn’t draw windows or use the mouse.  You could type cryptic 2-letter commands, if you could remember them, and try understand the stuff Macsbug would type back at you.  With some luck you might find out how your program killed itself (and maybe the operating system too).  I have a couple of books on Macsbug, that I have read over and over, basically just trying to remember the commands.  I can remember some stuff, and I have used it some.  Despite my best efforts, I could never like Macsbug.  Probably, this was because I had seen something that did the same job, but was way better.

    TMON was written by Waldemar Horwat.  It was almost always used with an optional add-on, called a User Area, that was written by Darin Adler.  Both of them were just kids at the time they worked on TMON.  Darin Adler was a college student, and Waldemar Horwat had not yet finished high school.  According to Darin Adler’s account, Horwat wrote the entire thing (in assembly language), before ever trying to assemble it.  They worked for TMQ Software, a company that became famous for creating some of classic Macintosh games, “Deja Vu” (actually 2 games), “Uninvited”, and “ShadowGate”.  Horwat and Adler worked on some of the games, as well as on the TMON debugger.  The company’s name was changed to ICOM Simulations at some point, and every version of TMON I have seen was published under that name.  Both Horwat and Adler went on to distinguished careers after their work on TMON.  Darin Adler joined Apple and became the technical lead for the team that created System 7.  He also worked on the legendary Magic Cap with Bill Atkinson and Andy Hertzfeld.  Waldemar Horwat got a degree in computer science from MIT, where he worked on architectures for large scale multiprocessing.  After that, he also worked on Magic Cap for a while and did some other things, including being an architect of the javascript language.  Like lots of the Mac illuminati, he now works for Google.  He’s also an accomplished professional photographer.

Why TMON was so great.

   TMON is just an object level debugger.  Like all of such programs, it lets you examine and change arbitrary locations in memory, disassemble machine code and display it in assembly language, examine and change values in registers, set breakpoints in code, and execute code stepwise.  What made TMON special was the same thing that made the Macintosh special.  It was the user interface.  Without relying on the toolbox or other parts of the operating system, TMON created windows, menus, and used the mouse to create an amazingly mac-like approach to debugging.  Use of the mouse is special.  It is common for a crash to cause the mouse to quit working (a “mouse freeze”).  You wouldn’t expect a low level debugger to have reliable use of the mouse.  But if you find yourself in TMON after a mouse-freezing crash, you just type Command-M and... the mouse works again.  Working in the debugger using windows and the mouse was so easy that TMON somehow became more than a debugger.  It became an exploration tool for the mac system.  Try it out.  It works great in Mini vMac.  To install it, put the TMON program and TMONStartup in the System Folder and reboot.  To enter TMON, you can just run a program that crashes.  I’ve always had plenty of those around. If you don’t have one handy, just press the programmer’s switch (on a real mac) or hold down control and type i y in Mini vMac.  Your desktop is still there, but the menu bar is obscured by TMON’s simpler button bar, and two tiny windows appear, one telling you why you entered TMON (interrupt 5 if you just interrupted a working system), and one that says welcome to the Monitor and reminds you about its author.  The buttons in the bar that replaced your Mac’s menu bar will open windows when clicked.  The Dump button will open a window for examining memory.  Assembly opens a view on memory interpreted as code.  The vertical size of the windows are controlled by dragging the grow-box at the bottom right corner, and the vertical position can be adjusted by must dragging the window (from anywhere else).  The horizontal size is fixed to the full width of the display.  The windows scroll using the arrows in the scroll bar (there is no thumb).  There is a close box by each window so you can put it away when you’re finished with it.  You can have a bunch of windows open, and they can overlap.  It’s not exactly like the regular Mac user interface, but it’s close enough that you will figure it out right away.  There is a nice manual for TMON written by Paul Snivley, and it includes a technical reference by Waldemar Horwat himself.  Maybe you can find it on line somewhere.

A window on the operating system

    The Disassembly window is a great tool for just looking around.  Open one and start disassembling at position 100 (hex).

  This is the start of the famous low memory globals area.  The operating system uses about 2600 bytes starting at that location to save various pieces of information about it’s state.  The first item is the famous MonkeyLives global that is chronicled in the story of the same name on folklore.org (read that story!).  The next two give the vertical and horizontal screen resolution in pixels per inch, both of which have the value 48 (hexadecimal, 72 decimal). These are over 500 of these globals, each of which contains some key information about the state of the machine at any time.  Some of them, like the screen resolution ones, don’t change very often.  Others change a lot.  You wouldn’t think that any of them would be changing while you are looking at them in the debugger, but at least one does.  Scroll down to location 16A, (or enter that number in the “Disassembly from” field), to find the one called Ticks.  TMON updates these often enough so you can see it happen.  Of course, you are looking at these in a Disassembly window, so the value of Ticks is incorrectly interpreted as code, not as a number.  Open a Dump window, and anchor it at 16A, to see the correct value of Ticks (in hex), as time goes by. 

Disassembling your code (and others’)

  The most important purpose of the Disassembly window is to show you your executing program, and to let you step through it.  A lot of early mac programs were written in assembly language, or in C or Pascal using compilers that would give you a copy of the assembly language that they produced from your program. With this you could easily figure out what instructions arise from each line of your high(er) level code. Some compilers made code in such a straightforward way that you could pretty much do the translation in your head as you went along.  TMON can read your function and global

variable names from a symbols file (or .Map file from MDS, Consulair Mac C or TML Pascal) or from inline names. And the Motorola 68000 processor uses a set of assembly language instructions that is elegant and easily learned and remembered.  There are 16 general purpose registers, 8 intended to hold data (D0-D7), and 8 intended for memory addresses (A0-A7).  Registers are 32 bits wide.  Parentheses around a memory register are used to dereference it. To fetch a 16 bit number from a memory location whose address was in A0 and put it into a data register, you can just say MOVE.W (A0), D0.  Most instructions had a 16 bit (.W), an 8 bit (.B) and a 32 bit (.L) variant.  Stack frames are created using the LINK command and destroyed with UNLINK.  By convention on the Mac, A6 has the address of the current stack frame.  In the User Area (click the User button), you can do a stack walk and see the entire sequence of events that led to your trouble.

    The instruction set of the M68k processors was an elaboration of the legendary DEC PDP-11 instruction set.  It was symmetric, predictable, and easy to use.  This made writing Mac programs in assembly language effective and fun, and made it really easy to read other people’s executable programs in a disassembly window of the TMON debugger, or after they had been disassembled by MacNosy.  It was even possible to disassemble the Mac ROM, and see exactly what the operating system functions were doing.

This was one of the best ways to thoroughly understand why the Toolbox wasn’t doing exactly what you wanted it to do.  If your program crashes in some Toolbox call, which is common, it probably means that you passed the function some messed up parameter or an address when you should have passed a value or visa versa.  With TMON you could follow your program’s flow of control into the Toolbox to show you what you did wrong.  It also opens a window on all the code your program depends on.  The operating system, the Toolbox, libraries that you are using, are all there.  In the early Macintosh, most of these were written in assembly language.  When you look at them in TMON, you are looking at their original source code (except, of course, for comments).  If it executes, you can read it.  Nothing is hidden from you.  The entire system is an open book.

Then why not program in assembly language?

    Of course the primary reason to avoid assembly language is that Apple may abandon the processor that you are using and switch to another one that has a different instruction set.  If they did that, your entire program would have to be rewritten in the new instruction set.  You would find yourself rewriting everything from scratch.  I never would have believed they would do that, until they did.  My argument for not believing it went like this:  If they did that, they’d have to rewrite almost all of their own operating system, including the part that is in ROM on every Mac out there.  And they’d never do that, right?  Of course in 1994 Apple abandoned the m68k processor and switched to IBM PowerPC. I don’t know all the reasons.  Maybe Motorola was not committed to keeping up the m68k line themselves.  At that time they were making a lot of noise about their new Reduced Instruction Set 88000 processor, which had a new instruction set.  Or maybe Apple thought Motorola wasn’t going to be able to compete with Intel, and IBM might.  In the end, I guess, IBM didn’t keep up.  In any case, this processor switch was an eye-opener. I realized at that time that the actions of Apple could not be predicted and there was nothing so unlikely that they wouldn’t do it.  This proved true, and this was just the first of a series of Crazy Eddie moves by Apple in the 1990s.  

   Many people think that assembly language is too difficult to be practical.  Recently I read somewhere that assembly language is so simple that it is impossible.  I recognize the thread of wisdom in this statement, but I don’t think I agree.  It was definitely not true of the M68k instruction set, and the Macintosh API.  The simplicity of assembly language makes it easy to learn, and assembly code is powerful and efficient.  All the capabilities of the processor are revealed.  In some ways, assembly language is the only one that makes any sense, because it is the only one that is about a real, rather than a virtual, machine. Anyway, the m68k language was practical to use.  After all, the Macintosh Toolbox was written in assembly. 

    You know what other instruction set is pretty good?  Intel x86. Imagine Apple had switched to Intel x86, back in 1994.  I wonder what things would look like now.  Microsoft stuck with that instruction set throughout the 1990s, no matter how old fashioned it was said to be by industry pundits and university experts.  In the end this worked to the benefit of Microsoft and all Windows developers.  You know what instruction set is total crap?  Power PC. The Power instruction set from IBM was a another result of the movement to make Reduced Instruction Set Computer architectures.  The idea was that people should never read or write assembly language.  Instead, the instruction set should be designed to be optimal for compilers, without regard to symmetry or elegance, or any of the things that matter to humans.  Compilers, they said, didn’t care about any of that stuff.  As a result, all the cool new processors in the 1990s used instruction sets that would make you puke to look at them.  Those processors were made by companies that were supposed to be the next big thing, because they had embraced the next wave in computer language architecture.  These companies were DEC, Sun, IBM, and Silicon Graphics.  I guess the RISC idea didn’t actually pan out all that well.  Apple was not destroyed by having been sucked into this, but assembly language programming on Macs was a casualty.  The pure butt-ugliness of the PowerPC instruction set made assembly language programming on the Macintosh a painful experience.  PowerPC also killed the practice of reading executable code, either in debuggers or disassemblers.  Try TMON on an old mac, or an emulator, and take a look at what was lost.

   Once I moved like the wind through executable code on my Mac.  Now I can only send messages to opaque objects, and that is all. 

-- BG (basalgangster@macGUI.com)