WinUAE 1.5.0 beta series

[Toni Wilen]

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

Beta 22: (To do: OGL/D3D scaling options. bleh.)

- AF2008 non-KS/extended ROMs didn't decrypt properly
- configuration cache checkbox added to paths-panel (default is enabled, saved to registry/ini)
- added pointless CD32+FMV Quickstart entry
- CDTV extended ROM 1.0 part numbers added (2.07 PN still missing)
- Action Replay 3 v3.09 even/odd ROM checksums added (roms dumped, thanks to Jope for soldering ROM sockets to my AR3). First four bytes, io-addresses that can't be dumped using software dump method, are 0x50 0x00 0x00 0x00. (how boring..)
- possible fix for sluggish GUI Memory-panel

[Thom87]

Originally Posted by Toni Wilen

- possible fix for sluggish GUI Memory-panel

Now is much faster but there is still a little delay when moving and before amount of memory is shown corectly. Other sliders (floppy etc) works fine, quick with no delay, like 1.4.6.

Thomas

[thomas]

16bit P96 modes don't work correctly in fullscreen. When moving the mouse, the pixel rows where the pointer was are updated with the top of the screen rather than with the area below the pointer. So you copy the screen title all over the screen by moving the mouse up and down. Pressing F12 cures it until you move the mouse again. A screenshot does not show the corruption, either.

32bit works fine.

[Toni Wilen]

Originally Posted by thomas

16bit P96 modes don't work correctly in fullscreen. When moving the mouse, the pixel rows where the pointer was are updated with the top of the screen rather than with the area below the pointer. So you copy the screen title all over the screen by moving the mouse up and down. Pressing F12 cures it until you move the mouse again. A screenshot does not show the corruption, either.

32bit works fine.

Can't duplicate and have heard this previously, unfortunately I'll have to blame buggy display drivers.

[samklein]

Originally Posted by thomas

16bit P96 modes don't work correctly in fullscreen. When moving the mouse, the pixel rows where the pointer was are updated with the top of the screen rather than with the area below the pointer. So you copy the screen title all over the screen by moving the mouse up and down. Pressing F12 cures it until you move the mouse again. A screenshot does not show the corruption, either.

32bit works fine.

try set the display buffer to LocalVRAM. This solve the problem. At least for me...

[Toni Wilen]

Originally Posted by samklein

try set the display buffer to LocalVRAM. This solve the problem. At least for me...

if it does, it is 100% display driver issue.

[Ed Cruse]

Originally Posted by Toni Wilen

if it does, it is 100% display driver issue.

I've had the same problem and going to LocalVRam does fix it. I've always figured it might be a bad driver because out of two computers that I have one has the problem and the other doesn't.

What is LocalVRam and nonLocalVRam? LocalVRam seems to be a lot slower.

[Toni Wilen]

Originally Posted by Ed Cruse

What is LocalVRam and nonLocalVRam? LocalVRam seems to be a lot slower.

Unfortunately it isn't that simple (or there would be no options to choose from)

On some PCs LocalVRAM is much faster than other options. On some PCs it is totally opposite.. Previous WinUAE versions always used "DefaultRAM" option.

LocalVRAM etc is parameter to IDirectDraw7_CreateSurface(). NonLocalVRAM = DDSCAPS_NONLOCALVIDMEM | DDSCAPS_VIDEOMEMORY. LocalVRAM = DDSCAPS_VIDEOMEMORY. SystemRAM = DDSCAPS_SYSTEMMEMORY. DefaultRAM = no flags set = driver can decide.

Perhaps automatic speed test is needed in future.. Or perhaps replacing DirectDraw with Direct3D (DirectDraw is basically obsolete, even 2D is now supposed to be done with 3D hardware because it can do blending/etc much faster) but older cards may have problems with 3D..

[Retro-Nerd]

Originally Posted by Toni Wilen

Perhaps automatic speed test is needed in future.. Or perhaps replacing DirectDraw with Direct3D (DirectDraw is basically obsolete, even 2D is now supposed to be done with 3D hardware because it can do blending/etc much faster) but older cards may have problems with 3D..

Maybe you could add a selection for Direct Draw or Direct3D. You can select D3D in Mame or VBA, but i still prefer Direct Draw. It looks better, at least on my old GeForce 6600.

[Ed Cruse]

Originally Posted by Toni Wilen

Unfortunately it isn't that simple (or there would be no options to choose from)

On some PCs LocalVRAM is much faster than other options. On some PCs it is totally opposite.. Previous WinUAE versions always used "DefaultRAM" option.

LocalVRAM etc is parameter to IDirectDraw7_CreateSurface(). NonLocalVRAM = DDSCAPS_NONLOCALVIDMEM | DDSCAPS_VIDEOMEMORY. LocalVRAM = DDSCAPS_VIDEOMEMORY. SystemRAM = DDSCAPS_SYSTEMMEMORY. DefaultRAM = no flags set = driver can decide.

Perhaps automatic speed test is needed in future.. Or perhaps replacing DirectDraw with Direct3D (DirectDraw is basically obsolete, even 2D is now supposed to be done with 3D hardware because it can do blending/etc much faster) but older cards may have problems with 3D..

Thanks for the explanation, it was over my head but thanks anyway.

As an update, I was having the same problem the message above noted with the 16bit full windows screen, I have a GeForce 6100 on my mother board, I downloaded the latest driver and it fixed the problem.

[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

[Marcuz]

D3D exits still from winuae as in previous betas (bootlog attached) it happens in 16 bit and 32 bit scaling modes.

OGL boots but the colours are garbled in 16 bit only, as in attached image, while it works in 32 bit modes.
[edit]: the green screen there happens with picasso mode at a 16 bit resolution but a 31 bit one in the display panel of winuae, so it's my error right?
can you clearify please: picasso mode overrides the resolution choosen in the Display panel ONLY and not the bit depth?

I'm not sure as i don't remember how it looked when i had it configured before the filters gone broke, months ago, but it seems to me the scaling was better ( ? ).

however: tested D3D with all bit depths alike (picasso, display panel and filter panel) it crashes everytime

the other image is the same exact configuration with filters disabled

[Toni Wilen]

Originally Posted by marco pedrana

D3D exits still from winuae as in previous betas (bootlog attached) it happens in 16 bit and 32 bit scaling modes.

Can't duplicate. Please attach both winuaelog.txt and crash dump.

OGL boots but the colours are garbled in 16 bit only, as in attached image, while it works in 32 bit modes.

windowed, fullscreen or both?

[edit]: the green screen there happens with picasso mode at a 16 bit resolution but a 31 bit one in the display panel of winuae, so it's my error right?

can you clearify please: picasso mode overrides the resolution choosen in the Display panel ONLY and not the bit depth?

Picasso depth should not have effect in ogl modes. Does ogl work properly if you just boot without floppy disks and harddrives? (always use the most simple test first)

[Marcuz]

Originally Posted by Toni Wilen

Can't duplicate. Please attach both winuaelog.txt and crash dump.

in a few minutes i'll have test the things you ask, but as for the D3D crash, no dump file gets created, only the bootlog and winuaelog. also i've noticed that while the first time i tryed it tooks some 20 seconds to Winuae to exit, the second time it was almost instantaneous after having launched the emulation.

is there some setting to be checked to force the dump?

[Blueberry]

Originally Posted by Toni Wilen

Beta 23: (official release: next week)

How about the PCMCIA SRAM removal problem? It is still there in beta 23:

I boot up in a configuration which includes the PCMCIA drive (drive L: in Windows). When I insert the card, it appears correctly in workbench, and I can access the disk. But when I remove it, it stays there, and I can still access it.

[Marcuz]

soo...

First case, RTG modes (which were the ones i reported up there and are full screen)

1) OGL
16bit modes > colour problem as written up there.
if inside the emulation i change the resolution to a non Picasso mode > Winuae hangs.
if instead in the display panels i try to select a windowed mode, instead to warn me that RTG modes select their own resolution (there was a pop up like that, right?) > Winuae crashes and produces a dump: if that is needed i can send it your way.

2) D3D crashes always no dump file gets created.

second case, non RTG modes, selected A1200 expanded config from quickstart menu, no disk inserted:

1) windowed:
both OGL and D3D works only with 16bit filter modes: OGL stays black and D3D crashes in 32 bit modes IF the display panel has 16 bit depth
2)full screen:
D3D crashes always no matter the depths combinations. dump gets created.
OGL screen turns black no matter the depths combinations.

as there are many cases, and the ones with bare A1200 are easily reproducible (i mean in the steps to do) can you indicate me the ones for which you need dumps if they are available?

[Toni Wilen]

Originally Posted by Blueberry

How about the PCMCIA SRAM removal problem? It is still there in beta 23:

How about remembering that I can't test it myself. And how about testing it when there is something about it in change log and not when there is few days left before official release... (nothing personal but this pisses off most developers, me including)

[Toni Wilen]

Originally Posted by marco pedrana

soo...

Just put all dumps to single archive, I'll ask questions after examining them

[Toni Wilen]

Originally Posted by Blueberry

I boot up in a configuration which includes the PCMCIA drive (drive L: in Windows). When I insert the card, it appears correctly in workbench, and I can access the disk. But when I remove it, it stays there, and I can still access it.

18-619 [3755 000x000]: WM_DEVICECHANGE 'L:\' type=1 inserted=0
..
18-719 [3755 000x000]: testing if HD_\\.\L: has media inserted
18-719 [3755 000x000]: read ok (512)
18-719 [3755 000x000]: hmc returned 0

So Windows sends devicechange message that tells L:\ has been removed but when WinUAE checks if it is removed by trying to open it and reading first block and for some weird reason read succeeds! right..

(WinUAE does it this way because devicechange message only reports drive letter but winuae does not internally use drive letters but device paths. In PCMCIA SRAM case it seems both are equal so stupid workaround is possible..)

[Marcuz]

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.

that dump (+ bootlog and winuaelog) along the rest in a big zipped file, coming your way