GitLab

Despite never being properly documented in the RISC OS PRMs, there's
evidence that Acorn were recommending that third-parties used OS_Byte
166 for locating the OS_Byte variables well into the mid-1990's:

https://www.riscosopen.org/forum/forums/5/topics/14676#posts-94080

Currently OS builds which use zero page relocation will only return the
low 16 bits of the address from OS_Byte 166, most likely breaking any
third-party software which is trying to use it. Attempt to restore
compatibility by having OS_Byte 166 add the missing high address bits
into the "next location" value returned in R2, and fix OS_Byte 167 in a
similar manner (adding into R1).

Additionally, make the values read-only, because the kernel is littered
with code that uses hard-coded OsbyteVars addresses and so is unlikely
to do anything sensible if someone was to modify the OsbyteVars address
that's stored in workspace.

Version 6.39. Tagged as 'Kernel-6_39'

Detail:
  * various low-numbered dynamic areas used by RISC OS 6 and Pyromaniac
  * OS_ReadSysInfo 8 host platform classes for VirtualRPC, A9Home, Pyromaniac
  * OS_Byte 0,<not 0> MosVer values for various systems since the BBC micro
  * OS_Byte 129,0,255 (BASIC INKEY -256) values for various RISC OS systems

Admin:
  Discovered that these weren't really recorded anywhere during recent
  allocation request. Some information gleaned from http://beebwiki.mdfs.net

Version 6.34. Not tagged

* Update OS_ScreenMode 11's handling of drivers which fail to
initialise. If there was no previous driver, then instead of trying to
restore that nonexistant driver, stick with the new one. This is mainly
to help with the case where the kernel's built in modes aren't accepted
by the driver, and valid modes only become available once an MDF is
loaded (this can happen with early OMAP3 chip revisions, which have very
tight sync & porch limits, causing 90% of the kernel's modes to be
rejected). If the kernel was to revert to the "no driver" state, then
loading the MDF would still leave you with no video output.
* Since we can now end up in a state where a driver is selected but
hasn't been programmed yet, update OS_Byte 19 to detect this (via the
magic ScreenBlankDPMSState value of 255) and avoid waiting for VSync
* Update RemovePages & InsertRemovePagesExit (screen DA handlers) to
avoid infinite loops if the screen DA gets shrunk to zero size (was seen
while attempting to complete the !Boot sequence while no driver was
active)

Version 6.33. Tagged as 'Kernel-6_33'

* Don't wait for VSync if we're in IRQ context, since (a) IRQ handlers
shouldn't take lots of time, and (b) it may hang the system. Fixes
https://www.riscosopen.org/tracker/tickets/424
* Extend the DPMSUtils-inherited "don't wait for VSync if HSync output
is off" fix to also deal with the case where VSync output is off, since
it's reasonable to assume that turning off VSync output could also
prevent the CPU from receiving the associated interrupts.

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

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:
  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:
  Resources/UK/Messages, hdr/KernelWS, s/Kernel - On return from a SWI with V set, do some basic validity checks on the error pointer in order to try and catch buggy SWIs that return bad pointers or invalid error blocks. If a bad pointer is found we'll substitute it with a pointer to a different error block, which has the SWI number in the error message, to allow the user to identify the source of the problem. (There's also a chance we'll crash when investigating a bad pointer, but crashing here in the kernel is preferable to crashing elsewhere because R12 should still contain the SWI number)
  hdr/OSMisc - Define SeriousErrorV reason codes and extended ROM footer entry IDs
  hdr/Options - Remove HangWatch integration flag, obsolete now that SeriousErrorV is available
  s/ArthurSWIs - Keep defaultvectab up to date with vector allocations
  s/Middle - Update serious error handling to call SeriousErrorV at several key points. This allows for accurate crash dumps to be obtained, along with a mechanism to warn low-level components such as RTSupport that the privileged mode stacks are being flattened.
  s/Middle - Add OS_ReadSysInfo 15, for enumerating extended ROM footer entries
  s/PMF/osbyte - Update InitNewFX0Error to use the ROM footer entry ID defined in hdr/OSMisc
Admin:
  Tested on Pi 1B, 2B, 3B


Version 5.35, 4.79.2.313. Tagged as 'Kernel-5_35-4_79_2_313'

Fix OS_Byte 19 getting stuck if it's called just before the screen blanker activates. Add new OS_ReadSysInfo reason code for determining IIC bus count.

Detail:
  s/PMF/osbyte - For OS_Byte 19, move screen blanker check (and current GraphicsV driver check) inside the WFI loop so that the loop will terminate if the screen should blank (or current GraphicsV driver should die) before the next VSync occurs. Also move the Portable_Idle call to before the interrupt trigger - the old location meant that if the screen blanked we'd continue on to the Portable_Idle call and end up pointlessly stalling the system
  s/Middle - Add OS_ReadSysInfo 14, as a legitimate way of finding the number of IIC buses present on the system
Admin:
  Tested on Pandaboard


Version 5.35, 4.79.2.261. Tagged as 'Kernel-5_35-4_79_2_261'

With ProtectStationID turned on there are no routes to writing the Econet station (or bottom octect of the IP address), a function previously fulfilled by the SetStation utility which pokes the hardware directly and doesn't fit into a HAL model.
Add a new subreason to OS_NVMemory to perform this role. This SWI appeared for RISC OS 5.00, and errors unsupported subreasons, so there's a means of run tim selecting its use by checking the platform class and trying the SWI. All RISC OS 5 based platforms can always be upgraded to this version, since they're all still being maintained.

hdr/Options: move the switch with the other options from osinit.s
i2cutils.c: new subreason

Ditch the 'ObsoleteNC1CMOS' switch, if it was obsolete for NC1, it's certainly obsolete now.
Ditch unmaintained messages files for Morris4/Omega/Ursula projects.
Tested on a Risc PC.

Version 5.35, 4.79.2.247. Tagged as 'Kernel-5_35-4_79_2_247'

Detail:
  This set of changes:
  * Adds basic support for multiple GraphicsV drivers, by way of some new OS_ScreenMode reason codes for registering/deregistering, selecting and enumerating drivers (11, 64-68)
  * Tidies up handling of HAL video calls so that the HAL calls will be transformed into a bona fide GraphicsV driver if they're implemented
  * Changes handling of 16bpp gamma table entries so that they're sent to GraphicsV in a generic form instead of in a VIDC-specific form
  * Adds a new GraphicsV call and defines new VIDC list items to allow GraphicsV drivers to utilise the new pixel formats
  File changes:
  * h/VIDCList, hdr/VIDCList, Makefile - Add new header export containing VIDC list type 3 definitions, to avoid repeated definitions in other components
  * Resources/UK/Messages - Add new GraphicsV/OS_ScreenMode error strings and some missing processor type strings
  * hdr/KernelWS - Clean up some pre-GraphicsV definitions, and add new workspace locations for storing the current GraphicsV driver number and the driver list
  * hdr/Options - Remove obsolete InverseTextTransparency option
  * hdr/VduExt - Add VDU variable 192 for storing GraphicsV driver number (same as ROL's VideoV driver number). Remove old 'Flag_*' mode flag definitions (use new 'ModeFlag_*' defintions instead). Add new OS_ScreenMode reason codes.
  * s/ARM600, s/VMSAv6, s/vdu/vdu23, s/vdu/vdugrafa, s/vdu/vdugrafd, s/vdu/vdupalxx, s/vdu/vdupointer, s/vdu/vduwrch - Strip out pre-GraphicsV code. Update GraphicsV code to use correct driver number.
  * s/ArthurSWIs - Pass the default GraphicsV claimant the VduDriverWorkSpace instead of ZeroPage
  * s/Getall - Add Hdr:VIDCList and s/vdu/VduGrafHAL to list of GETs
  * s/NewIRQs - Remove HAL VSync IRQ initialisation, is now handled by grafvhal. Remove old HAL VsyncIRQ entry point, all VSyncs are now handled by VsyncIRQ_ExtEntry.
  * s/PMF/osbyte - Stop OS_Byte 19 waiting forever if no video driver is active
  * s/PMF/osinit - Remove HAL VSync IRQ initialisation, is now handled by grafvhal
  * s/vdu/vducursoft - Use new workspace variable names and flag names
  * s/vdu/vdudecl - Remove old HALDAG_* definitions, GVDAG_* definitions are used instead. Add definition of the per-driver workspace structure and flags.
  * s/vdu/vdudriver - Remove pre-GraphicsV code. Update InitialiseMode to check for and initialise a HAL driver. Use cached driver features word in a few places instead of calling GraphicsV each time. Update PalIndexTable to disable VIDC mangling of 16bpp gamma tables.
  * s/vdu/vdugrafv, s/vdu/vdugrafhal - HAL<->GraphicsV code split off into its own file (vdugrafhal). Default GraphicsV claimant now only deals with VSync events for the active driver.
  * s/vdu/vdumodes - Get rid of old VIDC List type 3 definiton; now in hdr/VIDCList
  * s/vdu/vduswis - Added OS_ScreenMode reason codes 11 and 64-68 for registering, deregistering, selecting and enumerating GraphicsV drivers. Update mode set code to not bother checking if the driver supports the pixel format; instead we assume that the driver's vet mode call will do the check for us.
Admin:
  Tested in Tungsten, IOMD, OMAP3 & BCM2835 ROMs
  Requires HdrSrc-2_38 and updated video driver modes


Version 5.35, 4.79.2.203. Tagged as 'Kernel-5_35-4_79_2_203'

IssueService -> BL Issue_Service.

hdr/Options: Switch removed
s/Modhand: Switch removed, now considered equivalent to DebugROMInit. DebugROMInit changed so that the callback ordering is as expected, batched up until "callbacks" is hit after Service_PostInit.
PMF/osbyte: Redundant RISC OS 2.01 code deleted

Version 5.35, 4.79.2.184. Tagged as 'Kernel-5_35-4_79_2_184'

Detail:
  s/Middle - Added OS_ReadSysInfo 13 to allow the kernel to validate a key handler before the owner attempts to install it
  Resources/UK/Messages - Text for new "Bad key handler" error
  s/GetAll, s/PMF/Def - Get rid of now obsolete s/PMF/Def file. It only contained definitions for pre-HAL hardware, and for the key handler layout (now in Hdr:Keyboard)
  hdr/KeyWS - Increased size of KeysDown array so it can hold 768 keys instead of 160. Trim a couple of obsolete variables, and increase CurrKey/OldKey from 1 byte to 4 bytes.
  s/PMF/key, s/PMF/osbyte - Main bulk of the changes for the new key handling. All the important interfaces are now able to deal with extended (i.e. > 8 bit) internal key numbers, and the kernel is able to cope with key handlers which use 16 bit internal/low level key numbers instead of 8 bit.
Admin:
  Tested on Pandora & BB-xM
  Requires HdrSrc-2_20


Version 5.35, 4.79.2.178. Tagged as 'Kernel-5_35-4_79_2_178'

Variously the call to TranslateError was either followed (outside the switch) by an unnecessary SETV, or missing SETV for the non international case.
Added DMA controller HAL device for IOMD.

Version 5.35, 4.79.2.174. Tagged as 'Kernel-5_35-4_79_2_174'

Detail:
  hdr/HALEntries - Brought in line with RPi branch, plus addition of new HAL_UARTDefault HAL entry, to allow DualSerial to determine which (if any) of the HAL UARTs should be the default UART accessed via OS_SerialOp
  s/GetAll - Add GET of Hdr:SerialOp
  s/PMF/osbyte - Use OS_SerialOp 10 when constructing filename to open for OS_Byte 2
Admin:
  Tested in OMAP3, Tungsten ROMs


Version 5.35, 4.79.2.152. Tagged as 'Kernel-5_35-4_79_2_152'

The kernel already looks after all other aspects of the ARM CPU, so can look after the cache control command too.
 HelpStrs.s:New tokens for help and syntax
 CmdHelp.s:UK help and syntax
 Arthur3.s:Tables updates for *CONFIGURE/STATUS, lined some stuff up, default error text sync'd with Hdr:NewErrors
 MoreComms.s:Parsing and doing of *CACHE
 Utility.s:Hashing table updated for *CACHE
Other minor changes
 hdr/Options:Bring 'MosVer' into the private header
 hdr/RISCOS:aasm aliases for SP removed, MainVars and MosVer made private, added definition of the start of application space
 HeapMan.s:Use of GRAB changed to Pull
 Offset of TutuCMOS changed for more informative PrintSoundCMOS
 PMF/osbyte.s:Use OsBytes header file in place of MainVars

Version 5.35, 4.79.2.151. Tagged as 'Kernel-5_35-4_79_2_151'

On odd numbered versions was coming out as 7F not F7.

Version 5.35, 4.79.2.141. Tagged as 'Kernel-5_35-4_79_2_141'

Expand tabs.
Swap DCI for instructions now Objasm 4 is out.
Symbols for FSControl_CAT/RUN/OPT changed to non Arthur definitions.
Still boots on IOMD class, no other testing.

Version 5.35, 4.79.2.124. Tagged as 'Kernel-5_35-4_79_2_124'

Detail:
  s/Arthur3, s/ChangeDyn, s/HAL, s/HeapMan, s/Middle, s/MoreSWIs, s/NewIRQs, s/Utility, s/VMSAv6, s/PMF/key, s/PMF/osbyte, s/PMF/osword, s/vdu/vdudecl, s/vdu/vdudriver, s/vdu/vduplot, s/vdu/vduwrch - Tweaked lots of LDM/STM instructions in order to get rid of the depracation/performance warnings
Admin:
  Tested on rev A2 BB-xM


Version 5.35, 4.79.2.98.2.53. Tagged as 'Kernel-5_35-4_79_2_98_2_53'

Detail:
  A whole mass of changes to add high processor vectors + zero page relocation support to the Cortex branch of the kernel
  At the moment the code can only cope with two ZeroPage locations, &0 and &FFFF0000. But with a bit more tweaking those restrictions can probably be lifted, allowing ZeroPage to be hidden at almost any address (assuming it's fixed at compile time). If I've done my job right, these restrictions should all be enforced by asserts.
  There's a new option, HiProcVecs, in hdr/Options to control whether high processor vectors are used. When enabling it and building a ROM, remember:
  * FPEmulator needs to be built with the FPEAnchor=High option specified in the components file (not FPEAnchorType=High as my FPEmulator commit comments suggested)
  * ShareFS needs unplugging/removing since it can't cope with it yet
  * Iyonix users will need to use the latest ROOL boot sequence, to ensure the softloaded modules are compatible (OMAP, etc. don't really softload much so they're OK with older sequences)
  * However VProtect also needs patching to fix a nasty bug there - http://www.riscosopen.org/tracker/tickets/294
  The only other notable thing I can think of is that the ProcessTransfer code in s/ARM600 & s/VMSAv6 is disabled if high processor vectors are in use (it's fairly safe to say that code is obsolete in HAL builds anyway?)
  Fun challenge for my successor: Try setting ZeroPage to &FFFF00FF (or similar) so its value can be loaded with MVN instead of LDR. Then use positive/negative address offsets to access the contents.
  File changes:
  - hdr/ARMops - Modified ARMop macro to take the ZeroPage pointer as a parameter instead of 'zero'
  - hdr/Copro15ops - Corrected $quick handling in myISB macro
  - hdr/Options - Added ideal setting for us to use for HiProcVecs
  - s/AMBControl/allocate, s/AMBControl/growp, s/AMBControl/mapslot, s/AMBControl/memmap, s/AMBControl/service, s/AMBControl/shrinkp, s/Arthur2, s/Arthur3, s/ArthurSWIs, s/ChangeDyn, s/ExtraSWIs, s/HAL, s/HeapMan, s/Kernel, s/MemInfo, s/Middle, s/ModHand, s/MoreSWIs, s/MsgCode, s/NewIRQs, s/NewReset, s/Oscli, s/PMF/buffer, s/PMF/IIC, s/PMF/i2cutils, s/PMF/key, s/PMF/mouse, s/PMF/osbyte, s/PMF/oseven, s/PMF/osinit, s/PMF/osword, s/PMF/oswrch, s/SWINaming, s/Super1, s/SysComms, s/TickEvents, s/Utility, s/vdu/vdu23, s/vdu/vdudriver, s/vdu/vdugrafl, s/vdu/vdugrafv, s/vdu/vdupalxx, s/vdu/vdupointer, s/vdu/vduswis, s/vdu/vduwrch - Lots of updates to deal with zero page relocation
  - s/ARM600 - UseProcessTransfer option. Zero page relocation support. Deleted pre-HAL ClearPhysRAM code to tidy the file up a bit.
  - s/ARMops - Zero page relocation support. Set CPUFlag_HiProcVecs when high vectors are in use.
  - s/KbdResPC - Disable compilation of dead code
  - s/VMSAv6 - UseProcessTransfer option. Zero page relocation support.
Admin:
  Tested with OMAP & Iyonix ROM softloads, both with high & low zero page.
  High zero page hasn't had extensive testing, but boot sequence + ROM apps seem to work.


Version 5.35, 4.79.2.98.2.48. Tagged as 'Kernel-5_35-4_79_2_98_2_48'

Detail:
  Three main changes:
  * On odd-numbered (i.e. development) versions of the module, the UtilityModule will now take its date from the VersionNum file instead of using a hard-coded date
  * All build versions now look for the new "extended ROM footer" (as created by romlinker 0.04+) at the end of the ROM image and use it to determine the ROM build date for return by OS_ReadSysInfo 9,2. Failing to find the build date in the footer will cause OS_ReadSysInfo 9,2 to return 0.
  * On odd-numbered versions, OS_Byte 0 will now use the ROM build date (as found in the extended footer) to generate the error block that's returned to the user. This seems OK as the PRM describes OS_Byte 0 as returning the "creation date of the operating system". Plus it's a convenient way of getting the ROM build date into the Switcher, since the switcher uses OS_Byte 0. If the extended footer can't be found (or if the string isn't initialised yet, e.g. before Service_PostInit) the code falls back to a hard-coded string containing the date from the VersionNum file.
  File changes:
  Makefile - Updated to not create the obsolete Time+Date file (previously used for the ROM build date)
  Version - Use date from VersionNum file for development builds
  hdr/Options - New UseNewFX0Error variable/option to make it easy to check which OS_Byte 0 variant should be enabled
  hdr/KernelWS - Added new string buffers & extended ROM footer pointer to workspace
  s/Middle - Updated OS_ReadSysInfo 9 code, and added utility functions for searching the extended ROM footer for certain tags
  s/NewReset - Added a couple of calls to initialise the new string buffers just prior to Service_PostInit. This is required since OS_Byte/OS_ReadSysInfo shouldn't enable interrupts, but date conversion relies on the Territory module, which may enable interrupts.
  s/PMF/osbyte - Updated OS_Byte 0 code
Admin:
  Tested in Tungsten ROM, with and without the extended footer present.


Version 5.35, 4.79.2.115. Tagged as 'Kernel-5_35-4_79_2_115'

Detail:
  Three main changes:
  * On odd-numbered (i.e. development) versions of the module, the UtilityModule will now take its date from the VersionNum file instead of using a hard-coded date.
  * All build versions now look for the new "extended ROM footer" (as created by romlinker 0.04+) at the end of the ROM image and use it to determine the ROM build date for return by OS_ReadSysInfo 9,2. Failing to find the build date in the footer will cause OS_ReadSysInfo 9,2 to return 0.
  * On odd-numbered versions, OS_Byte 0 will now use the ROM build date (as found in the extended footer) to generate the error block that's returned to the user. This seems OK as the PRM describes OS_Byte 0 as returning the "creation date of the operation system". Plus it's a convenient way of getting the ROM build date into the Switcher, since the switcher uses OS_Byte 0. If the extended footer can't be found (or if the string hasn't been initialised yet, e.g. before Service_PostInit) the code falls back to a hard-coded string containing the date from the VersionNum file.
  File changes:
  Makefile - Updated to not create the obsolete Time+Date file (previously used for the ROM build date)
  Version - Use date from VersionNum file for development builds
  hdr/Options - New UseNewFX0Error variable/option to make it easy to check which OS_Byte 0 variant should be enabled
  hdr/KernelWS - Added new string buffers & extended ROM footer pointer to workspace
  s/Middle - Updated OS_ReadSysInfo 9 code, and added utility functions for searching the extended ROM footer for certain tags
  s/NewReset - Added a couple of calls to initialise the new string buffers just prior to Service_PostInit. This is required since OS_Byte/OS_ReadSysInfo shouldn't enable interrupts, but date conversion relies on the Territory module, which may enable interrupts.
  s/PMF/osbyte - Updated OS_Byte 0 code
Admin:
  Tested in OMAP ROM, with and without the extended footer present.


Version 5.35, 4.79.2.98.2.41. Tagged as 'Kernel-5_35-4_79_2_98_2_41'

Detail:
  Event numbers greater than 31 are possible, it's just that OS_GenerateEvent
  doesn't bother cheking the event semaphores for them. However, the value
  returned in R1 from these OS_Bytes always indicated that such events were
  disabled. This suggests that OS_GenerateEvent was not always so, but the
  initials in comments there suggest the change was about RISC OS 3.0.
  The OS_Bytes now correctly reflect OS_GenerateEvent behaviour.
  Another bug fix is that once the event semaphores had saturated at 255,
  OS_Byte 13 was still happy to decrement the semaphore, so for example 256
  enables followed by 255 disables would have disabled the event.
Admin:
  Not tested.

Version 5.35, 4.79.2.70. Tagged as 'Kernel-5_35-4_79_2_70'

Check-in of the few last-minute changes for the Customer L demo. Nothing exciting, apart from an extended touchscreen API.

Version 5.35, 4.79.2.13. Tagged as 'Kernel-5_35-4_79_2_13'

Detail:
  Added the HAL NVRAM entries.
  Modified i2cutils to use the HAL entries for NVRAM and behave sensibly if the HAL reports that there is no NVRAM, in which case there must be a forced reset_cmos call so that the cache gets set up sensibly.
Admin:
  Tested under the RPC emulator and appears to be working correctly, although some calls to IIC are still being made in the no nvram case.

Version 5.35, 4.79.2.8. Tagged as 'Kernel-5_35-4_79_2_8'

partial video changes for kernel/HAL split near-HAL code for VIDC/IOMD in vdu.vduhint briefly tested in Ursula desktop build still some kernel workspace dependency in near-HAL code

Version 5.35, 4.79.2.3. Tagged as 'Kernel-5_35-4_79_2_3'

* Added ARM_IMB and ARM_IMBRange SWIs as recommended by ARMv5.
* Some early prototype HAL bits popped in - a lot of source restructuring still
  to come.
* New debug target creates an AIF image with debug information, and translates
  this into an ASCII object file for the 16702B logic analyser.

Version 5.35, 4.79.2.1. Tagged as 'Kernel-5_35-4_79_2_1'

  Removed DriversInKernel conditional.
Detail:
  If the territory changes or the resource file changes, the kernel
    will now decache all the cached error blocks so that next time
    they are required, they will be looked up again.
  The error cacheing is now a kernel build option and is always set
    to on.
  Removed one of the 5 error messages to be cached - it never seems
    to happen.  The remaining 4 are more frequent.
Admin:
  Tested in Ursula build.
  Cannot be used with HdrSrc 0.94.  HdrSrc 0.95 and later is required
    (or HdrSrc 0.93 and earlier subject to other kernel requirements)
  Requires MessageTrans 0.42 or later for correct operation when a
    replacement messages file is loaded.

Version 5.32. Tagged as 'Kernel-5_32'

  RPCEm update.
* Register allocation in default ErrorV handler fixed - problems occured when
  callbacks were triggered on way out.
* OS_Byte 19 didn't manipulate interrupt disable flag correctly in 26-bit
  builds.
* Stray bit of debugging left in sprite code many years ago removed.

Version 5.23. Not tagged

Details:
  The Kernel will now compile to produce a pure 32-bit system if No26bitCode is
  set to TRUE.
  If No26bitCode is FALSE, then the Kernel will be a standard 26-bit Kernel,
  although some internal changes have taken place to minimise compile
  switches between the two cases. See Docs.32bit for more technical info.

  The hardest part was the flood-fill...

Other changes:
  Pointer shape changes now take place on the next VSync, rather than actually
  WAITING for the VSync. Turning the Hourglass on shouldn't slow your machine
  down by 5% now :)

  Lots of really crusty pre-IOMD code removed.

Admin:
  Tested in 32 and 26-bit forms in a limited desktop build. Basically, this
  will need to see a lot of use to iron out difficulties. I'd like anyone who
  has a non-frozen project to at least attempt using this Kernel.

Version 5.23. Tagged as 'Kernel-5_23'

OS_ReadSysInfo 2 now reports whether the IIC bus is fast (in bit 24 of R2), and whether I/O clocks should be stopped when idling the processor (bit 25).

OS_Byte 19 is a bit more careful in its use of Portable_Idle - an edge case
where the vsync interrupt was already pending now returns immediately.

Version 5.07. Tagged as 'Kernel-5_07'

Version 4.97. Tagged as 'Kernel-4_97'

Now calls XPortable_Idle, not Portable_Idle in key-wait code.
Calls Portable_Idle in OS_Byte 19.

Version 4.94. Tagged as 'Kernel-4_94'

ObsoleteNC1CMOS (like the CMOS header file).

Version 4.71. Tagged as 'Kernel-4_71'

Version 4.68. Tagged as 'Kernel-4_68'

RISC OS 3.7 generation kernel).
CMOS no longer gets scrambled when reset in STB build.
UpCall_KeyboardStatus now issued when OS_Byte 202 called or when keyboard
status byte is changed by other means (such as pressing Caps Lock).

Version 4.67. Tagged as 'Kernel-4_67'

Bandwidth limit for 7500FE fixed.
RO371Timings flag set to :LNOT:STB

Version 4.64. Tagged as 'Kernel-4_64'