WinUAE 1.5.0 beta series

[Toni Wilen]

Originally Posted by Blueberry

How about the PCMCIA SRAM removal problem?

Stupid workaround added, does http://www.winuae.net/files/b/winuae.zip work? Please, test this as soon as possible

[Toni Wilen]

Originally Posted by marco pedrana

update!
i've managed to make work D3D in this case:
RTG resolution, 32bit on the display panel without filters, booted up; switched to windowed mode (it works, i supposed it couldn't, my bad); then switched on D3D with 32bit mode too. it works. then if you go full screen it crashes and created a dump.

This may be yet another display driver bug.. CreateDevice failed, 80004005 S=1 F=0000 C=4005 (16389) () when it tried to create 3D display. Bogus looking error code.

Try "Display buffer" in misc panel set to DefaultRAM.

btw, dump file is corrupt and HUGE. (which may also point to display driver doing something really weird, especially if the dump isn't always written)

btw2, other dumps are confusing..

I have to ignore these until I can duplicate them myself (=needs step by step instructions and as much as information which settings stops if from crashing etc..)


EDIT: I can duplicate it now...

[Toni Wilen]

D3D fullscreen and D3D<>Picasso96 switching should be fixed now (http://www.winuae.net/files/b/winuae.zip)

[Marcuz]

Display buffer set to DefaultRAM, in the case of the D3D fullscreen doesn't changes the crash, and dump is not created always: sometime it happens, sometime it doesn't, with the same exact configuration.

what may affect it - maybe - it's that it gets created when switching display when the emulation has been booted completely, when it doesn't if it has not yet booted (starting in fullscreen)

(the "CreateDevice failed" string you write do appears in fact in a requester when Winuae crashes AND the dump is created, not when it doesn't.)

anyway, i have reproduced the huge dump also with the "DefaulRam" bit.

i attach a config that surely crashes it (when D3D filters are on)

...

other dumps:

-start Winuae
-leave quickstart panel as it is and start emulation windowed
-as the screen with the kickstart loaded appears asking to insert a disk, open the GUI
- enable filters: D3D > ok > back to the emulation it works.
- GUI again, in the display panel select Fullscreen > crash

the screen goes black and the requester with the "devicecreation failed bit is out of focus; you have to alt+tab to windows then back to winuae to press ok and exit. please notice that sometimes the dump is not created right away, but it may happen that it need you to click / mouse over on the lingering winuae icon in the tray

[Marcuz]

Originally Posted by Toni Wilen

D3D fullscreen and D3D<>Picasso96 switching should be fixed now (http://www.winuae.net/files/b/winuae.zip)

sorry haven't tryed yet that in my previous post, (had left the page open for a couple of hours, sorry) now i will test it


[edit]

tested! fixed in all the occurrencies i had reported thanks!

[Marcuz]

Update

while the D3D doesn't crashes anymore, each time i change the settings of size and position in the filter panel, during the emulation, winuae hangs indefinitely when it should return after closing the GUI.

i've tested this on different resolutions and with different pixel ratios.
it happens in full screen in non RTG modes; in this case, as the settings are loaded at the start, the filtering is working before you change it (so it is not related to the filtering settings different from "0")

also, when the GUI is on screen, you can see the changing values affect what happens behind it. only the closing of the GUI breaks the emulation.

everything works in windowed mode.

it happens also with the bare empty A1200 config as described in previous posts.

sorry if i could not report it before, but i'm touch and go today


edit

OpenGL too is broken in full screen: it stays black both if you load it at the sturt up and if you add it afterward (same A1200 test)
it works on windowed mode.

Suggestion: could the bit depth in the filter panel be forced to be always alike the one selected in display panel? if they differ and filter is = 16 you always end with garbled colours, so imho no point in keeping them separated.

[Toni Wilen]

Originally Posted by marco pedrana

Suggestion: could the bit depth in the filter panel be forced to be always alike the one selected in display panel? if they differ and filter is = 16 you always end with garbled colours, so imho no point in keeping them separated.

Works fine here. (it is the point of this setting to be able to have different internal emulated depth and real output depth because ogl/d3d can do the conversion automatically)

[Toni Wilen]

Originally Posted by marco pedrana

winuae hangs indefinitely when it should return after closing the GUI.

Does it stop hanging if you remove all joysticks? (for some reason here it hangs if I have USB pad inserted and winuae tries to reacquire the device after exiting GUI. This is really weird..)

[Marcuz]

Originally Posted by Toni Wilen

Does it stop hanging if you remove all joysticks? (for some reason here it hangs if I have USB pad inserted and winuae tries to reacquire the device after exiting GUI. This is really weird..)

no, nor any other USB device. also a precisation, change of settingsis not respomsible, as i assumed, the simple calling of the GUI blocks it. heh i'm not a great detective

anyway: could it be this a 32bit executable problem on Vista 64bit?

[Marcuz]

Originally Posted by Toni Wilen

Works fine here. (it is the point of this setting to be able to have different internal emulated depth and real output depth because ogl/d3d can do the conversion automatically)

yeah but even with a picasso mode? can you try this:
first boot full screen 1280*1024*32BIT, D3D enabled point 16BIT; your hd workbench with picasso screenmode is set UAE: 800*600*16BIT.
all should be fine.
then call the GUI switch to windowed mode (this way no crash happens, btw) 640*512: in my case the colours are screwed, similarly as the screenshot posted before.
am i doing something wrong?

i attach the config.

[edit]
argh... each time i check i find something different... yesterday the OGL issue with the colours was fixed by switching the bit depth to 32, now, with D3D: no matter what i change, in windowed mode, the colours stay garbled: i have to reset with the correct bitdepth and it gets fixed. then, if i am already in windowed mode, i can change back to 16bit depth the filter panel and it stay fixed...

[Ed Cruse]

Originally Posted by Toni Wilen

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

Beta 23: (official release: next week)

- OGL/D3D fixed but uses old scaling method (update after 1.5)
- AF2008 ROM scanner detection problems really fixed
- JIT timing change test (perhaps faster CPU without other side-effects..), added command line parameter -jitevent <val> current default 10000, old was 3000. Experiment if interested..
- default display buffer setting changed to "DefaultRAM" (which is same as in 1.4.6 and older, can cause too much confusion if new version even in non-Picasso96 mode is much slower than old version due to weird display drivers)
- disk write does not start if wordsync is enabled
- improved rare heavy CPU usage situation when sync word=0 without disk inserted
- improved dragndrop file type autodetection
- ignore duplicate directinput joystick axis indexes

I played around with the jitevent timing, it did not cause any problems that I could see. Counting a really tight loop it showed an 18% increase in cpu speed between 3000 and 10000, but using my compiler and two complex looping test programs I didn't see any speed increase. The two complex looping programs are single threaded, no delays or waits, they just go as fast as they can. One of them also uses a lot of inline fpu code. I also didn't see any difference in hardfile speed or RTG speed.

There doesn't seem to be much of an advantage, but there also doesn't seem to be any disadvantage.

[Toni Wilen]

Originally Posted by marco pedrana

yeah but even with a picasso mode?

Did you mean Picasso96 has wrong colors? That I can confirm if Picasso96 mode has different depth than Display panel depth and D3D depth is same as Picasso96 depth. But I thought you meant D3D/OGL modes have wrong colors (=native modes, not Picasso96..)

winuae.zip updated, color problems should be fixed but odd directinput hang/crash is not fixed (this is soo weird..)

[Little_Sharky]

Executed Winuae executable
Loaded up a configuration with hard drive , workbench 3.1 ,profile works 100% ,tested WITHOUT FILTERING AND WORKS GREAT
Enable Opengl filter with standar settings
Winuae Crashed!

debug.txt includes further details.

[Marcuz]

Originally Posted by Toni Wilen

Did you mean Picasso96 has wrong colors? That I can confirm if Picasso96 mode has different depth than Display panel depth and D3D depth is same as Picasso96 depth. But I thought you meant D3D/OGL modes have wrong colors (=native modes, not Picasso96..)

winuae.zip updated, color problems should be fixed but odd directinput hang/crash is not fixed (this is soo weird..)

that's what i meant: one of the test i did was to load a picasso setup and launch a whdload game from there so i could test both in the same session. it is picasso mode with the wrong colors

[edit]
color problem fixed now in the new one

[Toni Wilen]

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

Beta 24: (this never ends..)

- real PCMCIA SRAM card removal should really really work now
- real harddisk (or memory card or usb stick) disk change message could have been sent to wrong device unit if multiple harddisk devices were configured (including hardfiles)
- direct3d and opengl fullscreen fixed
- direct3d/ogl<>Picasso96 switching fixed (instant switch not possible)
- NTSC vblank end vpos fixed (top of display was cut in overscan modes)

[Marcuz]

i'm going to test it now

- direct3d/ogl<>Picasso96 switching fixed (instant switch not possible)

what does this mean? will have effect on a picasso-ed WB that launches a whdload enviroement while filters are in effect?

(reason for the question: if you have a common or fixed setup for filters to stretch a common game screen to full screen, if you can keep D3D or OGL active all the time and it does not hinder picasso, you can avoid to call the GUI each time you start the Whdload environment to change settings)

[Marcuz]

[EDIT]

tested. nope. full screen:
D3D still hangs if i call the GUI in non Picasso modes in the situation just described above, while the gui closing worked just a second before in the picasso mode.

changes to the stretching are visible under the gui but when you close it Winuae stays there with the black area in the middle.

OGL hangs just as soon you call the GUI, which does not open, same setting as above: picasso WB > launch whdload game > call GUI

in both cases, only way to close winuae is by calling Ctrl+Alt+Canc. Winuae is using about 90 Mb and 50% of CPU.


Windowed, everything works.

as a sidenote, and on this i'm not sure, and knowing it's not accurate please just take it with a grain of salt, it seems to me that the filters mode are, when they work, a bit more slow and hiccup.in' than before they got broken some betas ago. i don't have the working beta anymore, so i cannot check it.
sound also, when in filter mode is a bit more messy: that i'm pretty sure about.

[Toni Wilen]

I said hanging is not fixed and probably won't be because it happens inside directinput.. (either it stays or d3d/ogl will be disabled, too late now)

[Toni Wilen]

Originally Posted by marco pedrana

i'm going to test it now

what does this mean? will have effect on a picasso-ed WB that launches a whdload enviroement while filters are in effect?

(reason for the question: if you have a common or fixed setup for filters to stretch a common game screen to full screen, if you can keep D3D or OGL active all the time and it does not hinder picasso, you can avoid to call the GUI each time you start the Whdload environment to change settings)

It only means p96<>native mode switching with ogl/d3d will do it like in 1.4.6 (close and reopen window/screen) and not "instantly" like in other modes in 1.5

[Marcuz]

Originally Posted by Toni Wilen

I said hanging is not fixed and probably won't be because it happens inside directinput.. (either it stays or d3d/ogl will be disabled, too late now)

just a question: it is because a different way to implement filters? i mean, this thing worked before (Winuae 1.4.6?)

this way filters are practically useless in picasso modes :/