Skip to content

Releases: mirq/r200-p96-driver

0.40

Choose a tag to compare

@mirq mirq released this 19 Oct 15:27

Radeon9200.chip 0.40 (opts2)

Changes

  • Commit-chain walk removal (docs/07 candidate 1): the emitter
    validates every record as it consumes; the draw/offset-table count is
    guarded at each consume (stage 21) and compared before submission
    (stage 5). One cached-memory pass per commit removed.
  • Progress-based ring waits (docs/07 candidate 6 core): CpReserve /
    RadeonCpWait reset a stall budget whenever RB_RPTR advances and cap the
    total wait with an EClock deadline, sampled every 16th poll. A long
    GPU-bound frame is back-pressure, not CP death; a dead CP still fails
    fast (20k-poll no-progress budget, 1 s cap).
  • Includes the atom-reservation emitter (candidate 2, released earlier
    today as an intermediate).

Hardware validation (physical 68060 @ 192.168.1.21)

  • Gears (600-frame precalc, fullscreen 640x480, nosync, host prio -1):
    semantic 32bppx2 126.0 / 16bppx3 186.3 / 16bppx2 191.1 FPS - parity
    with main within noise; cpemit 16bppx3 194.8 FPS (+3.2% vs main).
  • Byte-identical CP streams: emitter bench CRC A8A11546 unchanged;
    tex-matrix (1188 checks) and tex-serial (76) host gates pass.

Known open items

  • RADEON3D_SUBMIT_NO_FENCE (inline fence coalescing) was attempted and
    reverted same day: the 2000-frame unpaced replay still fails with the
    historical signature; suspected interaction between the 20k-poll
    no-progress budget and long IMMD streaming stalls (old budget 100k).
  • Unpaced replay robustness remains the top open item.

Artifacts

  • Radeon9200.chip: 80,800 bytes, CRC32 CB892CFF
  • Prometheus.card: 7,796 bytes, CRC32 F3D56BF6 (build-date embedded)
  • Requires matched LIBS:minigl.library (interface 20) and cold reboot
    after install; see docs/05-build-deploy-run.md.

v0.31

Choose a tag to compare

@github-actions github-actions released this 02 Sep 21:30

Radeon9200 Prometheus integration 0.31

Release 0.31 ships the matched Radeon9200.chip and Prometheus.card pair.
The chip reports $VER: Radeon9200.chip 3.0 (2.9.2026) and exposes Radeon3D
interface 17.

Highlights

  • Adds interface-17 auxiliary render-surface allocation from driver-owned VRAM,
    preventing depth buffers from overlapping Picasso96 screen buffers.
  • Adds release-safe per-submission EClock telemetry and capture/plot tooling.
  • Adds the pre-serialized Radeon3D replay benchmark for isolating driver and
    command-processor throughput.
  • Preserves immutable record-chain emission, ordered commits, state batching,
    and client-written VRAM streaming segments.
  • Retains bounded surface validation, session generation checks, submission
    fences, recovery, and failure attribution for rejected semantic commits.
  • Keeps Picasso96 display, cursor, 2D acceleration, VGA, and validated
    internal-TMDS DVI support from 0.21.

Configuration

Install Radeon9200.chip and Prometheus.card as a matched pair. Monitor icons
use BOARDTYPE=Prometheus with
SETTINGSFILE=SYS:Devs/Picasso96Settings.9200. A valid positive DMASIZE is
required. CP=YES enables Radeon3D; OUTPUT=VGA remains the conservative
default, while OUTPUT=DVI requires a supported internal-TMDS COMBIOS profile.

See tooltypes.md for complete configuration and recovery precautions.

Validation

Validated on a physical 50 MHz 68060 Amiga with a Prometheus/FireBird bridge
and RV280 Radeon 9200. The MiniGL 800x600x32 fullscreen suite passes 24/24;
dynamic lightmap updates pass without commit failures. Release and debug builds
use the pinned GCC 6.5.0b toolchain in CI.

This remains an experimental driver. Use a recoverable setup for first boot on
new hardware.

v0.30

Choose a tag to compare

@github-actions github-actions released this 26 Aug 23:38

Radeon9200 Prometheus integration 0.30

Release 0.30 ships the matched Radeon9200.chip and Prometheus.card pair.
The chip reports $VER: Radeon9200.chip 3.0 (27.8.2026) and exposes Radeon3D
interface 13.

Highlights

  • Adds the hardware-TCL semantic path, including fixed-function lighting,
    normals, object-linear texgen, and sphere-map texgen.
  • Adds interface-13 client-written VRAM streaming segments and batched commits,
    avoiding the CPU copy from client records into driver staging memory.
  • Compacts untextured and single-texture TCL vertex records and uses burst
    stores for command-processor ring submission.
  • Fixes fog output on RV280, flat-shaded TCL primitives, texture-update
    ordering, compact-record stride handling, and depth targets padded for R200
    tile-pitch alignment.
  • Retains bounded surface validation, session generation checks, submission
    fences, recovery, and failure attribution for rejected semantic commits.
  • Keeps Picasso96 display, cursor, 2D acceleration, VGA, and validated
    internal-TMDS DVI support from 0.21.

Configuration

Install Radeon9200.chip and Prometheus.card as a matched pair. Monitor icons
use BOARDTYPE=Prometheus with
SETTINGSFILE=SYS:Devs/Picasso96Settings.9200. A valid positive DMASIZE is
required. CP=YES enables Radeon3D; OUTPUT=VGA remains the conservative
default, while OUTPUT=DVI requires a supported internal-TMDS COMBIOS profile.

See tooltypes.md for complete configuration and recovery precautions.

Validation

Validated on a physical 50 MHz 68060 Amiga with a Prometheus/FireBird bridge
and RV280 Radeon 9200. The MiniGL 800x600x32 fullscreen suite passes 24/24;
dynamic lightmap updates pass without commit failures. Release and debug builds
use the pinned GCC 6.5.0b toolchain in CI.

This remains an experimental driver. Use a recoverable setup for first boot on
new hardware.

v0.21

Choose a tag to compare

@github-actions github-actions released this 21 Aug 19:44

Radeon9200 Prometheus integration 0.21

Release 0.21 ships the matched Radeon9200.chip and Prometheus.card pair.
The chip reports $VER: Radeon9200.chip 3.0 (15.8.2026) and exposes Radeon3D
interface 8.

Highlights

  • Keeps Prometheus responsible for Radeon discovery, PCI ownership, bridge
    setup, and publication of the shared high-VRAM DMA arena.
  • Supports CRTC0 VGA output and the validated RV280 internal-TMDS DVI route,
    including BIOS-derived transmitter clocks up to the 165 MHz single-link
    limit. A 1920x1080 Workbench was physically validated.
  • Supports CLUT8, RGB565PC, and B8G8R8A8 scanout, palette, panning, DPMS, and a
    64x64 ARGB hardware cursor.
  • Accelerates fills, inversion, same-surface copies, lines, supported patterns
    and templates, and complete copies for all 16 four-bit Picasso96 minterms.
    On-board surface extents and arithmetic are checked before submission;
    overlapping ranges select a safe copy direction.
  • Uses cached 2D state, pipelined submissions, hardware FIFO backpressure, and
    skips unnecessary drains for safe off-board software fallbacks.
  • Provides bounded Radeon3D sessions, trusted command staging, fences, P96
    surface import, recovery, and semantic execution. Interface 7 adds native
    triangle-strip and triangle-fan records; interface 8 adds native quad-list
    records and perspective-correct v5 draws. The batch cap remains 8192 dwords.
  • Invalidates stale sessions on detach or recovery and restores a safe direct
    MMIO baseline before later Picasso96 work.
  • Includes GCC/vbcc ABI fixtures and runtime probes for discovery, sessions,
    submissions, fences, imported formats, and recovery.

Configuration

Monitor icons use BOARDTYPE=Prometheus together with
SETTINGSFILE=SYS:Devs/Picasso96Settings.9200. A valid positive DMASIZE is
required. CP=YES enables the active Radeon3D service; Picasso96 2D remains on
the direct-MMIO path. OUTPUT=VGA is the conservative default and
OUTPUT=DVI requires a supported internal-TMDS COMBIOS profile.

See tooltypes.md for complete semantics and recovery precautions.

Validation and performance

The current source has extensive physical 2D/3D correctness records, but no
complete version-3.0 2D benchmark baseline. Older P96Speed figures are not
promoted as release performance. performance.md defines the reproducible
baseline procedure and required artifact metadata.

The latest identified 3D checkpoint averaged 4.967 FPS in fullscreen textured
gears on the 50 MHz 68060/RV280 reference machine and passed the Phase 1 and
MiniGL Phase 4-6 suites. That number applies only to the hashes recorded in
R200_3D_PROGRESS.md.

This remains an experimental driver. Use a recoverable setup for first boot on
new hardware.

v0.20

Choose a tag to compare

@github-actions github-actions released this 13 Aug 09:25

Radeon9200 Prometheus integration 0.20

Version 0.20 moves Radeon board ownership and shared DMA publication into
Prometheus.card, with Radeon9200.chip handling RV280 initialization and
Picasso96 graphics operations.

Highlights

  • Ships the matched Prometheus.card and Radeon9200.chip runtime pair.
  • Reserves DMASIZE at the high end of VRAM and excludes it from Picasso96 and
    Radeon graphics operations.
  • Publishes the reserved pages through the existing Prometheus DMA vectors for
    peer PCI bus-master devices such as RTL8139.
  • Keeps Radeon cursor and optional CP resources in separate private VRAM below
    the shared DMA aperture.
  • Requires a valid positive DMASIZE reservation before Radeon card
    initialization succeeds.
  • Extracts complete monochrome template words with one 68020 bfextu.
  • Uses an endian-correct raw host-data store with Radeon MSB-first consumption,
    removing software bit reversal from the upload loop.
  • Advances source and row pointers directly instead of recalculating template
    offsets for every uploaded word.
  • Caches stable template engine state and reserves available FIFO capacity for
    the complete upload when possible.
  • Retains bounded extraction for partial final words and software fallback for
    unsupported CLUT write masks.
  • Enables the hardware cursor by default; HWSPRITE=NO remains available for
    an explicit software-cursor fallback.
  • Accelerates disjoint cross-surface source copies with independent source and
    destination pitches, removing the layer backing-store software fallback for
    overlapping windows.
  • Accelerates cross-surface source-XOR-destination (opcode $6) and selects
    reverse copy direction for physically overlapping surfaces. This removes the
    generic P96 backing-store path that made a smart-refresh window take about
    9.6 seconds to open over another window; the validated release takes 11.7 ms.
  • Adds DEBUG version 4 template workload counters and focused wide-template and
    Text() benchmarks to p96screen.
  • Extends the DEBUG block to version 5 with cross-surface copy path, unequal
    pitch, and fallback-reason counters.
  • Extends the DEBUG block to version 6 with calls, hardware/software split, and
    timing for every 2D callback, so interactive work can be attributed instead
    of only RectFill.
  • Adds HWTEXT to select between the hardware BlitTemplate upload and
    rtg.library's CPU default. The hardware path remains the default: it is 1.8x
    faster on eight-character Text() and 3.8x faster on a 64-pixel template.
  • Reserves template host-data FIFO entries in bursts instead of once per glyph
    row, cutting FIFO polling from 14.5 to 3.76 reads per template blit and the
    whole blit by 11.9 percent.
  • Adds an experimental VRAM-staged BlitTemplate expand behind TEXTSTAGE.
    It is off by default and known broken: it wedges the 2D engine on the
    reference machine. The shipping text path is unchanged.
  • Adds DEBUG version 7/8 probes that measure framebuffer-aperture write cost
    against MMIO register write cost, and confirm on real hardware that the 2D
    engine can colour-expand a monochrome source read from VRAM. Both are
    DEBUG-only; the release card is byte-identical without them.

Text Performance

P96Speed 1.2 Text performance increased from approximately 4400 to 6300
operations/second on the development system, a gain of about 43 percent. The
focused p96screen Text("P96Speed") benchmark improved from 40 to 30 ticks.

Development Status

This remains an early-development driver. The release candidate was tested on
the target Amiga before tagging; no additional release-only test pass was run.

The library reports $VER: Radeon9200.chip 1.0 (12.8.2026). Version 1.0 is
loaded by Prometheus.card; monitor icons use BOARDTYPE=Prometheus.

v0.14

Choose a tag to compare

@github-actions github-actions released this 12 Aug 16:29

Radeon9200.card 0.14

Version 0.14 is an early-development text-rendering performance update. It
optimizes the hardware JAM1/JAM2 BlitTemplate upload path used by Picasso96
Text() while retaining the direct-MMIO acceleration introduced in 0.12.

Highlights

  • Extracts complete monochrome template words with one 68020 bfextu.
  • Uses an endian-correct raw host-data store with Radeon MSB-first consumption,
    removing software bit reversal from the upload loop.
  • Advances source and row pointers directly instead of recalculating template
    offsets for every uploaded word.
  • Caches stable template engine state and reserves available FIFO capacity for
    the complete upload when possible.
  • Retains bounded extraction for partial final words and software fallback for
    unsupported CLUT write masks.
  • Enables the hardware cursor by default; HWSPRITE=NO remains available for
    an explicit software-cursor fallback.
  • Accelerates disjoint cross-surface source copies with independent source and
    destination pitches, removing the layer backing-store software fallback for
    overlapping windows.
  • Accelerates cross-surface source-XOR-destination (opcode $6) and selects
    reverse copy direction for physically overlapping surfaces. This removes the
    generic P96 backing-store path that made a smart-refresh window take about
    9.6 seconds to open over another window; the validated release takes 11.7 ms.
  • Adds DEBUG version 4 template workload counters and focused wide-template and
    Text() benchmarks to p96screen.
  • Extends the DEBUG block to version 5 with cross-surface copy path, unequal
    pitch, and fallback-reason counters.
  • Extends the DEBUG block to version 6 with calls, hardware/software split, and
    timing for every 2D callback, so interactive work can be attributed instead
    of only RectFill.
  • Adds HWTEXT to select between the hardware BlitTemplate upload and
    rtg.library's CPU default. The hardware path remains the default: it is 1.8x
    faster on eight-character Text() and 3.8x faster on a 64-pixel template.
  • Reserves template host-data FIFO entries in bursts instead of once per glyph
    row, cutting FIFO polling from 14.5 to 3.76 reads per template blit and the
    whole blit by 11.9 percent.
  • Adds an experimental VRAM-staged BlitTemplate expand behind TEXTSTAGE.
    It is off by default and known broken: it wedges the 2D engine on the
    reference machine. The shipping text path is unchanged.
  • Adds DEBUG version 7/8 probes that measure framebuffer-aperture write cost
    against MMIO register write cost, and confirm on real hardware that the 2D
    engine can colour-expand a monochrome source read from VRAM. Both are
    DEBUG-only; the release card is byte-identical without them.

Text Performance

P96Speed 1.2 Text performance increased from approximately 4400 to 6300
operations/second on the development system, a gain of about 43 percent. The
focused p96screen Text("P96Speed") benchmark improved from 40 to 30 ticks.

Development Status

This remains an early-development driver. The release candidate was tested on
the target Amiga before tagging; no additional release-only test pass was run.

The library reports $VER: Radeon9200.card 0.14 (12.8.2026).

v0.13

Choose a tag to compare

@github-actions github-actions released this 11 Aug 10:18

Radeon9200.card 0.13

Version 0.13 is an early-development text-rendering performance update. It
optimizes the hardware JAM1/JAM2 BlitTemplate upload path used by Picasso96
Text() while retaining the direct-MMIO acceleration introduced in 0.12.

Highlights

  • Extracts complete monochrome template words with one 68020 bfextu.
  • Uses an endian-correct raw host-data store with Radeon MSB-first consumption,
    removing software bit reversal from the upload loop.
  • Advances source and row pointers directly instead of recalculating template
    offsets for every uploaded word.
  • Caches stable template engine state and reserves available FIFO capacity for
    the complete upload when possible.
  • Retains bounded extraction for partial final words and software fallback for
    unsupported CLUT write masks.
  • Adds DEBUG version 4 template workload counters and focused wide-template and
    Text() benchmarks to p96screen.

Text Performance

P96Speed 1.2 Text performance increased from approximately 4400 to 6300
operations/second on the development system, a gain of about 43 percent. The
focused p96screen Text("P96Speed") benchmark improved from 40 to 30 ticks.

Development Status

This remains an early-development driver. The release candidate was tested on
the target Amiga before tagging; no additional release-only test pass was run.

The library reports $VER: Radeon9200.card 0.13 (11.8.2026).

v0.12.1

Choose a tag to compare

@github-actions github-actions released this 10 Aug 13:30

Radeon9200.card 0.12

Version 0.12 is a performance and callback-completeness update. It replaces
per-register OpenPCI library calls with validated direct MMIO, removes costly
generic arithmetic from the common surface path, and raises focused RectFill
performance from roughly 5.1k to 10.7k operations/second.

Highlights

  • Uses endian-correct volatile accesses after BAR ownership, type, and size
    validation instead of calling pci_inl()/pci_outl() for every register.
  • Inlines unchecked MMIO access in acceleration code, matching the closed
    driver's direct move.l command sequences.
  • Removes the solid-fill FIFO pre-poll and uses the RV280's validated bus
    backpressure behavior.
  • Matches the closed driver's WaitBlitter behavior: wait for 64 free FIFO
    entries, then wait for GUI idle, without a semaphore or redundant cache/HDP
    operations.
  • Replaces per-fill 64-bit surface bounds arithmetic with overflow-safe 32-bit
    checks; normal 1 KiB-aligned surfaces also avoid address-bias division.
  • Adds hardware destination inversion through ROP3_Dn.
  • Adds hardware JAM1/JAM2 monochrome BlitTemplate through host-data upload.
  • Installs EnableSoftSprite alongside the existing RV280 hardware cursor.
  • Extends p96screen with invert and template correctness and timing tests.

RectFill Performance

P96Speed 1.2 was run on an Amiga 4000 with a 50 MHz 68060 and RV280
1002:5964, using 640x480x16 and 13 seconds per focused test.

Build RectFill op/s Time/op Change
v0.11 validated mean 5066.7 197.37 us baseline
Pre-v0.12 comparison 5167 193.54 us -
Direct volatile MMIO ~6700 ~149.25 us +29.7% vs 5167
v0.12 10688 93.56 us +106.9% vs 5167
Closed driver reference 11881 84.17 us v0.12 is 10.1% lower

Direct volatile MMIO removed about 44 microseconds per operation. Replacing the
generic 64-bit validator removed another 56 microseconds and was the change that
crossed the 10k target. The v0.12 result is 2.11x the v0.11 validated mean and
within 10.1 percent of the closed driver.

Hardware Validation

  • Tested card: RV280 Radeon 9200 1002:5964, 128 MiB COMBIOS board.
  • CPU/bridge: 68060 at 50 MHz, Prometheus/FireBird environment.
  • Active ToolTypes: DMASIZE=2M, CP=YES, and HWSPRITE=YES.
  • Final release binary: 30,696 bytes, CRC32 FB3D08BE, SHA-256
    3b3f99815afe272526c3247b6389ea56f04b6c8214828403af014be3294562e0.
  • Benchmarked binary before the version-only rebuild: 30,696 bytes, CRC32
    85C2D325; executable code is otherwise identical.
  • Preserved on the Amiga as
    LIBS:Picasso96/Radeon9200.card.direct-fast-10688.
  • The CLUT8/RGB565PC/BGRA32/CLUT8 sequence passed fill, inversion, JAM1/JAM2
    template, pattern, mask, overlap-copy, cross-surface copy, guard, and
    direct-color readback tests.
  • No crash was recorded during cold boots, P96Speed, validation screen cycles,
    or return to Workbench.

The library reports $VER: Radeon9200.card 0.12 (10.8.2026).

v0.11

Choose a tag to compare

@github-actions github-actions released this 10 Aug 06:57

Radeon9200.card 0.11

Version 0.11 is a focused performance update to 0.10. It removes two redundant
pre-trigger synchronization writes from each direct-MMIO solid fill while
retaining the post-operation WaitBlitter completion fence.

Highlights

  • Reduces solid-fill submission from nine to seven MMIO writes, improving the
    focused RectFill mean by 3.65 percent in an otherwise identical build.
  • Retains the R200 CP ring and microcode in private VRAM reserved with
    DMASIZE, with bounded fallback and recovery.
  • Uses direct MMIO for Picasso96 fill, pattern, same-surface copy, and
    cross-surface copy even when the CP is active.
  • Tracks the backend with pending work so WaitBlitter drains MMIO or CP
    correctly instead of selecting solely from CP readiness.
  • Adds an opt-in 64x64 ARGB RV280 hardware-cursor surface with normal and
    Picasso96 BIGSPRITE pointer rendering.
  • Removes rtg.library's software-cursor overlap save/restore overhead when
    HWSPRITE=YES is active.
  • Establishes a driver-owned HOST_PATH_CNTL baseline and removes two
    redundant PCI reads from each HDP invalidate while retaining a final readback
    barrier.
  • Publishes DEBUG-only CP, DMA, MMIO, fill, drain, fallback, and cursor callback
    counters through the Radeon9200.Debug public port.
  • Corrects ToolType documentation: settings come from
    DEVS:Monitors/Radeon.info, not an icon beside the card binary.

RectFill Performance

P96Speed 1.2 was run on an Amiga 4000 with a 50 MHz 68060 and RV280
1002:5964, using 640x480x16 and 13 seconds per focused test.

Build RectFill op/s Change from v0.10
v0.9 published focused result 2593 -47.7%
v0.10 published mean 4960 baseline
v0.11 sample 1 5080 +2.4%
v0.11 sample 2 5083 +2.5%
v0.11 sample 3 5037 +1.6%
v0.11 mean 5066.7 +2.2%
Closed driver reference 11881 v0.11 is 57.4% lower

The exact v0.11 artifact samples have a 46 op/s range, 0.91 percent of the mean.
Compared with the original five-run CP-active mean of 1954.4 op/s, the final
result is 159.3 percent faster. It remains 52.6 percent below the 10693 target.
The saved final result is Work:P96Speed_v011_final.txt, CRC32 57CECA86.

Controlled DEBUG measurements explain the gain:

  • Suppressing the software cursor raised RectFill from 1992 to 3153 op/s,
    showing that generic sprite overlap handling dominated the original path.
  • Real hardware cursor plus MMIO 2D averaged 3424 op/s under instrumentation.
  • Shadowing HOST_PATH_CNTL raised that instrumented mean to 3487.7 op/s and
    reduced measured driver time by about 6 microseconds per fill.
  • Removing DEBUG timing hooks raised the release path to approximately
    4.93-4.96k op/s; nested ReadEClock calls materially affected the
    instrumented absolute score.
  • Removing two redundant pre-trigger flush/idle writes reduced fill submission
    from nine to seven MMIO writes. Paired builds differing only by that change
    improved from 4933.3 to 5113.3 op/s, saving 7.14 microseconds per operation
    and adding 3.65 percent.

Fully fenced release p96screen fill timings improved from v0.9's 18/21/41
ticks to 3/5/10 ticks in the final CLUT8/RGB565PC/BGRA32 sequence, reductions
of approximately 83%, 76%, and 76%. The full 8/16/32/8 sequence passed fill,
pattern, masks, overlap-copy, cross-surface copy, guard, and direct-color
readback tests.

Hardware Validation

  • Tested card: RV280 Radeon 9200 1002:5964, 128 MiB COMBIOS board.
  • CPU/bridge: 68060 at 50 MHz, Prometheus/FireBird environment.
  • Active ToolTypes: DMASIZE=2M, CP=YES, and HWSPRITE=YES.
  • Release binary: 31204 bytes, CRC32 E7E2F009, SHA-256
    ef5c9f2893af13d13411de8f1157896a6c22ae4a89379c23e122b991d0460594.
  • Final 8/16/32/8 test records: CRC32 00F2C01B, B94C0AAA, 2E80F380,
    and 1E10C436.
  • Binary release assets include the AMD microcode license and inherited-code
    redistribution notices.
  • No crash was recorded after repeated cold boots, 8/16/32/8 transitions,
    focused P96Speed runs, and post-benchmark Workbench use.

The library reports $VER: Radeon9200.card 0.11 (10.8.2026). Hardware cursor
support remains opt-in; bridge screenshots cannot capture the overlay, so
physical cursor appearance should be confirmed on the attached display.
Line, template/text, invert, planar, broader pattern, and unsupported
cross-surface operations continue to use Picasso96 software fallbacks.

v0.10

Choose a tag to compare

@github-actions github-actions released this 09 Aug 23:28

Radeon9200.card 0.10

Version 0.10 keeps the R200 command processor initialized for future 3D work
while routing Picasso96 2D operations through the faster direct-MMIO path. It
also adds an opt-in RV280 hardware cursor, reduces completion-path MMIO reads,
and adds enough DEBUG observability to prove which backend is active.

Highlights

  • Initializes and validates the R200 CP ring and microcode from private VRAM
    reserved with DMASIZE, while retaining bounded fallback and recovery.
  • Uses direct MMIO for Picasso96 fill, pattern, same-surface copy, and
    cross-surface copy even when the CP is active.
  • Tracks the backend with pending work so WaitBlitter drains MMIO or CP
    correctly instead of selecting solely from CP readiness.
  • Adds an opt-in 64x64 ARGB RV280 hardware-cursor surface with normal and
    Picasso96 BIGSPRITE pointer rendering.
  • Removes rtg.library's software-cursor overlap save/restore overhead when
    HWSPRITE=YES is active.
  • Establishes a driver-owned HOST_PATH_CNTL baseline and removes two
    redundant PCI reads from each HDP invalidate while retaining a final readback
    barrier.
  • Publishes DEBUG-only CP, DMA, MMIO, fill, drain, fallback, and cursor callback
    counters through the Radeon9200.Debug public port.
  • Corrects ToolType documentation: settings come from
    DEVS:Monitors/Radeon.info, not an icon beside the card binary.

RectFill Performance

P96Speed 1.2 was run on an Amiga 4000 with a 50 MHz 68060 and RV280
1002:5964, using 640x480x16 and 13 seconds per focused test.

Build RectFill op/s Change from v0.9
v0.9 published focused result 2593 baseline
v0.10 release, sample 1 4960 +91.3%
v0.10 release, sample 2 4956 +91.1%
v0.10 release, sample 3 4964 +91.4%
v0.10 mean 4960 +91.3%
Closed driver reference 11881 v0.10 is 58.3% lower

The v0.10 samples have an eight op/s range, only 0.16 percent of the mean.
Compared with the original five-run CP-active mean of 1954.4 op/s, the final
release is 153.8 percent faster. The saved final result is
Work:P96Speed_release_mmio_rectfill.txt, CRC32 E374B4AB.

Controlled DEBUG measurements explain the gain:

  • Suppressing the software cursor raised RectFill from 1992 to 3153 op/s,
    showing that generic sprite overlap handling dominated the original path.
  • Real hardware cursor plus MMIO 2D averaged 3424 op/s under instrumentation.
  • Shadowing HOST_PATH_CNTL raised that instrumented mean to 3487.7 op/s and
    reduced measured driver time by about 6 microseconds per fill.
  • Removing DEBUG timing hooks for the release raised the stable mean to
    4960 op/s; nested ReadEClock calls materially affected the instrumented
    absolute score.

Fully fenced release p96screen fill timings improved from v0.9's 18/21/41
ticks to 4/6/12 ticks in the final CLUT8/RGB565PC/BGRA32 sequence, reductions
of approximately 78%, 71%, and 71%. The full 8/16/32/8 sequence passed fill, pattern, masks,
overlap-copy, cross-surface copy, guard, and direct-color readback tests.

Hardware Validation

  • Tested card: RV280 Radeon 9200 1002:5964, 128 MiB COMBIOS board.
  • CPU/bridge: 68060 at 50 MHz, Prometheus/FireBird environment.
  • Active ToolTypes: DMASIZE=2M, CP=YES, and HWSPRITE=YES.
  • Release binary: 31260 bytes, CRC32 2AC0183B, SHA-256
    0790823a6ab0347f43f67ab5c2ba9b2da2d0c6b5e6cfa1d2ecf108b5aa410b60.
  • Final 8/16/32/8 test records: CRC32 CDE47391, 0506FCC6, 2F66E5E5,
    and BC93CD8B.
  • No crash was recorded after repeated cold boots, 8/16/32/8 transitions,
    focused P96Speed runs, and post-benchmark Workbench use.

The library reports $VER: Radeon9200.card 0.10 (10.8.2026). Hardware cursor
support remains opt-in; bridge screenshots cannot capture the overlay, so
physical cursor appearance should be confirmed on the attached display.
Line, template/text, invert, planar, broader pattern, and unsupported
cross-surface operations continue to use Picasso96 software fallbacks.