Sdltrs

[Jenz]

I'd be interested in fixing the bug in the floppy controller emulation and giving it a try.

Could you please share some details about this bug?

 

[dittman]

Could you please share some details about this bug?

I checked and your copy has the fix that Tim Mann added to xtrs. Look for my name (Eric Dittman) in the source to find the details.

I hadn't checked your source before as you took out the macOS support. If BartH's update was based on your source then it would be in there.

 

[Jenz]

I checked and your copy has the fix that Tim Mann added to xtrs.

Thanks for checking!

I hadn't checked your source before as you took out the macOS support. If BartH's update was based on your source then it would be in there.

"Only" the native GUI removed as it is dysfunctional on current versions of macOS. BartH ported my modified version of SDLTRS to the "Xcode" IDE.
It is still possible to build without "Xcode" on the command line (SDL2 and autoconf from https://brew.sh) by just running the "configure"-script or executing "make sdl2".

 

[gonk23]

Hi, I'm trying to get Jenz' version of SDLTRS working on macOS Catalina. Since there isn't a precompiled binary, I followed the process at https://gitlab.com/jengun/sdltrs/-/blob/master/BUILDING.md to build the macOS version, and it appears to build without any errors.

However when I go to run the compiled binary from the command line (i.e. using "./sdltrs") it just returns the error: "sdltrs fatal error: failed to initialize SDL: The video driver did not add any displays".

Any ideas what I'm doing wrong?

 

[Jenz]

However when I go to run the compiled binary from the command line (i.e. using "./sdltrs") it just returns the error: "sdltrs fatal error: failed to initialize SDL: The video driver did not add any displays". Any ideas what I'm doing wrong?

Thanks for the bug-report: you're doing nothing wrong This seems like an driver issue with SDL2 on macOS Catalina, unfortunately I cannot test it due to missing hardware, but can you please change line # 178 in the source file "main.c" from

if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_JOYSTICK | SDL_INIT_AUDIO | SDL_INIT_TIMER) != 0)

to

if (SDL_Init(SDL_INIT_EVERYTHING) != 0)

and try again?

I have to do this Apple stuff ...

 

[gonk23]

This works now. Thanks Jenz.

The "-fullscreen" option seems to have problems at the moment on the Mac. The screen goes black and the red LEDs appear about 1 quarter a screen height up from the bottom of the screen, and the emulator appears to work (e.g. I can hear a game's sound) but it just doesn't display anything (except for the LEDs). Command-tab doesn't allow me to switch to other Mac apps, and I have to command-Q to exit. If you or someone else doesn't beat me to it, I might have a look at the code to see if I can figure it out.

 

[Jenz]

This works now

Wow, didn't expect it to work ... But all the better: will change it like this ...

The "-fullscreen" option seems to have problems at the moment on the Mac.

That was expectable ... Please change line # 1350 in "trs_sdl_interface.c" to:

SDL_SetWindowFullscreen(window, fullscreen ? SDL_WINDOW_FULLSCREEN_DESKTOP : 0);

Thanks for the quick feedback!

 

[gonk23]

Thanks for your quick response! It's great having a cross-platform open source emulator that's being maintained.

Wow, didn't expect it to work ... But all the better: will change it like this ...

Ok, it looks like I may have lead you astray. I tried the "fixed" version again later today and it didn't work! I worked out that it only didn't work when I had my MacBook Pro connected to my external display and the MacBook was clamshelled (i.e. closed). It worked fine when using the MacBook without an external display. On a hunch, I wondered if it was something to do with a HiDPI hack I did to the external display configuration a while back, so I restored the external display to its native resolution. Sure enough it now works on the external display while clamshelled too. So it looks like SDL is having a problem with this HiDPI hack (i.e. nothing to do with sdltrs).

I rebuilt sdltrs using master commit f8b077a4 (i.e. the commit before you changed it to SDL_INIT_EVERYTHING) and that now works fine too. So it wasn't anything to do with that. I'll leave you to decide whether you want to revert that SDL_Init() change back or not. Sorry about that.

That was expectable ... Please change line # 1350 in "trs_sdl_interface.c" to:

Thanks, that behaves better now on a Mac because it sets up a new screen. I.e. it allows switching to other screens and apps without needing to quit sdltrs.

 

[gonk23]

Thanks, that behaves better now on a Mac because it sets up a new screen. I.e. it allows switching to other screens and apps without needing to quit sdltrs.

Actually, an unfortunate side-effect of using SDL_WINDOW_FULLSCREEN_DESKTOP (rather than SDL_WINDOW_FULLSCREEN) is that in full screen mode the emulation now appears smaller (same size as the windowed version). However "-scale" can be used to make it bigger.

 

[Jenz]

It's great having a cross-platform open source emulator that's being maintained.

Thanks, would be a shame if SDLTRS just "bit-rot" like this ... so I'll give it a try ...

... and that now works fine too. So it wasn't anything to do with that ... Sorry about that.

Don't worry, better on the "wrong track" than no report at all ... I leave it in ...

Actually, an unfortunate side-effect of using SDL_WINDOW_FULLSCREEN_DESKTOP (rather than SDL_WINDOW_FULLSCREEN) is that in full screen mode the emulation now appears smaller (same size as the windowed version). However "-scale" can be used to make it bigger.

Please checkout the SDL2 branch: https://gitlab.com/jengun/sdltrs/-/tree/sdl2
This branch contains only the SDL2 version of SDLTRS, but with "texture rendering support" (could be a little faster): changing line # 1323 in "trs_sdl_interface.c" to

SDL_WINDOW_HIDDEN|SDL_WINDOW_RESIZABLE);

lets you resize the window with the mouse ... at the moment these settings are not saved and some options reset the change ... that's why it still needs some work ...

 

[gonk23]

Please checkout the SDL2 branch: https://gitlab.com/jengun/sdltrs/-/tree/sdl2

I built sdl2trs, but when I ran it I got a segmentation fault. After a bit of investigating I found that in trs_screen_init() the SDL_GetWindowSurface() call was returning NULL and therefore "screen" was set to NULL which caused the segfault when SDL_MapRGB() was called later on. I called SDL_GetError() and it returned "No hardware accelerated renderers available". I googled this error message and found that in the call to SDL_CreateRenderer() by replacing the flag 0 (which apparently defaults to SDL_RENDERER_ACCELERATED) with SDL_RENDERER_SOFTWARE, this fixed the problem. I don't currently know enough about SDL renderers to know whether this is a good solution or not.

lets you resize the window with the mouse ... at the moment these settings are not saved and some options reset the change ... that's why it still needs some work ...

After getting the segmentation fault fixed, I added SDL_WINDOW_RESIZABLE and was able to get it to work. I like where this is heading, although the pixels can look odd at some sizes.

 

[Jenz]

SDL_GetWindowSurface() call was returning NULL and therefore "screen" was set to NULL which caused the segfault

I should always check for failed functions ...

SDL_CreateRenderer() by replacing the flag 0 (which apparently defaults to SDL_RENDERER_ACCELERATED) with SDL_RENDERER_SOFTWARE, this fixed the problem. I don't currently know enough about SDL renderers to know whether this is a good solution or not.

In my understanding, SDL should give priority to hardware acceleration and fallback to software rendering, but "SDL_GetWindowSurface" seems to be the problem: it should not be used with the rendering API. Because of my laziness, all TRS-80 characters are still "software surfaces" (not "textures") that are displayed on the "screen surface", which is then transferred to the renderer as texture ("SDL_UpdateTexture"). Seems to work (mostly), but mixes the old API for "software surfaces" with new one for "textures" ... therefore a revision is needed ...

I like where this is heading, although the pixels can look odd at some sizes.

That is the reason why the "SDL_WINDOW_RESIZABLE" is not set by default ...

 

[Jenz]

although the pixels can look odd at some sizes.

Please try this patch:

diff --git a/src/trs_sdl_interface.c b/src/trs_sdl_interface.c
index f911323..79ea7ae 100644
--- a/src/trs_sdl_interface.c
+++ b/src/trs_sdl_interface.c
@@ -1331,6 +1331,7 @@ void trs_screen_init(void)
       trs_sdl_cleanup();
       fatal("failed to create renderer: %s", SDL_GetError());
     }
+    SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear");
   }
 
   if (texture)

 

[gonk23]

I'm not seeing any difference when I resize the window with that patch, although I'm still using SDL_RENDERER_SOFTWARE, so I don't know if that affects it or not.

Interestingly, with or without that patch, when I resize the window just after loading sdl2trs, the resized version looks great when I'm actually resizing it, however when I release the mouse button that's when the pixels end up looking odd.

 

[Jenz]

I'm still using SDL_RENDERER_SOFTWARE, so I don't know if that affects it or not.

Please checkout the latest commit 5d9582e on the SDL2 branch: hopefully this will activate the hardware rendering on macOS ...

however when I release the mouse button that's when the pixels end up looking odd.

Maybe adding SDL_WINDOW_ALLOW_HIGHDPI to the SDL_CreateWindow flags will help ... can you send a screenshot?

 

[gonk23]

I tested sdl2 branch commit 5d9582e and that works unmodified on macOS. Thanks!

It must have also fixed the rendering problem on window resize because it looks great after I added the "SDL_WINDOW_RESIZABLE" and "SDL_HINT_RENDER_SCALE_QUALITY" patches to that commit.

As a bonus, the macOS green circle window button allows it to go into full screen mode (without specifying the sdl2trs "-fullscreen" option) although it's obviously stretched on widescreen monitors.

 

[Jenz]

I tested sdl2 branch commit 5d9582e and that works unmodified on macOS. Thanks!

You're welcome, testing and reporting is highly appreciated!

I added the "SDL_WINDOW_RESIZABLE" and "SDL_HINT_RENDER_SCALE_QUALITY" patches to that commit.

Added these changes also to latest SDL2 branch. No need for "SDL_WINDOW_FULLSCREEN_DESKTOP"?

As a bonus, the macOS green circle window button allows it to go into full screen mode (without specifying the sdl2trs "-fullscreen" option)

Doesn't "Alt-Enter" toggle full screen mode on macOS?

 

[gonk23]

Yes, "Alt-Enter" (or "option-return" on the Mac) does work. Its effect depends on the build:

(a) branch master 062bedc7 unmodified
Goes into a fullscreen mode which takes over the Mac and doesn't allow switching to other apps. It stops rendering to the screen, although it keeps responding to keyboard and playing sound (e.g. if a game). Pressing "option-return" again will restore to window mode however real-time rendering is still broken.

(b) branch master 062bedc7 with SDL_WINDOW_FULLSCREEN_DESKTOP
It correctly goes into a proper macOS fullscreen mode which allows switching to other apps/screens. However it doesn't scale to fit the screen, i.e. it returns to scale x1, so you only see the display in the top-left of the screen.

(c) branch sdl2 bd147276 unmodified
Goes into a fullscreen mode which takes over the Mac and doesn't allow switching to other apps. However it does keep real-time rendering to the screen. The aspect ratio is correct. Pressing "option-return" again will restore to window mode and rendering keeps working, although it sometimes puts the window in the bottom left of the desktop.

(d) branch sdl bd147276 with SDL_WINDOW_FULLSCREEN_DESKTOP
It correctly goes into a proper macOS fullscreen mode which allows switching to other apps/screens. There aren't any rendering problems. It scales to fit the ENTIRE screen, even if it means the aspect ratio is incorrect (i.e. it appears stretched). Pressing "option-return" again will restore to window mode and rendering keeps working, and it always puts the window back to the same size/position that it was before going into fullscreen mode.

So for macOS, I think it'll be better to use SDL_WINDOW_FULLSCREEN_DESKTOP, however it would be nice if it correctly scaled to both fill the screen AND keep the correct aspect ratio. Actually, keeping the correct aspect ratio would also be nice when resizing the window in window mode too.

 

[Jenz]

(b) branch master 062bedc7 with SDL_WINDOW_FULLSCREEN_DESKTOP
It correctly goes into a proper macOS fullscreen mode which allows switching to other apps/screens. However it doesn't scale to fit the screen, i.e. it returns to scale x1, so you only see the display in the top-left of the screen.

This also happens on some Linux systems with the software renderer. SDL_WINDOW_FULLSCREEN changes the graphic resolution, SDL_WINDOW_FULLSCREEN_DESKTOP just "expands" the window to fill the entire screen. The master branch sticks to the software renderer to ensure backwards compatibility with SDL 1.2 for ancient platforms ...

Actually, keeping the correct aspect ratio would also be nice when resizing the window in window mode too.

Please checkout commit 12d0881 on the SDL2 branch: this should keep the aspect ratio of the TRS-80 screen when resizing, but so called "letterboxing" will occur ...

 

[gonk23]

Please checkout commit 12d0881 on the SDL2 branch: this should keep the aspect ratio of the TRS-80 screen when resizing, but so called "letterboxing" will occur ...

Brilliant! This works well. The macOS native fullscreen mode (by clicking the green circle or pressing control-command-F) also works well.