WinUAE 2.4.0 beta series

[mark_k]

About the CD being mounted even when "CDFS automount CD/DVD drives" is not checked...

It seems that if the user changes the state of the CDFS automount checkbox, the change is not recognised is some cases. Example:

• Run WinUAE. In the Hard drives tab, select a CD ISO image file and check the CDFS automount box. Start emulation. (I'll assume you have also configured a hard drive to boot from.)
• After you have booted to Workbench you should see an icon for the mounted CD. Press F12, uncheck CDFS automount, then click Reset.
• The Amiga reboots and loads Workbench, but the disk icon for the CD still shows up (i.e. the CD was auto-mounted).
• Press F12 and look in the Hard drives tab. Notice that the CDFS automount box is still unchecked.

The same issue happens the other way around too. You can initially boot with CDFS automount unchecked. So no CD icon on Workbench. Checking the automount box and clicking Reset, the CD is not auto-mounted.

[Mequa]

Originally Posted by Toni Wilen

it is only CDFS that has this extra non-commercial license. Other aros modules are fine.

Is that AROS CDFS module actually GPL-incompatible, or just with the commercial needs of WinUAE?

(I assume the included AROS ROM is GPL-compatible.)

[Toni Wilen]

Originally Posted by Mequa

Is that AROS CDFS module actually GPL-incompatible, or just with the commercial needs of WinUAE?

(I assume the included AROS ROM is GPL-compatible.)

AFAIK GPL'd software can't be GPL'd and at the same time have commercial usage restrictions so yes and no.

Of course this probably needs to be checked by some legal expert but I'll take the "better safe than sorry" option when it is about legal stuff

[Toni Wilen]

Originally Posted by mark_k

About the CD being mounted even when "CDFS automount CD/DVD drives" is not checked...

Some options work this way and have always worked this way.. Not specific to 2.4, needs to be fixed some day..

[Bonifacy]

Originally Posted by Toni Wilen

Filters can require more processing time causing tearing but it still shouldn't happen (in non-fastest possible modes) because filters are processed immediately after emulated frame has been finished (which usually only takes max 20%-30% of real world frame time leaving lots of time for filter processing)

Check winuaelog.txt. Maybe the filter does not load correctly.

Nope. Everything seems fine unfortunately.

20-133 [0 000x000]: Max hardware surface size: 16384x16384
20-137 [0 000x000]: winuae_active(0)
20-182 [0 000x000]: Direct3D: Pixel shader 2.0+ support detected, shader filters enabled.
20-642 [0 000x000]: D3D9Ex: 00000056 ALPHA DYNAMIC 
20-642 [0 000x000]: D3D9Ex: PS=3.0 VS=3.0 16384*16384*50 FS VS=-1 B=0I 32-bit 0
20-699 [0 000x000]: D3D9Ex: pixelshader filter 'D:\Retro\Amiga\Emulators\WinUAE 2.4\plugins\filtershaders\direct3d\_winuae.fx' enabled
20-699 [0 000x000]: D3D9Ex: Attempting to load 'D:\Retro\Amiga\Emulators\WinUAE 2.4\plugins\filtershaders\direct3d\CRT.D3D.fx'
20-887 [0 000x000]: D3D9Ex: pixelshader filter 'D:\Retro\Amiga\Emulators\WinUAE 2.4\plugins\filtershaders\direct3d\CRT.D3D.fx' enabled
20-906 [0 000x000]: D3D9Ex: 1920*1080 texture allocated, bits per pixel 32
20-906 [0 000x000]: D3D9Ex: 3840*2160 working texture allocated, bits per pixel 32
21-042 [0 000x000]: POS (0 0 1920 1080) - (-960 -540 0 -270)[960,270] (480 405)

[Toni Wilen]

Originally Posted by Bonifacy

Nope. Everything seems fine unfortunately.

20-133 [0 000x000]: Max hardware surface size: 16384x16384
20-137 [0 000x000]: winuae_active(0)
20-182 [0 000x000]: Direct3D: Pixel shader 2.0+ support detected, shader filters enabled.
20-642 [0 000x000]: D3D9Ex: 00000056 ALPHA DYNAMIC 
20-642 [0 000x000]: D3D9Ex: PS=3.0 VS=3.0 16384*16384*50 FS VS=-1 B=0I 32-bit 0
20-699 [0 000x000]: D3D9Ex: pixelshader filter 'D:\Retro\Amiga\Emulators\WinUAE 2.4\plugins\filtershaders\direct3d\_winuae.fx' enabled
20-699 [0 000x000]: D3D9Ex: Attempting to load 'D:\Retro\Amiga\Emulators\WinUAE 2.4\plugins\filtershaders\direct3d\CRT.D3D.fx'
20-887 [0 000x000]: D3D9Ex: pixelshader filter 'D:\Retro\Amiga\Emulators\WinUAE 2.4\plugins\filtershaders\direct3d\CRT.D3D.fx' enabled
20-906 [0 000x000]: D3D9Ex: 1920*1080 texture allocated, bits per pixel 32
20-906 [0 000x000]: D3D9Ex: 3840*2160 working texture allocated, bits per pixel 32
21-042 [0 000x000]: POS (0 0 1920 1080) - (-960 -540 0 -270)[960,270] (480 405)

Another reason why log should be always included. You use fullscreen resolution but it works if resolution is close enough to native amiga internal resolution.

This filter can't work correctly with this new system where texture is larger than visible area. May be fixed later (if possible).

[Toni Wilen]

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

Beta 25: (RC3. Release date next week. Really.)

- CDFS ACTION_EXAMINE_ALL fixed.
- CDFS file/directory search now uses simple hash table for better performance.
- Fixed crash introduced in b23 if filesystem was asked to open directory that couldn't be opened.
- Directory filesystem host memory leak fixed (leaked few bytes when filehandle was closed). Very old bug.
- Autodetect old-style geometry if >512M OFS/FFS partition hardfile was created with older UAE version.
- Some rare DMS files didn't unpack properly.
- Possible fix for diagonal artifact in some D3D filter modes.

[Mequa]

Question: Will legacy Vsync retain the same functionality as earlier versions of WinUAE, including in fastest possible + non-JIT mode?

Also, will the CD32 boot-with-JIT bug be fixed?

[Toni Wilen]

Originally Posted by Mequa

Question: Will legacy Vsync retain the same functionality as earlier versions of WinUAE, including in fastest possible + non-JIT mode?

Not guaranteed, at least unless someone reminds about it when/if it gets broken and also includes useful enough report

Fastest possible was never supported in vsync until now in low latency mode.

Also, will the CD32 boot-with-JIT bug be fixed?

It seems to work again, probably due to big timing changes in recent versions.

[Toni Wilen]

Following still missing CDFS features added:
CDFS volume creation date
CDFS HighCyl geometry value wasn't updated.

Will be included in tomorrow's (final, unless something really bad happens) beta.

[mark_k]

Originally Posted by Toni Wilen

- More logical "RDB: WARNING: end of partition > size of disk" message. Check RDSK header size and partition(s) size separately.

The RDSK header warning is printed once, plus once for every partition on the disk. So for my HD image file with four partitions, it gets printed 5 times. Probably only the first time is necessary?

Also, the numbers in the warning message are wrong; 17850000 is the original hard drive's number of sectors (or maybe the number of sectors from the fake geometry in the RDSK - which I might have arranged to match the actual number of sectors), but the following number is the byte size of the HDF. So either multiply 17850000 by the sector size, or divide the HDF size by the sector size for the warning.

RDSK dump end
RDB: WARNING: RDSK header disk size > disk size! (17850000 > 4294967296)
Mounting uaehf.device 0 (0) (size=4294967296):
Z:\my_amiga_hd_4gb.bin:
RDB: WARNING: RDSK header disk size > disk size! (17850000 > 4294967296)
Mounting uaehf.device 0 (1) (size=4294967296):
RDB: Automount disabled, not mounting
Z:\my_amiga_hd_4gb.bin:
RDB: WARNING: RDSK header disk size > disk size! (17850000 > 4294967296)
Mounting uaehf.device 0 (2) (size=4294967296):
RDB: Automount disabled, not mounting
Z:\my_amiga_hd_4gb.bin:
RDB: WARNING: RDSK header disk size > disk size! (17850000 > 4294967296)
Mounting uaehf.device 0 (3) (size=4294967296):
RDB: Automount disabled, not mounting
Z:\my_amiga_hd_4gb.bin:
RDB: WARNING: RDSK header disk size > disk size! (17850000 > 4294967296)

[mark_k]

A small suggestion for A2024 support... when the user sets External display hardware in Chipset Options to A2024 (or I guess anything other than -), if filter is set to none show a dialog saying something like "Null filter required for A2024 emulation, enabling"

[Toni Wilen]

Originally Posted by mark_k

A small suggestion for A2024 support... when the user sets External display hardware in Chipset Options to A2024 (or I guess anything other than -), if filter is set to none show a dialog saying something like "Null filter required for A2024 emulation, enabling"

No. Automatic configuration changes are never reported and never will.

[Toni Wilen]

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

Beta 26: (RC4 and hopefully final)

- CDFS missing features added: HighCyl value and volume creation timestamp. I think all features are now done.
- CDFS media change stability improved (removing unreadable CD crashed)
- Forgot to mention: UAE CDFS also works fine under KS 1.x. (AROS CDFS was 2.0+)

[mark_k]

Originally Posted by Toni Wilen

No. Automatic configuration changes are never reported and never will.

Well okay, but could there be an automatic configuration change here? There isn't one at the moment. So a typical user might enable A2024 or Grafitti then wonder why the display isn't working properly (if they had filter set to none) because WinUAE doesn't enable the null filter in that case.

[Toni Wilen]

Originally Posted by mark_k

Well okay, but could there be an automatic configuration change here? There isn't one at the moment. So a typical user might enable A2024 or Grafitti then wonder why the display isn't working properly (if they had filter set to none) because WinUAE doesn't enable the null filter in that case.

I thought you meant you wanted a dialog to be displayed before it is automatically set. Not that it does _not_ change it automatically.

Starting from beta 24 I can't save States any longer, WinUAE always crash, dump attached

[Mequa]

Originally Posted by Toni Wilen

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

Beta 26: (RC4 and hopefully final)

- CDFS missing features added: HighCyl value and volume creation timestamp. I think all features are now done.
- CDFS media change stability improved (removing unreadable CD crashed)
- Forgot to mention: UAE CDFS also works fine under KS 1.x. (AROS CDFS was 2.0+)

Mostly good, however I still get a bit of slowdown in the Super Stardust tunnel demo I posted here when using fullscreen mode with new vsync and fastest possible CPU. Could someone see if they can replicate this? Oddly, switching from fullscreen to full-window mode seems to improve things (it has the opposite effect with many other programs!)

[Toni Wilen]

Originally Posted by chris70c

Starting from beta 24 I can't save States any longer, WinUAE always crash, dump attached

http://www.winuae.net/files/b/winuae.zip should fix it, please confirm. (Only happened when directory filesystem was enabled)

Works perfectly fine now, thanks