Common Problems with RISC OS 3.7 Developer Softload
---------------------------------------------------

"Error: This !Boot structure is only suitable for RISC OS 3.70 or later":

This is a problem which got "lost in the noise" when the build was being
made; !Boot.!Boot and !Boot.!Run both check for the presence of
UtilityModule 3.70 when starting up. As the softload ROM image doesn't get
loaded until after this point, the system won't start unless you either
comment the appropriate RMEnsure lines out or change the version number
required to 3.60 or 3.50 as necessary.

Strange system behaviour on RISC OS 3.7 startup; *unplug shows random
important modules unplugged:

RISC OS 3.70 has different CMOS allocation parameters to RISC OS 3.5 or 3.6;
having booted RISC OS 3.7 for the first time, you really need to do a
delete-power on to get the CMOS into the 3.7 default configuration. On
future cold boots, RISC OS 3.5 or 3.6 will "survive" through the confusion
of looking at a 3.7 CMOS configuration for long enough to get 3.7
bootstrapped, which is all that is needed.

System hangs on cold-booting RISC OS 3.7:

Some problems have been seen involving third-party cards which contain
user-configurable CMOS of their own; in the case of a popular SCSI card, for
example, the card will boot from RISC OS 3.5 or 3.6 into 3.7 on the very
first occasion that 3.7 is booted, but the configuration the card needs to
be put into to make it work correctly and with full functionality on RISC OS
3.7 prevents it from working with RISC OS 3.5 or 3.6 during subsequent
from-cold 3.7 bootstrap phases. Currently, the only definite way to get
things working is to yank the card in question. 

"Abort on data transfer" or other data abort messages on startup immediately
following RISC OS 3.7 installation:

Problems such as this are generally traceable to CMOS issues; having this
message displayed (rather than anything more sensible) indicates a problem
with MessageTrans. RMKill MessageTrans, enter BASIC and issue SYS"OS_Reset"
to get into a state where you can start using RMReinit to set all unplugged
modules back to active status.