Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #235690 > unrolled thread

What does this do on a 68K-based Mac?

Back to article view | Back to alt.folklore.computers

Contents

  What does this do on a 68K-based Mac? sean@conman.org - 2026-09-22 23:28 +0000
    Re: What does this do on a 68K-based Mac? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-23 00:28 +0000
      Re: What does this do on a 68K-based Mac? John Ames <commodorejohn@gmail.com> - 2026-09-23 08:27 -0700

#235690 — What does this do on a 68K-based Mac?

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
  

[toc] | [next] | [standalone]

#235691

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 “Inside Mac Vol III” (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 “wrap around” 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?

[toc] | [prev] | [next] | [standalone]

#235692

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

> Dusts off my actual paper copy of “Inside Mac Vol III” (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 “wrap around” 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.

[toc] | [prev] | [standalone]

Back to top | Article view | alt.folklore.computers

csiph-web