GitLab

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'