Linux/Unix build

A place to discuss current and future developments for STeem

Moderators: Mug UK, Steem Authors, Moderator Team

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4760
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Linux/Unix build

Postby simonsunnyboy » Sun Oct 07, 2012 9:52 am

Thanks, let's see what I can do. Atleast I can try to keep the Linux build alive when it is working again. With only 6 revisions at the moment, there are few things that can go wrong.

I finally found the tag version but ran into the same problems as with the trunk version. make 3rdparty ran through after I downloaded the missing libraries.

I probably won't make large functional patches to the STEEM base itself. But count me as a helping hand. We can easily switch to a work scheme where you develop stuffs under trunk and when they work, i help you with tagging etc? Subversion should not stand in the way of your efforts to work further on STEEM ;)
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4760
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Linux/Unix build

Postby simonsunnyboy » Sun Oct 07, 2012 10:01 am

The Makefile mentions symbolic links:

Code: Select all

# symbolic links - code, inc, 3rdparty


Those seem to be missing in the current SVN but i think could easily be generated.
Where are the links placed and to which exact locations to they point? Maybe this is my main problem to compile the Linux build at the moment.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1813
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Linux/Unix build

Postby Steven Seagal » Sun Oct 07, 2012 10:17 am

simonsunnyboy wrote:The Makefile mentions symbolic links:

Code: Select all

# symbolic links - code, inc, 3rdparty


Those seem to be missing in the current SVN but i think could easily be generated.
Where are the links placed and to which exact locations to they point? Maybe this is my main problem to compile the Linux build at the moment.


Can't help there, I'm ignorant of those things.
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4760
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Linux/Unix build

Postby simonsunnyboy » Sun Oct 07, 2012 11:14 am

Ok, no worries. I might convert the build system to Cmake (www.cmake.org). Hatari uses that and it is pretty nifty and helps with crossplatform builds alot.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

Ato
Captain Atari
Captain Atari
Posts: 300
Joined: Tue Aug 10, 2010 3:27 am
Location: Duisburg, Germany

Re: Linux/Unix build

Postby Ato » Mon Oct 08, 2012 2:07 pm

Steven Seagal wrote:Well it's not so hard to handle both / and \, M$ can do it.


Well, that's true but unfortunately not required. C99 puts it this way:

Semantics
2 A preprocessing directive of the form
# include <h-char-sequence> new-line searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
(ISO/IEC 9899:TC3, Committee Draft — Septermber 7, 2007, WG14/N1256, §6.10.2 Source file inclusion) - Wrong spelling of "September" copied from the document. :lol:

I take from this, that if I want to write code in C which compiles on either Unix or MS systems, I am better off using forward slashes only as path separators.

Hth. Cheers,
T.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1813
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Linux/Unix build

Postby Steven Seagal » Sat Mar 02, 2013 12:57 pm

The Linux build of Steem SSE 3.5.0, aka XSteem, has been released on 02/03/2013.
It hasn't all the features of the Windows build but the core emulation is up to date.
It will not work well on all systems (like mine).
But I know it works better on most systems.
For audio you really need to select the right device.
XSteem SSE only uses rtaudio (no portaudio).
Rendering issues will be solved when we switch to SDL.
I just realised that in the included 'Linux.txt' I typed 'IDE' instead of 'terminal'.


Here's where you can get it:

https://sourceforge.net/projects/steemsse/

Or on the kick ass site:

http://ataristeven.t15.org/Steem_all_builds.htm
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

User avatar
Silver Surfer
Forum Administrator
Forum Administrator
Posts: 1793
Joined: Mon Apr 22, 2002 6:50 pm
Location: Umeå, Sweden
Contact:

Re: Linux/Unix build

Postby Silver Surfer » Sun Mar 03, 2013 8:57 am

Works nicely! :) Tried a couple disk images so far and it works very good.

Also didn't need to start from terminal.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4760
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Linux/Unix build

Postby simonsunnyboy » Sun Mar 03, 2013 10:06 am

It works but I get this constant humming background noise (and the source is not known). The noise starts after activation of the RtAudio library for actual output.

It is so sad :( it worked well years ago but the Linux system was more dated. How about a proper ALSA or PulseAudio backend?
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1497
Joined: Sun Jul 31, 2011 1:11 pm

Re: Linux/Unix build

Postby Eero Tamminen » Sun Mar 03, 2013 11:50 am

Ato wrote:
Steven Seagal wrote:Well it's not so hard to handle both / and \, M$ can do it.


Well, that's true but unfortunately not required. C99 puts it this way:


C standard specifies '/' as the include file path separator. On platforms (like Windows) which use '\' as path separator, file system (not C-compiler) just happen interpret names with them as path + filename. I.e. it works by luck, not according specification, Steem code was buggy.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1813
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Linux/Unix build

Postby Steven Seagal » Sun Mar 03, 2013 5:34 pm

Again much depends on your system, apparently also for this terminal/explorer thing and sound.
XSteem SSE itself isn't broken, apparently library support isn't consistent in the Linux space & time, who's to blame?
I refuse to check more audio/video issues before I try something with SDL.
But, and I don't mean this sarcastically or anything, I thought Linux boys were all l33t coders, so if somebody can fix anything already they're most welcome. I spend so little time on Linux I only try to get the current build compile.
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4760
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Linux/Unix build

Postby simonsunnyboy » Sun Mar 03, 2013 5:49 pm

The blame is certainly not on your end, as I had these sound issues with the original Xsteem too. I already told the Hayward brothers to switch over to a plain ALSA driver which they didn't implement.

libSDL is very easy to use while you mention it, it leads to direct results on any platform it is available. For some reasons unknown to me, STEEM was not based from the start on it to utilize this. Hatari has no problems with its SDL backend and compiles for almost any target which has the libraries.

The STEEM sources and build files are a bit messy too, again not your fault, which makes it hard to get through and refactor.

I tried compiling the sources myself once more and get errors

Code: Select all

$ make
mkdir -p ./obj
nasm -felf -o./obj/asm_draw.o -i../steem/asm/ ../steem/asm/asm_draw.asm
nasm -felf -o./obj/asm_osd.o -i../steem/asm/ ../steem/asm/asm_osd_draw.asm
mkdir -p obj output
make res
make[1]: Betrete Verzeichnis '/home/marndt/src/steemsse-code/steemsse/X-build'
nasm -felf -o./obj/resource.o -i../steem/ ../steem/rc/resource.asm
make[1]: Verlasse Verzeichnis '/home/marndt/src/steemsse-code/steemsse/X-build'
make helper
make[1]: Betrete Verzeichnis '/home/marndt/src/steemsse-code/steemsse/X-build'
g++ -o ./obj/helper.o -c ../steem/helper.cpp -I../include -I../steem/code -I../3rdparty -I../3rdparty/pasti -I../3rdparty/dsp -I../3rdparty/6301 -I../3rdparty/zlib/contrib/minizip -I../3rdparty/zlib -I../3rdparty/rtaudio -lasound -w -Wfatal-errors -DUNIX -DLINUX -DSTEVEN_SEAGAL -DNO_PORT_AUDIO
In file included from ../include/x/hxc.cpp:594,
                 from ../steem/helper.cpp:36:
../include/x/hxc_listview.cpp: In member function ‘void hxc_listview::drag_end(int, int)’:
../include/x/hxc_listview.cpp:1017: error: cast from ‘hxc_listview_drop_struct*’ to ‘int’ loses precision
compilation terminated due to -Wfatal-errors.
make[1]: *** [helper] Fehler 1
make[1]: Verlasse Verzeichnis '/home/marndt/src/steemsse-code/steemsse/X-build'
make: *** [all] Fehler 2


I would try to modernize the build system myself (CMake) if I get a working build compiled which I can reverseengineer in its build sequence.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

bandit
Captain Atari
Captain Atari
Posts: 259
Joined: Tue Aug 05, 2003 9:02 pm
Contact:

Re: Linux/Unix build

Postby bandit » Sun Mar 03, 2013 6:49 pm

i really would like to have a good working OS X version:) that would help a lot finnishing my work to sort all my unsorted section:)

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1813
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Linux/Unix build

Postby Steven Seagal » Mon Mar 04, 2013 7:07 pm

Steem SSE uses makefiles with txt extension, because of the way some
backup tools work.

To build XSteem SSE, enter this in the terminal:
make -B -fMakefile.txt 3rdparty
make -B -fMakefile.txt

To build the debug build, enter this:
make -B -fMakefile_dbg.txt 3rdparty
make -B -fMakefile_dbg.txt

The 2 step process was already the way for previous Steem versions.
It is justified by slow building of some 3rd party software.

If you get compilation errors, you should update your configuration based on
hints given by the compiler.
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

Ato
Captain Atari
Captain Atari
Posts: 300
Joined: Tue Aug 10, 2010 3:27 am
Location: Duisburg, Germany

Re: Linux/Unix build

Postby Ato » Wed Mar 06, 2013 11:27 pm

Eero Tamminen wrote:C standard specifies '/' as the include file path separator.


The one that I quoted above (C99) does not define it as far as I can tell. So what C standard are you talking about? I'd like to read that myself since we had exactly that issue at work.

Cheers,
T.

Hippy Dave
Atari Super Hero
Atari Super Hero
Posts: 515
Joined: Sat Jan 10, 2009 5:40 am

Re: Linux/Unix build

Postby Hippy Dave » Thu Mar 07, 2013 7:28 am

'/' as an include file separator works in Borland 5 with opengl on Windows(tm)
e.g. #include <GL/glut.h>

Edit: Borland C++ Version 3.1 (1992) for DOS also uses '/'

I have never seen '\' as an include file separator for dos(tm), windows(tm),
atari(tm) or adsp21060.

That means you use '/', or you don't use '/' ... anything else is ain't real C.

In Microsoft C, (or Atari) you can set environment variables in a batch
file so that you don't use include file separators.
e.g. SET INCLUDE=D:\MSVC\INCLUDE
Last edited by Hippy Dave on Fri Mar 08, 2013 8:29 am, edited 1 time in total.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1497
Joined: Sun Jul 31, 2011 1:11 pm

Re: Linux/Unix build

Postby Eero Tamminen » Thu Mar 07, 2013 8:48 am

Ato wrote:
Eero Tamminen wrote:C standard specifies '/' as the include file path separator.


The one that I quoted above (C99) does not define it as far as I can tell. So what C standard are you talking about? I'd like to read that myself since we had exactly that issue at work.


It appears that the standard for C I was talking about was POSIX.

In the C-standard itself, any path characters in the include file name are implementation dependent, so "most portable" way would be not using them, but specify include file paths to the compiler in your makefiles.

However, as most of the portable C-code actually uses at least some POSIX APIs (for networking, file information etc) and several of the headers for those APIs are in sub-directories (specified by the POSIX spec), and all currently relevant platforms (OSX, Windows, Linux & its derivatives) support POSIX somehow, forward slashes are the most portable thing to use.

Ato
Captain Atari
Captain Atari
Posts: 300
Joined: Tue Aug 10, 2010 3:27 am
Location: Duisburg, Germany

Re: Linux/Unix build

Postby Ato » Fri Mar 08, 2013 1:59 am

Eero Tamminen wrote:It appears that the standard for C I was talking about was POSIX.


OK, got it. POSIX is not a C standard but an system level API, C99 is a standard.

Eero Tamminen wrote:However, as most of the portable C-code actually uses at least some POSIX APIs (for networking, file information etc) and several of the headers for those APIs are in sub-directories (specified by the POSIX spec), and all currently relevant platforms (OSX, Windows, Linux & its derivatives) support POSIX somehow, forward slashes are the most portable thing to use.


I supose you are talking about the potable C source code. Then I cannot see how using POSIX relates to what path seperator has to be used. It appears to me that you are mixing two things not related! Path seperators in #include statements are not defined by any API used in the source code but through the implementation in the compiler. - Which might make use of the POSIX API. 8)

Hht. Cheers,
T.

Hippy Dave
Atari Super Hero
Atari Super Hero
Posts: 515
Joined: Sat Jan 10, 2009 5:40 am

Re: Linux/Unix build

Postby Hippy Dave » Fri Mar 08, 2013 8:19 am

http://open-std.org/JTC1/SC22/WG14/www/standards
http://open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf
page 73 (91st page)

6.4.7 Header names
Semantics
2 The sequences in both forms of header names are mapped in an implementation-defined
manner to headers or external source file names as specified in 6.10.2.
3 If the characters ', \, ", //, or /* occur in the sequence between the < and > delimiters,
the behavior is undefined. (The same applies for the sequence between " delimiters.)

Thus, #include <1/a.h> is as 'implementation-defined' as #include <stdio.h> because
C programmers understand that the header file a.h is in the 1 sub-directory, and so
should the operating system.
Whereas, #include <sys\types.h> is 'undefined' because it specifies sys\types.h 'as'
the header file, and may be interpreted as being 'sys' separated from 'ypes.h' with
a tab '\t' character.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1497
Joined: Sun Jul 31, 2011 1:11 pm

Re: Linux/Unix build

Postby Eero Tamminen » Fri Mar 08, 2013 10:28 am

Ato wrote:Path seperators in #include statements are not defined by any API used in the source code but through the implementation in the compiler. - Which might make use of the POSIX API. 8)


They are specified in POSIX. For example <sys/stat.h>:
http://pubs.opengroup.org/onlinepubs/00 ... tat.h.html

(And e.g. in BSD where a lot of earlier POSIX stuff is taken from.)

Ato
Captain Atari
Captain Atari
Posts: 300
Joined: Tue Aug 10, 2010 3:27 am
Location: Duisburg, Germany

Re: Linux/Unix build

Postby Ato » Sat Mar 09, 2013 3:24 pm

Eero Tamminen wrote:They are specified in POSIX. For example <sys/stat.h>:
http://pubs.opengroup.org/onlinepubs/00 ... tat.h.html


Correct. That's an OS API and not a C-standard as Hippy Dave also pointed out. Anyway, I guess we are all on the same page now and have had enough poking around in C-standards. 8)

Cheers,
T.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1813
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Linux/Unix build

Postby Steven Seagal » Sun Mar 10, 2013 7:37 pm

Fascinating. But those considerations don't help the Unix build of Steem much. :)
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

User avatar
farvardin
Captain Atari
Captain Atari
Posts: 315
Joined: Fri Jan 01, 2010 5:50 pm
Location: France
Contact:

Re: Linux/Unix build

Postby farvardin » Sat Apr 20, 2013 8:08 pm

it works pretty well for me on Linux Mint. The sound is coming only from the left side, strangely.

I used Steem a long time ago. It's probably the most compatible ST emulator, it beats Hatari on this field. On the other hand, hatari has some interesting features, such as more configuration for screen size (3x instead of only 2x size) and for fullscreen.

Thank you for your work on Steem!

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1497
Joined: Sun Jul 31, 2011 1:11 pm

Re: Linux/Unix build

Postby Eero Tamminen » Sat Apr 20, 2013 8:59 pm

farvardin wrote:I used Steem a long time ago. It's probably the most compatible ST emulator, it beats Hatari on this field.


If there's something which Hatari doesn't emulate as well as Steem, please let Hatari developers know so that it can be fixed:
viewforum.php?f=51

As far as I know, Steem's main advantage over Hatari is Windows GUI [1], and especially its GUI debugger [2]. When it comes to emulation, for STE emulation Hatari and STeem are fairly equal, but Hatari's better on emulating anything else (ST, TT, Falcon).

[1] Hatari has nice GUIs for OSX and Linux, for Windows there's just the basic SDL GUI.
[2] Hatari has powerful debugger & profiler, but it's text-only.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1813
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Linux/Unix build

Postby Steven Seagal » Sun Apr 21, 2013 7:38 am

Eero Tamminen wrote:As far as I know, Steem's main advantage over Hatari is Windows GUI [1], and especially its GUI debugger [2]. When it comes to emulation, for STE emulation Hatari and STeem are fairly equal, but Hatari's better on emulating anything else (ST, TT, Falcon).


For TT & Falcon, no contest. For STF I contest (SSE build).
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1813
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Linux/Unix build

Postby Steven Seagal » Thu Jun 13, 2013 6:34 pm

XSteem SSE 3.5.1, the Unix/Linux port of Steem, has been released on 13/06/2013.

The Linux build of 3.5.1, includes emulation improvements (or regressions!) of the Windows version (CPU, drive...) but not all features (no IPF or interpolated scanlines for example). How well it works could depend on your configuration, please don't ask for support. It works well on my system (*), so it should be fine.

Download:
https://sourceforge.net/projects/steems ... SSE%203.5/

http://ataristeven.t15.org/Steem_all_builds.htm



(*) After an update, there was nothing to debug in Steem.
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm


Social Media

     

Return to “Development”

Who is online

Users browsing this forum: No registered users and 1 guest