1. 15 Dec, 2016 1 commit
    • Jeffrey Lee's avatar
      Add support for custom teletext modes · 92e90b01
      Jeffrey Lee authored
      Detail:
        This set of changes:
        * Adds support for the T, TX and TY mode string elements (as per RISCOS Ltd)
        * Adds support for entering arbitrary-resolution teletext modes by using mode selector blocks with the Teletext mode flag set
        * ScrRCol and ScrBRow mode variables can be provided in the mode selector in order to restrict the number of text rows/columns in teletext modes (as per RISCOS Ltd)
        * If the rows / columns are restricted in this manner then the text window will be centered on the screen, to try and avoid things looking too ugly (no variable text scaling implemented)
        * For HiResTTX, all colour depths >= 4bpp are now supported by teletext. This essentially makes the TTX256 switch obsolete.
        * If the "native" mode 7 is unavailable then the kernel will try a series of fallback resolutions & colour depths in an effort to find a combination that works
        Known bugs/issues:
        * Teletext column count has a max limit of 255 due to TTXDoubleCounts being a byte array
        * If there's a border around the text window, the border will not be refreshed when changing transparency modes using a VDU 23,18,0 sequence
        * ScreenLoad looks like it can overflow the LargeCommon buffer (no buffer size check) - needs fixing before LargeCommon can be safely shrunk below (Old)TTXMapSize
        File changes:
        - hdr/KernelWS - Make CharWidth non-conditional. Adjust handling of teletext workspace; it's now allocated from the system heap to allow it to cope with arbitrary screen sizes
        - s/vdu/vdu23 - Make CharWidth non-conditional
        - s/vdu/vducursoft - Make CursorTeletext cope with arbitrary colour depths, make CharWidth non-conditional, remove hard-coded teletext values
        - s/vdu/vdudriver - Deal with teletext workspace allocation during ModeChangeSub. Deal with selecting teletext modes (and validating colour depth) in GenerateModeSelectorVars.
        - s/vdu/vdugrafl - Make CharWidth non-conditional. Calculate offset required for text window centering.
        - s/vdu/vdumodes - Remove TTX256
        - s/vdu/vduswis - Try other teletext modes if native mode 7 not available. Extend OS_ScreenMode reason codes to cope with teletext mode strings.
        - s/vdu/vduttx - Update to use dynamic workspace. Replace various hardcoded values with variable lookups. Update character plotting + colour/palette selection to work with true-colour modes if HiResTTX.
        - s/vdu/vduwrch - Move some useful code into a subroutine. Update FastCLS to cope with true-colour teletext. Update AddressR0R1 to cope with text window centering offset. Make CharWidth non-conditional.
      Admin:
        Tested on Raspberry Pi, BB-xM
        VDU 23,18,0 in 256-colour teletext now works correctly (previously 64-colour mode was in use, causing palette update to be ruined by VIDC1-mangling)
      
      
      Version 5.74. Tagged as 'Kernel-5_74'
      92e90b01
  2. 30 Jun, 2016 1 commit
    • Jeffrey Lee's avatar
      Delete lots of old switches · f655fcf6
      Jeffrey Lee authored
      Detail:
        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.
      Admin:
        Identical binary to previous revision for IOMD & Raspberry Pi builds
      
      
      Version 5.51. Tagged as 'Kernel-5_51'
      f655fcf6
  3. 10 Jul, 2015 1 commit
    • Jeffrey Lee's avatar
      Add builtin software pointer support · d1af0ed0
      Jeffrey Lee authored
      Detail:
        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.
      Admin:
        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, 4.79.2.269. Tagged as 'Kernel-5_35-4_79_2_269'
      d1af0ed0
  4. 15 Dec, 2013 1 commit
    • Jeffrey Lee's avatar
      Assorted GraphicsV improvements · 694750de
      Jeffrey Lee authored
      Detail:
        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.
      Admin:
        Tested in Tungsten, IOMD, OMAP3 & BCM2835 ROMs
        Requires HdrSrc-2_38 and updated video driver modes
      
      
      Version 5.35, 4.79.2.203. Tagged as 'Kernel-5_35-4_79_2_203'
      694750de
  5. 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
      
      Detail:
        ECFShift/ECFYOffset:
        - 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
        Misc:
        - 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
      Admin:
        Tested on BB-xM
        Part of an implementation of the Extended Framebuffer Format spec:
        http://www.riscosopen.org/wiki/documentation/show/Extended%20Framebuffer%20Format%20Specification
      
      
      Version 5.35, 4.79.2.194. Tagged as 'Kernel-5_35-4_79_2_194'
      57d1a29d
  6. 05 Dec, 2012 1 commit
    • Jeffrey Lee's avatar
      Be more careful when updating Vinit from the VSync IRQ handler · e91fc098
      Jeffrey Lee authored
      Detail:
        s/vdu/vducursoft - TeletextFlashTest now stores the updated TeletextCount before calling SetVinit. This provides some protection against getting stuck in an infinite loop (+ stack overflow) if SetVinit takes longer than 1 VSync to complete (or some other catastrophe occurs)
      Admin:
        Tested on Raspberry Pi
      
      
      Version 5.35, 4.79.2.179. Tagged as 'Kernel-5_35-4_79_2_179'
      e91fc098
  7. 07 Sep, 2012 1 commit
    • Jeffrey Lee's avatar
      Clean up remaining kernel hacks · ef670f73
      Jeffrey Lee authored
      Detail:
        Docs/RPiNotes - Deleted, contents no longer relevant
        s/HAL, s/Kernel, s/vdu/vduswis, s/pmf/key - Cleaned up debug code
        s/NewIRQs - No need to piggy back on timer 0 IRQ to generate a fake VSync; PushModeInfo already claims/releases TickerV as appropriate if video driver doesn't provide a VSync IRQ.
        s/NewReset - Re-enable LookForHALRTC call, the stack imbalance bug was fixed before the Pi changes were merged in
        s/vdu/vducursoft - Streamline PostWrchCursor a bit by only preserving R14 around RestorePointer if the software pointer is in use
        s/vdu/vdudriver - Amend ModeChangeSub improvements to ensure old external framestore handling logic is used if driver doesn't support framestore growth/realloc
      Admin:
        Tested on Raspberry Pi with high processor vectors
        Kernel now looks to be in a good state for merging back into HAL branch
        Note - Software mouse pointer support in vducursoft only checks HALVideoFeatures, so doesn't take into account the capabilities of any GraphicsV driver that may be in use.
      
      
      Version 5.35, 4.79.2.147.2.20. Tagged as 'Kernel-5_35-4_79_2_147_2_20'
      ef670f73
  8. 10 May, 2012 1 commit
    • Ben Avison's avatar
      Merge of Raspberry Pi support code against latest kernel · f092f5f5
      Ben Avison authored
      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'
      f092f5f5
  9. 18 Dec, 2002 1 commit
    • Ben Avison's avatar
      Added 256-colour version of the (high-resolution only) teletext code, and... · 12055c33
      Ben Avison authored
      Added 256-colour version of the (high-resolution only) teletext code, and support for teletext when hardware scroll is disabled. Both are required for Tungsten.
      
      Turned off the module init/final service calls, since we still don't have an
      allocation for them.
      Upped the OS version number to 5.01.
      
      Version 5.35, 4.79.2.53. Tagged as 'Kernel-5_35-4_79_2_53'
      12055c33
  10. 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, 4.79.2.1. Tagged as 'Kernel-5_35-4_79_2_1'
      49836a59
  11. 28 Jun, 2000 1 commit
    • Ben Avison's avatar
      Added compile-time support for full-resolution teletext characters in teletext... · e87eeeca
      Ben Avison authored
      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'
      e87eeeca
  12. 04 Apr, 2000 1 commit
    • Kevin Bracey's avatar
      32-bit Kernel. · b4016e9c
      Kevin Bracey authored
      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'
      b4016e9c
  13. 05 Nov, 1996 1 commit