GitLab

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'