Tiny Core Linux
General TC => General TC Talk => Topic started by: Sliver X on June 04, 2016, 02:07:11 AM
-
I recently started playing with Tiny Core 7.1 after not having used it since the 5.x series (To build a graphical recovery partition system for a bunch of Windows 7 machines I took care of at a previous job), and am pretty impressed so far. I initially started building a dedicated emulator setup from the minimal Core setup and ended up making a fairly functional (For the bulk of what I do on a daily basis, at least) general desktop:
(http://sliverx.arc-nova.org/tcsnap-t.jpg) (http://sliverx.arc-nova.org/tcsnap.jpg)
For emulation I compiled and built a TCZ for Mednafen 0.9.38.7 and AdvanceMenu (An emulator frontend) and also the compositor Compton.
AdvanceMenu is tied to a shell script I wrote for my Ubuntu install (Hence why there's entries for emulators no available for TC currently) that allows running ROMs directly from 7zip files and other things:
#Multi-Emulator Launcher Script
###############################
#2016 Sliver X
#DECOMPRESSION FUNCTIONS: 7zip, RAR and Zip
###########################################
#Get File Extension of file passed to script.
ExtensionTest=$(echo $1 | sed 's/.*\.//')
#Check if it's compressed. If so, decompress to a temp directory.
case $ExtensionTest in
#It's a 7zip!
7z)
mkdir ~/romtemp
7z x "$1" -o"$HOME/romtemp"
;;
#It's a RAR!
rar)
mkdir ~/romtemp
rar x "$1" "$HOME/romtemp"
;;
#It's a Zip!
zip)
mkdir ~/romtemp
unzip "$1" -d "$HOME/romtemp"
;;
#It's not compressed in a method we care about!
*)
NotCompressed=$(echo "1")
;;
#End CASE test.
esac
#DETERMINE ROM TYPE
###################
#Check if the called ROM was decompressed by our script or not.
case $NotCompressed in
#The ROM was not decompressed by us. Assign "$1" to $ROM and make $ROMPath blank (Not needed).
1)
ROMPath=$(echo "")
ROM=$(echo "$1")
;;
#We decompressed the ROM. Go to temp directory and set is as $ROM and $ROMPath as our temp directory.
*)
cd ~/romtemp
for ROM in *.*
do
ROMPath=$(echo ~/romtemp/)
done
;;
#End CASE statement.
esac
#RUN ROM
########
#Strip the ROM name to the extension, then load it into a variable.
ROMExt=$(echo $ROM | sed 's/.*\.//')
#We'll test the extension, and load the ROM with the appropriate emulator if it's recognized.
case $ROMExt in
a26)
stella "$ROMPath$ROM"
;;
nds)
desmume "$ROMPath$ROM"
;;
cue)
mednafen "$ROMPath$ROM"
;;
pbp)
wine /home/sliverx/epsxewin/epsxe.exe -nogui -loadbin "$ROMPath$ROM"
;;
fds)
mednafen "$ROMPath$ROM"
;;
gb)
mednafen "$ROMPath$ROM"
;;
gba)
mednafen "$ROMPath$ROM"
;;
gbc)
mednafen "$ROMPath$ROM"
;;
gg)
mednafen "$ROMPath$ROM"
;;
lnx)
mednafen "$ROMPath$ROM"
;;
nes)
mednafen "$ROMPath$ROM"
;;
ngc)
mednafen "$ROMPath$ROM"
;;
cso)
PPSSPPSDL "$ROMPath$ROM"
;;
ngp)
mednafen "$ROMPath$ROM"
;;
pce)
mednafen "$ROMPath$ROM"
;;
sgb)
mednafen "$ROMPath$ROM"
;;
sms)
mednafen "$ROMPath$ROM"
;;
unf)
mednafen "$ROMPath$ROM"
;;
ws)
mednafen "$ROMPath$ROM"
;;
wsc)
mednafen "$ROMPath$ROM"
;;
32x)
fusion "$ROMPath$ROM"
;;
iso)
fusion "$ROMPath$ROM"
;;
bin)
mednafen "$ROMPath$ROM"
;;
a52)
mess a5200 -cart "$ROMPath$ROM"
;;
a78)
mess a7800 -cart "$ROMPath$ROM"
;;
col)
mess coleco -cart "$ROMPath$ROM"
;;
vec)
mess vectrex -cart "$ROMPath$ROM"
;;
z64)
mupen64plus "$ROMPath$ROM"
;;
v64)
mupen64plus "$ROMPath$ROM"
;;
smc)
mednafen "$ROMPath$ROM"
;;
fig)
mednafen "$ROMPath$ROM"
;;
sfc)
mednafen "$ROMPath$ROM"
;;
#End CASE statement.
esac
#Cleanup
########
#Check if we decompressed a ROM in the beginning
case $NotCompressed in
#We didn't decompress a ROM, so nothing to clean up! Quit.
1)
exit
;;
#We did. Delete temp directory and quit.
*)
rm -rf ~/romtemp
exit
;;
#End Case statement.
esac
As far as the OS iteslf goes, the list of packages I installed is as follows:
ntfs-3g.tcz
nvidia-352.63-4.2.9-tinycore.tcz
Xorg-7.7.tcz
alsa-modules-4.2.9-tinycore.tcz
alsa.tcz
alsa-config.tcz
jwm.tcz
aterm.tcz
dosbox.tcz
mednafen.tcz
p7zip-full.tcz
compton.tcz
advancemenu.tcz
pcmanfm.tcz
xarchiver.tcz
mtpaint.tcz
iptables.tcz
firefox-ESR.tcz
nano.tcz
volumeicon.tcz
xchat.tcz
gftp.tcz
The re-rolled initrd, TCZs and mydata.tar.gz totals about 269MB.
I started running into memory allocation errors with mount when trying to add the last bits of this: It seemed to have something to do with the 196(!) TCZ mounts in place. I directly integrated all the library TCZs into my initrd and was able to knock this down to 100 and no longer experience it.
ALSA initially gave me trouble as it would start my onboard audio muted. I unmuted it and turned the volume up via alsamixer then ran sudo alsactl --file /usr/local/etc/asound.state store, added that file to the Include list in the backup tool then added alsactl --file /usr/local/etc/asound.state restore to /opt/bootlocal.sh
OpenGL is the only thing that gave and is still giving me a headache: No matter what version I tried of the nVidia driver in the repositories I couldn't get GLX extensions to load, preventing Mednafen from working. I finally tracked down the issue to some symlinks under /usr/local/lib pointing to .so files from libGL instead of their nVidia equivalents. Adding the following to bootlocal.sh fixed it:
rm -f /usr/local/lib/libGL.so
rm -f /usr/local/lib/libGL.so.1
rm -f /usr/local/lib/libGL.so.1.2.0
ln -sf /tmp/tcloop/nvidia-352.63-4.2.9-tinycore/usr/lib/libGL.so /usr/local/lib/libGL.so
ln -sf /tmp/tcloop/nvidia-352.63-4.2.9-tinycore/usr/lib/libGL.so.1 /usr/local/lib/libGL.so.1
ln -sf /tmp/tcloop/nvidia-352.63-4.2.9-tinycore/usr/lib/libGL.so.1.2.0 /usr/local/lib/libGL.so.1.2.0
However, I can't get smooth scrolling working despite every xorg.conf tweak I can find. Compton also doesn't really seem to help either. It's almost like vsync isn't working at all.
Anyway, anyone else recently worked on a project that they would like to show? I'd be most interested in seeing what others are doing with Tiny Core.
-
I'm curious which Nvidia modules extension gave you the symlink issue. Because without the older hardware I couldn't test all the NVIDIA extensions thoroughly however those NVIDIA extension I use and have tested work flawlessly
Sent from my iPhone using Tapatalk
-
One area of cocern is if you're unpackng extensions into your own initrd but haven't considered handling of the extensions startup scripts then many extentions are likely to give problems like the nvidia module symlinks which are created by the startup script
Sent from my iPhone using Tapatalk
-
This old thread lists some:
http://forum.tinycorelinux.net/index.php?topic=16464.0
-
I'm curious which Nvidia modules extension gave you the symlink issue. Because without the older hardware I couldn't test all the NVIDIA extensions thoroughly however those NVIDIA extension I use and have tested work flawlessly
nvidia-352.63-4.2.9-tinycore.tcz, driving a GeForce 750 Ti
One area of cocern is if you're unpackng extensions into your own initrd but haven't considered handling of the extensions startup scripts then many extentions are likely to give problems like the nvidia module symlinks which are created by the startup script
The issue manifests with the stock initrd and loading everything as TCZs as well.
I'm loading the nVidia modules before Xorg, per what it states in the .info file for it:
Install onboot
This extension must load before Xorg
Is that right?
This old thread lists some:
http://forum.tinycorelinux.net/index.php?topic=16464.0
Thank you.
-
That's what happens when I open my mouth without booting up TC-7.x with nvidia-352.x drivers first to check.. :p
In this version of nvidia drivers the startup file was removed in favor of installing the actual symlink within the extension, this requires the module extension to be loaded first as it is in normal course of events.
So...
Since my installation and everyone elses (AFAIK) has been working as expected more research is needed
I just took this screenshot, OpenGL appears to be fully functional
(https://db.tt/ItyDakuK)
However as crazy as this sounds to me I can replicate the issue, which makes me wonder what changed recently??
Still investigating..
-
While I had a hard time believing the symlinks were not correct in your system, if either Xorg or libGL tcz's are loaded before any nvidia extension then the correct symlinks are not installed. The easiest solution is to load nvidia extension before either Xorg and libGL, however this is likely not the right answer as libGL will normally be loaded first..
So thanks for notifying of this, we're arriving at a solution and will advise when the updated nvidia extension is uploaded to the repo
-
While I had a hard time believing the symlinks were not correct in your system, if either Xorg or libGL tcz's are loaded before any nvidia extension then the correct symlinks are not installed. The easiest solution is to load nvidia extension before either Xorg and libGL, however this is likely not the right answer as libGL will normally be loaded first..
The first three entries on my onboot.lst file is as follows, if that helps with anything:
ntfs-3g.tcz
nvidia-352.63-4.2.9-tinycore.tcz
Xorg-7.7.tcz
So thanks for notifying of this, we're arriving at a solution and will advise when the updated nvidia extension is uploaded to the repo
No problem. Thanks for making the nVidia TCZ packages.
-
OpenGL is the only thing that gave and is still giving me a headache: No matter what version I tried of the nVidia driver in the repositories I couldn't get GLX extensions to load, preventing Mednafen from working. I finally tracked down the issue to some symlinks under /usr/local/lib pointing to .so files from libGL instead of their nVidia equivalents. Adding the following to bootlocal.sh fixed it:
rm -f /usr/local/lib/libGL.so
rm -f /usr/local/lib/libGL.so.1
rm -f /usr/local/lib/libGL.so.1.2.0
ln -sf /tmp/tcloop/nvidia-352.63-4.2.9-tinycore/usr/lib/libGL.so /usr/local/lib/libGL.so
ln -sf /tmp/tcloop/nvidia-352.63-4.2.9-tinycore/usr/lib/libGL.so.1 /usr/local/lib/libGL.so.1
ln -sf /tmp/tcloop/nvidia-352.63-4.2.9-tinycore/usr/lib/libGL.so.1.2.0 /usr/local/lib/libGL.so.1.2.0
Hi Sliver X
I discovered a few things..
The symlinks within all Nvidia extensions are correct, however..
Your symlink above will not work because the file which it links to "nvidia-352.63-4.2.9-tinycore/usr/lib/libGL.so.1.2.0" does not exist
therefore
ln -sf /tmp/tcloop/nvidia-352.63-4.2.9-tinycore/usr/lib/libGL.so.1.2.0 /usr/local/lib/libGL.so.1.2.0is not functional and whether the other links in your list are required is questionalble.
the important proprietary nvidia files/links which matter are:
/usr/lib/libGL.so.352.63
/usr/lib/libGL.so.1
/usr/lib/libGL.so
Since these files already exist (created when the nvidia extension is installed) in /usr/lib/ not /usr/local/lib/, the only concern is to remove any links to Xorg's libGL extension in /usr/local/lib/
I'm testing an nvidia extension which removes the offending files " /usr/local/lib/libGL.so* "
In the meantime if you care to verify? please replace from your bootlocal.sh file:
All this
rm -f /usr/local/lib/libGL.so
rm -f /usr/local/lib/libGL.so.1
rm -f /usr/local/lib/libGL.so.1.2.0
ln -sf /tmp/tcloop/nvidia-352.63-4.2.9-tinycore/usr/lib/libGL.so /usr/local/lib/libGL.so
ln -sf /tmp/tcloop/nvidia-352.63-4.2.9-tinycore/usr/lib/libGL.so.1 /usr/local/lib/libGL.so.1
ln -sf /tmp/tcloop/nvidia-352.63-4.2.9-tinycore/usr/lib/libGL.so.1.2.0 /usr/local/lib/libGL.so.1.2.0
with this
[ -e /usr/local/lib/libGL.so ] && rm -f /usr/local/lib/libGL.so
[ -e /usr/local/lib/libGL.so.1 ] && rm -f /usr/local/lib/libGL.so.1
[ -e /usr/local/lib/libGL.so.1.2.0 ] && rm -f /usr/local/lib/libGL.so.1.2.0
Removal of the above links should be all that is required to ensure the nvidia GL files are used. If for some reason a third party app can not find the already installed links to /usr/lib/libGL.so.352.63, then we may consider adding this link, but I'm fairly sure it won't be needed as the correct files already exist in path
ln -sf /tmp/tcloop/nvidia-352.63-4.2.9-tinycore/usr/lib/libGL.so.352.63 /usr/local/lib/libGL.so
and please advise
thanks
-
[ -e /usr/local/lib/libGL.so ] && rm -f /usr/local/lib/libGL.so
[ -e /usr/local/lib/libGL.so.1 ] && rm -f /usr/local/lib/libGL.so.1
[ -e /usr/local/lib/libGL.so.1.2.0 ] && rm -f /usr/local/lib/libGL.so.1.2.0
Putting this in my bootlocal.sh script remedies the issue as well, so I no longer get the following when running Mednafen (Using its OpenGL blitter):
Initializing video...
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 153 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Value in failed request: 0x0
Serial number of failed request: 32
Current serial number in output stream: 33
Compton and GLXGears do run without the fix, which is what was throwing me off so much in the beginning of all this.
Thanks for looking into it.
As an aside, if anyone would like the Mednafen, Compton or AdvanceMenu TCZ files I've rolled I'll create the .info, .list and .txt.md5 files for them and send via PM or email.
-
Hi Sliver X
As an aside, if anyone would like the Mednafen, Compton or AdvanceMenu TCZ files I've rolled I'll create the .info, .list and .txt.md5 files for them and send via PM or email.
Or you could just submit them to the repository:
http://wiki.tinycorelinux.net/wiki:creating_extensions#send_to
-
[ -e /usr/local/lib/libGL.so ] && rm -f /usr/local/lib/libGL.so
[ -e /usr/local/lib/libGL.so.1 ] && rm -f /usr/local/lib/libGL.so.1
[ -e /usr/local/lib/libGL.so.1.2.0 ] && rm -f /usr/local/lib/libGL.so.1.2.0
Putting this in my bootlocal.sh script remedies the issue as well...
Good, thanks for verifying. After the Nvidia extension updates are are submitted and your system has been updated from the repo you'll be able to remove the above code from your bootlocal.sh
As an aside, if anyone would like the Mednafen, Compton or AdvanceMenu TCZ files I've rolled I'll create the .info, .list and .txt.md5 files for them and send via PM or email.
I think it will be better and appreciated by all if you submitted them to the repo.
Thanks
-
Due to obligations I got delayed on this a bit, but think I've gotten proper TCZs made for the following:
AdvanceMenu 2.8 (Emulator frontend)
Compton 0.1~beta2 (Desktop compositor)
ePSXe 2.0.2 (Playstation emulator)
Kega Fusion 3.63x (Multi-Sega emulator)
libconfig 1.5 (Required by Compton)
Mednafen 0.9.38.7 (Multi-system emulator)
PPSSPP 1.0.0 (Sony PSP emulator)
QJoyPad 4.1 (Simulates keyboard/mouse inputs via gamepads)
However, I have a few questions before I submit them:
A couple are closed source applications, so I have no idea what compiler flags were used in their creation. Is that an issue?
For the .tcz.info files, on an initial build of something how should the Change-log: and Current fields be filled out?
I had to compile libconfig to get Compton's dependencies satisfied, which causes submitqc6 to complain that the TCZ is not in the repositories. Is this OK to just ignore and submit the .tcz.zsync file regardless?
Example Screenshot (http://sliverx.arc-nova.org/emuport.jpg)
-
You would need to double check that the license of the various packages allows them to be made available as extensions.
It is preferable not to use closed source applications, but where there is no choice and the license permits this can be OK.
For an initial build the info file should look like this: Change-log: first version
Current: 2016/04/15
In the case where an extension has a dep that is not yet in the repo, it is OK to go ahead and submit both.