GitLab

Detail:
  s/HeapSort, s/vdu/vdugrafc, s/vdu/vduswis - Avoid unnecessary remainder calculations in DivRem macro
  s/PMF/i2cutils, s/PMF/osword - Make use of DivRem's ability to accept a constant as the divisor
Admin:
  Tested on Cortex-A15


Version 5.35, 4.79.2.318. Tagged as 'Kernel-5_35-4_79_2_318'

IssueService -> BL Issue_Service.

The three subreasons were being dealt with as follows

8  - time only => convert time; read clock & convert that; mix; to UTC; set
15 - date only => convert date; to UTC; set
24 - both      => convert both; to UTC; set

So subreason 15 ended up setting the clock with the UTC date not taking into account any rollover/under due to the timezone. Now, the behaviour is

15 - date only => convert date; read clock & convert that; mix; to UTC; set

An example program to illustrate this is

 DIM block 128
 REM Example boundary case for -ve timezone
 REM *config.timezone -5
 REM TIME$="Sun,01 Jan 2013.19:01:00"

 REM Example boundary case for +ve timezone
 *config.timezone 5
 TIME$="Sun,01 Jan 2013.04:59:00"

 PRINT"Local => ";TIME$
 FOR i = 1 TO 31
  block?0=15
  $(block+1)="Sun,"+RIGHT$("0"+STR$i,2)+" Jan 2013"+CHR$0
  SYS"OS_Word",15,block
  OSCLI"echo <sys$time> <sys$date> <sys$year>"
 NEXT

Fault originates in Kernel-4_63-1_1_2_2.
Fixes ticket #230.

Version 5.35, 4.79.2.185. Tagged as 'Kernel-5_35-4_79_2_185'

Convrsions.s:
Don't trash R4 in OS_ConvertDateAndTime
Reject buffer sizes > 2G (seems reasonable for a time string, and allows us to claw back a flag bit).
PMF/osword.s:
Just call Territory_ConvertDateAndTime directly since that's all OS_ConvertDateAndTime does.
Trim some now irrelevant comments and switched out code.

Version 5.35, 4.79.2.144. Tagged as 'Kernel-5_35-4_79_2_144'

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:
  s/PMF/osword - Migrate the 2012 RTC fix from the HAL branch to the Cortex branch, plus apply similar fix to the code that handles HAL RTC devices (via new YearLOIsGood flag)
  s/PMF/i2cutils - Update HAL RTC year handling to correctly treat YearLO as either 2-bit int or 2-digit BCD
  hdr/RTCDevice - Add YearLOIsGood flag, revise NeedsYearHelp description
Admin:
  Tested on rev C2 beagleboard. Code seems to behave as intended.


Version 5.35, 4.79.2.98.2.21. Tagged as 'Kernel-5_35-4_79_2_98_2_21'

Also upissued to RISC OS 5.16 to release this in ROM
Detail:
  (list files and functions that have changed)
Admin:
tested at Castle (JB)
  (highlight level of testing that has taken place)
  (bugfix number if appropriate)


Version 5.35, 4.79.2.107. Tagged as 'Kernel-5_35-4_79_2_107'

Detail:
  HAL kernels (on the Cortex branch at least) now support HALDevice-based RTCs. If the kernels own RTC code is disabled or fails to detect an RTC, then after HAL_InitDevices is called the HALDevice list will be scanned for any HAL-resident RTC devices.
  Additionally, the RTCSupport flag (in Hdr:Machine.Machine), which was previously TRUE for all HAL kernels, can now be set to FALSE in HAL kernels to disable the kernels own IIC RTC code. This allows the unwanted legacy RTC code to be disabled for machines which are known to use HAL RTCs instead.
  hdr/RTCDevice - new header describing data structures used for HAL RTC device
  hdr/HALDevice - added RTCDevice device type, IIC serial bus type
  hdr/KernelWS - upgraded RTCFitted from a 1 byte field to 4 byte. It now stores either a null value (for no RTC), a value <2048 for an IIC RTC address, or a value >= 2048 for a RTCDevice ptr
  Makefile - added header export of hdr/RTCDevice
  s/GetAll - include hdr/RTCDevice
  s/NewReset - initialise HAL RTC after HAL_InitDevices if required
  s/PMF/i2cutils, s/PMF/osinit, s/PMF/osword - modifications to allow use of HAL RTC (and disallow use of builtin IIC RTC)
Admin:
  Tested on rev C2 beagleboard


Version 5.35, 4.79.2.98.2.11. Tagged as 'Kernel-5_35-4_79_2_98_2_11'

Detail:
 * Stopped calling the broken abort fixup code when running under VMSAv6.
   Might be desirable to update it, possibly farmed out to a separate module -
   still need to think about this.
 * Unaligned load optimisations can now be disabled by the global NoUnaligned
   flag for testing purposes.
 * Extended OS_ReadUnsigned to permit reading of 64-bit unsigned integers.
   See Docs.ReadUnsigned for more details. Also sped it up by using MLA
   (or UMLAL) for most digits rather than repeated addition.
 * Bugfix is OS_GSRead: an uninitialised r0 was being passed to
   OS_ReadUnsigned, causing undesirable effects on rare occasions.
Admin:
  Tested on a rev B7 beagleboard.

Version 5.35, 4.79.2.98.2.8. Tagged as 'Kernel-5_35-4_79_2_98_2_8'

Detail:
  Having scanned the kernel source for unaligned load code fragments which
  would abort on ARMv6 and v7 and not having found any, I took the opportunity
  to give them build-time switches to use unaligned LDR((S)H)/STR(H)
  instructions if built for a new enough platform. Also added a couple of
  cases of LDRSB that will benefit v4 CPUs and a few instances of the v6
  SXTH instruction, but since objasm doesn't yet understand it (and when it
  does, not everyone will have upgraded) they are currently written as
  DCI statements.
  Most of the changes are to OS_Word handlers, which are notorious in that
  their input/output block is not word-aligned.
Admin:
  Not tested, but it should at least build.

Version 5.35, 4.79.2.98.2.6. Tagged as 'Kernel-5_35-4_79_2_98_2_6'

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'

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'

Version 4.85. Tagged as 'Kernel-4_85'

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

Version 4.64. Tagged as 'Kernel-4_64'