Author Topic: Software ports - the state of my art until now  (Read 2738 times)

Mentore

  • Sr. Member
  • ****
  • Posts: 275
  • Karma: +18/-0
    • View Profile
Software ports - the state of my art until now
« on: November 19, 2025, 08:31:11 am »
Hello all, I have finally set up a convenient development environment for my ArcaOS 5.1 VM and I'm in the process of porting some other software, hoping it will be useful. I placed my hands on something interesting, I have to say - and many things just compile without problems, thanks to the huge work of people like Paul Smedley and the others. Thanks guys!

Now for a list of what's cooking (just the most relevant items):

  • MidiEditor - a Qt5 MIDI sequencer. It starts without problems, still have to try it on some complex MIDI file though. A really good help when it comes to music production.
  • yape on SDL: a Commodore VIC-20 / 64 / 128 / +4 emulator on SDL 2. Have to try it thoroughly but it seems working just fine.
  • jsEmu48 and x48 SDL: HP 48/49 emulators based on SDL. x48 still has problems due to the ROM / RAM image locations but it looks promising.
  • CometFTP: a Qt 5 SFTP client which looks very interesting.
  • CScope: one of the most interesting software analysis programs
  • semblance: text mode application to disassemble old MS-DOS software. Yes, I want to use it on some older DOS programs and see if I can do something on them.
  • two IMAP text mode mail clients - I would like to use them to build a REXX GUI wrapper and see if we can get a simple email client on IMAP.
  • Some interesting libraries: z80ex (Zilog Z80 emulation), capstone (disassembly), capsimage (disk image handling), libTmt (terminal emulation)
  • More to come in the next weeks I think..

After the good news, here are two interesting (?) problems I'm encountering on two ports:

1 - I'm working on porting Hatari (Atari emulator on SDL, https://www.hatari-emu.org/) and it mostly compiles, but then emxomf fails with two errors:

emxomf: Index too large
emxomfld: a.out to omf conversion failed for 'cpu/UaeCpu.a'.
make[2]: *** [src/CMakeFiles/hatari.dir/build.make:1287: src/hatari.exe] Error 1
make[1]: *** [CMakeFiles/Makefile2:460: src/CMakeFiles/hatari.dir/all] Error 2
make: *** [Makefile:146: all] Error 2


I think they may be related to cmake, but can't find the culprit. Some of my current flags are these (attaching the CMD file I'm using to set up my dev environment):

EMXOMFLD_LINKER=wl.exe
EMXOMFLD_TYPE=wlink
CFLAGS=-O2 -DOS2
CXXFLAGS=-O2 -DOS2
ASLAGS=-Zomf
LDFLAGS=-Zomf -Zhigh-mem
LIB=-lcx


2 - eigen3 (math library) and octave workshop, both requiring Qt4:
I've tried to install all Qt4 software from RPM repositories but I still seem unable to find the development libraries. I'm about to look at them again but currently I seem unable to compile Qt4 software.

I'll gladly accept any advice on these two problems I'm encountering - in the meantime I'll try on something more and maybe start publishing my works on hobbes.

Mentore

Lars

  • Hero Member
  • *****
  • Posts: 1474
  • Karma: +74/-0
    • View Profile
Re: Software ports - the state of my art until now
« Reply #1 on: November 19, 2025, 01:52:56 pm »
Hello all, I have finally set up a convenient development environment for my ArcaOS 5.1 VM and I'm in the process of porting some other software, hoping it will be useful. I placed my hands on something interesting, I have to say - and many things just compile without problems, thanks to the huge work of people like Paul Smedley and the others. Thanks guys!


After the good news, here are two interesting (?) problems I'm encountering on two ports:

1 - I'm working on porting Hatari (Atari emulator on SDL, https://www.hatari-emu.org/) and it mostly compiles, but then emxomf fails with two errors:

emxomf: Index too large
emxomfld: a.out to omf conversion failed for 'cpu/UaeCpu.a'.
make[2]: *** [src/CMakeFiles/hatari.dir/build.make:1287: src/hatari.exe] Error 1
make[1]: *** [CMakeFiles/Makefile2:460: src/CMakeFiles/hatari.dir/all] Error 2
make: *** [Makefile:146: all] Error 2


I think they may be related to cmake, but can't find the culprit. Some of my current flags are these (attaching the CMD file I'm using to set up my dev environment):

EMXOMFLD_LINKER=wl.exe
EMXOMFLD_TYPE=wlink
CFLAGS=-O2 -DOS2
CXXFLAGS=-O2 -DOS2
ASLAGS=-Zomf
LDFLAGS=-Zomf -Zhigh-mem
LIB=-lcx


2 - eigen3 (math library) and octave workshop, both requiring Qt4:
I've tried to install all Qt4 software from RPM repositories but I still seem unable to find the development libraries. I'm about to look at them again but currently I seem unable to compile Qt4 software.

I'll gladly accept any advice on these two problems I'm encountering - in the meantime I'll try on something more and maybe start publishing my works on hobbes.

Mentore

ASLAGS ? I suppose that should be ASFLAGS ?
I think -Zomf should go into CFLAGS and CXXFLAGS and not ASFLAGS (assuming ASFLAGS are for the assembler)

Dave Yeo

  • Hero Member
  • *****
  • Posts: 5606
  • Karma: +141/-1
    • View Profile
Re: Software ports - the state of my art until now
« Reply #2 on: November 19, 2025, 04:53:27 pm »
Which assembler is being used? If GAS, don't need the OMF, if NASM, -f aout

Mentore

  • Sr. Member
  • ****
  • Posts: 275
  • Karma: +18/-0
    • View Profile
Re: Software ports - the state of my art until now
« Reply #3 on: November 21, 2025, 08:53:49 am »
Hello all, I have finally set up a convenient development environment for my ArcaOS 5.1 VM and I'm in the process of porting some other software, hoping it will be useful. I placed my hands on something interesting, I have to say - and many things just compile without problems, thanks to the huge work of people like Paul Smedley and the others. Thanks guys!


After the good news, here are two interesting (?) problems I'm encountering on two ports:

1 - I'm working on porting Hatari (Atari emulator on SDL, https://www.hatari-emu.org/) and it mostly compiles, but then emxomf fails with two errors:

emxomf: Index too large
emxomfld: a.out to omf conversion failed for 'cpu/UaeCpu.a'.
make[2]: *** [src/CMakeFiles/hatari.dir/build.make:1287: src/hatari.exe] Error 1
make[1]: *** [CMakeFiles/Makefile2:460: src/CMakeFiles/hatari.dir/all] Error 2
make: *** [Makefile:146: all] Error 2


I think they may be related to cmake, but can't find the culprit. Some of my current flags are these (attaching the CMD file I'm using to set up my dev environment):

EMXOMFLD_LINKER=wl.exe
EMXOMFLD_TYPE=wlink
CFLAGS=-O2 -DOS2
CXXFLAGS=-O2 -DOS2
ASLAGS=-Zomf
LDFLAGS=-Zomf -Zhigh-mem
LIB=-lcx


2 - eigen3 (math library) and octave workshop, both requiring Qt4:
I've tried to install all Qt4 software from RPM repositories but I still seem unable to find the development libraries. I'm about to look at them again but currently I seem unable to compile Qt4 software.

I'll gladly accept any advice on these two problems I'm encountering - in the meantime I'll try on something more and maybe start publishing my works on hobbes.

Mentore

ASLAGS ? I suppose that should be ASFLAGS ?
I think -Zomf should go into CFLAGS and CXXFLAGS and not ASFLAGS (assuming ASFLAGS are for the assembler)

Thanks Lars, it indeed was a typo.The ASFLAGS directive was correct in the original CMD file (I guess: I may be wrong, though) - I got this CMD gathering info here and there but surely many thing still miss and I would like to get rid of the old GCC 9.2 in favour of the latest one from Paul. Will do that next week I believe.

Mentore

Mentore

  • Sr. Member
  • ****
  • Posts: 275
  • Karma: +18/-0
    • View Profile
Re: Software ports - the state of my art until now
« Reply #4 on: November 21, 2025, 08:55:32 am »
Which assembler is being used? If GAS, don't need the OMF, if NASM, -f aout

I have to look at it - will do that next week. My VM is in my office workstation, so until the next monday I will not be able to reach it.

Thanks Dave!
Mentore

Mentore

  • Sr. Member
  • ****
  • Posts: 275
  • Karma: +18/-0
    • View Profile
Re: Software ports - the state of my art until now
« Reply #5 on: November 24, 2025, 10:24:35 am »
Which assembler is being used? If GAS, don't need the OMF, if NASM, -f aout

OK, this is becoming confusing. The problem is here:

make[2]: Entering directory 'D:/Sviluppo/sorgenti/hatari/build'
[  9%] Building C object src/cpu/CMakeFiles/UaeCpu.dir/cpustbl.c.o
cd D:/Sviluppo/sorgenti/hatari/build/src/cpu && D:/USR/BIN/cc.exe -DCONFDIR=\"/etc\" @CMakeFiles/UaeCpu.dir/includes_C.rsp -O2 -DOS2 -Zomf -std=gnu99 -Wcast-qual -Wbad-function-cast -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wall -Wwrite-strings -Wsign-compare -Wformat-security -Wimplicit-fallthrough=2 -Wshadow=local -Wvla -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DNDEBUG -Wno-sign-compare -Wno-unused-variable -fwrapv -Wno-shadow=local -Wno-unused-but-set-variable -MD -MT src/cpu/CMakeFiles/UaeCpu.dir/cpustbl.c.o -MF CMakeFiles/UaeCpu.dir/cpustbl.c.o.d -o CMakeFiles/UaeCpu.dir/cpustbl.c.o -c D:/Sviluppo/sorgenti/hatari/build/src/cpu/cpustbl.c
emxomf: Index too large
{standard input}: Assembler messages:
{standard input}: Fatal error: emxomf failed
make[2]: *** [src/cpu/CMakeFiles/UaeCpu.dir/build.make:137: src/cpu/CMakeFiles/U
aeCpu.dir/cpustbl.c.o] Error 1


It's using cc as compiler (gcc 9.2.0 set by cmake). As I said before, I would like to swap it with Gcc 15.10 but just have to investigate on this.
Any clues? I'm pretty much lost...

Mentore

Dave Yeo

  • Hero Member
  • *****
  • Posts: 5606
  • Karma: +141/-1
    • View Profile
Re: Software ports - the state of my art until now
« Reply #6 on: November 24, 2025, 04:55:09 pm »
Tried building this. My cmake environment seems broken when it comes to using make, it seems to recurse until it hangs the system, so I use Ninja to build, "cmake -G Ninja .."
Had to work around, I think, our termio not supporting 57600 baud with some #if 0.
Dies here,
Code: [Select]
emxomf: Index too large
emxomfld: a.out to omf conversion failed for 'src/cpu/UaeCpu.a'.
ninja: build stopped: subcommand failed.

Investigating but I'd guess there is inline assembler that needs adjusting for aout, probably .section directives. Aout is very simple.

My quick hack,
Code: [Select]
diff --git a/src/rs232.c b/src/rs232.c
index 8175421b..a731cdd7 100644
--- a/src/rs232.c
+++ b/src/rs232.c
@@ -396,10 +396,12 @@ static bool RS232_SetBaudRate(int nBaud)
  { 9600, B9600 },
  { 19200, B19200 },
  { 38400, B38400 },
+#if 0
  { 57600, B57600 },
  { 115200, B115200 },
 #ifdef B230400                 /* B230400 is not defined on all systems */
  { 230400, B230400 },
+#endif
 #endif
  { -1, -1 }
  };
diff --git a/src/scc.c b/src/scc.c
index c37197c4..9eb61030 100644
--- a/src/scc.c
+++ b/src/scc.c
@@ -770,11 +770,13 @@ static void SCC_Serial_Set_BaudRate ( int Channel, int value )
 
  switch (value)
  {
+#if 0
 #ifdef B230400 /* B230400 is not defined on all systems */
  case 230400: new_speed = B230400; break;
 #endif
  case 115200: new_speed = B115200; break;
  case 57600: new_speed = B57600; break;
+#endif
  case 38400: new_speed = B38400; break;
  case 19200: new_speed = B19200; break;
  case 9600: new_speed = B9600; break;

Lars

  • Hero Member
  • *****
  • Posts: 1474
  • Karma: +74/-0
    • View Profile
Re: Software ports - the state of my art until now
« Reply #7 on: November 25, 2025, 07:32:01 am »
In case "nasm.exe" is used as the assembler:

why can you not use switch "-f obj" to produce an OMF object file right away ? That would be the equivalent to calling the C compiler with the "-Zomf" switch which will also produce an OMF object file.

That's at least the nasm switch I used to compile some SSE3 assembler code (unfortunately, alp.exe does not support SSE3) to link with a few other (OMF) object files with Watcom. And that worked without a problem.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 5606
  • Karma: +141/-1
    • View Profile
Re: Software ports - the state of my art until now
« Reply #8 on: November 25, 2025, 08:22:08 am »
You can use -f obj along with USE32 but then all the other object files have to be compiled with -Zomf in the CFLAGS/CXXFLAGS, also need AR=emxomfar, runlib=echo, and different LDFLAGS.
In this case their doesn't seem to be any assembler unless it is inline assembly, I didn't look that close. The build does something weird here, (all one line)
Code: [Select]
[87/195] Generating cpustbl.c, cpuemu_0.c, cpuemu_11.c, cpuemu_13.c, cpuemu_20.c, cpuemu_21.c, cpuemu_22.c, cpuemu_23.c, cpuemu_24.c, cpuemu_31.c, cpuemu_32.c, cpuemu_33.c, cpuemu_34.c, cpuemu_35.c, cpuemu_40.c, cpuemu_50.c
And also builds a 20MB static library which is what fails. Possibly it really does end up with too large an index.
If it was a configure based build, I'd try going OMF all the way and perhaps emxomfar would work better then ar in building the static lib.

Mentore

  • Sr. Member
  • ****
  • Posts: 275
  • Karma: +18/-0
    • View Profile
Re: Software ports - the state of my art until now
« Reply #9 on: November 25, 2025, 12:46:15 pm »
You can use -f obj along with USE32 but then all the other object files have to be compiled with -Zomf in the CFLAGS/CXXFLAGS, also need AR=emxomfar, runlib=echo, and different LDFLAGS.
In this case their doesn't seem to be any assembler unless it is inline assembly, I didn't look that close. The build does something weird here, (all one line)
Code: [Select]
[87/195] Generating cpustbl.c, cpuemu_0.c, cpuemu_11.c, cpuemu_13.c, cpuemu_20.c, cpuemu_21.c, cpuemu_22.c, cpuemu_23.c, cpuemu_24.c, cpuemu_31.c, cpuemu_32.c, cpuemu_33.c, cpuemu_34.c, cpuemu_35.c, cpuemu_40.c, cpuemu_50.c
And also builds a 20MB static library which is what fails. Possibly it really does end up with too large an index.
If it was a configure based build, I'd try going OMF all the way and perhaps emxomfar would work better then ar in building the static lib.

Hi Dave, thank you and thanks everyone.
Fact is - I really don't know much about CMake. The makefiles it creates always give me a headache  ???
If it were made via configure it would be (somewhat) easier. I'll try and figure out what can I do - Hatari would be a good piece of software to have on an OS/2 architecture.

I'll let you all know how things are going.
In the meantime I got Zork source code and some Z-Machine interpreter - will take a look also at these.

Mentore

fusion

  • Newbie
  • *
  • Posts: 23
  • Karma: +4/-0
    • View Profile
    • dcclost.com
Re: Software ports - the state of my art until now
« Reply #10 on: November 26, 2025, 01:15:34 am »
if you can get it to build completely with another machine, i had some success replacing the 'cc' binary with a bash script that logged the parameters cmake called cc with and then called cc itself.

then you could probably play back the log semi-manually in sections on the os/2 machine (for example it builds a utility that then generates a bunch of C files based on a cpu specification, which Dave pointed out) .. search and replace to change directories and all that.

90% of cmake seems to be an incredibly convoluted method of making sure your system has all sorts of stuff.. but you can totally just adjust the config.h you managed to generate with another machine after the fact..

make yourself a little makefile.os2

*shrug*