WinUAE 2.5.0 Beta series (Was 2.4.2)

[Toni Wilen]

Originally Posted by Dr.Venom

Great, fixed black screen with winuae.zip is confirmed.

Great, back to interlace mismatch issue: Does it still happen in all modes or only in non-fastest modes?

[Dr.Venom]

Originally Posted by Toni Wilen

Great, back to interlace mismatch issue: Does it still happen in all modes or only in non-fastest modes?

It still happens in all modes..

EDIT: tested with default A500CE, Approximate, Fastest Possible, each with the Hollywood Poker Pro "test"

[Toni Wilen]

Originally Posted by bernd roesch

When i stay longer on windows side and go back to winuae the clock run faster to reach the correct time.

Perhaps resume from GUI or pause state should simply call timer.device/TR_SETSYSTIME to fix big clock differences immediately (of course only if syncronize clock is enabled)

[MrX_Cuci]

Don't know if this is the right place to post this, but everytime I set the refresh rate to 50hz (or any other besides 60hz) onder host / display I get an error and WinUAE reverts back to directdraw mode. Seems if I force the HD Radeon driver to 50hz there is no problem using it in direct3D mode. Any work around for this? My display can handle 50hz and 60hz

[Toni Wilen]

Originally Posted by MrX_Cuci

Don't know if this is the right place to post this, but everytime I set the refresh rate to 50hz (or any other besides 60hz) onder host / display I get an error and WinUAE reverts back to directdraw mode. Seems if I force the HD Radeon driver to 50hz there is no problem using it in direct3D mode. Any work around for this? My display can handle 50hz and 60hz

Lets see..

- most likely nothing to do with 2.4.2 betas
- error message not included
- logs not included

[MrX_Cuci]

Ste the Radeon driver settings to default and seems to work now. I have a dmp file though from the crash. Any use for that?

EDIT: error is in the log though
02-659 [0 000x000]: CreateDevice failed, 8876086C S=1 F=0876 C=086C (2156) ()

[Toni Wilen]

Originally Posted by MrX_Cuci

Ste the Radeon driver settings to default and seems to work now. I have a dmp file though from the crash. Any use for that?

EDIT: error is in the log though
02-659 [0 000x000]: CreateDevice failed, 8876086C S=1 F=0876 C=086C (2156) ()

Dump and logs from 2.4.1 in 2.4.2 thread?

Seriously, can you duplicate the crash using latest 2.4.2 beta? Thats the important part.

[kfasheldon]

Hi Toni,

Most confused, Installed last full release and its working fine, just downloaded latest beta to install in a folder, runs but F12 does not bring up menu?

So I have tried copying the folder from Programs(x86) onto desktop , run the latest full release then from the folder on desktop and F12 will not work?

Any ideas, oh if I copy the beta to the installed folder in programs(x86) F12 wont work either ? Confused

[Toni Wilen]

Originally Posted by kfasheldon

Hi Toni,

Most confused, Installed last full release and its working fine, just downloaded latest beta to install in a folder, runs but F12 does not bring up menu?

So I have tried copying the folder from Programs(x86) onto desktop , run the latest full release then from the folder on desktop and F12 will not work?

Any ideas, oh if I copy the beta to the installed folder in programs(x86) F12 wont work either ? Confused

Do you mean F12 does not work even if you don't load any configurations (including configurations/default.uae. DO NOT delete this, keep it safe for debugging purposes it this file causes the problem)?

Which beta introduced the problem?

[Toni Wilen]

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

Beta 6:

- PC raw MFM decoding improved (uaeunp, Amiga/ST/PC multiformat PC images didn't decode properly)
- Interlace flag wasn't set if resolution had "i" flag but refresh rate didn't, caused blank screen in D3D modes.
- Set system time to host time (timer.device/TR_SETSYSTIME) when exiting GUI or unpausing if syncronize clock option is enabled. Only works if at least one directory filesystem is in use. (Shares directory filesystem process to minimize resource usage)
- Interlaced host resolution field matching with emulated interlace rewritten, now simply waits extra field if fields don't match. Can cause small sound glitches if small buffer but this is also much more reliable than old method. (Need tweaking)
- Small non-fastest CPU mode low latency vsync tweaks.
- Ignore CPU writes to DSKDAT. (Useless "DSKDAT: FIFO overflow!" log messages caused by some programs that poke DSKDAT).
- Added -nodirectinput command line parameter that completely disables directinput device enumeration.
- Gayle PCMCIA CF IDE emulation improvements, PCMCIA CF config #2 also supported (PC primary IDE IO addresses)
- GUI position is also saved in fullscreen mode, separate from windowed mode GUI coordinates.
- Some chipset mode on the fly configuration changes also reset RTG internal variables, causing blank screen when returning back to RTG mode. (Very old bug, "SetSwitch() - Picasso96 0x0x0" in log)
- Fullscreen RTG mode refresh rate uses chipset mode refresh rate or rate directly set in Expansions panel. Automatically selects lower available refresh rate if selected rate is unsupported.
- Added option to enable/disable RTG vblank interrupt emulation. Previously it was automatically enabled if Refresh rate option wasn't set to disabled. Moved to separate GUI option because of above new feature and because some games don't like RTG board generated interrupts.
- Direct3D mode RTG OSD only updated when any part of RTG bitmap changed.
- Blank unused displays(s) (opens full screen topmost black window(s)) option added to misc panel.
- Only save minimal CPU context (registers and PC) during native/m68k code switching. Previously it saved lots of unneeded data, including data that can be changed outside of CPU emulator. May also increase performance in some situations. Finally explanation and fix for mysterious copper state corruption.
- CD image mounter: MDS image CD audio tracks didn't play if subchannel data was not included, MDS image data tracks that also included subchannel data returned wrong data.
- Host MMU write protect ROM regions in JIT direct mode because JIT only checks destination address type when generating x86 code for the first time. Badly crashing programs can corrupt loaded ROM image causing repeating red/black screen reset loop. (Another mysterious previously reported problem solved)
- Restructured UAE boot ROM variable locations, ROM part write protected.
- Doubleclicking Input panel Input Source column resets clicked line back to default. (Currently keyboards only)
- Added uae-configuration harddrive attribute modification support:
-- Syntax: uaehfX_Z where X = unit number, Z = attribute name. (for example: "uaehf0_bootpri 10")
-- Attribute names: devicename, volumename, root, bootpri, read-only, filesys, controller.
-- Syntax is write-only. Use plain uaehfX to check current values.
-- Reset required to activate modified settings.

[mark_k]

Were there any changes to keyboard-related code in 2.4.2 beta 6?

I tested beta 6 under Wine 1.5.5, and the Amiga keyboard doesn't work any more. It was fine in b5 and earlier (with the same WinUAE config). I can still press F12 to bring up the settings window, it just seems that no key presses are seen by the emulated Amiga.

[Remember the old "reappearing settings window" bug in Wine? With beta 6 that no longer happens. I'm assuming that's related to the emulated Amiga not seeing key presses, so the Wine bug will probably show up again if/when this issue is fixed.]

I couldn't see any keyboard-related info in the winuae -log output, but I can attach that here if needed.

Edit: I got boot logs from both 2.4.1 and 2.4.2b6. Part of the 2.4.2b6 log:

RawInput enumeration..
RAWINPUT: found 0 devices
Windowsmouse initialization..
Catweasel joymouse initialization..

The corresponding part of the 2.4.1 log:

RawInput enumeration..
RAWINPUT: found 0 devices
DirectInput enumeration.. Keyboards..
I={6F1D2B61-D5A0-11CF-BFC7-444553540000} P={0AB8648A-7735-11D2-8C73-71DF54A96441}
'Wine Keyboard' 'Keyboard' 00000013 [Keyboard]
DirectInput enumeration.. Pointing devices..
I={6F1D2B60-D5A0-11CF-BFC7-444553540000} P={9E573ED8-7734-11D2-8D4A-23903FB6BDF7}
'Wine Mouse' 'Mouse' 00000212 [Mouse]
DirectInput enumeration.. Game controllers..
Windowsmouse initialization..
Catweasel joymouse initialization..

Could the problem be due to this change:
- Added -nodirectinput command line parameter that completely disables directinput device enumeration.

It seems that under Wine at least, beta 6 isn't enumerating DirectInput devices by default. And since rawinput doesn't work under Wine, there's no keyboard.

[Toni Wilen]

Originally Posted by mark_k

Were there any changes to keyboard-related code in 2.4.2 beta 6?

nodirectinput internal variable was accidentally set to true. Will be fixed soon..

[Dr.Venom]

Originally Posted by Toni Wilen

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

Beta 1:

- Always call D3D SetMaximumFrameLatency(1) if vsync mode (any vsync) to reduce latency, previously was only called when low latency no buffer mode used. (SetMaximumFrameLatency only available on Vista and later) Usually display driver control panel can be also used to override this value.

Is this SetMaximumFrameLatency the same thing as "Flip Queue Size" on ATI/AMD and "Max Frames to Render Ahead" on NVidia?

[Dr.Venom]

Originally Posted by Toni Wilen

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

Beta 1:

- Always call D3D SetMaximumFrameLatency(1) if vsync mode (any vsync) to reduce latency, previously was only called when low latency no buffer mode used. (SetMaximumFrameLatency only available on Vista and later) Usually display driver control panel can be also used to override this value.

Originally Posted by Dr.Venom

Is this SetMaximumFrameLatency the same thing as "Flip Queue Size" on ATI/AMD and "Max Frames to Render Ahead" on NVidia?

I'm answering my own question, but with a purpose. I looked this up on MSDN and it seems indeed the same as the "Flip Queue size" on AMD and "Max frames to render ahead" on NVidia.

The issue:
Although the D3D "SetMaximumFrameLatency()" function itself doesn't seem to allow a real setting of 0 frames rendered ahead (setting it to "0" will make it reset to "default"), there are certain utils that do enable a real setting of 0, i.e. really having zero frames rendered ahead. A setting of zero is ideal for emulation, as it will give the absolute lowest possible latency.

For ATI/AMD there's the RadeonPro tool (http://www.radeonpro.info/en-US/ ) with which a real setting of zero for Flip Queue Size is possible, and on NVidia this can be done through the NVidia Control Panel (http://www.tweakguides.com/NVFORCE_6.html ), although it's important to note that a real setting of zero for NVidia cards seems to be disabled in the newer drivers. With older drivers it was apparently possible (see: http://www.overclock.net/t/1263509/a...rames-0-option)

For WinUAE I always have the maximumframelatency / flipqueuesize set to 0 through the radeonpro utility, but the message in the Beta 1 release log triggered me to worry about the fact that WinUAE might infact override this real setting of "0" by setting SetMaximumFrameLatency(1). This is because the call by the RadeonPro utility might come before WinUAE calls its function, effectively overriding the zero latency with a one frame buffer, which would mean a 20ms latency loss :-/ ...

I guess I understand why WinUAE sets it to 1; basically because D3D9ex doesn't allow a -real- setting of "0", but has one prerendered frame as the minimum. (Calling "0" in D3D SetMaximumFrameLatency() is actually reserved for setting FrameLatency to driver "default"...). (No news for Toni I'm sure, but for others: http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx )

I'm really not sure why the D3D SetMaximumFramelatency() function call is limited to at least a value of 1. My best guess is that this is to keep compatibility with Windows Vista / 7 Aero vsynced window design (which always seems to use an extra buffer..)?

Toni, would it be possible to have the SetMaximumFrameLatency(1) not be called when the user has a real setting of "0" set?

I'm not sure how you would detect a real setting of "0", but possibly GetMaximumFrameLatency (http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx ) will report anything sensible when the real value is set to zero?

But if it can't be detected automatically, would it be possible to add a command line option to disable WinUAE calling the SetMaximumFrameLatency(1) option? If I'm right about this, then that would be very useful for ATI/AMD users that have FlipQueueSize set to zero (with RadeonPro utility), where WinuAE might currently override that value.. I'm not sure about NVidia, but possibly it's also useful for NVidia users who are running drivers below version 296.10 and also have set it to a real value of zero (but maybe the NForce setting overwrites the WinUAE call, in which case it would not be a problem)..

[Toni Wilen]

Originally Posted by Dr.Venom

I'm really not sure why the D3D SetMaximumFramelatency() function call is limited to at least a value of 1. My best guess is that this is to keep compatibility with Windows Vista / 7 Aero vsynced window design (which always seems to use an extra buffer..)?

Toni, would it be possible to have the SetMaximumFrameLatency(1) not be called when the user has a real setting of "0" set?

Shouldn't display control panel settings override application settings, including SetMaximumFramelatency() value?

Did you test if setting it to very high value using control panel utility overrides WinUAE's SetMaximumFramelatency(1)?

GetMaximumFrameLatency() is documented to return 1 or higher so I wouldn't trust it either..

EDIT:

I guess calling SetMaximumFramelatency(1) only if GetMaximumFrameLatency() returns value larger than 1 should work fine?

[Dr.Venom]

Originally Posted by Toni Wilen

Shouldn't display control panel settings override application settings, including SetMaximumFramelatency() value?

Hmm.. I'm not sure, but I guess not. Given that a value of "0" in SetMaximumFrameLatency() is reserved to set the frame latency at "Default", which I would guess means "Driver Default" (?), that's probably the only setting where the control panel setting will "override" the SetMaximumFrameLatency?

But I'm really not sure.. MSDN doesn't specify what is meant by "default". It says that it's typically at "3", but it doesn't say that's the default, which leaves open the option that it really is set to some default value, or that it is taking the "default value" that is set by the user in the control panel.. (I wish they would document this stuff somewhat better!)

Did you test if setting it to very high value using control panel utility overrides WinUAE's SetMaximumFramelatency(1)?

I just tested it with a value of "5" (the largest value RadeonPro allows), but this doesn't introduce additional lag. This seems to point that indeed SetMaximumFrameLatency(), for values other than "0", is overriding any config panel (RadeonPro) setting..

GetMaximumFrameLatency() is documented to return 1 or higher so I wouldn't trust it either..

EDIT:

I guess calling SetMaximumFramelatency(1) only if GetMaximumFrameLatency() returns value larger than 1 should work fine?

That would be a perfect solution

Just to be sure, maybe it's good to shortly test with a beta what value is returned by GetMaximumFrameLatency when the FlipQueueSize is set to a real zero render ahead buffer by any tool/config panel? Just to be sure it doesn't return any weird positive value (which would result in getting a false positive with the >1 check..)

[kfasheldon]

Originally Posted by Toni Wilen

Do you mean F12 does not work even if you don't load any configurations (including configurations/default.uae. DO NOT delete this, keep it safe for debugging purposes it this file causes the problem)?

Which beta introduced the problem?

Thanks for reply Toni, sorry it was not 100% report.

Problem fixed now, it would appear that Comodo Internet Security was the cause, odd it does not affect the Amiga Forever versions, nor does it effect latest install version from main site - only the zip only extracted into a directory, seems once you start emulation F12 is prevented from getting sent to the emulator and trapped somehow by Comodo ?. I have install AntiVir and all is well, just as a double check put back Comodo and F12 just does not work with Comodos default settings on Win 7 64bit.

Anyway - looks more the problem with the security software being paranoid rather than WinUAE, keep up great work, cheers Karl

[Toni Wilen]

Originally Posted by kfasheldon

Thanks for reply Toni, sorry it was not 100% report.

Problem fixed now, it would appear that Comodo Internet Security was the cause, odd it does not affect the Amiga Forever versions, nor does it effect latest install version from main site - only the zip only extracted into a directory, seems once you start emulation F12 is prevented from getting sent to the emulator and trapped somehow by Comodo ?. I have install AntiVir and all is well, just as a double check put back Comodo and F12 just does not work with Comodos default settings on Win 7 64bit.

Anyway - looks more the problem with the security software being paranoid rather than WinUAE, keep up great work, cheers Karl

Not the first time keyboard rawinput (combined with winpcap network support) has caused some security programs to block it. AFAIK both are commonly used by malware too..

[Toni Wilen]

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


Beta 7:

- Directory filesystem 64-bit seek (ACTION_CHANGE_FILE_POSITION64) broke in 240b27
- -nodirectinput mode was always enabled. (b6)
- -nodirectinput does not anymore disable mouse/keyboard directinput enumeration if rawinput fails to initialize.
- Syncronize clock enabled and loading new config crashed in some situations (b6)
- Blitter emulation didn't leave correct data in blitter's B data register after linedraw finished, fixes No Way demo by Academy that seems to use wrong minterm that requires correct static value in B data register.
- WASAPI exclusive software volume control support. It seems normal WASAPI volume control does nothing in exclusive mode.
- Added support for unimplemented integer instructions to 68k emulation code generators. Not yet in use. (This is easy part, unimplemented floating point support is very difficult because it requires special FPU stack frame)

**********************

- Experimental memory space rewrite. Now WinUAE reserves address space as much as possible (~1.6G if 64-bit OS, 512M if 32-bit, note that this is only reserved space, actual memory is not yet allocated). Allows more stable on the fly memory size changes. It is not guaranteed that this is safe to use and won't cause side-effects or other bad behavior or loss of performance, please test and report.

**********************

[Toni Wilen]

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

Beta 8:

- 68060 and CPU compatible checkbox ticked: generate unimplemented instruction exceptions instead of emulating instructions that real 68060 don't have. Integer instructions only, 040/060 FPU emulation still supports all 6888x instructions.
- Set FPU FPIAR register (No one shouldn't care, except unimplemented FPU exception handler which isn't supported)
- RTG state restore broke in previous update.
- Save RTG mode palette to statefile (Quite important missing information if dislay mode is 8-bit..)
- More memory space reservation updates.
- "Restart" GUI option improved, shouldn't cause strange errors if new config has 32-bit RAM enabled and old one didn't.
- Savestates with 32-bit RAM configured should now load without need to first load configuration that has same amount (or more) RAM configured.

[Toni Wilen]

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

Beta 9:

- Replaced readpu.c 68020+ special case TST An/PC-rel and CMP #imm,PC-rel variants with proper table68k entries.
- Debugger disassembler decodes illegal instructions if opcode is supported by higher CPU model, shown in parenthesis, note that PC is only incremented by 2 in this situation.
- Debugger W (write to memory) command supports multiple values and strings.
- Slow debugger commands can be aborted by pressing return (console only)
- 64-bit DIVL.L checked div by zero exception before checking if instruction is 68060 compatible.
- Use IOCTL_STORAGE_QUERY_PROPERTY to query optical drive vendor/product/version information instead of SCSI inquiry.
- "Take screenshots before filtering" supported in RTG modes, takes screenshot from emulated VRAM buffer. 8-bit png if 8-bit RTG mode, 24-bit png if >8 bit RTG mode. Does not capture mouse if mouse is emulated hardware sprite.
- "Capture before filtering" recording option supported in RTG modes.
- D3D D3DERR_DEVICELOST handling improved.
- Inhibit Windows error dialogs completely. On some systems missing harddrive still opened annoying Windows no disk error dialog(s).
- Improved extended ROM statefile support.
- Save ROM overlay state to statefile separately from CIA OVL pin state, fixes loading of statefiles if current configuration has CIA overlay support but state configuration does not. (Gayle based chipset or CD32)
- Misc statefile load compatibility improvements when current config is very different compared to statefile's configuration.
- DMA debugger 'c' = copper wanted this cycle but it wasn't available
- Extremely rare BPLxDAT non-DMA modifications emulated while bitplane DMA is disabled, not perfect but at least screen isn't completely blank anymore.
- Ancient Superfrog copper hack removed, it isn't needed anymore. (EyeQlazer/Scoopex is nearly correct now)

[1time]

Toni.. .. Thanks!

[Mclane]

Thanks for the update, as always, appreciated!

[pmc]

Originally Posted by Toni Wilen

- Ancient Superfrog copper hack removed, it isn't needed anymore. (EyeQlazer/Scoopex is nearly correct now)

The way this is written it's like you're saying that you removed an old copper hack and now EyeQLazer *nearly* works fine in the latest beta WinUAE.

But... I just tested and EyeQLazer already *does* work fine in the latest stable WinUAE release (2.4.1)

Or did you know that already and I just misunderstood what you were getting at in the quoted text?

[Toni Wilen]

Originally Posted by pmc

The way this is written it's like you're saying that you removed an old copper hack and now EyeQLazer *nearly* works fine in the latest beta WinUAE.

But... I just tested and EyeQLazer already *does* work fine in the latest stable WinUAE release (2.4.1)

Or did you know that already and I just misunderstood what you were getting at in the quoted text?

It does not work correctly (Screenshot in Pouet is also wrong) 242b9 is _almost_ correct.

[pmc]

So in short, yes I did misunderstand you.

OK, thanks for confirming.

[Toni Wilen]

Originally Posted by Mclane

Thanks for the update, as always, appreciated!

Thanks. This is getting a bit more interesting again, there are chipset updates in this beta series! Chipset emulation missing features are getting too rare

It does not work correctly (Screenshot in Pouet is also wrong) 242b9 is _almost_ correct.

http://www.winuae.net/files/b/winuae.zip should be exactly right, if someone wants to fix the screenshot

Not yet sure if this is correct fix, need some logic analyzer testing but didn't bother with it yet...

[Toni Wilen]

winuae.zip updated. Now Blerkenwiegel/Scoopex (another 64byte intro, this is really weird one) works 100%. It pokes both BPL0DAT and BPL1DAT using CPU in short loop.

Only chipset emulation needed few tiny updates, nothing related to timing. I am quite proud, it means emulator timing must be really really good because even single cycle error would break this intro

(Even Sequential/Andromeda still works without extra garbage)

[pmc]

WinUAE just keeps getting more and more accurate compared to the real hardware. Excellent work Toni! Thank you!

[Kettenhund]

There's a bug with the game "Targhan". The music on the titlescreen gets kind of out of sync and then the game reboots. I tried different configurations.

[Mclane]

"Quite proud"?

Toni, you should be sitting there with a smile that will never come off your face, Winuae is THAT good...

Cheers.

[Toni Wilen]

Originally Posted by Kettenhund

There's a bug with the game "Targhan". The music on the titlescreen gets kind of out of sync and then the game reboots. I tried different configurations.

Check first post. Which exact version of game? There appears to be multiple ones. (crack? original?) What was last working winuae beta? Or did it ever "work"?

EDIT: at least uncracked version will reboot soon after title screen because of failed protection check.

[Kettenhund]

yup, i'm talking about the uncracked version...sorry, but i don't know anymore on which version it worked...didn't start the game for a long time...

[Toni Wilen]

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

Beta 10:

- BPLxDAT CPU/Copper writes are now accurately emulated. (Blerkenwiegel/Scoopex)
- COPJMPx triggered second cycle is special, does not need to be free but if it is free, it is allocated for copper. (EyeQlazer/Scoopex is now 100% correct)
- Emulate copper waiting + CPU write to COPJMPx slightly different copper cycle usage.
- Fixed chipset emulation infinite loop if program crashed and wrote totally bogus values to programmable display refresh rate registers.
- Both mouse and joystick enabled in same port: moving joystick does not cause mouse big cursor jumps anymore.
- Automatic center option incorrectly set display limits to autoscale limits (black borders).
- "Release" key qualifier support. When [R] qualifier is selected, qualifier key is released before sending mapped keycode and then immediately pressed again. Qualifier selection GUI is currently ugly.
- Modified Input Qualifier support, now non-matched qualifier combinations (one or more qualifiers pressed but no match in any 8 slots) always trigger non-qualifier input target(s), previously nothing was triggered.
- Added "Wait for Blitter" GUI option, when enabled, CPU is paused if blitter is active and CPU attempted to modify blitter registers. Previously was always enabled if fastest possible CPU (and still is), now it can be manually enabled in other modes, can be useful when running 68020/AGA programs that run badly in non-ce modes but also have some display problems in ce modes. (because of not accurate enough CPU speed)
- Fixed flickering graphics corruption in some programs (for example Disposable Hero), also could have caused reduced performance. (b1 display limit feature)

[pmc]

Legendary update. Once again Toni, thanks.

[Mclane]

Yup, just when you think Toni has done it all he comes up with an even better version.

True genius...

[AVH_2009]

If you like this kind of development, why you dont spend some money for him?
I have done it some days ago. Follow me!
Thanks Toni for this great work!

[Dr.Venom]

Originally Posted by Toni Wilen

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

Beta 10:

- BPLxDAT CPU/Copper writes are now accurately emulated. (Blerkenwiegel/Scoopex)
- COPJMPx triggered second cycle is special, does not need to be free but if it is free, it is allocated for copper. (EyeQlazer/Scoopex is now 100% correct)
- Emulate copper waiting + CPU write to COPJMPx slightly different copper cycle usage.
- Fixed chipset emulation infinite loop if program crashed and wrote totally bogus values to programmable display refresh rate registers.
- Both mouse and joystick enabled in same port: moving joystick does not cause mouse big cursor jumps anymore.
- Automatic center option incorrectly set display limits to autoscale limits (black borders).
- "Release" key qualifier support. When [R] qualifier is selected, qualifier key is released before sending mapped keycode and then immediately pressed again. Qualifier selection GUI is currently ugly.
- Modified Input Qualifier support, now non-matched qualifier combinations (one or more qualifiers pressed but no match in any 8 slots) always trigger non-qualifier input target(s), previously nothing was triggered.
- Added "Wait for Blitter" GUI option, when enabled, CPU is paused if blitter is active and CPU attempted to modify blitter registers. Previously was always enabled if fastest possible CPU (and still is), now it can be manually enabled in other modes, can be useful when running 68020/AGA programs that run badly in non-ce modes but also have some display problems in ce modes. (because of not accurate enough CPU speed)
- Fixed flickering graphics corruption in some programs (for example Disposable Hero), also could have caused reduced performance. (b1 display limit feature)

Thanks for the continuing improvements

Small suggestion is to make the GUI "wait for blitter" mouseover message a bit less "technical". Now it states "Pauses the CPU if blitter is active and CPU attempted to modify blitter registers", which doesn't tell a whole lot from a user standpoint. I understand what it does because of your explanation above in the B10 release info, so maybe it's an idea to use this quote from it: "Wait for blitter: can be useful when running 68020/AGA programs that run badly in non-ce modes but also have some display problems in ce modes.". Or something else ofcourse that helps understand it from a user perpective.. (The other mouseovers in the chipset panel are also "non-technical", so it would also benefit the consistency).

A question about the "wait for blitter" option, are there any negative side-effects of having this option always enabled?

[Leandro Jardim]

Originally Posted by Dr.Venom

A question about the "wait for blitter" option, are there any negative side-effects of having this option always enabled?

This a very good question...

To this, I add:

Excuse my ignorance, but in a real Amiga, the blitter is not always synchronized, that is it does not always stop with the CPU access? With this option checked WinUAE can be more realistic but slower?

Sorry if my thoughts look stupid, I am only a very curious person...

[Toni Wilen]

Small suggestion is to make the GUI

I am not even sure what it should do.. Will improve it later..

A question about the "wait for blitter" option, are there any negative side-effects of having this option always enabled?

Yes, it won't help at all in 68000 CE, it would only make compatibility worse.. I think I'll make it impossible to have it enabled in this mode.

It again depends what you want as usual

- fastest possible: immediate blitter
- program that don't like too fast blitter (for example it assumes blit taking some time): no immediate blitter, waiting blitter won't break anything and possibly helps in some situations.

I'd enable it always when using 68020+ modes. (If immediate blitter not enabled).

I'll probably make following changes to quickstart settings:

- 68000 CE: does nothing, always ignored.
- Any approximate CPU mode or 68020+CE: enabled, only pause CPU if blitter would steal all cpu cycles. (no idle cycles in blitter cycle diagram + blitter nasty). Without this Hostages would break with usual insta-kill behavior
- Fastest possible CPU: enabled, any kind of blit.

Excuse my ignorance, but in a real Amiga, the blitter is not always synchronized, that is it does not always stop with the CPU access? With this option checked WinUAE can be more realistic but slower?

Yes, blitter does not always stop the CPU.

This option only protects against programs that don't wait for the blitter (Usually happens if old program made for 68000 runs on 68020), nothing else.

Previously only way to prevent this was to enable immediate blitter but it would most likely also make the program run too fast or have tearing or other graphics glitches. (Of course this does not guarantee it but it should at least reduce it)

Also helps with some AGA game graphics glitches, even in CE mode, because 68020 emulation is not accurate. (for example Last Ninja 3 CD32)

68000 CE is practically perfect, no need for these kinds of hacks. (and there is always at least 3 free cycles after blitter has been started due to way blitter works and there is guranteed to be some demo that only works if next CPU instruction fits in that 3 cycle space..)