Messages

1

General Discussion / Re: OS/2 - ArcaOS Santa's List for 2025

« on: Today at 08:28:26 am »

What about mesaGL? I don't remember its current status. A slow renderer would still be better than no renderer at all...
Mentore

I visited it, seven years back, and got it compiling and the examples ran good. [https://github.com/OS2World/LIB-GRAPHICS-WarpMesaGL.
Problem is that it is old. Gives gl.h while now it is gl2.h that is required.

sh*t. I was hoping there was a better solution.
AFAIK also PortableGL has its limits (TinyGL is good but even more limited).

Mentore

2

General Discussion / Re: OS/2 - ArcaOS Santa's List for 2025

« on: December 06, 2024, 08:06:24 am »

OK, it uses GTK. That would be a huge job to port, much like Qt. While nice to have, I can't imagine it being ported.
It can also run in a browser, so that might be a possibility, though even for that there's a good chance it needs something we don't have, webgl or node.js.

Might be possile to use odin to build GTK - but if it needs opengl, etc we're royally screwed. nodejs is working well enough to build chromium....

What about mesaGL? I don't remember its current status. A slow renderer would still be better than no renderer at all...
Mentore

3

Games / Re: RetroArch Port

« on: November 26, 2024, 08:17:55 am »

Hello Mentore

Just one extra thing. can you put your ported version of RetroArch in some repository (like Github - https://github.com/MentoreSiesto?tab=repositories)
If possible I want to learn from your makefile, and I think it will be nice for everyone to check it out.

Regards

I'll check my sources and do that asap. One thing I need to put in my TODO list is to get those sources in my repositories, indeed.

Mentore

4

Games / Re: RetroArch Port

« on: November 19, 2024, 07:51:12 am »

Hi.

I did understand, that you disabled this stuff. My point was that you should not concern yourself to much, with getting this to work. Cores will be enough work by themselves ;-)

Right you are 

Mentore

5

Games / Re: RetroArch Port

« on: November 18, 2024, 10:51:44 am »

Well I understand, that on an RaspberryPi, you would want that functionality, but I would just #ifdef Discord out.
Downloading of cores would also mean, you or someone would have to host the OS/2 specific core files. I don't know that it would be worth the hassle.
Rather I would have some RPMs or WPIs, which install some cores.

Hi Jochen,
As written before I ruled out Discord and some other options because I hadn't the needed libraries/time to port them - can't remember well what were my choices (Yes I'm a little chaotic, I should document my steps when I make them).
So Discord and maybe some other options are missing.
As for cores, I'd like to understand better if they have to be ported - I guess the answer is "yes", so downloading them via our RetroArch port might be cumbersome if we would rely on the "official" repository.
Guess I'll have to investigate a little further - for now I am content of being able to port on OS/2 such a beast, but indeed at the moment is just useless - so better try to take a step further.

Mentore

6

Games / Re: RetroArch Port

« on: November 15, 2024, 11:05:16 pm »

Hi Martin,
the next few weeks will be truly a handful both at work (where I have an ArcaOS VM) and in theatre, but I'll see what I can do. RetroArch would be really cute to have. It was tricky to port it due to its SSL libraries which rely a lot on IPv6 but I managed somehow - and I feel OS/2 would profit a lot of a new TCP/IP stack (which, I'm afraid, we will not see).

Mentore

Which feature needs networking? Is it for downloading core etc.?

As far as I know it's not only for downloading cores but also for networked game and (not in this version) Discord chat. I couldn't implement Discord due to some libraries missing (don't remember the details right now).

Mentore

7

Games / Re: RetroArch Port

« on: November 15, 2024, 08:26:32 am »

Hello Mentore

I don't know if you can port some of the basic cores for NES and SNES that are very common and don't require a console BIOS to be downloaded by the user.

Regards

Hi Martin,
the next few weeks will be truly a handful both at work (where I have an ArcaOS VM) and in theatre, but I'll see what I can do. RetroArch would be really cute to have. It was tricky to port it due to its SSL libraries which rely a lot on IPv6 but I managed somehow - and I feel OS/2 would profit a lot of a new TCP/IP stack (which, I'm afraid, we will not see).

Mentore

8

Games / Re: RetroArch Port

« on: November 14, 2024, 07:45:12 am »

Hello

Mentore ported RetroArch (1.19.1) and I just noticed today, which is awesome.

I installed "yum install SDL2 SDL2_net" it runs but I don't know if the cores (emulators) need also to be ported, or it will be download the cores from a site.

I tried to download the Core list from the app, but it is not downloading. Remains in 0%.

Anyone here with more experience with RetroArch?

Regards

Hi Martin,
this I have to investigate deeper. I also tried to download some core and, looking at the RetroArch homepage, it almost seems like cores have to be ported too. I'll have a look at what retroarch cores are - but many things point me in that direction (last of them, there are github repositories for cores).

Mentore

9

Programming / Re: DOSBox-x - infinite loop in configure/make

« on: November 07, 2024, 07:51:49 am »

As an example. this code compiles fine with DosBox,

Code: [Select]

    FSINFO fsinfo;
    ULONG drivenumber = drive[0];
    if (drivenumber > 26) { // drive letter was lowercase
        drivenumber = drive[0] - 'a' + 1;
    }
    APIRET rc = DosQueryFSInfo(drivenumber, FSIL_VOLSER, &fsinfo, sizeof(FSINFO));
    if (rc == NO_ERROR) {
        bool cdrom = false;
Whereas with DosBox-x, the error is,

Code: [Select]

drive_cache.cpp: In member function 'void DOS_Drive_Cache::SetBaseDir(const char*, DOS_Drive*)':
drive_cache.cpp:159:32: error: cannot convert 'DOS_Drive' to 'ULONG' {aka 'long unsigned int'} in initialization
  159 |     ULONG drivenumber = drive[0];
      |                         ~~~~~~~^
      |                                |
      |                                DOS_Drive
drive_cache.cpp:161:32: error: no match for 'operator-' (operand types are 'DOS_Drive' and 'char')
  161 |         drivenumber = drive[0] - 'a' + 1;
      |                       ~~~~~~~~ ^ ~~~
      |                              |   |
      |                              |   char
      |                              DOS_Drive


Thanks a million for all of these contributions on your side, Dave. It seems DosBox-x is not viable - too bad, but hey, I did try at least
Now back to RetroArch. I'll try to delve deeper into the network part and see if I can go a little further than my first attempt (there are some interesting TLS libraries, I shall try them all).

Mentore

10

Programming / Re: DOSBox-x - infinite loop in configure/make

« on: November 06, 2024, 12:02:46 pm »

Better to edit configure.ac, about line 368 and remove the CXXFLAGS line, the -Zmt on the LDFLAGS line and add -Zomf -Zhigh-mem -Zbin-files there. There's also a hard dependency on sdl-net in configure.ac you might want to comment out.
Then run "bash autogen.sh" rather then sh autoreconf then try configure.
There's other emxism's in the source to watch out for as you go.

OK, tried to modify it and no - still loops; make keeps calling configure. I'll have to delve deeper into this.
Mentore

11

Programming / Re: DOSBox-x - infinite loop in configure/make

« on: November 06, 2024, 08:01:25 am »

Better to edit configure.ac, about line 368 and remove the CXXFLAGS line, the -Zmt on the LDFLAGS line and add -Zomf -Zhigh-mem -Zbin-files there. There's also a hard dependency on sdl-net in configure.ac you might want to comment out.
Then run "bash autogen.sh" rather then sh autoreconf then try configure.
There's other emxism's in the source to watch out for as you go.

You're a wonderful source of information, Dave.
On a side note - I've ported RetroArch (!!!) and it's basically working. Have to include network support (it seems heavily bound to IPv6, though) and Qt tools (already started, but there are some differences in the needed files which I didn't understand).

But - it - WORKS.

Mentore

12

Programming / Re: [SDL2] SDL_ListModes and emulation

« on: November 05, 2024, 11:09:09 am »

Looking at your package, fuse.exe uses SDL120.DLL

Checked. Indeed it is as you say.
Funnily, I tried to re-configure and make and, lo and behold, the configure script expects SDL 1.2.4 and reports an error. So it seems I can't compile it this time (the only difference being trying to include network support).

Mentore

13

Programming / DOSBox-x - infinite loop in configure/make

« on: November 05, 2024, 10:22:02 am »

Hello all,
I'm having a real PITA trying to port DosBox-x under OS/2 with the latest tool (Gcc 9.2.0, the rest is up-to-date with ANPM netlabs repo).

I've issued the usual autoreconf and given a detailed configure script call with these options

./configure --prefix=/DosBox-x --enable-sdl2 --enable-force-menu-sdldraw --disable-sdlnet --disable-opengl --disable-alsatest --disable-alsa-midi --disable-libslirp --disable-x11

But then I notice that the created makefile contains a lot of calls to am<things> (which should be autotools) and starts configuring again, everytime restarting all the process with these starting lines

CDPATH="${ZSH_VERSION+.};" && cd . && /usr/bin/sh D:/Sviluppo/Sorgenti/dbox/dosb
ox/missing aclocal-1.16
 cd . && /usr/bin/sh D:/Sviluppo/Sorgenti/dbox/dosbox/missing automake-1.16 --fo
reign
CDPATH="${ZSH_VERSION+.};" && cd . && /usr/bin/sh D:/Sviluppo/Sorgenti/dbox/dosb
ox/missing autoconf
/usr/bin/sh ./config.status --recheck
running CONFIG_SHELL=/usr/bin/sh /usr/bin/sh ./configure --prefix=/DosBox-x --en
able-sdl2 --enable-force-menu-sdldraw --disable-sdlnet --disable-opengl --disabl
e-alsatest --disable-alsa-midi --disable-libslirp --disable-x11 CC=gcc.exe CFLAG
S=-O2 -g -DOS2 LDFLAGS=-Zomf -Zhigh-mem -Zmap -Zbin-files -Zargs-wild -Zargs-res
p LIBS=-lcx CPP=/usr/bin/cpp.exe CXX=gcc.exe CXXFLAGS=-O2 -g -DOS2 --no-create -
-no-recursion

What puzzles me is the continue reference (in bold) to config.status --recheck which starts again the configuration process. I'm searching in forums and other places but without any hint. I also tried to remove and force --recheck to disappear from the config* files and the created makefiles but without any result - it still keeps regenerating files which loops indefinitely.
Even trying to use bash instead of sh changes nothing.

I really can't understand what the problem may be - I remember in the past I got stuck on a similar issue with another project, but solved it modifying an already available makefile. Can't get a grip on this.

Mentore

14

Programming / Re: [SDL2] SDL_ListModes and emulation

« on: October 31, 2024, 09:11:30 am »

So I tried building fuse. For spectrum I used these configure arguments,

Code: [Select]

--without-libgcrypt --prefix=/@unixroot/usr/local LDFLAGS="-Zomf -Zhigh-mem -lcx"
and for Fuse,

Code: [Select]

--prefix=/Fuse-160 --without-x --without-gtk --disable-gtk3 --with-sdl  LDFLAGS="-Zomf -Zhigh-mem -lcx" LIBS="-lbz2 -lz"  LIBSPECTRUM_CFLAGS=-I/@unixroot/usr/local/include LIBSPECTRUM_LIBS=-l/@unixroot/usr/local/lib/spectrum.a 2>&1 | tee configure.log
and had to add to peripherals/ttx2000s.c, in the include area around line 37,

Code: [Select]

#ifdef __OS2__
#include <libcx/net.h>
#endif

I see configure output,

Code: [Select]

checking whether SDL UI requested... yes
configure: WARNING: SDL 2 not supported for the UI, using SDL 1 instead
checking for sdl-config... /@unixroot/usr/bin/sdl-config
checking for SDL - version >= 1.2.4... yes
and at the end,

Code: [Select]

****************************
*** Libspectrum features ***
****************************

Internal GLib replacement: no
zlib support: yes
bzip2 support: yes
audiofile support: no

********************
*** Fuse options ***
********************

User interface: sdl
Using SDL 2: no
Joystick support: yes
Using libjsw for joystick support: no
zlib support: yes
libxml2 support: yes
libpng support: yes
Available audio drivers: sdl  null
Selected audio driver: sdl
Spectranet support: yes
SpeccyBoot support: no
TTX2000 S support: yes
Desktop integration: no

Type 'make' to compile Fuse

Unluckily, it crashes while, I think, trying to show the settings. fuse --help does work. Perhaps due to lack of utilities? All I feel like doing right now as I'm not really interested in the emulator.

Thanks a lot Dave, I skipped the network support and some other things in order to obtain something working.
Quite possibly you are experiencing my same problem - SDL initialization fails due to SDL_LoadModes returning a 3 value array but with only one mode valid (the other two crash initialization).
I'll surely take your work into account as soon as I can.

Mentore

15

Programming / Re: [SDL2] SDL_ListModes and emulation

« on: October 30, 2024, 11:00:39 pm »

Hi Mentore

I have not played any ZX Spectrum games in many years, would not mind having another go at pacman as I think the Speccy version was the best.

Starfighter (downloaded from hobbes) is an SDL2 game that runs in a window so SDL2 for OS/2 should not be fullscreen only.

However, Starfighter does not work with SDL2 files installed by ANPM - currently at 2.0.18-3 -   but requires an earlier package http://hobbes.nmsu.edu/download/pub/os2/dev/SDL2-2.0.4-20160225.zip in order to run.

So, I guess the question is: Are you using the right variant of SDL2?


Regards

Pete

Thanks Pete. Indeed I already saw some SDL2 games on OS/2 working in windowed mode so yes, I guess my SDL2 install might be the culprit.
Feel free to fetch one of my ZX Spectrum emulators and try them: the 'net is literally full of snapshots and tape images to play, including some really great gems of the past which still stand the test of time (remember Jetpac?).
I'll have a look at different SDL2 implementations and maybe - with a little luck - repack the software with the good one for my port.

Mentore