Messages

1

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

2

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

3

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

4

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

5

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

6

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

7

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

8

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

9

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

10

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

11

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

12

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

13

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

14

Programming / Re: [SDL2] SDL_ListModes and emulation

« on: October 30, 2024, 10:58:11 pm »

The SDL2 rpm also works if linked against it. Are you perhaps using a 3D (OpenGL) surface? They're not supported.

Hi Dave,
the call to SDL_ListModes is done against a SWSURFACE so I guess it's the software renderer.
Maybe the best course of action is to take a look at the SDL2 games ported on OS/2 and see what I can do with them - I used the libraries and the runtimes taken from the RPM archive.
I won't be able to get back to my OS/2 VM until the next Monday, so I guess the next few days will be silent from this side.
Still I'm really exhalted from being able to port such a nice piece of software on OS/2, even if it's for my deep love for the ZX Spectrum.

Mentore

15

Programming / [SDL2] SDL_ListModes and emulation

« on: October 30, 2024, 12:29:37 pm »

You guys, something interesting here.
First of all the good news: I FINALLY got to compile a working release of FUSE, one of the best ZX Spectrum emulators available as open source https://sourceforge.net/projects/fuse-emulator/.

Configure and Make went successful but I encountered two major problems:

• the font file fuse.font used in the SDL version got broken during compilation. I solved it replacing the broken one with a pre-compiled version from a Debian distribution. OK, I cheated, but too little time to investigate on this;
• The executable crashed during SDL graphic mode initialization.

In the source file ui/sdl/sdldisplay.c there's a function named

uidisplay_init( int width, int height )

which calls SDL_ListModes like this:

modes=SDL_ListModes(NULL, SDL_FULLSCREEN|SDL_SWSURFACE);

where modes is of type SDL_Rect **modes; as per documentation.

I noticed that SDL_ListModes returns three available modes but only the first one seems somehow valid.
Trying to access modes[1] or modes[2] immediately crashed the program. SDL documentation was not helpful as I hoped.

The obvious solution was to force selecting modes[0] like this


#if defined (__OS2__)
   mn = 0; // Remove useless warning
   mw = modes[0]->w;
   mh = modes[0]->h;
   fprintf (stderr, "OS/2 system: resolution is %d x %d\n\r", mw, mh);
#else
...rest of original code follows...


I'm currently uploading everything on Hobbes, with source and utilities.
Did someone else encounter this problem? It seems almost like SDL2 under OS/2 works only in full screen mode. This may also explain why I can't start sUQLx (a Sinclair QL SDL emulator) in windowed mode, even if I try to force it.

Mentore