WinUAE 2.7.0 beta series

[Toni Wilen]

http://www.winuae.net/files/b/winuae_2700b16.zip

Beta 16: (RC1. Next week.)

- Z3 RTG base address was not adjusted if Processor Slot RAM was 128M.
- Writing to high BPL pointer when next cycle does same bitplane number DMA fetch: old address is used for fetch. (Powertrax / The Light Circle graphics glitch)
- Added workaround for Windows 8.1 bug, after SetCursorPos() call WM_MOUSEMOVE returns new coordinate as expected, then comes single message with old coordinate (this shouldn't happen) before it works correctly again. This fixes "Windows mouse" jumping ~50 pixels while moving the mouse. Rawinput HID mouse is not affected by this bug. (No, KB2908279 does not fix it, I guess working fix will be released someday)
- "Install mouse driver" + RTG mode has been unusable since 2600b1.
- Re-enabled "CIA TOD bug" by default but only in A500-like modes.
- Built-in HRTMon updated to 2.35
- Built-in AROS ROM updated. Added memory hack, bootup structures are allocated from hidden memory pool (located at 0xa80000-0xb80000, automatically enabled if built-in AROS rom is in use), when AROS starts booting from disk or HD, hidden pool is marked as full and all following allocations come from normal RAM. Now even 512k chip only config will boot and work with AROS rom replacement. Hack only used if CPU has 24-bit address bus. (68000/68010/68EC020).

[mark_k]

Originally Posted by Toni Wilen

[About Cirrus Logic bugs] (I think it is time to collect all bugs in one report and send to qemu developers)

I'd be happy to post a list to the qemu mailing list and/or bugtracker if you don't have time to do that. I think it would be appreciated; I noticed someone posted to qemu-devel recently mentioning Cirrus bugs. Probably the bugs you fixed would solve their problem too.

[Toni Wilen]

Originally Posted by mark_k

I'd be happy to post a list to the qemu mailing list and/or bugtracker if you don't have time to do that. I think it would be appreciated; I noticed someone posted to qemu-devel recently mentioning Cirrus bugs. Probably the bugs you fixed would solve their problem too.

I quickly found following changes: (Sources have " TW." in comments + explanation for change)

BLTUNSAFE() macro is broken. It assumes source and destination have same size and it rejects valid blits if blit is special, for example color expansion.

cirrus_do_copy(): "extra x, y", s->cirrus_blt_srcpitch or s->cirrus_blt_dstpitch can be zeros: division by zero. depth==0 in planar VGA modes, test and set it to 1.

cirrus_bitblt_start(): CIRRUS_BLTMODE_TRANSPARENTCOMP, "If color expansion is used with transparency, background pixels are not written."

CIRRUS_BLT_STATUS bit was missing. PicassoII driver polls this to check if blit has finished.

cirrus_write_bitblt(): Blitter CIRRUS_BLT_RESET start condition check was wrong.

cirrus_get_offsets(): CL 5434/36 "32bit/Pixel Data at Pixel Rate" = Offset doubled. Interlace and multiply vertical registers by two added.

cirrus_get_bpp16_depth(): Missing depth=8 check added.

cirrus_get_resolution(): "if 16 bit mode but SR7 bit 7 == 0: 2x width and palette mode". Interlace and multiply vertical registers by two added.

cirrus_linear_read() and cirrus_linear_write(): "linear vram also need planar handling" (PC hardware may not need this?)

cirrus_reset(): 5434 and newer have 4M support, was 5446 and newer.

DRAM Control register/valid_memory_config variable: handle memory mapping (fixes VRAM size detection if driver tries to find memory size by trying invalid settings for current hardware)

glue(glue(glue(cirrus_colorexpand_transp_, ROP_NAME), _),DEPTH), glue(glue(glue(cirrus_colorexpand_pattern_transp_, ROP_NAME), _),DEPTH): "Color expansion + transparency: fgcol, not bgcol"

glue(cirrus_bitblt_rop_fwd_, ROP_NAME)(CirrusVGAState *s,
uint8_t *dst,const uint8_t *src,
int dstpitch,int srcpitch,
int bltwidth,int bltheight)
glue(cirrus_bitblt_rop_bkwd_, ROP_NAME)(CirrusVGAState *s,
uint8_t *dst,const uint8_t *src,
int dstpitch,int srcpitch,
int bltwidth,int bltheight)
: optimize plain copy blits by using ROP_OP_32 when possible

vga.c: vga_draw_graphic() seems to assume shift_control = (s->gr[VGA_GFX_MODE] >> 5) & 3; must be >=2 (bit 6 of Mode Register is "256 color mode") or it uses standard VGA graphics mode, even if cirrus extended registers are used to enable extended (SVGA) modes. My workaround was to set bit 6 when any extended mode is enabled. This may be bug in my implementation.

[mark_k]

Originally Posted by Toni Wilen

- Added configurable directory filesystem file/directory name length limit, currently config file only, filesys_max_name_length=x, files and dirs with longer names are not seen in Amiga-side (directory operations only)

Is there a known safe maximum name length for the Workbench 3.1 CLI commands?

For example after CDing to my shared directory (which has some long filenames) List #?.lha works okay but Dir #?.lha gives a software failure requester (#80000002).

Strangely though, if I do Dir SHARE:#?.lha when the current directory isn't SHARE:, that seems to work fine!

Obviously limiting length to 30 is guaranteed safe, but maybe the Dir command actually has a higher usable limit?

[mark_k]

I had a quick play with CyberGraphX version 3 (available on Aminet). Some issues I noticed. Note that any or all of these might just be bugs in CGX since I didn't test on real hardware. But anyway.

From a fresh WB 3.1 installation I installed CGX3. Using emulated Piccolo card. I set Workbench to various modes, ran MultiView SCREEN (which opens using the same mode/depth as WB) then changed WB screenmode to another depth/resolution and saw what effect dragging the front screen down had.

Sometimes the mouse pointer gets stuck/vanishes (or the actual pointer position is different from where the pointer sprite image is).

Example: Set Workbench to CGX 8-bit 640x480 4 colours. Run MultiView with SCREEN tooltype, open e.g. S:Startup-sequence. MultiView opens its screen in the same mode as Workbench. Use Screenmode prefs to change WB mode to 24-bit 800x600. Try to drag WB screen down. It can only be dragged half-way down the screen. In the half-way-down position, move mouse pointer around and notice it disappears sometimes. If you keep moving the pointer downwards, the WB screen eventually auto-scrolls up to fill the whole emulation window again.

I also noticed many log messages on dragging screens: GFX SPECIAL BPUT IO 00008000 = 71 when RTG screen frontmost, GFX SPECIAL BPUT IO 00008000 = 51 when native screen frontmost. Maybe CGX repeatedly sets the RTG/native switch whenever screens are dragged?

On a rare occasion I noticed the rear screen image was corrupted or all-black when dragging the front screen down. That's probably more likely to happen when the screens have different depths (e.g. one 24-bit, the other 15).

[Toni Wilen]

Originally Posted by mark_k

I had a quick play with CyberGraphX version 3 (available on Aminet). Some issues I noticed. Note that any or all of these might just be bugs in CGX since I didn't test on real hardware. But anyway.

Exactly. I won't bother with it until confirmed on same real hardware.

I also noticed many log messages on dragging screens: GFX SPECIAL BPUT IO 00008000 = 71 when RTG screen frontmost, GFX SPECIAL BPUT IO 00008000 = 51 when native screen frontmost. Maybe CGX repeatedly sets the RTG/native switch whenever screens are dragged?

Bit toggled (bit 6) is interrupt enable/disable bit. Bit 5 is passthrough switch bit.

[msayed1977]

- Added workaround for Windows 8.1 bug, after SetCursorPos() call WM_MOUSEMOVE returns new coordinate as expected, then comes single message with old coordinate (this shouldn't happen) before it works correctly again. This fixes "Windows mouse" jumping ~50 pixels while moving the mouse. Rawinput HID mouse is not affected by this bug. (No, KB2908279 does not fix it, I guess working fix will be released someday)

I have found that Microsoft has released v2 of KB2908279 fix. I do not know whether it fixes this bug or not.