WinUAE 2.7.0 beta series

[huepper]

Hmmm, somethings wrong with "processor slot fast".

Try to use 128MB processor slot fast.
I add hdd-folder, folder for emergency-boot and for amigaos3.9 and try to boot up.
Emulation stops with a HALT1 in statusbar.

When i set processors slot fast to none and z3 to e.g. 128 mb it will work.

I think the problem I had also with an older beta version , but I have not noticed it.
With "motherboard fast" there is not a problem.

Can you or anyone confirm that?

(OS3.9 installation is running )

[Toni Wilen]

Originally Posted by huepper

Hmmm, somethings wrong with "processor slot fast".

Try to use 128MB processor slot fast.

Do not set it to 128M, it is technically invalid and KS ROM ram detection code overruns if there is any Z3 board that looks like RAM.. It is only safe without Z3 boards. (I guess this can be worked around by moving Z3 boards but it probably introduced other issues)

(Why does everyone always sets any kind of slider to max value and never testing values that would match real hardware..)

[huepper]

Originally Posted by Toni Wilen

Do not set it to 128M, it is technically invalid and KS ROM ram detection code overruns if there is any Z3 board that looks like RAM.. It is only safe without Z3 boards. (I guess this can be worked around by moving Z3 boards but it probably introduced other issues)

(Why does everyone always sets any kind of slider to max value and never testing values that would match real hardware..)

Thanks, with max. 64 MB it works, also lower settings.
Good to know that.

[huepper]

Ok here we are again.
OS3.9 ist installed, clean and without boingbags.

Running OS3.9 with active cl-emulation in chipset mode (without drivers installed, i got the problem mentioned above.
Running OS3.9 with installed drivers (CGFXv4) but in PAL Mode (Chipset) i got the same thing mentioned above.

Switching from chipset to cgfx-mode in workbench, als problems gone away.

To boot and install the drivers i got only a chance if i set cpu idle to the right side, cpu is at 185% and up but it works more or less.

EDIT: Should I test with Picasso96?

[huepper]

I found the solution to the problem.
In expansions tab i have to set the "refresh rate" to any other than chipset ...

So, it's no fault of WinUAE, excuse me please.

[Toni Wilen]

Originally Posted by huepper

I found the solution to the problem.
In expansions tab i have to set the "refresh rate" to any other than chipset ...

So, it's no fault of WinUAE, excuse me please.

It shouldn't cause that kind of slowdowns. Please attach your config file that has the problem, make sure problem still is there if you remove all harddrives and boot to "wb hand" screen.

[huepper]

Here are the config files.

A4000 - chipset.uae

HDD installed + CGFX4, Refresh Rate set to "chipset".
Start with the problem, once the driver is loaded, the problem is gone.

A4000 - chipset wo hdd.uae

Same as above but without hdd installed, Refresh Rate set to "chipset", so it boots to the "wb hand" screen.
However, the problem persists.

In all cases solve the problem itself, if I set refreshrate to e.g. default or e.g. 50Hz or all other.

[Ratte]

SuperPlus seems to be broken.
Compared to V2.5.0 the first two pixels are black.
(Same config)

Regarding SlotMem ... the OS is scanning the memarea up to $1000.0000
Some documents are talking about ZIII-config space from $1000.0000 up to $8000.0000.
But thats wrong, real hardware ist using $4000.0000 - $8000.0000 for ZIII.
$1000.0000 - $4000.0000 is reserved !!!

TripleA-docs uses $1000.0000 - $..... for 16MB chipmem with overlay to $00xx.xxxx and extra romspace and more....

Using the reserved area could break the os memdetection.

[Toni Wilen]

Originally Posted by Ratte

SuperPlus seems to be broken.
Compared to V2.5.0 the first two pixels are black.
(Same config)

Beta threads are only for reporting bugs introduced between last official and beta. So your task is to confirm it happened after 2.6.1

EDIT: config file and winuaelog.txt is of course also needed.

Regarding SlotMem ... the OS is scanning the memarea up to $1000.0000
Some documents are talking about ZIII-config space from $1000.0000 up to $8000.0000.
But thats wrong, real hardware ist using $4000.0000 - $8000.0000 for ZIII.
$1000.0000 - $4000.0000 is reserved !!!

Of course I know that! There are few reasons for this hack:
- It is JIT direct friendly. You don't want to require 1.5G of host memory address space just to allow any Z3 expansion. (JIT requires linear address space, near 1G unusable gap would be huge waste)
- It is JIT friendly, type of address region must be known before emulation starts.
- Much more space for Z3 expansions, huge Z3 RAM and huge RTG RAM possible.
- It would still break if you add $08000000 expansion that is larger than start of official Z3 I don't care about reserved in expanded configurations.

I only pointed out that always test something that commonly exists in real world first before going up to eleven.

[Toni Wilen]

Originally Posted by huepper

Same as above but without hdd installed, Refresh Rate set to "chipset", so it boots to the "wb hand" screen.
However, the problem persists.

http://www.winuae.net/files/b/winuae.zip should fix it. (board vblank handler did something that should be only done when board was active if refresh was chipset and hardware board emulation was enabled and it was inactive)

[huepper]

Originally Posted by Toni Wilen

http://www.winuae.net/files/b/winuae.zip should fix it. (board vblank handler did something that should be only done when board was active if refresh was chipset and hardware board emulation was enabled and it was inactive)

Thanks Toni, this one works.
Time to play around with some other features.

[Ratte]

Originally Posted by Toni Wilen

Beta threads are only for reporting bugs introduced between last official and beta. So your task is to confirm it happened after 2.6.1

EDIT: config file and winuaelog.txt is of course also needed.

Sorry, I can´t do that.



I´ve located the change between 2.5.1 and 2.6.0.

[Toni Wilen]

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

Beta 15:

- Removing directory harddrives on the fly crashed in some situations.
- Interlace with black lines ("fields+") didn't always work correctly.
- Only allow GUI mininize button if emulation has not yet been started, minimizing GUI when emulation window is open only causes problems..
- Copper debugger (od) shows when blit waiting WAIT ends and also stores copper instruction words when copper fetched them, shows '!' if words have changed since copper fetched them. (Previously it was possible to see copper list in state that makes no sense if program modified it after copper executed it)
- Add 16M to Z3 start address if Processor slot RAM is set to 128M, prevents KS RAM detection to confuse Z3 board as being part of Processor Slot RAM.
- Cirrus Logic graphics board enabled but inactive and refresh set to Chipset slowed down emulation.
- Sprite stuck in non-DMA mode was not correctly restored from statefile. (Has never worked previously)
- Adjusted programmed refresh rate blanking start and end position calculations.

[huepper]

Thanks for the new version.
I test it and think, all is ok.

But ... i changed processor slot fast to 128 mb, this is the only fast ram activated.
I set RTG Graphics card to "none" ... all is ok.
I set RTG Graphics card to "UAE Zorro II" ... all is ok.
I set RTG Graphics card to "UAE Zorro III" ... HALT1 in status bar
I set RTG Graphics card to "CL Emulation ZII" ... all is ok. (tested all gfx cards)
I set RTG Graphics card to "CL Emulation ZIII" (without PicassoIV) ... HALT1 in status bar
I set RTG Graphics card to "PicassoIV ZIII" ... fast permanently reset

Now it gets crazy ... if I delete the HDD , then it works , no matter what graphics card.

EDIT: I have always emulation is stopped and restarted.

[mark_k]

Something odd I noticed testing under Wine (on Linux with Nvidia graphics driver). Not sure whether this is relevant as far as WinUAE is concerned but thought I may as well mention it.

Cirrus RTG emulation: Seems much faster in DirectDraw mode than D3D.
In D3D mode, the larger the display mode (or rather, emulation window size), the higher the CPU% and lower the FPS indicator values are.
In DirectDraw mode, higher resolutions don't cause high CPU%/low FPS. Also, in DD mode if you manually set the window size to larger than the current display mode, the unused part isn't blanked immediately. It does seem to be blanked if you (e.g.) open the settings window and move it around over the main window.

Native modes: In contrast, native chipset modes seem generally faster in D3D than DirectDraw.
In DirectDraw mode, the larger the emulation window, the higher the CPU% and lower the FPS indicator values are. (This is with null filter, no scaling.) In D3D mode having a large emulation window size doesn't seem to affect CPU% or FPS.

[Toni Wilen]

Originally Posted by mark_k

Something odd I noticed testing under Wine (on Linux with Nvidia graphics driver). Not sure whether this is relevant as far as WinUAE is concerned but thought I may as well mention it.

"Problem" is most likely CL emulation code that (most likely because it is also generic VGA emulation and VGA is stupidly complex, not just quite simple linear SVGA+ mode emulation) has to know which memory addresses have been modified by the host emulation and this isn't very optimal and causes much bigger texture updates (and possibly wine does not handle big dynamic D3D texture updates as quickly as possible?) than uaegfx which is optimized to update as little as possible.

Generic emulation is always slower.

Some optimizations are possible but as I have said earlier, functionality first, optimization later, possibly much later.

[mark_k]

I did wonder whether, if WinUAE does some kind of partial texture update in D3D mode, Wine ends up reading back the whole texture from video RAM (slow). But that doesn't explain the contrast between CL and native modes, where D3D is faster and large window causes slowdown with DirectDraw. With native modes and DirectDraw, even though the actual size of the emulated display remains the same, it's the window size (even though much of it is blank) which causes the slowdown.

[Dr.Venom]

Hi Toni,

I noticed that CDDA music/audio is not working for CD32 games when using a PortAudio mode (asio4all in this case). If I use the same config, but select DSound, then the CDDA audio does work.

Log for both cases attached, hopefully they're helpful in tracing the issue.

EDIT:

In the log for DSOUND it shows:

18-449 [322 000-000]: SNDRATE 312.5*227.0*50.017082=3548086.759695
18-449 [322 000-000]: PAL mode lace V=50.0171Hz H=15625.0881Hz (227x312+1) IDX=1 (lace) D=2 RTG=0/0
18-449 [322 000-000]: RTGFREQ: 312*50.0171 = 15605.3296 / 50.0 = 312
18-453 [322 227=000]: DS: underflow (1920 4096)
20-784 [438 108=220]: IMAGE CDDA: playing from 205695 to 226734, track 15 ('Disposable Hero (1994)(Gremlin)(Track 15 of 16)[!].wav', offset 44, secoffset 0 (0))
22-871 [543 000=000]: VSync remembered: 50.017082Hz/1.0=50.017082Hz. MinV=45 MaxV=621i Adj=0 Units=143132 89.0%
22-871 [543 000=000]: CMD2: 'gfx_linemode=none

But in the log for portaudio it shows the following:

02-566 [322 000-000]: SNDRATE 312.5*227.0*50.016453=3548042.139613
02-566 [322 000-000]: PAL mode lace V=50.0165Hz H=15625.0881Hz (227x312+1) IDX=1 (lace) D=2 RTG=0/0
02-566 [322 000-000]: RTGFREQ: 312*50.0165 = 15605.1334 / 50.0 = 312
02-758 [331 000=000]: Interlaced frame type mismatch 0<>1 (447,375)
02-844 [335 000=000]: Interlaced frame type mismatch 0<>1 (-1,621)
04-930 [438 000=208]: IMAGE CDDA: thread killed
07-022 [543 000=000]: VSync remembered: 50.016453Hz/1.0=50.016453Hz. MinV=45 MaxV=621i Adj=0 Units=143134 89.0%
07-022 [543 000=000]: CMD2: 'gfx_linemode=none

[Toni Wilen]

Originally Posted by Dr.Venom

Hi Toni,

I noticed that CDDA music/audio is not working for CD32 games when using a PortAudio mode (asio4all in this case). If I use the same config, but select DSound, then the CDDA audio does work.

This is not a bug and it has always been like this. CD audio uses separate audio device instance = exclusive sound won't allow CD audio at the same time.

Mixing and resampling Paula audio with CD audio would be quite annoying to do..

[Dr.Venom]

Originally Posted by Toni Wilen

This is not a bug and it has always been like this. CD audio uses separate audio device instance = exclusive sound won't allow CD audio at the same time.

Ah ok, that's good to know, I'll keep using DSound for the CD32 config then.

Just out of interest, I remember you once considered adding XAudio2, but decided not to go ahead with it because (if I remember correctly) it doesn't allow play position reading from the buffer. Would you possibly consider adding it as a "fire and run" option? Meaning: only setting the audio-rate once based on real refresh rate, but from then on no additional adjustments to keep sync (as that would need play buffer position reading)?

This could possibly work well for (high-end) machines that can keep up with the frame rate? Latency wise it would possibly be better than DSound and still allow to mix the two streams.

P.S. Sorry if this is "slightly" OT for the beta series.