MINGW32 will be discontinued in the future.
So I fixed BII/SS so that it can also be built on MINGW64.
However, the following functions cannot be used:

JIT compiler
Windows/cdenable
Windows/router

The build will automatically determine which environment you are using, so if you build on ...

So does this have the potential to also help in Windows with the other fixed memory location issues? Or does it mostly move the issue to elsewhere in memory?


This has potential to solve the problem, but it also has cons.

Pros:
Do not acquire memory by specifying address
Do not use shared ...

I tried to implement a workaround.

Add following to the end of macemu/SheepShaver/src/MacOSX/config/config-macosx-x86_64.h and build.
#define MEM_BULK

Confirmed in the following environments.

Mac mini 2012
OCLP 2.4.0
macOS Sequoia 15.5
Xcode 16.4
SDL2 2.32.8

You have to set "jit false" in ...

If it helps, I should have time to merge https://github.com/mabam/macemu with present code in the end of next week.


I think the result will be the same as emendelson's pull request.


Is it possible to edit the code so that it works with the latest SDL2? This may not be worth the effort, I ...

It turned out that it works with SDL2 2.0.22 embedded in your app, but not with the latest 2.28.4.

I tried your pull request, but it didn't work properly, including the window appearing as a black rectangle.
However, the above build worked fine.
Is there any difference in the code?

Fixed drawing issue in the Windows version.
Download 28-08-2023 version.

viewtopic.php?t=5282

Thanks for your verification.
Merged to the master.

In the Windows build of SheepShaver, the cutscenes are similarly affected by freezes and stuttering. When I launch the game, it appears to run in a kind of 'slow motion'. It is smooth motion but extremely slow. This is the same in windowed or full screen mode. In addition, despite hardware being ...

With certain applications, problems such as part of the screen not updated or colors garbled may occur.
It may not be known until users of the applications report it.
The current version is stable, so we may be better to postpone merging until it's time to migrate to SDL3.

No, the changes for all host types.

Fixed the issue that garbage remains when running "Dark Forces" in Windows fullscreen.
It only effects when VOSF is disabled (default).

It also fixes the following bug:

https://www.emaculation.com/forum/viewtopic.php?t=11980

However, since I changed framebuffer handling, new bugs may appear ...

Merged to the master.

Ah, I see.
Fixed.

Added setting window position when switching to windowed mode.
Please test again with the latest test_fullscreen branch.

It seems strange, given both would rely on the same SDL based underpinings?


On any host, whether windowed or fullscreen, the drawing method is the same, and we let SDL handle the differences.
However, when I tried Dark Forces, I confirmed that it doesn't draw properly in fullscreen mode on ...

Honestly, the only thing I even need it for is to access the HFS formatted drive partitions on the SD card used by the Tash20.


It is possible to create an image file even if the SD card cannot be mounted.

1) Insert the SD card.
2) Click "Ignore" for Finder dialog.
3) From a terminal window ...

I recently fixed a similar issue in BasiliskII.
Specifically, I backported the high-precision timer of SheepShaver to BasiliskII.
Unfortunately, its implementation (src/timer.cpp) is OS dependent and Windows is not supported, so we can't use it.

Ah, I forgot about "make links"
Fixed.

By the way, the Windows version cannot use a high-precision timer, so there are no improvements in this update.

(From GitHub)
@Cat_7

SheepShaver/src/timer.cpp has been changed to a symlink.
There are many other symlinks in the SheepShaver/src directory.
Windows doesn't seem to handle symlinks by default.
How did you handle it in the past?

Yes, it's really odd.
The stable binary downloaded from the official site does not experience slowdown.
I haven't been able to find build options to get same behavior as it (both stable and beta).
My implementation is one workaround, not ideal.

Mini vMac runs emulation and drawing in a single thread.
Because of that, if drawing is blocked for some reason, the emulation speed will drop.
So I tried to separate the drawing to another thread in the macOS/SDL2 version.

https://github.com/kanjitalk755/minivma ... macos_sdl2

To recognize the image as a mixed mode CD: If you specify "disk", the CUE file may be destroyed, so you need to copy the correct file again.

I would suggest using the --config command line option to switch between preference files with different "keycodefiles".