Simcity for DOS

I see a Sign!

Simcity was developed by game designer Will Wright after having worked on a game called Raid on Bungeling Bay and finding it more fun to build the levels. The original Simcity was made for the Commodore 64 in 1985, but it wasn’t until 1989 that it was first released commercially on the Amiga, Macintosh and later IBM MS-DOS systems. It was ported to many platforms including at one point several forms of unix.

City map

My older brother was the first in the family to come across Simcity at school, they were running it on some very old school 8088 PC clones that had Hercules graphics and only PC speaker sound. When we got our 386sx machine in early 1990, it was because of my older brother that Simcity was the first game that got installed.

Heavy Traffic

Simcity quickly became a favourite amongst the family, we built many cities of various sizes, and challenged ourselves by restricting what we would build with. We used the disasters to keep the game interesting when we filled up the map, or we would just start building another new city to see if we could fit more people in. One challenge we set ourselves was quite interesting. We set up a map filled with nuclear power plants (this required the funds cheat) then wait for the numerous meltdowns to destroy most of the reactors. We had to try build a city in amongst the rubble and radiation, they usually didn’t get very big.

AAAH! Godzilla!

We originally played it using the hercules graphics mode, and later the EGA high-resolution colour graphics. The game supported pretty much any PC of the time graphically, and looked pretty good in the process. The colour EGA graphics are very colourful and pleasing to the eye. They animated quite well on our 386 machine, but on slower machines it could be a bit slow.

This city has a certain glow.

Sound came in the form of either PC speaker or Tandy sound support for those machines. It had a sort of pseudo digital sound output that some games had at the time. If your machine and speaker were good enough the speech in the sound effects was much clearer, but most of the sound effect were quite audible on most hardware.

Tasty Pollution

The great thing about the game is there is no winning or losing condition. You can pretty much do what you want with your city, whether that be large populations, design experimentation, or just simple destruction. There were a few scenarios that did have winning conditions, and you could be thrown out of office if your were doing a _really_ bad job, but we rarely played the scenarios and almost never got kicked out.

A happy city… sorta.

There was so much fun to be had with the game, we played it on a regular basis for pretty much the entire life of the old PC. It holds many nostalgic memories of both myself and my brothers playing it on a lazy summer afternoon. I’m pretty sure it’s one of the reasons some of the keys on our old keyboard got worn. If you’ve somehow been living under a rock and never played the original, I’d highly recommend you give it a go. There is a free version called Micropolis that is free and open source, but can be hard to get working. Stick with an old copy for either DOS or your favourite retro-computer platform.

Upgrading the SparcStation

This weekend I was fortunate in that I finally got another mbus module for my Sparcstation 20. I was however  unfortunate in that my data drive in it has failed. Because I back up on a regular basis, nothing much was lost, just some work I had done over the week that I also have stored elsewhere.

The machine had only 2 2Gb drives in it previously so I decided I would take the opportunity to also upgrade the hard disks. I had two fujitsu 18G  10K rpm drives set aside for just this purpose. Seeing as this would mean re-installing the OS, I thought I’d give the latest NetBSD (6.1.2) a try on the machine.

The mbus module I got is a SM61 that fortunately works out-of-the-box with the dual 50Mhz processor board I already have. Sun Sparc machines are unusual in that they support mismatched processors running in the same system. In this case as long as the motherboard is happy, and the processors are the same architecture (supersparc) everything is peachy.

So I burned a copy of the NetBSD 6.1.2 install disk and began the installation process. I noticed straight away a performance difference between 6.1.2 and the older 4.0.1. It seemed bogged down and slow compared to the older release for some reason, and the install disk would not extract the system from the CD. I had to instead use HTTP to get the base system installed.

I installed some packages including a benchmark utility called bytebench. Benchmarks like it are useful for determining if there is any change in speed of the system. I was unimpressed that the test results said the machine was _slower_ despite having an extra processor and faster hard disks. The old NetBSD with old hard disks and only 2 cpus would get about 7.2, where as the new setup maxed out at 6.2.

It may be possible that it requires a recompile to make it work faster. I suspect the distribution is compiled for the lowest cpu in mind, a V7 sparc. This system has V8 processors and should be faster. I however don’t really want to spend the time compiling the entire system, just for what might be a small gain.

Instead I’m reinstalling the old 4.0.1 version of NetBSD. Fortunately there isn’t much disadvantage in doing so. I’ve been able to build packages from recent versions of pkgsrc without a problem, and everything seems to work. I noticed the improved speed as soon as I fired up the installer. I have a bunch of binary package builds from the last install I had so that will also save me some time. I may try building this system from sources eventually if I have time, we’ll see if it makes a difference.

Some words on X windows

I’ve recently been reading about and watching a few videos about the replacement for X called Wayland. Now I know very little about Wayland itself, but I’ve been a user of X since about 1999 when I first went to university, so I can’t help it, I feel moved to write about my current and old experiences. X is actually really quite an old protocol and was designed with different goals in mind than those modern desktop environments have today. The history is written all over the internet so I won’t repeat it, but it is evident that X was originally meant for the X-terminal connected to a mainframe case that was so very common at the point of its inception.

One of the questions asked was “what does X do well?”

Lincity via SSH

The core of the X protocol is based around drawing primitives such as lines and circles but also includes pixmaps (bitmaps for those who don’t speak X). Here is an example screen shot of a program, lincity, that was one of the first games I wrote about here on my blog. In this case I’m running it through an SSH tunnel over an ADSL line with a maximum upload rate (to the X server) of about 75Kb/s. Because of the way X works lincity is not only able to draw to my remote display, but is able to animate the play area at a reasonable rate. This situation is something which VNC and RDP just can’t do over my connection. The remote machine running lincity is my old Sparcstation 20 with 2x 50Mhz supersparc processors, running a pkgsrc build at the same time.

Working remotely

Here is another screenshot of me monitoring my old Sparc, again doing a pkgsrc build (they take a long time with only 50Mhz you know). I’m able to get real time performance graphs and interactive terminals, all using about 5-7Kb/s data through a SSH tunnel, and much less when the remote windows are not visible on the screen. This kind of use if very common for me, not just to old machines, but also modern ones that are around my workplace, X and SSH makes it easy to start a program from any machine. This is very handy for testing and I can run software from home or work as I need.

XDMCP Chooser

My machines at home are running NetBSD, FreeBSD and Gentoo currently and whilst some of them are capable, none currently have a head attached. So I frequently use XDMCP and a X server on my windows machine to access them, and it works basically flawlessly. I realise this is a less common situation now, but with thin clients becoming all the rage in different forms, it seems this feature of X could be exploited more.

FVWM on my Sparc

I love that there is so much variety in window managers and that there are light ones that make even my oldest machine quite usable with recent operating systems. Pictured here is my nostalgic favourite FVWM, which incidentally is still being maintained and developed. Windowmaker, openbox, fluxbox, etc, all deserve to exist and have a dedicated user base. They are interesting and useful, but mostly truly light-weight, making using older hardware viable. People like myself who collect and use old hardware find this useful to keep life in their old pride-and-joys.

No matter how it is implemented under the hood, for users the network feature of X is seamless and very easy to use, in no small part due to the hard work of the X11 developers, many of whom are working on Wayland. So what motivated the big change?

One of the major factors is X is becoming too large and difficult a project to develop and manage. A contributing factor to this is the explosion in extensions to it that made it kind of bloated. It seems they were sort of added willy-nilly (mostly during the Xfree86 days) to meet the demands of people developing the more eye-candy based style desktop environments we see now. Fortunately the X developers have been cutting much of the debris out of the extensions and have made the X server modular. Now if only the X server was actually installed/packaged in separate modules for each extension and the core it might make having a slimmer server easier, but as far as I know that’s not possible.

Personally I’ve not had much trouble with X. I mostly had problems with getting proprietary drivers to work for my GPU back in the Xfree86 days, but I’ve not had that problem in ages. I have only really seen the flickering that has been talked about over high latency network connections, never over any LAN I’ve ever used. I understand that it probably does have huge design flaws, and that a newer system and design is needed to meet the needs of new desktop environments. I just feel somehow, that when it’s gone I’ll miss X.

Robomaze II for DOS

Be thankful this site has no sound!

Being stuck in bed the past few days left me some time to peruse some of my favourite DOS game websites. Recently I found Robomaze II on the RGB Classics website, I read that it was fondly remembered by many. You’d think with II in the title that it would be a sequel to an earlier game, but there is no Robomaze I. The game was released back in 1991 by a company called MVP Software, but developed by a company called Wetware. I hadn’t really heard of either company before, but I found that MVP had a catalog of about 20 odd games spanning both DOS and Windows 3.1.

Shareware professionals member!

It supports both CGA and EGA graphics cards and appears to have been designed for older XT, AT and early 286 machines although there were many 386 machines around at the time. I ran the game in EGA under Dosbox, and it seems the best way to play it for reasons I’ll explain as we go.

The first reason to use Dosbox is related to the animation speed. Faster CPUs cause the animations to run way too fast, and adjusting the speed in game doesn’t help with faster machines. Fortunately you can use the cycle count in dosbox to adjust the CPU speed. I thought the EGA graphics were reasonably well drawn and animated, but sometimes it isn’t clear what somethings actually are.

Ah silence!

The sound comes from the PC speaker, and if you have it enabled be prepared for some horrible music at the title screen. Seriously it’s bad, so very bad. The in game sound is limited to some basic sound effects and thankfully is much better, but still nothing fantastic to write home about.

So having started up the game and having my ears raped by the horrible sound, I tried to read the instructions and story but was faced with a wall of all uppercase text that was difficult to read! I managed, but it sure would have been nice to have lower case letters and some better formatting.

First Level

The games controls are pretty simple, but not the usual for PC platform games. You control your player with the arrow keys, you press left or right to start moving, down to stop moving and up to jump. When you press left or right you continue to move until you either drop, hit something or press stop. This produces some of the most awkward movement I’ve had in a platformer, but I guess you could get used to it. The space bar fires your weapon, and there are some other keys used for special abilities.

Decoration?

I’d personally recommend you use a joystick, which is the second reason I used dosbox with this game. You can use the mapper to use the keyboard, or connect a modern joypad.  Not having a game port on my capture machine meant I had to use my USB game pad. The joystick controls are far easier to handle and behave a bit more like you’d expect. You still need the keyboard nearby for the special abilities.

The hanging gardens

Aside from the controls the game is relatively nice to play, but there are some annoying points. Firstly there is quite a distance between check points. If you die or need to save and reload you go back to the last check point. It can be quite punishing of mistakes. I was also annoyed by moving platforms, since they crush the player you can find yourself being unable to avoid taking damage.

In summary, there are some things to like about this game, but you’ve got to be able to get past it’s weak points. This one is probably best left to those who remember it nostalgically.

Frame buffer and hard disk follow-up.

I investigated a couple of interesting things hardware wise yesterday that may be of interest.

Frame buffer

Firstly I tried out the Sun Wildcat Expert3d lite frame buffer card I got during this week. To my surprise it does indeed work with my systems, in fact it seems to be hardware compatible with both of them.  For those who haven’t read my earlier posts, I have two more “recent” Sun machines, a Sun Fire R280 and a Sun Fire V440. I tried the frame buffer card in both machines and the ROM not only recognised the cards but displayed boot messages on the screen.

I don’t have any Sun keyboards or mice for either machine so I wondered if I could use a standard HID compliant PC keyboard and mouse. This also surprisingly worked quite well both systems recognised the keyboard as being connected as long as you plugged it into port 0 (the left most bottom connector looking at the back). I wondered what issue people were having with these machines, I didn’t wonder long.