GitLab

Export less in hdr:RISCOS.
Delete unused GetDecimalPair routine.
Move CheckYear with other RTC stuff out of PMF/osword.
Hide DebugROMInit and DebugROMErrors in release (even numbered) versions.

Version 5.35, 4.79.2.127. Tagged as 'Kernel-5_35-4_79_2_127'

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:
 * Stopped calling the broken abort fixup code when running under VMSAv6.
   Might be desirable to update it, possibly farmed out to a separate module -
   still need to think about this.
 * Unaligned load optimisations can now be disabled by the global NoUnaligned
   flag for testing purposes.
 * Extended OS_ReadUnsigned to permit reading of 64-bit unsigned integers.
   See Docs.ReadUnsigned for more details. Also sped it up by using MLA
   (or UMLAL) for most digits rather than repeated addition.
 * Bugfix is OS_GSRead: an uninitialised r0 was being passed to
   OS_ReadUnsigned, causing undesirable effects on rare occasions.
Admin:
  Tested on a rev B7 beagleboard.

Version 5.35, 4.79.2.98.2.8. Tagged as 'Kernel-5_35-4_79_2_98_2_8'

Detail:
  Having scanned the kernel source for unaligned load code fragments which
  would abort on ARMv6 and v7 and not having found any, I took the opportunity
  to give them build-time switches to use unaligned LDR((S)H)/STR(H)
  instructions if built for a new enough platform. Also added a couple of
  cases of LDRSB that will benefit v4 CPUs and a few instances of the v6
  SXTH instruction, but since objasm doesn't yet understand it (and when it
  does, not everyone will have upgraded) they are currently written as
  DCI statements.
  Most of the changes are to OS_Word handlers, which are notorious in that
  their input/output block is not word-aligned.
Admin:
  Not tested, but it should at least build.

Version 5.35, 4.79.2.98.2.6. Tagged as 'Kernel-5_35-4_79_2_98_2_6'

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

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

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 compile-time support for full-resolution teletext characters in teletext emulation mode (MODE 7) for that authentic BBC Micro feel.

  Also introduced a few useful teletext control features via VDU 23,18.
  Unrelatedly, fixed *ScreenLoad to work for interlaced displays.

Detail:
  The new typeface is designed on a 16x20 grid (previously we had used 8x10),
  so it uses a screen resolution of 640x500 pixels (rather than 320x250).
  Since we have been unable to source a genuine teletext font, and since
  examination of a BBC Micro suggests that the genuine font may not have been
  a power-of-2 pixels wide, I have designed one specially, based upon the one
  supplied in Zap distributions (a 12x20 font). Rather than increase the
  amount of workspace that the kernel requires for cacheing graphic
  characters, it now generates them on the fly, as they are required; this
  should only add about 25% to their rendering time.

  The new VDU 23 sequences are as follows:

  VDU 23,18,0,mode,0,0,0,0,0,0
    Switch transparency mode
      mode = 0: "Text" mode: the whole display is set opaque
      mode = 1: "Mix" mode: foreground colours, and both foreground and
        background of boxed text are opaque; non-boxed background colours are
        all transparent
      mode = 2: "Box" mode: boxed regions are opaque, others are transparent
      mode = 3: "TV" mode: the whole display is set transparent
    Default is mode = 0.

  VDU 23,18,1,suspend,0,0,0,0,0,0
    Suspend or resume bitmap updates
    This call allows an application to request that the kernel suspends
    updates to the framebuffer bitmap. This allows for a significant speed
    increase in the rendering time for a large amount of text, for example
    when redrawing a complete teletext page, because each time you plot a
    single character, it can cause the whole of the rest of the line to be
    re-rendered. When you switch out of suspend mode, the whole screen is
    refreshed in a single pass. Note that the appearance of the display is
    undefined is you cause a hardware scroll while in suspend mode.
      suspend = 0: screen update is enabled
      suspend = 1: screen update is suspended
    Default is suspend = 0.

  VDU 23,18,2,reveal,0,0,0,0,0,0
    Reveal/conceal
      reveal = 0: characters between the Conceal control code and the next
        colour control code are replaced by spaces
      reveal = 1: all characters are displayed
    Default is reveal = 0.

  VDU 23,18,3,black_emable,0,0,0,0,0,0
    Enable/disable black foreground colour control codes
      black_enable = 0: control codes &80 and &90 do nothing
      black_enable = 1: control code &80 selects black text, control code
        &90 selects black graphics
    Default is black_enable = 0.

  I have performed some timing tests on the rendering of complete teletext
  pages grabbed from the teletext server. These show that the new code
  generally imposes a 2x speed hit. However, when using the VDU 23,18,1
  suspend function, this improves to a 20% speed increase when compared to
  the old low-resolution code. Better still, because the framebuffer is only
  being updated for the final stage of this process, the screen *appears* to
  be updated some 3x faster than with the old code!

  A comment on the VDU variable Log2BPC is in order: in previous kernels,
  this was able unambiguously to refer to both the framebuffer width of a
  character in bytes, and the framebuffer width of an "addressable pixel" in
  bits; this no longer works with the 16-pixel wide teletext font. Bearing
  in mind that future kernels may support Unicode system fonts where the
  width varies from character to character, I have chosen to fix Log2BPC to
  the "addressable pixel" definition.

Admin:
  Requires HdrSrc 0.89 and (for non-desktop builds) Interlace 0.61. A monitor
  definition file containing a definition for a 640x500 screen mode is also
  required; version 0.40 of ModeFiles contains a suitable mode for STB-400.

  Tested fairly rigourously on an Ursula build, a Lazarus build and an
  STB-400 build, using genuine teletext pages and Yellow River Kingdom.

Version 5.30. Tagged as 'Kernel-5_30'

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'