WinUAE 2.5.0 Beta series (Was 2.4.2)

[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..)