MacOSX/OSX/macOS 64-bit build for testing

[Elyus]

This is really amazing! Having a 64-bit Sheepshaver with SDL2 and all the other features is great.

SDL2 still has a few bugs, particularly with memory handling. I've been testing a number of games, and on my machine (MacBook Pro running 10.13.5), the screen fails to update in most games until I move the mouse around a lot. In certain cases, like Warcraft II, everything plays fine at first but always crashes after a few minutes with a malloc free error.

It probably will take some time and familiarity with SDL2 to debug, but my preliminary tests have found that it is always a double free or freeing a non-existent pointer error. The two places where it can happen are calls to SDL functions: SDL_BlitSurface on line 878 of video_sdl2.cpp and SDL_SetSurfacePalette on line 1083 of video_sdl2.cpp.

Maybe it's just me encountering this problem, but I'll try to debug further anyways.

Thanks to all the contributors and maintainers for keeping SheepShaver alive

[emendelson]

I have appended "hotkey" keyword to preference item.
Conventionally hotkey is control key, you can now change it by adding "hotkey" keyword to pref file.

Code: Select all

1: control(default)
2: option
3: control+option
4: command
5: control+command
6: option+command
7: control+option+command

It might be good to add this option to the Preferences pane someday, with a full explanation of the numbers. You've done more than enough work already, but I hope you might consider this also.

And has anyone tried to build a Windows executable from kanjitalk755's excellent code?

[kanjitalk755]

The key between between Z key and the shift key does not register.

Specifically, what kind of problem is it?

It probably will take some time and familiarity with SDL2 to debug, but my preliminary tests have found that it is always a double free or freeing a non-existent pointer error. The two places where it can happen are calls to SDL functions: SDL_BlitSurface on line 878 of video_sdl2.cpp and SDL_SetSurfacePalette on line 1083 of video_sdl2.cpp.

It turned out to be lack of mutex lock in video_sdl2.cpp. Fixed.

It might be good to add this option to the Preferences pane someday, with a full explanation of the numbers. You've done more than enough work already, but I hope you might consider this also.

Unfortunately, I don't interest in GUI improvements.
I hope someone else interests it.

And has anyone tried to build a Windows executable from kanjitalk755's excellent code?

My repo can be built not only macOS but also Linux(x86) and MinGW32/MSYS (not MSYS2).
But Windows build crashes with JIT.
Also, BasiliskII can be built in same platforms. 64-bit JIT of BasiliskII is not implemented.

[Ronald P. Regensburg]

The key between between Z key and the shift key does not register.

Specifically, what kind of problem is it?

This key does not do anything. Nothing happens when I press it. In Dutch and in most English keyboard layouts this key produces ` (grave accent, UTF-8 0x60) and with shift key ~ (tilde, UTF-8 0x7E). With option pressed, it is a 'dead' key that gives the grave accent to the next typed letter, like this: è.

In builds from cebix-macemu this all works as expected. In builds from your source the key does nothing. This key is not much used, but without the grave accent it is difficult to write for instance French text on a regular QWERTY keyboard.

[kanjitalk755]

I don't have that type of keyboard.
Can you cooperate with debugging?

1) Set "Build Configuration" to Debug.
2) Set breakpoint at video_sdl2.cpp#L1894

Code: Select all

switch (ks.sym) {

3) Run.
4) Press the key.
5) Tell me value of ks.sym.

[Elyus]

It turned out to be lack of mutex lock in video_sdl2.cpp. Fixed.

Thanks, kanjitalk755! I was messing around with SDL mutexes a bit last night after tumbling to a similar conclusion -- the mutex lock present was not protecting surface->map->table from being freed multiple times. The mutex locks you've added seem to fix the memory problems, and it runs smoothly now. You are very familiar with the code and a fast bug-patcher

When you have a chance, would you be willing to look at the "update_display_static_bbox" function? There's some error in calculating if a box is dirty, which is why most games are loading to a black screen until the mouse is moved. The quick fix is to initialize dirty = true, and force every box to update every time. It's a small hack that has a minimal impact on energy usage (on average, one or two more cpu wakes/second according to Xcode), but I'm wondering if there's a better solution.

[Ronald P. Regensburg]

1) Set "Build Configuration" to Debug.
2) Set breakpoint at video_sdl2.cpp#L1894

Where? How? In the Debug menu I see four different Breakpoint items.

Code: Select all

switch (ks.sym) {

Where do I enter that?

[Elyus]

If you're using Xcode, you should be able to open video_sdl2.cpp in the file browser and just click in the margin by the switch command to set a breakpoint. If you're building for debug/testing, when you press the play button, it should stop and open the visual debugger whenever you hit a key. At least, that's what worked for me. This is what I see when I press the "z" key.

[Ronald P. Regensburg]

Well, I finally got it. I had to struggle through issues that probably should be obvious, but are not obvious to someone who does this for the first time.
The prefs file needed to use full paths, otherwise SheepShaver would not run.
The key needed to be pressed while SheepShaver was in front, not while Xcode was in front.

Anyway, the image shows the result when the problem key (not the "z" key, but the key to the left of the "z" key) was pressed:

[Elyus]

Well, I finally got it. I had to struggle through issues that probably should be obvious, but are not obvious to someone who does this for the first time.
The prefs file needed to use full paths, otherwise SheepShaver would not run.
The key needed to be pressed while SheepShaver was in front, not while Xcode was in front.

Anyway, the image shows the result when the problem key (not the "z" key, but the key to the left of the "z" key) was pressed:

Ah, good point, the prefs file caused me trouble too since I typically use sheepvms. Actually, it should be possible to debug against sheepvms if you add an argument to the build scheme, but it doesn't seem beneficial for simple tests.

That's an interesting key code. From your earlier image, the key looks like a US backquote, but the SDL type is non-US backslash. I wonder if the desired behavior is backquote or backslash, respectively 0x0a or 0x2a? That might be something to test as well. If you want to try it firsthand, you could add the following case and check "0a" or "2a" in place of the ##:

Code: Select all

case 167: return 0x##; // non-us backslash

Unfortunately, you have to hardcode the sym value (167) since the standard SDL headers do not define an enum for that character. You could use the conversion macro in place of 167, SDL_SCANCODE_TO_KEYCODE(SDL_SCANCODE_NONUSBACKSLASH), but it's more overhead.

[emendelson]

That keystroke is listed in SDL_scancode.h in the SDL2 source:

SDL_SCANCODE_NONUSBACKSLASH = 100, /**< This is the additional key that ISO
* keyboards have over ANSI ones,
* located between left shift and Y.
* Produces GRAVE ACCENT and TILDE in a
* US or UK Mac layout, REVERSE SOLIDUS
* (backslash) and VERTICAL LINE in a
* US or UK Windows layout, and
* LESS-THAN SIGN and GREATER-THAN SIGN
* in a Swiss German, German, or French
* layout. */

I don't know how to make any use of this, unfortunately. But it seems that you could enable that key by adding the SDL2 source to the project (as kanjitalk755 explained in another post) and then modifying SDL_keycode.h, perhaps like this:

SDLK_NONUSBACKSLASH = SDL_SCANCODE_TO_KEYCODE(SDL_SCANCODE_NONUSBACKSLASH),

But I can't guess where you would go from there...

[emendelson]

Ronald,

Could you test whether kanjitalk755's build based on SDL1.2 (from earlier this month) supports that key? If you don't still have one of those builds, let me know and I'll send a link via PM.

[Ronald P. Regensburg]

I don't know how to make any use of this, unfortunately. But it seems that you could enable that key by adding the SDL2 source to the project (as kanjitalk755 explained in another post)

Well, it depends on the languages and the keyboard you use, I suppose. I use that key regularly, though not often, for the grave accent and I cannot do without it. The key has been on any Apple keyboard I used since 1995. Always keyboards with Dutch layout.

* Let's wait for kanjitalk755 to respond. He is the one who asked me to help debugging this issue as his keyboard does not have that key. *

Ronald,
Could you test whether kanjitalk755's build based on SDL1.2 (from earlier this month) supports that key? If you don't still have one of those builds, let me know and I'll send a link via PM.

I do not have that one anymore. I could dig into my Time Machine, but sending me a link is easier.

[emendelson]

PM sent.

[Ronald P. Regensburg]

In the earlier SDL1.2 build from kanjitalk755/macemu source the key works as expected.

[kanjitalk755]

When you have a chance, would you be willing to look at the "update_display_static_bbox" function? There's some error in calculating if a box is dirty, which is why most games are loading to a black screen until the mouse is moved. The quick fix is to initialize dirty = true, and force every box to update every time. It's a small hack that has a minimal impact on energy usage (on average, one or two more cpu wakes/second according to Xcode), but I'm wondering if there's a better solution.

I couldn't reproduce the issue.
But I noticed display must be redrawn when palette is changed.
Is your problem resolved with new code?

@Ronald
I have appended "167" key.

BTW, you can use "keycodes" file in SDL2 version, too.
A sample is macemu/BasiliskII/src/SDL/keycodes.
I duplicated "sdl Quartz"(SDL1) to "sdl cocoa"(SDL2).
But it's unusable because keymaps differ from SDL1.
I hope someone edits it correctly.

[Ronald P. Regensburg]

@Ronald
I have appended "167" key.

The key works works fine now. Thanks

BTW, you can use "keycodes" file in SDL2 version, too.
A sample is macemu/BasiliskII/src/SDL/keycodes.

I have always used the original keycodes file, also in the SDL2 version.

[Elyus]

I couldn't reproduce the issue.
But I noticed display must be redrawn when palette is changed.
Is your problem resolved with new code?

Yes! That seems to have fixed it. It's strange no one else was experiencing it, but I'm happy it's fixed. Thank you! :D

[emendelson]

Also, BasiliskII can be built in same platforms. 64-bit JIT of BasiliskII is not implemented.

Hello again,

Probably this should be in the BasiliskII forum, but I knew that you visit here.

Your BasiliskII build is stable and fast. Thank you! Here is one request: the unix executable does not seem to work with the -config command-line parameter. I use an application that creates preference file, then launches the unix executable with the parameter --config prefsfilename

The --config option seems to be in the code (in main_unix.cpp) but the program doesn't use it - or at least I can't make this work.

This doesn't work with your build. It always opens the setup specified in ~/.basilisk_ii_prefs. Is it possible to fix this? Thank you again!

[kanjitalk755]

The --config option seems to be in the code (in main_unix.cpp) but the program doesn't use it - or at least I can't make this work.

Fixed.

[emendelson]

The --config option seems to be in the code (in main_unix.cpp) but the program doesn't use it - or at least I can't make this work.

Fixed.

Perfect! Thank you!

[Ronald P. Regensburg]

@ kanjitalk755

It appears that another key is not working properly in SheepShaver 2.5:
The Caps Lock key behaves as the shift key, you need to keep it pressed to type capital letters.

Shall I perform the same debug procedure as with the previous failing key?

Edit: The sdl2 port of BasiliskII has the same issue.

[kanjitalk755]

It appears that another key is not working properly in SheepShaver 2.5:
The Caps Lock key behaves as the shift key, you need to keep it pressed to type capital letters

I have fixed the issue, but it is incomplete.

The LED status of caps lock key may reflect to uppercase/lowercase incorrectly.

[Ronald P. Regensburg]

It appears that another key is not working properly in SheepShaver 2.5:
The Caps Lock key behaves as the shift key, you need to keep it pressed to type capital letters

I have fixed the issue

Thanks again.

but it is incomplete.
The LED status of caps lock key may reflect to uppercase/lowercase incorrectly.

This only happens when SheepShaver (and BasiliskII) is started with the LED on (uppercase status). One press on the caps lock key suffices to make it work as expected and uppercase/lowercase typing then continues to reflect the LED status indication correctly.

Do you know if the SDL 1.2 versions somehow read the caps lock status when the apps are launched?

[kanjitalk755]

Do you know if the SDL 1.2 versions somehow read the caps lock status when the apps are launched?

On launching, the SDL1.2 generates a keydown event of caps lock if necessary.
But the SDL2.0 doesn't.
I tried similar action as SDL1.2, but failed.