WinUAE 2.3.3 beta series

[Toni Wilen]

2.3.3 beta series.

New VSync mode and bug fixes.

Quick rules:

Allowed posts in this thread:

- bug reports but make sure bug is NOT in previous offical version. (Old bug -> separate thread)
- comments and suggestion about new features in betas or changed feature in beta. (missing feature or old feature which has not been changed in latest beta series -> separate thread)

Everything else will be deleted, no questions asked. (includes offtopic posts, discussion about pros and cons of public beta testing etc..)

Misc notes:

- "not working" is not a bug report -> instadelete
- always include name of the program. "Everything" or "most games" fail is not a bug report!
- always use quickstart settings. Non-QS setting reports will be ignored unless there is reason why quickstart isn't good idea but still test using quickstart just to confirm! (unless it needs some HD highend config)
- always check logs (both winuaebootlog.txt and winuaelog.txt, don't forget to enable logging in misc-panel) for possible error or warning messages.
- remember to include PC specs + Windows version (if asked)
- graphics error -> include screenshot.
- disk based program -> include CRC32 (mouse over disk history arrow down button will show CRC32) of the image(s) (or SPS ID or full tosec name if from latest set). Plain name of the game is NOT generally enough! (usually there are different cracks, trainers etc..)

As usual, betas may destroy your PC and your sanity

This thread is for general discussion (bad/good/stupid idea/whatever, no trolling or flaming) about public beta testing.

Beta test related PMs or emails will be generally ignored.

[Toni Wilen]

Beta 1:

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

- new vsync option
* does not need extra buffers (very little input lag), make sure "no buffering" is selected
* works also in windowed/fullwindow mode
* attemps to autodetect exact refresh rate, ignores what Windows/driver reports
* less busy waiting, no more continuous 100% CPU usage
* much more stable than "normal" vsync
- old vsync is currently always forced to new mode
Usual vsync restrictions still apply: do not use fastest possible modes, 50Hz capable display and driver required if you want proper PAL speed.
Old vsync support may disappear later.

- keep old joystick Gameports setting if no joysticks detected when loading config file
- another method to enable unconfigured joystick: quick firebutton press = joystick port, long press = mouse port
- unconfigured joystick move left/right can also be used to enable joystick
- DirectDraw and 2x filter = non-centered image, broke few releases ago
- IDE multiple sector writes fixed (2.3.2 final fixed spurious interrupts but fix wasn't complete, last interrupt didn't always arrive causing driver to hang)
- set IDE CHS/LBA address after read/write command has finished as explained in ATA-1 spec (last accessed sector, not next sector). This is undefined in later ATA spec versions, but AOS IDE driver >256 sector transfers corrupt data if this is not handled exactly as ATA-1 spec says. (Infamous "max transfer problem")
- detect and log split >256 block IDE transfers
- only load OFS from RDB if partition and RDB filesystem dostype matches exactly
- create _winuae.fx only if full D3D plugin path exists
- A590/A2091 boot ROM was mapped non-executable, crashed on 68020+ CPUs

[Steve]

Originally Posted by Toni Wilen

Beta 1:

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

- new vsync option
* does not need extra buffers (very little input lag), make sure "no buffering" is selected

I have not tested this yet. Not sure if its worth using vsync if you dont have 50hz capable display? Anyway why not just grey out the buffering option (when new vsync is selected) so it can't be changed by the user. Would surely save some user confusion.

[Toni Wilen]

Originally Posted by Steve

I have not tested this yet. Not sure if its worth using vsync if you dont have 50hz capable display? Anyway why not just grey out the buffering option (when new vsync is selected) so it can't be changed by the user. Would surely save some user confusion.

It is beta If new method works fine, old method goes away etc..

50Hz is quite common today, most modern HD resolution LCD TVs and PC monitors accept 50Hz (via DVI or HDMI), but only when using "HD" resolutions (1920x, 1280x)

[Steve]

Originally Posted by Toni Wilen

It is beta If new method works fine, old method goes away etc..

Ok.

50Hz is quite common today, most modern HD resolution LCD TVs and PC monitors accept 50Hz (via DVI or HDMI), but only when using "HD" resolutions (1920x, 1280x)

Damn, my modern HD widescreen Samsung Syncmaster LCD (1920x1080) PC monitor only wants to do 60Hz.

[Dr.Venom]

Originally Posted by Steve

Damn, my modern HD widescreen Samsung Syncmaster LCD (1920x1080) PC monitor only wants to do 60Hz.

Modern but not modern enough for retro compatibility

I guess these days you can only be really sure by checking (before buying ) that the monitor also has a HDMI connection, as PAL 50hz and real NTSC (59.94hz) are part of the specification.

[Steve]

Originally Posted by Dr.Venom

Modern but not modern enough for retro compatibility

I guess these days you can only be really sure by checking (before buying ) that the monitor also has a HDMI connection, as PAL 50hz and real NTSC (59.94hz) are part of the specification.

Oh it has a HDMI and DVI port (I use the DVI to connect to my PC) so maybe it is capable of recieving a 50Hz signal?? Sorry for the OT by the way.

[Dr.Venom]

Originally Posted by Steve

Oh it has a HDMI and DVI port (I use the DVI to connect to my PC) so maybe it is capable of recieving a 50Hz signal?? Sorry for the OT by the way.

Yes it will, as long as you connect your PC and monitor through a HDMI cable. So your GFX card needs to have a HDMI port, or if it has not, at least TV/HDMI compatibility (the manual will show), in which case you need to attach a DVI->HDMI dongle.

Good luck .

[Mad-Matt]

This might seem a silly question, but how to properly test if vsync is working as designed ?

I can set 1080p 50Hz screenmode ok and all seems fine, screen fades are smooth. But its not realy different if I set a 60Hz mode (1980x1200) and use the Autovsync option running the game at 50hz. I cant tell the difference between the two.

And one last thing and please dont castrate me for it as its not a beta specific bug - but only bothering me now im messing with fullscreen vsync options. If attached an image showing that with null filter upscaling the sides dont match with vga pixel aspect (Easy to see with scanlines enabled too) Bilinier filter seems to fix but i dont like the blur. TV mode is also fine, but the missing lines bother me in some games.

[Steve]

Originally Posted by Dr.Venom

Yes it will, as long as you connect your PC and monitor through a HDMI cable. So your GFX card needs to have a HDMI port, or if it has not, at least TV/HDMI compatibility (the manual will show)

Possibly. It isn't too old. Maybe a couple of years. Its a Geforce 9800 GTX+ with dual DVI-I output ports but no HDMI out.

in which case you need to attach a DVI->HDMI dongle.

Good luck .

Aha! I do have one of these already! Never used it but thought it may come in handy eventually. I will try it!

EDIT: OK I have tried it and... IT WORKS!

Although the screen is now too fricking bright! lol. New vysnc mode is working really well so far. I am definitely getting 50Hz refresh rate and its working well. I tried SWOS and Banshee and the scrolling is very smooth although audio seems a bit to go up and down at times. I'm not sure why I don't get the LEDs displayed on fullscreen mode? is this normal. Also Direct3D appears to be working for me this time. I am really impressed with the new vsync option although in windowed mode it still shows on my monitor as 60Hz refresh rate.

[Steve]

I have tested the game ROADKILL using both new vsync and new auto vsync and its the first very fast scrolling game I have tested using the new beta. The fast scrolling shows up some very noticable tearing effect, particularly when driving up the screen in the positive Y-axis direction. The scrolling is very smooth and sound is almost perfect but the tearing effect is quite extreme in this game? Any suggestions. Also I eventually managed to get the on-screen LEDs to work somehow. Not sure why they failed to work before.

EDIT: Ok, forget that last statement. I have tested again but this time re-read the information about vsync mode - specifically the part about no 'fastest possible' cpu setting. I guess this is the cause of the tearing effect and the reason you advise to set cpu speed as 'approx A500/A1200 cycle exact'. Is this the same as ticking cycle-exact in the chipset section?? Too many options for me now! Anyway I ticked both CPU cycle-exact and chipset cycle-exact and sound buffer to 1 and everything runs beautifully! Roadkill is really fast, smooth with no tearing and excellent sound. I am very happy!

Approx cycle-exact makes a big difference - so why not grey out the fastest possible option when vsync is selected??

EDIT: I managed to fix the sound issues I was having by setting the sound buffer to 3. This seems to give me perfect sound although I am constantly paranoid the sound is delayed too much. I am sure its just me though. lol. I tried the ultimate test (Deluxe Galaga) and it plays very well. Also tried Banshee, Aladdin, Soccer Kid and Oscar. They are all playing very smoothly. Honestly, I never thought WinUAE could be as good this! Its awesome now!!

[Dr.Venom]

Originally Posted by Steve

Aha! I do have one of these already! Never used it but thought it may come in handy eventually. I will try it!

EDIT: OK I have tried it and... IT WORKS!

Great that you got it working . The HDMI standard is a blessing for us emulator fans..

EDIT: I managed to fix the sound issues I was having by setting the sound buffer to 3. This seems to give me perfect sound although I am constantly paranoid the sound is delayed too much. I am sure its just me though. lol. I tried the ultimate test (Deluxe Galaga) and it plays very well. Also tried Banshee, Aladdin, Soccer Kid and Oscar. They are all playing very smoothly. Honestly, I never thought WinUAE could be as good this! Its awesome now!!

It's indeed important to get to a stable soundbuffer. Ideally it's fully flat. If the buffer gets to volatile you can get buffer over- and underrruns which will impact the performance of the emulation adversely (either via video, sound and/or input lag). I have it run at a buffer setting of either 3 or 4 ("flat as a pancake stability" ) Interestingly the sound delay is almost unnoticable at that setting. And maybe, just maybe there'll be ways for Toni to further improve on it in the future? Who knows...

About being paranoid about sound delay, you wouldn't be paranoid about it when sitting behind a real amiga in front of a big TV in a large room (say at 4-5 meters distance) would you? While given the speed of sound that would delay the sound with about 10ms already versus what you see on screen...

Originally Posted by Mad-Matt

This might seem a silly question, but how to properly test if vsync is working as designed ?

I can set 1080p 50Hz screenmode ok and all seems fine, screen fades are smooth. But its not realy different if I set a 60Hz mode (1980x1200) and use the Autovsync option running the game at 50hz. I cant tell the difference between the two.

I guess you shouldn't notice any difference, as the only thing AutoVSync does is switching properly between 50/60hz on the same screen. So if you set your configuration to start in a screenmode of 60hz and you load up a PAL game, then given that the screenmode is also available in 50hz, it will automatically switch to that. Conclusion: sounds like everything is working like designed on your computer.

And one last thing and please dont castrate me for it as its not a beta specific bug - but only bothering me now im messing with fullscreen vsync options. If attached an image showing that with null filter upscaling the sides dont match with vga pixel aspect (Easy to see with scanlines enabled too) Bilinier filter seems to fix but i dont like the blur. TV mode is also fine, but the missing lines bother me in some games.

I'm guessing this is not a bug, but purely a settings problem. The behaviour you're seeing is probably caused by the aspect settings. Experiment with different aspect settings, like 5:4 or disabling it alltogether (that would be my suggestion) in the filter panel and you'll find a mode in which the problem you described will not occur. Another possibility is that you've enabled the 'scanlines' setting in Display panel, in combination with the scanlines option from the filter panel.

[Steve]

I managed to crash the emulator a couple of times during my testing. Not sure if I did anything particularly stupid. Two crash dumps attached.

I also have a problem with this new beta and the Roadkill IPF. I get corrupted sound whenever the cars are moving around. Sound is perfectly fine in this game at all other times. Very strange. I restarted the emulator and tried again just in case but same result occured. I made a recording of the dodgy sound which I uploaded to the zone.

[Toni Wilen]

Originally Posted by Steve

I managed to crash the emulator a couple of times during my testing. Not sure if I did anything particularly stupid. Two crash dumps attached.

Do not play with RTG modes and vsync

I also have a problem with this new beta and the Roadkill IPF. I get corrupted sound whenever the cars are moving around. Sound is perfectly fine in this game at all other times. Very strange. I restarted the emulator and tried again just in case but same result occured. I made a recording of the dodgy sound which I uploaded to the zone.

Did you use normal configuration? (Not vsync or similar) Did it work in 2.3.2? (I hope it did..)

[Steve]

Originally Posted by Toni Wilen

Did you use normal configuration? (Not vsync or similar) Did it work in 2.3.2? (I hope it did..)

Ermm, sorry! I thought it was related to the new vsync modes but I have just tested the same IPF with 2.3.2 and get the same problem. I guess its not beta-specific and it isn't related to vsync either as I turned this off.

EDIT:

Ok it may not be beta-related but still interesting. I just tested my original CD32 Roadkill disc and the game works properly using a very similar configuration (with just the CD32 specific bits added). This is still with the new vsync mode. So its a WinUAE/IPF specific problem.

[rsn8887]

Does the new Vsync mode still work in 100 Hz by displaying each frame twice? I really liked that feature of the old Vsync mode.

[Toni Wilen]

Originally Posted by rsn8887

Does the new Vsync mode still work in 100 Hz by displaying each frame twice? I really liked that feature of the old Vsync mode.

It is probably borken because I couldn't test it. For some reason no >75Hz modes are reported anymore, some driver issue probably, monitor is 120Hz LCD which did work when I last tested vsync modes, before "new" vsync was introduced.

[rsn8887]

Originally Posted by Toni Wilen

It is probably borken because I couldn't test it. For some reason no >75Hz modes are reported anymore, some driver issue probably, monitor is 120Hz LCD which did work when I last tested vsync modes, before "new" vsync was introduced.

I just tested it. It still works in 100 Hz mode for me, still doubling each frame like before.

I tested with Hyperdrive in A1200 "approx. A500/A1200 speed" setting, and no frame buffering. Sound and scrolling stability seems very very good. Cpu percentage is less than it was in old Vsync mode, where it was always 100%.

The old VSync still worked in "fastest possible" mode, as long as I used triple buffering, while the new Vsync gives very jerky scrolling in this mode. I don't know anything about the internals, but that might be a reason to still keep the old Vsync as an option?! I know you said to not use fastest possible but I couldn't resist to test it

[Toni Wilen]

The old VSync still worked in "fastest possible" mode, as long as I used triple buffering, while the new Vsync gives very jerky scrolling in this mode. I don't know anything about the internals, but that might be a reason to still keep the old Vsync as an option?! I know you said to not use fastest possible but I couldn't resist to test it

The plan is to improve this later. Technically it should allow fastest possible/JIT vsync without loosing (much) CPU power.

Old mode only sort of worked (depending on your view poit) in fastest possible mode.

[Steve]

Originally Posted by Toni Wilen

Do not play with RTG modes and vsync :

Ok, I am getting some very strange things happening with my workbench now since I removed vsync from my RTG windowed display. When using Direct3D, half the display is black as you can see, but I can still see my mouse. If I switch to DirectDraw then the second display happens with a shrinkage of the display and no mouse pointer??

I managed to get replicate the first bug in WinUAE 2.3.2 but the second seems to be unique to 2.3.3.

EDIT: Right, the first bug seems to have gone?? All I did was change to full-windowed mode and back again and the problem hasn't come back. What the hell?

EDIT: I managed to get the mouse back for the second bug still have the smaller display and a grey vertical moving bar appears whenever I move the mouse pointer.