ESR Meter, Logic Probe and a Sun Frame Buffer

Recently I built two kits that I was given for my birthday. I had asked Dad for them as they will later help me diagnose and hopefully repair old computer electronics, well at least I hope so. The first kit is a simple logic probe, the second an ESR meter. I’ve assembled a few kits before so I’m not the best at soldering but I’m good enough for through hole components. Fortunately these kits were through hole only.

Kits

The logic probe was by far the easier one to build, mostly because of the smaller number of components. It consists of a single logic chip filled with NOR gates and some basic passive components around it. It took about 2 and a half hours to complete with pretty much no problems. For those who don’t know a logic probe basically will tell you is a line is high or low, and with this probe it can also detect floating lines (a voltage that is neither high or low). It is a pretty simple device to build and use.

The ESR meter was a completely different kettle of fish. For starters it has many more components, it took me an hour just to position all the resistors on the board there were that many! The size of the pads for the components also seemed closer together and smaller making any soldering work much tighter and more fiddly. Controlling the amount of solder applied to joints helped form, but it was easy to use too much. The chips and display were all socketed which whilst isn’t easier to solder, it does mean you’re less likely to overheat the components. In hindsight I probably could have foregone the sockets as I can solder IC’s with out too much trouble now.

An ESR meter is a useful bit of kit to have for a few different scenarios, the most common being detecting faulty electrolytic capacitors. These caps (as they are commonly known) are a common cause of faults with power supplies, CRT’s, main boards, you name it. It is often an easy fix if you can identify the faulty cap. This is where the ESR meter makes things easier as it can test caps in circuit. If you want to know more about ESR meters look here.

I hope to use both these new tools to solve some issues with some of my older machines.

Frame buffer

Finally, a PCI frame buffer card that I got off ebay recently. It is a Wildcat Expert3D-Lite which has some basic 3D acceleration, I’m hoping to be able to use it as a frame buffer for either my Sun Fire R280 or Sun Fire V440. Unfortunately I did some web searching and it seems unlikely that it will be compatible, but one can hope. In either case it’s a nice addition to the collection.

Monument of Mars for DOS

Title Screen

Monument of Mars was created by Todd Replogle for Scenario Software and released by Apogee sometime during 1990. It is one of the earlier games that Apogee released and as such was made to run on the widest possible range of hardware possible. They re-used the FAST engine that was developed for Pharaoh’s Tomb and Artic Adventure, so there are some of the same issues with collision detection.

A Pit

Much like the other two games it uses CGA for graphics, and it animates nicely even on an older machine. The game does recommend that you don’t use an 8088 equipped machine, which I’m guessing is because of the crippled data bus. It was 8-bit compared to 16-bit on the 8086 and better machines, this made it much slower with graphics. I believe the other games running the FAST engine had similar issues with the 8088.

The hand drawn sprites themselves are about as good as you can get with CGA graphics, and most of the sprites are animated quite well.

Robots!

The PC speaker is used for sound as most older machines had only that as a sound device, although they could all be fitted with an Adlib card at the very least. The sound isn’t bad, but the CPU speed will affect how fast the sound is played and also how long the game will pause whilst it is playing back. Slower machines will have longer pauses so may benefit from having the sound turned off to improve the rate of play.

Spikes and such

The puzzles and obstacles in the game are similar but not as brutally difficult as Pharaoh’s Tomb and Artic Adventure. The problems with collision detection are still there, but seem to cause you less problems in the process of completing a level. With a little practice I got through about 11 levels in a reasonable time on my first play, and I didn’t find it overly frustrating. They also start out at a much more reasonable difficulty level and get harder as you go.

Moving platforms.

Most levels require you to get a key card to open the exit door. This may require you to jump over obstacles, and dodge or kill enemies. You have a limited number of shots for your gun so it is often best to dodge if you can, but ammunition can usually be found if you really need it. Some parts of the level have invisible switches that trigger when you walk over them, usually causing some blocks to appear. Usually this is to help you finish a level, so if something looks like you can’t get there, try looking for these invisible switches.

As the difficulty gets harder it is fortunate that you have infinite lives as you will need a few attempts to finish a level. There is also a level restart button so you don’t have to restart if you get yourself trapped. In this way Monument of Mars is much less punishing of mistakes than Pharaoh’s Tomb.

Tower Collapse!

The technology used for the game was significantly out of date when it was released. Yet somehow it has a charm that makes it fun to play. The puzzles are challenging without being unfairly hard, and you aren’t punished for making a mistake. It runs on very old hardware that would have still been very common at the time it was made, so you didn’t need to upgrade too much in order to play.

Apogee made Monument of Mars freeware in 2009, so there is little reason to not give it a go if you like puzzle platform games from the era.

DEC Legacy Gallery

A very nice set of photos of some very old DEC gear. I’m a bit young to have ever used any of it, would have loved to have seen it in the flesh. Click the link to Retrocosms blog to see the photos.

Retrocosm's Vintage Computing, Tech & Scale RC Blog

Had a great weekend at the DEC Legacy event in Windermere.  Here’s a gallery of photographs that I took and some video.

View original post

Storage Box Photo Tour 1

A couple of weeks ago I got all my hard disks out and took photos of them. This made me wonder if any of the disks still worked and what was on them. I keep all my PC expansion cards stored in some storage tubs inside static bags with some desiccant packs to keep them dry, which means I would have to have a look in them to search for a SCSI card to test the drives with. I figured why not take some photos of the cards whilst I am at it.

Basic tech cleaning gear

Firstly I have here a picture of two very useful things every computer technician should have around. A can of isopropyl alcohol in spray form for cleaning slots of various types, you could use contact cleaner as well, but that leaves a residue sometimes. The box is full of isopropyl infused medical wipes which are good for general cleaning and can be used to clean card edges and the like. Very useful for cleaning thermal paste up if you ever need to, they are less messy than other methods. Not pictured but also useful is a tooth brush (not used for teeth anymore!) and cotton buds to aid in the cleaning process.

The Thruth about E-Mail

Just today on facebook, I was having a “conversation” (more of a rant really) about email and advertising. This was brought on by a friend of mine who posted a link to a blatant slander ploy by Microsoft in the form of scroogled. I won’t post a link to it as I don’t feel it’s appropriate to link to propaganda.

Basically, the site goes into details about how they think Google is mistreating it’s users with the way they operate. To be clear, Google do read peoples emails in order to target advertising to them, they also use the web searches you do and any other information they can gather. This is not unusual, other companies such as Facebook, Apple, and Microsoft all do the same thing to some degree. The recent complaint is that people think Google have been spamming them, when really all they have done is put some discrete advertising at the top of their inbox. It’s not really spam, but if you’re a bit dim you might think it’s an email.

So there is a grain of truth in the mound of salt that Microsoft put up on the web, but just how bad is it?

Lets consider to start with that the services in question (Gmail, facebook, etc) are usually free of charge. So companies need to pay for running the service, and hopefully make some profit as well. They have already committed to making the service free so they have little option but to use advertising (much like free-to-air TV) to make money. Advertising is something we need to live with in order to have a lovely free service.

Now Google read you email pretty much with the aim of picking more relevant ads to display. This should work in everyone’s favour, but people of course complain about invasion of privacy (perhaps rightly so). You get ads that may actually be relevant (you can always ignore them) and advertisers only pay for people seeing ads that might be interested in the service.

The problem is e-mail never really has been private.

The reason for this is basically the design of the basic protocols that make up the e-mail services we know today. The main ways of reading messages come in the form of imap, pop, and http (web-mail). Http fortunately can be encrypted, if you see https:// at the start of the URL people can’t intercept the messages between the server and you. Both imap and pop generally use plain text, which is easy to read and intercept. Again it is possible to encrypt these transport methods, but that is far less common for those types of connection.

The transport of messages between servers is the really big flaw with e-mail services. SMTP is the protocol used, and whilst you can encrypt your SMTP connection to the server, the messages are often sent in plain-text from server to server enabling computers and clever people to intercept messages in a transparent way that is undetectable. Encryption of messages from server to server is starting to become common, but you can’t guarantee it. Yet.

Another problem with SMTP is that anyone can send an email from pretty much any email address. This is how many phishing scams trick people.

So is your e-mail really private. Well the answer is unfortunately no, anyone determined enough to find out what messages you are sending/receiving will get access to your messages. If they own the servers with your mail, they have full access with no effort. However privacy is gradually improving but not quite there yet. This is basically because the e-mail services as we know them were designed in the early days of the internet when such concerns were not thought of. If you have messages so private that you don’t want _anyone_ to read them you should consider using another service or encrypting the contents of the messages.

All this being said, I’d expect far greater invasion of privacy on social networking sites as people give away far more information for free on those than we typically do via e-mail.

Dark Ages for DOS

Title screen

Dark Ages was released by Apogee back in 1991, one of it’s distinguishing features is the use of older graphics technology, whilst having excellent sound support for the Adlib and Sound Blaster OPL music. The game is set in the Great Kingdom where a bad guy named Garth has taken over after the king died. You play as the prince and heir to the throne, and you set out to defeat Garth and regain your birth-right.

The menu for Dark Ages

The game was released as freeware in 2009, which is how I came across it when looking at the download section of the 3d Realms website when looking for another game. I hadn’t heard of the game before then, perhaps because it wasn’t widely distributed on magazine cover disks, or just not on the ones my older brother bought. I usually got most information about shareware games to play from the magazines back then. Mostly as we didn’t have a modem (which wouldn’t have worked well for us in the bush anyway).

Loading…

The games graphics are in EGA, which was very common at the time, especially amongst Apogee games. The graphics are reasonably well drawn and well animated, but look pretty average in comparison to other classic games that used EGA graphics such as Duke Nukem or Commander Keen. The players sprite in particular lacks detail.

Lava fall

Sound is where this old game shines technology wise. Whilst the sound effects use the PC speaker (a common technique even when a music card was present), the music is rendered using the OPL chip on either a Adlib card or Sound Blaster card. The music itself is quite fitting for the game, and sounds very good. It fits the atmosphere of the game and makes it feel more like an action game, even though it really isn’t.

The Prince of pansies on a fetch quest.

Game-play wise it is brutally difficult, but not for the reason that you might expect. For the most part enemies are easy to deal with, and there are usually only a few of them. The difficulty comes from the fact that health power-ups are very rare, making it difficult to heal once you are hurt. The layout of the enemies make it difficult to not get hurt, so it pays to be patient and be more careful in what you do. Some parts of the environment hurt you when you don’t expect them to, most notably the spider webs in corners hurt you, the prince must be a bit of a pansy.

He didn’t make it

Despite the difficulty and less than great EGA graphics, Dark Ages is an engaging platformer. It fortunately doesn’t have a limit on the number of deaths so you can play levels as much as you need to in order to complete them. Most of the levels are quite short and have simple goals such as finding an item for a wise man. So once you have practiced the levels you can breeze through them quickly, fortunately there are plenty of levels to complete and 3 episodes to play.

Multi-threading Comparison between Python and Java

I find myself unprepared this week for what I was going to write about, partly because of playing Dwarf Fortress after having had a long respite, and having been away for a good portion of the weekend. So I don’t have any screen captures done for the game I was planning on writing about.

Instead, I’ll be talking today about multi-threading on both Java and Python and why in general Java is better at it.

The story begins with a project I had at work, where I was asked to speed up a program written in python. The code was written in a single thread and I was told that it was a sequential type of algorithm that the coder thought couldn’t be multi-threaded. This sounded like a challenge to me so I got a copy of the code to look at and began optimising.

The code was designed to solve a problem within an area of mathematics, something related to topological groups. I didn’t really understand the complete idea behind what he was trying to do, after all the person that wrote the code was an honours student and being a engineer I didn’t do anything harder than second year maths, and not in this field. The basic gist is that he was trying to work out the rate of usual growth and geodesic growth of a particular word problem and if there is a pattern to the growth rates. If you understand this you probably know more than I do!

So I had some code and began investigating. I couldn’t see any obvious way to make a huge improvement to his algorithm, which isn’t surprising, but I did find some areas of implementation that I could fix to make the program faster.

The code used string variables, it used them _a lot_. After profiling the code I found that it spent a good portion of its time doing the string length function (len). Changing the code to use this function less (by keeping track of the length in a variable) I managed to speed up the code by quite a bit. This is because measuring the length of a python string is an order N operation, as the length isn’t stored but computed each time by traversing the string. This is pretty much the same as is done in many languages such as C.

I found a few other implementation details relating to strings, but quickly ran into a wall of not being able to make the program much faster. So my attention turned to changing the code to take advantage of multiple cores. Now having become more acquainted with the code I noted that there were situations where one function was called many times on many strings in a data set. This data set unfortunately grows rather quickly (exponential I think) so later iterations of the algorithm could take a long time single threaded. So I decided to go about processing more than one string at the same time in many threads.

This unfortunately led to me find a problem with using python for any kind of number crunching. After doing some research I found out about something called the Global Interpreter Lock. This lock basically means that within one instance of Python the interpreter will only be active on one thread. Because the code runs almost exclusively in the interpreter it wasn’t really going to be possible to do all the work within one instance of python. The threading model in python works well for stuff like I/O where a thread may not need the interpreter for a while and it can be used by someone else.

So being a Unix user I thought of using multiple instances of python and using OS pipes to communicate between all the different instances. This is called multi-processing rather than multi-threading, but it still allowed me to make use of many more processors and in theory it could have even been extended to multiple machines, but as it turned out this wasn’t necessary and wouldn’t have helped.

The problem I faced after much testing was that the main python process was spending way more time on I/O than pretty much anything else. Part of the problem being the large volume of data that needed to traverse the pipes in order for each thread to run. I tried several different techniques but couldn’t get an Improvement, this is when I decided a port to Java would be a good idea.

The port to Java was pretty straight forward for the code that makes up the main part of the algorithm, so I took the opportunity to do a simple test as to which one has better single threaded performance. I ran the python version of the code using pipes to both java and python processing instances in turn. I found with equivalent code that Java was about 50% faster just for the function I had put into the separate process, this looked promising and was useful in debugging some of the java code. Given that python is interpreted this shouldn’t be surprising.

I moved to java because of the threading model being much better. Firstly it actually supports having more than one VM thread running at a time, so it makes it possible to actually do some processing on multiple threads, and secondly it has a bunch of handy mechanisms to help allow you to get the maximum processing done. Synchronized blocks, locks, and the notify/wait system allows for thread safe programming whilst not having to poll for events, thus saving processing time. The main advantage over python in this case is not having to do the I/O to get data to processing threads, and being able to multi-thread more sections of the code.

Now having completed the java port the performance stats speak for themselves, it is significantly faster than the python implementation, taking about 4 days to do what would take weeks even with the multi-process python implementation. I do have to note that I was using the 2.7 version of python, so this does not reflect the performance or programming model in the new python 3 implementation.