Image Map Image Map
Results 1 to 2 of 2

Thread: Solaris 8 / Debian 7.1 + Games onto Sun Ultra 5 - A long story

  1. #1

    Default Solaris 8 / Debian 7.1 + Games onto Sun Ultra 5 - A long story

    Hi all,

    I've had a big-win of sorts with my Ultra 5. As some of you know I've started a few threads lately about the Ultra 5; mainly to do with installing Solaris and graphics card hardware.

    Well after spending about 30+hrs on Solaris 8 I decided that it just wasn't going to cut it. I had two main issues; firstly was my lack of experience with the 'down to earth' unix system administration. I'm not bad with the newer linux stuff; however I really struggled here. Things were in different places; configuration files were different etc. Simple tasks were taking me a long time googling; then blundering through until something worked. That wasn't the worst of it though; the show stopper was the lack of repositories for precompiled binaries. I found a useful site which an enthusiast maintains that had some common precompiled binaries (see here) however these mainly pertained to development tools, compilers and the more common essentials. I thought this might be enough but it wasn't.

    This was the final roadblock for Solaris 8. My aim was to compile at minimum a couple of game engines, chocolate-doom and scummvm, and then be satisfied. The a base dependency for both of these is SDL2 which needed to be compiled from source. No matter what I tried the compiler would fail trying to make SDL2. The annoying part is that someone has done this in the past (I've seen screenshots of the chocolate-doom engine running in solaris . Further investigation found that this was done with an older version of SDL (SDL1) which is no longer supported. As far as I could tell nobody has compiled SDL2 on Solaris 8; so there probably was incompatibilities in the code. I'm not a programmer by default; I do it when I have to but that is it. As such I gave up on Solaris as I didn't want to bombard the forums with too many questions.

    I then decided to try Debian 7.1. I went with 7.1 because I've experimented briefly with Debian on the sparc before. Anything newer than 7 is a bit broken; nobody puts much effort into compiling binaries anymore and it's rare that it 'just works'. Debian 9 is so bad that it can't even detect the CDROM in the machine so the installer fails before it even partitions the hard drive. Older than 7.1 gets tricky to find working binaries/repositories. Those that work have old versions of software which can be problematic. 7.1 is still relatively current, repositories are all there and it runs pretty fast on the sparc (easily as fast as Solaris .

    Installing 7.1 is a pretty easy task. Follow the prompts and it will generally work. One place it will fail is if you select 'debian graphical interface' during the optional packages part. I always leave this off and install xorg manually once the base install is complete. It will also fail to find the debian security repositories for 7 (I assume they have taken them down) however since this is a hobby machine that isn't an issue for me.

    Once installed I did a series of apt-get's to install xorg, compilers, and other assorted bits and pieces. I chose jwm as my window manager as it's super lightweight, at least has a menu for a terminal, plus runs really really fast on the older hardware. Once that was done I launched into compiling SDL2 in preparation for chocolate-doom and scummvm. On my first build this required little effort, I had to do a few more apt-get's to fulfil some compiler dependencies, mainly for development libraries for x-windows else it failed to build a video driver. Once done I compiled and installed, along with some other SDL2 addins such as mixer and net. Chocolate-doom then compiled fine and it was time for the test run...

    Well the first test run was a complete bust. It loaded, but man was it SLOW. I mean like 1 frame per minute slow. I checked the terminal output for the executable and noticed it warned me that I was using a software implementation of openGL. What?!?. Doom is a 2d game; it shouldn't need openGL? As it turns out SDL2 detected that I have an ATI Rage based chipset (with crappy 3d core) and also noticed I had a software implementation of openGL. It suggested I alter the doom config file to force software rendering (this stops software->fake hardware->software->screen). I did so and it still was very slow, but improved. The sound was super choppy and I noticed a lot of 'ALSA buffer underruns' in the terminal output. I then launched the doom setup which, like doom before, ran at about a frame per minute. Patiently I disabled all the sound options and relaunched doom. This time it worked GREAT! It was fast as ever! I was still not satisfied without the sound though... I started by reenabling the sound effects, but left the music turned off. This worked alright, however I think I noticed a slight slowdown (but it was ok). The music on the other hand was a dead loss.

    I then moved onto ScummVM. This compiled with minimal effort, but when it loaded to the opening screen it was slow like the menu in doom. I figured it was still using openGL in software to render, so I thought about it some more. The option I went with was to disable openGL support when compiling SDL2. The graphics card is so bad that I would never use it anyway. So I recompiled SDL2 using --disable-video-opengl --disable-video-opengles and --disable-video-vulkan. This disabled all hardware acceleration and only left the X11 driver.

    ScummVM then loaded up like a treat. It still had a tiny bit of cursor lag, but it was minimal and expected on a machine that only runs @ 360MHz. What didn't work like a treat was the sound! Same deal as doom; music was a complete bust but the effects worked ok. Same error too, 'ALSA buffer underrun'. I played around with the pulseaudio buffer size and number of chunks but it made little difference. Google helped here a bit, but none of the suggestions actually worked well enough.

    Scratching my head for a while lead me to realise it was the MIDI music that was causing issues. I'm not 100% sure how SDL2 handles MIDI; but my guess is it uses a software wavetable to generate PCM. The other guess I made was the sample rate conversion that must be going on; the sound card is at 44100kHz and the sounds produced by the games in ScummVM and Doom certainly are not that high. Both issues on a modern machine wouldn't be an issue because there is so much excess CPU power it just sucks it up. On my old sparc this is not the case.

    I played around with a ton more settings in pulseaudio trying to fix it up. Sample rates, buffers, upmixing etc. Nothing really made it work; some settings made it slightly better though (but still way way off the mark).

    I then recalled I was pretty hasty in compiling SDL2 and related libraries. When the configure scripts finished it listed a number of features it would use. A lot of them said "NO" which I ignored at the time as it didn't fatally error, but now I wondered whether it would make a difference (i.e. it's using a crummy software algorithm to process sound rather than a tweaked one). In my previous efforts I managed to brick ALSA pretty badly (tried to recompile libraries from source, caused an incompatibility with the kernel module). It was time to start fresh.

    I will return with part 2 - this involved a fresh install on another hard drive. That in itself was an epic journey, turns out these older sparcs won't boot from every type of SCSI HDD and I spent 3 hrs fixing a trap 3e error....
    System 80 Expansion Interface located! Thanks to all who helped out and the good people in the NZ vintage computer forums!

  2. #2


    Since I'm a bit short on time part 2 will be coming a little later....

    Until then here's a couple of (crummy) pictures....


    System 80 Expansion Interface located! Thanks to all who helped out and the good people in the NZ vintage computer forums!


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts