Archive for November, 2011

27
Nov
11

F117a for DOS

Title screen

Title screen

Quite some time ago as kids we got a microprose simulation pack. There were four different games, one of which was a flight simulator called F117a, it quickly became one of our favourite games. You fly the F117 nighthawk aircraft in any one of a number of realistic locations and circumstances. There are several different types of scenarios and locations ranging from cold war missions over Siberia, to full conventional war in the Persian gulf. You can deploy a variety of different weapons including smart bombs, missiles, dumb bombs and bunker busters. The game is actually an improved version of another one called f-19 stealth fighter, it features an improved engine with VGA graphics. This was partly because the nighthawk was kept a secret for quite a long time. When the original game was made it was known to exist, but no-one knew what it’s capabilities were or what it looked like. When some of the details were declassified and images made available to the public, microprose released this update to the original game. Of course as a kid I didn’t know or really care about the details of the original plane, I would have played it and enjoyed it regardless.

Graphics

End of mission

End of mission

The graphics for this game are impressive for a DOS game of it’s vintage. The graphics are VGA and polygon based with some simple shading employed. The speed of the engine even on a old 386sx 20Mhz was still quite reasonable and playable. It is also scalable in that it works quite well on faster machines such as the 486 and Pentium even though they were not available at the time. As a kid I was pretty amazed by the quality of the graphics, I had never seen anything quite as cool.

Sound

Mission Briefing

Mission Briefing

The game supports the Adlib sound card, Roland sound devices, and the basic PC speaker. Not having a Roland I can’t attest to the sound quality, but both the other devices sound good. I often use the PC speaker out of nostalgia for my old 386 which we didn’t have a sound card installed. There is one terribly annoying sound that you can fortunately turn off. The engine sound of the aircraft is a high pitched squeal that gets very tiring very quickly. You can turn it off (and toggle all sound) using Alt+V.

Gamplay

The Cockpit

The Cockpit

The game play varies a lot depending on the parameters that you set up. Being a stealth fighter there is usually very little in the way of dog fighting. Your approach to the mission will depend on the scenario. In a conventional war you can approach the targets pretty much directly and if you happen to be detected you can deal with the threat as you see fit. If you play under cold war rules, even being detected is enough for you to lose. Stealth is everything in these circumstances. You need to plan your path around SAM radar installations and try to avoid enemy aircraft. I usually played on the conventional war setting as a kid as the cold war setting was quite hard. Flying around is generally pretty straight forward. Landing on the other hand can be quite tricky, especially if you have to land on a carrier. Learning to read the instruments is a must for landing on carriers, unfortunately I’ve never mastered it and crash nearly every time.

Overall

End of mission - watercooler talk

End of mission – watercooler talk

F117a has stood the test of time for me. I  still fire it up every now and then to sneak in blow up a bunch of stuff and get out. The variable game play means you can make it as easy or difficult as you like. It gives you an idea of what flying a stealth fighter may be like. After a few flights you may feel the need to change things up, as the auto generated missions for a area can become similar after a while. Changing theatre, rules of combat, or the skill level of the enemy usually changes things up enough. You may also find it challenging to turn on the full simulation for landings, especially in the case of carrier landings.

This slideshow requires JavaScript.

21
Nov
11

DOS

With my hard disk still away for warranty, my main computer is still out of action. So today I’m writing about that which requires no screen shot for we have all seen it. I am of course referring to MS-DOS, which is for many of us my age, the first operating system we had experience with. I’ll forgo the history as that is easy to find on the internet. Today I’ll be trying to focus on the experience of using a DOS based computer.

The User Interface

The user interface was very, very different to what most users would expect to see today. The main means of interaction with the operating system directly was via the command line. Most commands were focused around operating on files that reside on disks (either floppy or hard disks). There were few other functions that the operating system provided out of the box. For new users the command line interface could be confusing and difficult to use. However there were some programs available called shells that made the system a bit more accessible to the average user. The one I used the most was dosshell that came with dos 4.01, it was relatively easy to use compared to the alternatives, and provided access to all the base features of the operating system with a few exceptions.

The Good

What made DOS good was it’s simplicity, this made it basically bullet proof. It was near impossible to crash it without either a hardware failure or third party software failure. It is notable in that pretty much all the versions of DOS made by microsoft are backwards compatible with older versions. Such backwards compatibility today is practically unheard of. The simplicity also meant that it runs on pretty much any hardware, your computer would run it as long as it had the base PC hardware required. It used very little in the way of memory and disk space.

The Bad

The 640kByte memory barrier was a big issue for many software designers for a long time. You could use more memory if you used XMS, EMS or a dos extender, but not all configurations were made equal. It could be hard to get the basic configuration right to run some programs, of which games were the most notorious. In some cases it was easier to create a separate boot disk.  As a programmer, the operating system did not provide anything in the way of support for different hardware configurations. So a lot of special hardware would have limited support for it in software, and if you didn’t have that hardware the software would simply not work at all.

There were not many options to change within the system, but for each new bit of hardware you had to install a new driver that took up precious extra memory. Changing the options themselves was a bit of a black art, and could be difficult in the earlier versions as the text editor provided was very basic indeed.

As the capabilities of hardware increased, and people moved to more seamless environments such as windows and the Macintosh systems of the time, DOS became less relevant as an operating system. We now demand more from our operating systems. They have to support a wide variety of hardware, connect us to the internet, and provide some basic software.

What would you use it for now?

It is often used as an embedded operating system where resources are limited, or for booting diagnostic utility programs. For myself I have a copy installed on an old machine for nostalgic purposes, mostly playing old games on old hardware. Somehow there is still something special about using disks and typing at the command line for me, but if you are not that way inclined there are many ways to run old software. Including running a emulator such as dosbox, or running a  copy in a virtual machine. Again if you are like me you may want the real deal. If you don’t have access to MS-DOS there is a free clone called FreeDOS if you don’t have the original, and it is basically compatible with some nice extensions and hardware fixes. Modern hardware should be capable of running either the original MS-DOS or  FreeDOS, but you should be aware that modern hardware will most likely be too fast for some old software, so some testing will be in order.

I’m interested to find out what other people have experienced with DOS. If you have something you’d like to share please leave a comment bellow.

13
Nov
11

Digger clone – Gwbasic game

Here’s an old program I wrote for gwbasic back when I was a teen. I’ve added some comments to make it easier to know what’s going on, but back then I wrote a fair bit of spaghetti code. The variable names also tend to be difficult to figure out sometimes too. Anyhow if you paste the following code into a text file, either gwbasic, qbasic or the modern remake of qbasic called QB64 will run this program. Note that the arrows on the number pad control the player and you have to have the numlock turned on for it to work. Yeah I didn’t know how to read the cursor keys for quite a while, and sometimes I continued to use this control scheme out of laziness.

Continue reading ‘Digger clone – Gwbasic game’

12
Nov
11

Hard Disk Failure

Unfortunately, my main hard disk in my desktop workstation has died. I was going to post some gwbasic code this week, but have unfortunately lost the little bit of work I had prepared. Fortunately I haven’t suffered any major loss of data, and should be able to restore most of my data from a recent backup. I’m attempting to rescue what I can using ddrescue but so far it’s not looking good. I’m currently still able to work from my macbook so I will try to get the code tidied up a bit to post here. Programming in gwbasic on a macbook in dosbox has it’s problems as there is no break key in order to stop a program.

05
Nov
11

Gwbasic – my first programming language

Gwbasic holds a lot of fond memories for me. I was about ten when dad gave me a book about programming in basic, and our computer, a 386SX with dos 4 on it, had gwbasic on it. The book I got was actually not even for the right platform. It was called 30 hour basic and was written for the BBC micro, I was fortunate in that it didn’t use any of the advanced features of the beeb, and that gwbasic supported everything in the book. I breezed through the book, typing the programs in, then trying my own variations on how they worked. Most of the programs were simple and there were basically no games in it. My imagination however was sparked, I instantly wanted to be a programmer and to write computer games, but learning to do this in gwbasic and with very little in the way of assistance from books or anything else was a bit of a journey.

For starters, there were no block if statements, or easy to use editors. Gwbasic used the same system of writing programs that the old microcomputers of the 80’s used. This meant typing in a line number and the code that you wanted, without being able to easily reference previous code. User definable functions and procedures were limited to what you could type on a single line, so I very rarely used them. I often used gosub and goto to accomplish the tasks I needed. This often led to a well know problem with basic programs. Spaghetti code! None of these things deterred me from writing and experimenting. I had found that there were shortcut keys using the alt key in combination with a letter to produce a keyword. I basically tried a combination of different things until I had worked out the syntax of the command. I very quickly learned enough to produce simple ascii games, that were usually often attempted clones of other games.

Numdrop gameplay

Numdrop gamplay

One of the first I made was called numdrop. It was meant to be a sort of clone of tetris, but being a kid I wasn’t yet good enough to make something as complex as tetris. So I came up with the idea that there would be single blocks falling like in tetris, but instead of having different shapes, I would have different weighted blocks. Larger blocks would crush smaller ones and earn you  points. My older brother helped me, by finding a timer function that allowed accurate timing for the speed of the game. As the levels progressed you had more blocks before the end of the level, and the game speed would increase.

Jump gameplay

Jump gameplay

Up until this point the most I could do with the graphics was draw lines and circles using the basic drawing commands available. Then my dad bought us the gwbasic reference manual, now I had the power! Reading the manual lead to the ability to use bitmap graphics, which as you probably know are important for games. I rigged up a simple sprite creator that basically had you entering the colour of each pixel by number, and created my first proper graphical game, Jump. It was a simple single screen platform game where you had to avoid a green monster, and a missile that would come out from it. The gameplay wasn’t great, but as a proof of concept that it could be done it worked a treat. This really was the starting point for me, now I could write proper games.

I even started to write a windows clone of sorts, called farout. This was quite an ambitious project, and I did manage to make the basics of it. It worked by having a set of routines and variables that were basically a template for each program I wanted to make. The programs would use the chain command to switch from program to program, so no multitasking was possible. A program could save it’s state before chaining back to the main program, allowing some simple windows like functionality in that you could suspend a program for use later. I even created a boot disk that automatically started it. The loading and switching of programs proved to be a little slow on floppy disk, the medium I was using the most at the time. So I whilst the base system was completed, I never really wrote many applications for it.

Gwbasic had limitations to the size of the data and code combined. It was about 60300 bytes if I remember correctly. This was only because of how the interpreter was written, the memory model it used could not take advantage of more than 64Kbytes of ram. programs were stored in memory in the form of tokens in a binary format that saved a lot of memory. 64K may not sound like much but you could do a heck of a lot with it! When it came to graphics however, and storing a lot of sprites for a more complex game, the memory was not really enough. I was beginning to want to build larger and more complex games, and upon starting them found I didn’t have enough room. This is where I stopped developing for gwbasic as a kid, and moved onto qbasic which had come out with the newer versions of DOS, and was on the computers at school.

I still have all the old programs that I wrote as a kid, and I occasionally go back to them from time to time. Recently finding one of my old games had suffered data loss (fortunately nothing else was lost)  I began to re-write it as an ascii art game. After having moved to more professional and higher level languages, programming for gwbasic was a bit of a strain on the memory. I never did this as a kid, but I’ve found keeping a running documentation of the program as you develop it helps immensely. Especially as you can’t label subroutines with sensible names. The challenge and power of the language to keep my interest has not faded, and as I write this I’m entertaining ideas of what I could squeeze into it. Stay tuned, I may fix up and release some of my code here. If you have any experiences with gwbasic, please comment bellow, I’d love to hear how others experienced the language.




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