Another Modem and a Canon XT Clone

I’ve come back to my parents to visit them again and have found some more interesting hardware hiding away including two modems and an old PC clone belonging to my younger brother. Unfortunately for my Dad, internet providers aren’t very good at providing good service to rural areas, he is too far to get any kind of ADSL service. This had meant that for much longer than others he had to rely on dial-up until alternatives became available.

I forgot to bring my own camera, but was able to borrow my mothers, which whilst it has a higher pixel count it didn’t seem to do as well in the shots I took. I’ve had to adjust these images for brightness particularly.

This Dynalink modem is a pretty basic USB modem, I unfortunately couldn’t open it for any internal shots but it’s probably not very interesting as it’s small and almost certainly a software modem of some type. Dad used it for some time and had problems with drop-outs so we went about getting a better modem.

So we got this modem, a SmartSwan Turbo which much like my own modem is a proper self-contained serial modem you can use without drivers. This one was bought a little later (sometime around 2003 I don’t really remember) and did perform quite a bit better than the Dynalink modem. Unfortunately given the line quality and distance to the exchange there were still some issues, mostly speed and the very occasional drop-out.

I was able to take this modem apart quite easily, just four screws on the bottom. Here is an overview of the main board, you’ll notice that it is an Ambient chipset and is a voice modem (although we didn’t use that feature). Unlike my modem this one does have a line transformer and a DIP mask ROM chip for the firmware. It also has some similar features, like what appears to be a rectifier chip in the modem front end. Interestingly there is a 74 series logic chip (surface mount) towards the lower right of the board, something that has become unusual in modern equipment.

Here are the two primary chips up close, I believe the left one is the main DSP doing most of the grunt work for the modem, the one on the right looks like the serial interface. I found it difficult to find the data sheets for these chips as Ambient was formerly Cirrus Logic and now is a part of Intel. The chips were made late in 2002 so Dad probably bought this about the same time I got my modem.

The front end has fewer protection devices and simpler circuitry with fewer passive components. It may be using an older design with some updates. Not being an analog circuit (or any kind of circuit) guru I can’t really tell. Next up I took some photos of an old XT PC clone, a Canon A-200 20HD. My younger brother bought this machine for basically nothing, which is extremely lucky considering how hard they are to find in working condition. I found an article on google books here that reviewed the machine when it first came out, you will need to scroll up to read the whole article.

The machine in all its glory! It is lucky enough to still have the Canon branded monitor and keyboard with it, everything seems to have yellowed quite badly, although at least it’s uniform. The keyboard is still nice to type on and doesn’t seem to have any defects, although it does have the older XT style layout. The keyboard is compatible with the IBM XT class machines so it is possible to use it on another machine or replace this one if needed. The monitor is a pretty basic green phosphor monochrome monitor that seems to have been treated quite well. There doesn’t seem to be any burn-in and it is still quite bright and easy to read.

Here I’ve pulled the lid off to expose the internals, you can see a Canon 360k 5.25 inch floppy drive and a 20Mb NEC hard disk that has unfortunately stopped spinning. Fortunately I have some MS-DOS 4.01 floppies that allowed me to boot the machine, but it took ages to get to the normal prompt. In the expansion slots you can see a memory expansion card, the graphic card and hard disk controller. The floppy, serial and a parallel controller are integrated on the main board which means there are some slots free for further expansion. The main processor is an 8086 at 4.77Mhz which can be at times significantly faster than the 8088 found in IBM PCs at the time. This is because the 8086 has a 16 bit data bus (as opposed to 8) and could move data and instructions faster over the bus.

Here is the graphics adapter, interestingly it is not a Canon part but is made by Twinhead judging by the logo on the board. I can’t tell if it is Hercules compatible but it most certainly is compatible with MDA cards. I didn’t get any clues from the chips as many are 74 series, memory or other generic chips.

This is a memory expansion card, these cards frequently have a few different devices on them as well. In this case what appears to be a real-time clock and a 25 pin RS-232 port. This card has 6 x 64Kb banks of extra memory (384Kb made with 4164 DRAM chips) which would have required a special driver for the machine to gain access to it. The machine finds 320Kb of ram, but this is most likely the memory on the motherboard.

Finally here is the hard disk controller, a Western Digital device much like a later 16 bit one I have in my spare parts box. This one is only 8 bit and has more parts on the board, one with an old school Toshiba logo. Controllers such as this one were very common in all kinds of PCs of the time. Unfortunately the hard disk doesn’t seem to work any more, perhaps it’s time this machine got an emulated hard disk of some type.

Advertisements

Man Hunter San Fransisco for DOS

Sierra

Man Hunter San Fransisco is a Sierra adventure game from 1989. The Man Hunter games are murder mystery inspired, but is set within a Orwellian world. The world has been successfully invaded by aliens called the Orbs. The Orbs have little ability to move among humans undetected and find keeping the human populance in check difficult. Hence the reason they recruit some humans known as Man Hunters to pursue criminals. The first game ended as you pursued one of the worst – Phil cook – to San Fransisco and had ended the orbs influence in New York. Your job here in San Fransisco is basically to try to catch Phil and hopefully defeat the Orbs here.

Golden Gate Bridge

It is unusual compared to the other Sierra adventure games in that there is very little text in-game, most information in the game is conveyed visually. The only time text is used in-game is when you die and the three creators give you a short clue or scolding. This was quite different as the other Sierra adventure games used text extensively and had a text parser to interpret the players actions. It was also the only early Sierra adventure game to feature more graphic death and a Orwellian tone.

He broke our fall

The AGI engine this game uses supports Hercules, CGA, EGA, and PCjr which was common to most of the earlier Sierra games such as Kings Quest, Space Quest and Leisure Suite Larry. I obviously played in EGA mode as it is the best looking, although I found it strange that only half the horizontal resolution seems to be used. It is something peculiar to the AGI engine as other games using it had the same feature, perhaps it is something to do with support for other graphic cards.

Being a detective, investigating murders leads to some very detailed and sometimes gory scenes of the victims and their surroundings. Always look carefully around for clues around these areas!

Your new home

Like the other early AGI games sound is either from the PC speaker or PCjr sound if you happen to have a PCjr or Tandy machine. The sound is quite basic and there is some simple music at the start in a short cinematic sequence. Fortunately the sound whilst simple is of a decent quality and won’t get annoying, but you can turn it off if you don’t like it.

City sky line

Playing the game is relatively straight forward, you interact with the world in a point and click like manner, except you control the cursor with the keyboard instead of a mouse. You don’t have to select actions to perform as any hot-spot on-screen will automatically change your cursor into the appropriate action, which you perform by pressing enter. I found using items less intuitive as you basically just select the item out of your inventory to use it. This would normally just have you look at the item, so it wasn’t clear you could use items that way.

Using the tracker

You need to use your special MAD (Manhunter Assistant Device) to track suspects using the tracking discs that the orbs implanted in everyone. Unfortunately you can’t get identification information as the tracking system does not transmit that due to a technical error on the Orbs part. So you must use clues found at the locations suspects visit to try and identify them. After all the Orbs want the names of the suspects. Using the MAD is fairly easy. When tracking the events at a location you can tag another suspect so that the tracker follows their movements. This can lead to other locations and more clues. If you happen to find a name or work one out from clues you can enter it into the information finder to get more details and an address.

Information search

The puzzles in-game are quite tricky, you need to pick up on visual clues and piece together the identity of the suspects you are chasing. This involves visiting the locations they have visited and in some cases catching up with them. You can end up running into situations that result in your death, which fortunately isn’t too punishing. I’d recommend having a pen and paper to write down any details or clues you find in an area.

The Square

Some areas of the game lead to short arcade sequences, which usually involve avoiding some kind of hazard whilst trying to reach a particular goal. Sometimes it’s not clear where the goal is or what path you should take. Strangely the default difficulty is set to hard for every arcade sequence, so if you find one hard you should adjust the difficulty in the game menu.

The death screen

We originally got Man Hunter back in the early 90’s, the same way we got Kings Quest 4, from one of my brothers friends. Like Kings Quest 4 we were never able to solve the game, and were in fact basically stuck on the first day. This was partly because I was quite young and hadn’t realised where some of the clues were and we didn’t even really know what we were looking for. For my recent play-through I decided to use a guide when I got stuck, which unfortunately became kind of necessary as the clues became more cryptic.

Climbing on the sign

Obviously when we first played it such guides were not available, which would have made some sections quite difficult and solvable mostly by trial and error. I’d suggest you give it a try without a guide at first, but be sure to write down as much detail as you can, and save often! This may require pausing the game in some sequences. Some clues are only on-screen for a short time and can easily be missed.

I found it was quite a compelling game, but also frustrating when faced with some puzzles especially where it wasn’t clear what I should be doing. If you enjoy trying to solve a good mystery you’ll probably like the Man Hunter games.

Recursive versus Iterative Algorithm Results Follow-up

A few week ago I did some preliminary investigation into the performance difference between recursive and iterative procedures/algorithms. The problem I chose to solve was path finding in an imperfect maze as there are algorithms which have the same theoretical complexity. I also already had some code lying around for both generating mazes and finding paths. I created iterative and recursive versions of the depth first search algorithm to compare with each other and included breadth first search for comparison to a known “slower” algorithm.

The first results I got were interesting, both the dfs (short for depth first search) algorithms were fairly close in terms of rates until the size of the mazes got larger. The results however were inconsistent because of the small number of mazes used for testing and differences in the behavior of the two dfs algorithms. Clearly I needed to test across a larger set of mazes and fix the behavior difference before I’d get good results. It wasn’t a waste of time as it did illustrate that it is possible for both types of algorithm to out-perform the other given even minor differences in behavior.

So I carefully adjusted the code so that both implementations of the dfs algorithms behaved in the same manner. Again I ran some initial tests and this time the iterative version of dfs out-performed the others in general. Satisfied that the code is behaving correctly I up-scaled the tests to 1000 different mazes across many sizes so I could graph the results.

You can see the rate for all the algorithms drops of very quickly! It is quite difficult to see much detail in this graph so I did some number crunching to determine the average time per search for each algorithm and size of maze.

This graph makes the difference much more clear. Note the parabola shape, this is because the worst case for all the algorithms is to search the entire maze, which obviously is the square of the X axis in this graph. The interesting part is how they compare with each other. The iterative dfs graph is very shallow compared to the others, it is in fact quite difficult to see much of an increase. It is however increasing in a similar fashion just not anywhere near as dramatic as both recursive dfs and iterative bfs (breadth first search).

So why the huge difference between iterative dfs and the others? The big difference between the two dfs algorithms is the cost of recursion. The extra cost is per square visited in the maze, so a doubling in the processing overhead per square produces a times four increase in the total overhead.

To get a good idea of why the overhead is so comparably large in the recursive case we need to think about how it is implemented at the machine code level. Basically for every square visited in the maze there is a function call to the recursive function and a return at the end. A function call and return involves a number of relatively expensive operations. Firstly information from the calling code needs to be pushed onto the stack (usually important register information), then the processor can “call” the function code which basically pushes a return address onto the stack and jumps to the function code. The first thing the newly called function must do is allocate space on the stack for its local variables, then it can do whatever processing it requires. Once finished the function will place the return value in either the stack or a register, remove local variables from the stack and then return control to the code that called it. This involves restoring the stack to remove the local variable information and then using the return address stored there to return to the calling code. The calling code can then retrieve anything it pushed on the stack before the call and continue operation. Quite the involved process!

Lets contrast that with what an iterative algorithm needs to do differently. Firstly any iterative algorithm needs to set up storage space for the body of the algorithm. In this case a stack (in the data segment or heap) for storing the current search and some variables for tracking the current location. Then the body can begin, usually this will be a loop of some kind, either a for loop or a while loop. These loops involve checking a condition and jumping at either the beginning or end, but are only short-range jumps within the function. The body of the code simply does the search updating the stack as it goes.

So for every square of the maze visited the recursive version has to deal with function call overhead (stack operations and far calls) where the iterative version has to only check a condition and make a short jump. There is more to it with the effects of the L1 and L2 caches, but I’ll leave that out because it’s x86 specific.

So the cost of recursion is high, in this case almost as bad as iterative breadth first search and it doesn’t guarantee the shortest path. Also because of limited program stack space, the recursive function cannot search as large a maze lest there be a stack overflow. So in general I’d recommend people stick with writing iterative code except where the complexity of a recursive function is significantly better. Your code should be faster and put less strain on the limited stack space.

Heart Light for DOS

Anti-aliasing?

Heart Light is a simple Boulder Dash like game that was released back in 1994 by Epic Megagames and developed by xland. You play as a dwarf who has to collect all the hearts in a level and then get to the exit. The game is similar to Boulder Dash in the sense that it has boulders that are affected by gravity, but different in that there are other elements like bombs, balloons and one way blocks that make new puzzle elements. I’ve seen other games like Blots and Supaplex that have similar elements.

Level 1

Heart Light has some pretty nice VGA graphics, the sprites and level elements are all easily recognisable and give you an idea how they might behave before you interact with them. Animation is reasonably smooth although objects and the dwarf only move whole tiles at a time. This means you don’t get as much time or indication than an object is going to move, and hence less time to dodge it. Interestingly the game supports monochrome VGA for some reason.

Level 2

The sound system supports Sound Blaster, Adlib and something it says is speaker sound that sounds nothing like the PC speaker! There is some music that loops in the background which doesn’t sound too bad, but might be tiresome if you play for a long time. Sound effects are digitised and sound best using the Sound Blaster support. If you find either annoying you can turn them off any time in game.

Level 4

The gameplay as you’d expect is much like the other Boulder Dash like games. There are a few minor differences, such as having infinite lives, no scoring system and being able to select any level to play. The levels themselves do a good job of being challenging without being frustratingly difficult. Earlier levels introduce new elements such as bombs and balloons in a way that explains how they work without actually explaining it in words. With a short play session I was able to learn the mechanics of the game and play through a significant number of levels.

Level 5

There are 70 levels in the game so it has enough to keep you busy solving the harder ones for quite a while. Interestingly the level data is stored in an ASCII format that you can modify in a text editor like notepad, so it is possible to create your own levels. I enjoyed playing it, it is simple and challenging without spoiling the fun. It was released in 2006 under the creative commons license, so there is little reason to not try it.

Inside a Netcomm Webmaster Modem

Today I’ve taken some photos of my most modern dial-up modem, the Netcomm Webmaster v90. I bought it back in 2003 as I was still using dial-up at the time. Many modems of the time were either software modems or host controlled modems, usually installed as an expansion card or external USB device. They were cheaper, but would usually not work as well as the complete modems did. I sought out this particular modem because it is a RS-232 external modem supporting the Hayes command set, these were generally more compatible and reliable. In particular if you ran Linux in those days as it was impossible to get HSF or HCF modems working with it.

Netcomm Webmaster modem

Here is the modem itself (with the top of its manual). It doesn’t have lots of indicator LEDs like earlier modems, it just has some for indicating the link status to the remote machine. Older modems had many more to show the status of the serial line in addition to the link status. I liked the blinky lights on the older devices but this is certainly nicer and simpler to look at.

Logic Board

The main logic board couldn’t look more different to it’s older counterparts. This one is made almost exclusively with surface mount technology, except where necessary. It doesn’t use a Rockwell or Conexant chipset which used to be very common. It doesn’t seem to have a line transformer preferring a solid state solution instead. It does seem to have a number of protection devices that were uncommon on older style modems and even HSF and HCF devices. Interestingly there appears to be a rectifier chip in both the power section and modem front end. Not being an electrical engineer I couldn’t say why.

By checking out the main chips data sheet, I figured that the Hynix chip is a RS-232 interface buffer and that the power supply section may include a voltage converter to create the line voltages required for RS-232. This may explain the rectifier chip on the left side of the board, it may be the tail end of a switch mode converter. The labeled chip is almost certainly the flash chip containing the firmware. The main chip requires an external ADC/DAC so some of the smaller chips around the front end are likely to be these devices.

Modem-on-a-chip

Here’s a close-up of the main chip, not much to say about it!

What I find the most interesting is how different the more modern modem is compared to a much earlier one such as the Bit Blitzer. The biggest difference seems to be the front end using solid state circuitry instead of a line transformer and relay or solid state switch. I’m not sure, but I suspect much of it is filtering to improve to signal quality and data rate. Whatever they did this device outperformed the HCF modem I was using before by a wide margin.