GitLab

OS_DynamicArea 27 is the same as OS_DynamicArea 5 ("return free
memory"), except the result is measured in pages instead of bytes,
allowing it to behave sensibly on machines with many gigabytes of RAM.

Similarly, OS_DynamicArea 28 is the same as OS_DynamicArea 7 (internal
DA enumeration call used by TaskManager), except the returned size
values are measured in pages instead of bytes. A flags word has also
been added to allow for more expansion in the future.

Hdr:OSMem now also contains some more definitions which external code
will find useful.

Version 6.29. Tagged as 'Kernel-6_29'

Version 6.28. Not tagged

This change adds a new OS_Memory reason code, 23, for reserving memory
without actually assigning it to a dynamic area. Other dynamic areas can
still use the memory, but only the code that reserved it will be allowed
to claim exclusive use over it (i.e. PageFlags_Unavailable).

This is useful for systems such as the PCI heap, where physically
contiguous memory is required, but the memory isn't needed all of the
time. By reserving the pages, it allows other regular DAs to make use of
the memory when the PCI heap is small. But when the PCI heap needs to
grow, it guarantees that (if there's enough free memory in the system)
the previously reserved pages can be allocated to the PCI heap.

Notes:

* Reservations are handled on an honour system; there's no checking that
the program that reserved the memory is the one attempting to map it in.

* For regular NeedsSpecificPages DAs, reserved pages can only be used if
the special "RESV" R0 return value is used.

* For PMP DAs, reserved pages can only be made Unavailable if the entry
in the page block also specifies the Reserved page flag. The actual
state of the Reserved flag can't be modified via PMP DA ops, the flag is
only used to indicate the caller's permission/intent to make the page
Unavailable.

* If a PMP DA tries to make a Reserved page Unavailable without
specifying the Reserved flag, the kernel will try to swap it out for a
replacement page taken from the free pool (preserving the contents and
generating Service_PagesUnsafe / Service_PagesSafe, as if another DA
had claimed the page)

Version 6.28. Tagged as 'Kernel-6_28'

Detail:
Similar to HeapReason_GetAligned, GetSkewAligned is used for allocating
aligned blocks (with optional boundary limit). However instead of using
the logical address of the user portion of the block for the alignment
calculation, it uses an arbitrary offset specified in R5. This makes
it useful for clients such as the PCI module, which care about the
physical alignment of blocks rather than logical alignment.

Admin:
Tested with heaptest

Detail:
This adds a new OS_DynamicArea reason code, 26, for adjusting
AplWorkMaxSize at runtime. This allows compatibility tools such as
Aemulor to adjust the limit without resorting to patching the kernel.
Any adjustment made to the value will affect the upper limit of
application space, and the lower limit of dynamic area placement.
Attempting to adjust beyond the compile-time upper/default limit, or
such that it will interfere with existing dynamic areas / wimpslots,
will result in an error.

Relevant forum thread:
https://www.riscosopen.org/forum/forums/11/topics/14734

Admin:
Tested on BB-xM, desktop active & inactive

Version 6.24. Tagged as 'Kernel-6_24'

Add a new reason code, OS_Memory 22, equivalent to OS_Memory 14, but
accepting a 64-bit physical address in r1/r2. Current ARM architectures can
only express 40-bit or 32-bit physical addresses in their page tables
(depending on whether they feature the LPAE extension or not) so unlike
OS_Memory 14, OS_Memory 22 can return an error if an invalid physical
address has been supplied. OS_Memory 15 should still be used to release a
temporary mapping, whether you claimed it using OS_Memory 14 or OS_Memory 22.

The logical memory map has had to change to accommodate supersection mapping
of the physical access window, which needs to be 16MB wide and aligned to a
16MB boundary. This results in there being 16MB less logical address space
available for dynamic areas on all platforms (sorry) and there is now a 1MB
hole spare in the system address range (above IO).

The internal function RISCOS_AccessPhysicalAddress has been changed to
accept a 64-bit physical address. This function has been a candidate for
adding to the kernel entry points from the HAL for a long time - enough that
it features in the original HAL documentation - but has not been so added
(at least not yet) so there are no API compatibility issues there.

Requires RiscOS/Sources/Programmer/HdrSrc!2

This is facilitated by two extended calls. From the HAL:
* RISCOS_MapInIO64 allows the physical address to be specified as 64-bit

From the OS:
* OS_Memory 21 acts like OS_Memory 13, but takes a 64-bit physical address

There is no need to extend RISCOS_LogToPhys, instead we change its return
type to uint64_t. Any existing HALs will only read the a1 register, thereby
narrowing the result to 32 bits, which is fine because all existing HALs
only expected a 32-bit physical address space anyway.

Internally, RISCOS_MapInIO has been rewritten to detect and use supersections
for IO regions that end above 4GB. Areas that straddle the 4GB boundary should
also work, although if you then search for a sub-area that doesn't, it won't
find a match and will instead map it in again using vanilla sections - this is
enough of an edge case that I don't think we need to worry about it too much.

The rewrite also conveniently fixes a bug in the old code: if the area being
mapped in went all the way up to physical address 0xFFFFFFFF (inclusive) then
only the first megabyte of the area was actually mapped in due to a loop
termination issue.

Requires RiscOS/Sources/Programmer/HdrSrc!2

ControlList_Interlaced is taken to have meant "output interlaced sync on H/V" and "configure DMA to show alternate lines in the framestore on alternate fields", therefore SyncPol flags mean:
b43
 00 = 'normal' progressive scan
 01 = interlaced sync, but both fields show the same image
 10 = (invalid)
 11 = interlaced sync, fields use alternate lines from the image

Version 6.21. Tagged as 'Kernel-6_21'

Detail:
  s/vdu/legacymodes - Make the Service_ModeExtension implementation automatically use ExtraBytes to request that the row length is a multiple of a word (since things fail with non-word aligned rows)
  hdr/VIDCList - Un-deprecate SyncPol bits 2 & 3 and improve the comments to indicate the difference between SyncPol interlace and control list interlace
Admin:
  Tested on BB-xM


Version 6.17. Tagged as 'Kernel-6_17'

Detail:
  Over the years the OS's substitute screen mode selection logic has grown to be a tangled mess, and the logic it does implement isn't always very useful. Additionally, the kernel is structured in such a way that it can be hard for modules to override it.
  This set of changes aims to fix the many of the problems, by doing the following:
  - Moving all substitute mode selection logic out of the core VDU driver code and into a Service_ModeTranslation handler. This means you now only have one place in the kernel to look instead of several, and modules can override the behaviour by claiming/blocking the service call as appropriate.
  - Moving handling of the built-in VIDC lists out of the core VDU driver code and into a Service_ModeExtension handler. This means programs can now inspect these VIDC lists by issuing the right service call (although you are essentially limited to lists which the GraphicsV driver is OK with)
  - Moving *TV interlace & offset adjustment logic into the Service_ModeExtension handler, since they're legacy things which can be handled more cleanly for MDF/EDID (and the old code was poking memory the kernel didn't own)
  - Adding a Service_EnumerateScreenModes implementation, so that if you end up in the desktop with ScreenModes non-functional, the display manager at least has something useful to show you
  - Enhancing the handling of the built-in numbered modes so that they are now available in any colour depth; the Service_ModeExtension handler (and related handlers) treat the builtin VIDC lists as a set of mode timings, not a discrete set of modes
  - Substitute mode selection logic is a complete re-write. Instead of trying a handful of numbered fallback modes, it now tries:
    - Same mode but at higher colour depths
    - Same mode but at lower colour depths
    - Alternate resolutions (half-width mode with no double-pixel if original request was for double-pixel, and default resolution for monitor type)
  - Combined with the logic to allow the builtin VIDC lists to be used at any colour depth, this means that the kernel should now be able to find substitute modes for machines which lack support for <=8bpp modes (e.g. OMAP5)
  - Additionally the mode substitution code will attempt to retain as many properties of the originally requested mode as possible (eigen values, gap mode type, etc.)
  Other improvements:
  - The kernel now actually vets the builtin VIDC lists instead of assuming that they'll work (which also means they'll have the correct ExtraBytes value, where applicable)
  - The kernel now uses GraphicsV 19 (VetMode2) to vet the mode during the mode switch process, using the result to detect where the framebuffer will be placed. This allows for GraphicsV drivers to switch between DA 2 and external framestores on a per-mode basis.
  - The kernel now supports mode selectors which specify LineLength values which are larger than necessary; this will get translated to a suitable ExtraBytes control list item (+ combined with whatever padding the driver indicates is necessary via the VetMode2 result)
  File changes:
  - hdr/KernelWS - Reserve space for a VIDC list, since the Service_ModeExtension implementation typically can't use the built-in list as-is
  - s/Arthur3 - Issue Service_ModeFileChanged when the configured monitor type is changed, so that DisplayManager + friends are aware that the set of available modes has changed
  - s/GetAll - Fiddle with GETs a bit
  - s/MemMap2 - Extra LTORG
  - s/NewIRQs - Small routine to install/uninstall false VSync routine (previously from PushModeInfo, which wasn't really the appropriate place for it)
  - s/Utility - Hook up the extra service call handlers
  - s/vdu/legacymodes - New file containing the new service call implementations, and some related code
  - s/vdu/vdudecl - Move mode workspace definition here, from vdumodes
  - s/vdu/vdudriver - Remove assorted bits of mode substitution code. Plug in new bits for calling GraphicsV 19 during mode set, and deal with ExtraBytes/LineLength during PushModeInfo
  - s/vdu/vdumodes - Move some workspace definitions to s/vdu/vdudecl. Tweak how the builtin VIDC lists are stored.
  - s/vdu/vduswis - Rip out more mode substitution code. Issue Service_ModeFileChanged when monitor type is changed by OS_ScreenMode.
Admin:
  Tested on Raspberry Pi 3, Iyonix, IGEPv5


Version 6.14. Tagged as 'Kernel-6_14'

Detail:
  ECFIndex and PalIndex claim to be mode variables, but it's impossible for extension modes to specify their values.
  Since they're easy to calculate from the ModeFlags and Log2BPP values, drop them from the mode workspace (+ table of builtin modes) and calculate them on the fly instead.
  File changes:
  - hdr/KernelWS - Drop ECFIndex & PalIndex from workspace
  - s/vdu/vdumodes - Adjust workspace definition, drop ECFIndex & PalIndex values from VWSTAB
  - s/vdu/vdudriver - Remove now-redundant copy loop from ModeChangeSub. Remove code from GenerateModeSelectorVars that sets up the ECFIndex & PalIndex values on the stack
  - s/vdu/vdugrafl - Adjust copy loop in SwitchOutputToSprite/Mask
  - s/vdu/vdupalette, s/vdu/vdupalxx - Add GetPalIndex routine to generate PalIndex on the fly. Drop the obsolete 16bpp palette/gamma table and shuffle the other entries to simplify GetPalIndex a bit.
  - s/vdu/vduplot - Add GetECFIndex routine to generate ECFIndex on the fly. Also, fix things so that mode 0 isn't the only rectangular-pixel mode which uses the special rectangular-pixel ECF patterns (index 0 vs. index 4). Fiddle with ExportedHLine a bit to avoid an out-of-range ADR.
  - s/NewReset - Fix UAL warning for MOV R0, AppSpaceStart. Adjust memset to not assume 512KB is the correct amount
Admin:
  Tested on Raspberry Pi 3


Version 6.11. Tagged as 'Kernel-6_11'

Detail:
  hdr/Options - The setting of the SMP switch can now be controlled by specifying the correct ASFLAGS, e.g. ASFLAGS="-PD \"SMP SETL {FALSE}\""
Admin:
  Untested


Version 6.08, 4.129.2.10. Tagged as 'Kernel-6_08-4_129_2_10'

Detail:
  hdr/VduExt:
  - Introduce mode variable 13, for specifying the minimum number of screen banks that are guaranteed to be available. Eventually the kernel will make use of this during mode vetting & selection, to give programs a simple and reliable way of selecting banked screen modes. Currently however it's only supported by VideoOverlay and the corresponding GraphicsV overlay APIs.
  - Extend the mode flags to allow display rotation & flipping to be specified. This is used to indicate that the framebuffer accessed by the CPU is not in the same orientation as what the user is seeing. Again, currently this is only supported by VideoOverlay and the corresponding GraphicsV overlay APIs.
Admin:
  Tested on OMAP3, OMAP4


Version 6.06. Tagged as 'Kernel-6_06'

Detail:
Admin:


Version 6.05. Tagged as 'Kernel-6_05'

Detail:
  The error block checks introduced in Kernel-5_35-4_79_2_313 are generating a few too many false positives and edge cases, so take the safe option of just disabling them rather than trying to tweak the rules further. Error pointers will still be checked, but the content of the error blocks will not.
  hdr/Options - Add CheckErrorBlocks switch so we can easily turn the code back on again in the future if necessary
  s/Kernel - Switch out all the code relating to error number checks, except for the dummy load of the first word of the error block, since that's still useful as a pointer validity check
  hdr/KernelWS - Revise SWIDespatch_Size definition so it's easier for it to cope with the various factors which may affect the despatcher size
Admin:
  Tested on PandaBoard
  Relevant discussion:
  https://www.riscosopen.org/forum/forums/11/topics/11133


Version 6.04. Tagged as 'Kernel-6_04'

Version 6.03. Tagged as 'Kernel-6_03'

Detail:
  Resolve allocation clash for vector &2C.  It appears that RISCOS Ltd used
  this vector in RISC OS 6 without getting it allocated - they really should
  have known better, since Hdr:RISCOS has always one of the header files
  centrally managed and coordinated between the two forks of RISC OS.
  Resolved by moving SeriousErrorV to &2D since it is a relatively recent
  addition (April 2016) and hasn't yet featured in a stable RISC OS 5
  release.
  Also correct some comments elsewhere in Hdr:RISCOS.


Version 6.01. Tagged as 'Kernel-6_01'

The kernel has no interest in Ethernet, and this prototype is tightly bound to 1 specific platform, so move it to EtherTH's exports instead.
Makefile tidied.

Newly born boards have all 0xFF's in their CMOS (EEPROM), but the new order of keyboard scan did
  Init -> Scan keyboard -> Check (or wipe) CMOS
and would therefore leave 0xFF's in a select few kernel workspace areas and OS_Byte values.
Defer the init which reads CMOS until after the check/wipe step. Only the screen area size is now done early, but MassageScreenSize clamps that properly anyway.

Arthur3.s: Relocate stranded function SetupPrinterBuffer to osinit.
PMF/key.s: Drop support for SoftReset.
PMF/osinit.s: Stuff in hardcoded defaults at early init. Retrieve the proper ones later. Take ownership of SystemSprite/RamFS/Font Manager dynamic areas (deferrable).
vdudriver.s: Use symbolic name.
NewReset.s: Defer SystemSprite/RamFS/Font Manager area creation, MouseInit, Read(Hard)CMOSDefaults until later.
hdr/Options: Delete unused IgnoreVRAM. Remove MaxRAMFS_Size now PMPs make it not useful. Shuffle ARM6Support/XScaleMiniCache/XScaleJTAGDebug to be adjacent to their definitions.

Tested by filling first 256 bytes with 0xFF and powering up. Reset now completes, OS_Byte variables look sensible.

Version 5.95. Tagged as 'Kernel-5_95'

Detail:
  s/MemInfo, hdr/KernelWS - Rather than peeking L2PT to determine if the compatibility page is enabled, use a workspace var to track its state. This ensures we won't get confused if other software decides to map something of its own to &0.
  s/NewReset - Ensure the CompatibilityPageEnabled flag is initialised correctly
Admin:
  Tested in Iyonix ROM softload


Version 5.90. Tagged as 'Kernel-5_90'

Detail:
  To make it easier to support arbitrary complexity keyboard controllers (eg. USB via DWCDriver on the Pi) have the kernel do the early keyboard recovery key press detection instead of the HAL.
  During the first pass those modules used for reading the keyboard are started, ignoring the CMOS frugal bits.
  The keyboard is then scanned for 3s, during which time the RAM is cleared (unless the HAL indicated it has already been done).
  During the second pass the remaining modules are started respecting the CMOS frugal bits. Any which were already started in the first pass are inserted into the new chain, so the keyboard is reset once and only once.

  Boot times, with a 300cs key scan time in NewReset.
  Risc PC with 160MB RAM (128+32+0).
  Times from turning on power to initial "beep", using a stopwatch.
                RISC OS 3.70 RISC OS 5.22 This OS
  ARM610        12.5         10.4         10.3
  ARM710        11.8         10.2         9.7
  StrongARM 233 11.1         9.5          8.4

  In NewReset.s:
  Remove old KbdScan code (leave Reset_IRQ_Handler for IIC only)
  If HAL_KbdScanDependencies returns a null string then present KbdDone flag and skip to full init.
  A few vestiges of soft resets removed.
  Do RAM clear when waiting for INKEY (being careful not to trash the running modules...).
  Clearing just the freepool on a 2GB Titanium cleared 7EFD6 pages (99.2%).

  In ModHand.s:
  2nd pass need to sneaky renumber the nodes (so *ROMModules is in the right order, frugal bits line up) without resetting the chain

  In HAL.s:
  Change ClearPhysRAM to ClearWkspRAM, such that it only clears the kernel workspace rather than all RAM. The bulk of the RAM is cleared during the keyboard scan by new function ClearFreePoolSection.
  Add a variant of Init_MapInRAM which clears the mapped in RAM too (as these very early claims will not be in the free pool when the RAM is cleared later).
  Remove HAL keyboard scan setup & IRQ handler.
  Fix bug in HALDebugHexTX2, the input value needs pre-shifting by 16b before continuing.

  In GetAll.s, PMF/osbyte.s:
  Use Hdr:Countries and Hdr:OsBytes for constants.

  In PMF/key.s, PMF/osinit.s:
  Relocate the key post init from PostInit to KeyPostInit.
  Changed PostInit to not tail call KeyPostInit so they can be called independently.

  In hdr/KernelWs:
  Improve comments, add InitWsStart label to refer to.

  In hdr/HALEntries:
  Add HAL_KbdScanDependencies.
  Delete KbdFlag exports.
  Took the opportunity to reorder some of the higher numbered HAL entries and re-grouping, specifically (112,120) (84,106,108,117).
Admin:
  Tested on an ARM6/ARM7/SA Risc PC, BeagleBoard xM, Iyonix, Pandaboard ES, Wandboard Quad, IPEGv5, Titanium, Pi 2 and 3.
  Requires corresponding HAL change.
  Submission for USB bounty.

Version 5.89. Tagged as 'Kernel-5_89'

Version 5.87. Not tagged

Detail:
  When HiProcVecs is enabled, there will now be a read-only page located at &0 in order to ease compatibility with buggy software which reads from null pointers
  Although most of the page is zero-filled, the start of the page contains a few words which are invalid pointers, discouraging dereferencing them, and a warning message if the memory is interpreted as a string.
  On ARMv6+ the page is also made non-executable, to deal with branch-through-zero type situations
  OS_Memory 20 has been introduced as a way of determining whether the compatibility page is present, and also to enable/disable it
  File changes:
  - hdr/Options - Add CompatibilityPage option
  - hdr/OSMem - Declare OS_Memory reason code 20
  - hdr/KernelWS - When CompatibilityPage is enabled, make sure nothing else is located at &0
  - s/NewReset - Enable compatibility page just before Service_PostInit (try and keep zero-tolerance policy for null pointer dereferencing during ROM init)
  - s/MemInfo - OS_Memory 20 implementation. Add knowledge of the compatibility page to OS_Memory 16 and 24.
Admin:
  Tested on BB-xM


Version 5.87. Tagged as 'Kernel-5_87'

Add OS_Memory 19, which is intended to replace the OS_Memory 0 "make uncacheable" feature, when used for DMA

Detail:
  Making pages uncacheable to allow them to be used with DMA can be troublesome for a number of reasons:
  * Many processors ignore cache hits for non-cacheable pages, so to avoid breaking any IRQ handlers the page table manipulation + cache maintenance must be performed with IRQs disabled, impacting the IRQ latency of the system
  * Some processors don't support LDREX/STREX to non-cacheable pages
  * In SMP setups it may be necessary to temporarily park the other cores somewhere safe, or perform some other explicit synchronisation to make sure they all have consistent views of the cache/TLB
  The above issues are most likely to cause problems when the page is shared by multiple programs; a DMA operation which targets one part of a page could impact the programs which are using the other parts.
  To combat these problems, OS_Memory 19 is being introduced, which allows DMA cache coherency/address translation to be performed without altering the attributes of the pages.
  Files changed:
  - hdr/OSMem - Add definitions for OS_Memory 19
  - s/MemInfo - Add OS_Memory 19 implementation
Admin:
  Tested on Raspberry Pi 3, iMx6


Version 5.86, 4.129.2.3. Tagged as 'Kernel-5_86-4_129_2_3'

Detail:
  This commit lays some of the groundwork for SMP support within the HAL, kernel, and OS.
  Makefile, hdr/HALDevice, hdr/DBellDevice - Add definitions for a doorbell HAL device, to allow CPU cores to signal each other via interrupts
  hdr/HALEntries - Repurpose HAL_Matrix and HAL_Touchscreen entry points for new SMP-related entry points. Add a couple of IRQ-related definitions.
  hdr/KernelWS - Boost MaxInterrupts to 256
  hdr/Options - Add new SMP build switch to control whether the kernel is built in SMP-friendly mode or not. SMP-friendly kernels should still run on single-core machines, but may behave slightly differently.
  s/ARMops - Make as many ARMops SMP-safe as possible, relying on hardware support for broadcasting of cache/TLB maintenance operations
  s/ExtraSWIs - Make SMP-friendly full OS_SynchroniseCodeAreas only sync application space and the RMA (full-cache IMB not really possible with SMP)
  s/NewIRQs - Update IRQ despatcher comments to (hopefully) reflect reality
  Docs/SMP/HAL, Docs/SMP/IRQ - Add documentation covering the new HAL calls and IRQ behaviour
Admin:
  Tested on Raspberry Pi 2, 3, OMAP4, iMX6


Version 5.86, 4.129.2.2. Tagged as 'Kernel-5_86-4_129_2_2'

Detail:
Admin:
  tested on iMx6 revD1 and revC2

Version 5.86. Tagged as 'Kernel-5_86'

Detail:
  The ExtraBytes control list item can be used to add padding between framebuffer rows.
  When the kernel sees a VIDC list containing this item, it will now adjust the LineLength and ScreenSize mode variables accordingly, with the end result that the correct amount of memory will be allocated for the framebuffer and the OS will render into it correctly.
  Files changed:
  - hdr/KernelWS - Add DisplayLineLength variable to allow the correct LineLength value to be preserved when screen output is redirected to a sprite
  - s/vdu/vdudriver - Make ModeChangeSub initialise DisplayLineLength before calling SwitchOutputToSprite. Update PushModeInfo to take ExtraBytes into account when calculating LineLength and ScreenSize.
  - s/vdu/vdugrafl - Adjust SwitchOutputToSprite to use DisplayLineLength when restoring screen output
  - s/vdu/vduwrch - Fix full-screen CLS to not write to the padding bytes
Admin:
  Tested on Raspberry Pi 3


Version 5.82. Tagged as 'Kernel-5_82'

Version 5.81. Tagged as 'Kernel-5_81'

To account for ARM changing their minds about how to clear the exclusive lock on different architectures, provide a function pointer with a known good implementation. This is similar to the run of NOPs returned by OS_PlatformFeatures 0 for those that need it.
If in the future any errata or similar are needed, then there's only 1 place to change it, plus clients don't need their own CPU type detection logic.

Version 5.77. Tagged as 'Kernel-5_77'

Detail:
  s/vdu/vdugrafl, s/vdu/vduttx - Adjust initialisation & shutdown of TTX workspace to fix workspace being erroneously freed/reinitialised when redirecting output to a sprite
  s/vdu/vdugrafk - If ScreenLoad needs to load one row at a time (e.g. when graphics window width != sprite width), allocate a block from the RMA instead of assuming that ScrLoaBuffer is large enough
  hdr/KernelWS - Get rid of ScrLoaBuffer, and shrink LargeCommon to a suitable size. Frees about 2K of VDU workspace.
  s/GetAll - Move Hdr:Sprite earlier in list of GETs
Admin:
  Tested on Raspberry Pi


Version 5.75. Tagged as 'Kernel-5_75'

Detail:
  This set of changes:
  * Adds support for the T, TX and TY mode string elements (as per RISCOS Ltd)
  * Adds support for entering arbitrary-resolution teletext modes by using mode selector blocks with the Teletext mode flag set
  * ScrRCol and ScrBRow mode variables can be provided in the mode selector in order to restrict the number of text rows/columns in teletext modes (as per RISCOS Ltd)
  * If the rows / columns are restricted in this manner then the text window will be centered on the screen, to try and avoid things looking too ugly (no variable text scaling implemented)
  * For HiResTTX, all colour depths >= 4bpp are now supported by teletext. This essentially makes the TTX256 switch obsolete.
  * If the "native" mode 7 is unavailable then the kernel will try a series of fallback resolutions & colour depths in an effort to find a combination that works
  Known bugs/issues:
  * Teletext column count has a max limit of 255 due to TTXDoubleCounts being a byte array
  * If there's a border around the text window, the border will not be refreshed when changing transparency modes using a VDU 23,18,0 sequence
  * ScreenLoad looks like it can overflow the LargeCommon buffer (no buffer size check) - needs fixing before LargeCommon can be safely shrunk below (Old)TTXMapSize
  File changes:
  - hdr/KernelWS - Make CharWidth non-conditional. Adjust handling of teletext workspace; it's now allocated from the system heap to allow it to cope with arbitrary screen sizes
  - s/vdu/vdu23 - Make CharWidth non-conditional
  - s/vdu/vducursoft - Make CursorTeletext cope with arbitrary colour depths, make CharWidth non-conditional, remove hard-coded teletext values
  - s/vdu/vdudriver - Deal with teletext workspace allocation during ModeChangeSub. Deal with selecting teletext modes (and validating colour depth) in GenerateModeSelectorVars.
  - s/vdu/vdugrafl - Make CharWidth non-conditional. Calculate offset required for text window centering.
  - s/vdu/vdumodes - Remove TTX256
  - s/vdu/vduswis - Try other teletext modes if native mode 7 not available. Extend OS_ScreenMode reason codes to cope with teletext mode strings.
  - s/vdu/vduttx - Update to use dynamic workspace. Replace various hardcoded values with variable lookups. Update character plotting + colour/palette selection to work with true-colour modes if HiResTTX.
  - s/vdu/vduwrch - Move some useful code into a subroutine. Update FastCLS to cope with true-colour teletext. Update AddressR0R1 to cope with text window centering offset. Make CharWidth non-conditional.
Admin:
  Tested on Raspberry Pi, BB-xM
  VDU 23,18,0 in 256-colour teletext now works correctly (previously 64-colour mode was in use, causing palette update to be ruined by VIDC1-mangling)


Version 5.74. Tagged as 'Kernel-5_74'

Detail:
  hdr/OSMisc, s/ARMops - Don't expose the new ARMops via OS_MMUControl 2, they haven't been fully tested/developed yet
Admin:
  Builds, untested


Version 5.73. Tagged as 'Kernel-5_73'

Detail:
  Modern ARMs (ARMv6+) introduce the possibility for the page table walk hardware to make use of the data cache(s) when performing memory accesses. This can significantly reduce the cost of a TLB miss on the system, and since the accesses are cache-coherent with the CPU it allows us to make the page tables cacheable for CPU (program) accesses also, improving the performance of page table manipulation by the OS.
  Even on ARMs where the page table walk can't use the data cache, it's been measured that page table manipulation operations can still benefit from placing the page tables in write-through or bufferable memory.
  So with that in mind, this set of changes updates the OS to allow cacheable/bufferable page tables to be used by the OS + MMU, using a system-appropriate cache policy.
  File changes:
  - hdr/KernelWS - Allocate workspace for storing the page flags that are to be used by the page tables
  - hdr/OSMem - Re-specify CP_CB_AlternativeDCache as having a different behaviour on ARMv6+ (inner write-through, outer write-back)
  - hdr/Options - Add CacheablePageTables option to allow switching back to non-cacheable page tables if necessary. Add SyncPageTables var which will be set {TRUE} if either the OS or the architecture requires a DSB after writing to a faulting page table entry.
  - s/ARM600, s/VMSAv6 - Add new SetTTBR & GetPageFlagsForCacheablePageTables functions. Update VMSAv6 for wider XCBTable (now 2 bytes per element)
  - s/ARMops - Update pre-ARMv7 MMU_Changing ARMops to drain the write buffer on entry if cacheable pagetables are in use (ARMv7+ already has this behaviour due to architectural requirements). For VMSAv6 Normal memory, change the way that the OS encodes the cache policy in the page table entries so that it's more compatible with the encoding used in the TTBR.
  - s/ChangeDyn - Update page table page flag handling to use PageTable_PageFlags. Make use of new PageTableSync macro.
  - s/Exceptions, s/AMBControl/memmap - Make use of new PageTableSync macro.
  - s/HAL - Update MMU initialisation sequence to make use of PageTable_PageFlags + SetTTBR
  - s/Kernel - Add PageTableSync macro, to be used after any write to a faulting page table entry
  - s/MemInfo - Update OS_Memory 0 page flag conversion. Update OS_Memory 24 to use new symbol for page table access permissions.
  - s/MemMap2 - Use PageTableSync. Add routines to enable/disable cacheable pagetables
  - s/NewReset - Enable cacheable pagetables once we're fully clear of the MMU initialision sequence (doing earlier would be trickier due to potential double-mapping)
Admin:
  Tested on pretty much everything currently supported
  Delivers moderate performance benefits to page table ops on old systems (e.g. 10% faster), astronomical benefits on some new systems (up to 8x faster)
  Stats: https://www.riscosopen.org/forum/forums/3/topics/2728?page=2#posts-58015


Version 5.71. Tagged as 'Kernel-5_71'

Add new ARMops. Add macros which map the ARMv7/v8 cache/TLB maintenance mnemonics (as featured in recent ARM ARMs) to MCR ops.

Detail:
  - Docs/HAL/ARMop_API - Document the new ARMops. These ops are intended to help with future work (DMA without OS_Memory 0 "make temp uncacheable", and minimising cache maintenance when unmapping pages) and aren't in use just yet.
  - hdr/Copro15ops - Add new macros for ARMv7+ which map the mnemonics seen in recent ARM ARMs to the corresponding MCR ops. This should make things easier when cross-referencing docs and reduce the risk of typos.
  - hdr/KernelWS - Shuffle kernel workspace a bit to make room for the new ARMops
  - hdr/OSMisc - Expose new ARMops via OS_MMUControl 2
  - s/ARMops - Implement the new ARMops. Change the ARMv7+ ARMops to use the new mnemonic macros. Also get rid of myDSB / myISB usage from ARMv7+ code paths; use DSB/ISB/etc. directly to ensure correct behaviour
  - s/HAL - Mnemonic + ISB/DSB updates. Change software RAM clear to do 16 bytes at a time for kernel workspace instead of 32 to allow the kernel workspace tweaks to work.
Admin:
  Binary diff shows that mnemonics map to the original MCR ops correctly
  Note: Raspberry Pi builds will now emit lots of warnings due to increased DSB/ISB instruction use. However it should be safe to ignore these as they should only be present in v7+ code paths.
  Note: New ARMops haven't been tested yet, will be disabled (or at least hidden from user code) in a future checkin


Version 5.68. Tagged as 'Kernel-5_68'

Detail:
  On Cortex-A53, a load/store exclusive instruction will abort if it targets non-cacheable memory or if the D-cache is disabled. Since the correct operation of these instructions is important to the OS and apps, it makes sense to prevent *Cache Off / OS_MMUControl 0 from being able to disable the D-cache on such systems.
  hdr/OSMisc, s/ARMops - Add new OS_PlatformFeatures 0 flag to indicate when disabling of the D-cache isn't allowed
  s/VMSAv6 - Update MMUControl_ModifyControl to force the D-cache to always be on when the "unsafe to disable D-cache" PlatformFeatures flag is set. Also, disallow mismatched I+D cache settings if we have an L2 cache (causes issues due to IMB ops only flushing to PoU), and fix dangerous D-cache invalidation when it's only the I-cache which is being disabled
  s/ARM600 - Clean up MMUControl_ModifyControl a bit so that it's a closer match to the VMSAv6 version, and fix the dangerous D-cache invalidation.
Admin:
  Tested on ARM11, Cortex-A7, Cortex-A53


Version 5.62. Tagged as 'Kernel-5_62'

Detail:
  This set of changes:
  * Refactors page table entry encoding/decoding so that it's (mostly) performed via functions in the MMU files (s.ARM600, s.VMSAv6) rather than on an ad-hoc basis as was the case previously
  * Page table entry encoding/decoding performed during ROM init is also handled via the MMU functions, which resolves some cases where the wrong cache policy was in use on ARMv6+
  * Adds basic support for shareable pages - on non-uniprocessor systems all pages will be marked as shareable (however, we are currently lacking ARMops which broadcast cache maintenance operations to other cores, so safe sharing of cacheable regions isn't possible yet)
  * Adds support for the VMSA XN flag and the "privileged ROM" access permission. These are exposed via RISC OS access privileges 4 and above, taking advantage of the fact that 4 bits have always been reserved for AP values but only 4 values were defined
  * Adds OS_Memory 17 and 18 to convert RWX-style access flags to and from RISC OS access privelege numbers; this allows us to make arbitrary changes to the mappings of AP values 4+ between different OS/hardware versions, and allows software to more easily cope with cases where the most precise AP isn't available (e.g. no XN on <=ARMv5)
  * Extends OS_Memory 24 (CheckMemoryAccess) to return executability information
  * Adds exported OSMem header containing definitions for OS_Memory and OS_DynamicArea
  File changes:
  - Makefile - export C and assembler versions of hdr/OSMem
  - Resources/UK/Messages - Add more text for OS_Memory errors
  - hdr/KernelWS - Correct comment regarding DCacheCleanAddress. Allocate workspace for MMU_PPLTrans and MMU_PPLAccess.
  - hdr/OSMem - New file containing exported OS_Memory and OS_DynamicArea constants, and public page flags
  - hdr/Options - Reduce scope of ARM6support to only cover builds which require ARMv3 support
  - s/AMBControl/Workspace - Clarify AMBNode_PPL usage
  - s/AMBControl/growp, mapslot, mapsome, memmap - Use AreaFlags_ instead of AP_
  - s/AMBControl/main, memmap - Use GetPTE instead of generating page table entry manually
  - s/ARM600 - Remove old coments relating to lack of stack. Update BangCam to use GetPTE. Update PPL tables, removing PPLTransL1 (L1 entries are now derived from L2 table on demand) and adding a separate table for ARM6. Implement the ARM600 versions of the Get*PTE ('get page table entry') and Decode*Entry functions
  - s/ARMops - Add Init_PCBTrans function to allow relevant MMU_PPLTrans/MMU_PCBTrans pointers to be set up during the pre-MMU stage of ROM init. Update ARM_Analyse to set up the pointers that are used post MMU init.
  - s/ChangeDyn - Move a bunch of flags to hdr/OSMem. Rename the AP_ dynamic area flags to AreaFlags_ to avoid name clashes and confusion with the page table AP_ values exported by Hdr:MEMM.ARM600/Hdr:MEMM.VMSAv6. Also generate the relevant flags for OS_Memory 24 so that it can refer to the fixed areas by their name instead of hardcoding the permissions.
  - s/GetAll - GET Hdr:OSMem
  - s/HAL - Change initial page table setup to use DA/page flags and GetPTE instead of building page table entries manually. Simplify AllocateL2PT by removing the requirement for the user to supply the access perimssions that will be used for the area; instead for ARM6 we just assume that cacheable memory is the norm and set L1_U for any L1 entry we create here.
  - s/Kernel - Add GetPTE macro (for easier integration of Get*PTE functions) and GenPPLAccess macro (for easy generation of OS_Memory 24 flags)
  - s/MemInfo - Fixup OS_Memory 0 to not fail on seeing non-executable pages. Implement OS_Memory 17 & 18. Tidy up some error generation. Make OS_Memory 13 use GetPTE. Extend OS_Memory 24 to return (non-) executability information, to use the named CMA_ constants generated by s/ChangeDyn, and to use the Decode*Entry functions when it's necessary to decode page table entries.
  - s/NewReset - Use AreaFlags_ instead of AP_
  - s/VMSAv6 - Remove old comments relating to lack of stack. Update BangCam to use GetPTE. Update PPL tables, removing PPLTransL1 (L1 entries are now derived from L2 table on demand) and adding a separate table for shareable pages. Implement the VMSAv6 versions of the Get*PTE and Decode*Entry functions.
Admin:
  Tested on Raspberry Pi 1, Raspberry Pi 3, Iyonix, RPCEmu (ARM6 & ARM7), comparing before and after CAM and page table dumps to check for any unexpected differences


Version 5.55. Tagged as 'Kernel-5_55'

hdr/AHCIDevice:
  Remove this, since it clashes with the (differing API version number) copy exported by SATADriver. Post merging the Kernel back to the trunk the newer file datestamp has meant the wrong one gets exported during any ROM build which includes both components. Since the Kernel doesn't need AHCIDevice itself, it is left to the respective client (SATADriver or AHCIDriver in this case) to export them.
hdr/ModHand:
  Resolve the longstanding clash of Module_Title with the same named symbol that CMHG uses. There are very few assembler needing to look at the module header (Kernel, FileCore, Debugger, Podule) directly, but every C module which uses CMHG and wants one of the ModHandReason values ends up with a duplicate define.
  Obsolete Arthur era Module_LoadAddr value.
ArthurSWIs.s/MoreComms.s/NewReset.s/SWINaming.s/SysComms.s/Utility.s:
  Module_Title->Module_TitleStr.
ModHand.s:
  Module_Title->Module_TitleStr.
  Recode Module_LoadAddr using the file type from Hdr:FileTypes.
GetAlls.s:
  Drop unused NVRAM and PortMan headers. Add Hdr:FileTypes.

Version 5.54. Tagged as 'Kernel-5_54'

Detail:
  hdr/Options - Reduce the scope of SASTMhatbroken and InterruptDelay switches so that they're only enabled when we're building for ARMv4 targets
  s/ARM600, s/VMSAv6, s/ExtraSWIs, s/Exceptions - Move duplicate code out of s/ARM600 & s/VMSAv6 and into shared locations. OS_UpdateMEMC, the bulk of OS_MMUControl, and OS_SynchroniseCodeAreas are now located in s/ExtraSWIs. Meanwhile the data & prefetch abort veneers have been moved to the new file s/Exceptions. s/ARM600 and s/VMSAv6 are now almost purely to do with the different page table formats.
  s/GetAll - GET s/Exceptions
Admin:
  Tested on Raspberry Pi


Version 5.52. Tagged as 'Kernel-5_52'

Detail:
  This change gets rid of the following switches from the source (picking appropriate code paths for a 32bit HAL build):
  * FixCallBacks
  * UseProcessTransfer
  * CanLiveOnROMCard
  * BleedinDaveBell
  * NewStyleEcfs
  * DoVdu23_0_12
  * LCDPowerCtrl
  * HostVdu
  * Print
  * EmulatorSupport
  * TubeInfo
  * AddTubeBashers
  * TubeChar, TubeString, TubeDumpNoStack, TubeNewlNoStack macros
  * FIQDebug
  * VCOstartfix
  * AssemblingArthur (n.b. still defined for safety with anything in Hdr: which uses it, but not used explicitly by the kernel)
  * MouseBufferFix
  * LCDInvert
  * LCDSupport
  * DoInitialiseMode
  * Interruptible32bitModes
  * MouseBufferManager
  * StrongARM (new CacheCleanerHack and InterruptDelay switches added to hdr/Options to cover some functionality that StrongARM previously covered)
  * SAcleanflushbroken
  * StrongARM_POST
  * IrqsInClaimRelease
  * CheckProtectionLink
  * GSWorkspaceInKernelBuffers
  * EarlierReentrancyInDAShrink
  * LongCommandLines
  * ECC
  * NoSPSRcorruption
  * RMTidyDoesNowt
  * RogerEXEY
  * StorkPowerSave
  * DebugForcedReset
  * AssembleKEYV
  * AssemblePointerV
  * ProcessorVectors
  * Keyboard_Type
  Assorted old files have also been deleted.
Admin:
  Identical binary to previous revision for IOMD & Raspberry Pi builds


Version 5.51. Tagged as 'Kernel-5_51'

Detail:
  This change gets rid of the following switches from the source (picking appropriate code paths for a desktop build):
  * STB
  * RO371Timings
  * NormalSpeedROMS
  * AutoSpeedROMS
  * RISCPCBurstMode
  * InterlacedPointer
  * ParallelFlashUpgrade (and s/FlashROM file)
  * Embedded_UI
  Some of the deleted code might be worth revisiting in future:
  * OS_ReadSysInfo 4 support for storing the MAC in alternate CMOS locations (including 2nd copy for error checking) or fetching via Service_MachineAddress
  * Mouse handling changes, possibly aimed at hiding the mouse pointer if a mouse isn't connected
  * More strict CMOS validation in s/NewReset
Admin:
  Identical binary to previous revision for IOMD & Raspberry Pi builds


Version 5.50. Tagged as 'Kernel-5_50'