Previous 2.6 on Debian - Black window

Was able to build Previous 2.6 on my Debian 11 machine. Window comes up, but it is just blank, nothing in the window. Any hints on what I could be missing?

These issues are always difficult to debug without a machine with the same OS. Unfortunately all I have is my Mac. Maybe someone with programming skills can try to fix the problem on an appropriate machine. The problem is most likely related to window and renderer initialization (SDL2) in fast_screen.c (Screen_Init() and repainter()).

Quote from: andreas_g on September 16, 2022, 03:56:02 AMThese issues are always difficult to debug without a machine with the same OS. Unfortunately all I have is my Mac. Maybe someone with programming skills can try to fix the problem on an appropriate machine. The problem is most likely related to window and renderer initialization (SDL2) in fast_screen.c (Screen_Init() and repainter()).

Ok, I'll dig into it later this evening. I had seen some people were saying they had built it sucessfully on Debian so I thought perhaps I was missing something. Then again, they said it compiled, not that it actually worked :-)

I can hear the emulator starting up. I think it is running its just that something is not right with the rendering. When you resize the window smaller you get repaints (in black) and then if you scale back to a larger size you stop getting repaints entirely.

I built the softfloat branch two days ago on a Pi 4 and I was getting good rendering.

@wizard how do you obtain the source code? I do

svn co https://svn.code.sf.net/p/previous/code/branches/branch_softfloat


Oops, softfloat r1170 will not build, same problem as I had on macOS (see other thread).
So, I built trunk r1156, that's fine.

@wizard when you run `Previous` from a terminal it prints messages, what do you get? Also, which desktop environment eg GNOME?

Quote from: pomosapien on September 17, 2022, 07:37:19 AMI built the softfloat branch two days ago on a Pi 4 and I was getting good rendering.

@wizard how do you obtain the source code? I do

Code Select Expand

svn co https://svn.code.sf.net/p/previous/code/branches/branch_softfloat


svn checkout https://svn.code.sf.net/p/previous/code/trunk previous-code

Quote from: pomosapien on September 17, 2022, 08:50:52 AM@wizard when you run `Previous` from a terminal it prints messages, what do you get? Also, which desktop environment eg GNOME?

I am running gnome, X windows server with latest Nvidia drivers

The terminal window starts with this:
SDL screen request: 1120 x 856 (windowed)
Init680x0() called
68040 MMU: TC=0000 enabled=0 page8k=0 PC=00000000
CPU cycleunit: 256 (0.500)
1872 CPU functions


I think the emulator is running, probably at the window for the menu. If I randomly press buttons, I here a beep and the loggin continues in the emulator. It's just the screen is black.

I read somewhere that the SDL renderer is not thread safe on all platforms, especially when using OpenGL. What happens if you replace the line
sdlRenderer = SDL_CreateRenderer(sdlWindow, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC);with
sdlRenderer = SDL_CreateRenderer(sdlWindow, -1, SDL_RENDERER_SOFTWARE | SDL_RENDERER_PRESENTVSYNC);in fast_screen.c?

Quote from: andreas_g on September 22, 2022, 01:08:03 AMI read somewhere that the SDL renderer is not thread safe on all platforms, especially when using OpenGL. What happens if you replace the line

Code Select Expand

sdlRenderer = SDL_CreateRenderer(sdlWindow, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC);with

Code Select Expand

sdlRenderer = SDL_CreateRenderer(sdlWindow, -1, SDL_RENDERER_SOFTWARE | SDL_RENDERER_PRESENTVSYNC);in fast_screen.c?

Window stays black, but now when you resize it crashes.
This is what the terminal says:
SDL screen request: 1120 x 856 (windowed)
Init680x0() called
68040 MMU: TC=0000 enabled=0 page8k=0 PC=00000000
CPU cycleunit: 256 (0.500)
1872 CPU functions
Previous: malloc.c:2379: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.

The crash is probably a bug in SDL or some routine of the OS. I'm afraid I have no idea why the screen is still black. As the emulator seems to run in the background it is most likely related to the screen drawing routine of SDL2/Linux.

Does the resolution need to match NeXT hardwares odd Fixed Resolution 1120 by 832 at 92 DPI ?  As this may be the original NeXT Colorstation Chipset software driver  https://www.nextcomputers.org/NeXTfiles/Docs/Hardware/nextstation_color.pdf  It also appears to be the same 1120 by 832 at 92 dpi with NeXT Monostations which are 2 bit grey scale , Simon may know for sure. :)

@Rob Blessin Black Hole
Yes, Black hardware did only support 1120 by 832 pixels. Therefore this resolution is hardcoded in the OS. There is no way to change it on black hardware.

@wizard
Is the issue with the black window still open?

Quote from: andreas_g on October 24, 2022, 01:17:33 AM@wizard
Is the issue with the black window still open?

Yeah, just did a svn checkout https://svn.code.sf.net/p/previous/code/trunk previous-code
built fine.  I launched Previous from a terminal and it seems to start up and stop. But you get a black screen. If you hit control-c or attempt to close the window, the emulator seems to progress further with logging text and your hear the NeXT "beep" sound. It seems like the emulator is running but you have a black screen. CPU is being hit pretty hard too. This is on Debian with NVIDIA drivers. I have some other apps that run SDL 2.0 fine on this system.

---

Okay, this might be a multi-threading issue. It seems some platforms do not support to run the renderer in a secondary thread. The problem is, that running it on the main thread steals lots of performance from the emulation itself. Swapping main and secondary thread is not easy either. I have to think about a proper solution. Can you send me an e-mail so I can reply with a patch to confirm my theory? Or just PM me your e-mail address.

Quote from: andreas_g on October 31, 2022, 09:04:26 AMOkay, this might be a multi-threading issue. It seems some platforms do not support to run the renderer in a secondary thread. The problem is, that running it on the main thread steals lots of performance from the emulation itself. Swapping main and secondary thread is not easy either. I have to think about a proper solution. Can you send me an e-mail so I can reply with a patch to confirm my theory? Or just PM me your e-mail address.

I started having similar issues like, black screen, ctrl+c on console makes the emulator progress but still black screen, or even the window not displaying, but present on the taskbar.

This may be related to wayland, as i can use Previous successfuly by running:
env - DISPLAY=:0 ./Previous

Maybe SDL is trying to render using wayland instead of X11, and there may be some incompatibility.

BTW, the trunk and branch_softfloat trigger some weird issue in my attempt at a linux port, where the emulation hangs immediately after linux boots and shows the prompt (the cursor should be blinking, but it freezes), without any message in the console. This is probably something that needs to be fixed on the linux side, but it doesn't hang so easily on branch_filesharing.

Hope this helps.

Does the black screen issue also occur on latest branch_softfloat? For the other problem I can't tell what might be wrong. If you have some skills with C and debugging maybe you can find the problem? There are debugging messages in the code that can be enabled individually.

Quote from: andreas_g on November 17, 2022, 03:11:09 AMDoes the black screen issue also occur on latest branch_softfloat? For the other problem I can't tell what might be wrong. If you have some skills with C and debugging maybe you can find the problem? There are debugging messages in the code that can be enabled individually.

I did a few tests with branch_softfloat, and when i start normally with ./previous, it seems to be using wayland, window is created but not displayed (shows in  alt+tab but you can't switch to it) and fails to use PulseAudio:

...
[SCC] Reset channel A
[SCC] Reset channel B
[KMS] Reset
[Sound] Initializing output device.
[Audio] Can't use audio: Could not connect PulseAudio stream
HANGS HERE ^

if i press ctrl+c, i can then switch to the Previous window, and it shows the message to quit. Then i can use it normally.

By running:
env - DISPLAY=:0 ./Previous
it looks like it's using X11 and i can use it normally, but the audio driver being used is ALSA which is different from above.

It might be some issue where audio is being initialized before the window, and hanging on pulseaudio failing.
Not sure why a different audio library is being used depending on wayland or X11.

Quote from: ramalhais on November 17, 2022, 12:39:27 PMBy running:
env - DISPLAY=:0 ./Previous
it looks like it's using X11 and i can use it normally,

Trying that I still get a black screen on my machine with NVIDIA drivers (Debian 11)
$DISPLAY=:0 environment variable is set anyway on my machine.

Quote from: wizard on November 17, 2022, 07:03:42 PMTrying that I still get a black screen on my machine with NVIDIA drivers (Debian 11)
$DISPLAY=:0 environment variable is set anyway on my machine.

The trick with that command is that it unsets all variables so that it won't use wayland, and then sets DISPLAY so that it uses X11/Xwayland.
have you tried pressing ctrl+c on the terminal where you launch Previous?

BTW, can you try branch_filesharing? That's the one that works best for me. I have built that both on ubuntu and fedora.

Quote from: ramalhais on November 21, 2022, 04:44:54 PMThe trick with that command is that it unsets all variables so that it won't use wayland, and then sets DISPLAY so that it uses X11/Xwayland.
have you tried pressing ctrl+c on the terminal where you launch Previous?

BTW, can you try branch_filesharing? That's the one that works best for me. I have built that both on ubuntu and fedora.

Ctrl-C will advance the emulator, but it is a black screen. Just tried with branch_filesharing
using  env - DISPLAY=:0 ./Previous

THe developer had sent me some fixes , so hopefully those will show up as those builds work for me.

I think it is time for a little clarification:
I am a hobbyist working on Previous for fun. I gladly share my work with the community in here and hope it is useful for some people. Anyway I do not have the capacity to provide extensive support for Previous. I do not earn any money with it and my time resources are limited. There are already thousands of working hours in this project.

Previous is developed and tested on macOS. So running Previous on macOS will provide the best experience and least bugs. Thanks to the help of many forum members Previous also runs on other platforms but due to the diversity of these platforms problems might occur on some systems. If I find the time I can help with debugging but the main work has to be done by the one experiencing the problem. If someome provides me with patches that fix specific problems, I'll apply them to the sources.

There is some new code in branch_softfloat (r1231) that is worth testing.

Quote from: andreas_g on November 25, 2022, 02:46:36 AMThere is some new code in branch_softfloat (r1231) that is worth testing.

Compiling works well except for the following:

• The header file history.h (included from src/debug/debugdsp.c) is missing (removing the include seems to solve this)
• libSDL2-2.26 or later is required to call SDL_GetWindowSizeInPixels in src/fast_screen.c (available in the latest Macports version)
  

However, I just noticed that the mouse is captured, but the mouse cursor does not move (in NeXTstep 3.3 as well as my bare metal test code https://github.com/michaelengel/Baremetal-NeXT). Previous thinks the mouse is captured and I can successfully uncapture it, but there's no reaction to mouse pointer movement. This is on Monterey 12.6.1/M1 Pro.

I think I found the problem. If fExp is == 1.0 in Main_HandleMouseMotion (main.c), then fDeltaX and fDeltaY are not being initialized. The attached diff fixes the problem for me.
previous_softfloat_r1231.diff.txt

Quote from: cuby on November 29, 2022, 04:41:14 PMI think I found the problem. If fExp is == 1.0 in Main_HandleMouseMotion (main.c), then fDeltaX and fDeltaY are not being initialized. The attached diff fixes the problem for me.
previous_softfloat_r1231.diff.txt

Thank you very much for debugging this! Obviously a stupid mistake by me. I'll add your patch later today.

Update: Patch is online (with some extensions).

Do you see it as a problem, that Previous requires the latest version of SDL2? Personally I always upgrade to the latest version immediately. It almost always has more bug fixes than regressions.

Quote from: andreas_g on November 29, 2022, 11:09:13 PMDo you see it as a problem, that Previous requires the latest version of SDL2? Personally I always upgrade to the latest version immediately. It almost always has more bug fixes than regressions.

On Debian this means that we have to compile and maintain SDL2 by ourselves, as the system versions are not very recent. For me this is fine, as I use my own compiled versions for Previous more or less from the beginning. But it might be some blocker for people who want to compile Previous on a vanilla Debian system and do not know how to provide newer lib.

BTW: thanks for the fix @cuby :)

Quote from: andreas_g on November 29, 2022, 11:09:13 PMThank you very much for debugging this! Obviously a stupid mistake by me. I'll add your patch later today.

Update: Patch is online (with some extensions).

Do you see it as a problem, that Previous requires the latest version of SDL2? Personally I always upgrade to the latest version immediately. It almost always has more bug fixes than regressions.

I think it would be nicer to have it compile or run with more common versions available in the latest distributions.
Maybe #ifdef the old/new code with SDL_VERSION_ATLEAST(X, Y, Z) (easiest way) or use SDL_GetVersion(&linked_time_version); so that the same binary can run on both old and new SDL2 shared libraries.

For example: I'm using Fedora35 with SDL2-2.24.0 and Ubuntu 22.10 with SDL2-2.24.0
Older versions of ubuntu have SDL2 2.0.8 up to 2.0.20

I'll make it depend on SDL 2.24.0. The earlier versions of SDL cause a serious problem while the application window is minimized (100% CPU and 100% GPU usage due to missing VSYNC).

Threaded renderer (faster but less compatible) is now a compile-time option. For now you need to disable it by editing CMakeLists.txt (set ENABLE_RENDERING_THREAD to 0). If someone knows how this can be simplified, please tell me.

The new code is in branch_softfloat (r1243). If you do not have SDL2 v2.26.0 or later you need to comment out line 354 in fast_screen.c (SDL_GetWindowSizeInPixels()). This will be fixed in the release. Now hopefully this resolves all those black screen issues.

In Previous v2.7 you can disable the threaded renderer using the configure script:
./configure --disable-rendering-thread
This should fix the problems with black windows.

Here's a patch for the dealing with the SDL version.
Tested on:
- Ubuntu 22.10 with SDL2 2.24.0
- Fedora 35 with SDL2 2.26.0

EDIT:
The latest version of the branch_softfloat fixes the issue i was having with the lockups. When i have time, i'll try to pinpoint which of the commits fixed it.