Re: [hatari-devel] Troed's MacOS build

[Bob Carpenter <hatari@xxxxxxxxxx>]

Nicolas,

I do not see the problem when running Closure with SDL 2.0.5 and EmuTOS 0.9.6. I also tried TOS 1.04. However, I am not running an older version of MacOS. I am running MacOS Sierra (10.12) so my test is not valid since it looked like the problem occurred with older versions of MacOS (OS X).

Bob C

On Oct 24, 2016, at 1:56 PM, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:

Hi

Troed has some emails problem at the moment, so he asked me to forward his emails so people could download his OSX build and check if it works (note that he had some crashes with sdl 2.0.5 and Closure, do other people see this too ?)

Nicolas


---------- Forwarded message ----------

It seems my emails no longer reach the mailing list - I did find it strange that I got absolutely no replies to any of the below ... 

(Verified by going to the list archive on the web just now, none of them are there)

/Troed

---------- Forwarded message ----------
From: Troed Sångberg <tsangberg@xxxxxxxxx>
Date: Sun, Oct 23, 2016 at 6:39 PM
Subject: Re: [hatari-devel] Troed's MacOS build
To: hatari-devel@xxxxxxxxxxxxxxxxxxx

Alright, I'm just getting more and more confused. I've done a lot of testing with the RC1 build (SDL 2.0.5, "their" build script) I posted earlier. It crashes always/often (unsure if it's been exactly 100% or very close to it) in Closure at the start of the multi scroller screen - in ST mode. It does not seem to crash in STE mode. The code paths in the demo are extremely similar (sync scroll used also for STE) so already there it's pretty strange.

I have not been able to provoke a crash with anything else I've tested (mostly Union Demo and We Were @) - at all. 

I'm out of ideas. It seems to be an SDL2 issue - but caused somehow by the specific behaviour of Closure in ST mode. An also only on older versions of macOS ... so I can't really see this being a showstopper. But I would appreciate it if others test as well.

Btw Nicolas, the big y-swinging SYNC disting logo in the beginning of Closure shows two non-fullscreen lines at the bottom of the screen. I'm very surprised that I would've made such an error - is it possible Hatari is displaying 276 lines even though the VBLANK at line 274 should've kicked in? Needless to say, I don't see such non-fullscreen lines with my original Closure-disc on my STE with my Dell 2001FP with vpos set to show all (AFAIK) lines ... :P

/Troed

On Oct 22, 2016 11:35 PM, "Troed Sångberg" <tsangberg@xxxxxxxxx> wrote:

... and unfortunately I see the same crash even on a fully uptodate 10.6 system (10.6.8 or whatever the latest is, didn't check). I don't think this should stop us from making a release, since I don't know the cause, but it would be good to have more testing so as to understand what it is that works and what doesn't so that it could be put into release notes (my first guess, x64 is ok but i386 isn't, but I need to test more).

There's also a difference between the SDL 2.0.5 and 2.0.4 I built today compared to my earlier pre-release build with 2.0.4. This time I used clang and thus the proper fat-build script from the SDL project. Previously I used gcc and manual patching of their Makefile to create a fat binary. The manual-gcc version needs more work on dependencies (didn't work on the fresh 10.6 install).

/Troed

On Sat, Oct 22, 2016 at 2:28 PM, Troed Sångberg <tsangberg@xxxxxxxxx> wrote:

I made a new build with SDL 2.0.4 and I unfortunately get the exact same crash (this time I did get to see a few pixels of graphics from the loaded screen, first time the multi-scroll screen in Closure is shown, but I think it's the same crash otherwise. Same callstack, same kern invalid address).

Next up would be to update my 10.6 install to the last point release Apple made. Doing that now.

/Troed

On Sat, Oct 22, 2016 at 1:39 PM, Troed Sångberg <tsangberg@xxxxxxxxx> wrote:

Hmm.

So I created a brand new 10.6 install on my Macmini 2,1 (2GHz Core 2 Duo) - and was pleased to see that the build I just made started up immediately. That means all linking etc that I've taken care of to be compatible that far back work as it should.

However - when I then tested (using Closure of course, what else) the install something rather strange happened. A segfault directly after the vertical logo-scroll screen, when it has loaded the next screen and should just start executing it. I don't even know where to start debugging that (and I don't have much time available unfortunately) so I'd appreciate it if others could test on older macOS versions as well. This being a completely fresh install of course means no point upgrades of the OS have been done etc.

It was very speedy though, no performance issues neither windowed or fullscreen. 

I do not get the crash on my MBP on 10.11.6

/Troed

*) KERN_INVALID_ADDRESS at 0x11 in com.apple.main-thread, and at the top of that thread is SDL ... 

On Sat, Oct 22, 2016 at 11:35 AM, Troed Sångberg <tsangberg@xxxxxxxxx> wrote:

Hatari v2.0.0 macOS release candidate 1: https://troed.ddns.net/f/74192ceae6/

SDL 2.0.5, EmuTOS 0.9.6

If all textfiles are updated I can start putting together a release .dmg as well - let me know.

Note: SDL 2.0.5 no longer has support for OSX 10.5, only 10.6 and up. That's fine IMHO, while I did compile for 10.5+ before I'm not sure it was tested or used. I will dig out an old 10.6 machine later this weekend myself.

/Troed

On Sat, Oct 22, 2016 at 8:43 AM, Troed Sångberg <tsangberg@xxxxxxxxx> wrote:

Deadline? ;) But yes - the only slight unknown is the new SDL

/Troed

On Oct 21, 2016 22:30, "Nicolas Pomarède" <npomarede@xxxxxxxxxxxx> wrote:

Le 09/10/2016 à 22:36, Bob Carpenter a écrit :

I have run Troed’s MacOS (I guess I should call it that now) Hatari build. It looks good, but there was a problem that I forgot to mention to Jerome in the GUI. If you select Load Config from the File menu rather than using it from the Preferences dialog, you will get a message to reset the emulator. However, if you click on Reset, it does not reset Hatari but acts as if you had pressed Cancel and ignores your setting changes.

Also, I am thinking that View Tab Bar should be disabled in Hatari since it does work correctly at this time. In theory, it might be interesting to have several Hatari tabs available running different type of STs. However, all it does now is add an extra bar and no place to create a new tab. Therefore, I think simply disabling the option and eliminating questions is the way to go.

Bob C

Hi

I think current Hatari's code will be the one used for release and OSX UI code should be up to date.

Troed, would you have time to build an OSX binary, as the one you provided for the previous versions ?

Thanks

Nicolas