From Newsgroup: alt.folklore.computers

I came across this bit of wisdom recently:

Date: Sun, 26 May 1996 02:40:10 -0700
From: Paul Snively <chewy@chelsea.ios.com>

On the Macintosh, which lacks protected memory, a popular thing to do is
to stick some magic number into location 0 so that dereferencing a null pointer or handle will crash immediately. Long ago, a friend used the
ASCII value of 'NIL!' for the purpose, but time and some real thought
about what a good value on the Macintosh really was eventually led to 0x50FFC001, which is a flawless Mac crasher value (for at least three
reasons that are left as an exercise to the reader) but unfortunately
isn't a cool legible value.

Why 0x50FFC001?

One reason: if you try to execute this, it's an Seq instruction with an undefined addressing mode, so it will trap.

Second reason: if this is an address, a 16 or 32 bit load will trap as an unaligned address.

I'm not sure what the third reason is. It's a large positive value (1,358,938,113) but other than that, it doesn't really stand out. On the 24-bit address space of a stock 68000 it probably references ROM, but a byte read should be okay? On a 32-bit address, the memory probably doesn't
exist. Would that be the third reason?

-spc

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Tue, 22 Sep 2026 23:28:01 -0000 (UTC), sean wrote:

I came across this bit of wisdom recently:

Date: Sun, 26 May 1996 02:40:10 -0700
From: Paul Snively <chewy@chelsea.ios.com>

On the Macintosh, which lacks protected memory, a popular thing to
do is to stick some magic number into location 0 so that
dereferencing a null pointer or handle will crash immediately.

Double-dereference, surely.

Long ago, a friend used the ASCII value of 'NIL!' for the purpose,
but time and some real thought about what a good value on the
Macintosh really was eventually led to 0x50FFC001, which is a
flawless Mac crasher value (for at least three reasons that are
left as an exercise to the reader) but unfortunately isn't a cool
legible value.

Why 0x50FFC001?

One reason: if you try to execute this, it's an Seq instruction with
an undefined addressing mode, so it will trap.

Second reason: if this is an address, a 16 or 32 bit load will trap
as an unaligned address.

Obviously this was in the days of the original 68000 processor, since
the later 32-bit Motorola CPUs allowed odd-addressed accesses to words
and larger.

I'm not sure what the third reason is. It's a large positive value (1,358,938,113) but other than that, it doesn't really stand out. On
the 24-bit address space of a stock 68000 it probably references
ROM, but a byte read should be okay? On a 32-bit address, the memory
probably doesn't exist. Would that be the third reason?

Dusts off my actual paper copy of rCLInside Mac Vol IIIrCY (cough, cough);
on page III-17:

The MC68000 can directly access 16 megabytes (Mb) of address
space. In the Macintosh, this is divided into four equal
sections. The first four Mb are for RAM, the second four Mb are
for ROM, the third are for the SCC, and the last four are for the
IWM and the VIA. Since each of the devices within the blocks has
far fewer than four Mb of individually addressable locations or
registers, the addresses within each block rCLwrap aroundrCY and are
repeated several times within the block.

So basically the top 8MiB were used as I/O address space. This address
must lie within some area that was not allocated to any device, and I
guess that applied to the later 68000-based machines as well: Mac
Plus and 512KE, Mac Portable, PowerBook 100, Mac Classic?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Wed, 23 Sep 2026 00:28:33 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

Dusts off my actual paper copy of rCLInside Mac Vol IIIrCY (cough, cough);
on page III-17:

The MC68000 can directly access 16 megabytes (Mb) of address
space. In the Macintosh, this is divided into four equal
sections. The first four Mb are for RAM, the second four Mb are
for ROM, the third are for the SCC, and the last four are for the
IWM and the VIA. Since each of the devices within the blocks has
far fewer than four Mb of individually addressable locations or
registers, the addresses within each block rCLwrap aroundrCY and are
repeated several times within the block.

So basically the top 8MiB were used as I/O address space. This address
must lie within some area that was not allocated to any device, and I
guess that applied to the later 68000-based machines as well: Mac
Plus and 512KE, Mac Portable, PowerBook 100, Mac Classic?

I'd have to try and dig up service manuals/etc. to be sure, but AFAIK
from the Plus on up there are third-party accelerators that can add
more than 4 MB of RAM - which suggests that the simple 4x 4MB mapping
was gone, or there'd be address conflicts with the ROM and I/O devices.
Re: the address in question, AFAIK the 68000 simply doesn't concern it-
self with the MSBs making it out to the bus; 0x50FFC001 and 0x00FFC001
are different values in one of the address registers, but to anything
outside the CPU itself they'll come out as the same address.
Earlier versions of MacOS and the Toolbox ROM exploited this by packing non-address data into the MSBs of pointers, which caused issues down
the line when they wanted to expand RAM on '020-'040 Macs - and some applications unwisely depended on that, which is why the Control Panel
applet for virtual memory also includes a switch for 32-bit addressing.
--- Synchronet 3.22a-Linux NewsLink 1.2