• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

What Happens When These Machines Fail?

Juliet Elysa

Well-known member
I don't know if I'm using the wrong search words or just don't know what I'm looking for, but I'm curious about what happens when the Apple I, II, III and Lisa have a hardware problem that would cause a Sad Mac in later computers. I'm a very visual person so pics would be great, but they seem to be hard to find so a description of some sort would work too. :)

Thanks everyone!

 

Elfen

Well-known member
The 6502 machines were a bit more forgiving with hardware issues.

For example - On the Apple II/IIIs, if part of RAM fails, the system would only accept what RAM is left and the machine would work with the smaller RAM amount, depending on where it would fail. It usually was with 16K or 8K blocks. Thus givien an Apple II with 64K RAM:

If memory fails on the top 64K, it would default to a 48K setting.

If memory fails around 48K area, it would default to a 32K setting.

If memory fails around 32K area, it would default to a 16K setting.

If memory fails around 16K area, it would default to a 8K setting.

Now, if memory fails within this 8K area, it could default into a 4K setting or it would give a screen of jumbled characters. The most important part of memory for a 6502 machine is the Zero Page of RAM which is the first 256 Bytes of RAM. If RAM fails in this area, then the Apple (and other 6502 machines) would not be able to boot because this is the area that the CPU uses to store its registers and processor stack information. Anything above Zero Page is for the User to program, mostly taken up by the OS to the first 1K.

Other things that could fail - mostly I/O, would simply not work. If your Disk Drive Card fails, you would not be able to use your disk drives, you would be able to use the rest of the machine. Same with your other cards. Only problem here is if your Octal Buffers Chips which controls the slots - if they fail, then none of your slots would work. But that is an easy fix once you find which chips to replace.

Sometimes the Keyboard Processor Chip fails so you either get dead rows of keys or your keyboard would not work at all. And if your CPU fails, you get a screen of jumbled characters or a blank screen.

All of these issues are simple fixes once you diagnosed the problem. But there are no "Sad Mac" Code for the Apple or most 6502 machines I know of, you just need to know the symptoms effecting the machine and fix as needed.

 

Gorgonops

Moderator
Staff member
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:

nobootscreen.jpg.25f883275aa512881f943053baa55bfe.jpg


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

 
Last edited by a moderator:

Juliet Elysa

Well-known member
That all makes sense. :) When I was a kid the public library here had an old text mode computer of some sort in the children's section, and it was notorious for crashing with random gibberish like the picture when it was turned on. I remember being very amused by it... :p

 

cb88

Well-known member
My library had Dynix terminals I thought they were awesome :D .... not Dynix as in unix but Dynix as in the catalog system there are acutally still a few online you can access via telnet.

This was in the early 90's

 

Elfen

Well-known member
IIRC, the IIe and IIc have an integrated diagnostic routine (I don't know about the II and II+). I always accessed it with Control-Open Apple-Closed Apple-Reset, but the support article below suggests that you just need to hold down Closed Apple while turning on the power. 

http://support.apple.com/kb/TA38047?viewlocale=en_US
The IIe had a simple diagnostic routine, while later the //e with the 65C02 had a more complete diagnostic routines. But all three basically tested RAM, and the later tested some I/O. The II and II+ did not have this in ROM, though there was a diagnostic/repair floppy disk floating about somewhere.

The Atari XL Series also had a diagnostic test routines not found in the 400/800.

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:

nobootscreen.jpg.25f883275aa512881f943053baa55bfe.jpg


(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. 
Machines that had programable character maps (Vic 20, C64, Atari), would also display graphics instead of text as their character map pointers which would say where the character maps would be, would be pointing to some random place in RAM instead. Later graphical machines like the Atari ST and Amiga would do like the Macintosh if they could not reach the point of generating a "Sad Mac" Code.

 
Last edited by a moderator:

Juliet Elysa

Well-known member
Later graphical machines like the Atari ST and Amiga would do like the Macintosh if they could not reach the point of generating a "Sad Mac" Code.
Cool, I hadn't thought about the ST and Amiga that way. It makes a lot more sense than what I thought before... I can't even explain that.  :lol:

 

CelGen

Well-known member
Lisas have a curve of fault decoding as they turn on. The primary steps when power is applied like the reading of ROMs is basically transparent. You only know a checkpoint has been reached when the speaker clicks and the video is initialized. From there the logic boards are tested one at a time and if any faults are found you are given either a numerical code  or a numerical code and a beep code.

 

olePigeon

Well-known member
On the Apple II series computers, it had a built in hardware test.  Closed-Apple-Reset will run a motherboard and memory test.

 

Elfen

Well-known member
That's only on the IIe/IIc/IIgs. The Apple II/II+ do not have Apple Keys on the keyboard. There used to be an old diagnostic board for the older machines which went into the slot and activated by PR #[slot Number the card is in]. It does not work on the IIe/IIgs as it will get an incorrect ROM Checksum in the diagnostics.

 
Top