Not familiar there, but I guess you can select the machine in the tabs and open the rom/image from the menu “File/Open”?
You showed an image of the Qt version of ClockSignal. Therefore, I assume, you built it (so you know how to) and messed with it, even just briefly, so you’d likely know something about what does what or where stuff goes.
Building it was easy, using it is another thing as I’m not familiar with the application (tried a few roms grabbed from slackware, but had no real luck on booting anything, but that could be me) 
If you want to make the Qt window, go to OSBindings/Qt then type qmake then make.
ClockSignal expects to find system ROMs in /usr/local/share/CLK or /usr/share/CLK. Haiku does not have /usr/local so you’ll need to modify the source to change what directory it looks in.
For SDL2, that’s in main.cpp around line 700. I don’t know where it is for the Qt version (might be the same place, as I don’t know if the Qt is just the interface or the whole program).
I have to be honest, though, and say if you want ST emulation, use Hatari. i just tried the Qt version to start the ST emulation, and it won’t accept anything except the UK version of TOS 1.00.
1 Like
I’m assuming it doesn’t care which regional version you use (UK, US, etc.) as long as you name it TOS100.img. I’ll try it sometime when I’m done experimenting with SDL2 in other OS’s (having no luck in Ubuntu Jellyfish; nothing I install runs!) trying to see if my Pentium G4560 is at all the cause of such horrible emulator performance in ClockSignal.
Does Haiku still use Mesa for OpenGL rendering (software rendering, obviously)?
Ok, I just ran NeverBall… which uses SDL2/OpenGL and the exact same thing happened. So, at least we know now that it’s either OpenGL (Mesa) and/or SDL2 that is causing the massive CPU hoggage and core bouncing. But since GLTeapot does NOT do this (unless it’s just the fact that it’s framerate throttled via Vertical Sync), then we know it’s not Mesa either. Does SDL1 behave this way? I don’t recall this type of thing happening, when I was able to run Hatari. Now I can’t even get Hatari to run because I can’t figure out Libretro (no non-Libretro version of Hatari for Haiku exists anymore?). I can load the Hatari Core, but then what? I can specify a directory, but then can’t figure out how to get back to where I was… nothing I do will let me go back. So I just quit. Ugh…
Hatari and Atari800 both run fine for me. I had to build them from source, though, as I don’t care for RetroArch very much. And both detect joysticks, unlike the SDL2 stuff I’ve managed to get running.
1 Like
Can you show me how to build from source? I’ve done Haiku (several years ago) but not apps and games and such.
You can get Hatari from here
I used the git repository, but you should also be able to download the source for Hatari 2.4.1
I added these two lines to hatari/CMakeLists.txt at lines 164 and 165 (using Genio):
SET(GCC_COVERAGE_LINK_FLAGS "-lnetwork")
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${GCC_COVERAGE_LINK_FLAGS}")
Then, from the good old Terminal did:
./configure
make
That should do the trick. The executable will be in the src/ directory. If you try and run it from there, it’ll be looking for ‘tos.img’ to be in the same directory.
1 Like
Well, it worked! And Hatari doesn’t make the CPU go crazy, either, so I know it’s not Mesa or SDL2 causing ClockSignal to go crazy. That leaves only the main code (the general emulator, as the app itself freaks out the CPU, not a particular emulated environment (Apple II, Atari ST, etc.)). So, now the question is… how do we fix it? 
1 Like
I’m pretty sure Hatari uses SDL, not SDL2.
I did a bit of research and, from what I can tell, it uses SDL2 nowadays. Look through the version list. I saw several references of SDL2 mentioned and SDL1 being depreciated. Did I misread things?
I don’t know. I didn’t see anything in Hatari that specifically mentions SDL2. ClockSignal and Stella have includes for SDL2, whereas I only see an include for SDL on Hatari. But, given that I don’t actually know what I’m doing, that may not mean as much as I think it does.
I was mostly basing it on the fact that Hatari can see my joysticks where Stella (and, presumably, ClockSignal) do not. Since I’ve only seen that with SDL2 things, that’s where I was getting the idea that it used SDL and not SDL2.
I knew I wasn’t crazy… I went back and looked (emphasis mine, in bold):
2016-11-04: Version 2.0.0
Hatari 2.0.0 has been released. You can download it from http://download.tuxfamily.org/hatari/2.0.0
Many thanks to all the people who contributed to this version in different ways (code, bug report, testing, reverse engineering and documentation of the real HW, …), see doc/authors.txt for a list of devs / contributors.
Major highlights of this new version :
- Hatari can use SDL2, this will take advantage of HW acceleration on the host PC and greatly enhance perfomance on OSX for example
- Hatari now uses one single CPU core for all machines (ST, STE, TT, Falcon). No more need for 2 different binaries
- video emulation now supports the 4 STF wakeup states for MMU/GLUE and a much more accurate state machine for border removal
- CPU emulation was improved a lot by using WinUAE’s CPU and fixing some low level behaviour : IACK sequence, exception/interrupt stacking, 2 cycle accesses, bus accesses timing depending on memory region, instruction pairing, …
- Falcon DMA sound was fixed
- support for MegaST and MegaSTE machine types
- improvements to Gemdos HD emulation
- SDL UI reworked with more options
- resizable window when using SDL2 (using HW acceleration)
However, as for Haiku… this may NOT apply… how would we check/know? The CMake tool is just the compiler, right? The source code tells it what to do and how to assemble stuff, right? So, if you already have SDL2 installed, it should use it, right? I installed a bunch more SDL2 stuff to get ClockSignal to compile, so maybe I should recompile Hatari (with ALL the SDL2 stuff installed now) and see if there is any difference?
Interesting. I wonder what has to be done to get it to use SDL2? Not that I’m in any hurry to try to it. I guess I’ll have to look a bit more closely at the config stuff and see if it’s in there.
I wonder if someone could create a simple Test app that they could make two versions of for Haiku. One that specifically uses SDL 1.x exclusively and the other uses SDL 2.x exclusively.
Unless there is a way to change a given app like Hatari to specifically use SDL 1.x vs. SDL 2.x.
UPDATE! Found it? A simple application with SDL (1.2 and 2), to check whether it is working or not. · GitHub
Or this?: A SDL2 C++ test app · GitHub
You can use readelf from the binutils package to see what libraries are linked…
readelf -d /path/to/exe | grep NEEDED
or the lddtree command from the pax_utils package which uses readelf and gives nicer output
I found this when I did “lddtree” to the Hatari binary:
libSDL2-2.0.so.0 => /boot/system/lib/libSDL2-2.0.so.0
Just one line amidst a bazillion… but does that mean Hatari is defintely using SDL2 and not SDL1?
Well, readelf says my joystick using Hatari build is, indeed, using libSDL2. So that blows my theory on why Stella won’t see it.
I guess now I’ll have to see if I can get the PythonUI to work.
Anyway, I’m still thinking that ClockSignal’s ST emulation is wonky because it’s just “not there” yet.
Since SDL 1.2 is NOT binary compatible with SDL 2.x it is highly unlikely to be using SDL 1.2 at all.