WinUAE 2.6.0 beta series

[Toni Wilen]

Confirmed, it leaks texture resources when display is regenerated (resize, mode changes etc..)

EDIT: Today's winuae.zip should fix it.

[mark_k]

I can still trigger a crash in the latest winuae.exe by setting Workbench to an A2024 mode and resizing the window several times.

[msayed1977]

While I was running Battle Chess with beta 6, suddenly my desktop appeared without exiting the emulator. The resolution of the desktop was my native desktop resolution, but the mouse pointer could not exceed the emulator resolution until I pressed ALT-F4 to exit the emulator.
I do not know whether it is a new bug or not, but it is the first time to happen with me. I did not change my configs.
Please investigate.

Originally Posted by dlfrsilver

I have encountered the same problem , i post a screen and files tonight when back from work.

Here is my configs again, Toni.

[Leandro Jardim]

Hi, Toni;

"Terrific" the ultimate updates, hein?!

But now; I cant connect with A2065 anymore. Bellow are the files for WinUAE and Miami DX.

I cant wait for to see when the "Automatic scaling" will work for my 16:9 lcd without it to stretch the picture when I drag screens down...

[Toni Wilen]

Originally Posted by Leandro Jardim

I cant connect with A2065 anymore

Does http://www.winuae.net/files/b/winuae.zip work again?

btw, there has to be a bug in a2065 ethernet chip documentation (79c90)..

Chip has 3 config bits, INIT, STRT and STOP.

INIT = initialize chip, STOP must be set before setting INIT, STOP is automatically cleared.
STRT = start chip, STOP must be set before setting STRT, STOP is automatically cleared.
STOP = same as chip reset. (Clears INIT and STRT)

I think you'll see the problem. It is impossible to set STRT after setting INIT without reseting the chip (=INIT required again..). Other part documentation says you can also set both INIT and STRT at the same time.

NetBSD 1.0 driver set INIT first, then STOP and then STRT. Does not match documentation. This shouldn't work..

A2065 SANA2 driver sets INIT and then STRT. Again does not match documentation.. Also shouldn't work..

Because I don't have A2065, I can't test this. Now STRT is allowed if either INIT or STOP bit is set, also setting STOP won't reset initialization. I guess "must be set" is not actually required

I cant wait for to see when the "Automatic scaling" will work for my 16:9 lcd without it to stretch the picture when I drag screens down...

Unfortunately it can never work. It is impossible to detect between "it is dragging, don't recenter" or "screen was moved down, recenter". It is same thing!

It can work in some situations with some ugly extra logic but it can never work perfectly.

[thomas]

I think you'll see the problem. It is impossible to set STRT after setting INIT without reseting the chip (=INIT required again..). Other part documentation says you can also set both INIT and STRT at the same time.

Well, the part of the docs you quoted does not say that INIT is required after STOP. It says that you always set STOP and then either INIT or STRT.

Judging just from this piece of documentation I would say the right sequence is STOP -> INIT -> STOP -> STRT.

[mark_k]

Originally Posted by Toni Wilen

btw, there has to be a bug in a2065 ethernet chip documentation (79c90)..

It seems the A2065 uses the earlier AM7990 chip, not the AM79C90. See the board pic at amiga-hardware.com.

There seem to be quite a few differences between the chips. Appendix B in the AM79C90 datasheet describes them. You can download the AM7990 datasheet from datasheetarchive.com.

[mark_k]

Originally Posted by Toni Wilen

Does http://www.winuae.net/files/b/winuae.zip work again?

On testing the latest winuae.exe under Wine, Wine exits with this message:
wine: Call from 0x7bc4d010 to unimplemented function KERNEL32.dll.GetVolumeInformationByHandleW, aborting
wine: Unimplemented function KERNEL32.dll.GetVolumeInformationByHandleW called at address 0x7bc4d010 (thread 0009), starting debugger...

Looking at the MSDN function documentation GetVolumeInformationByHandleW is only supported in Windows Vista and later. So you might want to not call it when running under XP.

Would you be able to upload a WinUAE build which always uses GetVolumeInformationByHandleW though, so I can file a bug report at winehq.org to get at least a stub implemented in Wine? (I'll give the URL of that build in the bug report.)

[Toni Wilen]

Originally Posted by thomas

Well, the part of the docs you quoted does not say that INIT is required after STOP. It says that you always set STOP and then either INIT or STRT.

Yes but this chip or documentation has strange definition of reset. STOP bit is supposed to do same as hardware reset = initialization is assumed to be lost. At least documentation says "internal logic state is reset".

Originally Posted by mark_k

There seem to be quite a few differences between the chips. Appendix B in the AM79C90 datasheet describes them.

I have it already, this behavior is not documented.

Originally Posted by mark_k

On testing the latest winuae.exe under Wine, Wine exits with this message:
wine: Call from 0x7bc4d010 to unimplemented function KERNEL32.dll.GetVolumeInformationByHandleW, aborting
wine: Unimplemented function KERNEL32.dll.GetVolumeInformationByHandleW called at address 0x7bc4d010 (thread 0009), starting debugger...

Looking at the MSDN function documentation GetVolumeInformationByHandleW is only supported in Windows Vista and later. So you might want to not call it when running under XP.

Would you be able to upload a WinUAE build which always uses GetVolumeInformationByHandleW though, so I can file a bug report at winehq.org to get at least a stub implemented in Wine? (I'll give the URL of that build in the bug report.)

This was the FAT check which requires GetVolumeInformationByHandleW(), I missed it being Vista+ only.

winuae.zip now use GetProcAddress() to get&check if GetVolumeInformationByHandleW() exists. Works on XP again but FAT timestamp stuff only works under Vista or later.

winuae_GetVolumeInformationByHandleW.zip is previous winuae.zip renamed. (Note that at least one directory filesystem needs to be mounted before GetVolumeInformationByHandleW() is called).

[mark_k]

Originally Posted by Toni Wilen

This was the FAT check which requires GetVolumeInformationByHandleW(), I missed it being Vista+ only.

winuae.zip now use GetProcAddress() to get&check if GetVolumeInformationByHandleW() exists. Works on XP again but FAT timestamp stuff only works under Vista or later.

Could the GetVolumeInformation function be used as an alternative under XP? It seems similar, except instead of a file handle you pass a root directory path, e.g. "D:\".

[Toni Wilen]

Originally Posted by mark_k

Could the GetVolumeInformation function be used as an alternative under XP? It seems similar, except instead of a file handle you pass a root directory path, e.g. "D:\".

Used path may not be complate path in all situations and I am not going to waste time with XP unless feature really needs to be XP compatible (This one does not).

[Leandro Jardim]

It works again, thanks Toni!

[mark_k]

Originally Posted by Toni Wilen

Used path may not be complate path in all situations and I am not going to waste time with XP unless feature really needs to be XP compatible (This one does not).

There is some example XP-compatible code on the Microsoft site to get a full path name from a file handle. (There's a Vista+ function GetFinalPathNameByHandle which does that directly, of course you don't need that since you can use GetVolumeInformationByHandleW on Vista.) There's an alternative XP-compatible method to get the full path from a file handle shown here. Both methods look pretty hairy, I'm not sure which one is worse!

[Toni Wilen]

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

Beta 7:

- In JIT mode format 2 stack frames had wrong address field contents, this also broke 68060 unimplemented integer instruction exceptions (64-bit variants of DIVL and MULL).
- GUI boot priority/autoboot/automount handling fixed and simplified.
- 68030 "cycle-exact" mode used 020 instruction cache emulation code. No guarantees that this fixes all 68030 "CE" problems.
- D3D texture memory leak fixed (b6)
- A2024/Graffiti extra display buffer memory leak fixed.
- 1/50s file modification date also supported on FAT volumes. Returns FAT file creation date (which has 10ms resolution, file modification date only has 2s resolution) if it is inside file modifcation date's 2s resolution. (Currently Vista or newer only)
- 68040+ "no FPU" exception stack frame still had incorrect data.
- Disable 68040/060 CPU "More compatible" option if JIT is enabled. JIT active and not emulating unimplemented instructions isn't safe because JIT and normal emulation does not always agree which instructions are supported.
- A2065 emulation tweak, Ethernet chip documentation STOP/STRT/INIT bit documentation is not very clear.

[dlfrsilver]

Toni, just a question : i use b7, and came two times with a HALT1 message. What is it, and how to unlock this state ?

[Toni Wilen]

HALT = CPU double faulted and stopped. Reset releases it. (Perhaps any key could also release halted state to make it less confusing)

Previously it caused immediate reset, now it stops just like real CPU would stop.

[dlfrsilver]

Ok, thank you for the hint

[Skylight]

After some years without WinUAE and WHDLoad i decided to "play" with it again to fight boredom while i'm in Beijing again.

And there seems to be an annoying "bug" in WinUAE introduced in WinUAE 2.5.0.0 and still present in 2.6.0.0b7.

There are some serious graphic glitches when running the WHDLoad install of Turrican II.
See the attached screenshot.
It looks like the whole viewport is flickering.
But to show this i would have to upload a video.

With WinUAE 2.4.x everything still works fine. So something has changed with 2.5.x.

Maybe someone can verify this.

[Toni Wilen]

Most likely it is not a bug but fastest possible mode becoming faster (do you use fastest possible cpu mode?)

(and wrong thread too )

[Skylight]

When running my own HDF install or ClassicWB etc. then the CPU is of course set to fastest possible.

But i did test now with 2.6.0.0b7 and cycle-exact +500% and there are still some graphic glitches but not as much as before.

And this happens only with Turrican II.

Maybe some changes in the Turrican2.slave can help too.
I did already talk to Bert about the Turrican.slave since the slave (or the old code) stops the Rainbow Arts intro too early when the CPU is too fast and so u can't see the "Manowar" title picture. And something is missing without "Welcome to Turrican hahahahaha".

If i would have the source codes i could do some necessary changes too in my (limited) free time.
But tomorrow i'm going back to Munich, then to VW in Mosel/Zwickau, then to BMW/MINI Oxford and then back to Beijing.

btw .. since i tested it with 2.6.0.0b7 i felt i was right here

EDIT: even with 68020 and cycle-exact +0% u get alot of glitches!