My Computing History : Part 3

In the last part of this series we were still using our old Twinhead Superset 590 for playing MS-DOS games. It was roughly 1996 when Dad went about replacing the now quite old 386sx with a new machine. The machine we got was a Cyrix 6×86 166PR with 16Mb of RAM and Windows 95b. Even though it wasn’t the fastest machine you could get it was a massive upgrade for us.

Long Shot!

Gaming wise there was quite a bit of catching up to do, the old 386sx hadn’t been up to playing recent games for really quite a long time. So the new machine was our first chance to play games like Doom. The machine had come with a sampler CD which had a number of Demos on it, one of which being the shareware version of Doom. Instead of running in DOS this one had the Doom95 executable which allowed us to play in higher resolutions, although this distorted the aspect ratio of the game.

Doom got me pretty well hooked and I played the hell out of the shareware episode. But it wasn’t the only game that got me hooked, the demo for Mechwarrior 2 also grabbed my attention, even though there were only a few Mech’s and missions to play it was an amazing game to play. Especially coming from DOS games that could run on a 386sx.

We started getting some commercial games for it as well, mostly strategy games such as Command and Conquer, Age of Empires and Civilization II. This happened partly because my older brother had left home and gone to university, so games were more available to him. The Cyrix machine held up pretty well to be honest playing most of them fairly well. The main limiting factor was the small amount of RAM which meant some games caused the hard disk to thrash quite a bit.

With all this new interesting stuff you’d think we would have abandoned the old DOS games and machine. However that didn’t happen at all, we kept playing and using the old 386sx for quite a while until Dad bought us an “upgrade” to it in the form of a Reply Corp. 486 25Mhz. The 386sx was seven years old when it finally got retired, I used laplink software to transfer all our old games and software to the “new” machine in bulk.

Turbo Pascal 6 about Screen
Turbo Pascal 6 about Screen

It was on this old PC that I continued creating software, it was my mathematics teacher that first gave me a copy of Turbo Pascal 6.0 with a couple of sample programs that he had written himself. Being a compiler and having features like pointers (a foreign concept for a basic programmer) I wasn’t really prepared for making anything larger yet.

One of the first projects I made was a rudimentary menu program. The Reply machine came with almost nothing on the hard disk, with basically the bare essentials from a windows 95 DOS boot disk which was almost nothing. The old Dosshell wouldn’t work on the newer DOS and Dad really needed a menu program to make using the machine easier.

So I made a simple text-based menu program. It worked with a pair of batch files which would call each other, one which the menu would modify and the other to restart the menu when the selected program was done. It was a bit convoluted, and in hindsight there was a better solution, but it worked well for us for quite some time.

I also made a couple of text mode games which were ports of earlier basic games, and a simple pong like game with the graph unit mostly just to learn about pascal. However I still made a few significant projects in QBasic.

War game screen
War game screen

Probably the largest project I ever took on in QBasic was simply called War. If you read the last part you’d know that Civilization was particularly popular in our house, but one thing it couldn’t do was any kind of multiplayer.

War was developed as a very simplified strategy game. There was no technologies or anything like that, you simply had cities which could produce units with which to fight the other players. The units were similar to those from the late game in Civilization, and you could play it hotseat style between 3 players.

I made some variations on it, such as one focusing on ocean based warfare with ships and another that you could play against the computer. It really needs some UI polish to make it more playable however.

In my later years if high school I didn’t have as much time for coding, so generally I spent much of my spare time studying in the hopes of getting to University, which is where the next part will begin.


My Computing History: Part 2

In part one of my computing history my family got our first computer, a Twinhead Superset 590. We used it for DOS gaming, and I learned to program on it with GWBasic. In this part I get a bit older, go to high school and continue learning more about computing and programming.

We were still quite into DOS gaming at the time and had expanded the number of games that we played. This was partly due to my older brother starting to buy shareware magazines which came with cover disks. This was really the first exposure we had to the wider world of software and computing. Even though we didn’t get to play many of the games you’d see in the magazines we read them religiously. The cover disks were also a great source of new games to play, even if we could never get the registered version.

The Title Screen

Civilization was particularly popular in our house, with some family members still playing it regularly today! It’s still quite a remarkably addictive game, and it’s simple enough to enjoy, but complex enough to sink your teeth into. Some of the later games in the franchise didn’t quite hit this mark as well as the first, so they haven’t stuck with us as well.

Being a family of chess players, we had to have Battle Chess of course, but also Sargon 4 which Dad always says was one of the better chess programs he’s ever used. He still uses it for practice to this day!

1993 was my first year in high school. They had several proper computer labs with cool machines to play with. One lab had old XT clones which my brother played Simcity on, another had Macintosh classics connected together on a network, and the third had 486 PCs. These computers all had a variety of games on them which were fun to play once done with school work, but finding Qbasic on the 486 computers was eye opening. It was a big change from GWBasic.

QBasic is quite a bit more capable than GWBasic, and has a faster interpreter. However it is mostly compatible and has brilliant online help, so I was able to get coding on it very fast. A few projects I had were moved over to it and gained a number of features. The projects I took on got much bigger with better graphics.

Flight game screen

I had built a few “simulation” programs in GWBasic that were modeled after Microprose games that we played. Some of the first QBasic programs were adaptions of these, one called Flight being a flight simulator and Sea Serpent being a submarine simulation. Neither have particularly good game play, but when I got older and learned trigonometry I updated Flight a bit with my new knowledge. Being able to use it for something useful made it easier to learn the concept.

Puzzle was another project that started life in GWBasic. I moved it over to QBasic as it started to get too big to work on the older interpreter. The idea sort of came from a shareware game called Squarez that we played quite a bit. You placed tiles down individually, some would stick around and others would immediately activate, you don’t need to make a square. It’s not a super compelling game, but it works, and looks much more like games I was playing at the time.

Puzzle did spawn a more original idea in the form of Mazing. I took the same play field, filled it with random tiles, and placed the player at the bottom with the task of getting to the exit at the top of the screen. Tiles would activate when you move into them, some clearing the way whilst others were traps. As you progress there are fewer nice tiles and more traps and blocks. It wasn’t as complete in the sense that it didn’t have the niceties like high scores and help, but it some ways it plays better as a game.

The first level.

Two of my favorite shareware games from the time were Xargon and Hocus Pocus. So I decided that I wanted to make a platform game of my own. It is called Bob’s Fury and was one of my more ambitious projects, it involved a lot of graphics and data. My younger brother helped out with some of the graphics and original levels. It played quite slowly on the Qbasic interpreter, and there were some bugs and design issues I never resolved, but it did function well enough to be playable. We made 40 levels for it, so it was quite an achievement considering I was 14 when I finished making it initially.

This is one of the few projects of mine which has lived on. I reused the engine to make a shorter second game called tomb and later in the story I start making a port of it in Pascal which I’m still working on today. It’s evolved a lot since back then, but I’ll save the details for that part of the story.

Bobs Fury game screen
Bob’s Fury Game play.

These weren’t the only projects I made, but are perhaps the more important ones. Looking back I was quite prolific at creating games for QBasic. This was a product of being a teenager with lots of time and passion for creating. It was quite fun and exceptionally educational, it helped me with high school level mathematics quite a bit.

At this point in the story we were still using the Twinhead 386sx and were for quite a while not able to run the latest software and games. In the next part we get a new computer which was quite a leap ahead in terms of capability and I develop more software projects and begin to learn another programming language.


My Computing History: Part 1

Recently I’ve had the pleasure of reading the computing journey of Retrotech Chris in his book of Nostaligia, which you can find on his site here. It was an interesting read about how he became interested in computing and his journey through to now as a retro computer collector and youtuber.

I’ve been documenting parts of my computing history here on my blog for a long time, but have never really told the story as a whole and have surely missed some parts. So today I begin to tell this story.

For much of my youth we didn’t have much in the way of technology, basically just a TV with two channels, some battery powered toys, and an electric train set. This was partly because of where we lived, which was a farm in rural Australia. It was the 1980’s which had a terrible drought, so my parents were struggling, but as kids things were good. We were free to play outside in the dirt in a way kids don’t do anymore.

There were some instances I got to see computers in action at school. Like many schools we had Apple II/e computers, and at one point we had an Atari 800 computer in our class room. These were usually used to play educational games such as Where in the World is Carmen Sandeigo, but there were also some fun arcade games.

It was very early 1990 when Dad bought a computer for running the farms accounts, it was a Twinhead Superset 590, which is basically a PC clone with a 386sx running at 20Mhz, with VGA and 1Mb of memory. It ran MS-DOS 4.01, which seems to be disliked, but for us it seemed to work well enough. Dad got it with windows 3.0 and a productivity suite called Open Access. It had a 40Mb Seagate hard disk and both a 5.25″ and 3.25″ floppy drive.

We didn’t have much in the way of games at first, I think the first thing we used was vpic, which is basically just an image viewer. As simple as it was, it was pretty amazing, as the most sophisticated thing we had up til that point was a TV. But soon after my older brother brought home Simcity from school, he got it from the schools XT computers so it ran in a monochrome CGA mode.

There wasn’t much of a software market out in the bush, but there were some games we did buy commercially. The first one being Where in Time is Carmen Sandiego and the Combat Action game pack. We also bought some games second hand from one of my older brothers high school friends, the one I remember most fondly being Kings Quest IV.

Gaming obviously is fun, but it isn’t what sparked a life-long love of computing for me. Programming in GWBasic is where it really began, not long after we first got the computer. My Dad gave me a book for learning to program in BASIC called 30hr Basic that helped me learn the ropes, but unfortunately being for the BBC micro computer it couldn’t teach me everything that GWBasic could do. It was enough however to start experimenting and start making the first simple games I made.

Numdrop gameplay

One of the first ones was called Numdrop. Something many learning programmers do is try to clone something pre-existing. We had been playing a Tetris clone called Nyet, and that is what I had wanted to clone, however lacking enough knowledge I couldn’t figure out how to make shapes fall. So I came up with the idea of dropping different numbered pieces. The mechanic for removing blocks is basically larger numbers crush smaller ones. It was simplistic but it worked. My older brother helped me out with the timing mechanism.

Another game I made was a clone of the Windmill software classic Digger. I didn’t manage to get the game mechanics working the same here either, but it did turn out to be a playable game. The very first video I made on my youtube channel is about it, I’ve embedded it below.

My parents used to get a mail out catalog of books that they used to receive on a regular basis. As kids Mum and Dad would let us pick books we were interested in, and luckily for me the official Microsoft GWBasic reference guide turned up in the catalog. My parents ordered it for me, because by then I was quite invested in learning more. It is an extremely useful book, I learned how to finally do proper graphics, which up till that point I had only experimented with.

The first game I made with this new knowledge was Jump. Which is an extremely simple “platform” game. It didn’t run particularly fast, but it did work reasonably well. I’ve also made a video about it here.

These three games were only the tip of the iceberg, I made them and many other small games and programming experiments over the first 3 years of computing. I probably spent more time programming than I did playing games! I’m quite fortunate that I did save most of them as it’s something I can now show my own children. I lost one due to a bad floppy disk unfortunately.

I think this is a good place to leave things for today, next time I’ll cover my early teenage years where I move up to using Qbasic and some more DOS gaming.


Motherboard: MSI MS-5156 Socket 7

It’s been a little while since my last post, partly because I’ve been quite busy, but also partly because I’ve been putting much of my energy into making youtube videos. I’ve been meaning to write something for the blog, but have been procrastinating because I’m having difficulty with the floppy drive repair I’m attempting.

I recently received a socket 7 machine, which was used as a data logger for physics experiments in a lab. It came in a chassis that was in poor shape so I’ve stripped the useful parts and taken some photos. Lets take a look, first at the motherboard.

It is an MSI MS-5156 socket 7 and appears to have been manufactured in 1997. It has an Intel 430TX PCIset chipset which from what I’ve read seemed to be fairly good for the most part with some disappointing but not deal breaking issues. My board has a Pentium @ 120Mhz and 16Mb of fast page RAM installed and also came with some cards I’ll show later.

Looking at the details of the chipset on Anandtech I found that it looks like a mid to lower range chipset. It does seem to support what were the latest and fastest Intel, AMD and Cyrix processors from the time. Although there are a number of technical issues where it is worse than it’s contemporaries, such as the range of FSB speeds, which doesn’t go as high as super socket 7 boards peaking at 75Mhz. Like the Elitegroup mainboard in a previous machine I looked at, it can not cache all the memory, with only 64Mb of a possible 256Mb being cachable. For most uses these wouldn’t have been serious problems at the time.

Some of it’s features are also forward looking supporting newer standards that were gaining traction at the time. It supports ATX power supplies which had some safety and design improvements and also supports SDRAM which is faster than the 72pin EDO and Fast Page RAM.

Like the motherboard, some components are not very high spec for the time this machine was originally built. The Pentium running @ 120Mhz is half the speed of the high end parts available at the time, and whilst 16Mb was still common in 1997 it was a bit small and slow being fast page RAM.

The video card on the other hand is a Diamond Multimedia Stealth 64, it has the S2 Trio64V+ chip that was very common on 2d graphic cards of the time. I’ve found the S3 based cards are usually quite good for anything that doesn’t use 3d acceleration (although they do pair nicely with a Voodoo 2). This particular example comes with expanded video memory (2Mb?), so it can display at higher resolutions.

The other board that was present is the analog data acquisition board, an Compuscope 220. It appears to be basically a 2 channel 25Mhz digital oscilloscope from what I can read on the web. It has 4 BNC connectors two of which are the input, I assume the others are either trigger inputs (or outputs) of some description. There is a sticker on it indicating that it was last calibrated in 1991, so it’s significantly older than the rest of the PC. Unfortunately without the software this is likely completely useless.

Looking back at the motherboard we see that the jumper settings for adjusting the FSB and multiplier are documented nicely on the silkscreen. There are additional tables listing settings for specific CPUs from each of the manufacturers if you don’t know the FSB and multiplier for your particular CPU. This leaves no room on the silkscreen for documenting the other jumpers, which leaves you reaching for the manual to hook up the front panel or adjust the memory voltage for instance. Look here for the manual, settings are also listed at stason.org.

This machine was clearly not meant to be fast, I suspect it was built simply to contain the data logger card and run the software that was likely in a much older machine before this one. Perhaps the older machine had died, and this was a solution to keep the equipment running. So in that sense it was probably more than fast enough for what it was used for.


Bob’s Fury Update: Bug Squished!

For quite some time I’ve had a very nasty bug in my game, where basically it would lock up whenever a sound was played through any sound device on my microbyte 386sx machine. What made this bug tricky to fix is that it worked perfectly fine on other hardware I had available and on the emulation I was using for testing (which was Dosbox).

I had already discounted any results from Dosbox, as it is widely known that the emulation is not hardware accurate. So I tested on the hardware I had available. Unfortunately I don’t have a lot of old 286 and 386 machines laying around, so I tested on the Microbyte 386sx and my Pentium MMX system. The big clue I got from that is that the sound code worked fine on the Pentium but not on the 386.

This is where I was stalled for quite a while, I tested much of the code and couldn’t figure out the fault. What I needed was another 286 or 386 machine to be sure it wasn’t just a quirk of the Microbyte, but this wasn’t something I could do easily. Recently I found an alternative solution that helped me solve the problem.

I have been watching some of Jim Leonard’s videos, as he makes some really good content about PC’s and is generally extremely knowledgeable. He had some of the same sorts of issues with developing DOS software using Dosbox for emulation, which is why he tends to use real hardware where possible. However he did recommend a PC emulator I hadn’t heard of called 86box.

So I downloaded 86box and fired it up. I was able to set up a virtual machine fairly quickly and found I could change some key configuration options I would later need. Most importantly I could replicate the crash in the emulator and experiment to find the cause.

Knowing that some aspect of the hardware configuration was causing the crash, I changed the configuration of 86box until the game didn’t crash, the key element turned out to be enabling the NPU. With it enabled the sound code worked a treat even on an emulated 386 system.

The reason for the crash, whilst difficult to work out, is actually quite simple. I have an interrupt hooked on $1C for playing sounds of any type, during the interrupt it would figure out the length of the next sound in timer ticks. This would use some simple floating point arithmetic.

Because I had configured the pascal compiler to use 80287 instructions and included emulation for when a NPU isn’t present the code would crash during the $1C interrupt. This would happen because of how the NPU emulation works. If a 286+ CPU encounters a floating point instruction and there is no NPU present it fires an interrupt, which redirects to the software emulation.

The problem plays out like this: In the main code there were some floating point calculations, these would use the emulation which could then be interrupted by more code also needing the NPU. This would mess up the internal state of the emulation causing a crash. This can’t happen with a real NPU because it can’t be interrupted mid instruction.

The solution was fairly simple, I turned off 80287 instructions and emulation and made minor adjustments to code so as to not require it. This got it working on real machines without a math-coprocessor and in 86box so I was quite pleased. I’m not entirely sure why I had used the 80287 code generation in the first place, but I can see why it persisted in my code for so long. Many of the machines I had tested on over the years were 486+ class computers, these all have the co-processor built in, so the problem wouldn’t appear. Dosbox didn’t expose the bug because there is no configuration option for turning off NPU support.

There is more work yet to do, such as implementing a lookup table to save on some of the calculations, and fixing other bugs. I’m now automatically packaging a download based on my most recent subversion revision which you can find here. I’m thinking about eventually hosting the binaries and code on somewhere like github.


Attempting to Fix a 3.5″ Floppy Drive and a New 5.25″ Drive

The start of the year is a time when I am usually visiting family, but is also a time for cleaning out old junk and rubbish at work. This year I did a little cleaning out whilst visiting family and found an old 3.25″ floppy drive from our original old PC. Upon returning to work we took the opportunity to do some serious cleaning before things get busy again, and in the process found a 5.25″ floppy drive basically unused and still wrapped in plastic. Two old gems having sat on a shelf for at least a couple of decades.

First up lets take a look at the 5.25″ drive, it is a FZ-506 made by Chinon in 1987 (I think). Whilst this is probably the first Chinon drive I’ve owned myself, these were fairly common drives back in their day. This example is basically pristine, it shows no yellowing, the lubrication seems in good shape, and it operates like brand new. It even still has the cardboard in the drive, for protecting the heads in transit. Quite a lucky find indeed.

The 3.25″ drive is a Panasonic (made for them by Matsushita) and is of an unusual design. This particular example was in our old Twinhead 386sx machine, it was one of the first upgrades my Dad bought for it. This drive saw many of our games, homework and home-made software from my teenage years, so it has a little sentimental value. It was very well used, so it’s no surprise that it’s not working.

When I hooked it up the drive seems to think it is working, but it failed to seek, and the spindle speed didn’t seem quite right. With many old drives (of any type) it’s often simply a case of mechanical components being seized and requiring lubrication. A little bit of light machine oil freed up the spindle motor and seemed to free up the head actuator.

Testing with Image disk revealed that the disk speed is now correct, and that it can read tracks on a disk, but it still isn’t able to seek properly. The actuator seems to not even be trying to move. This makes me suspect the control board, and looking at the connector I suspect it may be as simple as a dry solder joint.

Unfortunately I’ve run out of time this month, although I’ll be keeping it on my work bench because I think I have a good chance of repairing it. I should have some repair result next time.


Neut Tower for DOS

Today’s game was made by SpindleyQ starting in 2018 releasing a shareware episode in early 2020. It is an EGA puzzle game that would have fit right into the shareware gaming scene in the late 80’s and early 90’s. The author took on an unique challenge, doing all the development on a 286 machine without using any tools created after 1992.

They used Borldand Turbo C which was a very popular language at the time, and used that to make almost all the tools they used for producing the game. In a way this makes it feel much more like a game from the era, everything you see could have been genuinely made at the time.

The graphics are in EGA, and uses the Borland Graphical Interface (BGI) as an engine for drawing to the screen. Whilst not super fast, the BGI is good enough to make this game run smoothly and animate well. The graphics style is well put together, colourful and animated smoothly.

There is some basic sound support for the Adlib card and the PC speaker, I used the Adlib support and I thought the sound is perfectly reasonable. There isn’t any music and there are some simple sound effects for most events in the game.

The controls are fairly simple, basic movement controls, a key to activate switches, a key to activate your companion, and a key to switch which character you are controlling.

The games starts with Jaye sitting at her desk when an earthquake hits. The building becomes quite damaged and she gets trapped in her office. She then activates Neut, an AI program that she has been working on. Jaye is able to move through the real world and interact with switches and turn on terminals whilst Neut can only travel through the network cabling in the walls and use powered on terminals as teleporters to access and hack security devices. Your goal is simply to escape the damaged building.

Along the way there are snippets of story mixed in with the puzzles, and both are generally done exceptionally well. There are companions to find and help, and terminals to interact. Although there is some mild coarse language, it’s not over the top, and isn’t really all that bad. Keep an eye out for clues, one puzzle I did had clues in the boss screen, not somewhere you’d usually look!

Neut Tower is a compelling and interesting puzzle game. The available shareware episode is a bit short at only 6 levels, but they are very well designed and fun to play. On the authors website it says this is still in development, so there may be more content yet to come and the possibility of some registered episodes. You can download it and support the author on their website.


New Microphone setup

It’s no secret that my old microphone was less than ideal. Basically it wasn’t sensitive enough, wasn’t easily adjustable, and sounded different every time I set myself up for recording.

It’s a cheap lapel mic, which explains much of the quality issues I experienced, it was however better than nothing and allowed me to get started making content. Fortunately I had salvaged an old condenser microphone from some equipment that was being retired.

It’s an AKG GN 30 ESP with a CK31 capsule, which isn’t a particularly modern piece of audio gear, but from what I’ve read online is actually fairly decent, and something that they still make. From what I’ve read online it seems these are commonly installed in Churches, various types of halls, and often teleconferencing systems. My particular example was new in 2006, and was part of an Accessgrid facility, I salvaged it when the audio system there was upgraded.

Of course being a condenser mic you can’t just connect it to any old thing and expect it to work. It requires an XLR cable and phantom power in order to operate. So to connect it to my PC I had to get an audio interface that would support it.

Step in the Swamp Industries SM11, a basic 3 channel Mixer with a builtin USB sound interface. It wasn’t too expensive either at just under $100 AUD. Add in an XLR cable and it was pretty much a case of plug and record, which was refreshingly easy.

The mixer has a few nifty features that I’ll be using, such as the ability to plug in head phones to monitor the audio being recorded, and being able to play audio through the USB sound card, so you can hear approximately what it will sound like over the PC sound output.

My audio set up is still quite new and I’m still working out all the kinks, I’ve found having a better mic can make doing good recordings more difficult as it picks up sounds that my old mic wouldn’t hear. Such as the sound of my old Sparcstation running in the background, or my air conditioner. But this is less of an audio problem and more an environmental one.

I’ve finished my first video using the new audio setup, have a listen bellow and let me know what you think.


9th Anniversary and General Update

Another year has gone by, and whoa what a year it has been! We basically had a double whammy of natural disasters here in Australia. First we had what would have to be one of the worst fire seasons I can remember, with what felt like most of everything burning. Then the Covid19 pandemic came and sent us all into lockdown, which is likely to have consequences for us all economically for the next year or so at least.

I feel exceptionally lucky that I haven’t really been affected all that badly by the events of this year (touch wood). Lockdown was an interesting experience, in some ways good and bad in others. It was nice to be home and be more relaxed, and get more time with the kids. However it made it difficult to socialise and communicate with colleagues and made home feel like work. Where I live things are mostly back to normal, the only real difference being some people wearing masks.

I started making youtube content this year, which has been quite fun. I’ve had mixed results, some of my videos are lucky if they get one view, which is kind of disappointing, while a few of them have had a small number of views.

I’ve been thinking about it and there’s a few possible problems that may be the cause. Firstly, it’s entirely possible that I’m not doing anything terribly wrong, just that it takes some time before people discover what I’m making. I had that experience to a degree in the first few years of writing here.

I’m not sure it’s a simple as that though, as there are quite probably some issues in what and how I’m making my videos that might be putting people off. I have the capture setup mostly sorted, although I think my audio quality could use improvement mainly by getting a better mic.

I think that most of the area I need to improve is mostly in my own “performance”. I’ve managed to make some videos in a more relaxed off script style, and other that are more scripted. I feel like I sound stilted and stiff in much of the audio, particularly the more scripted ones. The only real way I’m going to do better here is by practicing.

The last thing I thought may be a problem is basically the subject matter I’m picking. I think that GWBasic is quite a niche subject. Although my most popular video happens to be the one about Donkey.bas. I’ll continue making these as I feel like it’s something I like to talk about, and there isn’t really much of what I’d like to watch on youtube on this subject.

Old MS-DOS games as a subject are a bit more mainstream, I suspect that I just haven’t generated enough content in this space yet. Also there’s enough good content out there that it’s hard to get noticed.

I know that the main audience of my Minecraft videos is basically just my daughter. Which is kind of a shame because I really enjoyed making them and they took quite a while to make. I feel this is probably mostly because of the sheer number of people making content for Minecraft. I’ll probably still make these, but I might make a separate channel for them.

I haven’t had as much time for writing here, partly due to my youtube activity, but also because I’ve been busy, and feeling tired when not busy. I’m working on making some more time for myself, so I can hopefully spend some more time on my projects.

Speaking of things that have seen less activity it has been a few years since I last made a post about the old Sparcstation, the main reason being it’s taking a long time to rebuild all the packages I intend on trying/using. I’ve been using qemu to emulate a real system and have run into problems with emulation, I may fire up the old system to see if it’s quicker building on it or at least double up how much I’m building at a time.

I’m still sporadically working on Bob’s Fury, but I’m still stuck on the bug that causes it to crash on the microbyte 386 when the PC speaker is enabled. There is of course plenty of other work to do, such as creating the levels and eventually rewriting of the graphics library.

Finally, I’d like to thank anyone who’s been reading or watching my content. Whilst I do this as my hobby and for myself, it’s nice to know that others appreciate my efforts.


Solder Runner for DOS

Today’s game, Solder Runner, was made by Sumware Software back in 1996. This is notable as it’s after the release of Windows 95 and was in a time of decline for games development for DOS. It’s kind of like Paganitzu, Chaganitzu, God of Thunder or Bloxinies, except the puzzles span multiple screens. It comes with a level editor and three episodes, although the third episode appears to be incomplete.

I originally tried playing this in Dosbox, but it seemed to cause issues with the game such as only being able to play the third episode despite selecting the first one to play. So I fired up an old PC, to run the installer you need to be running windows9x (or better), but once installed the files can be copied to a pure MS-DOS machine. In this case I copied the game to the old IBM thinkpad laptop and captured images and video using my epiphan capture device.

The game appears to use high resolution VGA graphics (640x400x16), which for the most part aren’t bad. I noticed that a few digital photos of circuit boards were used in places, which is interesting, but the images appear to be a bit noisy where they are used. Other artwork such as the tiles and sprites are reasonably well drawn, although it isn’t clear what the functionality of some items are just by looking at them. However you’ll learn what they are fairly quickly.

There is supposed to be some digitised sound, but I couldn’t get it to work for me. The standard PC sound isn’t too intrusive or annoying, so it’s acceptable in this case. The controls take a little getting used to as you need to press a direction key twice to move a space  when changing direction. It’s annoying at first but you get used to it.

The game is divided up into three episodes, each episode is one large level consisting of many screens. Puzzles vary in size from simple ones that fit in one screen to much larger puzzles that require back tracking or retrieving keys or solder beads. The very first large puzzle on the first episode has you circle around the same screens multiple times before you can collect everything you need and move on.

The static hazards are much like those in similar games. Some shoot at you and others block your path or offer a small puzzle element. Keys may be required for progression at times and you’ll almost certainly have to back track at times. This can make things a little tedious as screens do not reset, so you can end up traveling several screens with basically nothing to interact with when you return to fetch something you need.

The enemies are quite different to what you’d find in similar games, they represent different types of computer virus in the system. They move quite erratically, in a semi-random fashion that makes them difficult to shoot and predict. I think this has made it harder to implement good puzzles involving them, if they had a more predictable logical behaviour that differed depending on the enemy type then you could base some puzzles around them. Much like those you’d find in similar games. As it stands they are more of a nuisance that you have to avoid or shoot.

Apart from issues with dosbox there are some game mechanics that may cause you problems. Diodes in the level only allow you to travel through them in one direction, you’re automatically pushed in that direction if you move onto one and they are often laid out in chains. Your controls are not disabled whilst this is happening, and you can attempt to move or shoot whilst the diodes push you to your destination. This can result in you glitching into a part of the level you’re not prepared for, so best to keep your hands of the keys whilst moving through a diode chain.

Solder Runner was reasonably fun to play, but it has some flaws. It does do multi-screen puzzles reasonably well, just other games such as God of Thunder in particular do it better. It feels incomplete and unpolished in many ways, which is confirmed by the third episode, which has barely any content and is clearly incomplete. Bellow is a video with some commentary and game play.

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's Vintage Computing, Tech & Scale RC Blog

Random mutterings on retro computing, old technology, some new, plus radio controlled scale modelling.


retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way