Building a Replacement Server 2.0

I built my current server about five years ago as a replacement for my Sparcstation 20 so it could be retired from the role and used in a more desktop role. Recently the machine I built suffered what I thought was a hardware failure and hasn’t been up in some time. This has brought forward plans I’ve had for quite a while to replace it with something more power efficient. I’ve been struggling for quite a while to find something that is relatively cheap, but also more power efficient than the 60-100W my old Celeron 2.4 Ghz uses.

One option I had been investigating for a while is the plethora of small form factor PCs that are generally available. I looked at various offerings from Intel, Gigabyte and others that are available and found that whilst they were indeed quite power efficient, they also tended to cost quite a bit for a bare bones system that would require buying additional components. For this reason I decided it would be better to go for another option.

I had looked among my collection of old hardware for an alternative, and couldn’t find anything that was suitable, so I was going to have to buy something new. With small form factor PCs ruled out due to cost I had to do some research. I ended up finding some videos from Phil’s Computer Lab where he used old thin client machines for various purposes such as retro gaming or in some cases being able to play fairly modern games. Checking out the specifications of the thin clients they appeared to be reasonably powerful, efficient, cheap, and you get a complete system that require minimal additional components. Sounds like a winner!

I ended up buying an HP T620 thinclient with the 1.5Ghz Quad core AMD GX-415GA chip. It came with 4 Gb of DDR3 memory and 16Gb flash in the form of an M.2 drive. Whilst not terribly impressive specs for a modern machine, it’s fairly good for 2013 technology and is certainly better than the old Celeron I currently have. The most exciting aspect of the thin client is its power efficiency. I had a fairly good idea that it would be significantly better than the old machine because the power brick is 65W, so the likely maximum energy draw has to be less than what the old machine draws at idle. Being a low power device it is passively cooled and is completely silent in operation.

So I got out my kill-a-watt style power meter to see how much energy I could expect this machine to consume, I was pleasantly surprised. With the default operating system (embedded windows 8) it used a whopping 2W after boot at idle. Being so low I was completely astonished! I wasn’t planning on using windows as the operating system, so knowing the idle power may be different I went about the software install. Like previous server installs I’m using NetBSD again, partly because it makes it easy for me to migrate, but also just because I like it.

I had some difficulties installing because of UEFI, but once I resolved that the install went smoothly. Hardware support turned our fairly well, with all the major devices except the wireless working. Given I’ll be using Ethernet that’s not much of an issue for me. After boot on a clean install the idle power consumption is around 7W, which is still quite impressive. I suspect the higher consumption is because of the open source radeon driver not having good power management, which I can’t do much about at the present time.

The only issue I had after installing the operating system was the distinct lack of storage, 16G is not really all that much and I know that I’ll need more. Luckily these thin clients can take upgraded storage, mine has a mSATA slot that some revisions of this unit don’t. So I went online and bought a 120G Kingston UV500 mSATA SSD. Had my unit not had that slot I could have upgraded the M.2 drive to something larger. There are also a number of USB ports that could be used for external storage.

I’ve now deployed the new machine and I’m quite happy with the results. I’m quite happy with the performance, which I’d say is in large part due to the SSD storage. I like that it’s passively cooled because that makes it completely silent. Lastly the extremely low power consumption makes it very cheap to run, and I managed to get mine (including the extra storage) for significantly less cost than you’d pay for most small form factor PCs.

SS20 Desktop: Basic Web Browsing

Last time I looked at the relative performance of the CPU modules I have on hand, the HyperSPARC running at 90Mhz seemed to be the best option for using the machine in a workstation role. Today we begin to test this out by trying to browse the web. This sounds simple, but it’s actually quite challenging to do for a vintage machine as web browsers tend to require lots of graphics processing and there are very limited options available.

I have managed to get three basic web browsers compiled and working, Lynx, Links and Dillo. I’ve tried building others that are light weight with little success, more main-stream browsers such as firefox are simply too demanding to even try. Three potential candidates for future build attempts are ELinks, Midori and Netsurf.

The first program, lynx is one of the older programs, started in 1992 by students and staff at the University of Kansas it is still updated today. It runs from a terminal and has no graphical capability, because of this it is quite useful for vision impaired users as it works well with screen readers. You would be forgiven for thinking that lacking graphical display is a hindrance on the modern web, but lynx manages to make most pages quite readable. Well behaved/designed websites generally work quite well with some compromises on formatting, I tried google searches, reading on wikipedia and several wordpress blogs which all worked quite well. I was even able to use it to read my email via gmail. Unfortunately there are also plenty of sites that aren’t friendly to lynx (such as ebay), and page formatting isn’t always nice to read. These issues stem mostly from sites that haven’t crossed over to HTML 5, or ones that over use complex formatting. It performs quite well on the Sparc Station.

Links whilst having a similar name is a completely separate project to lynx. It offers the capability to run in a text-only terminal in much the same way as lynx, but can also be used graphically via X, SVGALib, or a frame buffer directly. This makes it quite useful on machines that don’t have a working X server. Much like lynx, well behaved websites are very usable and generally work quite well, again with some formatting compromises. It handles page formatting roughly as well as lynx does, but with the addition of images. This makes some websites like ebay more usable, although the formatting is still wonky at times. I’ve had gmail working on it in the past, but not today due to the current build or changes to gmail.

Dithering example

Performance on the sparc is pretty good, with short delays when images are being displayed for the first time. This happens because my sparc has an 8-bit display and Links will convert images using dithering and colour approximation. To maximise the number of colours it can use Links uses something called a private colour map. This is why other windows have their colours messed up whilst Links is in focus and vice versa. This sounds like it would result in poor image quality, however links manages this conversion quite well. The loading delay would certainly be shorter on 24 bit displays.

Dillo is a light-weight browser with a GUI that looks much more familiar for most users. It requires much more computing power compared to the others, but as a result it tends to display web pages with formatting closer to what you’d expect from the page. I found that many pages worked quite well, but others failed to display anything at all. It seemed to be an issue with SSL, I have the root certificates installed, but it still believed all connections had invalid certificates when clearly they didn’t. However you can see from the screen shot, that sites like wikipedia render exceptionally well.

Performance on the SparcStation unfortunately is quite slow, mostly whilst loading a page. Dillo can consume so much CPU as to even starve the X server of cycles, making it appear the system has frozen (when it hasn’t). From what I’ve read this could be because Dillo is multi-threaded, and is probably starting a number of threads upon loading a page. It may run significantly better on systems with more than one CPU, in my case switching to using the SuperSparc modules would possibly solve this.

Browsing the web on such an old machine was never going to be easy, some things just aren’t feasible such as javascript and video content. However it actually works reasonably well for reading static web pages and doing basic interaction such as posting a comment. Of the three browsers I’ve tried so far I think Links is probably the most usable, it provides images and formats pages reasonably well without consuming too many CPU cycles. Lynx comes second only because it doesn’t show images, it is a good option for text only browsing. Finally Dillo is probably just a smidge too demanding for my particular hardware and fails ungracefully with some sites, although it does provide the prettiest render you also have to wait the longest.

SS20 Desktop: Renewed Vigour

Last time I had started to finally get to grips with the system hanging issues, having found out much of the problem came down to the SMP kernel issues related to the on-board SCSI that are still prevalent within NetBSD releases. I was fortunate that I’d been given a chance to try out a patch that made SMP much more stable (although not perfect). This gave me essentially 4 different configuration options. After thinking about it, I decided it would probably be prudent to make some measurements to hopefully determine what the best way to go is.

I have three Mbus modules (pictured above), a dual CPU SuperSparc @ 50Mhz, a single CPU SuperSparc @60Mhz and a single CPU HyperSparc @ 90Mhz. The clock speeds can be a little misleading as there is a little more to each module. The SuperSparc modules each come with 1Mb per CPU of cache where as the HyperSparc has only 256Kb, and the dual CPU module runs on a slower Mbus @40Mhz whilst the other two run at 50Mhz. Additionally the rough guide to Mbus modules, an essential site for anyone with a sun machine like mine, suggested that the SuperSparc CPUs would actually perform better on a per clock basis. Given all this it’s not really clear which the best performers will be. From here on in I’ll abreviate SuperSparc to SS and HyperSparc to HS

Today we’re going to look at the results of some of the intensive benchmarks I’ve put the modules through, and at the end the best choice of configuration given the hardware I have on hand. All the tests are run with the same OS (NetBSD 7.1) and hardware with the exception of the Mbus modules under test.

The first set of benchmarks are aimed at measuring basic CPU speed. The benchmarks I’ve used are Dhrystone (version 2.1), Whetstone and both the double and single precision versions of the linpack benchmark. These tests are measuring single threaded performance of the modules.

Just looking at these charts it’s obvious that the HS is the fastest of the three modules. Given its higher clock speed that is to be expected, but it also attained higher scores per clock for all the tests except whetstone. The linpack tests show a large difference with the HS running about 12% faster per clock for double precision and about 22% faster per clock for the single. The Dhrystone test showed a much more subdued advantage, only running about 7% faster per clock. The Whetstone test showed the HS was slower, doing floating point arithmetic by about 11% slower per clock cycle.

Both SS modules performed about the same relative to their clock rate, which indicates the Mbus speed wasn’t a large factor in these tests, and that the data size was likely smaller than that of the L2 cache (1Mb). I would have expected the dual 50Mhz module to be slower in single threaded tasks as the Mbus is slowed to 40Mhz (as opposed to 50Mhz the others use).

I’m not sure how I feel about the results here, the data set size for the tests was almost certainly too small to even exceed the capacity of the HSs 256Kb cache. I’m not sure what to make of the linpack results, but the dhrystone and whetstone results seem to indicate the HS core is better at integer and string operations and the SS core is better at floating point.

I selected the next benchmark because it offered speed measurements over a range of data sizes. The Sieve of Eratosthenes is a simple algorithm for finding prime numbers within a finite numerical space. Rather than explain it myself look here on Wikipedia for more details. One of it’s key features is that it is quite hard on a CPU’s memory bandwidth, and it’s use of the cache is quite sub-optimal. I omitted testing the 50Mhz SS module.

The results are quite interesting. The HS enjoys an advantage of about 14% per clock when the data set fits within it’s cache, but suffers quite a performance drop once the data set gets larger. Despite being 30Mhz slower the SS is faster for data sets small enough for its cache but too large to fit in the HSs cache. I suspect this gap would be widest at just below 1Mb data size, but the program didn’t allow control over that. The worst data point shows the HS as 44% slower per clock. This is quite surprising, as the SS is not much faster than the Mbus speed (only 10Mhz faster) I didn’t expect the advantage in that data size to be so large. After 1Mb data size is exceeded, the HS starts to catch up again, but the data points don’t get large enough to know if it ever achieves equal relative performance again. I’d imagine that once the data is large enough both modules would perform close to the same as memory bandwidth becomes the limiting factor.

The next benchmark is similar in that there is measurement over a range of data sizes, but the algorithm is significantly different. The algorithm used is heapsort, a relatively efficient sorting algorithm used in many places. You can find more details here on Wikipedia. One of it’s characteristics is that it is much more cache friendly. Again I omitted testing the dual 50Mhz SS.

Looking at the graphs this test really requires some points at larger data sizes. I can only really guess, but I’d imagine that the performance would eventually converge given that memory bandwidth would eventually become the dominant factor. The previous test indicates that there may even be a window in which the SS performs better, but without actual data we will never know.

Given that I’ll be using this machine as a desktop workstation I ran a benchmark known as x11perf. It simply tests the maximum speed of components of the X11 protocol. It’s often known just as X for short, and is basically the software that unix systems use to interface to video displays.The chart shows performance relative to the dual 50Mhz SS (the yellow line represents it). A 2 is twice and fast, and 0.5 is half as fast. Each point on the X axis is a test, like line drawing for instance, there are so many tests (over 300) it wasn’t practical to separate and chart them individually. Out of interest I ran the dual 50Mhz SS with a MP kernel to see if it made any appreciable difference.

There are some quite interesting features of this chart. Firstly you’ll notice that both the faster modules have tests that are significantly slower than the dual SS (30-35% slower at worst). This is because those tests are CPU bound, and with a dual CPU module both the X server and client can have a whole CPU to itself. Typically those tests involve little actual drawing to screen, like plotting points.

In general the dual 50Mhz SS is slower than the faster modules. The SS @ 60Mhz is about 1.15 times faster on average and the HS is 1.75 times faster on average. The HS is in general the best on the raw performance numbers, with some odd exceptions. Some tests seem to favour the SS @ 60Mhz, which would be down to cache size.

Relative to their clock speed, the 60Mhz SS does better than the HS, but I’d imagine this would be due to the SBus limiting the maximum through put to the frame buffer. The SBus only runs @ 25Mhz so is almost certainly going to slow down a faster CPU when drawing.

The last and final test is one called Ramspeed. It’s basically designed to measure the memory bandwidth. I opted for the more general integer and floating point tests over the specific reading and writing tests as they are more likely to represent a computational load. There are 4 tests, Copy creates two buffers and copies data from one to the other, Scale creates two buffers and copies data from one to the other, but scales the number by some constant, finally Triad creates 3 buffers and adds two of them together (scaling one by a constant factor) and storing the result in the third buffer. All buffers are the same size. The tests I’ve chosen only test with buffers that are 32Mb in size, so much larger than the caches of either of the modules. You can select the buffer size and some tests available in the program test a range of sizes.

The results are pretty bad for the HS, it achieves slightly better speed only for the copy operations, which shouldn’t be surprising as the Mbus should be a limiting factor. However for the other tests the SS performs quite a bit better, so much in fact I ran the tests many times just to make sure. This would appear to be down to the memory and cache architecture of the modules, not just the cache size, although that is certainly playing an important role in the HS failing to perform. The HS does have significantly smaller L1 cache only having a 8k instruction cache versus a 20k Instruction and 16k data L1 cache in the SS core.

Having now spent a couple of weeks testing these modules I think we’re starting to get a picture of what these chips can do relative to each other. The HS is clearly faster as long as any data isn’t larger than its cache. The SS on the other hand isn’t as fast at it’s peak, largely due to a lower clock speed, but handles larger data sets significantly better. The X11 test showed that it is quite beneficial to have multiple CPUs in a workstation, even if only for basic X11 applications. However it also shows the HS being quite a good choice. I think the tests also show there was some merit to the idea that the SS modules performed better relative to their clock speed, but it also shows this is highly dependent on the work load.

So what am I going with and what would I recommend. With the hardware I have I’ll use the HS @ 90 for running the machine as a workstation as that makes it snappier to use in general. The flip side is that if I were to use the machine for a computational load, such as compiling a number of packages, number cruching, or a basic server the two SS modules would almost certainly perform much better as long as the job could be divided between the CPUs. Even the SS @ 60Mhz has a good chance of doing computation better on it’s own. The HS on it’s own is disadvantaged by not being able to multi-task as well, I have noticed that X is in general less responsive when the machine is under load (compared to both SS modules together), so a second HS module would probably be a nice addition in the future.

If money was no object and I could have any parts at all, both Ross and Sun had decent offerings. The fastest SS is 85-90Mhz, two of these would certainly be quite fast. However I’d imagine they probably wouldn’t be as fast as any pair of HS modules over 125Mhz. So in the end the HS modules would be the way to go if you had access to anything. As it stands, looking around online it’s actually really hard to find faster modules for a reasonable price. Among the SS modules those over 60Mhz are quite expensive and largely not available. The HS parts have a similar problem, but you can get 90Mhz – 133Mhz parts at fairly decent prices, although faster modules still command a high price, and slower modules wouldn’t be worth it. Again with what’s available the HS seems the way to go.

I’ve tried to be as thorough as possible, but if you want to see the raw data  and gnumeric spreadsheet with calculations and charts you can find them here.

SS20 Desktop: Kernel Issues

Over the past few weeks I’ve been continuing my work trying to get the latest NetBSD working on my Sparcstation 20. The system has been hanging and I’d had trouble working out why, so I turned to reading as much as I could to see if I could find any clues. I found in the mailing list someone suggesting that not all SCSI drives are co-operative with the on board controller when running a MP (multi-processor) kernel on later versions, so I looked through my collection of SCA drives to see if I had a different model I could try. I found I had an IBM Ultrastar disk that is around 18G in size, so I swapped the Fujitsu drive (model MAJ3182MC) out for it. Surprisingly this made my system behave much better, it would install, and run on the uni-processor kernel with no issues at all where the fujitsu drives seemed to cause the system to hang frequently under disk access.

However booting with a MP kernel still would hang within about 20 minutes or during disk access, so it was at this point I joined the mailing list to ask others what I could do to resolve the issue. The people on the list are quite friendly and have been very helpful in trouble shooting. It seems that there are some kernel bugs related to MP that are present in 7.1 that are at least partially resolved in more recent versions of the kernel. Like most open source OS’s the current stable release is behind by a version or two from where the developers are currently working. It seems that there is some possibility of the fix being back-ported to 7.1, I tested out a patched MP kernel that was greatly improved in this respect. It still hung, but after a much longer period of time, and only when provoked by a specific program. Feedback from the mailing list also seems to indicate that choosing not to use the on board SCSI is another way that I could work around the problem.

So I now have multiple options for running my system. I could switch to using a single processor, I’d have the option of either a 60Mhz SuperSparc (currently installed with a dual 50Mhz module) or 75Mhz Ross HyperSparc, and everything should work well. Alternatively I could acquire an SBus SCSI card to connect my hard drives, or forgo a local disk entirely by using networking booting and a NFS share, both avoiding having to use the on board SCSI. Finally I could use the system as it is now with the patched 7.1 kernel, it worked well enough that this is quite feasible. I’m leaning towards booting the machine over the network at the moment.

In the short term with Christmas approaching, I’ll be putting the project aside until I have more time in the new year.

SS20 Desktop: Some minor progress

Whilst it has been some time since the original post, I have been a busy beaver trying to get the old Sparcstation 20 running. I’ve been making an effort to get the hardware working with some mixed success, and have made much better progress with the software.

The hardware is of course the much more pressing matter for obvious reasons. I had a recurrence of the problem I had with stack under run errors and just general problems booting in general. Of course this lead me to suspect the hardware, so this week I went about trying to work out what exactly was causing the issue. One way to help determine which part is at fault is by stripping the system back to the minimal and gradually add components while testing the system in between. Having removed most components the stack under run symptom didn’t disappear, trying each memory stick individually didn’t improve things, so I began to fear the worst as surely not all the RAM I have is faulty. It was at this point I decided to run the set-defaults command to reset the computers configuration despite not seeing anything there that should cause any issues, this funnily enough seemed to do the trick, as far as getting the machine to the open boot prompt without any errors and passing all the diagnostic tests with everything installed. I had to scale back to a 17G fujitsu HDD as the larger one didn’t cooperate with the system.

At this point I breathed a big sigh of relief as my hardware is probably in working condition. It’s booting the OS (NetBSD 7.1) and seems to run fine with one problem. Random system hangs. There doesn’t seem to be any pattern such as when the machine is loaded down or network access. I’m guessing that the kernel is having some issue and tries to hand control back to the system ROM, but this some how hangs/fails. I might try running the machine with out the X server in case it is stopping any errors from being displayed. I looked into the kernel messages and noted a few devices that may also be the culprit. The kernel is detecting the on board graphics (comes up as sx0 in the messages) even though I do not have a VSIMM installed, as I’m using a SBUS graphic board instead. The audio chip in my machine is listed as a DBRI, which is known to have issues with the current kernel driver. If you try to play audio in any manner the system hangs, it’s been a bug for a while, it kinda worked under NetBSD 4.0 when I last had that running. With this in mind I’m building my own kernel with the drivers for these two devices and other unnecessary devices removed.

I’ve had much more luck getting software to build in my emulated machine. I’ve got a fairly large collection of software to try out. Although I did have trouble much earlier on when either QEMU or the emulated machine would hang during a build. I can’t be sure if that’s down to the emulation or if it’s a genuine issue with the OS, and a possible cause of my problems on the real machine. Whilst I haven’t really changed anything in the emulation, it hasn’t hung for quite a while, so it’s any bodies guess as to the cause when it did happen.

Progress has been slow, but I’m gradually getting there! I’ve seen some cheap Ross Hypersparc 90Mhz modules that I’m considering buying as an upgrade.

SparcStation Desktop project.

Unfortunately I’ve been neglecting my poor old Sun hardware, mostly because of time and space constraints. I thought I’d try to go some way to correcting this by actually beginning the process of setting up the SparcStation 20 as a vintage desktop work station. I’d been planning on doing this for ages, as long ago as when I built the replacement server machine.

Hardware wise I’ve not acquired anything new, although everything needed a test and some basic cleaning to get it working. I’m still having issues, but I’m unsure if it’s an hardware fault or a problem with the software I’m installing. We’ll get to the software in a moment, first we’ll look at the hardware installed.

At the moment I have 3 CPUs in the machine. They are all V8 Supersparcs with two 50Mhz chips on one module and a 60Mhz one on a module on it’s own. Each module has 1Mb of cache memory which doesn’t sound like much now, but was a large amount when these machines first appeared.

Frame Buffer

I’ve currently got about 304Mb of memory installed, I had more but unfortunately one of the sticks that was in it fails to detect anymore. I’d like to have a VSIMM as that would allow me to use the built in cg14 frame buffer (graphics card) which is probably the best performing one available for machines of it’s type. I managed to purchase a 2Mb TGX+ frame buffer and adapter to connect it to a VGA screen, which is doing an odd resolution of 1152×900 at 8 bits per pixel. It’s obviously not the fastest, but it does the job. I’ve selected an 136Gb 10K RPM SCA drive for the hard disk, certainly a bit of overkill, but it would just be sitting on my shelf otherwise.

The initial issue I had was stack under run errors after the boot screen came up and the machine attempted to boot. My first instinct was of course failed memory, which lead me to find the undetected memory module. But no matter which memory I ran I had the same problem. After some poking into the system environment (kinda like the BIOS settings in the PC but without the nice interface.) I found some items that were not at their defaults and changing them back seems to have fixed the stack under run.

Dual CPU MBUS module

Unfortunately that’s not the end of the issues, as after installing and running NetBSD for a while the machine will hang, reset or have a watchdog timer trigger. This certainly could be faulty RAM, but the power supply is also a potential suspect as is the operating system itself. I need to follow this up with some more testing, unfortunately I don’t have a spare PSU to test with.

Software wise I’m much more prepared and have had much more success. I’ve been using Qemu, which does full-system emulation for a number of old and different platforms, including Sparc systems. Qemu has been useful for building packages and the kernel specifically for my machine. Something I had done ages ago when I first intended to do the install.

At the time I built for NetBSD 6.1.4 which is the OS I’ve installed and tried out on the machine. It’s out of date by quite some margin now, so I’ve set up a new virtual machine to start work on getting 7.1 packages and kernel built. It has a bunch of improved hardware support, particularly in the frame buffer acceleration, so I’m keen to see how it goes. I’m still building packages I want for it, but I’m happy with 7.1 under qemu so far. I’m hoping the improved hardware support helps with the hang/watch dog/reset issues.

When it’s all done, I’ll post about what it’s like to use the machine for specific tasks, like say browsing the web and checking email.

Xsokoban on NetBSD

Having been busy and stressed out lately I haven’t had much time for tinkering or gaming. This is where smaller games that you can play as a quick distraction can help, as they are easy to squeeze in between other jobs, and todays game is one such game.

Xsokoban is obviously a clone of the old classic game sokoban. The original was made for the PC-8801 way back in 1982 by Thinking Rabbit. It has since been implemented and ported to pretty much every system, Xsokoban is one such port for Unix systems running X windows.

There isn’t anything really remarkable about this particular port. The quality of the graphics is quite reasonable, and it works well on pretty much any system I’ve tried it on including my older machines such as the Sparcstation 20. I’ve even played it over SSH via my comparatively slow ADSL2 connection, and it worked really quite well.

Interestingly the game has been studied in the field of computer science, it turns out it’s quite a difficult problem computationally, being PSPACE-complete. Lots of different researchers have worked on different algorithms for solving and producing optimal solutions. The complexity certainly makes me feel better about getting temporarily stuck on level 6!

As far as enjoyment goes, it’s really enjoyable for the puzzle solver in me, even when I’m stuck. It doesn’t take a huge commitment to play for a short while, and is quite challenging! This particular port isn’t any better or worse than any other, so don’t go out of your way, but NetBSD and FreeBSD users will find it easy to get running.

This slideshow requires JavaScript.

3rd Aniversary and Work on the Sparcstation

This weekend marks the third year I’ve been writing this blog. The first thing I wrote about was my Sparcstation 20, which I had just acquired at the time. I installed NetBSD 4.01 on it, which was reasonable then, but has become quite out of date now. So 186 posts and 3 years later I’m in the process of upgrading the machine to NetBSD 6.1.5.

Machine without the PSU

This has been a long time coming, and there are a number of reasons for the upgrade. Firstly, the older version of NetBSD was becoming more difficult to keep software up to date on. I had stuck with 4.01 for some time because of performance issues I had when trying out 6.1.2 last year. But some packages didn’t update properly lately and I had been left with some software working and others just becoming broken. I could have stuck with an older version of pkgsrc, but that has problems as well.

Another reason is I’ve received the hardware required to use the machine as a desktop machine with screen,keyboard and mouse instead of a headless server. I retired the machine from active server duty and built a replacement server quite recently to facilitate both upgrading the OS and hardware to try and make it a practical desktop workstation. I was very fortunate to receive a donation of a keyboard and mouse suitable for the machine, and have since bought the frame buffer card and adapter to complete the hardware necessary.

Frame Buffer

I got the hardware up and running last weekend and powered up the machine with everything set up for the first time. I was happy that without upgrading the OS, I had the display, keyboard and mouse all working with an X server with little effort. I was impressed that the X server seemed quite speedy compared to what I expected. However X server (Xsun) was really outdated and didn’t seem to support everything thrown at it.

So I began to install NetBSD 6.1.4. I found it was best to use the serial console for the install as the install disk does not handle the sun console on the frame buffer properly. It seems that it just doesn’t have the TERMCAP entries for the sun console, as once the system is installed the console works fine. The install worked pretty much the same as the older version with a few minor changes. The performance of 6.1.4 seemed better than the last time I tried an upgrade, but still isn’t as fast as the older 4.01 release.

So I’ve begun building the system from sources to take advantage of the V8 Supersparc. I’m assuming the binary distributions you download are actually built for the slower V7 Sparc that can be common in some of the other older and slower machines. The build process is surprisingly very easy to follow. We will see if there is any significant difference when it’s finished building.

 

Building a Replacement Server

I’ve been using my old SparcStation 20 for about 3 years for storing my source repositories, allowing VPN access and web serving among other functions. I originally set it up like this as an interesting project to see if I could make good use of exceptionally old hardware with more modern software (NetBSD in this case) and it turned out to be quite handy. The experience as a whole has been a very positive one.

Sun Keyboard and Mouse

Now the time has come to not so much retire the SparcStation, but move it into a new function as a vintage workstation. I was very fortunate to receive a donation of a type 5c keyboard and mouse suitable for use with it, all I have to get is a frame buffer card and I can plug in a screen and use it as a desktop. Fortunately frame buffer cards are much easier to find than keyboard/mouse combinations so I shouldn’t have an issue finding one.

Having decided to build a new server machine, I went looking through my collection of old hardware to see what I could build out of my spare parts. I already had the large tower case recently donated, so I checked out what was installed in it. Turns out it was a Duron 800, which is quite reasonable, but after measuring its power consumption (about 70W without hard drives) I decided I could make a machine that was cheaper to run with some other parts.

Obviously I want something more efficient than the SparcStation, which uses around 130W with everything installed. It turned out to be quite difficult to find x86 hardware that is efficient once everything is installed. After looking at what I have and doing a bit of research I decided to try out the old Coppermine Celeron 800Mhz as it had quite a low TDP. Powered up with a graphic card but no hard disks it used about 60W, unfortunately it didn’t want to boot, and no amount of prodding got it to work.

Looking in my collection of old hardware I didn’t have many alternatives. I could use a socket 7 based system, but that would likely be _slower_ than the sparc and may use a similar amount of power. I have some Pentium II boards, but I wanted them as spares for my Win98 system. In the end I used some suitable socket 478 (Pentium 4) hardware, which initially looked bad efficiency wise. The P4 of course was known for running hot, and hence also using lots of power.

My older brother donated a MSI socket 478 mainboard to me some time ago without a CPU. I looked through my collection of CPUs and found a Celeron 2.4Ghz and heat sink. I installed it and 1Gbyte of DDR and it worked with little effort, but the power consumption without hard disks was about 80 something watts, not ideal. I decided to press on with this hardware as I had no other vintage parts that would be suitable, and that power usage ought to be the worst for the board and processor. That and I don’t have money for new hardware at the moment.

Machine Assembled

So I assembled the machine in the chassis with a Pioneer DVD drive and two Western Digital hard drives. I selected two 80Gb ATA WD drives as they turned out to have the best power consumption and reasonable capacity. All together, just sitting at the BIOS screen the machine used about 100W. Again a worst case and not that great a saving, but at least it’s significantly faster.

I decided to stick with NetBSD for this build for a few reasons, firstly it is simpler to migrate the configuration and data from the old machine. Secondly I like NetBSD because of how light it is and how easy it is to work with. I downloaded the latest version (6.1.4 as of this writing) and went through the install process. Installation was fairly easy, but I couldn’t get X to work correctly on my hardware. I didn’t have a local X server before, so I didn’t worry about getting it to work beyond XDMCP.

After installation I measured the power consumption of the machine at idle, I was pleasantly surprised that it dropped to about 65-70 Watts, a nice improvement over the sparc. Power usage peaks at about 100W when the machine is under full load as I first thought. After setting up the hard disks to power down after idle for a while I managed to reduce this to just bellow 60W.

I’m now happy with the hardware I have set up, although I could use modern hardware and save even more power. I’m currently in the process of setting up the software. I’m rebuilding the kernel and userland for NetBSD. It’s a surprisingly easy process, and well worth it especially for older hardware. I’m not ready to deploy the machine yet, but it looks like it will work well.

Artsoft games on NetBSD

R’n’D Menu Screen

Today I am looking at two games for Unix systems called Rocks’n’Diamonds (R’n’D for short) and Mirror Magic. Both were developed by Artsoft which seems to consist of one person, Holger Schemel. Both games are sort of clones of older games for much older platforms. Rock’n’Diamonds is a Boulder Dash like game that was first released in 1995 and last updated at the end of 2013. Mirror magic is very much like Deflektor, originally released in 1995 and updated until 2003. Whilst both games are based on older games they both add features to the old formula. Today I’ve built and played these under NetBSD on my SparcStation 20.

Text Box

Being made by the same person, both games share some similarities, particularly in the art style. The menus and sprites are very colourful, they almost look like they belong at a carnival. Everything is well drawn, animated and items look like they should. Items brought over from the older games have been updated graphically, they don’t look identical to the originals but are also easily identifiable for players of the old games.

Green Goo

They run of the same graphics engine originally developed for R’n’D which supports X11 and SDL mainly. The X11 versions work quite well, even on exceptionally old hardware like my old SparcStation 20 which is quite impressive. They work moderately well over longer distances via SSH, but the latency and bandwidth can be a problem on slower links whilst LAN speeds works flawlessly. There is a SDL version, but the version I installed (from Macports on my macbook) seems to be significantly slower than even X over SSH. This is hopefully just something peculiar to the Macports version on Mac OSX.

Playing Via SSH

Both also have the same sort of sound engine and from what I can experience on the Macports version they are good for what they are. I only got to test sound in R’n’D and unfortunately during game play you can get swamped with the same sounds playing repetitively. So you might enjoy your playing experience more with the sound off. Playing on NetBSD on the old Sparc machine this wasn’t an issue as sound doesn’t work there.

Mirror Magic Menu Screen

The game play for R’n’D is interesting in that it combines elements from games such as Boulder Dash and Sokoban, and includes most of the elements added by Supaplex and Emerald Mines to Boulder Dash. The game has three game engines that any level can use. Rocks’n’Diamonds, Supaplex and Emerald Mines. The later allowing levels from those games to be played and solved as they are in the original. I haven’t played enough of the levels to give a good impression of what they are like as a whole, but those that I have played have been fun. I did try levels from the older games and they seemed to work quite well.

Holy balls of steel!

Mirror Magic similarly has its roots in older games, specifically Deflektor and Mindbender. Basically there is a Laser, a bunch of mirrors, obstacles, and stuff to destroy in the levels. You need to direct the laser with the mirrors to destroy objects in the way and get the beam to the target. Usually this requires destroying all of the metal spheres in the level. You have a limited amount of fuel, and the laser can over heat if the beam hits the wrong type of object. It’s important to keep an eye on both the fuel and heat gauges as running out of fuel or over heating can sneak up on you. What I’ve played so far has been quite fun, although I was disappointed that only levels from the old games were included.

Balls busted

Both games have a level editor which is easy to use. The editor in R’n’Ds is quite flexible and allows users to create their own custom objects that behave differently to the stock ones. This allows people to make all sorts of different creations, one even claiming to have recreated Zelda! There are lots of different level packs available on the Artsoft website for R’n’Ds, but not really any for Mirror Magic. In either case, if you do happen to beat all the levels there is still lots of gameplay in the user created levels and building some of your own.

What Mc Duffin?

Despite being based on older games that are well known, I think both of these games bring something new to the table. R’n’Ds brings many more levels including user created ones and variety in game play that the original games didn’t have. Mirror Magic is a decent remake of the originals with the addition of a level editor. Both run on Windows, Mac OSX, Linux, and BSD. There is even a DOS port of both although the port of R’n’Ds is a little out of date. If you like any of the old games on which these are based you might wanna give them a try.