AGA border sprites

[mark_k]

Just noticed something playing with AGA emulation. I'm guessing the same thing happens on a real Amiga, but anyway...

Using an AGA config, boot Workbench 3.1. Use Overscan prefs to change the NTSC text overscan size to the maximum possible (724x241). Use the default mouse pointer with hotspot at the top left. Enable border sprites using BSprite.

With an NTSC non-interlaced WB, move the pointer to the extreme right. Notice that the sprite brightness reduces. That's because the sprite is sort-of interlaced; half its lines are shown in each frame, with the others transparent. With an NTSC interlaced WB the effect is different; the pointer shimmers more noticeably. With a PAL WB (interlaced or not) the pointer disappears when it is in the rightmost position.

Is the effect with NTSC related to the long/short line toggle?

Update/addition: I noticed another issue with the same setup (border sprites enabled). Open Pointer preferences and draw some vertical lines at the right edge of the pointer image. Click Use. Move the pointer to the extreme right, then slowly left. Notice that the thickness of the rightmost vertical line (which should be one low-res pixel width) changes as you move the pointer. It alternates between one low-res pixel and half that, until the right edge of the pointer is inside the WB screen are again. A similar thing applies when you set the pointer to high-res; there, the rightmost pixel alternates between normal and disappeared as you move the pointer in from the right.

If you set the Workbench screen mode to super-high res and pointer sprite to low res, the rightmost pixel column of the pointer sprite changes width from 1→2→3→4→1 etc. shres pixels as you move the pointer to the left. With a high-res pointer, the rightmost two pixel columns of the pointer are affected.

I can upload a bootable ADF with those settings if you want.

Update 2: I also got WinUAE (2.7.0 official) to hang/crash by setting full overscan, enabling border sprites and setting the pointer hotspot towards the right of the image, then moving the pointer to/around the upper left of the screen. I managed to trigger the crash in both PAL and NTSC super-high res laced modes (32-colour if that's relevant), but it didn't happen immediately, or every time.

On the crash WinUAE log output was many lines of this:
JIT: Argh --- Am already in a handler. Shouldn't happen!

[mark_k]

Another issue I noticed, this applies when using a super-high res Workbench with border sprites enabled. No overscan needed. When the pointer moves near the bottom of the screen, some stripes appear at the lower right below the active WB screen area. More stripes also appear to the right of those when you move the pointer towards the lower right.

There's a similar issue with stripes at the top right of the screen, when you set a mouse pointer which has its hotspot towards the bottom of the sprite, and move the pointer to the top of the screen.

[Toni Wilen]

Will test later.. (Border corruption is of course a bug)

btw, JIT "caused" crashes are useless, try without JIT.

[mark_k]

Things look slightly different now with WinUAE 2.7.1b1. The stripes are multi-coloured and there are a few stray single pixels.

I also noticed that one pixel row of the sprite is a lighter red than the others. That only applies to a single scanline in the left ~1/3 of the display though. In the pic below you can see where that effect ends. (That effect is present in 2.7.0 too.)

[Toni Wilen]

Right border sprite missing pixels fixed. (When border sprite was detected, rightmost pixel that needs to be drawn calculation didn't include possible extra pixels needed for sprite pixel doubling/quadrupling)

EDIT: I can't duplicate any max right edge disappearing or "interlaced" sprite effects.

[mark_k]

Testing the latest winuae.exe (datestamp 2014-01-04 20:20), there is still a single right pixel of the pointer sprite missing/present, alternating as you move the pointer to the left.

Also the top and bottom stripes are still present. But you only mentioned the right border being fixed so I'm guessing you know that already.

Edit to add: the max right edge disappearing (PAL) / interlaced (NTSC) effect does happen for me with WinUAE 2.7.0 but not with 2.7.1b1. The attached zip file contains a bootable ADF and config. Boot with Kickstart 3.1 ROM. With WinUAE 2.7.0, double-click the MaxOverscan.pre icon, then move pointer to the right.

Edit 2: If you boot that disk, then double-click one of the high-res pointer preset icons, the right half of the sprite is missing. That's an OS bug rather than an emulation problem, right?

[Toni Wilen]

Both borders should be fixed now.

Disappearing sprite was caused by bad update in 2.7.0 (which also broke part of Elfmania scoreboard).

If you boot that disk, then double-click one of the high-res pointer preset icons, the right half of the sprite is missing. That's an OS bug rather than an emulation problem, right?

Bug or restriction. Sprite size change (16 <> 32 <> 64 wide) requires copperlist modification and perhaps old programs assume mouse cursor change must be immediate, without calls to slow routines that are needed to rebuild copperlist.

[mark_k]

With the latest winuae.exe everything seems fine with border sprites, except that strange "slightly lighter red line" when the pointer extends above the top of the Workbench screen.

The width of the lighter region seems to vary depending on screen res (high res or super high res) and depth.

Could it perhaps not be an emulation problem, but related to the graphics.library copperlist? I took a screen capture to see exactly what the colours were. The red sprite colour is E04040, whereas the lighter colour is EE4444. Notice that the OCS/ECS colour E44 would convert to 24-bit AGA EE4444. But maybe there's a bug in graphics.library which, except for that one partial scanline, incorrectly converts it to E04040??? Does it happen on a real AGA machine?

Originally Posted by Toni Wilen

Bug or restriction. Sprite size change (16 <> 32 <> 64 wide) requires copperlist modification and perhaps old programs assume mouse cursor change must be immediate, without calls to slow routines that are needed to rebuild copperlist.

Perhaps it's a bug in IPrefs then? Even running a program which opens a custom screen (which should cause the system copperlist to be rebuilt) doesn't restore the missing right half of the pointer.

[Toni Wilen]

Originally Posted by mark_k

Could it perhaps not be an emulation problem, but related to the graphics.library copperlist? I took a screen capture to see exactly what the colours were. The red sprite colour is E04040, whereas the lighter colour is EE4444. Notice that the OCS/ECS colour E44 would convert to 24-bit AGA EE4444. But maybe there's a bug in graphics.library which, for at least that one partial scanline, incorrectly converts it to E04040??? Does it happen on a real AGA machine?

It is AGA hardware "problem", full AGA color palette update needs two color register writes, first high 4 bits of all color components is written (does same as OCS/ECS), this also automatically updates low 4 bits to emulate OCS/ECS colors (E44 becomes EE4444, FFF becomes FFFFFF because F0F0F0 would not be full white anymore on AGA when running OCS/ECS software). Next write updates low 4 bits to final color value (000 is written: E04040). Color can be slightly wrong between those two writes and it can be wrong quite long time (more than 2 scanlines in worst case) because copperlist normally writes all colors' high bits and then all low bits (which is more optimal, switching between low and high bits requires yet another write to separate control registers)

[mark_k]

Ah that explains it. I guess Pointer prefs sets the pointer colour to E04040 (when in reality EE4444 would be more correct). It seems the ROM default pointer red colour is EE4444.