WinUAE 2.3.2 beta series

[mfilos]

Awesome update Toni!!! Thanks \o/

[hexaae]

Near perfection....

[Toni Wilen]

Originally Posted by hexaae

Near perfection....

No, it isn't!

[hexaae]

That's what I like best...
Months ago I thought it was very unlikely to have emulated SCSI commands to make CD-AUDIO games like T-Zer0 work with WUAE, but you did it...

[Dwyloc]

@Toni Wilen
This may just be user error but I am unable to get the latest beta or previous
release to allow me to have configuration with kickstart 3.1, 68000 CPU full ECS chipset 2MBs chipram and 1.5MB slow ram.

When ever I select the above config WinUAE boot workbench 3.1 fine but reverts to having just 1MB slow ram instead of the 1.5MB selected.

I am not sure if this is intended behaviour or not but as it would recreate the configuration of my 4MB minimig as it uses 512K for the kickstart rom it would be a useful configuration for testing.

[Toni Wilen]

Originally Posted by Dwyloc

@Toni Wilen
This may just be user error but I am unable to get the latest beta or previous
release to allow me to have configuration with kickstart 3.1, 68000 CPU full ECS chipset 2MBs chipram and 1.5MB slow ram.

When ever I select the above config WinUAE boot workbench 3.1 fine but reverts to having just 1MB slow ram instead of the 1.5MB selected.

I am not sure if this is intended behaviour or not but as it would recreate the configuration of my 4MB minimig as it uses 512K for the kickstart rom it would be a useful configuration for testing.

You probably have IDE or PCMCIA (Gayle) feature enabled. Set chipset extra to "A500".

[Dwyloc]

Originally Posted by Toni Wilen

You probably have IDE or PCMCIA (Gayle) feature enabled. Set chipset extra to "A500".

Thanks for the explanation, so user error again :-)

It would be a nice enhancement to the GUI if it ghosted out the option when for more than 1MB of slow ram when the other options are selected.

Off topic: Sadly I guess that means I cant recreated my 4MB Minimigs configuration under WinUAE as it has IDE and 1.5MB slow and 2MB of chip, but then it is an Amiga Emulator, not an Amiga Clone emulator :-)

Thanks again for taking the time to set me right and all your hard work on
WinUAE.

[Toni Wilen]

Originally Posted by Dwyloc

Thanks for the explanation, so user error again :-)

It would be a nice enhancement to the GUI if it ghosted out the option when for more than 1MB of slow ram when the other options are selected.

Off topic: Sadly I guess that means I cant recreated my 4MB Minimigs configuration under WinUAE as it has IDE and 1.5MB slow and 2MB of chip, but then it is an Amiga Emulator, not an Amiga Clone emulator :-)

Thanks again for taking the time to set me right and all your hard work on
WinUAE.

I never really bothered with this too much (limit become too low) because there are no real Amigas that can have both slowram and IDE without hardware hacks.

[Dr.Venom]

Hi Toni,

When playing a game that switches in-game to interlaced mode and then back to non-laced, then the custom chipset_refreshrate setting is lost. It still shows the value in the menu (F12), but it isn't applied anymore.

For example in Slamtilt in multiball mode the screen switches to interlaced mode, but after switching back to lowres the custom chipset_refreshrate setting is ignored.

Hopefully you can fix this.

Thx and best

[Toni Wilen]

Originally Posted by Dr.Venom

Hi Toni,

When playing a game that switches in-game to interlaced mode and then back to non-laced, then the custom chipset_refreshrate setting is lost. It still shows the value in the menu (F12), but it isn't applied anymore.

For example in Slamtilt in multiball mode the screen switches to interlaced mode, but after switching back to lowres the custom chipset_refreshrate setting is ignored.

I can't duplicate it using WB lace<>nonlace switching, it works fine.
(always find the most simple test and I am also quite sure this has nothing to do with 2.3.2 betas either = I become even more lazy)

[Toni Wilen]

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

Beta 8 (RC1. Few days only to go):

- always disable FPU when using GUI to change CPU to 68000 or 68010
- slow ram max is now 1.5M (was 1.0M) when Gayle features are enabled
- stereo separation 0% equaled 100% if stereo delay was 0 or 1
- stereo delay 1 was same as 0
- brightness/contrast/gamma read-only numeric value box added
- AROS rom updated

[Dr.Venom]

Originally Posted by Toni Wilen

I can't duplicate it using WB lace<>nonlace switching, it works fine.
(always find the most simple test and I am also quite sure this has nothing to do with 2.3.2 betas either = I become even more lazy)

I guess it's a more subtle problem than "lazy testing" will show.

I digged a bit deeper and found out a bit more. When a floating point chipset_refreshrate value is set, it seems to get reset to the nearest integer value after nonlace>lace>nonlace switching in a game or demo. Eg. 49.996 gets reset to 50, but say 51.22 is not resetted back to 50. It stays at 51.22, or it might get reset to 51 instead (this bit is speculation from my side, as it is not easy to test in my current setup).

An easy/simple test (well...)
To find a really easy test example isn't easy, but i'll try. I'll also explain a bit more than needed probably, just to avoid misunderstanding. Just skip the parts you already know... I'll take my LED screen as example.

The LED screen in HDMI mode has a refresh rate of ~50.0017. If I run WinUAE at the default setting of 50 I get rolling screen tearing in the no-buffering display mode (my preferred mode as you know ). By a little calibration of the chipset_refreshrate value to about 49.996 the screen tearing is stabilized to only a few lines jittering back and forth in the same place. As per the earlier discussion/topic about this issue.

So for clarity, the symptom I get when playing Slamtilt is that when the chipset_refreshrate is set to 49.996 it works perfectly and the screen tearing is minimized, as long as the game is in lowres mode. But once the game switches to highres laced in multiball and back, then the rolling screen tearing is introduced again. The floating point value of 49.996 seems to be reset to the nearest integer (50). If I press F12 it still shows the floating point value, but it isn't applied. I need to change it only slightly, to say say 49.9961 and then it's applied again.

This can be tested somewhat easier then playing through Slamtilt. Enable the no-buffering display mode in WinUAE and load up any A500 game that only uses lowres and lots of scrollling screen parts. For example Jim Power. You'll probably notice rolling screen tearing with the refresh rate left at the default (50). Calibrate shortly to a value that stabilizes to screen tearing to only a few lines jittering back and forth.

Now load up a game that uses a highres laced screen somewhere. My examples would be Agony or Shadow of the Beast, which both have an interlaced loading picture. Let's take Beast as the example. Load up this game with the calibrated (floating point) value for the chipset_refreshrate. You'll notice that after loading up the game and going past the interlaced loading picture, that the rolling screen tearing is introduced again at the title screen of Beast (with the multi-layered scrolling "forest" (don't know how to exactly call it.)

Hope this illustration and simple (YAY! not ) example helps.....

[Toni Wilen]

But it still does not happen on WB. I did say I always use the most simple test case and you again ignored it

[Dr.Venom]

Yes, but I can't see how you can test/prove this on a static workbench screen, as a static screen doesn't show screen tearing?

[Toni Wilen]

Originally Posted by Dr.Venom

Yes, but I can't see how you can test/prove this on a static workbench screen, as a static screen doesn't show screen tearing?

I'll of course check the FPS counter at the bottom. I am not going to check for tearing etc when there is much easier way. You are still looking at this problem from wrong angle

[Dr.Venom]

I'm probably not making myself clear enough. This issue doesn't show by looking at the fps counter; that was my point when saying that it seems to get rounded to the nearest integer. Ofcourse I also inmediately tested this after your "make an easy test" comment, by looking at the fps counter and setting it to values like eg. 48.22 and 51.12 in the expectation that it would reset to 50, thus apparently showing an example of it through the fps counter. But it does not, unfortunately. It's more subtle, the floating point values seems to get reset to the nearest integers, which the counter in the bottom will not reveal as it only shows integer values.

So:

• a value of 49.996 gets reset to 50 after the lace-nonlace switch --> this can't be proven by looking at the fps counter, as that only shows the integer values (a value of "50" both before and after the switch).
• setting a value of 51.22 or 48.22 seems to get reset to the nearest integers (or not changed at all?), so both before and after the lace<>nonlace switching the fps counter will still show "51" or "48", thus you can't draw any conclusions on the case in point.

Could it be that you're still looking at this problem from the wrong angle?

[Toni Wilen]

I don't have time to look at it from any angle anymore unless there is enough information to find the problem without any extra debugging. It is more or less too late now.

Possible tests: does it "fix" itself if you change for example doubling mode, exit gui? Does it get "fixed" if you adjust rate to some other value, exit gui, enter gui and change it back to original? Can it be "fixed" at all without restarting?

[Dr.Venom]

Yes, it "fixes" itself by the things you mention.

So:

• enter gui, change line mode to normal, exit gui, enter gui, change line mode back to double -> problem is "fixed"
• enter gui, change rate to some other value, exit gui, enter gui, change rate back to original -> problem is "fixed"

[Toni Wilen]

Originally Posted by Dr.Venom

Yes, it "fixes" itself by the things you mention.

So:

• enter gui, change line mode to normal, exit gui, enter gui, change line mode back to double -> problem is "fixed"
• enter gui, change rate to some other value, exit gui, enter gui, change rate back to original -> problem is "fixed"

And just entering and exiting GUI won't fix it, right?

[Dr.Venom]

That's right, just entering and exiting the gui does not fix it.