GitLab

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:
  s/vdu/vdudriver - When using mode selector blocks, don't allow the system to switch into double-vertical, double-pixel, or BBC-gap modes which are in colour depths unsupported by the kernel
Admin:
  Tested on BB-xM


Version 6.13. Tagged as 'Kernel-6_13'

Detail:
  s/HAL - OS_Hardware 3 (remove HAL device) will now re-scan the device list for the device following the Service_Hardware call, so that the device list won't become corrupt if the service call triggers addition/removal of devices.
Admin:
  Tested on iMX6
  *HDMIOff now correctly removes the HDMI audio device and SoundDMA's software mixer device (SoundDMA removes mixer in response to the HDMI audio device vanishing, but re-entrancy bug meant that the HDMI device was left on the list)
  Note that this only covers re-entrancy via Service_Hardware. OS_Hardware 2/3/4/5 are not re-entrant from other locations (e.g. IRQ handlers or memory allocation service calls).


Version 6.12. Tagged as 'Kernel-6_12'

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:
  s/MemInfo - The wrapper around OS_Memory 0 introduced in Kernel-5_35-4_79_2_311 was preserving the wrong PSR field on exit, causing any error generated by the core code to be lost.
Admin:
  Tested on Iyonix
  Fixes *screensave saving mostly white pixels (address translation for "external" VRAM should have failed and caused ADFS to fall back to a bounce buffer)
  Is also likely to be the cause of https://www.riscosopen.org/forum/forums/5/topics/11713 (address translation should have failed for soft ROM)


Version 6.10. Tagged as 'Kernel-6_10'

Detail:
  As the application slot is now a normal dynamic area, there's no need to manipulate the CAM directly. Convert FudgeSomeAppSpace into a OS_ChangeDynamicArea SWI followed by memset().
  ChangeDyn.s: Offset by 32k to account for the -32k that dynamic area -1 has.
  NewReset.s: Delete FudgeSomeAppSpace and replace as above.
Admin:
  Submission from Timothy Baldwin.

Version 6.08. Tagged as 'Kernel-6_08'

Detail:
  NewReset.s: Remove warning about soft reset, this is not supported any longer
  MsgCode.s: Reload LR after potentially changing mode
  PMF/osinit.s: Delete vestiges of soft reset support
Admin:
  Submission from Timothy Baldwin.

Version 6.07. Tagged as 'Kernel-6_07'

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:
  s/ChangeDyn - Due to the way that some page flags map to the same bits as (different) DA flags, the Batcall that PMP_PreGrow makes in order to claim the requested page was getting confused and thinking that the special DMA PreGrow handler should be used instead of the DA-specific one (which in this case is a custom one responsible for claiming the right page). Modify PMP_PreGrow so that it only supplies DA flags to the Batcall, and patches in any custom page flags afterwards.
  Also swap magic number for appropriate symbol in PMPGrowHandler.
Admin:
  Tested on BB-xM
  Fixes CAM corruption when a PMP claims a specific page, due to the PMP code and DA code disagreeing about which page should be used


Version 6.00. Tagged as 'Kernel-6_00'

The default OS_Byte value enabled num lock, but this was passed to the keyboard *before* a decision to wipe the CMOS (and hence potentially override it) was made.
This left the LED on until a key was pressed, regardless of the configured state.
Change the default OS_Byte value to be off so there's only one transition (off->on, or off->off), and refresh the keyboard after the validity of CMOS has been made.
Ref: https://www.riscosopen.org/forum/forums/4/topics/10400

Version 5.99. Tagged as 'Kernel-5_99'

This is now a HAL only kernel, and 0x3200000 is most likely somewhere in RAM.

Detail:
  s/Middle - Tweak register dump generation so that it'll attempt to provide sensible R13 & R14 values if the abort came from the same mode that we're handling the abort in. R13 will be adjusted by however much data we've pushed onto the stack, and R14 will be set to &DEADDEAD to indicate that the CPU has corrupted it and we don't know what the original value was.
Admin:
  Tested on BB-xM


Version 5.98. Tagged as 'Kernel-5_98'

When SyncLib-0_04 is used in conjunction with SDIODriver, the exclusive access instructions (instead of SWP) abort when the cache is off, causing the machine to hang if *Cache Off is used.
See A15 TRM section 6.4.5 for the logic.
Copy the A53's known CPU flags to prevent the D cache being turned off.

Version 5.97. Tagged as 'Kernel-5_97'

Detail:
  s/vdu/vdudriver - On startup, initialise all palettes to 0, not just Pal_Blank. Ensures that entries which might not always be explicitly initialised (e.g. pointer) are self-consistent. Also make sure InitialiseMode communicates the pointer palette to the new GV driver, since some components tend to program it in a lazy manner (e.g. Hourglass)
  s/vdu/vdupalxx - Fix UpdateAllPalette setting R4 to 0 on exit. Fix PV_BlankScreen R0 return value to be 0/1 as the comment suggests instead of always being 0 due to GraphicsV calls.
Admin:
  Tested on wandboard
  Fixes incorrect hourglass colours after reset, due to software RAM clear not wiping the kernel's palette (kernel + Hourglass thought old colours were still in use, but IMXVideo hadn't been told any colours yet so was using defaults of 0)


Version 5.96. Tagged as 'Kernel-5_96'

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/vdu/vdugrafl - Disable hardware scrolling if we're in a teletext mode with a border. Quick fix in lieu of adding some code to make sure the relevant border areas are cleared when scrolling.
  s/vdu/vduttx - Ignore VDU 23,18,<n> sequences when outside of teletext. Fixes a crash when screen update suspend/resume sequences are used.
Admin:
  Tested on RiscPC


Version 5.94. Tagged as 'Kernel-5_94'

During the first pass keyboard scan the ROM module nodes are built off the anchor ROMModuleChain.
During the second pass the whole set of ROM module nodes are temporarily constructed anchored on the stack, then switched over.
This caused a problem when a duplicate name module was encountered on a podule (eg. MbufManager in a NIC) because FindROMModule searches from the ROMModuleChain anchor, didn't find a match, so created a new node rather than linking it to the NewerVersion/OlderVersion linked list on the existing node.
Then *Unplug and *RMInsert would say "Module is not in ROM" if the optional podule specifier was given, because the search stopped at the first node with the right name.

Swap round the second pass so it anchors directly on ROMModuleChain, and keeps the first pass anchor on the stack (needed only occasionally to copy over details of modules already initialised).

Tested on a Risc PC with NIC, can now selectively unplug MbufManager again.

Version 5.93. Tagged as 'Kernel-5_93'

Detail:
  s/Oscli:
  - Reorder RemoveOscliCharJobs to avoid WrchV being left claimed while the output stream is being closed, to resolve ticket #420.
  - Register usage also tweaked a bit to make the code a bit shorter & easier to read
  - Fix RedirectWrch to deal with errors correctly. PSR save/restore macros were added to the routine during the 32bit conversion process, but (a) they were inadvertantly causing all errors to be ignored, and (b) they were redundant since WrchV has no special in/out requirements for the PSR flags
Admin:
  Tested on Pandaboard
  Ticket #420 fix based around Colin's fix from https://www.riscosopen.org/forum/forums/4/topics/5269


Version 5.92. Tagged as 'Kernel-5_92'

Detail:
  s/NewReset - In Kernel-5_89, the initial OS_ResyncTime call was erroneously moved to after Service_PostInit, which had the side-effect of causing TerritoryManager's initial evaluation of AutoDST rules to be performed using an uninitialised RTC, with varying side effects depending on the user's timezone (e.g. UK stuck in DST all year round due to lack of BST in 1970). Move the call back to its original location so that TerritoryManager and any other PostInit claimants can see the correct time.
Admin:
  Tested in Iyonix ROM
  Resolves ticket #441


Version 5.91. Tagged as 'Kernel-5_91'

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'

Detail:
  Return the calculated checksum from MakeChecksum, like the comment says.
Admin:
  Spotted during code review (not tagged).

Detail:
  s/ExtraSWIs - Fix global OS_SynchroniseCodeAreas using the wrong appspace size; would have resulted in appspace only being partially synced if some pages were mapped out due to lazy swapping
  s/ARMops, s/ExtraSWIs, s/MemMap2 - Simplify code by making DCache_LineLen / ICache_LineLen store the actual line length values on ARMv7+ instead of the log2 values. Optimise SMP I-cache invalidation by allowing it to do a global invalidate. Ensure all ARMv7+ range checks use LO instead of NE, to avoid any problems with mismatched I/D line lengths (can't be sure the op range was rounded to the larger of the two)
Admin:
  Tested on iMX6


Version 5.88, 4.129.2.5. Tagged as 'Kernel-5_88-4_129_2_5'

OS_ConvertVariform 15 outputs 128b numbers per RFC4122.

Version 5.88. Tagged as 'Kernel-5_88'

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:
  Prior to ScreenModes starting (when CurrentMonitorType becaomes 7) this SWI would return Auto as 31 for EDID rather than -1, as would be the case had ReadMultiField been called.
  Change to use -1 for consistency and so it gets translated to type 3 (VGA).
Admin:
  Submission from Willi Theiss.

Version 5.85. Tagged as 'Kernel-5_85'

Detail:
  s/vdu/vdupointer - The software pointer code was calculating LineLength manually, due to previous kernel versions not storing a copy of the value that would be safe to use during screen redirection.
  Fix the code to use the new DisplayLineLength variable, so that the software pointer will be correct in modes which have row padding.
Admin:
  Tested on Raspberry Pi 3


Version 5.84. Tagged as 'Kernel-5_84'

Detail:
  s/vdu/vduswis - Don't use RMVForCurrentMode when R0 = ModeNo, only use it if R0 is -1. This ensures that results for explicitly-specified modes will always represent the base properties of the mode and won't be influenced by any unusual properties of the current mode, e.g. LineLength/ScreenSize alterations caused by driver-specific framebuffer padding.
Admin:
  Tested on Raspberry Pi 3


Version 5.83. Tagged as 'Kernel-5_83'

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'

Detail:
  Accept a monitortype of 'EDID' (as distinct from 'Auto', which uses the ID pins) to force the kernel, via ScrModes, to use the native screen mode prior to executing the boot sequence.
  Required for discless boot, this also helps if the boot sequence fails, the desktop will be entered in the monitor's native resolution, or a fallback if GraphicsV rejects that.
  The allocation of the EDID monitor type has been carefully selected to degrade to 'Auto' when used with an older OS. That way the configuration in CMOS is safe to use with softloads on top of older physical ROMs.
  When OS_ScreenMode is queried return the 'Auto' type, ie. at an API level there's no distinction.
Admin:
  Requires HdrSrc-2_67.
  Submission for the EDID bounty.

Version 5.80. Tagged as 'Kernel-5_80'

Detail:
  Some closer examination of the PL310 TRM reveals that there's no need to poll for completion of maintenance operations if we only use atomic ops.
  Since there's no particular need for us to use the background ops, just rewrite everything to use the atomic ops and get rid of the polling.
  This should also avoid the need for any costly locking in SMP setups.
  File changes:
  - s/ARMops - Updated as above
Admin:
  Tested on Pandaboard, iMx6


Version 5.79. Tagged as 'Kernel-5_79'

Detail:
  s/Arthur2 - When installing a code system variable, a register fumble resulted in OS_SynchroniseCodeAreas being called with a bogus address range. Fix it.
Admin:
  Tested on Pandaboard


Version 5.78. Tagged as 'Kernel-5_78'

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/ChangeDyn - Set r6 bit 0 if the area is smaller than the cache range threshold, because that's what's checked for at lines 3077 and 3092
Admin:
  Tested on Raspberry Pi


Version 5.76. Tagged as 'Kernel-5_76'

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:
  s/vdu/vdudriver, s/vdu/vdumodes - Re-introduce TTX256 so that 8bpp teletext will be used if no MDF is loaded
  s/vdu/vdudriver - If the video driver didn't support the native mode 7 colour depth, ModePromoTable was swapping it for another mode number, preventing the AltTTX code in FindOKMode from operating. So, skip the ModePromoTable check for mode 7.
  s/vdu/vduswis - Minor correction to alternate teletext mode search; 1<<5 = 32bpp, so stop search at log2bpp of 6
Admin:
  Tested on Raspberry Pi


Version 5.74. Retagged as 'Kernel-5_74'

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'