GitLab

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'

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

1) Bring IOMD HAL more up to date. Add support for new call HAL_CleanerSpace (preparation for StrongARM kernel support).

2) In kernel, add HAL_CleanerSpace call (preparation for
StrongARM and XScale core support). Fix bug found with
ARMv3 support during test on Risc PC.

3) Implement new API for kernel SWIs that have used top
bits of addresses as flags. The new API has an extra
flag that must be set, so kernel can distinguish and
support both APIs. The reason for all this is that
addresses are 32-bits now, people, keep up there. Briefly:

  OS_HeapSort
    bit 31 of r0 set for new API, r1 is full 32-bit address
    flags move from r1 bits 31-29 to r0 bits 30-28

  OS_ReadLine
    bit 31 of r1 set for new API, r0 is full 32-bit address
    flags move from bits 31,30 of r0 to bits 30,29 of r1

  OS_SubstituteArgs
    bit 31 of r2 set for new API, r0 is full 32-bit address
    flag moves from bit 31 of r0 to bit 30 of r2

Tested on Risc PC and briefly on Customer A 2

Ta

Version 5.35, 4.79.2.41. Tagged as 'Kernel-5_35-4_79_2_41'

fix bug in oscli gstrans handling (a problem provoked by long command lines with top bit set buffer addresses and not fixed properly). Problem was mistaken rejection of gstrans'd parameters other than at beginning of buffer.

Tested on simple desktop build for Risc PC

Version 5.35, 4.79.2.40. Tagged as 'Kernel-5_35-4_79_2_40'

Look for LongCommandLine flag, command line size currently
set at 1k.
For HAL/32bit builds, the kernel buffer space is at high
(top bit set) address, which may break some code using signed
comparisons. So *beware* that there may be some latent
bugs in old kernel code using these buffers, not yet found.
One such bug, in s.Arthur2 found and fixed.
Tested moderately on ARM9 desktop build.
Lovely to reimplement things I did two and half years ago.

Version 5.35, 4.79.2.37. Tagged as 'Kernel-5_35-4_79_2_37'

Reimplement Lazy task swapping, an amusing idea from Ursula, would have done it sooner but couldn't be bothered (humour).

Currently activates for all ARMs flagged as base-restored
abort model. No handling of eg. StrongARM pre-revT bug, but
then the kernel no longer runs on StrongARM (progress).
Still some details to fix: all aborts in current app space
assumed to be missing pages, but this must be fixed to
handle abort code in app space, things like debuggers
marking code read only.

Plus, small fixes:
  OS_Memory 8 returns vaguely useful info for RAM,VRAM
  in HAL build (temporary partial implementation)
  Broken handling of old BBC commands with (fx,tv etc)
  with no spaces fixed (fudgeulike code from Ursula,
  now 32-bit).

Version 5.35, 4.79.2.31. Tagged as 'Kernel-5_35-4_79_2_31'

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

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'

Version 4.84. Tagged as 'Kernel-4_84'