arm64, window title setter

[kode54]

Now builds successfully for arm64, and has a dispatch to main thread to set the window title

[kode54]

Oops, spoke too soon. I need to check the aclocal thing that gets referenced.

[kode54]

Hmm, it builds when I run autoreconf on the build files, but then a bunch of the generated files that are included in the repo end up with major changes to them.

[ghost]

What is going on with your makefile.in kode54? The first set of changes matches up with the proper places in my makefile.in, but the 2nd set of changes is almost 300 lines earlier in yours than they would occur in mine.

Also great job on fixing the title bar :) Nice to not have to modify the cfg file to activate the popup status window

[kode54]

Yeah, it would occur later in the file if src/Makefile.in were committed with the autoreconf regeneration step already applied. I guess I'll commit those changes, then.

[kode54]

Yeah, the MSIE crashes on msn.com, with the following error:

IEXPLORE caused an invalid page fault in
module MSHTML.DLL at 0167:7adb13cd.
Registers:
EAX=02e9f924 CS=0167 EIP=7adb13cd EFLGS=00200212
EBX=02a024bc SS=016f ESP=fffffffe EBP=02e9f904
ECX=02a02364 DS=016f ESI=00000002 FS=2e17
EDX=02a025c4 ES=016f EDI=02e9fa44 GS=0000
Bytes at CS:EIP:
56 57 8b 75 08 8b 7d 0c 89 75 ec 89 7d f4 8b 75
Stack dump:

Disassembly:

0:  56                      push   esi
1:  57                      push   edi
2:  8b 75 08                mov    esi,DWORD PTR [ebp+0x8]
5:  8b 7d 0c                mov    edi,DWORD PTR [ebp+0xc]
8:  89 75 ec                mov    DWORD PTR [ebp-0x14],esi
b:  89 7d f4                mov    DWORD PTR [ebp-0xc],edi
...

Looks like it stack overflowed and tried to push esi to the end of the memory block.

[ghost]

Yeah, the MSIE crashes on msn.com, with the following error:

IEXPLORE caused an invalid page fault in
module MSHTML.DLL at 0167:7adb13cd.
Registers:
EAX=02e9f924 CS=0167 EIP=7adb13cd EFLGS=00200212
EBX=02a024bc SS=016f ESP=fffffffe EBP=02e9f904
ECX=02a02364 DS=016f ESI=00000002 FS=2e17
EDX=02a025c4 ES=016f EDI=02e9fa44 GS=0000
Bytes at CS:EIP:
56 57 8b 75 08 8b 7d 0c 89 75 ec 89 7d f4 8b 75
Stack dump:

Disassembly:

0:  56                      push   esi
1:  57                      push   edi
2:  8b 75 08                mov    esi,DWORD PTR [ebp+0x8]
5:  8b 7d 0c                mov    edi,DWORD PTR [ebp+0xc]
8:  89 75 ec                mov    DWORD PTR [ebp-0x14],esi
b:  89 7d f4                mov    DWORD PTR [ebp-0xc],edi
...

Looks like it stack overflowed and tried to push esi to the end of the memory block.

Ohhh, that crash. Yeah, I've seen it. I think it might be due to the fact that these windows installations are fairly generic and not using the proper motherboard drivers for everything in Windows. I have a lot of issues with Unreal and XVD DSOUND blue screens which a google search indicates as needing to install the manufacturer's motherboard drivers.

[kode54]

I'm using that Gigabyte board, which only has an ancient IDE driver for Windows 95, nothing for Windows 98.

[ghost]

I'm using that Gigabyte board, which only has an ancient IDE driver for Windows 95, nothing for Windows 98.

That board is new though and quite likely has bugs in it. Have you tried a new image with a different motherboard/cpu combo?

[kode54]

I'm open to suggestions. There aren't that many Socket 7 boards that accept a new enough Pentium MMX for it to really be highly performant. Name a board, I'll find the firmware myself. Of course, it would help if you linked to the drivers, if they're not still provided by the vendor.

[ghost]

I personally like the FIC VA-503+ with an AMD K6 chip. That was the core of a system I had built back in the late 90s. Unfortunately, while I do have ALL of FIC's stuff archived... I'm not sure which one is for that board.

I also had one built using the DFI K6VX3+, but that one isn't supported :(

Ironically, that was the ONLY time I liked AMD's stuff.

[ghost]

Okay, got the same issue with IE on Win98 SE on the FIC board with a K6-2/450 cpu.

I've been testing this for a while tonight and it appears the issue is with the MSN homepage and not the emulation itself.

[almeath]

Thanks for your work on this @kode54 , are we all in agreement that the instability you are experiencing in Windows is related to your specific configuration and not anything contained in these commits? If so, I will be happy to merge them. I will then do some testing on my Intel Mac over the weekend to make sure it is all working smoothly on that architecture as well.

[kode54]

I don't think it's anything related to the commits I've prepared, but if anything, existing code in the arm64 backend. If not that, then something else entirely. It will pave the way for anyone attempting to fix the bugs in question, though. As opposed to, say, trying to get the x86_64 recompiler working under Rosetta 2. Which this should also fix, actually. (The MAP_JIT is required under the 10.14+ SDKs.)

[ghost]

I don't think it's anything related to the commits I've prepared, but if anything, existing code in the arm64 backend. If not that, then something else entirely. It will pave the way for anyone attempting to fix the bugs in question, though. As opposed to, say, trying to get the x86_64 recompiler working under Rosetta 2. Which this should also fix, actually. (The MAP_JIT is required under the 10.14+ SDKs.)

There is definitely an issue with the audio code in the arm64 side. As long as I have my system cfg set to none for audio, I can get a lot of Windows games to work. But if I add a sound card, then Windows will have issues with blue screens when starting ones like Unreal.

Other than that, I have a perfectly setup Win98se system setup using the Gigabyte board and PII/450 cpu. It even reboots and shuts down windows properly (and shut down correctly returns to the PCem Configuration Manager).

[kode54]

Hmm, I'll see if I can fix that as well, if it's arm64 specific. Though I may not be able to tell if it's specific to a given sound card, or specific to the output API it's choosing.

[ghost]

Hmm, I'll see if I can fix that as well, if it's arm64 specific. Though I may not be able to tell if it's specific to a given sound card, or specific to the output API it's choosing.

Happens with all of the ones that have drivers for Windows. I just spent all day testing :P

Btw, I got Unreal to stop killing me as soon as the game starts and actually display graphics. Usually runs between 95-100 % speed.

[ghost]

Hmm, I'll see if I can fix that as well, if it's arm64 specific. Though I may not be able to tell if it's specific to a given sound card, or specific to the output API it's choosing.

Odd question, but do you think the crash when quitting PCem might be tied into the emulated system's window not being closed when "shutdown"?

Edit: That's not the cause of the crash.

[kode54]

I still can't get Final Reality to run the benchmark, it only crashes with a DDERR_EXCEPTION. It also appears to do some garbage blitting during the startup cycle, which would seem like one of the GPU emulators is walking on memory.

[kode54]

The GPU glitches less when I use a Voodoo 1 instead of Voodoo 2, but Final Reality still won't run.

[ghost]

The GPU glitches less when I use a Voodoo 1 instead of Voodoo 2, but Final Reality still won't run.

Have you tried without Voodoo support? I think I tried a banshee or voodoo3 with the same problems.

[kode54]

What 3D accelerator should I use instead? Software rendering mode in applicable games? S3 VIRGE?

[ghost]

Not sure. Think of it as a buffet and try everything :)

[kode54]

So far, everything I've tried is broken.

[ghost]

Sounds like Final Reality isn't compatible? Or there are issues in the arm64 video code as well as audio code.

[kode54]

It was compatible under PCem v16 or v15 or even v14, on x86 32 bit.

[ghost]

So issues with the Arm64 code then

[kode54]

Even the x86_64 voodoo code was broken, last time I used it. It had broken color blending modes, either the lighting or the color.

[ghost]

I use PCem for Dos predominantly. This is the first time I've tried Windows stuff.

[kode54]

Must not be many people testing the actual hardware aspects of it, for any actually not-terribly-old games. I always just used Dosbox if I needed DOS games, unless they magically needed MMX or 3Dfx.

[ghost]

Must not be many people testing the actual hardware aspects of it, for any actually not-terribly-old games. I always just used Dosbox if I needed DOS games, unless they magically needed MMX or 3Dfx.

Giving up?

[kode54]

I haven't given up yet, but it does appear that the arm64 codegen is broken, or does something bad somewhere. The x86_64 codegen doesn't suffer from the same problems.