GitLab

Detail:
  hdr/VduExt - Define new Service_DisplayChanged reason code for us to issue before anything actually happens. Define new Service_DisplayStatus reason codes for drivers to issue when they change their configuration/capabilities in some way.
  s/Utility - Listen out for Service_DisplayStatus
  s/vdu/vdudriver - When DisplayStatus_Changing/DisplayStatus_Changed is received for the current driver, translate into the appropriate DisplayChanged reason codes so that software which only cares about the current driver doesn't have two sets of service calls to listen out for
  s/vdu/vduswis - When switching driver in OS_ScreenMode 11, issue the new Service_DisplayChanged PreChanging reason code before we update the current GraphicsV driver VDU variable
Admin:
  Tested in Iyonix ROM softload


Version 5.35, 4.79.2.216. Tagged as 'Kernel-5_35-4_79_2_216'

  HAL graphics driver calls.  Added further debug capability
Detail:
  Added additional HAL call. minor code correction in hal graphicsv dispatcher
  Added DebugReg macro to aid debugging
Admin:
  (highlight level of testing that has taken place)
  (bugfix number if appropriate)


Version 5.35, 4.79.2.215. Tagged as 'Kernel-5_35-4_79_2_215'

ClearPhysRAM runs after ARM_Analyse and would wipe out the RAM copies of the various CP15 registers defining which caches are present, leading to the IMB_Full and IMB_Range operations skipping most of their job.
Space freed below DebuggerSpace by moving the RAM copies of the processor vectors up a bit.
Tested with a nobbled HAL which doesn't do the RAM clear, inspecting the workspace in a debugger to see it's preserved (only affects VSMAv6 models).

Version 5.35, 4.79.2.214. Tagged as 'Kernel-5_35-4_79_2_214'

Fix OS_SpriteOp 41 (read pixel) for 4K colour sprites. Update ECF patterns to work sensibly in true colour modes.

Detail:
  s/vdu/vdugrafg - Change SetupSprModeData to calculate SprReadNColour from log2bpp instead of the NColour mode variable - fixes the alpha component being lost when using OS_SpriteOp 41 to read from 4K colour sprites with alpha channels
  s/vdu/vdudriver - Change SetCol30 to generate more sensible ECF colour blocks when in true colour modes. Previously it would treat each byte of the 8 byte ECF pattern as a separate row, and replicate the byte 4 times to produce one colour word per row. However this isn't so great for true colour modes, especially if you have an alpha channel which needs specific values. So to fix the issue, take inspiration from how Paint assumed the ECF patterns worked, and treat 16bpp modes as being a 1x4 pattern and 32bpp modes as being a 1x2 pattern
Admin:
  Tested on BB-xM
  OS_SpriteOp 41 fix fixes Paint colour picker always returning 0 alpha when picking from 4K ARGB sprites
  ECF change fixes Paint's masked sprite background ECF pattern to display properly in true colour modes


Version 5.35, 4.79.2.213. Tagged as 'Kernel-5_35-4_79_2_213'

Detail:
  Early in OS startup, certain kernel memory areas (zero page, the privileged
  mode stacks, system heap, etc) are initially allocated only in the L2PT.
  The soft CAM is initialised later, using the L2PT as it is at that point.
  However, the pointer to the table that maps from page table cache policy
  bit layouts for the current CPU back to the platform-independent
  (OS_DynamicArea style) flags was corrupted, meaning that the CAM entries
  for these memory areas were initialised with a default value, which was
  non-cacheable non-bufferable. Application slots and most dynamic areas were
  unaffected, because once enough of the kernel was initialised to be able to
  use AMBControl or OS_ChangeDynamicArea, this function was no longer used.
  The problem comes when those pages come to be remapped; this could be due
  to requests for specific physical RAM pages, or (what I was actually
  investigating) DDT changing the access permissions on them. The problem was
  that as far as the CPU was concerned, the pages were cacheable/bufferable,
  but BangCam examined the soft CAM to decide what cache management
  operations to perform, and so got it wrong. The subsequent poke of the L2PT
  resulted in undefined CPU behaviour; in particular it seems to cause L2
  caches to throw a strop (enough so that disabling the L2 cache was enough
  to make DDT significantly more reliable).
Admin:
  It looks like this bug has been present on all HAL versions of RISC OS.
  Tested with DDT on a Beagleboard, previously the most crashy platform.
  There remains an IRQ (and FIQ) hole in OS_SetMemMapEntries when changing
  permissions on the page containing the processor vectors, which I haven't
  attempted to fix. Arguably, it should also issue Service_PagesSafe/Unsafe,
  in case anyone is DMAing to/from the remapped pages.

Version 5.35, 4.79.2.212. Tagged as 'Kernel-5_35-4_79_2_212'

One less warning in each of ARM600/VMSAv6.

Detail:
  s/ARM600, s/VMSAv6 - When processing an LDM which wasn't the "user mode registers" form, the initialisation of lr was being skipped, resulting in the registers being loaded from garbage addresses. Shuffle things around slightly so that the branch to label 34 works as intended.
Admin:
  Issue spotted by Willi Theiss
  Builds, but untested


Version 5.35, 4.79.2.211. Tagged as 'Kernel-5_35-4_79_2_211'

ModeFlag_GreyscalePalette handling improvements. Issue service calls on certain GraphicsV events. Sprite tweaks and fixes.

Detail:
  hdr/VduExt - Add reason codes used by Service_DisplayChanged & Service_DisplayStatus
  s/vdu/vdugrafg - Remove dependency on SpriteReason_BadReasonCode; just use the size of our lookup table instead. Alter SpriteOp lookup table so that unimplemented ops return an error instead of doing nothing. Fix PutSprite incorrectly using the slow GCOL action plotter if a request was made to plot a sprite using its mask but the sprite has none.
  s/vdu/vdugrafl - Update screen redirection handling to set ModeFlag_GreyscalePalette if switching output to a sprite with a greyscale palette or a RISC OS Select alpha mask. Restore the flag to its correct value when restoring screen output.
  s/vdu/vdupalxx - Update ModeFlag_GreyscalePalette in realtime as the palette is changed
  s/vdu/vduswis - Issue Service_DisplayChanged during OS_ScreenMode 11. Issue Service_DisplayStatus during OS_ScreenMode 65 & 66.
Admin:
  Tested on Iyonix, BB-xM


Version 5.35, 4.79.2.210. Tagged as 'Kernel-5_35-4_79_2_210'

ARM600:
Decode LDRSB, do the sign extend, and fault all the other loads and stores not understood.
VMSAv6:
As the loads and stores not understood are now vetted properly, it should be safe to UseProcessTransfer (previously they'd have been disassembled incorrectly).
Paste in LDRSB code from ARM600.
Fix dubious looking access of CurrentGraphicsVDriver from WsPtr.

Tested briefly on StrongARM.

Version 5.35, 4.79.2.209. Tagged as 'Kernel-5_35-4_79_2_209'

Detail:
  s/Kernel - UndPreVeneer, PAbPreVeneer and AdXPreVeneer all need to take into account the location of ZeroPage. In reality UndPreVeneer is the only one that matters, as the other two aren't really used.
Admin:
  Tested on Raspberry Pi with high processor vectors
  Undefined instructions now generate errors correctly


Version 5.35, 4.79.2.208. Tagged as 'Kernel-5_35-4_79_2_208'

Fix dodgy mode changes on Raspberry Pi. Fix crash when switching to a driver which uses DA 2 if DA 2 isn't already large enough.

Detail:
  s/vdu/vdudriver:
  - Fix bug in ModeChangeSub which caused the VariableFramestore flag to be ignored, resulting in unreliable mode changes on the Raspberry Pi.
  - Changed InitialiseMode to reset a few more variables when preparing to use a driver which uses DA 2. Without this the screen DA handler will likely crash when attempting to resize the DA for the initial mode change.
Admin:
  Tested on Raspberry Pi


Version 5.35, 4.79.2.207. Tagged as 'Kernel-5_35-4_79_2_207'

Detail:
  s/MemInfo - Fix OS_Memory 0 physical-to-logical conversion returning bad addresses for most cases due to R5 being modified by physical_to_ppn (bug introduced in revision 4.4.2.20)
  s/vdu/vdudriver - Fix some VDU driver variables not being initialised correctly when switching GraphicsV driver
  s/vdu/vdugrafv - Fix handling of VSync events from GraphicsV drivers other than driver zero
  s/vdu/vduswis - Fix abort when OS_ScreenMode 11 is passed a bad driver number
Admin:
  Tested on Raspberry Pi
  There still seems to be a bug lurking somewhere when switching to a GraphicsV driver that uses DA2; the system will crash horribly unless DA2 is already a suitable size for the initial mode change


Version 5.35, 4.79.2.206. Tagged as 'Kernel-5_35-4_79_2_206'

Fix CAO pointer being reset incorrectly when calling OS_ExitAndDie with zero page relocation enabled

Detail:
  s/MoreSWIs - OS_ExitAndDie now correctly sets the CAO to zero when ZeroPage is non-zero
Admin:
  Tested on BB-xM with high processor vectors
  Issue originally spotted by Sprow


Version 5.35, 4.79.2.205. Tagged as 'Kernel-5_35-4_79_2_205'

Detail:
  hdr/Options, s/ArthurSWIs, s/ChangeDyn, s/PMF/KbdDrA1, s/PMF/key, s/vdu/vdugrafa, s/vdu/vdugrafd, s/vdu/vdugrafhal, s/vdu/vdugrafv, s/vdu/vdumodes, s/vdu/vduwrch:
  - Strip out DoingVdu build switch (did nothing)
  - Strip out Japanese16BitSound switch (did nothing)
  - Strip out MakeModeSelectorsForModeNUmbers switch (altered the mode list structures, but there wasn't any code to do anything with the new data)
  - Strip out remaining uses of UseGraphicsV switch (now hardwired to {TRUE})
  - Strip out ShadowROM switch (altered FixedAreasTable to show the shadow mapping, but code to create the mapping is missing)
  - Strip out PollMouse switch (old Archimedes-era debug/development option)
Admin:
  Tested on BB-xM
  Builds to same binary as previous version


Version 5.35, 4.79.2.204. Tagged as 'Kernel-5_35-4_79_2_204'

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...

The kernel will use RTC_Read and RTC_Write to access the hardware clock, while maintaining the software clock as before.
Makefile: header export is now in the RTC module's sources
KernelWS: remove RTCFitted flag
NewReset: sync the time after the module init
i2cutils: deleted clock chip code
osinit: move OS_ResyncTime into PMF/realtime
realtime: mostly packages up ordinals and calls the respective SWI

Tested on IOMD softload.

Version 5.35, 4.79.2.202. Tagged as 'Kernel-5_35-4_79_2_202'

IssueService -> BL Issue_Service.

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'

There's an exit case from CheckYear which skips the actual clock read, so add an explicit call to RTCToRealTime for that case (cf. OS_ResyncTime).
Remove use of ARMv2 era MULTIPLY macro, just use MUL.
Tested on IOMD with a HAL RTC.

Version 5.35, 4.79.2.200. Tagged as 'Kernel-5_35-4_79_2_200'

Want LSR not ROR otherwise in the need help + HAL + 2 bit case the IIC address in R1 comes out as &800000A1.
Added HAL device ids for a couple more RTC devices.

Version 5.35, 4.79.2.199. Tagged as 'Kernel-5_35-4_79_2_199'

Detail:
  s/vdu/vdugrafh - Fixed SpriteMaskAddr to use the right Log2BPC value when generating addressed for alpha masks. Fix ReadPixelMask to return 255 when sprite has now mask, but mode word has wide mask bit set.
Admin:
  Tested on BB-xM
  Reading/writing alpha mask pixels now works properly across the whole image


Version 5.35, 4.79.2.198. Tagged as 'Kernel-5_35-4_79_2_198'

Fix plotting of RISC OS 5 type sprites and masks. Fix hang when attempting to report "alpha mask not supported" error. Fix reading/writing of alpha mask pixels.

Detail:
  s/vdu/vdugrafg - Fixed PutSprite and PlotMask to correctly deal with RISC OS 5 type sprite mode words. Fix infinite loops in PutSpriWideMaskErr casued by R14 getting trashed.
  s/vdu/vdugrafh - Fixed SpriteMaskAddr malfunctioning when trying to calculate addresses in alpha masks. Minor ReadPixelMask & WritePixelMask optimisations.
  s/vdu/vduswis - Fixed OS_ScreenMode 13 & 14 to count "G2" as a valid colour specifier.
Admin:
  Tested on BB-xM
  Should hopefully fix the random hangs reported on the forums when trying to use sprites with alpha masks


Version 5.35, 4.79.2.197. Tagged as 'Kernel-5_35-4_79_2_197'

No longer returns a RISC OS specific error block to the HAL, instead uses a platform agnostic IICStatus value.

Version 5.35, 4.79.2.196. Tagged as 'Kernel-5_35-4_79_2_196'

Detail:
  s/vdu/vduswis - Add an extra LTORG that's within range of LDR r14,=&1FFF instruction
Admin:
  Tested in Iyonix softload
  Fixes build errors for Tungsten ROM, should fix IOMD + BCM2835 too.


Version 5.35, 4.79.2.195. Tagged as 'Kernel-5_35-4_79_2_195'

Add support for the new RISC OS 5 style sprite mode word. Add partial support for alpha channel sprite masks. Implement OS_ScreenMode reasons 13-15

Detail:
  ECFShift/ECFYOffset:
  - hdr/PublicWS - Add ECFShift and ECFYOffset to list of public exports (SpriteExtend was using hardcoded values). Rearrange exports so that VduWorkspace exports are now labelled as such.
  - hdr/KernelWS - Make sure ECFShift & ECFYOffset match their exported locations
  - hdr/OSRSI6, s/Middle - Add OS_ReadSysInfo 6 items 83 & 84, for reading ECFYOffset and ECFShift locations
  Mode flags/VDU variables:
  - Makefile - Add hdr/VduExt to the C header exports
  - hdr/VduExt - Get rid of NotRVVTBarWobblyBits macro and defined VDU variables manually so that Hdr2H will handle them. Begin replacing overly generic 'Flag_*' mode flag definitions with 'ModeFlag_*' instead. Define new flags as required by the new screen/sprite modes. Add OS_ScreenMode reason codes and mode selector format (from s.vdu.vdudecl)
  - NewModes/NEWF2, NewModes/O...

Step changes in RealTime are now accompanied by a service call. Note the initial read isn't announced, mainly because this is before the module chain is started so nobody's listening anyway.

Version 5.35, 4.79.2.193. Tagged as 'Kernel-5_35-4_79_2_193'

Version 5.35, 4.79.2.192. Tagged as 'Kernel-5_35-4_79_2_192'

Version 5.35, 4.79.2.191. Tagged as 'Kernel-5_35-4_79_2_191'

Version 5.35, 4.79.2.190. Tagged as 'Kernel-5_35-4_79_2_190'

The StrongARM TRM (and hints from ARM600.s revision 4.3.2.2) show that the StrongARM will only do burst writes to memory marked as C=1 B=1, but by default RISCOS_AccessPhysicalAddress only allows bufferable.
So, checking for StrongARM first, two extra snippets are enabled - first mark as C=1 B=1, then afterwards clean the cache before moving onto the next 1MB.

On a StrongARM Kinetic these burst writes improve the RAM clear from ~60ms per MB to 40ms per MB. For a 256MB SODIMM that's over 5s knocked off the boot time.
Other memory configurations will be similarly improved, though 256MB is of course the maximum the motherboard can hold.

Tested in ROM on a Risc PC with StrongARM and ARM710.

Version 5.35, 4.79.2.189. Tagged as 'Kernel-5_35-4_79_2_189'

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'

GPIODevice: defines for OMAP4 targets
KernelWS: bump up the IICBus_Count from 3 to 4

Version 5.35, 4.79.2.187. Tagged as 'Kernel-5_35-4_79_2_187'

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'

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'

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'

Not tagged.

Not tagged.

SystemName, ROMSizeOffset, HAL32, HAL26 only used here, moved here.
Remove uses of "M_" booleans, apparently that's bad form.
Fix SWIDespatch_Size for the non thumb capable case (was ASSERTing).
Swapped UserMemStart for AppSpaceStart.
Removed last use of OldComboSupport (pre Medusa!).
Removed switch 'CDVPoduleIRQs', a correction to the machine definitions mean this can now simply be switched on NumberOfPodules (previously, IOMD couldn't chain podule interrupts).
Take out disabled sub interrupt support - it's in CVS if you want to try to get it working.
Moved ConfiguredLang to 11 for everyone, it only matters if !Boot fails, and no harm in making it common for 5.xx onwards.

Version 5.35, 4.79.2.183. Tagged as 'Kernel-5_35-4_79_2_183'

Add new HAL call, HAL_IRQMax, to allow the kernel to determine the number of IRQ lines/devices at runtime

Detail:
  hdr/HALEntries - Reuse the old HAL_MonitorLeadID call number for HAL_IRQMax
  hdr/KernelWS - Rearrange CursorChunkAddress workspace a bit. Removed unused OldOscliBuffs and a couple of pre-HAL allocations, and made DefIRQ1Vspace the same size for all build configs. Add an IRQMax var to zero page workspace to cache the value returned by HAL_IRQMax.
  s/HAL - Initialise IRQMax shortly after HAL initialisation. Revise ClearPhysRAM comment to reflect which vars are preserved in the current version of the code.
  s/NewIRQs - Strip out a fair bit of pre-HAL code to make the file more readable. Update OS_ClaimDeviceVector/OS_ReleaseDeviceVector to check against IRQMax instead of the MaxInterrupts compile-time limit.
Admin:
  Tested on BB-xM, Iyonix, RiscPC, Pi
  Although the OS will now nominally adapt at runtime to how many IRQ devices there are, it's still using MaxInterrupts as an upper limit as the device claimant table has a fixed memory allocation.


Version 5.35, 4.79.2.182. Tagged as 'Kernel-5_35-4_79_2_182'