GitLab

Detail:
  s/TickEvents:
  - Change initial TickNodeLeft check in ProcessTickEventChain to exit on HI rather than NE. This fixes a case where the ticker event chain can become corrupted if ProcessTickEventChain is re-entered while in the middle of processing multiple nodes which are due to fire at the same time (after initial node is removed from the list, head node will be left with a TickNodeLeft value of 0)
  - Move "IRQ's off again" PSR write to be after the 10 label, to ensure that IRQs are off before we examine/process the next node (naughty CallEvery may have exited with IRQs enabled)
  - Stop using crusty old WritePSRc macro (currently generates 4 instructions for something that should be 1)
  - Also get rid of ARM2-era NOPs
  - Optimise CallEvery check to be MOVS rather than LDR + CMP
Admin:
  Tested on Pandaboard
  Should fix problem reported on forums with apparent wrap-around of TickNodeLeft value of first node: https://www.riscosopen.org/forum/forums/5/topics/3544
  May also fix other ticker corruption problems: https://www.riscosopen.org/forum/forums/4/topics/2708


Version 5.35, 4.79.2.278. Tagged as 'Kernel-5_35-4_79_2_278'

hdr/ExportVals: the copyright header insertion got a bit confused with some of the file contents
TickEvents.s: a bad merge from Ursula branch 4.1.4.2 to trunk 4.2 left behind unmatched push/pull where TickIrqReenter had been removed
hdr/Options & NewIRQs.s: collapse remaining TickIrqReenter switches
osinit.s: when ZeroPage is in a top bit set address only the last buffer pointer would get zeroed

Tip offs from eagle eyed Tim Baldwin.

Version 5.35, 4.79.2.201. Tagged as 'Kernel-5_35-4_79_2_201'

OS_CallAfter and OS_CallEvery were treating the delay in R0 as a signed number, limiting its possible range. The PRM didn't require this (a -ve delay doesn't make sense, so implicitly times are unsigned), reworked to allow times up to 0xFFFFFBFF.
Aside:
  OSLib exports these functions as 'int', but it doesn't seem to make a distinction for unsigned versus signed anyway (other unsigned arguments are plain int too)
  The 'callx' library was already prototyped with unsigned times back in 1997

Added comment to hdr/Options about FirstUnpluggableModule - since the keyboard and mouse drivers got moved out of the kernel in 3.50, the original intent (to not allow you to unplug vital modules) has long since been lost, and really the only use of this value is to save 8 bits of CMOS frugal bits.

Version 5.35, 4.79.2.181. Tagged as 'Kernel-5_35-4_79_2_181'

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'

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'

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:
  Most of the centisecond timers were incremented very early in the Timer0
  interrupt routine, but MetroGnome was incremented after we had called
  TickerV. Routines on TickerV are allowed to enable interrupts, so any
  interrupt routines that use OS_ReadMonotonicTime and IRQRQA are unable to
  accurately determine if the monotonic time is one tick out-of-date or not.
  MetroGnome is now incremented with the other timers.
Admin:
  Tested with the timer code in STB-400 MPEGDriver.

Version 5.22. Tagged as 'Kernel-5_22'

Version 4.83. Tagged as 'Kernel-4_83'