GitLab

OS_CLI permits commands to be prefixed with a temporary filing
system, for example "ADFS:Format"

It also passes commands unrecognised to FileSwitch to be executed,
so "ADFS::HardDisc4.$.!Boot" first sets the temporary filing to
ADFS then executes ":HardDisc4.$.!Boot".

This does not work if the path contains a special field,
currently this results in an error as the special filed
would be lost.

Unfortunately many programs, including the RISC OS source
fail because of this.

Instead if a filing system prefix with special field
is found switch to the Temporary filing system and
treat the whole command as a path to execute. For example
passing "IXFS#W:$.HardDisc4.!Boot" sets the temporary filing
system to "IXFS" then executes "IXFS#W:$.HardDisc4.!Boot".

Version 6.30. Tagged as 'Kernel-6_30'

Detail:
  NewReset.s: Remove warning about soft reset, this is not supported any longer
  MsgCode.s: Reload LR after potentially changing mode
  PMF/osinit.s: Delete vestiges of soft reset support
Admin:
  Submission from Timothy Baldwin.

Version 6.07. Tagged as 'Kernel-6_07'

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:
  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:
  The kernel will examine all modules that it is requested to initialise
    and will refuse to initialise any module without a module flags word
    entry in its module header or with bit 0 the first flags word being
    clear (bit 0 being ModuleFlag_32bit)
  Error message added to all the messages files.
  New error block added to message counting block.  The Non-32-bit module
    message is not a cached error message, though.
Admin:
  Tested in 32-bit Lazarus build.

Version 5.38. Tagged as 'Kernel-5_38'

More stuff. Up to the desktop now; cache on, working keyboard. Some source restructuring to start to make splitting it up into several object files more feasible.

* 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'

Detail:
  The kernel can now disable all substitutions into error messages that
    it generates and count the number of times each error is looked up.
    The ErrorCount BASIC program then displays that information so that
    you can see if any odd errors are occurring or weird errors that you
    would not be expecting.
  It is not sensible to build a release with countmsgusage enabled.
Admin:
  Tested in Ursula build.

Version 5.32. Not tagged

  Removed DriversInKernel conditional.
Detail:
  If the territory changes or the resource file changes, the kernel
    will now decache all the cached error blocks so that next time
    they are required, they will be looked up again.
  The error cacheing is now a kernel build option and is always set
    to on.
  Removed one of the 5 error messages to be cached - it never seems
    to happen.  The remaining 4 are more frequent.
Admin:
  Tested in Ursula build.
  Cannot be used with HdrSrc 0.94.  HdrSrc 0.95 and later is required
    (or HdrSrc 0.93 and earlier subject to other kernel requirements)
  Requires MessageTrans 0.42 or later for correct operation when a
    replacement messages file is loaded.

Version 5.32. Tagged as 'Kernel-5_32'

  Added common error cache.
Detail:
  Fixed module header validation code which was broken in 5.22.  This
    shouldn't have caused much of a problem as it was only a bizarre
    check (SWI chunk looked valid but SWI handler was 0) that would
    have failed - but be reported as a valid set of SWI entries.
  Added common error message cache.  Several common errors (Buffer
    overflow; Number not recognised; Bad vector release; and a couple
    of others) are now cached the first time they are translated into
    a block of memory in the system heap.
Admin:
  Tested in Ursula build - cacheing only active in Ursula build - change
    HdrSrc if you want it in your products too.
  Requires HdrSrc 0.94

Version 5.31. Tagged as 'Kernel-5_31'

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'