WinUAE 3.6.1 beta series

[Toni Wilen]

Originally Posted by AMIGASYSTEM

Nothing in particular I just added WASAPI, i enclose file config

It still does not really explain if 3.6.1 had anything to do with it

btw, you may get some improvements with multithreaded RTG if you normally get sound glitches when continuous large screen updates are happening at the same time. (But probably only if you have fast CPU with large memory bandwidth)

[AMIGASYSTEM]

Yes Toni was just a case,I tried the same configuration with older versions of WinUAE it's the sound is always perfect. So the miracle is in the right configuration of me set

[White]

Hi Toni,
Thanks for the latest beta 5 and 6
If it can be useful I attach my configuration and 2 dmp
sometimes winuae beta 6 and crashed and stopped working for a restart of the configuration.
I wanted to ask if it could be a corrupt memory problem.
Thanks and sorry for the report I hope it is useful.
Good day.

[Toni Wilen]

Originally Posted by White

Hi Toni,
Thanks for the latest beta 5 and 6
If it can be useful I attach my configuration and 2 dmp
sometimes winuae beta 6 and crashed and stopped working for a restart of the configuration.
I wanted to ask if it could be a corrupt memory problem.
Thanks and sorry for the report I hope it is useful.
Good day.

This is same as previously, so my guess was wrong and cause is something else..

Does it always happen during restart or after restart and GUI is again open?

EDIT: A2065 and NE2000 didn't close ethernet connection (slirp/pcap) when restart was pressed and then any incoming packet caused crash because A2065 board was freed.

winuae.7z should fix it.

[White]

Toni, thank you for the explanation
I understand that it is not 'part of the development of winUAE, but this type of error and only part of the hardware emulated?
Or "cURL" could create this type of error.
And bring this kind of problem?
If the question is not right.
I apologize.
Thanks again.

[HanSolo]

When I choose in "advanced uae expansion board" option "New UAE (128k ,rom, indirect) from menu, WinUAE becomes very unstable and crash very often. This board type is required for "Multithreaded" option to work, so I decided to test it and got crash wherever multithreaded option is checked or not. I using current beta 6, nvidia gtx 1060, nothing special in my configuration 060 blizzard expansion + 128mb ram on this card + 512mb uae rtg card , amiga os 3.9 bb2

[Toni Wilen]

Originally Posted by HanSolo

When I choose in "advanced uae expansion board" option "New UAE (128k ,rom, indirect) from meny, WinUAE becomes very unstable and crash very often. This board type is required for "Multithreaded" option to work, so I decided to test it and got crash wherever multithreaded option is checked or not.

"Not enough information" and sounds like this isn't really 3.6 or 3.6.1 specific? (What multithreaded option?)

[HanSolo]

In "RTG Board" section there is "multithreaded" option to check.

[mark_k]

Originally Posted by Toni Wilen

I checked hardfiles I have, some of them have $80, some $40 in FSHD block. Probably hdtoolbox version difference.

Or maybe some other partitioning tool? devices/hardblocks.i says "... this proposal tries to be forward-looking by making the block size explicit, and by using only the first 256 bytes for all blocks but the LoadSeg data."

So Commodore's HDToolBox probably (I didn't bother actually checking different versions) always puts $40 in fhb_SummedLongs. And a few other HDFs created with other tools that I checked also behave like that.

[Toni Wilen]

Originally Posted by mark_k

Or maybe some other partitioning tool? devices/hardblocks.i says "... this proposal tries to be forward-looking by making the block size explicit, and by using only the first 256 bytes for all blocks but the LoadSeg data."

So Commodore's HDToolBox probably (I didn't bother actually checking different versions) always puts $40 in fhb_SummedLongs. And a few other HDFs created with other tools that I checked also behave like that.

I am quite sure I have always used various versions of hdtoolbox only.

Originally Posted by HanSolo

In "RTG Board" section there is "multithreaded" option to check.

It has nothing to do with boot ROM type. Also, as I said, not enough information.

Originally Posted by White

Toni, thank you for the explanation
I understand that it is not 'part of the development of winUAE, but this type of error and only part of the hardware emulated?
Or "cURL" could create this type of error.
And bring this kind of problem?
If the question is not right.
I apologize.
Thanks again.

If hardware network card was active and was listening for packets, it was still listening for packets even after restart was pressed. Which can and will cause issues..

[White]

Hi Toni,
thanks for the answer and for your help to better understand this problem.
At the moment cURL seems to be fixed by the author for streaming everything seems to be fine.
I'll do more tests tonight.
Thanks as always for your work.
And sorry for my questions.
Thank you

[DamienD]

Originally Posted by Toni Wilen

http://www.winuae.net/files/b/winuae_3610b6.7z
http://www.winuae.net/files/b/winuae64_3610b6.7z

Beta 6: (Almost there..)

- Task bar icon -> close window (possibly also other "external" close methods) didn't always work in D3D11 fullscreen mode.
- Virtual RDB non-512 byte block size support. Last update also broke it if filesystem field was empty.

Retest D3D11 mode changes etc again, thanks.

Weird, my fresh "Classic WB 3.1 Lite" .HDF no longer works in this beta...

Logs attached.

Edit: I can see what's happening, when adding in my "System.hdf" (or any .HDF) the boot priority is set as "-128" by default where previously it was "0"...



If I change to zero then all good but surely I don't need to do this every time I add in a .HDF?

Edit #2: seems this behaviour started in b5; all good in b4.

[Toni Wilen]

That was close, you managed to edit it and fix the original "it does not work" report before it was too late

I fixed obviously wrong variable (priority vs bootpriority) and apparently it was originally (many, many years ago..) supposed to be -128 (no boot) but because it was wrong variable, actual boot priority default become 0. And of course I didn't bother to test it too much because it was so obvious and then forgot about it as usual

[DamienD]

Originally Posted by Toni Wilen

That was close, you managed to edit it and fix the original "it does not work" report before it was too late

All required information / logs were there to begin with

My edits were further investigation i.e. which beta it first occurred with and a screenshot to help make it easier for you to understand the issue (not that you wouldn't quickly figure it out anyway)

[White]

Hi Toni,
With the beta x64 6 no error occurs anymore.
cURL and YT.rexx work perfectly in the new beta version I tested.
Use ethernet.device as a network card, with os 4.1
With this option selected "unimplemented CPU emu" everything works.
Not selecting the program causes crash, I hope it is useful.
Everything works, thanks again.
I leave the configuration file if it can be useful
Thanks again for your work.

[Toni Wilen]

Originally Posted by White

Hi Toni,
With the beta x64 6 no error occurs anymore.
cURL and YT.rexx work perfectly in the new beta version I tested.
Use ethernet.device as a network card, with os 4.1
With this option selected "unimplemented CPU emu" everything works.
Not selecting the program causes crash, I hope it is useful.
Everything works, thanks again.
I leave the configuration file if it can be useful
Thanks again for your work.

This makes no sense because 68k is completely stopped when OS4 is running. Sounds more like you did other modifications or it is simply random.

And always describe "crash". (or it becomes useless "it does not work" bug report)

[White]

Hi Toni,
thanks and sorry, in the future I always attach the crash logs.
Excuse me and thank you again for your explanations.

Originally Posted by AMIGASYSTEM

Nothing in particular I just added WASAPI, i enclose file config

Interestingly, I get all kinds of hiccups and sound glitches, as well as sound timing issues, when using WASAPI (and always have), but it's perfect when using DSOUND. I chalked it up to something system specific to my PC like my sound driver not playing nice. I wasn't really concerned about it, but it sounds like others have varying results... Is there a specific log that would show something like that? I'd be happy to set a test case and generate one if so.

[DamienD]

Originally Posted by Khenemet_Heru

Interestingly, I get all kinds of hiccups and sound glitches, as well as sound timing issues, when using WASAPI (and always have), but it's perfect when using DSOUND.

Same here but doesn't bother me as DSOUND works perfectly on my laptop / setup

[Toni Wilen]

I haven't used direct sound for ages. WASAPI is perfect.

Config and log (boot to whatever that has glitches, let it have glitches for 10 seconds or more, quit). As usual.