I'm lazy, so once again, I'll share a recent post to the MiNT List about building the latest release of the MiNTLib. Whats news? Support for GCC4 and also support for the Coldfire CPU for the upcoming Firebee! I am by no means as skillful or knowledgeable as Frank Naumann was, who is dearly missed for his support of the platform and shaping MiNTLib, and the kernel, to be what they are today.
---
Before this goes up into SpareMiNT, thought it should be tested to have a consensus that the build is good. I have not found any issues, but that does not mean that I did not overlook something obvious and my Falcon is pretty much a test/dev environment rather than 'production.'
Files are here:
http://www.radix.net/~atari/mint/recent/
[ ] mintbin-0.3-4.m68kmint.rpm 31-May-2010 11:54 579k
[ ] mintbin-0.3-4.src.rpm 31-May-2010 12:00 328k
Install this package first to fix a conflict between the older version and the latest MiNTLib.
[ ] mintlib-0.59.1-1.m68kmint.rpm 02-Jun-2010 16:11 961k
[ ] mintlib-0.59.1-1.src.rpm 02-Jun-2010 16:24 1.4M
[ ] mintlib-debug-0.59.1-1.m68kmint.rpm 02-Jun-2010 16:13 1.7M
[ ] mintlib-devel-0.59.1-1.m68kmint.rpm 02-Jun-2010 16:15 1.6M
[ ] mintlib-profile-0.59.1-1.m68kmint.rpm 02-Jun-2010 16:17 1.8M
Here is the MiNTLib packages themselves, install what is needed. They include the Coldfire libs, as well as the 68000 and 68020-60 libs.
[ ] fdlibm-5.3-2.m68kmint.rpm 04-Jun-2010 13:49 109k
[ ] fdlibm-5.3-2.src.rpm 04-Jun-2010 13:49 85k
[ ] pml-2.03-4.m68kmint.rpm 01-Jun-2010 18:10 25k
[ ] pml-2.03-4.src.rpm 01-Jun-2010 18:10 68k
The MiNTLib update will remove math.h, so whichever math lib is being used needs to be upgraded as well. Both PML and Fdlibm include libraries for 68000 / 68020-60 / Coldfire. PML's Coldfire support is from Vincent's patching. I added the Coldfire support to Fdlibm, and have not tested it yet.
[ ] gcc-4.5.0-1.m68kmint.rpm 01-Jun-2010 15:40 6.5M
[ ] gcc-4.5.0-1.src.rpm 03-Jun-2010 14:52 32.8M
[ ] gcc-c++-4.5.0-1.m68kmint.rpm 01-Jun-2010 15:51 9.5M
Finally, if you want to be brave, GCC 4.5.0 for FreeMiNT. I used this to built MiNTLib, so it seems pretty stable. Based on Vincent's latest patch. If this is installed, it will replace GCC 2.95.3, and you will want this MiNTLib and also Binutils 2.20.1.
I used 'black magic' to build this package. It was build with the Cross Compiler in PS3 Linux using a spec file modified to detect whether it is running natively or cross, and then I had to modify the RPM to be totally 3.0 compliant as it was built with RPM 4.4. There were some other tricks employed in there to fix problems with RPM noting the OS used for the build.
---
Hopefully today I will post a little tutorial (that might possibly be a tad incomplete, but we'll see) on how to try to setup an environment to try to cross compile RPMs. Right now, I am testing this process with the newly released OpenSSL 1.0.0a and will probably also try this with a rebuild of OpenSSH 5.5p1, to keep us up to date!
Wednesday, June 9, 2010
Tuesday, June 1, 2010
Multi-Target SpareMiNT (RPM) Thoughts - How to do it maybe...
This is the other list post about multiple targets for RPM....
---
This is extremely long, but hopefully I explain almost everything....
Basically, this is my thought towards a multi architectured SpareMiNT. Note that this can be tweaked, as I am just basically taking stabs to see what works where. And it is definitely not perfect.
Now, my opinion on libraries versus binaries is this, I think we should try to build the libraries all bundled into a single RPM, because a huge problem will arise with includes needing to overwrite each other. I have, so far, done this with both OpenSSL and Zlib. Binaries can each get their
own package, but the problem arise when lib/binary combination, and that is going to take some thought or fancy spec maneuvering. Anyway....
My first thought is we basically have 3 targets:
m68kmint - 68000, basically the base
m68k020mint - 68020-60
cfmint - 5475
So, for the release of make, you have:
make-3.81-3.src.rpm The src RPM to rebuilt the packages
make-3.81-3.m68kmint.rpm The 68000 binary
make-3.81-3.m68k020mint.rpm The 68020-60 binary
make-3.81-3.cfmint.rpm The Colfire binary
Can these be built? Yes, but we have to make our systems allow them to be installed before we get to the build process.
All systems can install m68kmint.rpm packages, but there need to be changes to allow m68k020mint.rpm and/or cfmint.rpm packages to be installed and/or built.
Two files need to be edited. The first one is /etc/rpmrc.
I believe the original looks like this:
#
# /etc/rpmrc
#
optflags: -O2 -fomit-frame-pointer
Provides: /sbin/rmt
---
Basically this file is just specifying the CFLAGS (Compiler Optimizations)
to use when building a RPM pacakge. So, my modifications:
#
# /etc/rpmrc
#
optflags: m68kmint -O2 -fomit-frame-pointer
optflags: m68k020mint -m68020-60 -O2 -fomit-frame-pointer
optflags: cfmint -mcpu=5475 -O2 -fomit-frame-pointer
#optflags: -O2 -fomit-frame-pointer
Provides: /sbin/rmt
---
The above is setting the CFLAGS for the additional 2 targets so they are
CPU specific.
The other file that needs changes is the /usr/lib/rpm/rpmrc file. This
file is quite large. To be brief, here is the original snippet of lines
that contain mint and might be changed (but not all will):
arch_canon: m68kmint: m68kmint 13
arch_canon: atarist: m68kmint 13
arch_canon: atariste: m68kmint 13
arch_canon: ataritt: m68kmint 13
arch_canon: falcon: m68kmint 13
arch_canon: atariclone: m68kmint 13
arch_canon: milan: m68kmint 13
arch_canon: hades: m68kmint 13
buildarchtranslate: atarist: m68kmint
buildarchtranslate: atariste: m68kmint
buildarchtranslate: ataritt: m68kmint
buildarchtranslate: falcon: m68kmint
buildarchtranslate: atariclone: m68kmint
buildarchtranslate: milan: m68kmint
buildarchtranslate: hades: m68kmint
arch_compat: atarist: m68kmint noarch
arch_compat: atariste: m68kmint noarch
arch_compat: ataritt: m68kmint noarch
arch_compat: falcon: m68kmint noarch
arch_compat: atariclone: m68kmint noarch
arch_compat: milan: m68kmint noarch
arch_compat: hades: m68kmint noarch
buildarch_compat: atarist: m68kmint noarch
buildarch_compat: atariste: m68kmint noarch
buildarch_compat: ataritt: m68kmint noarch
buildarch_compat: falcon: m68kmint noarch
buildarch_compat: atariclone: m68kmint noarch
buildarch_compat: milan: m68kmint noarch
buildarch_compat: hades: m68kmint noarch
---
These are the definitions that allow rpm / sparemint software to be
installed on the various Atari systems. Now, here is my 'modified'
version, which allows the newer RPMs to install:
arch_canon: m68kmint: m68kmint 13
arch_canon: atarist: m68kmint 13
arch_canon: atariste: m68kmint 13
arch_canon: ataritt: m68kmint 13
arch_canon: falcon: m68kmint 13
arch_canon: atariclone: m68kmint 13
arch_canon: milan: m68kmint 13
arch_canon: hades: m68kmint 13
arch_canon: coldtari: m68kmint 13
buildarchtranslate: atarist: m68kmint
buildarchtranslate: atariste: m68kmint
buildarchtranslate: ataritt: m68kmint
buildarchtranslate: falcon: m68kmint
buildarchtranslate: atariclone: m68kmint
buildarchtranslate: milan: m68kmint
buildarchtranslate: hades: m68kmint
arch_compat: atarist: m68kmint noarch
arch_compat: atariste: m68kmint noarch
arch_compat: ataritt: m68kmint m68k020mint noarch
arch_compat: falcon: m68kmint m68k020mint noarch
arch_compat: atariclone: m68kmint m68k020mint noarch
arch_compat: milan: m68kmint m68k020mint noarch
arch_compat: hades: m68kmint m68k020mint noarch
arch_compat: coldtari: m68kmint cfmint noarch
buildarch_compat: atarist: m68kmint m68k020mint cfmint noarch
buildarch_compat: atariste: m68kmint m68k020mint cfmint noarch
buildarch_compat: ataritt: m68kmint m68k020mint cfmint noarch
buildarch_compat: falcon: m68kmint m68k020mint cfmint noarch
buildarch_compat: atariclone: m68kmint m68k020mint cfmint noarch
buildarch_compat: milan: m68kmint m68k020mint cfmint noarch
buildarch_compat: hades: m68kmint m68k020mint cfmint noarch
buildarch_compat: coldtari: m68kmint m68k020mint cfmint noarch
---
Yes, the coldtari name needs to be fixed. :)
What this does now is this lets machines with 68030+ CPUs install the m68k020mint packages besides the standard ones. It also 'allows' the RPMS for all three targets to be built on the various systems.
So, now we have support for installing the RPMs, and support for building them, how do we build them?
So, take a standard RPM spec file. This is the file that has the instructions for building a package. We will use make.spec
For 68000 (The Default)
rpm -ba make.spec
For 68020-60
rpm -ba make.spec --target m68k020mint
For Coldfire
rpm -ba make.spec --target cfmint (Oops, this might fail, we'll get to that)
What this is doing is passing the compiler optimization for those targets to RPM, which, for make, this is how they are used:
make_cv_sys_gnu_glob=yes \
CFLAGS="${RPM_OPT_FLAGS}" ./configure \
--host=m68k-atari-mint \
--prefix=%{_prefix} --disable-nls \
--disable-nsec-timestamps
Right here we are either setting no CPU target or -m68020-60 or -mcpu=5475 at the CFLAGS="${RPM_OPT_FLAGS}"
This will produce makefile to build that way and output a properly named RPM.
Did I just mention a possible problem with Coldfire? Well, the problem is that since Coldfire binaries will not run on anything other than Coldfire CPUs, this causes configure to error out when testing for a Cross Compiler. My 'current' solution for that is the above "--host=m68k-atari-mint" line, which causes configure to think it is cross compiling the Coldfire target on a 68060 system, which is sort of true. This option, I believe, is ignored for the 68000 and 68020-60 targets.
Anyway, if you are still with me, thats my thought. I'm sure a bunch of this is confusing, and people can tweak it, so, go for it!
In closing, let me share a large snippet of the Zlib spec to demo what I talked about in the intro:
%build
# Coldfire
CFLAGS="-mcpu=5475 ${RPM_OPT_FLAGS}" \
./configure \
--prefix=%{_prefix}
make
mv libz.a libzCF.a
# 68020-60
CFLAGS="-m68020-60 ${RPM_OPT_FLAGS}" \
./configure \
--prefix=%{_prefix}
make
mv libz.a libz020.a
# 68000
CFLAGS="${RPM_OPT_FLAGS}" \
./configure \
--prefix=%{_prefix}
make
%install
[ "${RPM_BUILD_ROOT}" != "/" ] && rm -rf ${RPM_BUILD_ROOT}
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/include
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/lib
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/lib/m68020-60
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/lib/m5475
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/share/man/man3
#make install \
# prefix=${RPM_BUILD_ROOT}%{_prefix}
install -m644 libz.a ${RPM_BUILD_ROOT}%{_prefix}/lib/libz.a
install -m644 libzCF.a ${RPM_BUILD_ROOT}%{_prefix}/lib/m5475/libz.a
install -m644 libz020.a ${RPM_BUILD_ROOT}%{_prefix}/lib/m68020-60/libz.a
install -m644 zlib.h ${RPM_BUILD_ROOT}%{_prefix}/include/zlib.h
install -m644 zconf.h ${RPM_BUILD_ROOT}%{_prefix}/include/zconf.h
install -m644 zutil.h ${RPM_BUILD_ROOT}%{_prefix}/include/zutil.h
install -m644 zlib.3 ${RPM_BUILD_ROOT}%{_prefix}/share/man/man3
# compress manpages
gzip -9nf ${RPM_BUILD_ROOT}%{_prefix}/share/man/man*/* ||:
---
If you can follow this, what is happening is Zlib is being compiled 3 times, and the libs for the first 2 compiles are moved out of the way. Finally, everything is installed manually, and the libs for all 3 targets are placed in their correct locations.
The only other way to cleanly support the multilibs I can see, besides having all three loaded into 1 package is to make the 68000 package the main package, and then the other 2 packages sub to it, so you would have:
zlib-devel.m68kmint.rpm
zlib-devel020.m68kmint.rpm
zlib-develcf.m68kmint.rpm
Anyway, this is long enough, but this is my thought process. Any and all thoughts except on how to make this better.
Keith
---
This is extremely long, but hopefully I explain almost everything....
Basically, this is my thought towards a multi architectured SpareMiNT. Note that this can be tweaked, as I am just basically taking stabs to see what works where. And it is definitely not perfect.
Now, my opinion on libraries versus binaries is this, I think we should try to build the libraries all bundled into a single RPM, because a huge problem will arise with includes needing to overwrite each other. I have, so far, done this with both OpenSSL and Zlib. Binaries can each get their
own package, but the problem arise when lib/binary combination, and that is going to take some thought or fancy spec maneuvering. Anyway....
My first thought is we basically have 3 targets:
m68kmint - 68000, basically the base
m68k020mint - 68020-60
cfmint - 5475
So, for the release of make, you have:
make-3.81-3.src.rpm The src RPM to rebuilt the packages
make-3.81-3.m68kmint.rpm The 68000 binary
make-3.81-3.m68k020mint.rpm The 68020-60 binary
make-3.81-3.cfmint.rpm The Colfire binary
Can these be built? Yes, but we have to make our systems allow them to be installed before we get to the build process.
All systems can install m68kmint.rpm packages, but there need to be changes to allow m68k020mint.rpm and/or cfmint.rpm packages to be installed and/or built.
Two files need to be edited. The first one is /etc/rpmrc.
I believe the original looks like this:
#
# /etc/rpmrc
#
optflags: -O2 -fomit-frame-pointer
Provides: /sbin/rmt
---
Basically this file is just specifying the CFLAGS (Compiler Optimizations)
to use when building a RPM pacakge. So, my modifications:
#
# /etc/rpmrc
#
optflags: m68kmint -O2 -fomit-frame-pointer
optflags: m68k020mint -m68020-60 -O2 -fomit-frame-pointer
optflags: cfmint -mcpu=5475 -O2 -fomit-frame-pointer
#optflags: -O2 -fomit-frame-pointer
Provides: /sbin/rmt
---
The above is setting the CFLAGS for the additional 2 targets so they are
CPU specific.
The other file that needs changes is the /usr/lib/rpm/rpmrc file. This
file is quite large. To be brief, here is the original snippet of lines
that contain mint and might be changed (but not all will):
arch_canon: m68kmint: m68kmint 13
arch_canon: atarist: m68kmint 13
arch_canon: atariste: m68kmint 13
arch_canon: ataritt: m68kmint 13
arch_canon: falcon: m68kmint 13
arch_canon: atariclone: m68kmint 13
arch_canon: milan: m68kmint 13
arch_canon: hades: m68kmint 13
buildarchtranslate: atarist: m68kmint
buildarchtranslate: atariste: m68kmint
buildarchtranslate: ataritt: m68kmint
buildarchtranslate: falcon: m68kmint
buildarchtranslate: atariclone: m68kmint
buildarchtranslate: milan: m68kmint
buildarchtranslate: hades: m68kmint
arch_compat: atarist: m68kmint noarch
arch_compat: atariste: m68kmint noarch
arch_compat: ataritt: m68kmint noarch
arch_compat: falcon: m68kmint noarch
arch_compat: atariclone: m68kmint noarch
arch_compat: milan: m68kmint noarch
arch_compat: hades: m68kmint noarch
buildarch_compat: atarist: m68kmint noarch
buildarch_compat: atariste: m68kmint noarch
buildarch_compat: ataritt: m68kmint noarch
buildarch_compat: falcon: m68kmint noarch
buildarch_compat: atariclone: m68kmint noarch
buildarch_compat: milan: m68kmint noarch
buildarch_compat: hades: m68kmint noarch
---
These are the definitions that allow rpm / sparemint software to be
installed on the various Atari systems. Now, here is my 'modified'
version, which allows the newer RPMs to install:
arch_canon: m68kmint: m68kmint 13
arch_canon: atarist: m68kmint 13
arch_canon: atariste: m68kmint 13
arch_canon: ataritt: m68kmint 13
arch_canon: falcon: m68kmint 13
arch_canon: atariclone: m68kmint 13
arch_canon: milan: m68kmint 13
arch_canon: hades: m68kmint 13
arch_canon: coldtari: m68kmint 13
buildarchtranslate: atarist: m68kmint
buildarchtranslate: atariste: m68kmint
buildarchtranslate: ataritt: m68kmint
buildarchtranslate: falcon: m68kmint
buildarchtranslate: atariclone: m68kmint
buildarchtranslate: milan: m68kmint
buildarchtranslate: hades: m68kmint
arch_compat: atarist: m68kmint noarch
arch_compat: atariste: m68kmint noarch
arch_compat: ataritt: m68kmint m68k020mint noarch
arch_compat: falcon: m68kmint m68k020mint noarch
arch_compat: atariclone: m68kmint m68k020mint noarch
arch_compat: milan: m68kmint m68k020mint noarch
arch_compat: hades: m68kmint m68k020mint noarch
arch_compat: coldtari: m68kmint cfmint noarch
buildarch_compat: atarist: m68kmint m68k020mint cfmint noarch
buildarch_compat: atariste: m68kmint m68k020mint cfmint noarch
buildarch_compat: ataritt: m68kmint m68k020mint cfmint noarch
buildarch_compat: falcon: m68kmint m68k020mint cfmint noarch
buildarch_compat: atariclone: m68kmint m68k020mint cfmint noarch
buildarch_compat: milan: m68kmint m68k020mint cfmint noarch
buildarch_compat: hades: m68kmint m68k020mint cfmint noarch
buildarch_compat: coldtari: m68kmint m68k020mint cfmint noarch
---
Yes, the coldtari name needs to be fixed. :)
What this does now is this lets machines with 68030+ CPUs install the m68k020mint packages besides the standard ones. It also 'allows' the RPMS for all three targets to be built on the various systems.
So, now we have support for installing the RPMs, and support for building them, how do we build them?
So, take a standard RPM spec file. This is the file that has the instructions for building a package. We will use make.spec
For 68000 (The Default)
rpm -ba make.spec
For 68020-60
rpm -ba make.spec --target m68k020mint
For Coldfire
rpm -ba make.spec --target cfmint (Oops, this might fail, we'll get to that)
What this is doing is passing the compiler optimization for those targets to RPM, which, for make, this is how they are used:
make_cv_sys_gnu_glob=yes \
CFLAGS="${RPM_OPT_FLAGS}" ./configure \
--host=m68k-atari-mint \
--prefix=%{_prefix} --disable-nls \
--disable-nsec-timestamps
Right here we are either setting no CPU target or -m68020-60 or -mcpu=5475 at the CFLAGS="${RPM_OPT_FLAGS}"
This will produce makefile to build that way and output a properly named RPM.
Did I just mention a possible problem with Coldfire? Well, the problem is that since Coldfire binaries will not run on anything other than Coldfire CPUs, this causes configure to error out when testing for a Cross Compiler. My 'current' solution for that is the above "--host=m68k-atari-mint" line, which causes configure to think it is cross compiling the Coldfire target on a 68060 system, which is sort of true. This option, I believe, is ignored for the 68000 and 68020-60 targets.
Anyway, if you are still with me, thats my thought. I'm sure a bunch of this is confusing, and people can tweak it, so, go for it!
In closing, let me share a large snippet of the Zlib spec to demo what I talked about in the intro:
%build
# Coldfire
CFLAGS="-mcpu=5475 ${RPM_OPT_FLAGS}" \
./configure \
--prefix=%{_prefix}
make
mv libz.a libzCF.a
# 68020-60
CFLAGS="-m68020-60 ${RPM_OPT_FLAGS}" \
./configure \
--prefix=%{_prefix}
make
mv libz.a libz020.a
# 68000
CFLAGS="${RPM_OPT_FLAGS}" \
./configure \
--prefix=%{_prefix}
make
%install
[ "${RPM_BUILD_ROOT}" != "/" ] && rm -rf ${RPM_BUILD_ROOT}
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/include
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/lib
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/lib/m68020-60
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/lib/m5475
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/share/man/man3
#make install \
# prefix=${RPM_BUILD_ROOT}%{_prefix}
install -m644 libz.a ${RPM_BUILD_ROOT}%{_prefix}/lib/libz.a
install -m644 libzCF.a ${RPM_BUILD_ROOT}%{_prefix}/lib/m5475/libz.a
install -m644 libz020.a ${RPM_BUILD_ROOT}%{_prefix}/lib/m68020-60/libz.a
install -m644 zlib.h ${RPM_BUILD_ROOT}%{_prefix}/include/zlib.h
install -m644 zconf.h ${RPM_BUILD_ROOT}%{_prefix}/include/zconf.h
install -m644 zutil.h ${RPM_BUILD_ROOT}%{_prefix}/include/zutil.h
install -m644 zlib.3 ${RPM_BUILD_ROOT}%{_prefix}/share/man/man3
# compress manpages
gzip -9nf ${RPM_BUILD_ROOT}%{_prefix}/share/man/man*/* ||:
---
If you can follow this, what is happening is Zlib is being compiled 3 times, and the libs for the first 2 compiles are moved out of the way. Finally, everything is installed manually, and the libs for all 3 targets are placed in their correct locations.
The only other way to cleanly support the multilibs I can see, besides having all three loaded into 1 package is to make the 68000 package the main package, and then the other 2 packages sub to it, so you would have:
zlib-devel.m68kmint.rpm
zlib-devel020.m68kmint.rpm
zlib-develcf.m68kmint.rpm
Anyway, this is long enough, but this is my thought process. Any and all thoughts except on how to make this better.
Keith
MiNTLib / Kernel Future and also SpareMiNT......
Since I have been remiss with updates, been doing work with some progress, let me post some of my list postings. Will be 2, one about the future (this post) and the next about SpareMiNT for multiple targets......
---
Hi All,
Well, not sure where to go with this conversation, but we need to start it.
First being, we need a person, or a group of people, to steer MiNTLib and the Kernel. Mainly, I think, these people need to decide when it is time to do a release, maybe a little project planning, but I do not believe we need too much. I think this needs to more or less be a decision by the group.
It seems to me that it was more or less decided we should release MiNTLib at 0.59, should this be done now, or with a past build? I know I agree with this since some of the modern tools (gmp/mpfr/mpc/gcc) need support from functionality added and fixed in the CVS/developmental branch of the MiNTLib.
I would propose that we do a release now, and then plan the 0.60 version of MiNTLib to be released around the time of the Firebee release (possibly) in case things need to be fixed or added for Coldfire.
As for the kernel, I can not speak to it's status for release. I would recommend a road map or maybe a list of goals to prepare it for release, mainly bug squishing, and then expand that list to include what features, additions, etc, would go into the next revision.
Now, the other question is Sparemint. Where should it head? Are people still willing to build RPMs and support the software, and do people still want the software supported?
The other issue with Sparemint (well RPM), at least in my opinion, is architecture support. By default, unless currently noted, RPMs are built for a 68000 target. Should that remain the same, or should this expand so that packages are also target at 68020-60 and then later at the Coldfire? If so, how?
I have my own ideas / thoughts for this, but not much point in executing it if it would be of no use.
Remember, Alan is also working on a Gentoo MiNT distribution. I just want to basically see programming resources not go to waste, and get some real 'direction.'
Sorry for writing a book. Back to working on MPFR RPM.....
Keith
---
Hi All,
Well, not sure where to go with this conversation, but we need to start it.
First being, we need a person, or a group of people, to steer MiNTLib and the Kernel. Mainly, I think, these people need to decide when it is time to do a release, maybe a little project planning, but I do not believe we need too much. I think this needs to more or less be a decision by the group.
It seems to me that it was more or less decided we should release MiNTLib at 0.59, should this be done now, or with a past build? I know I agree with this since some of the modern tools (gmp/mpfr/mpc/gcc) need support from functionality added and fixed in the CVS/developmental branch of the MiNTLib.
I would propose that we do a release now, and then plan the 0.60 version of MiNTLib to be released around the time of the Firebee release (possibly) in case things need to be fixed or added for Coldfire.
As for the kernel, I can not speak to it's status for release. I would recommend a road map or maybe a list of goals to prepare it for release, mainly bug squishing, and then expand that list to include what features, additions, etc, would go into the next revision.
Now, the other question is Sparemint. Where should it head? Are people still willing to build RPMs and support the software, and do people still want the software supported?
The other issue with Sparemint (well RPM), at least in my opinion, is architecture support. By default, unless currently noted, RPMs are built for a 68000 target. Should that remain the same, or should this expand so that packages are also target at 68020-60 and then later at the Coldfire? If so, how?
I have my own ideas / thoughts for this, but not much point in executing it if it would be of no use.
Remember, Alan is also working on a Gentoo MiNT distribution. I just want to basically see programming resources not go to waste, and get some real 'direction.'
Sorry for writing a book. Back to working on MPFR RPM.....
Keith
Monday, May 24, 2010
The world of RPMs and SpareMiNT with FreeMiNT....... Specs and multiple targets...
RPMs, at least for users, make it easy for them to add or remove software, update, etc. More modern versions of RPM even make net updates pretty easy.
For developers though, RPM is hit or miss. Personally, I dislike the spec file. The spec file is basically the recipe, or instructions, for RPM to take a source archive, and possible a patch, and to successfully compile it, install it, and then package it for use by users.
Where am I going with this? Well, my latest adventure in trying to solve a major issue with SpareMiNT, how do you support multiple targets, and differentiate between them. Multiple targets meaning 68000, 68020-60, and 5475 (Coldfire).
68000 will work anywhere. On the Coldfire CPUs, though, these packages degrade performance because they must be run through an emulation layer to emulate the difference between the two architectures, since Coldfire is missing 68k instructions. So, when possible, you want software targeted for Coldfire. 68000 is compatible with 68020-60, but there are various optimizations gained from targeting the series of CPUs, so while you might not need all native software targeted for these higher end CPUs, there are some nice performance boost given in different areas.
68020-60 will only work on these CPUs and not Coldfire (I could be wrong). On that Atari ST platform, 68020 are rare, 68030 are common, 68040 are uncommon, and 68060 is pretty common now with the CT60.
5475 will only work on Coldfire series chips, such as the Firebee that is currently being developed / tested / in production. This series of chips is basically the successor of the m68k series. There is no telling how common this CPU will become, but tools are already supporting this target. I have built OpenSSL to include libraries supporting the target, and the GCC port also supports it, along with MiNTLib.
So, we have a quick and dirty summary of our targets. If you are a developer, you probably want or should have libraries built for each target, while if you are a user, you most likely only want binaries targeted at the systems CPU. This is where things get messy.
For developers, having the libraries separated is easy, currently, 68000 libs are the default and reside in /usr/lib and /usr/local/lib. The other targets reside in m68020-60 and m5475 directories in each of those directories. When software is built and the compiler is told to build for a CPU target or defaults to 68000 if nothing is specified, and it searched those directories first for supporting libraries needed, and then falls back to the 68000 libs if needed (and this behavior may change). So, this makes it sort of easy for developers. Only sort of, because when the libraries are installed doing the standard 'make install' they never actually go to the right home, so that needs to be done manually, and the '.la' file with the lib, if it has one, needs to be updated as well for the relocation. If I am incorrect with this statement, boy have I been making additional work for myself!
Anyway, the point is, we have an easy way to separate the libraries, and keep track. And, all of the libraries can be easily packed into a single -dev RPM for specific software. My recent Zlib build includes libs for all three targets, but only binaries for 68000.
This is where we run into problems. We have no easy way to separate the binaries. All of the binaries are just dumped into /usr/bin or /bin. Now, we could add CPU targeted subdirectories, but I do not see that as being worthwhile. My thought right now has been that the suffix is modified on an RPM for a user package so they can choose which version they want. For instance, I am using m68kmint (what has been used, 68000), m68k020mint (68020-60 target) and cfmint (5475). Not the most pretty solution, but we need something.
I guess that is it for rambles.....
Currently I am testing to see if I can build a Coldfire RPM of OpenSSH by just adding "--host=m68k-atari-mint" to configure. Configure is tricked into thinking it is cross compiling on my Falcon, which I guess is not a bad thing. I actually got a decent distance once with the compilation today before the dreaded malloc bug hit. Maybe that is my current issue with RPM, no luck building OpenSSL so far in RPM form because of the same bug..... RPM basically forces you to complete the process from the beginning to the end, no restarting without a lot of monkey business and tricking RPM.
For developers though, RPM is hit or miss. Personally, I dislike the spec file. The spec file is basically the recipe, or instructions, for RPM to take a source archive, and possible a patch, and to successfully compile it, install it, and then package it for use by users.
Where am I going with this? Well, my latest adventure in trying to solve a major issue with SpareMiNT, how do you support multiple targets, and differentiate between them. Multiple targets meaning 68000, 68020-60, and 5475 (Coldfire).
68000 will work anywhere. On the Coldfire CPUs, though, these packages degrade performance because they must be run through an emulation layer to emulate the difference between the two architectures, since Coldfire is missing 68k instructions. So, when possible, you want software targeted for Coldfire. 68000 is compatible with 68020-60, but there are various optimizations gained from targeting the series of CPUs, so while you might not need all native software targeted for these higher end CPUs, there are some nice performance boost given in different areas.
68020-60 will only work on these CPUs and not Coldfire (I could be wrong). On that Atari ST platform, 68020 are rare, 68030 are common, 68040 are uncommon, and 68060 is pretty common now with the CT60.
5475 will only work on Coldfire series chips, such as the Firebee that is currently being developed / tested / in production. This series of chips is basically the successor of the m68k series. There is no telling how common this CPU will become, but tools are already supporting this target. I have built OpenSSL to include libraries supporting the target, and the GCC port also supports it, along with MiNTLib.
So, we have a quick and dirty summary of our targets. If you are a developer, you probably want or should have libraries built for each target, while if you are a user, you most likely only want binaries targeted at the systems CPU. This is where things get messy.
For developers, having the libraries separated is easy, currently, 68000 libs are the default and reside in /usr/lib and /usr/local/lib. The other targets reside in m68020-60 and m5475 directories in each of those directories. When software is built and the compiler is told to build for a CPU target or defaults to 68000 if nothing is specified, and it searched those directories first for supporting libraries needed, and then falls back to the 68000 libs if needed (and this behavior may change). So, this makes it sort of easy for developers. Only sort of, because when the libraries are installed doing the standard 'make install' they never actually go to the right home, so that needs to be done manually, and the '.la' file with the lib, if it has one, needs to be updated as well for the relocation. If I am incorrect with this statement, boy have I been making additional work for myself!
Anyway, the point is, we have an easy way to separate the libraries, and keep track. And, all of the libraries can be easily packed into a single -dev RPM for specific software. My recent Zlib build includes libs for all three targets, but only binaries for 68000.
This is where we run into problems. We have no easy way to separate the binaries. All of the binaries are just dumped into /usr/bin or /bin. Now, we could add CPU targeted subdirectories, but I do not see that as being worthwhile. My thought right now has been that the suffix is modified on an RPM for a user package so they can choose which version they want. For instance, I am using m68kmint (what has been used, 68000), m68k020mint (68020-60 target) and cfmint (5475). Not the most pretty solution, but we need something.
I guess that is it for rambles.....
Currently I am testing to see if I can build a Coldfire RPM of OpenSSH by just adding "--host=m68k-atari-mint" to configure. Configure is tricked into thinking it is cross compiling on my Falcon, which I guess is not a bad thing. I actually got a decent distance once with the compilation today before the dreaded malloc bug hit. Maybe that is my current issue with RPM, no luck building OpenSSL so far in RPM form because of the same bug..... RPM basically forces you to complete the process from the beginning to the end, no restarting without a lot of monkey business and tricking RPM.
Sunday, May 23, 2010
Zlib 1.2.5 and OpenSSH 5.5p1 (Compiled against OpenSSL 1.0.0) RPMs.....
First we have Zlib. The binaries are built for 68000, and libs are included for 68000 / 68020-60 / 5475.
http://www.radix.net/~atari/mint/new/zlib-1.2.5-1.src.rpm
http://www.radix.net/~atari/mint/new/zlib-1.2.5-1.m68kmint.rpm
http://www.radix.net/~atari/mint/new/zlib-devel-1.2.5-1.m68kmint.rpm
And here is OpenSSH 5.5p1, built for either 68000 or 68020-60. To install the 68020-60 versions, modifications need to be made to Sparemint's rpmrc file adding the m68k020mint target.
http://www.radix.net/~atari/mint/new/rpmrc.etc
is a modified rpmrc file for /etc and
http://www.radix.net/~atari/mint/new/rpmrc.usrlibrpm
is the modified version of the file in /usr/lib/rpm/
This also adds a cfmint target as well.
No 5475 version yet as it needs to be either cross compiled or built natively on a Coldfire board.
http://www.radix.net/~atari/mint/new/openssh-5.5p1-1.src.rpm
http://www.radix.net/~atari/mint/new/openssh-5.5p1-1.m68kmint.rpm
http://www.radix.net/~atari/mint/new/openssh-clients-5.5p1-1.m68kmint.rpm
http://www.radix.net/~atari/mint/new/openssh-server-5.5p1-1.m68kmint.rpm
http://www.radix.net/~atari/mint/new/openssh-5.5p1-1.m68k020mint.rpm
http://www.radix.net/~atari/mint/new/openssh-clients-5.5p1-1.m68k020mint.rpm
http://www.radix.net/~atari/mint/new/openssh-server-5.5p1-1.m68k020mint.rpm
If the above rpmrc files are installed, it is possible to built architecture specific RPMs, with properly formatted .spec files with:
rpm --target m68k020mint -ba openssh.spec
Basically, the CPU target is specified as the CFLAGs, and the spec file needs to read this variable and provide it to the configuration mechanism used for building the source.
http://www.radix.net/~atari/mint/new/zlib-1.2.5-1.src.rpm
http://www.radix.net/~atari/mint/new/zlib-1.2.5-1.m68kmint.rpm
http://www.radix.net/~atari/mint/new/zlib-devel-1.2.5-1.m68kmint.rpm
And here is OpenSSH 5.5p1, built for either 68000 or 68020-60. To install the 68020-60 versions, modifications need to be made to Sparemint's rpmrc file adding the m68k020mint target.
http://www.radix.net/~atari/mint/new/rpmrc.etc
is a modified rpmrc file for /etc and
http://www.radix.net/~atari/mint/new/rpmrc.usrlibrpm
is the modified version of the file in /usr/lib/rpm/
This also adds a cfmint target as well.
No 5475 version yet as it needs to be either cross compiled or built natively on a Coldfire board.
http://www.radix.net/~atari/mint/new/openssh-5.5p1-1.src.rpm
http://www.radix.net/~atari/mint/new/openssh-5.5p1-1.m68kmint.rpm
http://www.radix.net/~atari/mint/new/openssh-clients-5.5p1-1.m68kmint.rpm
http://www.radix.net/~atari/mint/new/openssh-server-5.5p1-1.m68kmint.rpm
http://www.radix.net/~atari/mint/new/openssh-5.5p1-1.m68k020mint.rpm
http://www.radix.net/~atari/mint/new/openssh-clients-5.5p1-1.m68k020mint.rpm
http://www.radix.net/~atari/mint/new/openssh-server-5.5p1-1.m68k020mint.rpm
If the above rpmrc files are installed, it is possible to built architecture specific RPMs, with properly formatted .spec files with:
rpm --target m68k020mint -ba openssh.spec
Basically, the CPU target is specified as the CFLAGs, and the spec file needs to read this variable and provide it to the configuration mechanism used for building the source.
Friday, May 21, 2010
m68k-atari-mint Cross Compiler (GCC 4.5.0 / Binutils 2.20.1) for PS3 YellowDog Linux 6
Just like Vincent's cywin cross compiler, this installs in /opt/cross-mint. Just extract the 3 files in /. You will also need at least MiNTLib and PML, which can be grabbed from Vincent's page.
http://www.radix.net/~atari/mint/ps3/binutils-2.20.1-mint-20100410-bin-ps3-ydl6.tar.bz2
http://www.radix.net/~atari/mint/ps3/gcc-4.5.0-mint-20100511-bin-ps3-ydl6.tar.bz2
http://www.radix.net/~atari/mint/ps3/mintbin-0.3-patch-20091031-bin-ps3-ydl6.tar.bz2
http://www.radix.net/~atari/mint/ps3/binutils-2.20.1-mint-20100410-bin-ps3-ydl6.tar.bz2
http://www.radix.net/~atari/mint/ps3/gcc-4.5.0-mint-20100511-bin-ps3-ydl6.tar.bz2
http://www.radix.net/~atari/mint/ps3/mintbin-0.3-patch-20091031-bin-ps3-ydl6.tar.bz2
OpenTTD, Maelstrom and other jabbers.....
As far as I can recall, Maelstrom was stable, except for maybe a problem with writing scores to disk. I'm thinking it is time for me to give it a go again, build it with the latest tools and SDL, and see how it performs. Hopefully I can even get it going in TOS, which would be nice. Here is the old version:
http://www.radix.net/~kws/mint/Maelstrom-mint-050806-unstable.tar.gz
And here is the latest 'working' version of OpenTTD.
http://www.radix.net/~atari/mint/openttd-0.5.1-atari.zip
I should probably qualify that, working for me. I had this run on my Falcon for about 36 hours without a problem. Since this revision, they have switched the code to C++, and every time I build, the resulting binaries fail. It seems to be some weird string issue, but I never get far investigating cause I shift my time back towards ScummVM or other MiNT items like the modern GCC running natively and OpenSSL/SSH. I do have the latest (1.01) source tree sitting compiled on the Falcon just waiting for debugging to see if I can figure out what the woes are.
This info is mostly from this ancient web page:
http://www.radix.net/~atari/
And, for the curious.... This is a game I want to get ported and working, and so far have not been able to for lack of hacking time mostly:
http://www.artsoft.org/rocksndiamonds/
Two others would be Rise of the Triad and Jagged Alliance 2, both of which lack real websites. I did a TON of work on JA2 originally to make the released source compile with GCC on Windows removing many of the, um, Microsoftisms of the C code.
http://www.radix.net/~kws/mint/Maelstrom-mint-050806-unstable.tar.gz
And here is the latest 'working' version of OpenTTD.
http://www.radix.net/~atari/mint/openttd-0.5.1-atari.zip
I should probably qualify that, working for me. I had this run on my Falcon for about 36 hours without a problem. Since this revision, they have switched the code to C++, and every time I build, the resulting binaries fail. It seems to be some weird string issue, but I never get far investigating cause I shift my time back towards ScummVM or other MiNT items like the modern GCC running natively and OpenSSL/SSH. I do have the latest (1.01) source tree sitting compiled on the Falcon just waiting for debugging to see if I can figure out what the woes are.
This info is mostly from this ancient web page:
http://www.radix.net/~atari/
And, for the curious.... This is a game I want to get ported and working, and so far have not been able to for lack of hacking time mostly:
http://www.artsoft.org/rocksndiamonds/
Two others would be Rise of the Triad and Jagged Alliance 2, both of which lack real websites. I did a TON of work on JA2 originally to make the released source compile with GCC on Windows removing many of the, um, Microsoftisms of the C code.
Thursday, May 20, 2010
OpenSSL 1.0.0 for 68000 / 68020-60 / Colfire 5475
I have just finished building OpenSSL for all 3 targets. Of little use to most people. This is not an RPM as the malloc issue is basically killing me in trying to construct one.
Here is OpenSSL:
http://www.radix.net/~atari/mint/openssl-1.0.0-mint-020-60.tar.bz2
http://www.radix.net/~atari/mint/openssl-1.0.0-mint-m5475.tar.bz2
http://www.radix.net/~atari/mint/openssl-1.0.0-mint.tar.bz2
Each archive is stand alone, so, install one, or install them all. Just make sure the last one installed is the platform for which you wish the ssl binary to run on. 68000 and 68020-60 versions pass all tests. Currently unable to test the Coldifre version. Built natively on my Falcon with GCC 4.4.3.
I am going to work on OpenSSH 5.5p1 next.
Here is OpenSSL:
http://www.radix.net/~atari/mint/openssl-1.0.0-mint-020-60.tar.bz2
http://www.radix.net/~atari/mint/openssl-1.0.0-mint-m5475.tar.bz2
http://www.radix.net/~atari/mint/openssl-1.0.0-mint.tar.bz2
Each archive is stand alone, so, install one, or install them all. Just make sure the last one installed is the platform for which you wish the ssl binary to run on. 68000 and 68020-60 versions pass all tests. Currently unable to test the Coldifre version. Built natively on my Falcon with GCC 4.4.3.
I am going to work on OpenSSH 5.5p1 next.
My Development Environment......
Well, the first thing to say is that it is not very organized at all.
With Vincent Rivière's cygwin port of the latest GCC releases, I am now doing a lot of building on a laptop with cygwin, that is also running AranyM. For instance, all ScummVM releases are built there just for the fact that it takes forever to build a complete ScummVM on my Falcon.
I have also been making use of my PS3 for development as well. Have YellowDog Linux 6.1 setup, and built a previous versions of Vincent's GCC port on it. Not sure how much longer this will last since Sony has decided to remove this functionality from updates to the system firmware, but since I rarely use the thing, I won't really run into a problem unless some BluRay movie wants an update. Currently I am bringing the tools on it up to date with the latest GCC release. And, I'm using Linux here cause I have so far not been real happy with any modern Linux on my x86 system. I might try getting Ubuntu gong at some point on an x86....
Otherwise, we have my Falcon. It has a CT60 (first release) with the latest generation 68060, clocked at 72 Mhz cause I still have not installed the CTCM. It also has the nice feature of a non working parallel port, at least for flashing the CT60. Its got a 20 Mhz bus, thanks to Mark Duckworth. Actually, I was able to get a hold of 2 68060s, sold one to him, and delivered it personally, and he updated my CT60s flash at that time (when I finally learned the || port was bad) besides wiring the machine for 20 Mhz bus. The CT60 has 512 megs of ram. I have an Ethernec plugged into the cartridge port for net access. For drives, I have a Startech IDE -> SATA adapter connected thru a 44 pin to 40 pin adapter (plugged in backwards) with a 160 GB Drive and a Pioneer DVDRW. This system is using an eiffel for keyboard / mouse. It is also connected, at any given time, to either an MT32, Casio, or Kawaii keyboard. CTPCI should be arriving shortly for it, actually 2 of them. I also have a second CT60, but only the one Falcon.
A coming attraction, hopefully, is a Coldfire development board. I have two of these boards, one is installed in a case and ready to go. Also have a Radeon Card (7000) and a PCI USB card to use with it, but, currently, both can not be connected due to how the PCI slots are laid out on the board. Need to spend some cash and get something to move the slots. The only media this board takes is a Compact Flash card, which I have. I currently do not have a keyboard / mouse, as I either need an eiffel for it, or to test the USB board. So far, I have been able to boot this system with EMUTOS build by Didier using the Radeon card. Have not had the chance yet to try using the USB card.....
I do have other Atari systems, but none of them are really seeing much use at the moment. The main ones I have are a stock 1040 STf (1.4 TOS), 520 ST with 2.5 Megs (1.0 / 1.4 switchable), 1040 STe with AdSpeed STe and 4 Megs (1.6 TOS), and 2 Mega STes, one with a PAK 030. The first 3 systems were all purchased new in the late 80s / early 90s!
Well, the first thing to say is that it is not very organized at all.
With Vincent Rivière's cygwin port of the latest GCC releases, I am now doing a lot of building on a laptop with cygwin, that is also running AranyM. For instance, all ScummVM releases are built there just for the fact that it takes forever to build a complete ScummVM on my Falcon.
I have also been making use of my PS3 for development as well. Have YellowDog Linux 6.1 setup, and built a previous versions of Vincent's GCC port on it. Not sure how much longer this will last since Sony has decided to remove this functionality from updates to the system firmware, but since I rarely use the thing, I won't really run into a problem unless some BluRay movie wants an update. Currently I am bringing the tools on it up to date with the latest GCC release. And, I'm using Linux here cause I have so far not been real happy with any modern Linux on my x86 system. I might try getting Ubuntu gong at some point on an x86....
Otherwise, we have my Falcon. It has a CT60 (first release) with the latest generation 68060, clocked at 72 Mhz cause I still have not installed the CTCM. It also has the nice feature of a non working parallel port, at least for flashing the CT60. Its got a 20 Mhz bus, thanks to Mark Duckworth. Actually, I was able to get a hold of 2 68060s, sold one to him, and delivered it personally, and he updated my CT60s flash at that time (when I finally learned the || port was bad) besides wiring the machine for 20 Mhz bus. The CT60 has 512 megs of ram. I have an Ethernec plugged into the cartridge port for net access. For drives, I have a Startech IDE -> SATA adapter connected thru a 44 pin to 40 pin adapter (plugged in backwards) with a 160 GB Drive and a Pioneer DVDRW. This system is using an eiffel for keyboard / mouse. It is also connected, at any given time, to either an MT32, Casio, or Kawaii keyboard. CTPCI should be arriving shortly for it, actually 2 of them. I also have a second CT60, but only the one Falcon.
A coming attraction, hopefully, is a Coldfire development board. I have two of these boards, one is installed in a case and ready to go. Also have a Radeon Card (7000) and a PCI USB card to use with it, but, currently, both can not be connected due to how the PCI slots are laid out on the board. Need to spend some cash and get something to move the slots. The only media this board takes is a Compact Flash card, which I have. I currently do not have a keyboard / mouse, as I either need an eiffel for it, or to test the USB board. So far, I have been able to boot this system with EMUTOS build by Didier using the Radeon card. Have not had the chance yet to try using the USB card.....
I do have other Atari systems, but none of them are really seeing much use at the moment. The main ones I have are a stock 1040 STf (1.4 TOS), 520 ST with 2.5 Megs (1.0 / 1.4 switchable), 1040 STe with AdSpeed STe and 4 Megs (1.6 TOS), and 2 Mega STes, one with a PAK 030. The first 3 systems were all purchased new in the late 80s / early 90s!
Wednesday, May 19, 2010
ScummVM for Atari... Its woes and future (hopefully)
The woes with ScummVM....
ScummVM is an amazing piece of software, and also is extremely complicated. That fact that it currently runs on high end Atari machines is amazing. I believe, currently the Atari/FreeMiNT platform is the lowest end platform supported. There use to be an AmigaOS port for 68k, but I believe that is no longer the case.
Anyway, the port is still without it's numerous problems. I guess I am here to try to list those. Can they be fixed? Hopefully, the problem is getting the amount of dedicated time to do this work.
One of the biggest problems has been sound. Adlib emulation takes a huge hit on the CPU, and that is using the older included emulation code. The newer code is even harder on the CPU cycles. Now, between SDL 1.2.9 and 1.2.11, there was a great increase in the speed of the sound handling, so Patrice made some extremely useful optimizations. But, I seem to hit up with sound race conditions (or maybe not) in some games, so, unfortunately, all officially released versions of ScummVM are using the older SDL.
Now, for instance, I can run Monkey Island 2 - LeChucks Revenge (DOS) with almost no issue using newer revisions of SDL. The game plays close to original speed if not at 100%. The 1.2.9 revision of SDL has some lags but is pretty good. Now, Indiana Jones and the Fate of Atlantis (DOS CD Talkie) runs just about full speed with new SDL, but will randomly crash anywhere from 5 to 30 minutes, while with SDL 1.2.9, stable, but some lag. I think a sound race condition is introduced because of the efficiency of the newer SDL in these talkie games, since ScummVM is producing both an Adlib music stream and a digital speech stream. This is one problem I have not been able to figure out at all, but I could be wrong in this thought. While GDB has been wonderful in some other troubleshooting, with this crash it is of little use because there is no code to look at to see where the crash occurred. But then, this theory could be wrong from another issue and approach I was taking to fix it....
ScummVM really wants threads to be able to use timers. As far as I know, timers are used in quite a few engines such as Sierra's AGI engine, the SKY engine and some of the more modem Scumm games, as well using any midi music driver. I have never been able to get threads to work with ScummVM (pth), and ScummVM does not like the included vbl timer Patrice did in SDL, and I believe Patrice thought that possibly the code segment was too large. Now, I was able to hack ScummVM, and this patch has never gone into the official source, but was given the OK with additional work, to fire the timers through screen updates. This works well and allows ST Midi music to work (out to an MT32 on my Falcon), along with AGI games (I completed Space Quest I) and some other titles. Although, I still get the wierd crash with Talkie games like Fate of Atlantis, even though one stream of sound is taken out of the picture. This sort of makes me question the whole idea of a possible race condition. GDB is still of no help here. Also, the timer hack works great with the newer revisions of SDL, but causes crashing with 1.2.9, the version I use for releases.
Another problem is memory usage. Memory usage is not a problem at all when used in MiNT, but seems to be a huge problem in TOS and MagiC. I have never been able to run a game in ScummVM in TOS, and do not have MagiC, while others have been able to do this. But they can only run smaller games, and not larger ones. While I have not spent too much time on this issue, I'm guessing there is a problem with how memory is used between ST Ram, and FastRAM. It seems MiNT does not care, while maybe TOS is dumping ScummVM into ST Ram. It has been a while since I messed with this, since I hate having to constantly reboot to test, but it is a problem that I need to get figured out. Besides flags, I tried messing around with redefining how the mallocs worked, which did not get me anywhere.......
Another current problem I have is that binaries compiled with -m68020-60 do not work. So, I have been back to building 68000 versions for a while.
Well, that lists the main deficiencies I know of. Improvements? Well, there is already a midi driver I added into the ScummVM tree that works on my Falcon with hacked timers. I have been toying around with trying to add a midi -> ym driver, although that still needs a lot of thought to figure out if this is really worthwhile. This is more of a way to reduce the load on the CPU. Also, as previously mentioned, trying to make use of the DSP is on my radar as well. I want to see if I can offload some Adlib functionality to it, and possibly MP3 decoding since using compressed sounds files currently is just too heavy of a CPU load.
Anyway, there you have it. The status of ScummVM. Even with the problems, it is still incredible it works on the platform, and I think the majority of the thanks go to Patrice Mandin for his SDL work. Maybe some of this long winded post should be added to the next readme. :)
ScummVM is an amazing piece of software, and also is extremely complicated. That fact that it currently runs on high end Atari machines is amazing. I believe, currently the Atari/FreeMiNT platform is the lowest end platform supported. There use to be an AmigaOS port for 68k, but I believe that is no longer the case.
Anyway, the port is still without it's numerous problems. I guess I am here to try to list those. Can they be fixed? Hopefully, the problem is getting the amount of dedicated time to do this work.
One of the biggest problems has been sound. Adlib emulation takes a huge hit on the CPU, and that is using the older included emulation code. The newer code is even harder on the CPU cycles. Now, between SDL 1.2.9 and 1.2.11, there was a great increase in the speed of the sound handling, so Patrice made some extremely useful optimizations. But, I seem to hit up with sound race conditions (or maybe not) in some games, so, unfortunately, all officially released versions of ScummVM are using the older SDL.
Now, for instance, I can run Monkey Island 2 - LeChucks Revenge (DOS) with almost no issue using newer revisions of SDL. The game plays close to original speed if not at 100%. The 1.2.9 revision of SDL has some lags but is pretty good. Now, Indiana Jones and the Fate of Atlantis (DOS CD Talkie) runs just about full speed with new SDL, but will randomly crash anywhere from 5 to 30 minutes, while with SDL 1.2.9, stable, but some lag. I think a sound race condition is introduced because of the efficiency of the newer SDL in these talkie games, since ScummVM is producing both an Adlib music stream and a digital speech stream. This is one problem I have not been able to figure out at all, but I could be wrong in this thought. While GDB has been wonderful in some other troubleshooting, with this crash it is of little use because there is no code to look at to see where the crash occurred. But then, this theory could be wrong from another issue and approach I was taking to fix it....
ScummVM really wants threads to be able to use timers. As far as I know, timers are used in quite a few engines such as Sierra's AGI engine, the SKY engine and some of the more modem Scumm games, as well using any midi music driver. I have never been able to get threads to work with ScummVM (pth), and ScummVM does not like the included vbl timer Patrice did in SDL, and I believe Patrice thought that possibly the code segment was too large. Now, I was able to hack ScummVM, and this patch has never gone into the official source, but was given the OK with additional work, to fire the timers through screen updates. This works well and allows ST Midi music to work (out to an MT32 on my Falcon), along with AGI games (I completed Space Quest I) and some other titles. Although, I still get the wierd crash with Talkie games like Fate of Atlantis, even though one stream of sound is taken out of the picture. This sort of makes me question the whole idea of a possible race condition. GDB is still of no help here. Also, the timer hack works great with the newer revisions of SDL, but causes crashing with 1.2.9, the version I use for releases.
Another problem is memory usage. Memory usage is not a problem at all when used in MiNT, but seems to be a huge problem in TOS and MagiC. I have never been able to run a game in ScummVM in TOS, and do not have MagiC, while others have been able to do this. But they can only run smaller games, and not larger ones. While I have not spent too much time on this issue, I'm guessing there is a problem with how memory is used between ST Ram, and FastRAM. It seems MiNT does not care, while maybe TOS is dumping ScummVM into ST Ram. It has been a while since I messed with this, since I hate having to constantly reboot to test, but it is a problem that I need to get figured out. Besides flags, I tried messing around with redefining how the mallocs worked, which did not get me anywhere.......
Another current problem I have is that binaries compiled with -m68020-60 do not work. So, I have been back to building 68000 versions for a while.
Well, that lists the main deficiencies I know of. Improvements? Well, there is already a midi driver I added into the ScummVM tree that works on my Falcon with hacked timers. I have been toying around with trying to add a midi -> ym driver, although that still needs a lot of thought to figure out if this is really worthwhile. This is more of a way to reduce the load on the CPU. Also, as previously mentioned, trying to make use of the DSP is on my radar as well. I want to see if I can offload some Adlib functionality to it, and possibly MP3 decoding since using compressed sounds files currently is just too heavy of a CPU load.
Anyway, there you have it. The status of ScummVM. Even with the problems, it is still incredible it works on the platform, and I think the majority of the thanks go to Patrice Mandin for his SDL work. Maybe some of this long winded post should be added to the next readme. :)
Tuesday, May 18, 2010
Lets share some links....
Right off the presses
GMP / MPFR / MPC for 68020-60 target. Just extract this files into / on a native system. Built specifically to build a native version of GCC 4.5.0
GMP 4.3.2
MPFR 2.4.2
MPC 0.8.1
Here is some stuff I have built. Just the highlights. You can see everything @ http://www.radix.net/~atari/mint/
Native GCC 4.4.3 for the 68000. Works great.
http://www.radix.net/~atari/mint/new/gcc-4.4.3-1.m68kmint.rpm
http://www.radix.net/~atari/mint/new/gcc-c++-4.4.3-1.m68kmint.rpm
GCC 4.4.3 binaries only compiled for 68020-60. Seem to work fine. I have not done any testing to see if they work better than there 68000 counterparts. Just extract this archive over the existing install from /
http://www.radix.net/~atari/mint/new/gcc-4.4.3-020-binaries.tar.bz2
GCC 4.4.3 binaries only compiled for Coldfire. Totally untested! Just extract this archive over the existing install from /
http://www.radix.net/~atari/mint/new/gcc-4.4.3-v4e-binaries.tar.bz2
OpenSSL 0.9.8l with binaries built for 68000, but libraries built for 68000 / 68020-60 / Coldfire. Coldfire has not been tested. I am currently working on build OpenSSL 1.0.0.
http://www.radix.net/~atari/mint/new/openssl-0.9.8l-2.m68kmint.rpm
http://www.radix.net/~atari/mint/new/openssl-0.9.8l-2.src.rpm
http://www.radix.net/~atari/mint/new/openssl-devel-0.9.8l-2.m68kmint.rpm
Zlib 1.2.3 built just like the above OpenSSL, includes the libraries for all 3 targets.
http://www.radix.net/~atari/mint/new/zlib-1.2.3-1.m68kmint.rpm
http://www.radix.net/~atari/mint/new/zlib-1.2.3-1.src.rpm
http://www.radix.net/~atari/mint/new/zlib-devel-1.2.3-1.m68kmint.rpm
For the brave, http://www.radix.net/~atari/mint/new/ includes some binaries targeted for 68020-60 (Like OpenSSH) that are RPMs, and also has modified rpmrc files to support these. I don't support this, yet, as this is something that needs to be decided on as a group, basically the direction to head as far as how to support multiple targets.
Here is an older revision of LibGMP built for the 68000, and fully tested. Newer revisions for the 68000 have issues.
http://www.radix.net/~atari/mint/gmp-4.2.4-1.m68kmint.rpm
http://www.radix.net/~atari/mint/gmp-4.2.4-1.src.rpm
Lzip
http://www.radix.net/~atari/mint/lzip-1.5-1.m68kmint.rpm
http://www.radix.net/~atari/mint/lzip-1.5-1.src.rpm
Lzo
http://www.radix.net/~atari/mint/lzo-2.03-1.m68kmint.rpm
http://www.radix.net/~atari/mint/lzo-2.03-1.src.rpm
A working version of the MPC lib for 68000, compiled against the older revision of GMP
http://www.radix.net/~atari/mint/mpc-0.8.1-atari.tar.bz2
Subversion, which seems to work well, used heavily in ScummVM development. Many of the prereqs for building it are also present in the same directory.
http://www.radix.net/~atari/mint/subversion-1.5.6-1.m68kmint.rpm
http://www.radix.net/~atari/mint/subversion-1.5.6-1.src.rpm
Right off the presses
GMP / MPFR / MPC for 68020-60 target. Just extract this files into / on a native system. Built specifically to build a native version of GCC 4.5.0
GMP 4.3.2
MPFR 2.4.2
MPC 0.8.1
Here is some stuff I have built. Just the highlights. You can see everything @ http://www.radix.net/~atari/mint/
Native GCC 4.4.3 for the 68000. Works great.
http://www.radix.net/~atari/mint/new/gcc-4.4.3-1.m68kmint.rpm
http://www.radix.net/~atari/mint/new/gcc-c++-4.4.3-1.m68kmint.rpm
GCC 4.4.3 binaries only compiled for 68020-60. Seem to work fine. I have not done any testing to see if they work better than there 68000 counterparts. Just extract this archive over the existing install from /
http://www.radix.net/~atari/mint/new/gcc-4.4.3-020-binaries.tar.bz2
GCC 4.4.3 binaries only compiled for Coldfire. Totally untested! Just extract this archive over the existing install from /
http://www.radix.net/~atari/mint/new/gcc-4.4.3-v4e-binaries.tar.bz2
OpenSSL 0.9.8l with binaries built for 68000, but libraries built for 68000 / 68020-60 / Coldfire. Coldfire has not been tested. I am currently working on build OpenSSL 1.0.0.
http://www.radix.net/~atari/mint/new/openssl-0.9.8l-2.m68kmint.rpm
http://www.radix.net/~atari/mint/new/openssl-0.9.8l-2.src.rpm
http://www.radix.net/~atari/mint/new/openssl-devel-0.9.8l-2.m68kmint.rpm
Zlib 1.2.3 built just like the above OpenSSL, includes the libraries for all 3 targets.
http://www.radix.net/~atari/mint/new/zlib-1.2.3-1.m68kmint.rpm
http://www.radix.net/~atari/mint/new/zlib-1.2.3-1.src.rpm
http://www.radix.net/~atari/mint/new/zlib-devel-1.2.3-1.m68kmint.rpm
For the brave, http://www.radix.net/~atari/mint/new/ includes some binaries targeted for 68020-60 (Like OpenSSH) that are RPMs, and also has modified rpmrc files to support these. I don't support this, yet, as this is something that needs to be decided on as a group, basically the direction to head as far as how to support multiple targets.
Here is an older revision of LibGMP built for the 68000, and fully tested. Newer revisions for the 68000 have issues.
http://www.radix.net/~atari/mint/gmp-4.2.4-1.m68kmint.rpm
http://www.radix.net/~atari/mint/gmp-4.2.4-1.src.rpm
Lzip
http://www.radix.net/~atari/mint/lzip-1.5-1.m68kmint.rpm
http://www.radix.net/~atari/mint/lzip-1.5-1.src.rpm
Lzo
http://www.radix.net/~atari/mint/lzo-2.03-1.m68kmint.rpm
http://www.radix.net/~atari/mint/lzo-2.03-1.src.rpm
A working version of the MPC lib for 68000, compiled against the older revision of GMP
http://www.radix.net/~atari/mint/mpc-0.8.1-atari.tar.bz2
Subversion, which seems to work well, used heavily in ScummVM development. Many of the prereqs for building it are also present in the same directory.
http://www.radix.net/~atari/mint/subversion-1.5.6-1.m68kmint.rpm
http://www.radix.net/~atari/mint/subversion-1.5.6-1.src.rpm
An Atari blog. Never have really done the blog thing before, but since my work on all sorts of different packages for that Atari/FreeMiNT platform is so disjointed, I decided I needed a place to actually talk about what I am doing and hopefully provide links that might be helpful to someone out there. So, anyway, not too sure how often this will be updated.
At the moment, I am working on OpenSSL 1.0.0. So far, it only needed 1 additional patch besides the existing patches to add support for our platform. I was able to successfully build and fully test a version built for 68000 with GCC 4.4.3. Right now my Falcon is building a 68020-60 version to test. Unsure if this will get packaged as an RPM at this stage because the build keeps getting the dreaded malloc crash.
I'm hoping to start working on building GCC 4.5.0 natively. Have successfully built GMP, MPFR, and MPC for a 68020-60 target. Right now, the 68000 target is not doing too well with testing.
Other pending projects? Well, I just ordered the FireBee yesterday, hoping to get something going with my ColdFire development board soon too, but just have not invested the time in trying. I got a hold of a NEC USB PCI card to try to get keyboard and mouse going on it, besides already having Radeon 7000s on hand in expectation of the CTPCI showing up soon.
And my latest adventure is into the realm of learning to use the 56001 DSP in the Falcon. ScummVM needs a lot of help (It has tons of issues on the platform besides the horsepower it needs) so I am hoping that I can figure out a way to use the DSP to alleviate the load on the CPU. I have always been thinking about trying to make all of the adlib code run from it for adlib emulation. Another possibility is getting MP3 decoding working with ScummVM to have the ability to use compressed sound with the DSP's help. Again, this is an area where I need to find time to invest. Of course, ScummVM has other problems with timers, sound race conditions, and memory needs outside of mint.
Also always messing with other items here and there. Anyway, enough for now. Hopefully I'll get back on here and start posting links to some of my older packages sitting in my webspace with some short descriptions.....
At the moment, I am working on OpenSSL 1.0.0. So far, it only needed 1 additional patch besides the existing patches to add support for our platform. I was able to successfully build and fully test a version built for 68000 with GCC 4.4.3. Right now my Falcon is building a 68020-60 version to test. Unsure if this will get packaged as an RPM at this stage because the build keeps getting the dreaded malloc crash.
I'm hoping to start working on building GCC 4.5.0 natively. Have successfully built GMP, MPFR, and MPC for a 68020-60 target. Right now, the 68000 target is not doing too well with testing.
Other pending projects? Well, I just ordered the FireBee yesterday, hoping to get something going with my ColdFire development board soon too, but just have not invested the time in trying. I got a hold of a NEC USB PCI card to try to get keyboard and mouse going on it, besides already having Radeon 7000s on hand in expectation of the CTPCI showing up soon.
And my latest adventure is into the realm of learning to use the 56001 DSP in the Falcon. ScummVM needs a lot of help (It has tons of issues on the platform besides the horsepower it needs) so I am hoping that I can figure out a way to use the DSP to alleviate the load on the CPU. I have always been thinking about trying to make all of the adlib code run from it for adlib emulation. Another possibility is getting MP3 decoding working with ScummVM to have the ability to use compressed sound with the DSP's help. Again, this is an area where I need to find time to invest. Of course, ScummVM has other problems with timers, sound race conditions, and memory needs outside of mint.
Also always messing with other items here and there. Anyway, enough for now. Hopefully I'll get back on here and start posting links to some of my older packages sitting in my webspace with some short descriptions.....
Subscribe to:
Posts (Atom)