GitLab

Detail:
  s/Middle - If the HAL provides an extended machine ID, make sure OS_ReadSysInfo 4 doesn't return a MAC address. This is because the old-style machine ID which the MAC is extracted from will be completely synthetic and is so known not to contain a MAC (even if it may look like it does)
Admin:
  Tested on BB-xM, Raspberry Pi


Version 5.35, 4.79.2.188. Tagged as 'Kernel-5_35-4_79_2_188'

Detail:
  Briefly, this set of changes:
  * Adjusts PhysRamTable so that it retains the flags passed in by the HAL from OS_AddRAM (by storing them in the lower 12 bits of the size field)
  * Sorts the non-VRAM entries of PhysRamTable by speed and DMA capability, to ensure optimal memory allocation during OS startup.
  * Adjust the initial memory allocation logic to allow the cursor/sound chunk and HAL noncacheable workspace to come from DMA capable memory
  * Extends OS_Memory 12 to accept a 'must be DMA capable' flag in bit 8 of R0. This is the same as available in ROL's OS.
  * Extends OS_DynamicArea 0 to allow the creation of dynamic areas that automatically allocate from DMA capable memory. In ROL's OS this was done by setting bit 12 of R4, but we're using bits 12-14 for specifying the cache policy, so instead bit 15 is used.
  * Fixes OS_ReadSysInfo 6 to return the correct DevicesEnd value now that the IRQ/device limit is computed at runtime
  File changes:
  * hdr/OSEntries - Add definitions of the various flags passed to OS_AddRAM by the HAL. Add a new flag, NoDMA, for memory which can't be used for DMA.
  * hdr/KernelWS - Tidy PhysRamTable definition a bit by removing all the DRAM bank definitions except the first - this makes it easier to search for code which is interacting with the table. Remove VRAMFlags, it's redundant now that the flags are kept in the table. Add DMA allocation info to InitWs.
  * s/AMBControl/memmap - Updated to mask out the flags from PhysRamTable when reading RAM block sizes.
  * s/ARM600 - Strip out a lot of IOMD specific pre-HAL code.
  * s/ChangeDyn - Updated to cope with the flags stored in PhysRamTable. Implement support for DMA-capable dynamic areas. Rewrite InitDynamicAreas to insert pages into the free pool in the right order so that the fastest memory will be taken from it first.
  * s/GetAll, s/Middle - Fix OS_ReadSysInfo 6 to return the correct HAL-specific DevicesEnd value
  * s/HAL - Significant rework of initial RAM allocation code to allow the kernel workspace to come from the fastest DMA incapable RAM, while also allowing allocation of DMA capable memory for HAL NCNB workspace & kernel cursor/sound chunks. ClearPhysRAM rewritten as part of this.
  * s/MemInfo - Updated to cope with the flags stored in PhysRamTable. Add support for the new OS_Memory 12 flag. Update OS_Memory 7 to not assume PhysRamTable entries are sorted in address order, and rip out the old pre-HAL IOMD implementation.
  * s/NewReset - Remove GetPagesFromFreePool option, assume TRUE (as this has been the case for the past 10+ years). Revise a few comments and strip dead code. Update to cope with PhysRamTable flags.
  * s/VMSAv6 - Remove a couple of unused definitions
  * s/vdu/vdudriver - Update to cope with PhysRamTable flags
Admin:
  Tested in Kinetic RiscPC ROM softload, Iyonix softload, & OMAP3


Version 5.35, 4.79.2.186. Tagged as 'Kernel-5_35-4_79_2_186'

Permits applications to query what value would be used in the event of a CMOS reset for a given configure value. Notably, the configure plugins will use this in favour of 'ResetCMOS'.
hdr/Options: retire the 'Select16BitSound' switch, add comment for ChecksumCMOS switch
hdr/KernelWS: DuffEntry and Nowhere moved here
Kernel.s: Unused OSMD removed, retire single use of SPIRQ in favour of r13_irq
Middle.s: Retire SPIRQ
NewReset.s: Trim out 300+ lines of CMOS reset defaults, call OS_NVMemory 6 instead
PMF/i2cutils.s: CMOS reset default code and table moved here with refactoring
Note, the previous code preserved YearCMOS during the zeroing, only to unconditionally write it later - so have removed it from the zeroing step.
Note, the locations 80-111 are now considered as system CMOS in the allocations hence are now wiped too (previously they got skipped as user CMOS during R-power-on).

Tested on OMAP3 ROM with delete-power-on and R-power-on variants, and a simple BASIC program to read locations 0-255 via OS_NVMemory.

Version 5.35, 4.79.2.180. Tagged as 'Kernel-5_35-4_79_2_180'

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'

NewReset.s:
The one remaining use of SetBorder was to denote the user asked for and got a CMOS reset, which in the HAL case emitted a warning because setting the border is potentially complicated/slow.
To solve this, the reset is noted and replaces the normal RISC OS banner with a warning message. The behaviour and text for this comes from the BBC Master, though the escape key is used in place of break since a reset isn't actually needed.
Moved the unused cputable inside its corresponding switch.
Two occurrences of WriteS_Translated would have executed the message in the V=1 case.
KernelWS/Resources:
Flag added to workspace, translation added to messages files.
Heapman.s:
Commented out use of SetBorder removed.
Kernel.s:
SetBorder macro removed.
Middle.s:
Switched out use of SetBorder removed.
Super1.s:
Conditional WriteS_Translated would try to execute the message in the opposite condition case.


Version 5.35, 4.79.2.157. Tagged as 'Kernel-5_35-4_79_2_157'

Detail:
  s/Middle - Callback and breakpoint environment handler workspace is now specified as being ZeroPage relative
Admin:
  Untested, but same fix as on RPi branch


Version 5.35, 4.79.2.155. Tagged as 'Kernel-5_35-4_79_2_155'

Detail:
  s/Middle - Callback and breakpoint environment handler workspace is now specified as being ZeroPage relative
Admin:
  Tested on Raspberry Pi with high processor vectors


Version 5.35, 4.79.2.147.2.10. Tagged as 'Kernel-5_35-4_79_2_147_2_10'

With no VRAM, in Kernerl.s.HAL line 370, the less than 16M case sets aside half the RAM as available for video (more than, it uses no more than 32M) but the exactly equals 16M case set aside none.
Add some exports to hdr.HALEntries to define the subreasons to OS_Hardware.

Version 5.35, 4.79.2.154. Tagged as 'Kernel-5_35-4_79_2_154'

Detail:
  hdr/OSEntries, s/HAL, s/Kernel - Add compressed ROM support.
  With the current scheme, a compressed ROM will have everything except the HAL and kernel compressed.
  During the keyboard scan period the kernel will allocate some temporary decompression workspace and call the decompression stub that was appended to the ROM.
  The decompression stub is expected to perform in-place decompression of the ROM. Once decompression is complete the workspace will be freed and the page tables updated to make the ROM image readonly.
  It's the HAL's responsibility to make sure any compressed ROM is located in an area of physically contiguous RAM large enough to hold the uncompressed image.
  More info here: http://www.riscosopen.org/wiki/documentation/show/Compressed%20ROMs
  Makefile, h/OSEntries - Add C export of hdr/OSEntries
  hdr/HALDevice - Add device ID for Tungsten video device. Convert tabs to spaces for consistency.
  hdr/HALEntries, s/NewReset - Moved KbdFlag_* definitions to hdr/HALEntries so HALs can use them in their keyboard scan code
  s/ArthurSWIs, S/HAL, s/HeapSort, s/Kernel, s/MemInfo, s/Middle, s/NewIRQs, s/TickEvents, s/vdu/vdugrafb - Make use of BLX, BFI and long multiplies if the CPU supports them. Don't support SWI calls from thumb mode if the CPU doesn't support thumb.
  s/HAL - Made the LDMIA in Init_MapInRAM more sensible (register order was backwards). The old code did work, but wasn't doing what the comments described. Removed unused/unfinished HAL_Write0 function. Improve RISCOS_LogToPhys to check L1PT for any section mappings if the logical_to_physical call fails
  s/ModHand - Save one instruction by using ADR instead of MOV+ADD to compute lr
  s/NewReset, s/PMF/key - Pass L1PT to HAL_Reset to allow machines without hardware reset (e.g. IOMD) to perform resets by manually disabling the MMU and restarting the ROM
  s/vdu/vdudriver, s/vdu/vdugrafv - Use GVEntry macro borrowed from NVidia module for setting up the GraphicsV jump table. Make GraphicsV_ReadPaletteEntry call HAL_Video_ReadPaletteEntry if left unclaimed. Fixup GV_Render to only call HAL_Video_Render if the HAL call is implemented.
Admin:
  Tested with OMAP3, IOMD & Tungsten ROMs/softloads.


Version 5.35, 4.79.2.138. Tagged as 'Kernel-5_35-4_79_2_138'

Export less in hdr:RISCOS.
Delete unused GetDecimalPair routine.
Move CheckYear with other RTC stuff out of PMF/osword.
Hide DebugROMInit and DebugROMErrors in release (even numbered) versions.

Version 5.35, 4.79.2.127. Tagged as 'Kernel-5_35-4_79_2_127'

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:
  hdr/OSRSI6, s/Middle - Added ESC_Status to the list of items that OS_ReadSysInfo 6 exports
Admin:
  Tested in ROM softload on Iyonix


Version 5.35, 4.79.2.121. Tagged as 'Kernel-5_35-4_79_2_121'

Detail:
  hdr/OSRSI6, s/Middle - Added ESC_Status to the list of items that OS_ReadSysInfo 6 exports
Admin:
  Tested on rev A2 BB-xM


Version 5.35, 4.79.2.98.2.47. Tagged as 'Kernel-5_35-4_79_2_98_2_47'

Detail:
  s/Middle - Correct the actual item numbers to match those defined in the header 9and those used in the HAL branch)
  hdr/OSRSI6 - Corrected ROM version numbere where the new items are available from
Admin:
  Untested!


Version 5.35, 4.79.2.98.2.45. Tagged as 'Kernel-5_35-4_79_2_98_2_45'

Detail:
  s/Middle - Added some new OS_ReadSysInfo 6 items which are needed by the zero page relocation kernel. Also duplicated some existing entries to avoid conflicts with ROL's allocations.
  hdr/OSRSI6, Makefile - New header listing OS_ReadSysInfo 6 items
  hdr/PublicWS - Duplicated the workspace definitions for &0-&4000, but with a 'Legacy_' prefix to their names. Also added some new entries as needed by the zero page relocation kernel. Once existing modules have been updated to use OS_ReadSysInfo 6 & the Legacy_ definitions, the old defs will be removed.
  hdr/KernelWS - Removed 'Export_' prefix from all the exported workspace values, since the kernel can now use the original names directly
  hdr/Options - Dummy HiProcVecs option so merging things will be a bit cleaner
Admin:
  Tested on rev A2 BB-xM


Version 5.35, 4.79.2.98.2.44. Tagged as 'Kernel-5_35-4_79_2_98_2_44'

Detail:
  s/Middle - Added some new OS_ReadSysInfo 6 items which are needed by the zero page relocation kernel. Also duplicated some existing entries to avoid conflicts with ROL's allocations.
  hdr/OSRSI6, Makefile - New header listing OS_ReadSysInfo 6 items
  hdr/PublicWS - Duplicated the workspace definitions for &0-&4000, but with a 'Legacy_' prefix to their names. Also added some new entries as needed by the zero page relocation kernel. Once existing modules have been updated to use OS_ReadSysInfo & the Legacy_ definitions, the old defs will be removed.
  hdr/KernelWS - Removed 'Export_' prefix from all the exported workspace values, since the kernel can now use the original names directly
  hdr/Options - Dummy HiProcVecs option so merging things will be a bit cleaner
Admin:
  Tested in ROM softload on Iyonix


Version 5.35, 4.79.2.118. Tagged as 'Kernel-5_35-4_79_2_118'

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:
  s/Middle, s/PMF/osinit - Kernel now passes the buffer pointer to the HAL in R0 instead of R1, for ATPCS compliance.
Admin:
  Tested on rev A2 BB-xM


Version 5.35, 4.79.2.98.2.35. Tagged as 'Kernel-5_35-4_79_2_98_2_35'

Detail:
  OS_ReadSysInfo 10 is left unimplemented since it's a bit fiddly for us.
  OS_ReadSysInfo 11 is compatible with ROL's implementation, exposing HAL_DebugTX and HAL_DebugRX if the HAL provides them.
  See here for 10,11 docs: http://select.riscos.com/prm/core/osreadsysinfo.html
  OS_ReadSysInfo 12 is a new call to return the 'extended machine ID', to allow the HAL to specify the format & validity of the ID.
  If the HAL responds to the new HAL_ExtMachineID call then it's assumed that no old-style machine ID is present. The Kernel will generate an old-style ID using the contents of the extended ID, and use that with OS_ReadSysInfo 2/5.
  New software should use OS_ReadSysInfo 12 in preference to 2/5.
  s/Middle - Updated OS_ReadSysInfo SWI
  s/PMF/osinit - New old-style machine ID initialisation code
  hdr/HALEntries - Added new HAL_ExtMachineID entry
Admin:
  Tested on rev A2 BB-xM


Version 5.35, 4.79.2.98.2.34. Tagged as 'Kernel-5_35-4_79_2_98_2_34'

OS_ReadSysInfo 6 (subreason code is 23 for IRQsema). This will
be useful if zero page is ever protected and the IRQ semaphore
moved.

Version 5.35, 4.79.2.90. Tagged as 'Kernel-5_35-4_79_2_90'

Detail:
  * I noticed in passing that the default exception handlers were broken for
    non-IOMD machines if the exception was raised in FIQ mode - unless you
    had a very large application slot, then the machine would lock up. Now
    properly HAL-ised.
  * Added a new event number, allocated for PRISM use back in June.
Admin:
  Not tested. However, it can't make the situation any worse!

Version 5.35, 4.79.2.78. Tagged as 'Kernel-5_35-4_79_2_78'

Added "fast" flash tool for Customer L, allowing ROMs to be sent serially at
115200 baud not 9600 baud.
Fix to VDU despatch for ARMv4 and later.
Fixes to power on delete keyboard and keyboard timeout
Implemented MemoryReadPhys and MemoryAmounts with the HAL.

Version 5.35, 4.79.2.59. Tagged as 'Kernel-5_35-4_79_2_59'

*Configure ANYTHINGsize was broken due to not setting R0 to ReadUnsigned
IIC ack message uninternationalised
OS_Memory was saying we only had 4M of RAM
VDU4 scrolling when output was switched to sprite was causing corruption
on use of CTRL-J and CTRL-K
Default SystemSize CMOS set to 32k

Version 5.35, 4.79.2.55. Tagged as 'Kernel-5_35-4_79_2_55'

Detail:
  Lots of changes since last version, at least the following:
  * Updated OS timestamp, removed alpha status
  * Negative INKEY OS version changed to &AA
  * GraphicsV is now alocated vector number &2A
  * ROM moved up to &FC000000
  * Max application slot increased to 512 Mbytes (for now)
  * Max size of RMA increased to 256 Mbytes
  * RMA is now first-created dynamic area (so it gets lowest address after
    top of application slot)
  * OS_Memory 10 reimplemeted
  * New OS_ReadSysInfo 6 values 18-22 added
  * OS_ReadSysInfo 8 gains flag bit to indicate soft power-off
  * Misc internal top-bit-set-address fixes
  * *ChangeDynamicArea can take sizes in megabytes or gigabytes
  * Magic word "&off" in R0 passed to OS_Reset powers down if possible
  * Added acceleration: block copy; CLS; text window scroll up; rectangle
    fill
  * Disabled LED flashing in page mode (liable to crash)
  * Masked sprite plot and VDU 5 text avoids reading the screen if poss...

Version 5.35, 4.79.2.48. Tagged as 'Kernel-5_35-4_79_2_48'

1) Bring IOMD HAL more up to date. Add support for new call HAL_CleanerSpace (preparation for StrongARM kernel support).

2) In kernel, add HAL_CleanerSpace call (preparation for
StrongARM and XScale core support). Fix bug found with
ARMv3 support during test on Risc PC.

3) Implement new API for kernel SWIs that have used top
bits of addresses as flags. The new API has an extra
flag that must be set, so kernel can distinguish and
support both APIs. The reason for all this is that
addresses are 32-bits now, people, keep up there. Briefly:

  OS_HeapSort
    bit 31 of r0 set for new API, r1 is full 32-bit address
    flags move from r1 bits 31-29 to r0 bits 30-28

  OS_ReadLine
    bit 31 of r1 set for new API, r0 is full 32-bit address
    flags move from bits 31,30 of r0 to bits 30,29 of r1

  OS_SubstituteArgs
    bit 31 of r2 set for new API, r0 is full 32-bit address
    flag moves from bit 31 of r0 to bit 30 of r2

Tested on Risc PC and briefly on Customer A 2

Ta

Version 5.35, 4.79.2.41. Tagged as 'Kernel-5_35-4_79_2_41'

Ursula. Quite a hairy code merge really, so let's hope it is
worth it to someone. What you get (back after 2 or 3 years):
- much more efficient for largish numbers of DAs (relevance
  to current build = approx 0)
- fancy reason codes to support fast update of
  Switcher bar display (relevance = 0)
- support for clamped maximum area sizes, to avoid address
  space exhaustion with big memory (relevance = 0)
- better implementation of shrinkable DAs, performance
  wise (if lots of DAs, relevance = approx 0)
- support for 'Sparse' DAs. Holey dynamic areas, Batman!
  (relevance, go on someone use the darned things)
Moderately development tested on HAL/32bit ARM9 desktop.
Note the Switcher should be compiled to use the new
reason codes 6&7, for fabled desktop builds.

Also, during this work, so I could see the wood for the
trees, redid some source code clean up, removing pre-Medusa
stuff (like I did about 3 years ago on Ursula, sigh). That's
why loads of source files have changed. The new DA stuff
is confined pretty much to hdr.KernelWS and s.ChangeDyn.

Ta.

Version 5.35, 4.79.2.38. Tagged as 'Kernel-5_35-4_79_2_38'

* Allows HAL-driven software resets.
* Sound buffers corrected to be uncacheable.

Version 5.35, 4.79.2.33. Tagged as 'Kernel-5_35-4_79_2_33'

More stuff. Up to the desktop now; cache on, working keyboard. Some source restructuring to start to make splitting it up into several object files more feasible.

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'

* 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'

(NVRamSpeed is not defined in the Kernel workspace so we need an
 alternative way to work the speed of the I2C bus - so I've used
 I2Cticks - defined in PMF.i2cutils)

Version 5.34. Tagged as 'Kernel-5_34'

  New routine in i2cutils that allows access to protected sections such as
  MAC address
  OS_ReadSysInfo 4 now checks both copies MACAddress if MACNVRAM2copies is set
Detail:
  32K EEPROM has to be configured with IIC address &A6 (i.e wired up on the pcb)
  ClockNVMemoryFast has been replaced with MaxI2Cspeed so that several different
  rates can be used depending on the devices on the IIC bus.
Admin:
  Need to implement routine that can use one copy of the MAC address to
  replace the other in the event of it being corrupted.


Version 5.33. Tagged as 'Kernel-5_33'

Had one of those weekend brainstorms - managed to speed up SWI despatcher _and_ add Thumb support to it.

Fixed OS_BreakPt - was confused by PC/PSR split.

Version 5.24. Not tagged

Detail:
  "Podule" number now displayed again in *ROMModule output - flag
     preservation issue caused it to disappear in 5.23.
  *Eval output no longer misses its trailing space, neither do "Podule" or
    "Extn ROM" in *ROMModules output.
  Heap manager now works again in non-SVC modes.
  Exception dump now contains faked up 26-bit PC+PSR lookalike.
Admin:
  Assembled.

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'

Detail:
  MACFROMNVRAM was intended to force the Kernel to fetch the MAC
  address from NVRAM for Customer F 5. In practice it is not needed
  as its main purpose was to avoid getting the MAC address from
  the RawMachineID but this will not happen in Customer F 5 as
  RawMachineID will not be set.

Admin:
  Not tested.
  MACFROMNVRAM will be removed from HdrSrc.

Version 5.17. Tagged as 'Kernel-5_17'