WinUAE 4.9.2+ beta series

[Ponki1986]

Originally Posted by Toni Wilen

Sounds like "internal" 16-bit screen mode. Does anything change if you select 32 bit mode in WinUAE display panel (even if you use windowed mode!)

EDIT: I ran WinUAE in 16 bit color depth but only in Full Window mode and had previously also had to lower the Windows desktop depth to 16 bit. Otherwise, WinUAE always started emulation in 32 bit color depth. After all, 16 bits did not help, the PiP windows were black.

I decided to run Process Monitor and create two logs. Both recorded the launch of WinUAE 4.9.2, the loading of the configuration, the launch of AmigaOS and the launch of the Genetic Species game. I launched the game in a PiP window on Workbench. I then pressed F12 and shut down the emulator.

The difference in the two logs is that the first one is running WinUAE in XP compatibility mode, and with Direct3D version 9. Then the PiP works fine. The second log is running without XP compatibility, and with Direct3D version 11. Then the PiP windows are black. Perhaps this will prove useful at least a little.

https://drive.google.com/drive/folde...Im_38Dueghim3a

EDIT: I installed VC Redist 2015-2022 but it didn't help.

[Xiantrius]

Originally Posted by Toni Wilen

Sounds like "internal" 16-bit screen mode. Does anything change if you select 32 bit mode in WinUAE display panel (even if you use windowed mode!)



This is not request thread but consider it done
(+Reset is done immediately when keys are pressed but reset only continues after releasing at least one key)

Hard reset is already possible by including also ALT key.



C without parameter resets.

Ok THX Toni Wilen
Sorry, i didn't know that a hard reset is also generated when I press ALT. Tried it out and took Pinball Wizard as a test, because it likes to hang in memory and it doesn't work with Normal Reset.


best regards,
Xiantrius

[Toni Wilen]

Originally Posted by Ponki1986

The difference in the two logs is that the first one is running WinUAE in XP compatibility mode, and with Direct3D version 9. Then the PiP works fine. The second log is running without XP compatibility, and with Direct3D version 11. Then the PiP windows are black. Perhaps this will prove useful at least a little.

Does it work without XP compatibility if you choose D3D9 in misc panel?

[Ponki1986]

No. PiP mode only works correctly for me with XP compatibility. Only then the window content is correct, otherwise the window is black.

Version 4.9.1 worked for me in XP mode, and I was able to use Direct3D version 11. I had therefore forgotten about the PiP problem once posted in the thread condemned above.

[Dic_Ray]

Originally Posted by Ponki1986

Then the PiP windows are black.

What computer and Windows version do you use? Have your computer an internal chipset graphic and a discrete graphics card? Black windows content I often saw, when a program used a certain graphics card. Perhaps you could try to associate WinUAE to your internal chipset graphic.

[Ponki1986]

Windows 7 Professional x86 SP1. I checked on two computers and the situation is identical.
1. Fujitsu Futro S720: SoC CPU AMD G-Series GX-217GA 1.65GHz and GPU AMD Radeon HD 8280E, 2 GB RAM, 128 GB mSATA SSD.

2. GA-MA74GM-S2 (rev. 1.x), CPU AMD Phenom X4 9500, GPU nVidia Quadro FX 1800, HDD SATA 500 GB, 4 GB RAM.

In both cases, I have all the drivers installed. I also have Direct3D version 9 and 11 installed. Both work in WinUAE. The only problem is with PiP, but this one disappears when running WinUAE in XP compatibility mode. The same is true for both computers. I will try to install Windows 7 but without Service Pack 1. Once an AMIGASYSTEM user wrote that he has Windows 7 without SP1 and PiP works with him in WinUAE. Maybe that's the reason.

EDIT: I installed Windows 7 Build 7600, which is without SP1. Of course all drivers and Direct3D as well. Surprisingly, the situation is still the same. At this point, I don't know what's going on anymore... I cannot use a different version of Windows type 8 or 10 because I have prepared a modification for 7 that gives the impression that the only system that runs on the computer is AmigaOS.

[Toni Wilen]

Graphics card or Windows version shouldn't affect it at all, PIP screen is simply CPU drawn on top of internal RTG buffer. It is not separate graphics element.

Which is why I still suspect it has something to do with host display format or RTG mode screen format. For example XP compatibility might force some specific settings that UAE didn't request.

[Ponki1986]

Does the way the computer is connected to the display make a difference? I'm using an adapter from Display Port to HDMI, and my 26" LCD is a 2008 LG TV. I might try an analogue connection using a D-Sub VGA cable?

EDIT: I connected the computer analogically with a D-SUB cable and a DVI-VGA adapter. The situation is still the same.


Could anyone comment on how PiP works for him? What kind of Windows does he have? What computer parameters? I will be grateful.

[pjhutch]

I was wondering if it is possible to change the Help feature on WinUAE, so it pickup different type of help files beyond the standard winuae.chm. So, depending if file exists e.g., winuae.chm, Winuae.pdf or no help file found, go to the https://www.vware.at/projects/winuae/ page?

[liveevil]

@Toni Wilen

I think there is an oddity when playing audio in CHD files. I started a thread here -
https://eab.abime.net/showthread.php?t=112171

Basically, it seems to wait a second or two before you start hearing the audio, and when speech plays on some games you don't hear the beginning of it.

I edited the .cue file from Battle Chess CD32 so that it boots straight to the CD player. I posted the CHD at the bottom of the link I posted. When you play any of the audio tracks there is a few seconds silence before you can hear it so you miss the first part. I tried the same CHD in the Sega GenesisGXPlus emulator and the tracks play fine on the CD player. They start instantly. Any chance you could have a look ?

[Ponki1986]

Originally Posted by Toni Wilen

Which is why I still suspect it has something to do with host display format or RTG mode screen format.

Any chance you'll solve this problem?

[Toni Wilen]

Originally Posted by Ponki1986

Any chance you'll solve this problem?

I don't know.. Try reducing Z3 RAM to 64M and VRAM to 64M too. 32-bit Windows versions can have relatively small per-process address space limits which can cause unexpected problems if too much RAM is allocated.

[Keatah]

Thought I'd stick my big nose in here to say how awesome the ongoing work is for this emulator. It's a key component for my All-In-One retro rig - a childhood dream about having all 70's - 90's machines rolled into one.

Effen'Love it!

[Toni Wilen]

https://download.abime.net/winuae/fi...nuae_4920b3.7z
https://download.abime.net/winuae/fi...ae64_4920b3.7z

Beta 3:

- 68000 IPL check position is now almost fully accurate (Still some special cases to check and test). Very big thanks to fx68k author!
- W debugger command hang fixed.
- Full drive/RDB mode is now normal checbox. Hopefully it is now less confusing than button that didn't really look like a button. If selected HDF already has RDSK identifer, checkbox is ticked and disabled. Checkbox can be only ticked/unticked if selected HDF does not have RDSK identifier.
- GDI mode didn't force 32-bit screen depth mode.
- FloppyBridge uae-configuration change now really updates all internal variables.
- Screenshots didn't work if 256 color checkbox was not ticked (tried to create 24-bit palette indexed image)
- DMACONR blitter status 1 cycle delay was broken (Circle scroller / UFO)
- Enabling DMA debugger and then returning to emulator continuously reported conflicts until next frame had finished. DMA debugger init was changed but tables were not fully initialized.
- Keyboard reset now behaves more like real hardware. Press keys, hardware gets reset (if keyboard reset warning is not active), reset continues only when at least 1 key is released. If all keys are kept pressed more than 5 seconds: do hard reset.
- DMA debugger CIA access line includes also E-clock state (0, 2, <data access info>, 6, 8) and any "wasted" cycles needed to sync with E-clock are marked with "-".
- DMA debugger is wider. More space for future features.
- New cputester tests done, for example all SR modification instructions (including STOP) tested with both trace + pending interrupt. No errors found.
- If STOP was executed without trace active and STOP enabled trace, STOP still stops normally and only interrupt can wake it up. (b1)
- Blitter busy bit read incorrectly as blit not busy if blitter was in non-nasty mode and not line mode and CPU stole second to last D channel slot.
- Removed all remaining Windows 7/Vista checks (from days when XP and Vista was still supported).
- "Remove interlace artifacts" is broken. Will be fixed later.

btw, this thread is only about beta related bugs or problems. Don't post unrelated new feature or improvement requests here.

[R-TEAM]

64bit version dont Start at all - 32bit version runs ...
Win 10 64bit (Intel CPU)

Regards

[Rotareneg]

Same here on my desktop, Windows 10 21H2, i7-860.

Problem Event Name:	APPCRASH
Application Name:	winuae64.exe
Application Version:	4.9.2.0
Application Timestamp:	63557dfc
Fault Module Name:	winuae64.exe
Fault Module Version:	4.9.2.0
Fault Module Timestamp:	63557dfc
Exception Code:	c000001d
Exception Offset:	0000000000693218
OS Version:	10.0.19044.2.0.0.256.48
Locale ID:	1033
Additional Information 1:	115e
Additional Information 2:	115e5dd9efe79b7ca5e81e565fbb6a33
Additional Information 3:	cbc7
Additional Information 4:	cbc73e41f68725845155ad8670d5fdc0

[enigma776]

Originally Posted by R-TEAM

64bit version dont Start at all - 32bit version runs ...
Win 10 64bit (Intel CPU)

Regards

Works fine for me,

Windows 10 21H2
i9-10850k

[Mclane]

Win 10 21H2 i7 v4 16gig ram

Both versions start fine..

[Toni Wilen]

64-bit version has wrong CPU requirement (requires AVX). Will be fixed in next beta.

[Rotareneg]

Cool, I was worried my CPU was suddenly going to be too old after just getting it (checks emails...) uh... 13 years ago? Yeah, we probably should upgrade one of these days.