[UtD] ARAnyM miniPack

[Francois LE COAT]

Hi,

ARAnyM http://aranym.github.io/ is the GNU/GPL ATARI Virtual Machine
from which a minimal configuration, the *miniPack* is distributed
http://eureka.atari.org/miniPack.zip miniPack is modified in its
configuration (faster). It supports :

`Run_win` allows launching on PC with Windows
`MacAranym` allows launching on MacARM with macOS
`MacAranym JIT` allows launching on MacIntel with macOS
`run_x86.sh` allows launching on PC with x86-Linux
`run_ppc.sh` allows launching on Mac _and_ PS3 with PPC-Linux
`run_arm.sh` allows launching on Raspberry Pi with ARM-Linux

So Macintosh-PC-PlayStation3-RaspberryPi are all supported with
Windows, macOS and GNU/Linux.

This simple ARAnyM configuration is running on any machine.
Here is a video https://www.youtube.com/watch?v=uA20AhHiKc4

Merry Christmas.

Enjoy, it's yours =)

--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org/

[Blast!]

thanks

[Francois LE COAT]

Hi,

When I run the miniPack under macOS Mojave all is correct like in:

https://www.youtube.com/watch?v=uA20AhHiKc4

But when I run it from macOS Catalina, it fails. I mean if I launch
`MacAranym JIT.app` all is running alright like under macOS Mojave.
But if I launch `MacAranym.app` (no JITc) ARAnyM is not finding
the "./Aranym_files" folder in the local path. This binary is from:
<https://dwww.xn--donz-epa.ch/atari/software/macaranym/aranym-1.1.0+git-macosx-arm64_x86_64_20221003.dmg>
Can somebody confirm the issue, with Catalina or more recent macOS?

Thanks,

Francois LE COAT writes:
> ARAnyM http://aranym.github.io/ is the GNU/GPL ATARI Virtual Machine
> from which a minimal configuration, the *miniPack* is distributed
> http://eureka.atari.org/miniPack.zip miniPack is modified in its
> configuration (faster). It supports :
>
> `Run_win` allows launching on PC with Windows
> `MacAranym` allows launching on MacARM with macOS
> `MacAranym JIT` allows launching on MacIntel with macOS
> `run_x86.sh` allows launching on PC with x86-Linux
> `run_ppc.sh` allows launching on Mac _and_ PS3 with PPC-Linux
> `run_arm.sh` allows launching on Raspberry Pi with ARM-Linux
>
> So Macintosh-PC-PlayStation3-RaspberryPi are all supported with
> Windows, macOS and GNU/Linux.
>
> This simple ARAnyM configuration is running on any machine.
> Here is a video https://www.youtube.com/watch?v=uA20AhHiKc4
>
> Merry Christmas.
>
> Enjoy, it's yours =)

Happy New Year 2023!

[Philipp Donzé]

Hi François

I do not have a system to test as I’m fully moved to Apple Silicon since some time… and macOS Catalina is also old by now.

Try running the MacAranym from „Terminal“ so we get the log out put to check for error messages or hints.

Something like the following:

Test % ./MacAranym.app/Contents/MacOS/MacAranym

ARAnyM 1.1.0 2022/10/03 (git:e3f82365)

Using config file: '/Users/philipp/Test/Aranym_files/config'

Using video driver cocoa

Using audio driver coreaudio

ETH0: unsupported type 'ptp'

Could not open joystick 0

OS ROM image '/Users/philipp/Test/Aranym_files/ROM' not found.

EmuTOS 2022/08/16 loading from '/Users/philipp/Test/Aranym_files/emutos-aranym.img'... [OK]

EmuTOS version 1.2.1 

unit 18 is managed by NatFeats: Master

hda:  Non-ATARI root sector

Floppy read(-1, 001004, 1) failed.

NF BOOTSTRAP_ARGS()

NF BOOTSTRAP(/Users/philipp/Test/Aranym_files/mintara.prg -> $00014f94, 14225516)

NF BOOTSTRAP($00014f94, 14225516) -> 0

VDI video mode = 640x480 1-plane

Perhaps it’s also some issue with the „Privacy and Security“ setting? So you could check the system preferences too whether MacAranym has the appropriate access, e.g. if the test folder is within the „Downloads“ folder.

Kind regards

Philipp

--
You received this message because you are subscribed to the Google Groups "ARAnyM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aranym+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/aranym/16b0aaf6-5ffe-33c4-d6f6-bce0904e413a%40gmail.com.

[Francois LE COAT]

Hi Philipp,

If you tell us that you can't test under macOS Catalina, does it mean
that ARAnyM miniPack is running directly on your macOS version, just
unzipping it on the desktop folder? Is it running or not?

Because when I unzip the ARAnyM miniPack on the desktop, and try to
launch it from the terminal, I have the attached "catalina.txt" report,
and the display in the attached "catalina.gif" image.

The configuration that exists in "./Aranym_files" is not detected.
Can you reproduce such an issue, with your macOS version on your Mac?

Thanks to confirm.

Best regards,

[Francois LE COAT]

Hi Philipp,

If I run it from the miniPack folder, I have a "Segmentation fault":

"
% ./MacAranym.app/Contents/MacOS/MacAranym
ARAnyM 1.1.0 2022/10/03 (git:e3f82365)

Using config file: '/Users/admin/Desktop/miniPack/Aranym_files/config'

Using video driver cocoa
Using audio driver coreaudio
ETH0: unsupported type 'ptp'
Could not open joystick 0

OS ROM image '/Users/admin/Desktop/miniPack/Aranym_files/ROM' not found.
EmuTOS 2022/08/16 loading from
'/Users/admin/Desktop/miniPack/Aranym_files/emutos.img'... [OK]
EmuTOS version 1.2.1
Segmentation fault
"
Can you confirm if the ARAnyM miniPack is running or not?

Best regards,

Francois LE COAT wrote:
> If you tell us that you can't test under macOS Catalina, does it mean
> that ARAnyM miniPack is running directly on your macOS version, just
> unzipping it on the desktop folder? Is it running or not?
>
> Because when I unzip the ARAnyM miniPack on the desktop, and try to
> launch it from the terminal, I have the attached "catalina.txt" report,
> and the display in the attached "catalina.gif" image.
>
> The configuration that exists in "./Aranym_files" is not detected.
> Can you reproduce such an issue, with your macOS version on your Mac?
>
> Thanks to confirm.
>

[Francois LE COAT]

Hi Philipp,

If I run `MacAranym JIT.app` instead of `MacAranym.app` all is fine:
"
% ./MacAranym\ JIT.app/Contents/MacOS/MacAranym\ JIT
ARAnyM 1.1.0
Using config file: '/Users/admin/Desktop/miniPack/Aranym_files/config'
BPF(0): unsupported type 'ptp'

Could not open joystick 0
OS ROM image '/Users/admin/Desktop/miniPack/Aranym_files/ROM' not found.
EmuTOS 2022/08/16 loading from
'/Users/admin/Desktop/miniPack/Aranym_files/emutos.img'... [OK]

NF_CONFIG not available
NF_CONFIG not available

unit 18 is managed by NatFeats: Master

hda: GEM
NF BOOTSTRAP_ARGS()
NF BOOTSTRAP(/Users/admin/Desktop/miniPack/Aranym_files/mintara.prg ->
$0100010c, 67108852)
NF BOOTSTRAP($0100010c, 67108852) -> 0
realloc_region: reg = 0, newsize 153600
realloc_region: reg is NULL
pid 0 (MiNT): FAT-FS [C]: WARNING: mounting unchecked fs, running
dosfsck is recommended
pid 0 (MiNT): Found MiNT 1.18 with kerinfo version 2
pid 0 (MiNT): arafs: Dcntl(FS_INSTALL) descr=4FD
pid 0 (MiNT): arafs: Dcntl(FS_MOUNT) dev_no: 256
pid 0 (MiNT): arafs.c: init
pid 0 (MiNT): arafs: ok (dev_no = 0)
pid 0 (MiNT): arafs: ara_root E_OK (256)
pid 0 (MiNT): arafs: __creat: enter
pid 0 (MiNT): arafs: __dir_search: search: 'clipbrd'
pid 0 (MiNT): arafs: __dir_search: compare 'clipbrd' with: '.',next=25E3A4
pid 0 (MiNT): arafs: __dir_search: compare 'clipbrd' with: '..',next=0
pid 0 (MiNT): arafs: __dir_search: return NULL
pid 0 (MiNT): arafs: ara_lookup: 'clipbrd'
pid 0 (MiNT): arafs: __dir_search: search: 'clipbrd'
pid 0 (MiNT): arafs: __dir_search: compare 'clipbrd' with: '.',next=25E3A4
pid 0 (MiNT): arafs: __dir_search: compare 'clipbrd' with:
'..',next=25E434
pid 0 (MiNT): arafs: __dir_search: compare 'clipbrd' with:
'clipbrd',next=0
pid 0 (MiNT): arafs: __dir_search: return 25E434
pid 0 (MiNT): arafs: __dir_search(clipbrd): f=25E434
pid 0 (MiNT): arafs: ara_lookup : return E_OK
pid 0 (MiNT): arafs: __creat: enter
pid 0 (MiNT): arafs: __dir_search: search: 'scrap.txt'
pid 0 (MiNT): arafs: __dir_search: compare 'scrap.txt' with:
'.',next=25E404
pid 0 (MiNT): arafs: __dir_search: compare 'scrap.txt' with: '..',next=0
pid 0 (MiNT): arafs: __dir_search: return NULL
pid 0 (MiNT): arafs: __unlink_cookie: nlink > 0, inode not deleted
pid 0 (MiNT): block_IO []: ../block_IO.c, 1477: Specified cache size
too small (0).
pid 1 (xaloader): run_km(xaaes040.km) ok (bp 0x4F22160)!
pid 1 (xaloader): run_km: run=0x4F22260
pid 17 (desktop): arafs: ara_root E_OK (256)
"
You can see it in the attached "catalina.gif" image :-)

Can you confirm you are able to launch ARAnyM miniPack on your Mac?

[Francois LE COAT]

Hi Philipp,

If I run the previous release you made: ARAnyM 1.1.0 2022/10/03
(git:e3f82365) there was no "Segmentation fault", it was fine:

"
% ./MacAranym.app/Contents/MacOS/MacAranym
ARAnyM 1.1.0 2022/10/03 (git:e3f82365)
Using config file: '/Users/admin/Desktop/miniPack/Aranym_files/config'
Using video driver cocoa
Using audio driver coreaudio
ETH0: unsupported type 'ptp'
Could not open joystick 0
OS ROM image '/Users/admin/Desktop/miniPack/Aranym_files/ROM' not found.
EmuTOS 2022/08/16 loading from
'/Users/admin/Desktop/miniPack/Aranym_files/emutos.img'... [OK]
EmuTOS version 1.2.1

unit 18 is managed by NatFeats: Master
hda: GEM
NF BOOTSTRAP_ARGS()
NF BOOTSTRAP(/Users/admin/Desktop/miniPack/Aranym_files/mintara.prg ->
$0100010c, 67108852)
NF BOOTSTRAP($0100010c, 67108852) -> 0
realloc_region: reg = 0, newsize 153600
realloc_region: reg is NULL
pid 0 (MiNT): FAT-FS [C]: WARNING: mounting unchecked fs, running
dosfsck is recommended
pid 0 (MiNT): Found MiNT 1.18 with kerinfo version 2
pid 0 (MiNT): arafs: Dcntl(FS_INSTALL) descr=4FD
pid 0 (MiNT): arafs: Dcntl(FS_MOUNT) dev_no: 256
pid 0 (MiNT): arafs.c: init
pid 0 (MiNT): arafs: ok (dev_no = 0)
pid 0 (MiNT): arafs: ara_root E_OK (256)
pid 0 (MiNT): arafs: __creat: enter
pid 0 (MiNT): arafs: __dir_search: search: 'clipbrd'

pid 0 (MiNT): arafs: __dir_search: compare 'clipbrd' with: '.',next=249694

pid 0 (MiNT): arafs: __dir_search: compare 'clipbrd' with: '..',next=0
pid 0 (MiNT): arafs: __dir_search: return NULL
pid 0 (MiNT): arafs: ara_lookup: 'clipbrd'
pid 0 (MiNT): arafs: __dir_search: search: 'clipbrd'

pid 0 (MiNT): arafs: __dir_search: compare 'clipbrd' with: '.',next=249694

pid 0 (MiNT): arafs: __dir_search: compare 'clipbrd' with:

'..',next=249724

pid 0 (MiNT): arafs: __dir_search: compare 'clipbrd' with:
'clipbrd',next=0

pid 0 (MiNT): arafs: __dir_search: return 249724
pid 0 (MiNT): arafs: __dir_search(clipbrd): f=249724

pid 0 (MiNT): arafs: ara_lookup : return E_OK
pid 0 (MiNT): arafs: __creat: enter
pid 0 (MiNT): arafs: __dir_search: search: 'scrap.txt'
pid 0 (MiNT): arafs: __dir_search: compare 'scrap.txt' with:

'.',next=2496F4

pid 0 (MiNT): arafs: __dir_search: compare 'scrap.txt' with: '..',next=0
pid 0 (MiNT): arafs: __dir_search: return NULL
pid 0 (MiNT): arafs: __unlink_cookie: nlink > 0, inode not deleted
pid 0 (MiNT): block_IO []: ../block_IO.c, 1477: Specified cache size
too small (0).
pid 1 (xaloader): run_km(xaaes040.km) ok (bp 0x4F22160)!
pid 1 (xaloader): run_km: run=0x4F22260
pid 17 (desktop): arafs: ara_root E_OK (256)
"
You can see it in the attached "catalina.gif" image :-)

There is an issue with:
<https://www.xn--donz-epa.ch/atari/software/macaranym/aranym-1.1.0+git-macosx-arm64_x86_64_20221003.dmg>

Can you confirm?

[Philipp Donzé]

Hi François

No, I haven’t tested miniPack on my system before, but I will do it now and document it below.

I’m trying to run on Apple Silicon MacBook Pro under macOS Ventura 13.1.

1. So, I downloaded the minipack, unzipped it into the Downloads folder and double clicked it to launch.

==> Warning that the app is coming from the Internet and couldn’t be searched for malware.

==> No way to launch it as the only options are „Move to Bin“ or „Cancel" 

Right-click/context action on the app and launch choose „Open“ to launch it.

==> Again a warning, but now I have the option „Open“.

Still the app does not launch. It doesn’t find the local configuration.

The think is: We have downloaded the pack from the internet! All files are „quarantined“ (which can be verified using "ls -l@"

% ls -l@ miniPack

total 56

drwxrwxrwx@  9 philipp  staff   288 21 Dez 16:09 Aranym_files

com.apple.quarantine  57 

drwxr-xr-x@  3 philipp  staff    96 14 Apr  2019 MacAranym JIT.app

com.apple.quarantine  57 

drwxr-xr-x@  3 philipp  staff    96  3 Okt 19:22 MacAranym.app

com.apple.quarantine  57 

-rwxrwxrwx@  1 philipp  staff  2960 21 Dez 16:10 README_LINUX.rtf

com.apple.quarantine  57 

-rwxrwxrwx@  1 philipp  staff  3985 21 Dez 16:10 README_MACOS.rtf

com.apple.quarantine  57 

-rwxrwxrwx@  1 philipp  staff  2721 21 Dez 16:11 README_WINDOWS.rtf

com.apple.quarantine  57 

drwxrwxrwx@ 14 philipp  staff   448 29 Apr  2020 bin

com.apple.quarantine  57 

-rwxrwxrwx@  1 philipp  staff    45 30 Apr  2020 run_arm.sh

com.apple.quarantine  57 

-rwxrwxrwx@  1 philipp  staff    45 30 Apr  2020 run_ppc.sh

com.apple.quarantine  57 

-rwxrwxrwx@  1 philipp  staff    50  9 Jun  2019 run_win.bat

com.apple.quarantine  57 

-rwxrwxrwx@  1 philipp  staff    45 30 Apr  2020 run_x86.sh

com.apple.quarantine  57 

To clear the quarantine flag we can use the following command:

xattr -d -rs com.apple.quarantine miniPack

Now, the „Aranym_files“ folder and its content is not „contaminated“.

When I launch the app now it is asking me if I want to allow accessing the content of the "Downloads“ folder.

After granting access it is now loading the configuration from „Aranym_files“.

==> But the app is crashing with a "Segmentation fault"

Looking at the location, I see that it tries to load libGL during initialization of SDL:

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread

0   libGL.dylib                         0x1d015e540 glGetString + 12

1   SDL2                                 0x10533d8cc 0x10526c000 + 858316

2   SDL2                                 0x10533d70c 0x10526c000 + 857868

3   MacAranym                           0x104ad4660 HostScreenOpenGL::getBpp() + 44

4   MacAranym                           0x104bc6328 SDLGui_Init() + 260

5   MacAranym                           0x104a9b028 InitAll() + 440

==> Modifying the configuration does not work easily because the „Aranym_files/config“ is flagged as executable. (Otherwise TextEdit would open it for editing)

Solving this using the command:

chmod -x miniPack/Aranym_files/config

And then opening the configuration file in an editor to modify the OpenGL setting:

[OPENGL]

Enabled = No

==> Now starting MacAranym is working on my system.

As the quarantine flag is propagated from the downloaded miniPack.zip to all the files contained within.

I think by using a DMG (and even signing it with a valid developer certificate), you can avoid the files being „contaminated“ by the quarantine flags and that users have to go through a lot of „warnings“ about untrusted sources.

Kind regards

Philipp

--
You received this message because you are subscribed to the Google Groups "ARAnyM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aranym+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/aranym/e7d102b4-50d0-3a7f-015b-bc5097c7cf0a%40gmail.com.
<catalina.txt><catalina.gif>

[Francois LE COAT]

Hi,

I confirm that ARAnyM miniPack runs if we disable OpenGL. Here is
attached an image "catalina.gif" where it runs perfectly, disabling
OpenGL. You gave me the correct solution, Philipp, thanks :-)

In facts, I recently enabled OpenGL in the ARAnyM miniPack, only for
the last release, because graphic performances are much better. It
is quick to boot, and using ATARI system VDI layer is considerably
faster. But enabling OpenGL reveals an issue, I haven't thought about.

The ARAnyM miniPack is designed for many different platforms, so I
can't package it with .dmg. But I found that successfully download
the ZIP archive, is very dependent on the WEB browser you're using.

Do you know the iCab WEB browser, from Alexander Clauss ATARIan?

<http://www.icab.de/>

When using Chrome, Safari for instance, for downloading, the binary
that is obtained can't be launched normally. If you use iCab, the
binary is not altered. You could launch it normally, without any
warning message. This is not a problem with the miniPack only!

Do you think that enabling OpenGL could be done, correcting the
ARAnyM's code? Can we get rid of the "Segmentation fault"???

Many thanks for your work. That's helping a lot!

Best regards,

Philipp Donzé writes:
> Hi François
>

> No, I haven’t tested miniPack on my system before, but I will do it now
> and document it below.
>
> I’m trying to run on Apple Silicon MacBook Pro under macOS Ventura 13.1.
>
>
> 1. So, I downloaded the minipack, unzipped it into the Downloads folder
> and double clicked it to launch.
> ==> Warning that the app is coming from the Internet and couldn’t be
> searched for malware.
> ==> No way to launch it as the only options are „Move to Bin“ or „Cancel"
>
> Right-click/context action on the app and launch choose „Open“ to launch it.
> ==> Again a warning, but now I have the option „Open“.
>
> Still the app does not launch. It doesn’t find the local configuration.
>

[Philipp Donzé]

Hi François

I know that there are some browsers and tools which do not set the quarantine flag. But they are not standard. Safari and Chrome are.

And to be honest: I consider the quarantine flag a security feature, as it indicates to the user that something has been downloaded from the internet and therefore might not be „save“ for opening. He should reconsider whether a source was trust-worthy before opening it. In the end, what we are running in this virtual machine might, depending on the configuration (which he downloaded in this case!) access any file on his computer. Luckily macOS has built-in limitations to warn the user if an app accesses the „Documents“, „Downloads“ or „Desktop“ folder. But it would be much safer for the end-user if the app was fully sandboxed, so that the user can trust that it won’t tamper with any file he didn’t gave access to.

Sandboxing MacAranym would involve a lot of work (which very probably cannot be share with the other platforms). So there would be the „core ARAnyM“ and „MacAranym“. MacAranym adding some onboarding feature requesting the necessary accesses (e.g. to the Aranym_files folder, installing networking helper). As I’m only a casual C/C++ developer, this is not something I would think about writing in these languages. I prefer Swift and SwiftUI. SwiftUI which is more robust  in the latest macOS releases (11, 12 and 13) and even not available before macOS 10.15… as you see: all these developments will impact backward compatibility.

Kind regards

Philipp

-- 
You received this message because you are subscribed to the Google Groups "ARAnyM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aranym+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/aranym/a962cbb6-13bb-1416-6da0-4bc2f1891ede%40gmail.com.
<catalina.gif>

[Philipp Donzé]

Hi again

Do you think that enabling OpenGL could be done, correcting the
ARAnyM's code? Can we get rid of the "Segmentation fault"???

I was investigating the source of the crash yesterday evening and found that it occurs in

int HostScreenOpenGL::getBpp(void)

when calling

SDL_GL_GetAttribute(SDL_GL_BUFFER_SIZE, &bpp);

At this point, it tries to access libGL.dylib`glGetString

(lldb) bt

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3b0)

  * frame #0: 0x00000001d015e540 libGL.dylib`glGetString + 12

    frame #1: 0x0000000104d39db8 SDL2`___lldb_unnamed_symbol4375 + 684

    frame #2: 0x0000000104d39bf8 SDL2`___lldb_unnamed_symbol4375 + 236

    frame #3: 0x00000001040c3b68 MacAranym`HostScreenOpenGL::getBpp(this=0x000060000275f390) at hostscreen_opengl.cpp:314:2

    frame #4: 0x000000010422782c MacAranym`SDLGui_Init() at sdlgui.cpp:189:71

    frame #5: 0x0000000104057980 MacAranym`InitAll() at main.cpp:467:19

I tried replacing it with the value which has been set just a few lines before (=15). But then it simply crashed a few lines later

(lldb) bt

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3b0)

  * frame #0: 0x00000001d015e540 libGL.dylib`glGetString + 12

    frame #1: 0x0000000100392284 MacAranym`HostSurfaceOpenGL::calcGlDimensions(this=0x00006000035fc480, width=0x000000016fab1618, height=0x000000016fab1614) at host_surface_opengl.cpp:92:30

    frame #2: 0x0000000100392d58 MacAranym`HostSurfaceOpenGL::resize(this=0x00006000035fc480, width=624, height=416, force_recreate=true) at host_surface_opengl.cpp:203:2

    frame #3: 0x0000000100391ea0 MacAranym`HostSurfaceOpenGL::createTexture(this=0x00006000035fc480) at host_surface_opengl.cpp:67:2

    frame #4: 0x0000000100391e0c MacAranym`HostSurfaceOpenGL::HostSurfaceOpenGL(this=0x00006000035fc480, width=624, height=416, bpp=15) at host_surface_opengl.cpp:46:2

    frame #5: 0x0000000100391ee8 MacAranym`HostSurfaceOpenGL::HostSurfaceOpenGL(this=0x00006000035fc480, width=624, height=416, bpp=15) at host_surface_opengl.cpp:45:1

    frame #6: 0x0000000100394508 MacAranym`HostScreenOpenGL::createSurface(this=0x0000600002ec83c0, width=624, height=416, bpp=15) at hostscreen_opengl.cpp:489:33

    frame #7: 0x00000001004f7860 MacAranym`SDLGui_Init() at sdlgui.cpp:189:27

    frame #8: 0x000000010032799c MacAranym`InitAll() at main.cpp:467:19

It seems that there is an issue with the `glGetString` method.

According to my understanding (and I’m definitely not a dynamic library expert), the code is crashing in the „stub“ of the dynamic library.

As if the dynamic library was not properly load or is incomplete.

Any hints on how to debug this? It would also be interesting whether it is just glGetString or any other method of the dynamic library.

But currently I don’t know how to find this information.

Kind regards

Philipp

[Thorsten Otto]

On Sonntag, 8. Januar 2023 13:29:26 CET Philipp Donzé wrote:
> when calling
> SDL_GL_GetAttribute(SDL_GL_BUFFER_SIZE, &bpp);

Does it really make at big dfference whether you use the HostScreenOpenGL
driver or not? I remember that there could be a problem when trying to also
use the OpenGL natfeat (eg. Khronos makes use of this). Even if it works,
there might be a big performance issue, because the Natfeat driver has to
switch opengl context every time it is used, in order not to conflict with the
OpenGL context used by the HostScreen driver.

Maybe there is a similar issue when SDL already uses OpenGL.

But otherwise, glGetString is a core function that should even be present in
GLES contexts. If that dumps core, then there might be a problem with SDL.
What version did you install, and from what vendor? I usually prefer macports,
because homebrew does not provide universal binaries.

[Philipp Donzé]

Hi Thorsten

I don’t know what OpenGL brings in reality… but macOS still supports it/bridges it to metal on M1. So it might still be „supported" for some time.

I’m building currently with SDL 2.24.2. (SDL 1.x is not working anymore on recent macOS…)

As far as I know I have simply downloaded it from the release page on GitHub (https://github.com/libsdl-org/SDL/releases)

I did some googling for some hours and it seems the issue is that we are not creating an OpenGL context at all after opening the SDL window.

After adding two lines:

auto context = SDL_GL_CreateContext(window);

SDL_GL_MakeCurrent(window, context);

to "HostScreenOpenGL::setVideoMode(int width, int height, int bpp) everything seems to work. No more crashes on startup.

Surely I haven’t tested any natfeats so far… I’m not the right person to do it, as I haven’t the configuration/setup and not the time.

I’m wondering whether OpenGL ever worked for anybody using SDL 2 because I do not see where the OpenGL context would be created at all.

According to my understanding SDL doesn’t do it "on its own". But again: I’m not an SDL expert and I’m using just Google to find documentation and example snippets to learn from...

So if anybody would like to test SDL2 and OpenGL, I’ve created a branch with my fix, based on current master.

https://github.com/pd95/aranym/tree/fix-macOS-OpenGL-crash

Kind regards

Philipp

--
You received this message because you are subscribed to the Google Groups "ARAnyM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aranym+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/aranym/8671628.1NqXAcsZDX%40earendil.

[Francois LE COAT]

Hi Philipp,

If the correction to sources makes a working binary to MacAranym, it
must be what should be done, to avoid "Segmentation fault". In that
case, I would be very interested to get a working binary for the
ARAnyM miniPack, because for the moment, it's just crashing badly.

Would you release a new working binary, on your own page?

Thanks,

Best regards,

[Philipp Donzé]

Hi François

I put up a quick build of the fix for testing (=I didn’t add any info to my website, as I don’t consider this a regular build)

I didn't see any performance gains when enabling OpenGL and testing with Kronos... I would probably have to fiddle with tiny GL or so.

Kind regards

Philipp

[Francois LE COAT]

Hi Philipp,

Many thanks for that binary which is called "ARAnyM 1.1.0 2022/10/05 (git:424495c2)" as you can see in the attached "catalina.gif" image. This means it is running well under macOS Catalina, with no more trouble. If you can't see a difference between OpenGL enabled or not, that's probably because the MacAranym version is a non-JITc version, and that Just In Time compiler makes a lot of difference with the speed.

When I made the following video ...



https://youtu.be/uA20AhHiKc4

... I was using the `MacAranym JIT.app` version, and enabling OpenGL has been a considerable speedup. Otherwise, the demonstration video would have been too long, too slow, and I wouldn't have published it, indeed.

You're helping me a lot with the ARAnyM miniPack ! So, thanks again. You may test it under macOS Ventura. It is running alright :-)

Best regards,

Philipp Donzé wrote:

Hi François

I put up a quick build of the fix for testing (=I didn’t add any info to my website, as I don’t consider this a regular build)

I didn't see any performance gains when enabling OpenGL and testing with Kronos... I would probably have to fiddle with tiny GL or so.

Kind regards

Philipp

Francois LE COAT writes:

Hi Philipp,

If the correction to sources makes a working binary to MacAranym, it
must be what should be done, to avoid "Segmentation fault". In that
case, I would be very interested to get a working binary for the
ARAnyM miniPack, because for the moment, it's just crashing badly.

Would you release a new working binary, on your own page?

Thanks,

Best regards,

[Philipp Donzé]

Hi François

I’m happy to help. But to be honest, even when I run Eureka and do the Julia drawing as in your video, I perceive no speed difference between the MacAranym version without or with OpenGL enabled.

The calculations done are heavily FPU dependent… so I still do not see the benefit of OpenGL.

Further I tried upgrading to SDL 2.26.2 (=the latest framework version) and OpenGL didn’t work anymore :-)

So my fix is some temporary thing...

Kind regards

Philipp

Am 09.01.2023 um 20:16 schrieb Francois LE COAT <lec...@gmail.com>:

Hi Philipp,

Many thanks for that binary which is called "ARAnyM 1.1.0 2022/10/05 (git:424495c2)" as you can see in the attached "catalina.gif" image. This means it is running well under macOS Catalina, with no more trouble. If you can't see a difference between OpenGL enabled or not, that's probably because the MacAranym version is a non-JITc version, and that Just In Time compiler makes a lot of difference with the speed.

When I made the following video ...



https://youtu.be/uA20AhHiKc4

... I was using the `MacAranym JIT.app` version, and enabling OpenGL has been a considerable speedup. Otherwise, the demonstration video would have been too long, too slow, and I wouldn't have published it, indeed.

You're helping me a lot with the ARAnyM miniPack ! So, thanks again. You may test it under macOS Ventura. It is running alright :-)

Best regards,

Philipp Donzé wrote:

Hi François

I put up a quick build of the fix for testing (=I didn’t add any info to my website, as I don’t consider this a regular build)

I didn't see any performance gains when enabling OpenGL and testing with Kronos... I would probably have to fiddle with tiny GL or so.

Kind regards

Philipp

Francois LE COAT writes:

Hi Philipp,

If the correction to sources makes a working binary to MacAranym, it
must be what should be done, to avoid "Segmentation fault". In that
case, I would be very interested to get a working binary for the
ARAnyM miniPack, because for the moment, it's just crashing badly.

Would you release a new working binary, on your own page?

Thanks,

Best regards,

-- 
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org/

--
You received this message because you are subscribed to the Google Groups "ARAnyM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aranym+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/aranym/1fb9e473-341b-f9e1-35a6-e2b53bfe6e55%40gmail.com.
<catalina.gif>

[Francois LE COAT]

Hi,

When OpenGL is enabled, it makes a difference, because I use a natfeat VDI, which is hardware accelerated. That's what I suppose. Even if I'm not explicitly using OpenGL code in the ATARI application (Eureka 2.12), VDI graphics are faster on MacIntel.

If I use OpenGL code in the application (Eureka 2.12), it can be hardware accelerated or not. And even if OpenGL is not still supported with SDL2, I can use it with the ATARI code, and I do. The only drawback is it won't be accelerated by the hardware. That's not really worrying. We can't still take benefit from natfeat OSMesa with SDL2 ... But I'm not very often using it with ARAnyM.

The trouble was that I wanted to enable OpenGL for all the platforms, with the ARAnyM miniPack, for performances. But it was crashing with MacARM, and not with MacIntel.

So now all the platforms can benefit from OpenGL, and it is no more an issue with MacARM. Good work :-)

Thanks Philipp. You're working great.

Best regards,

Philipp Donzé wrote:

Hi François

I’m happy to help. But to be honest, even when I run Eureka and do the Julia drawing as in your video, I perceive no speed difference between the MacAranym version without or with OpenGL enabled.

The calculations done are heavily FPU dependent… so I still do not see the benefit of OpenGL.

Further I tried upgrading to SDL 2.26.2 (=the latest framework version) and OpenGL didn’t work anymore :-)

So my fix is some temporary thing...

Kind regards

Philipp

[Philipp Donzé]

Hi all

A follow up on this:

Further I tried upgrading to SDL 2.26.2 (=the latest framework version) and OpenGL didn’t work anymore :-)

So my fix is some temporary thing...

I think I found a definitive fix (=a robust implementation) to make OpenGL work with SDL2.

I’ve created pull request #100 with the relevant change for review and commenting:

And I put up some MacAranym binaries on my website for testing:

It would be great if somebody else could test the change and see if it breaks OpenGL on some other platform/system with SDL2.

Please let me know.

Best regards

Philipp

[Francois LE COAT]

Hi,

ARAnyM http://aranym.github.io/ is the GNU/GPL ATARI Virtual Machine
from which a minimal configuration, the *miniPack* is distributed

http://eureka.atari.org/miniPack.zip miniPack is modified with a fix
on the OpenGL option. It supports:

`Run_win` allows launching on PC with Windows
`MacAranym` allows launching on MacARM with macOS
`MacAranym JIT` allows launching on MacIntel with macOS
`run_x86.sh` allows launching on PC with x86-Linux
`run_ppc.sh` allows launching on Mac _and_ PS3 with PPC-Linux
`run_arm.sh` allows launching on Raspberry Pi with ARM-Linux

So Macintosh-PC-PlayStation3-RaspberryPi are all supported with
Windows, macOS and GNU/Linux.

This simple ARAnyM configuration is running on any machine.
Here is a video https://www.youtube.com/watch?v=uA20AhHiKc4

Happy New Year.

Enjoy, it's yours =)