English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 30 November 2013, 14:24   #321
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
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).
Toni Wilen is offline  
Old 01 December 2013, 15:20   #322
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,966
Quote:
Originally Posted by Toni Wilen View Post
[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.
mark_k is offline  
Old 01 December 2013, 15:48   #323
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by mark_k View Post
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.
Toni Wilen is offline  
Old 01 December 2013, 16:28   #324
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,966
Quote:
Originally Posted by Toni Wilen View Post
- 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 is offline  
Old 01 December 2013, 16:52   #325
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,966
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).
mark_k is offline  
Old 01 December 2013, 17:36   #326
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by mark_k View Post
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.

Quote:
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.
Toni Wilen is offline  
Old 04 December 2013, 00:37   #327
msayed1977
Better than the Original
msayed1977's Avatar
 
Join Date: May 2008
Location: Cairo, Egypt
Posts: 145
Quote:
- 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.
msayed1977 is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
WinUAE 2.5.1 beta series Toni Wilen support.WinUAE 69 22 December 2012 11:22
WinUAE 2.3.3 beta series Toni Wilen support.WinUAE 124 17 September 2011 16:48
WinUAE 2.3.2 beta series Toni Wilen support.WinUAE 79 31 May 2011 20:39
WinUAE 2.3.0 beta series (was 2.2.1) Toni Wilen support.WinUAE 229 22 September 2010 20:20

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 09:04.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.06792 seconds with 14 queries