Early 8-bit machines rarely had hardware diagnostic tests even remotely as informative as the "Sad Mac" display. When something like an original Apple II (and the Apple I is similar) powers on hardware initialization generally goes something like this:
1: The CPU is reset and begins executing ROM code pointed to by the startup vector near the top of the 6502's address space.
2: Said ROM instructs the CPU to blindly stuff initialization information into any peripherals that don't "just work" when powered on or reset.
3: Memory tests usually only start at the base of "User Memory" and are limited to a simple upward count in which a byte is written and read back; top of memory is generally set at the point where a readback returns a different value than was written.
4: At this point the CPU will then execute BASIC, check for a bootable disk, or whatever. If the disk controller or other vital peripheral is broken or memory corrupted in some way the simplistic initialization couldn't detect, well, the computer will crash into some indeterminate state and may or may not display anything at all useful in diagnosing the problem on the screen.
As Elfen notes on a 6502 machine if there's a memory fault in the first 256-512 bytes of memory (the first page after the zero page is the stack) the machine will generally just wander off into the weeds and die. Usually the BASIC interpreter and low-level OS occupies a page or three after that that probably also isn't meaningfully tested (again, remember, all the memory test in these machines usually does is "count fingers and toes" to set top of RAM) so a problem there will result in a random crash or other symptom that isn't easily summed up in a screenshot. If there's one *common* thing about early 8-bit machines that indicates a fatal hardware issue it's a screen that looks like:
(Linked from Willegal's page about diagnosing and repairing Apple IIs) On old computers that don't require their video hardware to be initialized with software to display the contents of RAM if the CPU doesn't run (for whatever reason) you'll see a frozen page of random characters; when RAM chips are initially powered on their contents will usually be random, or close to it, and the garbage screen is the video generation hardware happily interpreting the contents. You'll see screens like this on broken/halted Apple I and IIs, Commodore PETs, TRS-80 Model I/IIIs, old CP/M machines, etc; on some of these machines if you look sharp you may actually see a brief flash of a garbage screen like this on a *working* machine, depending on how late in the ROM boot process it gets around to clearing the video memory. (TRS-80 Model I's with disk interfaces actually probe the disk controller and try to boot before they clear it so it'll be onscreen for a second or two; without disk it's cleared almost instantaneously.)
So far as it goes, under some circumstances broken Macintoshes will display garbage screens like this (IE, if there's an issue with the ROMs or something they won't even be able to generate a Sad Mac.); the difference is that Mac display systems don't have a "character mode", they're always displaying graphics, so a wedged/halted CPU will just result in a display of random dots instead of characters. Again, the one point about this sort of behaviour is it depends on either the video hardware being "hardwired" so it can drive the monitor without being initialized, or the system has to crash out and die *after* it initializes said hardware. I mentioned Commodore PETs; I've repaired a 2001-N starting from a "junk screen" condition, and the nice thing about the behaviour is as you make progress in getting the thing further into booting you can generally see some results on the screen directly. Later PETs changed out a big segment of their hardwired video generation circuitry for a 6545 CRTC controller which *has* to have a few bytes of information pushed into its registers in order for the system to display anything. Therefore there's a lot more about the system that has to "work" before you'll see anything at all. Most computers built after the IBM PC would fall into that latter category. (That's one of the reasons why the lowest level diagnostics in PC machines... and Macs, for that matter, return *audio* feedback in the form of beeps/"chimes of death" for the truly showstopper issues.)