Be more sensible with how much RAM we put into application space on boot

Detail:
  s/NewReset - During ROM init, keep application space mostly empty instead of attempting to move all RAM into it. This prevents the page order from being reversed, ensuring that in systems with two or more memory speeds the ROM modules get to use the fast RAM instead of the slow RAM (see free pool initialisation logic in InitDynamicAreas)
  After ROM module init, rebalance memory between the free pool and application space so that they each get 50%. This will provide plenty of memory for the boot sequence and any single-tasking stuff (e.g. booting into BASIC), without starving the free pool of memory and breaking any background processes like USB.
Admin:
  Tested on BB-xM
  Fixes issue where USB devices would fail to initialise properly on some systems due to the boot sequence temporarily locking application space while the free pool is empty


Version 5.35, 4.79.2.225. Tagged as 'Kernel-5_35-4_79_2_225'

VersionASM

@@ -13,11 +13,11 @@
                         GBLS    Module_ComponentPath
 Module_MajorVersion     SETS    "5.35"
 Module_Version          SETA    535
-Module_MinorVersion     SETS    "4.79.2.224"
-Module_Date             SETS    "30 Apr 2014"
-Module_ApplicationDate  SETS    "30-Apr-14"
+Module_MinorVersion     SETS    "4.79.2.225"
+Module_Date             SETS    "07 May 2014"
+Module_ApplicationDate  SETS    "07-May-14"
 Module_ComponentName    SETS    "Kernel"
 Module_ComponentPath    SETS    "castle/RiscOS/Sources/Kernel"
-Module_FullVersion      SETS    "5.35 (4.79.2.224)"
-Module_HelpVersion      SETS    "5.35 (30 Apr 2014) 4.79.2.224"
+Module_FullVersion      SETS    "5.35 (4.79.2.225)"
+Module_HelpVersion      SETS    "5.35 (07 May 2014) 4.79.2.225"
                         END

VersionNum

@@ -5,19 +5,19 @@
  *
  */
 #define Module_MajorVersion_CMHG        5.35
-#define Module_MinorVersion_CMHG        4.79.2.224
-#define Module_Date_CMHG                30 Apr 2014
+#define Module_MinorVersion_CMHG        4.79.2.225
+#define Module_Date_CMHG                07 May 2014
 
 #define Module_MajorVersion             "5.35"
 #define Module_Version                  535
-#define Module_MinorVersion             "4.79.2.224"
-#define Module_Date                     "30 Apr 2014"
+#define Module_MinorVersion             "4.79.2.225"
+#define Module_Date                     "07 May 2014"
 
-#define Module_ApplicationDate          "30-Apr-14"
+#define Module_ApplicationDate          "07-May-14"
 
 #define Module_ComponentName            "Kernel"
 #define Module_ComponentPath            "castle/RiscOS/Sources/Kernel"
 
-#define Module_FullVersion              "5.35 (4.79.2.224)"
-#define Module_HelpVersion              "5.35 (30 Apr 2014) 4.79.2.224"
+#define Module_FullVersion              "5.35 (4.79.2.225)"
+#define Module_HelpVersion              "5.35 (07 May 2014) 4.79.2.225"
 #define Module_LibraryVersionInfo       "5:35"

s/NewReset

@@ -1324,11 +1324,11 @@ WallopDuffOnes
         BL      DynArea_Create          ; ignore any error, we're stuffed if we get one!
         Pull    "r0-r12"
 
-        LDR     R0, =(AplWorkMaxSize-32*1024):SHR:12    ; maximum number of pages in aplspace
+        LDR     R0, =(1024*1024):SHR:12 ; 1MB of RAM in aplspace should be plenty for ROM init. Theoretically we don't need any at all, but having some there should make it easier to debug any ROM init failures.
         MOV     R3, #32*1024            ; aplwork start
         LDR     R1, =ZeroPage+AplWorkSize ; aplwork size
         MOV     r11, #AP_AppSpace
-        BL      FudgeConfigureRMA       ; put as much as possible in aplspace
+        BL      FudgeConfigureRMA       ; put some memory in aplspace
 
         LDR     R0, =ZeroPage
         LDR     R1, [R0, #AplWorkSize]
@@ -1727,6 +1727,24 @@ SkipHardResetPart2                      ; code executed on all types of reset
         CMP     r1, #SoftReset          ; a softie?
         SWINE   XOS_WriteI+7            ; go beep! Yaay!
 
+; Now that ROM modules have mostly finished allocating memory, move a large
+; chunk of the free memory from the free pool into application space so that
+; the boot sequence and configured language have something to play around with
+; (particularly if booting into BASIC!)
+; However be careful not to move everything, otherwise anything which locks
+; application space during boot could cripple important background processes
+; like USB
+        Push    "r1"
+        LDR     r0, =ZeroPage
+        LDR     r1, [r0, #AplWorkSize]
+        LDR     r0, [r0, #FreePoolDANode+DANode_Size]
+        SUB     r1, r1, #32*1024
+        SUB     r1, r1, r0
+        MOV     r1, r1, ASR #1          ; 50% each sounds fair
+        MOV     r0, #ChangeDyn_FreePool
+        SWI     XOS_ChangeDynamicArea
+        Pull    "r1"
+
         CMP     r1, #PowerOnReset
         BNE     %FT75