16
Dec
14

Improving Joystick support for Bob’s Fury

Some of the hardware support within Bob’s Fury has been far from ideal, the joystick/game pad being one such device. I had only added support for a simple 2 button joystick, as that’s all I had when I first wrote the code a long time ago. It proved to be inadequate as there just simply wasn’t enough buttons to support all the functions in game, and you couldn’t choose what the buttons do.

Old Joystick Configuration

Old Joystick Configuration

So with the aid of a real machine and a Gravis game pad I worked out how the basic 4 button devices work. It turns out they aren’t much different. I had originally coded my interface to expect two joysticks, each with 2 axis and 2 buttons. It turns out that the buttons on the second joystick correspond to the 3rd and 4th buttons on the Gravis game pad, which means it was fairly simply to allow such a device to support 4 buttons with a minimal effort. I re-wrote the joystick hardware code to be a single joystick with 4 buttons and axis which should support most devices.

New Configuration Screen

New Configuration Screen

Once I got the joystick code re-worked I didn’t want to give fixed functions to the buttons, so I had to recode the configuration interface to allow changing what the buttons do, which funnily enough took longer to get right than the hardware side of things. After some testing in Dosbox I’m pretty happy with the result. I still need to test on some real hardware to make sure everything works, and I need to test a two button joystick to ensure that still works as well. I’ll update the download once I’ve tested it on real hardware.

10
Dec
14

Redhat Enterprise Linux 7.0 Workstation

At work I have been using Redhat Enterprise Linux 6 for some time to run some multimedia equipment. With the need to upgrade to new software and hardware I’ve had to also look at upgrading the OS to meet some of the requirements for the new software. The new version has some significant “upgrades” in the form of using Gnome 3 and systemd, lets see how good they are.

The desktop

The desktop

Gnome 3 is a significant departure from the previous version, it is clearly heavily influenced by Mac OSX and tablet interfaces. Personally I am not a huge fan. Most of the customisation features that were in Gnome 2.x have been removed. Some I miss the most are placing application launchers and widgets on panels and having a proper visual pager for the work spaces. There seems to be very little option for any customisation at all.

There are some small improvements however. The configuration dialogue for the network setup is nice and simple, but still allows for more advanced settings if required. The calendar is cleaner and incorporates your schedule information in the display. Still it somehow feels very uninspired.

Mac OSX like controls

Mac OSX like controls

Even the lock screen leaves something to be desired. It expects you to uncover the password entry box by swiping upwards or doing the equivalent with your mouse before you can enter your password and unlock the screen. This is annoying every time I come back to my computer as it adds an extra step to an otherwise simple process, it is completely unnecessary. From what I can tell it was added simply as eye candy.

Gnome 3 certainly isn’t ugly, it is full of eye candy everywhere. Lots of animations and fades that you couldn’t do on older hardware because of performance concerns. But I find the lack of customisation features makes the desktop feel sterile, I can’t make it my own, which is something I’d expect from Apple, not a open source desktop environment.

Systemd components (from wikipedia)

Systemd components (from wikipedia)

Systemd is the other perhaps more controversial change, there has been much debate and flaming across the internet from both sides. Basically it is a replacement for sysvinit and a number of other small daemons such as cron and the login process. I did note in this instance that RHEL 7 still includes and runs crond and rsyslogd even though systemd has replacements. I’m guessing they are _trying_ to ease the pain of migration.

I had a look into the configuration files for systemd, and whilst they are at least readable and you can edit them, there are many options that aren’t clear. It is however easier than the old configuration system under sysvinit, but no-where near as nice as the RC system under BSD which is much easier to handle. The thing I felt was the most concerning is the binary log files, which fortunately you don’t need on RHEL 7.0 because of rsyslogd logging in a readable format.

The settings windows

The settings windows

There are many technical issues with systemd that could and should be addressed, but I don’t think they are really the source of most of the conflict. It seems to me that the proponents of systemd have cleverly and somewhat underhandedly managed to force a number of larger Linux distributions to use it. The long and short of it is that because they managed to merge udev into it, and have been swallowing other small important services, it is forcing its way into many distributions regardless of merit. Using such means was always going to upset many people. If they had only replaced sysvinit instead of swallowing up so much and behaved better when it came to bugs and criticism, many people would have fewer or no arguments against it.

On a technical level I understand why systemd was made, sysvinit was a bit of a pain, although extremely flexible. But I disagree with them replacing and swallowing other services into the main init package. Larger more complex software is more likely to have bugs and security flaws, and the init process is perhaps the most important one in terms of security. The fact that they have practically coerced people into using it is distasteful. It seems that the systemd devs are attempting to co-opt the entire Linux eco-system to control for themselves.

File Broswer

File Broswer

I don’t know why OpenRC wasn’t adopted as it’s a quite nice clone of the BSD rc.d system which I’ve found _very_ easy to use and works very well. The problem now is that systemd has incorporated important parts of the Linux OS that now make it difficult to use anything else, and will likely make implementing portability to BSD difficult but not impossible. I suspect that a compatibility layer will eventually be created for the BSD systems.

I didn’t mean this to be a rant about systemd or gnome 3, but there is little else to talk about in the base install of RHEL 7.0. It was pretty bare bones, which isn’t such a bad thing, but it was even lacking some of the useful system tools such as the disk utility. I found many packages seem to be older than they should be, which has caused some minor issues, but this is something common to the older releases. I’ll still end up using this RHEL due to requirements at work that are unavoidable, but I won’t be recommending it to anyone that can avoid it.

I was considering using a form of Linux on my home desktop system to replace the ageing windows install, but seeing Gnome 3 and systemd has made me reconsider my position. I’m seriously thinking FreeBSD may be better for me, but if I do install a Linux it will likely be Debian, as that is generally a bit friendlier to power users. I’ll almost certainly not use Gnome and systemd if possible, but given the politcs currently in process that may become difficult.

07
Dec
14

Lightning Strikes

Unfortunately for many in the Hunter valley there have been many quite severe storms, most including lightning. Lightning had knocked out power to some parts of the valley, but it also is often the cause of damage to electronics when they cause power surges.

Usually in storms I try to play it safe by powering down and switching off (or unplugging) at the wall anything that could be damaged and I can do without. This for me usually means doing this for my computers, TV and anything else I’m not using. Stuff like my ADSL modem I normally leave on so I can use my tablet or laptop on the WLAN.

Unfortunately my ADSL modem is exactly what got hit in a lightning strike recently. I have all my sensitive electronics connected to surge protectors so some may find it surprising anything got damaged, but there are good reasons something like this can happen.

Surge protectors are great for protecting your equipment, but they aren’t perfect. For starters they all have a limited amount of energy that they can absorb, anything more and a surge will still get through destroying the protection circuit in the process. In my case today I don’t think the surge came from the mains power supply. Other devices on the same power board didn’t fail, and most of my modem still functions.

I thought the surge may have come from the phone line, but I’m unsure because of the damage caused. Basically any ethernet ports that were connected to the modem have been damaged and no longer function. This includes the ports on the modem. In total two ports on the modem, an ethernet card and a port on my switch have failed.

Luckily I have some spare network cards to replace the broken one, and my switch and modem work well enough to continue using until I can replace them. In the future I may have to also disconnect ethernet cables.

25
Nov
14

Pharaoh’s Tomb for DOS

Title Screen

Title Screen

Pharaoh’s Tomb is one of the earliest titles in the Apogee library being released back in 1990. It was designed by one of the key members of Apogee, George Broussard, before he became part of the company. He originally released the game under the Micro F/X name. It uses the same FAST engine developed by Todd Replogle that was used in the games Monuments of Mars and Arctic Adventure which were both produced around the same time.

I had a quick look into other titles developed by George Broussard and found that Pharaoh’s Tomb was his first commercially released platform puzzle game. This may explain some of the design issues I’ll mention and why Arctic Adventure was vastly improved over this title.

Special Notice

Special Notice

Like the other games, Pharaoh’s Tomb uses both CGA for graphics and PC speaker for sound, which are about the same quality as the other games: about as good as you can do with the technology used. From what testing I have managed, I think it would have worked reasonably well on even the oldest PC’s except perhaps 8088 based machines.

The game has you playing as an archaeologist called Nevada Smith, an obvious reference to Indiana Jones. You job is basically to explore a pyramid gathering treasure as you go, and of course survive the various traps you’ll find along the way. Many of the hazards are similar to those found in the other FAST games, but there are a couple of additions.

The Pyramid

The Pyramid

Something that struck me as soon as I started playing was how much harder Pharaoh’s Tomb is compared to the other games. One of the main issues is the collision detection, which seems to be much more of a problem. It feels like the designer has used the collision detection to make the game harder rather than design the levels to minimise the issue. Combined with having a limited number of lives this makes it very difficult to progress very far.

The Anteroom

The Anteroom

The designer didn’t stop there however, some treasures and objects are either totally unreachable or trap you, leaving you alive but unable to complete the level. This forces you to memorise the levels and just plain feels a bit unfair. It can be quite frustrating.

Interestingly the game has a screen talking about the collision detection system that the others lack. It explains that all the objects use bounding boxes for collision detection basically as part of the FAST engine and that you should be careful when near objects. I think they must have known the collision detection was an issue, but perhaps didn’t have a good solution.

One Mis-step....

One Mis-step….

Because of these issues Pharaoh’s Tomb unfortunately doesn’t play as well as either Arctic Adventure or Monuments of Mars. It still has some of the same charm, but the frustrations with the collision detection and level design make it much less fun to play. Like the others it was made freeware in 2009, but I would suggest you play the other games. Arctic Adventure retains much of the difficulty, but makes it less frustrating with unlimited lives and many other additions. Monuments of Mars similarly has unlimited lives, but also works better with the collision detection resulting in what feels like less unfairness.

18
Nov
14

ESR Meter Repair and Investigating Jitters

This weekend I decided I’d tackle a repair that has been waiting quite some time. A bit more than a year ago I built an ESR meter from a kit. The version I have is the 2007 Bob Parker meter that was featured in Silicon Chip. I built the kit and was quite pleased with the result except during calibration of the battery voltage warning I manage to break the trimpot. Fortunately the unit still worked quite well, so I wasn’t all that concerned, the only downside being that it warned of a low battery all the time.

This weekend I happened by Jaycar to buy some unrelated stuff when I remembered the damaged trimpot and looked through the parts bin. I didn’t remember the value of it exactly, I thought it was around 200k Ohms. So I ended up getting a 250k part as it was the closest value, thinking that would be close enough. However I had remembered the value incorrectly as it is actually 10k Ohms.

trimpot circuit diagramRather than going back and looking again for another part I looked at the circuit diagram. It seemed that the resistance value of the trimpot shouldn’t matter too much. Here’s a diagram of where it fits into the circuit.

It looked like the trimpot is basically providing a voltage for the IC to detect a low battery, it also has a resistor either side to limit the current flowing through it. I figured the higher value should only reduce the amount of current flowing through the trimpot and that I’d still be able to adjust it such that the IC would get the correct sense voltage. So I went ahead and replaced the broken one with the 250k new one.

After fitting the new part I tested the meter, it powered up and didn’t report a low battery, success! I needed to adjust the trimpot so that the low battery alarm would work correctly. I didn’t have a variable power supply so I created the low voltage by putting in some older cells that had about the right low voltage I needed. Adjusted the trimpot and checked that good batteries continued to not set of the low battery alarm.

As an extra measure I checked the meter against the calibration resistors to make sure the meter is still accurate.

This slideshow requires JavaScript.

Something else I heard about recently was people finding trigger jitter in particular models of Rigol Oscilloscopes. I first heard about it from watching a recent EEVBlog episode where Dave does some tests on his own equipment. I decided to test out my Rigol DS2072.

First let me explain trigger jitter a little. An oscilloscopes trigger mechanism is what starts the scope both capturing and displaying at a particular point in a waveform. Trigger Jitter is basically a situation where the scope will not start at the same part of a waveform each time, causing the waveform to literally jitter backwards and forwards on the display. This can be a problem if timing is sensitive in the signal and for performing some measurements.

Unfortunately I don’t have a signal generator (something I should rectify) so I had to use the 1Khz square-wave output on the scope normally used for compensating the probes. At first glance it wasn’t apparent that there was any jitter at all.

I also checked the AC coupled waveform and didn’t see a difference, then I realised I should probably zoom in on the waveforms to see if the jitter was just too small to see on the scale I was using.

I checked the DC coupling again like Dave did, checking intervals to see if there was any periodic jitter. I found none just like he did.

I then checked the AC coupled version and you can see here that there is indeed some jitter. I didn’t realise it when I did the test, but this is actually a different instance of jitter than what Dave on the EEVBlog found. He was testing AC coupling for the trigger input, here I’ve tested AC coupling on the input itself. I’ve run out of time this weekend so I’ll test the trigger coupling soon, but this illustrates that AC coupling on the input can also cause jitter in these scopes.

So what does this mean for me and using my scope going forward? Well as long as I use DC coupling I don’t have to worry about it, as that doesn’t seem to have the issue. I need to be aware of it when using AC coupling, and use appropriate means to reduce the problem. Although given what I’m interested in, I’m fairly unlikely to really need AC coupling most of the time as digital circuits that I’m interested in can be probed with DC coupling mostly. I’m still happy with my scope, although I haven’t had much call to use it for a while.

11
Nov
14

Download for Bob’s fury

This week, after much time thinking about it, I decided I’d finally offer my old school platform game, Bob’s Fury for download. I originally wrote it in Qbasic back when I was 14 with the help of my younger brother who did some of the graphics, levels and helped play test it. The idea for making my own platformer had grown out of playing two of my then favourite games, Xargon and Hocus Pocus.

VGA Screenshot

VGA Screenshot

I originally had much larger plans for it, I had wanted to make water levels and puzzles like those in Xargon and run and gun sections like those in Hocus Pocus. At this stage I was still using gwbasic and I found that it was difficult to store enough graphics and tile information for one screen, it seemed like I wasn’t going to be able to build anything at all when I discovered Qbasic on the school computers.

Qbasic had many advantages, it supports a better graphics mode which allowed 256 colours at 320×200, then a common resolution for most PC games. The interpreter also had roughly twice the memory available to it which allowed me to use many sprites and get two screens per level. It took me roughly a year to build the engine and most of the levels. It was still quite limited in many aspects and didn’t live up to the original dream, but it was still a significant achievement.

Later in high school I had a computer studies teacher who did a bit of programming themselves. I know it seems odd, but not that many teachers of computer studies could actually program in those days. Anyway I was lucky enough that he gave me a copy of Borland Turbo Pascal 6.0, which was to be the first compiler I’d get to use. It was a bit of a learning curve, but I managed to learn pascal much quicker than either basic. I decided I wanted to port Bob’s fury as Pascal was a much faster language and wouldn’t be as limited as Qbasic.

EGA Screenshot

EGA Screenshot

I had a few problems however when I learned the graphics library. Firstly I hadn’t encountered pointers before, and they were required for bit mapped graphics. So I experimented with some simple vector graphics at first. Also Pascal didn’t have any support built-in for the graphics modes I wanted to use. So I put off making a port until I could learn more about the language.

Shortly after I went to University and got internet access I was able to solve some of these problems. I practised and learned how to use pointers in general and I found files that provided support for the graphics modes I was after. By 1999 I had built much of the tools and libraries for graphics and a few ancillary libraries needed. I’ve been working on this port sporadically since then.

I’ve been reluctant to release it for a few reasons. The first one being it’s quite unfinished. I haven’t really made enough new levels, I’m only really half way through making the first episode. The bulk of the levels are actually from the original Qbasic version, which are obviously quite limited. I’ve built a system for playing Adlib music, but haven’t made any music yet, appart from tracks for testing the software anyway.

CGA in game.

CGA in game.

So why am I releasing it? Well because despite the limitations it’s pretty cool, and I have fun playing it. (one of the reasons progress has been slow!) I want to motivate myself to get busy making more levels, now I realise there will probably be little interest in it, but stuff that I post about on my blog tends to get worked on. So having it here is a great motivation for doing more work and perhaps reporting progress as I get more done.

I’ve put a ZIP file on my download site here.

 

04
Nov
14

Tubular Worlds for DOS

Tubular Worlds

Tubular Worlds

Today’s game, Tubular Worlds, is a horizontally scrolling shoot ‘em up seemingly inspired by the likes of R-type. It was created by Creative Game Design and published by Dongleware Verlags GmbH in 1994. I’ve never heard of any software from either company in the past, so when encountering this game on a shareware magazine cover disk I had no idea what to expect. The magazine simply called it a “surprise” and offered absolutely no clues about the game.

Preparing for Battle

Preparing for Battle

I remember the introduction sequence seemed quite atmospheric and intriguing the first time I saw it. It involves some kind of “Cyber legion cadet” gearing up for battle, which looked kinda like what I’d expect a borg drone to do before battle. This was all the story we got as the cover disk had no room on it for any kind of documentation. As it turns out the story isn’t all that important, as was common for most shoot ‘em up games of the time.

Weird Creatures

Weird Creatures

Graphically the game is quite impressive, with some very nice and colourful VGA sprites and backgrounds. The sprites animate very nicely, it’s obvious lots of work was put into making them as arcade like in quality as possible. I think that in general the art style is influenced by Japanese games and animation, all the objects are quite detailed. One of the only downsides of the graphics is that it can be hard to see some of the incoming projectiles sometimes.

More Preparation?

More Preparation?

Back when I first played the game we didn’t have a sound card of any type, and Tubular Worlds doesn’t support PC speaker so we were left with playing in silence then. Having played it now with a sound blaster I can say that we were missing out. The background music is catchy and has a quick tempo, but isn’t overly distracting. It’s not the best I’ve ever heard, but it’s pretty good. The sound effects are appropriately arcadey, and fit quite well with the music.

Early in the first level

Early in the first level

The control options are the keyboard, mouse or joystick. The keyboard controls are precise, but I feel with the speed of the ship you lack manoeuvrability that helps in both getting power-ups and dodging bullets. I feel the mouse controls work much better, you can more easily dodge and collect power-ups. I didn’t get to try the joystick option as I didn’t have a suitable joystick at the time, however I suspect that it would work much like keyboard does, especially if you have a game pad.

Second level

Second level

I was never really into shoot ‘em ups when playing on our DOS machine, having only really played much of Starfire, Overkill and Stellar Defence. So Tubular worlds seemed like something quite different to me at the time. One thing the others lacked was simultaneous multi-player, which is implemented fairly nicely here, only it makes the game a fair bit easier, so turn up the difficulty if you plan on playing with a friend.

The main complaint I have is the game is extremely short. The game is divided into 4 worlds each with about 3 levels and a boss stage. It felt like each level only took a couple of minutes to complete and didn’t really fully explore the possibilities with arrangements of enemies. I did only play the shareware worlds, so the other worlds may be longer, but most shareware games of the day just offered more of the same once registered.

Pointy Things

Pointy Things

It’s quite hard for me to look at the wider picture as I’ve not really played many shooters, but it is clear that Tubular Worlds doesn’t really stand out as unique. I didn’t think it was bad, but there isn’t much that would keep me coming back to play more. I quite enjoyed playing the levels in the shareware episode, but wasn’t really impressed by the boss, it seemed uninspired and didn’t reflect anything about the levels that came before it. In summary, I quite like this game, and you might enjoy it more than I did if you’re into shooters. However it’s not really anything special by any means, so don’t be surprised if you only play through it once.

This slideshow requires JavaScript.




Blogs I Follow

Enter your email address to follow this blog and receive notifications of new posts by email.


Mister G Kids

A daily comic about real stuff little kids say in school. By Matt GajdoĊĦ

Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm - Vintage & Retro Computing Blog

Random mutterings on retro computing, old technology, some new, plus any other stuff that interests me

ancientelectronics

retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way

lazygamereviews

MS-DOS game reviews, retro ramblings and more...

Follow

Get every new post delivered to your Inbox.