open-apple key doesn't seem to work

[sh95014]

(Don't have a Raspberry Pi, this was observed in macOS)

sa2 UI:

1. Boot into the ProDOS system disk, with the tabbed card menu
2. At the bottom of the screen it says "(open-apple)? for Help".
3. Press the Option key and "?" (or "/" without also holding down Shift), nothing happens.

Probably not related, but looking at the code I don't see a SetButtonReleased() call for Paddle::ourOpenApple or Paddle::ourSolidApple.

[audetto]

You will have to debug

https://github.com/audetto/AppleWin/blob/0264538f4bb580976f36fd58417ef7d2678c0068/source/frontends/sdl/sdlframe.cpp#L472-L481

and

https://github.com/audetto/AppleWin/blob/0264538f4bb580976f36fd58417ef7d2678c0068/source/frontends/sdl/sdlframe.cpp#L536-L546

and see what events you receive. We can add a few duplicates if necessary.

[audetto]

1. Boot into the ProDOS system disk, with the tabbed card menu
2. At the bottom of the screen it says "(open-apple)? for Help".

which image please

[sh95014]

Oh lord I don't know how I missed those setButtonReleased() calls. Sorry for the noise, please ignore. 🤦‍♂️

It was https://mirrors.apple2.org.za/ftp.apple.asimov.net/images/masters/prodos/PRODOS-8%20v4.0.2%20System.dsk

[audetto]

Odd, it works for me. I just press Alt-/, without shift.

Does Open/Solid Apple works on your keyboard?

Try to start karateka and see if the character punches and kicks.

[sh95014]

Tried Karateka, and the keys do work. I'll dig into it a bit now that you've confirmed it's a macOS issue.

[sh95014]

Figured it out. On some keyboard layouts (I think US International is the specific culprit here) the Alt/Option key is used to modify the character sent to the application. In this specific case, Option-? doesn't send '?' with the "option" modifier bit set, but just sends '÷'!

So the fix to this specific problem is simple enough:

diff --git a/source/frontends/sdl/sdlframe.cpp b/source/frontends/sdl/sdlframe.cpp
index dfb6448f..d54b208d 100644
--- a/source/frontends/sdl/sdlframe.cpp
+++ b/source/frontends/sdl/sdlframe.cpp
@@ -85,6 +85,17 @@ namespace
         ch = 0x09;
         break;
       }
+    case SDLK_SLASH:
+      {
+        if (SDL_GetModState() & KMOD_SHIFT) {
+          ch = 0x3F;  // '?'
+        }
+        else
+        {
+          ch = 0x2F;  // '/'
+        }
+        break;
+      }
     case SDLK_a ... SDLK_z:
       {
         // same logic as AW

but does not solve the problem in general. For example, option-W would send '∑' instead of having the paddle button down with a 'W'. I don't think there's a fix without mapping the full keyboard. I'll propose something.

[sh95014]

Unfortunately, I've gotten stuck. The problem in SDLFrame is that the modified character ('÷' for Option-'?', for instance) is correctly being filtered out by SDLFrame::ProcessText because it's nonsense, but to intercept Option-'?' in SDLFrame::ProcessKeyDown would require us to know what the Shift modification would do. In the code snippet above, we assume that Shift-'/' is '?' but that's not guaranteed.

MacOS actually has an API called charactersIgnoringModifiers that I've switched to in my keyboard implementation, but I don't think SDL provides it. From my experiments, SDL_KeyboardEvent's keysym.sym returns the same value whether or not Shift is held down, whereas what we needed was for '1' to return '1' but Shift-'1' to return '!' or whatever is correct on that keyboard like charactersIgnoringModifiers does. SDL1 seemed to have offered a solution but that seems to have disappeared now in SDL2 and I'm not sure how accurate it ever was anyway.

So possible broader fix would be to intercept all the Apple //e physical keys, and assume the shift modification but maybe allow the user to remap. I'm not too familiar with SDL so maybe you know of another solution.

[audetto]

I could ignore all ASCII values (i.e. SDL_TextInputEvent) and handle everything in processAppleKey.

• we would need a mapping table
• able to match exactly the layout of the Apple ][ keys
• but, make it harder for people to type non letters as the location of (let's say '$') on your keyboard might not be the same as the original Apple ][

In the end I opted for a logical layout where keys are where the appear and not where they used to be on the Apple ][. But you might want to disagree. We could even have a runtime switch for this.

Back to your problem, why dont you add PgUp and PgDown as aliases of Alt? Or if you have 2 more keys on your keyboard which are currently unused?

[sh95014]

No, I agree with your logical layout, I think the other way would be painful for users.

Laptop users won't have PgUp and PgDn (or any other keys than the function keys) to steal, plus if it's not a proper modifier key there might be more complications with auto-repeat and such. Unless you end up with a lot of macOS users it's probably not worth the effort. There appears to be a workaround to disable the behavior at a system-level as well.

[audetto]

Can I close it?

[sh95014]

Sure, I don’t think there’s a reasonable fix at the moment without SDL providing charactersIgnoringModifiers.