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.


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.



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.


A Guide to Memory/Object Pooling

I was recently listening to a vlog by a games developer who wanted a new programming language specifically for games, and one of his big gripes with C++ was the memory allocation process. He had a number of arguments, none of which resonated with me, but it did spark interest for me in the memory allocation/de-allocation problem. I’ll briefly discuss the problem from the perspective of a language like C (in this case Pascal) and one that uses garbage collection (in this case Java).

Most languages dynamically allocate and free memory in very much the same way as even very old languages such as Pascal did. You have to explicitly ask the API to allocate memory for you, and then explicitly free it when you are finished with it. In an OO language like C++ this results in the need for destructors to free the memory the object uses when it is destroyed.

Either way memory is allocated and freed, and if it is done on a regular basis this can lead to something called heap fragmentation. Heap fragmentation is not quite the same as disk fragmentation in that an allocated block will not be split up. Pascal for instance allocates memory one block after another, simply creating the new one at the end of the old one. However when a block of memory is freed it leaves a hole, these holes are effectively heap fragmentation.

Pascal deals with these holes by maintaining a free list, which is a linked list containing all the free blocks available. When an application allocates more memory the list is traversed to find the first available memory big enough for the new allocation, hopefully filling the hole but possibly leaving a small amount still available. Clearly the holes will likely get smaller over time until they are unusable, and the more holes there are the longer any memory allocation will take.

Other allocation schemes are available in other languages, but they have similar issues, take a look here to see what I mean. Whatever scheme you use there is significant cost the more you allocate and free memory.

Garbage collected languages such as Java have problems of their own. Whilst it is claimed that allocating memory in Java is practically free in terms of complexity, freeing memory is known to have performance issues as the garbage collector (GC for short) kicks in to clean up. The mechanics of the memory allocation mechanism are largely hidden in a language like Java, so that shouldn’t concern you much, but the performance impact a garbage collector can have should concern you.

So why is the GC a potential performance hazard? In order for the GC to know which memory to free it must work out which memory is still being used. One way of doing that is maintaining a reference count for each pointer/reference in use. Obviously any reference with a count of zero can be freed, but this leads to another problem, determining which collections of objects can be freed.

Imagine a data structure like a tree in which every node holds a reference not only to its children but its parent as well. If you were to use the tree, holding only a reference to the root node, then later released that reference, reference counting would not enable freeing the memory the tree uses. Even though no external objects can reach it. A GC therefore also needs to have an algorithm that will check the reachability of memory.

That’s a rather simplistic view of garbage collection, but it’s enough to see that running the GC can be expensive.

So how can you deal with these issues? It seems it doesn’t matter which kind of system/language you use, memory management has real implications for performance. One answer is to use a technique commonly called object or memory pooling.

A simple way to think of a memory pool is that it’s a lot like a cupboard. When you need something it’s quite quick to go to the cupboard and get something that’s available there, and when you’re done with it you return it. If the cupboard turned out to be empty, you’d have to go down to the shops in order to buy more of whatever you need. An advantage being you can stock your cupboard with resources you plan on using later.

Memory and object pools are effectively exactly the same thing. You can preallocate memory, use it, return it to the pool, then use it again. This reduces the amount of stress on the memory allocation system, leading to fewer GCs and less heap fragmentation. You’d be amazed how much difference something like this can make on a system, especially something like Android.

As an example, I implemented a path finding algorithm in Java for a maze game I am writing. I could have used a dynamically sized data stack that grows and shrinks as the algorithm functions. That would however trigger the GC much more frequently as is uses and releases memory on the data stack. It is much better to preallocate the maximum size of the stack once, and reuse the same memory every time the algorithm is used. This only allows one instance of the algorithm to run at once, but it can be adjusted to allow multi-threading by creating a shared pool that each instance can use.

So what kinds of objects or memory should you use pooling for? Ideally anything that is short-lived should have some kind of pooling scheme in place as they put the most stress on the memory allocation system. This would be objects like particles and bullets in a game engine. Long-lived and infrequently used objects that pose less of a problem to the system don’t really need to be pooled as they cause much less stress.

Pooling can also be used for other resources that are expensive to create and destroy such as database or network connections. This can help alleviate stress on other systems such as the network stack, database servers, and file systems. So they are really an import tool in any programmers toolbox to improve performance.


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

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

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.



Works for DOS

Goughlui has recently had an interesting look at some old versions of common productivity software, namely Power Point and Lotus 1-2-3. I thought I might contribute by documenting some of the old DOS productivity software that I have, and today I’ll be looking back at MS Works 2.0. There’s a lot to look at so this might take a while!

This version of works was developed back in 1987-89, but my Dad didn’t buy it until some time later in the early 1990′s. We used it for pretty much everything. Me and my brothers wrote much of our homework on it, and Dad used the spreadsheet to manage the farms finances.

It wasn’t the first office suite we had, but it was used for most of the life of the old DOS PC.

You’ll notice from the screen shots that works primarily uses ASCII characters in place of graphics. It does however have a graphics mode to display the text allowing bold, underlined, strikethrough, and italicized text to appear on screen. Most other word processors used colours or special characters to indicate these features and were consequently much harder to read.

I have had to capture most screenshots in a basic text mode as dosbox doesn’t emulate the graphics mode works uses very well. This results in some parts of the screen not updating correctly when using the graphics mode in dosbox.

This version of works includes 4 major functions. A word processor, spreadsheet, database and communications package. I’ll try to talk about each in turn.

Graphics mode

Graphics mode

Text mode

Text mode

Firstly the word processor. It would be considered fairly basic by today’s standards but had a very good feature set for the day. It does most things modern word processors do with a few exceptions. Whilst there are formatting options such as bold and double spacing, there are only a limited set of fonts and text sizes available. Fonts and sizes depended on the printer support installed and didn’t change the appearance on screen.

Also inserting any kind of graphics is limited to charts created with the spreadsheet. Like Goughlui I’ve constructed an animated GIF with the menus to give you an idea what the word processor can do.

The spreadsheet is similarly limited. You can’t add graphics and formatting text is limited. It is however very usable for most basic tasks. Something that would frustrate many users is the lack of easy to find help when typing in formulae. It also lacks the feature of having multiple work sheets in each spreadsheet file.

You can create a chart based on data in your spreadsheet, but again the features available are limited in comparison to modern software. It does however manage to offer a number of different chart types such as the normal bar, pie and x-y charts.

Again another GIF of the menus available.

Works includes a very basic flat-file style database, but it is of very limited use because most things could be done much easier in a spreadsheet. The main reason you may use the database would be if you intended to use the mail-merge feature as using a spreadsheet file is not supported.

Database software like this hasn’t really survived today, as software like MS Access seems to be absent from current office suites.

Works includes a basic communication package which is basically a VT52 or ANSI terminal emulator. It does support sending and receiving files, but it seems that it doesn’t tell you which transfer protocol it uses. It probably would have been adequate to connect and upload/download files to or from a mainframe or mini computer, then still a common part of corporate infrastructure.

Finally something I remember playing with and enjoying as a child is the tutorial program. It is a whimsical introduction to the software for absolute beginners which actually does a pretty good job of teaching the basics of using the computer and works itself. The program shows you how to do something and then guides you through doing it yourself.

It reminds me of the IBM PC demonstration disk that Terry Stewart showed on youtube for his machine. You don’t see tutorial programs like these any more!

Compared to modern software Works lacks much of the features we take for granted today. However I have found that it is still quite usable today, as long as you don’t need graphics of any kind. I wrote today’s post using its word processor and found that the basic editing is as good as modern software. Mostly it’s missing features that DOS machines of the late 80′s and early 90′s weren’t capable of without a GUI like windows to support the application.


Boppin’ for DOS

Boppin’ is a puzzle game developed by Accursed Toys and published by Apogee in 1994. Unlike most puzzle games this one has a story, you play as either Yeet or Boik in a quest to restore all the bad guys to the video game world that were stolen by Hunnybunz. Without the bad guys all the heroes are out of jobs and are bored as no-one wants to play a game that isn’t complete.

It was originally made for the Amiga, but it didn’t see much success there. So the authors ported it to the PC and made some improvements and trade-offs in the process. The PC graphics in VGA were re-mastered in 256 colours as opposed to the 32 used on the Amiga. The sound however had a down-step in quality on the PC as it was converted for lower bit rates and FM synthesis.

The VGA graphics are excellent, they are very artistic and unique for games of the time. This is hardly surprising as one of the designers had lots of experience with artwork and designing tiles and sprites for games. I was also impressed in general with the animations, although you need a machine better than the minimum specs to avoid slow down. The minimum specs call for a 386 with 2MB of RAM, I’d suggest a fast 386 at a minimum and to avoid any 386sx machines as they have limited memory bandwidth. This would have made the game less popular with owners of older machines at the time.

Something interesting you may run into depending on the version you play is the suicide animations for Yeet and Boik, and the ‘Deaddy bear’ logo for Accursed toys. These feel like strange additions to the game given the artwork and graphics are fairly cheery and colourful. It doesn’t fit with the motif of the game. The later version of the game had these removed by default with a ‘politically correct’ logo screen for the company and the option to re-enable the blood via the command line.

Sound support comes in many flavours including the Sound Blaster, Gravis Ultrasound, Pro Audio Spectrum and more. I used Sound Blaster support as that was most convenient at the time. Digitised sound is used for the sound effects, and they were what you’d expect for the most part. The FM synthesized music was much more interesting and quirky, reflecting the art style and atmosphere of the game. Again, when playing on a slower machine the sound quality suffered much like the graphic speed, another reason to use a faster DOS machine.

Controlling Yeet (or was it Boik?) is fairly straight forward. You can move either left or right with the usual keys and can use up and down to use elevators. You are meant to throw blocks around the play field so that they collide with like blocks to eliminate them. You throw a block by holding the ‘waggle’ button and either left or right and then releasing the waggle button. This was a bit odd at first, but I got used to it. The blocks only travel in diagonal directions at first and will bounce around until they hit either a refractor which changes their direction or a block that will stop it either for elimination (known in-game as boppin’) or losing a life if the block doesn’t match or has hit a non-bouncy wall. It sounds more complicated than it actually is.

It was actually quite easy to learn enough to play through the earlier levels quite well. There is no time limit so it pays to carefully line up your shots and work out any bounces. If you do happen to get stuck in a level, you can restart it restoring your lives and score. If you happen to die, you can continue with the only penalty being loss of score. It makes progressing through the levels much easier and means you won’t have to repeat the earlier levels every time you die.

The game also includes a two player mode. Basically you both just compete for points by trying to bop the blocks faster than your opponent. It basically just adds the urgency that the single player game lacks. Unfortunately I didn’t have anyone to play with me to try it out properly.

In the end I found that it was quite fun, but it wasn’t as challenging as I would have liked as a single player. Once I had mastered the controls and got a feel for how the blocks move and bounce it got significantly easier, the main challenge remaining was learning the level layouts and the best way to complete them. There are lots of levels, and you can load and save your game, so you need not repeat playing any levels to preserve some of the challenge.

Boppin’ has been released as freeware and is fairly easy to find. If you go to the home page for the game you will find a windows version of the game that uses the Amiga sounds and music whilst retaining the DOS graphics and levels, getting the best of both worlds. The windows version also restores the original gory logo and the suicide animations, I wonder where they were trying to go with that?

Blogs I Follow

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

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


retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way


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


Get every new post delivered to your Inbox.