Archive Page 2

27
Jun
17

Chopper Commando for DOS

Back in my teens I aspired to create my own computer games and actually made some nifty little games, but I didn’t ever distribute them. Today’s game, Chopper Commando was made by Mark Currie when he was 15 and did make it out in 1990. It’s a fairly simple arcade helicopter game in which you’re given a mission to complete.

It was written with Turbo Pascal 5 using the Borland Graphics Interface (or BGI). The game uses CGA 4 colour graphics at 320×200 which are mostly drawn using the basic line and fill functions from the BGI library. So artistically the game has a fairly simple line-drawn style that does the job. Sound is also fairly basic, with a few simple beeps coming from the PC speaker.

Upon starting the game you select your pilot from the roster, the number of bombs you can carry and finally the difficulty of the mission. Each difficulty setting has 5 unique missions which is chosen at random each time you play. There is a bit of variety in the missions, some are strictly destruction, whilst others involve deliveries or retrieval of items.

Controls aren’t as intuitive as I’d like, but once I slowed the game down I managed to progress quite well with the keyboard controls. To move you tap the direction you want to move and you gain speed in that direction, in order to stop you have to tap the reverse direction until you slow down and stop. It’s not the easiest way to handle controls, but I managed to make it work for me. I tried using the mouse, but that just resulted in a crash (the helicopter not the game), this could be because I was using Dosbox to play.

Destroying bad guys isn’t too hard, there are four weapons to use for dispatching your foes. First is a basic gun that fires forward. I found it best for shooting targets in the air but the bullets also slow down and fall to the ground, so you can destroy ground targets with it. There are also basic bombs which basically behave like the gun without the forward movement, these are easier to use on ground targets. You have the option to use missiles, but I found they were more likely to get me killed so I didn’t tend to use them. Finally there is a mega bomb which has a larger explosion radius.

Chopper Commando is a fairly simple game, but it has a lot of little extra details that make it charming and fun. The game uses a different colour palette for day and night missions. You can eject from a damaged helicopter and run around throwing grenades until a spare one arrives, and after missions there is a short piece of text from the office that makes fun of you when you die, or congratulates you upon success.

Obviously it’s not very technically impressive, but it’s quite fun. I looked for the Authors website, but it appears to be down, but you can find this on the Classic Dos Games website with a slightly updated version that fixes some bugs and source code.

This slideshow requires JavaScript.

Advertisements
01
Jun
17

SparcStation Desktop project.

Unfortunately I’ve been neglecting my poor old Sun hardware, mostly because of time and space constraints. I thought I’d try to go some way to correcting this by actually beginning the process of setting up the SparcStation 20 as a vintage desktop work station. I’d been planning on doing this for ages, as long ago as when I built the replacement server machine.

Hardware wise I’ve not acquired anything new, although everything needed a test and some basic cleaning to get it working. I’m still having issues, but I’m unsure if it’s an hardware fault or a problem with the software I’m installing. We’ll get to the software in a moment, first we’ll look at the hardware installed.

At the moment I have 3 CPUs in the machine. They are all V8 Supersparcs with two 50Mhz chips on one module and a 60Mhz one on a module on it’s own. Each module has 1Mb of cache memory which doesn’t sound like much now, but was a large amount when these machines first appeared.

Frame Buffer

Frame Buffer

I’ve currently got about 304Mb of memory installed, I had more but unfortunately one of the sticks that was in it fails to detect anymore. I’d like to have a VSIMM as that would allow me to use the built in cg14 frame buffer (graphics card) which is probably the best performing one available for machines of it’s type. I managed to purchase a 2Mb TGX+ frame buffer and adapter to connect it to a VGA screen, which is doing an odd resolution of 1152×900 at 8 bits per pixel. It’s obviously not the fastest, but it does the job. I’ve selected an 136Gb 10K RPM SCA drive for the hard disk, certainly a bit of overkill, but it would just be sitting on my shelf otherwise.

The initial issue I had was stack under run errors after the boot screen came up and the machine attempted to boot. My first instinct was of course failed memory, which lead me to find the undetected memory module. But no matter which memory I ran I had the same problem. After some poking into the system environment (kinda like the BIOS settings in the PC but without the nice interface.) I found some items that were not at their defaults and changing them back seems to have fixed the stack under run.

Dual CPU MBUS module

Dual CPU MBUS module

Unfortunately that’s not the end of the issues, as after installing and running NetBSD for a while the machine will hang, reset or have a watchdog timer trigger. This certainly could be faulty RAM, but the power supply is also a potential suspect as is the operating system itself. I need to follow this up with some more testing, unfortunately I don’t have a spare PSU to test with.

Software wise I’m much more prepared and have had much more success. I’ve been using Qemu, which does full-system emulation for a number of old and different platforms, including Sparc systems. Qemu has been useful for building packages and the kernel specifically for my machine. Something I had done ages ago when I first intended to do the install.

At the time I built for NetBSD 6.1.4 which is the OS I’ve installed and tried out on the machine. It’s out of date by quite some margin now, so I’ve set up a new virtual machine to start work on getting 7.1 packages and kernel built. It has a bunch of improved hardware support, particularly in the frame buffer acceleration, so I’m keen to see how it goes. I’m still building packages I want for it, but I’m happy with 7.1 under qemu so far. I’m hoping the improved hardware support helps with the hang/watch dog/reset issues.

When it’s all done, I’ll post about what it’s like to use the machine for specific tasks, like say browsing the web and checking email.

04
May
17

Snow White’s Voyage for DOS

Today I’m looking at a platform game called Snow White’s Voyage, originally released by Alive software back in 1996. Of course by this time Windows 95 had changed the scene quite drastically, with most developers having abandoned developing games for DOS. The game has fairly low system requirements, needing only a 386 and about 512K conventional RAM, much less power than many late DOS machines had. So this game is a little unusual when put in the context of when it was released, it’s like it time travelled by about 4-6 years.

The story isn’t quite the same as the fairy tale, the game is divided into 9 episodes with only a few being related to the original story. Each episode begins with a short blurb of story text and a legend of the hazards and treasures to collect for points. The game-play itself doesn’t really rely on the story, so you can ignore it if you wish.

The graphics in Snow White are ok, nothing spectacular, but they do the job. I can totally sympathise, as Alive Software is a one-man software company, I can understand how hard it can be to generate attractive graphics by yourself. The graphics engine seems to be programmed reasonably well, as it appears it would work well on retro hardware like a 386. Although there was one peculiarity, the bottom of the previous level appears to be the ceiling for the one you are playing! Fortunately entities on the previous level don’t seem to be active up there (avoiding slow-down). I’m guessing all the levels are stored together in a single lump per episode. This could have been avoided by restricting the vertical scrolling range, or by only using the tile data from the current level. Apart from looking a bit odd the only problem it introduces is restricting your jump height where it need not be.

Digitised sound and OPL music are supported for the Sound Blaster, and some music with basic sound effects for the PC speaker. The music is implemented quite well, although there are no original tunes, I think the introductory tune is from The Marriage of Figaro and reminds me of a Tom and Jerry cartoon where the music was also used. The music resets every time you die or start a new level, which can sound a bit strange, otherwise it’s generally well done. The sound effects are fairly understated but fairly decent for what they are. PC speaker on the other hand is probably best avoided, it’s not the worst I’ve heard, but it’s not the best either.

The keyboard controls follow a fairly standard layout for platform games of the time, so getting your fingers on the right keys isn’t too hard. Basic movement works well enough but I found the jumping mechanic a bit of a problem. Basically your horizontal movement in a jump is about half as fast as your normal speed. The main problem this creates is difficulty in jumping over obstacles that otherwise shouldn’t be all that hard to avoid. There are also some problems navigating up some tiles that are intended as ladders.

Luckily the game has an easy difficulty option that removes some of the more difficult hazards making it much easier (but still challenging) to progress. The enemies aren’t too hard to dodge, but they are deadly accurate with their projectiles which are difficult to dodge. The worst ones being low flying birds that basically drop un-avoidable eggs on your head. Part of the issue is you basically have to restart the level every time you are hit, making any hit at all very punishing. It’s confusing because you have hearts that are like hit points/health in other games. Fortunately the level doesn’t reset when you start again, so bad guys stay dead if you’ve killed them.

Luckily the levels are quite short, so you’re never sent too far back, but being so short and limited in height has meant there is not that much variety in the map design. I did only get to play the first episode however as I played the shareware episode, and I’ve noted that later chapters do change things up a bit. In the lake for instance the game becomes top-down as you guide Snow White around on a raft, in the later stages of the game you play as Prince Charming, so there’s some variety, just not so much in the shareware chapter.

From what I’ve played Snow Whites Voyage is ok for what it is, but clearly it’s not a classic like say Commander Keen. Alive Software are still around, and you can buy this game in a bundle with some of their other legacy titles for about $5 USD which honestly isn’t too bad if you have any nostalgia for their games.

This slideshow requires JavaScript.

 

05
Apr
17

Motherboard: Aopen AX34-U

I’ve been rather busy of late, and it’s been raining here in buckets, so finding the time for photographing a board has been tricky. In any case I had some time today and have found a socket 370 board made by Aopen.

I wasn’t able to decipher the date of manufacture from any of the date codes on the board, but it’s almost certainly made around the early 2000’s. It supports the Tualatin and Coppermine cores of the Pentiun III and Celeron chips. The Coppermine ones had a reputation of being quite good at over-clocking at the time.

Looking at the board as a whole the layout is pretty standard for the time, although I’m puzzled as to why the AMR slot is right next to the AGP slot. I’ve never seen an AMR card in the wild, probably because they were pretty poor software modems. On this board it occupies what would be a prime spot for a PCI slot, which I’d much rather have.

You’ll also note it still has a legacy ISA slot, something which disappeared from consumer hardware in a few short years around the time this board was made. ISA slots stuck around for a surprisingly long time, partly due to the amount of hardware that was made for it. It was used for many unusual cards some for controlling industrial machines. I have one somewhere that was used as a lighting controller for dance floor lighting in a pub. Machines made for industrial conditions kept the ISA slot for much longer.

Unfortunately this board seems to have suffered leaky caps, a common cause of failure for many electronics. One has coated a surrounding chip with it’s goo. This kind of problem can be repaired, but it isn’t usually done because of the time or cost involved if you pay someone to do it. If you have the time, patience and skill you can clean up the goo and replace the caps, often restoring the device to functionality. I’m not confident I can repair this yet, as my soldering skills are pretty much hobbyist level. It’s easy to damage a board like this as it has very fine traces and small pads designed for machine assembly.

Performance wise this would have been quite a nice piece of kit. It has a VIA Apollo Pro 133T chipset which was a reasonable performer as well as being cheaper than alternatives. It had room for 1.5Gb of RAM providing you used the expensive-at-the-time 512Mb modules. With only 3 SDRAM slots you couldn’t use many of the cheaper sticks to make up the difference, but few people were going for more than 0.5Gb of RAM at the time.

From a technicians point of view it’s fine in terms of specs, but the board silk-screen isn’t as helpful as others when connecting the front panel and setting jumpers. The front panel is marked, but isn’t real easy to read, which can be worse in the tight confines of a case. Luckily there aren’t too many jumpers as software controls much of the settings, most of the jumpers you won’t need to touch with perhaps the exception of the one that sets the FSB speed. The manual is also still available if you need further help.

As an end user this would have been quite a good buy, it has most things you need integrated (except NIC) and has a decent chipset with support for a decent range of configurations. You could build either a cheap and cheerful machine, or something with pretty good performance with a board like this one.

 

07
Mar
17

Space Nightmare for DOS

I’m not much good at shoot’em up games, which is why today’s game, Space Nightmare has a completely appropriate title. It was made by a Canadian company called Microdem in 1994. It is odd for a DOS game as it uses some high resolution graphics and what appears to be Mode X using 16 colours. Like most shooters it has a fairly throw away story about aliens coming to steal our copper, but what’s really important is you get to blow stuff up!

Graphics support is unusual for a DOS game of the period. The menus are drawn at 640x480x256 if set to use SVGA and 640x350x16 for standard VGA cards. In game it appears to use 320x240x16 which is essentially Mode X, but it appears to be only using 16 of the 256 normally available colours in that mode. The game does perform quite well mostly, with some of the smoother scrolling I’ve seen in game. There is some slow down occasionally which seems to happen when the game is loading an image for displaying the first time. You notice this especially when it loads larger images like those for the end of level boss. This might not happen on actual hardware, I was playing using Dosbox.

Artistically the graphics are quite nice and colourful, for EGA. There is dithering in some of the graphics because of the limited number of colours used. This could be a technical issue with the graphic engine, perhaps it only supports a 16 colour mode? Did they limit it for speed? I’m sure they could have gone with 256 colours and not compromised too much on speed and being in Mode X it should have been easy. So the decision to use 16 colours puzzles me.

Sound comes from either the PC speaker or a Sound blaster card. I couldn’t test the PC speaker sound unfortunately because the game disables it as an option if it detects a sound blaster, which I guess is fair. The music is ok, although the tracks all sound fairly similar they do fit the theme of a shooter like this one. Sound effects are also ok, although weapon sounds get louder as you upgrade them. I suspect it plays the sound once for each shot in air, so once you’re upgraded it adds the sound from many shots together. It could have been implemented better, but you can turn down your volume as needed to compensate.

When starting the game you get to choose between one of three ships. Dynamite only fires forward, but is one of the faster ships, upgrades simply add more projectiles. Blaster is slower, but upgrades add increasing amounts of spread shots which can effectively blanket the upper screen with bullets. Lastly Cancer fires forward only at first, but upgrades add shots going backwards and to the sides equally. I found Cancer the most successful as it allowed me to combat foes coming from more directions much easier.

The enemies are mostly mobile air units of some type. They will often fire a burst of bullets directly at you, so dodging is absolutely necessary. I found this quite hard as the hit boxes for your ships are quite large. You can end up being trapped by several barrages and can’t avoid taking a hit. This wouldn’t be a problem if being hit didn’t take _all_ your power-ups, which leaves you very vulnerable. Whilst you can take more than one hit before dying, this is severely punishing.

I found this game quite hard, I couldn’t get past the second level after many attempts. This could just be because I’ve never really been all that good at this type of shooter. I think that having more than one life, and not losing your power-ups when hit would have made this much more playable for me. People who are fans of vertical shooters (and are better than me at it) will probably find some fun, as long as you’re good at dodging.

This slideshow requires JavaScript.

22
Feb
17

Making a new GWBasic game.

When I was young I learned to code using GWBasic, a BASIC interpreter that came with MS-DOS 4.01. I’ve posted some code and talked about it in the past, but not really developed anything new, that is until today. I’ve re-written a game from scratch I had lost on a corrupted floppy disk called dodge, yes it’s not much of a name but it basically describes the game play in that you dodge bad guys and collect score items for points.

The original had some basic EGA graphics, but this time I’ve used text-mode characters for a few reasons. Firstly it is easier to implement both in terms of artistry and coding. The original never played well due to slowness in the interpreter and the implementation that I had used. Finally using text mode increases the effective game play area by more than 2 times, which will allow for more interesting levels. I didn’t implement any sound either in the original or the new, but music often doesn’t work well on the PC speaker and I’m not much of a composer.

Being a much more mature programmer I’ve been able to make the game mechanics better and add features that the original never had. There are 5 built-in levels (encoded with RLE) and the capability to load a custom level from a text file. The original only had randomly generated levels that were far simpler. I’ve made the movement of enemies better than the original, and gravity affects most items so that they are reachable.

I could have coded the game using a modern text editor, but for that extra nostalgic feeling I coded the game in the interpreter itself. It’s not as intuitive of course as you can’t simply scroll back and forth through the program, instead needing to use the LIST command to see parts of the program. Luckily editing a line isn’t too bad, as after display it on screen you can edit it easily. The interpreter also has some nifty features that can speed up program entry. Many keywords such as print and input have keyboard shortcuts, usually alt and the first letter of the keyword. This not only sped up program entry, but enabled me to discover keywords when I was a kid before I got the user manual.

Using the interpreter to write the code does however demand much more of your memory, I don’t remember this bothering me much as a kid, but now as an adult I needed to keep notes on the structure of the program and variables used. I would have written these out by hand on a notebook back in the day, but doing the coding with the interpreter running in dosbox meant I could run a text editor for my notes. It’s probably one of my more complex gwbasic programs at 592 lines of code.

Overall it has been quite fun writing with gwbasic again, like revisiting somewhere you went as a kid. I’m making the code available at the usual places, both my download website, and my google drive (in case the website is down). The code should work on QBasic as well as the original interpreter.

31
Jan
17

Creating a benchmark: part 6 problem solved!

Quite some time ago, in fact more than a year ago now, I was working on a basic series of benchmarks to test the comparative performance of the Borland Graphics Interface (BGI) versus a hand coded graphics library. I ran into a problem with my hand coded library not working on some of my real hardware. I ran the tests on a Pentium MMX @ 200Mhz and a 386sx @ 20mhz, it ran fine on the newer machine whilst failing on the older one. I figured perhaps I was overloading the older graphics chip.

So coming back to the problem today with a renewed sense of determination, I did some reading. There happened to be a book in the university library about programming VGA graphics, and I noted that all of their code only copies single bytes to graphic memory at a time, I was copying 2 bytes (a 16 bit word) at a time so wondered if that might be the issue. I changed it and the program still crashed almost immediately.

After some tinkering and some basic math I worked out that sprites being drawn near to the bottom of the screen were the cause of the problem. The test algorithm actually allows sprites to be drawn partially obscured by the right or bottom edge of the screen. On most VGA cards this isn’t a problem, but the trident chip in the 386sx didn’t like any pixels being drawn outside of the visible frame buffer. After writing some basic clipping into the sprite routines the program worked all the way through.

I’ve tested 3 different programs on two different real machines (as opposed to emulation). BGIbench is the original program that uses the provided graphics libraries that came with Turbo Pascal, I’ve used it in conjunction with the VGA256 BGI driver. VGABench is the initial lazy implementation of a hand made graphics library, it’s implemented entirely in pascal and isn’t optimised at all. Lastly is VGABench2 which is an optimised version of VGABench using assembly where necessary, and in the case of line drawing a better algorithm. All three programs were coded and compiled with Turbo Pascal 6.0 and use the same basic test code.

Each program performs 7 tests based around primitive functions found in the BGI. Each test counts the number of primitives that can be drawn over a period of 30 seconds. VGABench doesn’t have a function for drawing circles so it has no results for that test. The tests in order: put-pixels simply draws individual pixels a random colour. Filled Boxes draws solid coloured rectangles in a pre-defined pattern. Circles draws a number of concentric circles in a per-determined way. Random lines does what you’d expect, drawing lines randomly. Horizontal and vertical lines are similarly obvious. Finally the sprite test draws a 10×10 bitmap at random locations on the screen.

At first glance it’s pretty obvious that optimised, hand written code is significantly faster on the Pentium, particularly for filled boxes and sprites where VGABench2 achieves roughly twice the output to the screen. I managed a five-fold increase in the rate of drawing circles, which is impressive as circles are the hardest to draw. The first VGA Bench however is not really much better than the BGI and in some tests actually performs worse. You’ll note that the put-pixel tests all come out fairly close in terms of results, this is because there is little to optimise there.

I suspected that the reason VGABench2 performed so well is because the code copies 16 bits at a time instead of 8bits. I tested this out by changing it to copy 8bits at a time and found it was still faster than the BGI, but by a much smaller margin. VGABench2 copying 16bits yields about 156k sprites, but modifying it to copy 8bits yielded about 80k compared to BGI which achieves around 73k sprites. The first VGABench demonstrates how important optimisation is. It copies data 16bits at a time, but doesn’t even achieve the performance that BGI does, managing around 68k sprites.

386sx-20

The picture looks quite different on the 386sx machine, with the performance looking much more even with a few exceptions. The BGI seems to perform comparatively well across most categories only lagging behind in drawing circles, filled boxes and sprites. My first lazy implementation, VGABench seems to lag behind in pretty much everything except drawing filled boxes, which barely outperforms the BGI.

The results for VGABench2 are good, but not as good as on the Pentium machine. Line drawing is basically the same speed as the BGI. Filled boxes achieves about twice the speed, and circles about 5 times the speed, but the sprites are comparatively slower at about 1.5 times the speed. The explanation for the performance of sprites and filled boxes is interesting and is related to how the test is implemented. The filled boxes are drawn in a deterministic way, a grid of 10×10 sized boxes, the sprites are distributed randomly. Filled boxes end up being drawn pretty much always on even addresses, and sprites will be drawn on even and odd addresses around the same amount. This affects speed because of something called word alignment.

The 386sx, 286 and 8086 processors have a 16 bit data bus, which means the processor can access 16bits at a time. The memory is organised as a bunch of 16bit words, so when accessing 16 bits on an even address only a single memory word is accessed, and when a 16 bit access needs an odd address, two memory words are required. This means doing 16bit reads/writes on odd addresses are half as fast as on even ones, in fact they are about the same speed as an 8 bit transfer.

In beginning to sum up the series, it’s important to remember why I started it at all. Basically I remembered hearing many people discouraging use of the BGI mostly because it is slow compared to hand crafted code. The tests I’ve done have confirmed this, but I feel that it’s also shown how a lazy (or poor) implementation can be even slower. My optimised code is faster, but took a lot of time and effort to create and is missing many features that the BGI provides, such as support for other graphics cards, clipping, and other graphics primitives that are more complicated. I can see why many people without the time and know-how would have found it easier to simply use the graphics library provided.

That being said, hand written optimised code certainly has an important place as well. It was pretty fun and challenging to try and make something faster, even though I almost certainly didn’t get my code anywhere near as fast as more proficient assembly programmers. Also it’s hand optimised code that made many PC action games possible at all. Gaming on the PC would be very different without the hardware guru’s that could squeeze amazing things out of basic hardware. Writing this has made me reconsider my stance on sticking with the BGI for my platform game, I probably won’t gain a lot of performance, but I may be able to get it to work on older hardware as a consequence.

Code and binaries are available from the pascal downloads.




Blogs I Follow

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


Mister G Kids

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

Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm's Vintage Computing, Tech & Scale RC Blog

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

ancientelectronics

retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way

lazygamereviews

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