1. 20 Jan, 2019 1 commit
    • Jeffrey Lee's avatar
      Palette/gamma optimisations · 831e1d94
      Jeffrey Lee authored
        - Fix conditional code sequence in PV_BulkWrite which meant that the greyscale palette flag was being recalculated when the border or pointer colour was changed.
        - Change PV_1stFlashState / PV_2ndFlashState to act as NOPs in true colour modes, which helps to avoid regular redundant gamma table updates (due to the flashing colour logic in the VSync handler).
        Tested on Raspberry Pi 3
      Version 6.18. Tagged as 'Kernel-6_18'
  2. 14 Jul, 2018 1 commit
    • Jeffrey Lee's avatar
      Evict ECFIndex and PalIndex from VDU workspace · bcc668c7
      Jeffrey Lee authored
        ECFIndex and PalIndex claim to be mode variables, but it's impossible for extension modes to specify their values.
        Since they're easy to calculate from the ModeFlags and Log2BPP values, drop them from the mode workspace (+ table of builtin modes) and calculate them on the fly instead.
        File changes:
        - hdr/KernelWS - Drop ECFIndex & PalIndex from workspace
        - s/vdu/vdumodes - Adjust workspace definition, drop ECFIndex & PalIndex values from VWSTAB
        - s/vdu/vdudriver - Remove now-redundant copy loop from ModeChangeSub. Remove code from GenerateModeSelectorVars that sets up the ECFIndex & PalIndex values on the stack
        - s/vdu/vdugrafl - Adjust copy loop in SwitchOutputToSprite/Mask
        - s/vdu/vdupalette, s/vdu/vdupalxx - Add GetPalIndex routine to generate PalIndex on the fly. Drop the obsolete 16bpp palette/gamma table and shuffle the other entries to simplify GetPalIndex a bit.
        - s/vdu/vduplot - Add GetECFIndex routine to generate ECFIndex on the fly. Also, fix things so that mode 0 isn't the only rectangular-pixel mode which uses the special rectangular-pixel ECF patterns (index 0 vs. index 4). Fiddle with ExportedHLine a bit to avoid an out-of-range ADR.
        - s/NewReset - Fix UAL warning for MOV R0, AppSpaceStart. Adjust memset to not assume 512KB is the correct amount
        Tested on Raspberry Pi 3
      Version 6.11. Tagged as 'Kernel-6_11'
  3. 04 Feb, 2018 1 commit
    • Jeffrey Lee's avatar
      Fix some pointer colour issues. Fix PaletteV 6 (blank screen) return value. · 96e8fff1
      Jeffrey Lee authored
        s/vdu/vdudriver - On startup, initialise all palettes to 0, not just Pal_Blank. Ensures that entries which might not always be explicitly initialised (e.g. pointer) are self-consistent. Also make sure InitialiseMode communicates the pointer palette to the new GV driver, since some components tend to program it in a lazy manner (e.g. Hourglass)
        s/vdu/vdupalxx - Fix UpdateAllPalette setting R4 to 0 on exit. Fix PV_BlankScreen R0 return value to be 0/1 as the comment suggests instead of always being 0 due to GraphicsV calls.
        Tested on wandboard
        Fixes incorrect hourglass colours after reset, due to software RAM clear not wiping the kernel's palette (kernel + Hourglass thought old colours were still in use, but IMXVideo hadn't been told any colours yet so was using defaults of 0)
      Version 5.96. Tagged as 'Kernel-5_96'
  4. 30 Jun, 2016 2 commits
    • Jeffrey Lee's avatar
      Delete lots of old switches · f655fcf6
      Jeffrey Lee authored
        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.
        Identical binary to previous revision for IOMD & Raspberry Pi builds
      Version 5.51. Tagged as 'Kernel-5_51'
    • Jeffrey Lee's avatar
      Delete pre-HAL and 26bit code · 7d5bfc66
      Jeffrey Lee authored
        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.)
        Identical binary to previous revision for IOMD & Raspberry Pi builds
      Version 5.49. Tagged as 'Kernel-5_49'
  5. 10 Jul, 2015 1 commit
    • Jeffrey Lee's avatar
      Add builtin software pointer support · d1af0ed0
      Jeffrey Lee authored
        This set of changes adds support for rendering software mouse pointers directly in the kernel, rather than requiring graphics drivers to render them themselves as was the case previously.
        If a driver returns from GraphicsV_Features with the 'hardware pointer' bit clear, and a call to GraphicsV_UpdatePointer is returned unclaimed, then the kernel will step in and render a software pointer. This allows selective control over which areas of the screen the software pointer is used (e.g. if hardware only supports its use in some areas)
        hdr/KernelWS - Shrink PointerXEigFactor to 1 byte to free up some space for tracking the display log2bpp. Use 8 words of space for tracking software pointer state.
        s/vdu/vducursoft - Adjust existing the existing calls to the software pointer RemovePointer/RestorePointer functions so that they're called with IRQs enabled
        s/vdu/vdudriver - Keep track of display log2bpp. Claim/release memory needed for restoring pixels under software pointer.
        s/vdu/vdugrafhal - Update HAL_VideoUpdatePointer handling so that 0 can be returned in a1 to indicate the GraphicsV call should be left unclaimed.
        s/vdu/vdupalxx - Trigger updates of the cached software pointer palette whenever it's likely to become invalidated.
        s/vdu/vdupointer - Add software pointer implementation. Relying on a SpriteExtend OS_SpriteOp would be nice, but we're in the background so have to do plotting & unplotting manually. ColourTrans is used to cache the pointer palette colours for the current mode, although we're limited to calling it from a callback.
        Tested on Raspberry Pi & BB-xM
        Pointer is very flickery under some circumstances (e.g. running !CloseUp) due to needing to plot/unplot around any VDU driver screen access (as per text cursor). So code may need revising in future once we can trap reads/writes from specific screen memory pages.
      Version 5.35, Tagged as 'Kernel-5_35-4_79_2_269'
  6. 09 Mar, 2014 1 commit
    • Jeffrey Lee's avatar
      ModeFlag_GreyscalePalette handling improvements. Issue service calls on... · 7fbbad3d
      Jeffrey Lee authored
      ModeFlag_GreyscalePalette handling improvements. Issue service calls on certain GraphicsV events. Sprite tweaks and fixes.
        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.
        Tested on Iyonix, BB-xM
      Version 5.35, Tagged as 'Kernel-5_35-4_79_2_210'
  7. 15 Dec, 2013 1 commit
    • Jeffrey Lee's avatar
      Assorted GraphicsV improvements · 694750de
      Jeffrey Lee authored
        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.
        Tested in Tungsten, IOMD, OMAP3 & BCM2835 ROMs
        Requires HdrSrc-2_38 and updated video driver modes
      Version 5.35, Tagged as 'Kernel-5_35-4_79_2_203'
  8. 06 Aug, 2013 1 commit
    • Jeffrey Lee's avatar
      Add support for the new RISC OS 5 style sprite mode word. Add partial support... · 57d1a29d
      Jeffrey Lee authored
      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
        - 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
        - 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
        Tested on BB-xM
        Part of an implementation of the Extended Framebuffer Format spec:
      Version 5.35, Tagged as 'Kernel-5_35-4_79_2_194'
  9. 04 Jul, 2012 1 commit
    • Robert Sprowson's avatar
      Make GraphicsV_IICOp more consistent · c671badb
      Robert Sprowson authored
      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, Tagged as 'Kernel-5_35-4_79_2_159'
  10. 21 May, 2012 1 commit
    • Robert Sprowson's avatar
      Make Mike's macros permanent. · 2c9aad90
      Robert Sprowson authored
      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, Tagged as 'Kernel-5_35-4_79_2_150'
  11. 08 Aug, 2011 1 commit
    • Jeffrey Lee's avatar
      Add zero page relocation support · 2247d8e9
      Jeffrey Lee authored
        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.
        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, Tagged as 'Kernel-5_35-4_79_2_98_2_48'
  12. 06 May, 2004 1 commit
    • Kevin Bracey's avatar
      * HAL can choose to limit amount of screen memory to allocate · 0f6941a8
      Kevin Bracey authored
        [Not fully implemented - for now leaves at least 16MB free if only
        one RAM area; was 1MB].
      * Added HAL_USBControllerInfo, HAL_MonitorLeadID and HAL_Video_Render.
      * Added HAL->OS call OS_IICOpV.
      * OS_MMUControl now allows independent control of I and C bits.
      * Added facility to deactivate keyboard debounce (magic word "NoKd" in
        R2 in KeyV 0).
      * Fixed problem with RAM amounts not a multiple of 4MB.
      * Supremacy bit (in VDU 19) now sets all 8 bits of supremacy.
      * Added PaletteV 14 (reads gamma tables).
      * Added Supremacy transfer functions (like gamma correction, but for
        supremacy). Allows easy global supremacy effects in a mode-independent
        fashion. Controlled with PaletteV 15,16.
      * Added modes 50-53 (320x240, 1,2,4,8bpp). Intended for small LCD.
      * Added 13.5kHz versions of TV modes (selected by Hdr:Machine).
      * Upped desktop version to 5.06.
      Version 5.35, Tagged as 'Kernel-5_35-4_79_2_66'
  13. 07 Oct, 2002 1 commit
  14. 06 Oct, 2000 1 commit
  15. 05 Oct, 2000 1 commit
  16. 03 Oct, 2000 1 commit
  17. 15 Sep, 2000 1 commit
    • Kevin Bracey's avatar
      * Converted to building with ObjAsm (but still a single object file using ORG). · 49836a59
      Kevin Bracey authored
      * 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, Tagged as 'Kernel-5_35-4_79_2_1'
  18. 04 Apr, 2000 1 commit
    • Kevin Bracey's avatar
      32-bit Kernel. · b4016e9c
      Kevin Bracey authored
        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.
        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'
  19. 10 Mar, 2000 1 commit
  20. 26 Jan, 2000 1 commit
  21. 14 Oct, 1999 1 commit
  22. 21 Jan, 1997 1 commit
  23. 06 Nov, 1996 1 commit
  24. 05 Nov, 1996 1 commit