GitLab

* Update OS_ScreenMode 11's handling of drivers which fail to
initialise. If there was no previous driver, then instead of trying to
restore that nonexistant driver, stick with the new one. This is mainly
to help with the case where the kernel's built in modes aren't accepted
by the driver, and valid modes only become available once an MDF is
loaded (this can happen with early OMAP3 chip revisions, which have very
tight sync & porch limits, causing 90% of the kernel's modes to be
rejected). If the kernel was to revert to the "no driver" state, then
loading the MDF would still leave you with no video output.
* Since we can now end up in a state where a driver is selected but
hasn't been programmed yet, update OS_Byte 19 to detect this (via the
magic ScreenBlankDPMSState value of 255) and avoid waiting for VSync
* Update RemovePages & InsertRemovePagesExit (screen DA handlers) to
avoid infinite loops if the screen DA gets shrunk to zero size (was seen
while attempting to complete the !Boot sequence while no driver was
active)

Version 6.33. Tagged as 'Kernel-6_33'

Detail:
  s/vdu/vduswis - Fix 18 year old register corruption bug in FindOKMode which would prevent it from falling back to Service_ModeTranslation if Service_ModeExtension returned a VIDC list but the VIDC list was rejected by the GraphicsV driver
  s/vdu/vdudriver - Also, change a couple of error cases in ModeChangeSub so that they use the "Screen mode not available" error instead of the incorrect "Not enough screen memory" error.
Admin:
  Tested on Raspberry Pi 3
  Fixes issue reported on forums where if AnyMode is loaded, numbered modes in unsupported colour depths weren't being replaced with substitutes (although note that there are still some AnyMode-related issues to resolve)
  https://www.riscosopen.org/forum/forums/4/topics/12773


Version 6.16. Tagged as 'Kernel-6_16'

Detail:
  Over the years the OS's substitute screen mode selection logic has grown to be a tangled mess, and the logic it does implement isn't always very useful. Additionally, the kernel is structured in such a way that it can be hard for modules to override it.
  This set of changes aims to fix the many of the problems, by doing the following:
  - Moving all substitute mode selection logic out of the core VDU driver code and into a Service_ModeTranslation handler. This means you now only have one place in the kernel to look instead of several, and modules can override the behaviour by claiming/blocking the service call as appropriate.
  - Moving handling of the built-in VIDC lists out of the core VDU driver code and into a Service_ModeExtension handler. This means programs can now inspect these VIDC lists by issuing the right service call (although you are essentially limited to lists which the GraphicsV driver is OK with)
  - Moving *TV interlace & offset adjustment logic into the Service_ModeExtension handler, since they're legacy things which can be handled more cleanly for MDF/EDID (and the old code was poking memory the kernel didn't own)
  - Adding a Service_EnumerateScreenModes implementation, so that if you end up in the desktop with ScreenModes non-functional, the display manager at least has something useful to show you
  - Enhancing the handling of the built-in numbered modes so that they are now available in any colour depth; the Service_ModeExtension handler (and related handlers) treat the builtin VIDC lists as a set of mode timings, not a discrete set of modes
  - Substitute mode selection logic is a complete re-write. Instead of trying a handful of numbered fallback modes, it now tries:
    - Same mode but at higher colour depths
    - Same mode but at lower colour depths
    - Alternate resolutions (half-width mode with no double-pixel if original request was for double-pixel, and default resolution for monitor type)
  - Combined with the logic to allow the builtin VIDC lists to be used at any colour depth, this means that the kernel should now be able to find substitute modes for machines which lack support for <=8bpp modes (e.g. OMAP5)
  - Additionally the mode substitution code will attempt to retain as many properties of the originally requested mode as possible (eigen values, gap mode type, etc.)
  Other improvements:
  - The kernel now actually vets the builtin VIDC lists instead of assuming that they'll work (which also means they'll have the correct ExtraBytes value, where applicable)
  - The kernel now uses GraphicsV 19 (VetMode2) to vet the mode during the mode switch process, using the result to detect where the framebuffer will be placed. This allows for GraphicsV drivers to switch between DA 2 and external framestores on a per-mode basis.
  - The kernel now supports mode selectors which specify LineLength values which are larger than necessary; this will get translated to a suitable ExtraBytes control list item (+ combined with whatever padding the driver indicates is necessary via the VetMode2 result)
  File changes:
  - hdr/KernelWS - Reserve space for a VIDC list, since the Service_ModeExtension implementation typically can't use the built-in list as-is
  - s/Arthur3 - Issue Service_ModeFileChanged when the configured monitor type is changed, so that DisplayManager + friends are aware that the set of available modes has changed
  - s/GetAll - Fiddle with GETs a bit
  - s/MemMap2 - Extra LTORG
  - s/NewIRQs - Small routine to install/uninstall false VSync routine (previously from PushModeInfo, which wasn't really the appropriate place for it)
  - s/Utility - Hook up the extra service call handlers
  - s/vdu/legacymodes - New file containing the new service call implementations, and some related code
  - s/vdu/vdudecl - Move mode workspace definition here, from vdumodes
  - s/vdu/vdudriver - Remove assorted bits of mode substitution code. Plug in new bits for calling GraphicsV 19 during mode set, and deal with ExtraBytes/LineLength during PushModeInfo
  - s/vdu/vdumodes - Move some workspace definitions to s/vdu/vdudecl. Tweak how the builtin VIDC lists are stored.
  - s/vdu/vduswis - Rip out more mode substitution code. Issue Service_ModeFileChanged when monitor type is changed by OS_ScreenMode.
Admin:
  Tested on Raspberry Pi 3, Iyonix, IGEPv5


Version 6.14. Tagged as 'Kernel-6_14'

Detail:
  s/vdu/vduswis - Don't use RMVForCurrentMode when R0 = ModeNo, only use it if R0 is -1. This ensures that results for explicitly-specified modes will always represent the base properties of the mode and won't be influenced by any unusual properties of the current mode, e.g. LineLength/ScreenSize alterations caused by driver-specific framebuffer padding.
Admin:
  Tested on Raspberry Pi 3


Version 5.83. Tagged as 'Kernel-5_83'

Detail:
  s/vdu/vdudriver, s/vdu/vdumodes - Re-introduce TTX256 so that 8bpp teletext will be used if no MDF is loaded
  s/vdu/vdudriver - If the video driver didn't support the native mode 7 colour depth, ModePromoTable was swapping it for another mode number, preventing the AltTTX code in FindOKMode from operating. So, skip the ModePromoTable check for mode 7.
  s/vdu/vduswis - Minor correction to alternate teletext mode search; 1<<5 = 32bpp, so stop search at log2bpp of 6
Admin:
  Tested on Raspberry Pi


Version 5.74. Retagged as 'Kernel-5_74'

Detail:
  This set of changes:
  * Adds support for the T, TX and TY mode string elements (as per RISCOS Ltd)
  * Adds support for entering arbitrary-resolution teletext modes by using mode selector blocks with the Teletext mode flag set
  * ScrRCol and ScrBRow mode variables can be provided in the mode selector in order to restrict the number of text rows/columns in teletext modes (as per RISCOS Ltd)
  * If the rows / columns are restricted in this manner then the text window will be centered on the screen, to try and avoid things looking too ugly (no variable text scaling implemented)
  * For HiResTTX, all colour depths >= 4bpp are now supported by teletext. This essentially makes the TTX256 switch obsolete.
  * If the "native" mode 7 is unavailable then the kernel will try a series of fallback resolutions & colour depths in an effort to find a combination that works
  Known bugs/issues:
  * Teletext column count has a max limit of 255 due to TTXDoubleCounts being a byte array
  * If there's a border around the text window, the border will not be refreshed when changing transparency modes using a VDU 23,18,0 sequence
  * ScreenLoad looks like it can overflow the LargeCommon buffer (no buffer size check) - needs fixing before LargeCommon can be safely shrunk below (Old)TTXMapSize
  File changes:
  - hdr/KernelWS - Make CharWidth non-conditional. Adjust handling of teletext workspace; it's now allocated from the system heap to allow it to cope with arbitrary screen sizes
  - s/vdu/vdu23 - Make CharWidth non-conditional
  - s/vdu/vducursoft - Make CursorTeletext cope with arbitrary colour depths, make CharWidth non-conditional, remove hard-coded teletext values
  - s/vdu/vdudriver - Deal with teletext workspace allocation during ModeChangeSub. Deal with selecting teletext modes (and validating colour depth) in GenerateModeSelectorVars.
  - s/vdu/vdugrafl - Make CharWidth non-conditional. Calculate offset required for text window centering.
  - s/vdu/vdumodes - Remove TTX256
  - s/vdu/vduswis - Try other teletext modes if native mode 7 not available. Extend OS_ScreenMode reason codes to cope with teletext mode strings.
  - s/vdu/vduttx - Update to use dynamic workspace. Replace various hardcoded values with variable lookups. Update character plotting + colour/palette selection to work with true-colour modes if HiResTTX.
  - s/vdu/vduwrch - Move some useful code into a subroutine. Update FastCLS to cope with true-colour teletext. Update AddressR0R1 to cope with text window centering offset. Make CharWidth non-conditional.
Admin:
  Tested on Raspberry Pi, BB-xM
  VDU 23,18,0 in 256-colour teletext now works correctly (previously 64-colour mode was in use, causing palette update to be ruined by VIDC1-mangling)


Version 5.74. Tagged as 'Kernel-5_74'

Detail:
  This change gets rid of the following switches from the source (picking appropriate code paths for a 32bit HAL build):
  * FixCallBacks
  * UseProcessTransfer
  * CanLiveOnROMCard
  * BleedinDaveBell
  * NewStyleEcfs
  * DoVdu23_0_12
  * LCDPowerCtrl
  * HostVdu
  * Print
  * EmulatorSupport
  * TubeInfo
  * AddTubeBashers
  * TubeChar, TubeString, TubeDumpNoStack, TubeNewlNoStack macros
  * FIQDebug
  * VCOstartfix
  * AssemblingArthur (n.b. still defined for safety with anything in Hdr: which uses it, but not used explicitly by the kernel)
  * MouseBufferFix
  * LCDInvert
  * LCDSupport
  * DoInitialiseMode
  * Interruptible32bitModes
  * MouseBufferManager
  * StrongARM (new CacheCleanerHack and InterruptDelay switches added to hdr/Options to cover some functionality that StrongARM previously covered)
  * SAcleanflushbroken
  * StrongARM_POST
  * IrqsInClaimRelease
  * CheckProtectionLink
  * GSWorkspaceInKernelBuffers
  * EarlierReentrancyInDAShrink
  * LongCommandLines
  * ECC
  * NoSPSRcorruption
  * RMTidyDoesNowt
  * RogerEXEY
  * StorkPowerSave
  * DebugForcedReset
  * AssembleKEYV
  * AssemblePointerV
  * ProcessorVectors
  * Keyboard_Type
  Assorted old files have also been deleted.
Admin:
  Identical binary to previous revision for IOMD & Raspberry Pi builds


Version 5.51. Tagged as 'Kernel-5_51'

Detail:
  This change gets rid of the following switches from the source (picking appropriate code paths for a 32bit HAL build):
  * HAL
  * HAL26
  * HAL32
  * No26bitCode
  * No32bitCode
  * IncludeTestSrc
  * FixR9CorruptionInExtensionSWI
  Various old files have also been removed (POST code, Arc/STB keyboard drivers, etc.)
Admin:
  Identical binary to previous revision for IOMD & Raspberry Pi builds


Version 5.49. Tagged as 'Kernel-5_49'

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'

Detail:
  s/vdu/vduswis - Fix conversion of mode specifier to mode string so that the X eigen value is only reported in the mode string if it was included in the mode specifier; previously was erroneously basing the decision on whether the Y eigen was specified, resulting in e.g. "EX4294967295" if only the Y eigen was included
  - Fix a stack imbalance causing the conversion of mode string to mode specifier crashing (typically with branch through zero) if an invalid eigen value is specified in the string (e.g. EX-1 as above)
Admin:
  Tested on Raspberry Pi


Version 5.35, 4.79.2.302. Tagged as 'Kernel-5_35-4_79_2_302'

Detail:
  s/PMF/osinit, s/vdu/vdudriver - Move GraphicsV_StartupMode call from InitialiseMode to TranslateMonitorLeadType. This means (a) it'll only be used if the CMOS mode is set to 'auto' and (b) the returned mode can more easily be read by other modules via OS_ReadSysInfo 1.
  s/vdu/vduswis - Make OS_CheckModeValid act as if we have practically unlimited screen memory if using a GraphcisV driver with variable external framestore. In this case it's the driver should have already OK'd the memory requirements from within the VetMode call issued by FindOKMode - although the check won't be fully valid if we're checking for a shadow mode as the driver currently isn't told how many screen banks are required.
Admin:
  Tested on Raspberry Pi
  OS_CheckModeValid fix ensures valid modes which require large amounts of VRAM are reported correctly when we're currently in a low-memory mode


Version 5.35, 4.79.2.220. Tagged as 'Kernel-5_35-4_79_2_220'

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'

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'

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'

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 storing the current GraphicsV driver number and the driver list
  * hdr/Options - Remove obsolete InverseTextTransparency option
  * hdr/VduExt - Add VDU variable 192 for storing GraphicsV driver number (same as ROL's VideoV driver number). Remove old 'Flag_*' mode flag definitions (use new 'ModeFlag_*' defintions instead). Add new OS_ScreenMode reason codes.
  * s/ARM600, s/VMSAv6, s/vdu/vdu23, s/vdu/vdugrafa, s/vdu/vdugrafd, s/vdu/vdupalxx, s/vdu/vdupointer, s/vdu/vduwrch - Strip out pre-GraphicsV code. Update GraphicsV code to use correct driver number.
  * s/ArthurSWIs - Pass the default GraphicsV claimant the VduDriverWorkSpace instead of ZeroPage
  * s/Getall - Add Hdr:VIDCList and s/vdu/VduGrafHAL to list of GETs
  * s/NewIRQs - Remove HAL VSync IRQ initialisation, is now handled by grafvhal. Remove old HAL VsyncIRQ entry point, all VSyncs are now handled by VsyncIRQ_ExtEntry.
  * s/PMF/osbyte - Stop OS_Byte 19 waiting forever if no video driver is active
  * s/PMF/osinit - Remove HAL VSync IRQ initialisation, is now handled by grafvhal
  * s/vdu/vducursoft - Use new workspace variable names and flag names
  * s/vdu/vdudecl - Remove old HALDAG_* definitions, GVDAG_* definitions are used instead. Add definition of the per-driver workspace structure and flags.
  * s/vdu/vdudriver - Remove pre-GraphicsV code. Update InitialiseMode to check for and initialise a HAL driver. Use cached driver features word in a few places instead of calling GraphicsV each time. Update PalIndexTable to disable VIDC mangling of 16bpp gamma tables.
  * s/vdu/vdugrafv, s/vdu/vdugrafhal - HAL<->GraphicsV code split off into its own file (vdugrafhal). Default GraphicsV claimant now only deals with VSync events for the active driver.
  * s/vdu/vdumodes - Get rid of old VIDC List type 3 definiton; now in hdr/VIDCList
  * s/vdu/vduswis - Added OS_ScreenMode reason codes 11 and 64-68 for registering, deregistering, selecting and enumerating GraphicsV drivers. Update mode set code to not bother checking if the driver supports the pixel format; instead we assume that the driver's vet mode call will do the check for us.
Admin:
  Tested in Tungsten, IOMD, OMAP3 & BCM2835 ROMs
  Requires HdrSrc-2_38 and updated video driver modes


Version 5.35, 4.79.2.203. Tagged as 'Kernel-5_35-4_79_2_203'

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'

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/OldPSSrc, NewModes/PSSrc, s.vdu.vdu23, s.vdu.vducursoft, s.vdu.vdudriver, s.vdu.vdugrafg, s.vdu.vdugrafj, s.vdu.vdugrafl, s.vdu.vdumodes, s.vdu.vdupal10, s.vdu.vdupal20, s.vdu.vdupalette, s.vdu.vdupalxx, s.vdu.vduwrch - Renaming Flag_* to ModeFlag_*
  - s.vdu.vdudecl - Remove OS_ScreenMode reason codes & mode selector format definitions; these are now in hdr/VduExt. Flag_* -> ModeFlag_* renaming.
  - s.vdu.vdupalxx - Apply a greyscale palette in PV_SetDefaultPalette if the greyscale mode flag is set
  New sprite types:
  - s.vdu.vdudriver - Extend GenerateModeSelectorVars to deal with the wide mask flag, 64K sprites, and the new RISC OS 5 sprite mode word format.
  - s.vdu.vdugrafdec - Store more information about the sprite in the SprReadNColour ... SprLog2BPC block.
  - s.vdu.vdugrafg - Update SpriteVecHandler to be able to detect whether RISC OS 5 format sprites are allowed palettes. Update SetupSprModeData to store the extra sprite info that's defined in vdugrafdec. Update PutSprite to fault any sprites with wide masks - SpriteExtend must be used for that (once implemented!)
  - s.vdu.vdugrafh - Update WritePixelColour to avoid temporary poking of NColour VDU variable for 8bpp sprites. Correctly replicate data when writing to RISC OS 5 format sprites. Update ReadPixelMask, WritePixelMask, SpriteMaskAddr, GetMaskspWidth to deal with wide masks. Delete obsolete bounce_new_format_masks routine.
  - s.vdu.vdugrafi - Comment updated to reflect new reality
  - s.vdu.vdugrafj - Get rid of unused code block in CreateHeader/PostCreateHeader. Update SanitizeSGetMode to generate RISC OS 5 style sprite mode words where applicable. Update DecideMaskSize to rely on GetMaskspWidth for calculating mask width.
  - s.vdu.vdugrafl - Update SwitchOutputToSprite/SwitchOutputToMask to deal with the new sprite formats. Allow PushModeInfoAnyMonitor to fail.
  - s.vdu.vduswis - Extended OS_ReadModeVariable to cope with new sprite types
  Misc:
  - s.vdu.vdudriver - Fixed bug with VIDCList copying where any -1 value in the structure would terminate the copy, instead of only -1 as a control item number
  - s.vdu.vduswis - Implemented OS_ScreenMode 13 (Mode string to specifier), 14 (mode specifier to string), and 15 (set mode by string). Mostly as per ROL's specs, but minus support for teletext attributes, and plus support for new RISC OS 5 attributes (L... layout specifier, 4096 & 24bpp packed modes, etc.)
  - s.vdu.vduwrch - Pick correct default text colours for the new modes
Admin:
  Tested on BB-xM
  Part of an implementation of the Extended Framebuffer Format spec:
  http://www.riscosopen.org/wiki/documentation/show/Extended%20Framebuffer%20Format%20Specification


Version 5.35, 4.79.2.194. Tagged as 'Kernel-5_35-4_79_2_194'

Temporary assignment changed to one from Hdr:NewErrors.

Version 5.35, 4.79.2.176. Tagged as 'Kernel-5_35-4_79_2_176'

Variously the call to TranslateError was either followed (outside the switch) by an unnecessary SETV, or missing SETV for the non international case.
Added DMA controller HAL device for IOMD.

Version 5.35, 4.79.2.174. Tagged as 'Kernel-5_35-4_79_2_174'

Detail:
  Docs/RPiNotes - Deleted, contents no longer relevant
  s/HAL, s/Kernel, s/vdu/vduswis, s/pmf/key - Cleaned up debug code
  s/NewIRQs - No need to piggy back on timer 0 IRQ to generate a fake VSync; PushModeInfo already claims/releases TickerV as appropriate if video driver doesn't provide a VSync IRQ.
  s/NewReset - Re-enable LookForHALRTC call, the stack imbalance bug was fixed before the Pi changes were merged in
  s/vdu/vducursoft - Streamline PostWrchCursor a bit by only preserving R14 around RestorePointer if the software pointer is in use
  s/vdu/vdudriver - Amend ModeChangeSub improvements to ensure old external framestore handling logic is used if driver doesn't support framestore growth/realloc
Admin:
  Tested on Raspberry Pi with high processor vectors
  Kernel now looks to be in a good state for merging back into HAL branch
  Note - Software mouse pointer support in vducursoft only checks HALVideoFeatures, so doesn't take into account the capabilities of any GraphicsV driver that may be in use.


Version 5.35, 4.79.2.147.2.20. Tagged as 'Kernel-5_35-4_79_2_147_2_20'

Detail:
  hdr/HALEntries - Add new HAL_Video_StartupMode HAL entry to allow the HAL to specify a startup mode
  s/HAL, s/Kernel - Tweaked debug routines
  s/vdu/vdudriver - Make use of HAL_Video_StartupMode in InitialiseMode to decide what initial mode should be. Clean up some hacks & debug. Improve handling of external framestores; if bit 5 of GraphicsV_DisplayFeatures r0 is set, the kernel will now allow the display driver to grow/shrink/move its framestore in response to mode changes.
  s/vdu/vdugrafv - Adjust default GV_FramestoreAddress implementation to only claim vector if HAL returns a framestore
  s/vdu/vduswis - Re-enable FindOKMode
Admin:
  Tested on Raspberry Pi with high processor vectors


Version 5.35, 4.79.2.147.2.18. Tagged as 'Kernel-5_35-4_79_2_147_2_18'

No accepts  r0 = b31-24 set 0
                 b23-16 fully qualified IIC address
                 b15-0  starting offset
            r1 = buffer pointer
            r2 = number of bytes to tranfer
            r4 = b31-24 display number
                 b23-16 head
                 b15-0  reason code (=14)
Now returns r0 = result codes as per HAL_IICTransfer()
            r1 = buffer pointer incremented by number of bytes transferred
            r2 = number of bytes *not* transferred
            r4 = 0
Removed '_' after Video in entry numbers to be consistent with other HAL entry naming, and HAL_VideoFlybackDevice.
Added IICStatus return numbers to Hdr:HALEntries.
Stop calling HAL_MonitorLeadID as only IOMD implemented it - just guess VGA until the graphics driver says otherwise.

Version 5.35, 4.79.2.159. Tagged as 'Kernel-5_35-4_79_2_159'

While the HAL and kernel were being split some temporary macros were used for the bits being worked on, after 12 years of use they're probably safe to adopt.
mjsCallHAL -> CallHAL; mjsAddressHAL -> AddressHAL; mjsHAL -> HAL.
OS_VIDCDividerSWI code now always does NoSuchSWI (had been switched out previously).
File vduhint.s no longer assembled (was empty).


Version 5.35, 4.79.2.150. Tagged as 'Kernel-5_35-4_79_2_150'

Detail:
  This is a new branch from the current tip of the HAL branch, incorporating
  the changes received from Adrian Lees. The same caveats apply - this is a
  work in progress and will not work on any other platform at present.
Admin:
  Builds, but not tested.

Version 5.35, 4.79.2.147.2.1. Tagged as 'Kernel-5_35-4_79_2_147_2_1'

Improve heap manager. Add heap testbed. Add dummy implementation of some OS_ScreenMode reason codes.

Detail:
  s/HeapMan, hdr/KernelWS - Heap manager improvements:
    - Errors generated by interrupted heap operations that are forced to complete by a OS_Heap call from the background are now cached in kernel workspace until the foreground task is resumed. This prevents them from being potentially overwritten by MessageTrans running out of background error buffers.
    - Added new OS_Heap reason code, #7 - Get area aligned. This allows areas of memory to be allocated at specific (power-of-2) alignments, and optionally without crossing a given (power-of-2) boundary. Alignment & boundary calculations are performed using logical addresses.
    - Removed the limitation that all free and allocated blocks must be a multiple of 8 bytes in length. This change was required in order to allow OS_Heap 7 to function correctly. Now the only requirements are that blocks must be multiples of 4 bytes in length, at 4 byte alignment, with a minimum length of 8 bytes. 4 extra padding bytes may still be added to the end of allocations in order to avoid creating 4-byte free blocks.
  s/HeapMan, TestSrc/HeapTest/Makefile, TestSrc/HeapTest/c/testbed, TestSrc/HeapTest/s/asm - Added heap testbed program. Can either use the OS_Heap SWI or directly include a copy of the Kernel's heap manager sources.
  s/vdudecl, s/vduswis - Added dummy implementations of OS_ScreenMode 4, 5 and 6. This prevents the Wimp generating lots of "Unknown OS_ScreenMode reason code" errors when redrawing the screen.
  s/Arthur3, s/Oscli - Moved dotstring closer to where it's used to avoid "ADRL out of range" errors in Tungsten build
Admin:
  Tested in OMAP3 ROM & Tungsten ROM softload.
  Heap testbed successfully performed over 400 million heap ops, so there shouldn't be any serious bugs in the new code (touch wood)


Version 5.35, 4.79.2.128. Tagged as 'Kernel-5_35-4_79_2_128'

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.i2cutils line 454: this LDR of byte values was harmless (bits 8
    upwards are discarded later) but slower than an LDRB on ARMv6 or later.
  s.PMF.i2cutils line 556: should have loaded RTCFitted using LDRB. Looks
    like effect would have been to reduce utilisation of CMOS cache.
  s.vdu.vduswis line 1500: mistakenly accessing ExternalFramestore using LDR.
    I don't think the intention was to prevent the screen DA being resized
    while screen memory was claimed, but that was the effect.
  s.vdu.vduwrch line 3106: this LDR of a 1-byte variable was harmless (only
    used for testing bit 4) but slower than an LDRB on ARMv6 or later.
  CPU version is no longer specified in the makefile - it's better to inherit
  it from the build environment now that we actually set it appropriately.
Admin:
  Built and briefly tested.

Version 5.35, 4.79.2.98.2.9. Tagged as 'Kernel-5_35-4_79_2_98_2_9'

Detail:
  174: left border size
  175: bottom border size
  176: right border size
  177: top border size
Admin:
  Not tested.

Version 5.35, 4.79.2.68. Tagged as 'Kernel-5_35-4_79_2_68'

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 possible
  * Framestore made USR mode accessible
  * Fix for VDU 5,127 bug - now relies on font definitions being in extreme
    quarters of memory, rather than bottom half
  * Allocated 64-bit OS_Convert... SWIs
  * IIC errors use allocated error numbers
  * Looks for Dallas RTC before Philips RTC because we're using a Philips
    NVRAM device with the same ID
  * Fix to bug that meant the oscillator in the Dallas RTC wasn't enabled
  * Default mouse type (USB) changed to allocated number
  * Ram disc max size increased to 128 Mbytes (Ursula merge) and made
    cacheable for StrongARMs (not XScale)
  * Branch through zero handler now works in USR mode, by use of a
    trampoline in the system stack to allow PC-relative register storage
  * Address exception handler changed to not use 0 as workspace
  * OS_Memory 13 extended to allow specification of cacheability and access
    privileges
  * Added OS_Memory 16 to return important memory addresses
  * RISCOS_MapInIO() takes cacheable flag in bit 3, access permissions in
    bits 10 and 11, doubly-mapped flag in bit 20, and access permissions
    specified flag in bit 21
  * Bug fix in last version for application abort handlers didn't quite
    work; register shuffle required
  * "Module is not 32-bit compatible" error now reports the module name
  * Default configured language changed from 10 to 11 (now Desktop again)

Version 5.35, 4.79.2.51. Tagged as 'Kernel-5_35-4_79_2_51'

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

kernel now attempts to substitute video mode numbers in face of h/w with limited bits-per-pixel support (not tested yet)

HAL_API document added - early draft only, of interest to those
writing or modifying HALs for new h/w
ARMop_API document added - early draft only, of interest only
to those modifying kernel to support new ARM cores
*** polite comments on HAL_API welcome ***

Version 5.35, 4.79.2.15. Tagged as 'Kernel-5_35-4_79_2_15'

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'

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

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'

* Wasn't allowing writes to most of EEPROM.
* Old prototype OS_SetTime SWI code removed.
* MPEGPoduleNTSCNotPALMask option support removed to simplify things a bit.
* Now can cope with a system with a PAL/NTSC link, but no monitor detect line.
* Default PAL & NTSC modes now always 12 & 46 respectively.
* Kernel now knows about monitor type 8 (NTSC) - modes 44-46 (640x200) are
  available.
* STB/NC CMOS test removed from POST pending further investigation.

Version 4.90. Tagged as 'Kernel-4_90'

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

Version 4.64. Tagged as 'Kernel-4_64'