_ReadXPRam
/_WriteXPRam
actually work
Offset (hex) | Length (dec) | Related to |
1 | 1 | Used by a system program _InternalWait
|
8 | 4 | Looks like the last 4 bytes of the regular PRAM (See IM, Vol II, OS Util) |
10 | 16 | Looks like the first 16 bytes of the regular PRAM (See IM, Vol II, OS Util) |
78 | 4 | Startup Disk info (apparently, SCSI id) |
7C | 2 | System Beep. As was pointed out earlier, it is
in fact an id (short int ) of the corresponding
'snd ' resource in the System file;accessed through the Sound control panel |
7E | 1 | Used by a system program _InitProcMenu
|
7F | 1 | Apparently it has something to do with the way windows and dialogs appear on the screen |
80 | 2 | Used by a system program _GetVideoDefault apparently, some default video settings |
82 | 6 | Hilite Color, apparently in the RGB format, set up through the Color control panel |
8A | 1 | Bit field: Memory/cache control flags
|
AF | 1 | Has something to do with the RAM disk size
|
B8 | 4 | A 32-bit field whose
|
BD | 33 | looks like the name of the default AppleTalk zone (in Str32 format)Used (and set!) by some system programs in ROM ,
|
DE | 2 | at addresses 8009d544 and 8009d73C
|
E0 | 4 | has something to do with the network: an AppleTalk active/inactive flag, and the selected network access (say, LocalTalk
or EtherTalk). See Chooser and Network control panel |
E4 | 12 | Latitude/Longitude of the place this Mac is at. Set up through the Map control panel |
Saving and Restoring xPRAM
Applications/Control panels/Extensions that can save the current xPRAM
settings, and restore them at a later moment:
PRAM
, and apparently all (or a part of) xPRAM
, although xPRAM
is not mentioned by name.
xPRAM
given the field's offset
and length
:
D0
contains 0
(no error) or -1
(failure: say, the offset
is not within the 256-byte xPRAM
).xPRAM
: set the offset
to 0
and the length
to 256
. Note, some old Mac models (II's and IIx's) had a bug in their ROM that prevents from writing the very last byte of xPRAM
(offset=255
).
using C/C++ on a 68k Mac
To read size
bytes of the xPRAM
into a (previously allocated) buffer where
, starting from the beginning of xPRAM
:
asm{}
inlines in C++ code. So I had to code in hex...
Writing to xPRAM
is similar to reading, only one has to use trap A052
rather than A051
. The following function writes size
bytes from a buffer where
into xPRAM
, starting at offset
:
How _ReadXPRam/_WriteXPRam do their job
Here's an insight (gained from tracing A051
/A052
traps in MacsBug):
these traps use some sort of serial (bit-by-bit) interface to access the clock chip, via the bus address 0x50f00000
(or something like this).
How did I find out the
Traps xPRAM
layout_ReadXPRam
/_WriteXPRam
are not documented, let alone the xPRAM
.
I figured the stuff out by messing around with MacsBug: I restarted the system, and dropped into the debugger as soon as I could. I set breaks on traps A051
(_ReadXPRam
) and A052
(_WriteXPRam
), and let the system go on booting and run. I played with all control panels and watched if setting/resetting some values ends up in the debugger. There, a mere peek at the contents of D0
will tell everything: the location (byte-offset) in xPRAM
that is being read/written is in the lower-order word of D0
, and the size of the data is in the high-order-word. This is exactly the way I reengineered the xPRAM
map (well, I also disassembled a few control panels, e.g., Sound, Cache, and Memory)