Archive for the 'BASIC' Category

03
Apr
20

Sparcie goes to youtube!

I’ve been thinking about creating youtube content for years, recently I finally got around to trying my hand at content creation. The technical aspects I’ve had sorted out for quite a while as I’ve been involved in supporting the technical aspects of remote teaching for quite a long time. It’s mostly the content itself which is the biggest challenge for me.

So I set myself up to record at home on my PC, I’ve installed some tools such as OBS, Audacity, Shotcut, and Handbrake, then sorted out the hardware as best I could. At the moment my microphone is probably the part that lets me down the most, being a relatively cheap one, but with everyone currently needing such technology it’s hard to get good equipment. I have an old web camera that is also sub optimal, but I don’t really plan on using it at this stage.

So what kind of content do I have planned? I’ve been planning on making some videos about gwbasic for some time, as the content I have seen hasn’t really been the sort that I’d like to watch. My first video is basically telling the story and demonstrating one of my gwbasic games that I made when I was a kid. In the future I’ll also cover stuff made by other people and in other languages such as QBasic and Pascal. However my focus is less on the programming and more on the programs themselves. Although if someone really wants a tutorial I may make a few.

I am thinking of doing gaming related content as well, perhaps some windows 9x games. I play a lot of Minecraft so that may get a showing as well.

Here’s my first video, warts and all. Let me know what you think.

09
Apr
19

Modern BASIC: PCBasic and QB64

Last month I had intended to make the next Sparcstation desktop post, but unfortunately have been having trouble getting the software I had intended to cover to build. So that’s still in the works and today we’re going to look at something else interesting: modern implementations of old BASIC Languages. It seems I’m not the only one that feels nostalgia for the old BASIC interpreters that were common to almost every machine. The two I’m looking at today are particularly nostalgic for me as I learned to program on the original interpreters.

The first, PC-BASIC is made by Rob Hagemans and is an extremely well polished GWBasic emulator. It seems to be 100% compatible as I’ve been able to run all of my old basic programs including ones that use graphics and sound. Here are some images of programs running.

This slideshow requires JavaScript.

The graphics and sound are indeed very accurate compared to MS-DOS hardware and the original interpreter. There is good support for all the graphics modes including those from special machines such as the Tandy/PCjr and Olivetti machines that had special versions of the interpreter. The PC speaker is emulated quite well (better than under Dosbox) and support for Tandy 3-voice sound is included. I’m not sure if it was deliberate, but it seems that the processing speed on my laptop is similar to what I used to experience on our old 386sx back in the day.

The next program, QB64, is a new language designed to mimic QBasic and QuickBasic with extensions that provide access to modern graphics and sound libraries. It can build native executables for Linux, Windows and Mac OS, so it’s pretty impressive and capable of producing programs for modern systems. Here are some programs running.

This slideshow requires JavaScript.

I tried to compile some of my old programs, from both GWBasic and Qbasic, and found some worked without modification whilst others didn’t work or required modification. I had some issues with the programs that did build, the first and most obvious is that the programs started in what is initially a very small window. Resizing the window doesn’t stretch the display, but pressing alt+enter does give a nice full screen display. The second issue is more complex and arises from the fact the programs are compiled and not interpreted. Basically they run way too fast because they are running at native speeds on modern hardware. This issue however should be fixable by modifying your programs with better timing code. Thirdly I’ve found one or two features from the old languages aren’t implemented, meaning some old programs won’t work, the Gorilla game that came with Qbasic being one.

An IDE is provided which looks almost identical to QBasic, so it’s very familiar and relatively easy to use. Auto indentation seems to fix old programs as they are loaded and parsed, and there is some very nice syntax highlighting, making even old programs much more readable. Although one negative point is the built-in help only covers items specific to QB64 and has omitted a language reference for the base QBasic language.

Given that we can run the original interpreters in Dosbox, how do these modern interpretations compare?

PC-BASIC is quite good in the compatibility department, working with basically everything I threw at it. The only real disadvantage it has is speed compared to running GWBasic in Dosbox, and the ability to change the emulation speed. On the other hand it has some features that appeared in real hardware, but aren’t emulated in Dosbox. (such as screen borders on CRTs) It also gives access to features found on special versions of GWBasic, such as the special Tandy graphics and sound that would be otherwise inaccessible on the standard interpreter. You can get this interpreter from his github website, I recommend using the development version as it is more compatible and has fewer bugs.

QB64 doesn’t fair so well with every older program, those that work do so quite well however. Many programs will work with a little modification, whilst others will require major re-working. I suspect the main benefit of QB64 is less about running old programs and more about building new programs. It features some extensions to the QBasic/QuickBasic language that allow more modern features of the operating system to be used such as 3d graphic acceleration and digital sound. You can get QB64 from their website, I used the stable version and found it worked quite well.

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.

20
Oct
15

QBasic Gorillas

Qbasic GorillasToday I’m looking at the classic old artillery game Gorillas, it was an example program for the Qbasic interpreter that was packaged with MS-DOS 5.0 and later. Because it was so widespread, being on practically every machine of its time, it was widely played and loved by many. I first encountered it on our high school computers in computer studies classes, we often got to play some games after we finished our work. We played many games, but Gorillas  (and Nibbles) were favourites.

Dancing Gorillas!

Dancing Gorillas!

Being written in Qbasic graphics and sound support is fairly basic. Unless you’re using an old machine with CGA only, the graphics are in high resolution EGA (640x350x16) and whilst not spectacular have some charm. Sound is PC speaker, again largely due to the limits of Qbasic. Most sounds are fairly basic, although the intro tune is kinda cool.

City Skyline

City Skyline

The game field consists of a city skyline with two Gorillas atop a building at opposite ends of the screen. Each Gorilla takes turns hurling an explosive banana at the other, with the player aiming the shots by entering the angle and velocity. The round only ends when one of the Gorillas is hit by a banana, with the survivor being the winner. There was no computer AI, so you had to play it in a hot-seat style or on your own. It’s simple and fun to play, although there isn’t much variety.

Target hit!

Target hit!

Normally this is where a post like this would end, with some kind of summary of what I thought. Today however I decided to have a quick go at making a simple modification to the game, adding an AI to the game so you can play solo. The tricky part with making an AI player in this case isn’t making something that will play well, but making something a human has a chance of beating. I could quite easily make it simply calculate the ideal velocity and angle, but that wouldn’t be much fun.

A winner is you.

A winner is you.

So what have I done instead? It’s a fairly simple algorithm, I set the initial aim to some sensible defaults and after each shot adjust the velocity depending on whether the shot landed short or long. This actually proved to be quite good at making hits, but not before making a few shots giving a human player a chance. Occasionally they will make a hit on the first shot, but that only happens when the buildings are set up just right. One circumstance that the computer does poorly is when a tall building is blocking the path of the bananas. I deal with this to a degree by making the angle higher when the banana doesn’t go very far. It will still take many shots for the AI to succeed.

I’ve made the modified version available here. It requires the original Qbasic to run and DOS in one form or another (Dosbox recommended). The game is pretty much unchanged apart from adding the AI, which you activate by naming a player Computer. You can have the computer play itself by naming both players Computer. Another improved version of the game exists, and has improvements such as a league table and improved graphics and sound. It’s called Gorillas Deluxe and can be found here.

07
Aug
14

Gwbasic Demonstrates Chaos

Back when in my late teens my older brother brought home a program that was supposed to demonstrate some of chaos theory. He originally wrote it in QBasic but I have reconstructed it here for gwbasic.

It’s a fairly simple construction, you have an “Ant” which can move in any one of 8 cardinal directions like that on a compass. Instead of being labeled North South etc, each direction is given a number 0-7 like in the diagram. As the ant moves around the screen it changes the colour of the pixel it moves over increasing its colour by 1. when the colour reaches its limit (in this case 15 as it is an EGA mode) the colour is cycled back around to 0. When the ant moves onto a new pixel it adds the colour of the pixel to its direction and uses the MOD operator to restrict the direction to the range 0-7. There is also some code to keep the ant on-screen.

The initial state requires a series of coloured boxes be drawn on the screen so there is something for the ant to react to. I’ve set up the code to pick random colours for these boxes and for the initial direction the ant travels (its initial position is fixed although it need not be). After this initial setup the ant essentially behaves deterministically.

Here are a set of images from one run of the program.

This slideshow requires JavaScript.

You can see in the first image that the ant has moved in a pretty much structured and predictable way, but as the program runs for longer the ant begins to produce patterns that seem unpredictable and random, notably the longer it runs the more “chaos” is introduced into the image. Because the ant is deterministic you’ll get the same image over time if you use the same initial state, but given any change no matter how small you will end up with a dramatically different image.

I’m no expert in the field of chaos but from what I could glean from the Wikipedia page one of the main attributes of a chaotic system is sensitivity to initial parameters, there are two other attributes, topological mixing and dense periodic orbits but I don’t really understand them. So I think the program may demonstrate chaotic behaviour, but I’m not sure that it’s a particularly good example. In any case it’s certainly fun to watch and play with the initial state.

As a bonus I coded another graphic example that produces a fractal pattern based on triangles. I was told the algorithm by a friend at Uni who had been shown the code when he was young. I’ve reproduced the algorithm here. Fractals are one of those things I’ve been meaning to learn about, but never really seem to get around to. That’s all for today!

06
Jan
14

Floppy backup and some GwBasic programs

This week my brother brought back all the remaining floppies we had at home for the purposes of backing them up. So I’ve been quite busy this weekend imaging disks and copying data. I have in the process discovered some interesting software that I forgot we had, and some I didn’t know we had. I found quite a bit of GwBasic software created by myself and my older brother. I had something like 200 odd disks to copy so it will take some time to sort the data out.

That’s not all I did fortunately, otherwise this would have been quite the short post! Before the disks came I had time to re-write a few GWBasic games that I remembered from books I read in the school library as a child. BASIC used to be a very prolific language with a interpreter on pretty much every platform, quite often in ROM. Much software was written with it including a lot of commercial software and corporate databases. There were also books and magazines abound filled with source code for various platforms.

It was a common thing for people to acquire BASIC programs from magazines or books during the 80’s. The only way to get these programs into your machine was commonly typing them in, which could end up error prone and was time consuming. Still it was quite enjoyable once you got your program running. My problem was that there was little to no source code available specifically for GwBasic where I lived.

Fortunately there were a couple of programs generic enough that did work. The ones I re-made recently were called Ghost Guzzler and Down-hill Skiing.

Ghost Guzzler

Ghost Guzzler

Ghost Guzzler is a simple game in which you have a number (a ghost) travelling across the screen towards your number. Your job is to “guzzle” the ghost before it reaches you by changing your number to match the ghost and pressing the guzzle key. I made some changes to the original. I added some proper timing code so the game is not too fast, and speed up the game as you play.

Down-hill Skiing

Down-hill Skiing

Down-hill Skiing is another pretty simple game. You’re simply skiing down a slope and need to stay on the ski run. The run will skift left and right randomly as in the original, but I added varying width to it as well. Like Ghost Guzzler it needed to have proper timing code added. This program is interesting as it uses the text scrolling features of the machine to give the illusion of movement down the hill.

Both of these programs were quite enjoyable to code, and only took about an hour to code each. It was quite a nostalgic process for me as I often spent many afternoons experimenting and coding. Now having a backup of all my old floppies in a new and better form I will revisit a few more programs.

Space Escape

Space Escape

I did this in part because of finding a website dedicated to GwBasic. The author had similarily looked on the net as I have in the past and not found much in the way of programs or information specific to this interpreter. He has posted some nifty information about his history with GwBasic, but most notably has written a new game for it called Space Escape. It shows what could be accomplished with the interpreter with relatively simple code. You can find his site here.

19
Feb
12

Trap for gwbasic

On a personal note, I recently became a dad again for the second time! So I’m quite tired and may not be very good at writing something intelligent, and todays entry will be short. The game I’m talking about today is called trap, and was written by Bruce Brandt in 1993 from what little information I could find on the internet. It was written in gwbasic and is now freeware. The game has no story, and is pretty basic. You move around a grid of rotating doors and your task is to trap the monsters that are travelling around in as little time as possible. Monsters will randomly teleport if you run into them directly or if you push a door into them. It’s surprising fun in short bursts in the same way that minesweeper is. Once you figured out the best ways to trap the monsters you can get you time down quite quickly. I was able to finish the game in about a minute at best but usually take about 90-120 seconds. You’ll find that it gets more difficult based on where the monsters start. If you find a monster at the edge of the map, it’s often a lot easier to force the monster to teleport than to try to trap him where he is. Some times the starting position of the doors can be a hinderance, but you can usually get around this. Running the game is pretty easy if you’re used to running programs in gwbasic, but there is also a pre-compiled DOS version around as well. It’s quite a difficult game to locate on the internet these days, but if you search for the author’s name and the word trap you should be able to locate it within an old BBS archive still around on the internet. I originally got it from a shareware disc from a magazine that my older brother bought so searching along those lines may also help.

12
Feb
12

Qbasic

Qbasic Intro Screen

Qbasic Intro Screen

Back when I was at high school we got some newish 486 workstations in our computer labs. Fortunately for me they had a copy of Qbasic on them which I quickly put to use. Qbasic is the language I primarily used whilst I was at high school, I wrote many larger projects than I ever could with gwbasic with the knowledge I had at the time. One of the main differences was the ability to use non-numeric labels that could mean something, and the ability to have functions separate to the main body of code. As I learned to use these features my code got neater and easier to modify, which was a good thing because the projects got significantly larger! I only ever had the version that came for free with ms-dos 6 so I couldn’t use many features that other Qbasic programmers use. This didn’t really matter cause at the time I had no other programmers (and no internet) to help guide me on how to use features and hardware directly that I had no prior knowledge of. This meant that I only really used whatever I could invent easily, or find in the user guide for Qbasic or the reference manual for gwbasic. Here are some of the projects that I made during these years.

Flight

Flight game screen

Flight game screen

This was originally a game written in gwbasic based on some space ship/jet designs me and my brother built out of lego. Here I had added many new features that were a lot like those found in the game f117a by microprose. The main goal of the game is to destroy land facilities whilst avoiding planes and SAM radar installations. The graphics were generated by vectors mostly and the small icons for the tactical display were created using the draw statement. The draw statement generated graphics in pretty much the same way as you would use the turtle in the logo language. You gave the cursor instructions on where to go and which colours to use. This was good in that I could draw images of any size and not worry about the amount of memory used, but bad in that the amount of detail was quite limited. Really it was more suited to gwbasic where I initially used this technique. One of the features in this version I learned in maths class in school. Yes, trigonometry at school helped me make the players plane fly using proper vectors flying at all angles instead of the 8 directions many games offered. Who would have thought something at school would turn out to be useful!

Puzzle and Mazing

Puzzle game screen

Puzzle game screen

One thing I did do quite a bit when learning something new was write a clone of another game to practise the technique. Most of the time the clones were a shadow of the original and puzzle is definitely one of those clones. Back in the day we used to play a game called Squarez deluxe by Adam Pederson rather a lot, I was just starting out with the bitmapped graphics and had completed two very simple games in gwbasic called jump and dodge. So to try out some ideas I had for having a lot of bitmaps I started to write a clone of squarez of sorts. I first started writing puzzle in gwbasic before I had Qbasic. I quickly ran into problems running out of memory partly because I didn’t know how to save memory on the graphics. When I got Qbasic I migrated the code across and built the rest of the game. You only got to place one tile at a time, and they usually did their thing as soon as you placed them. It was pretty much a matter of luck as to how the game played out, but this was one of the first games I built that had more than just a few sprites in them. The code became a horrible mess because I didn’t use the function feature of qbasic, and there were many remnants of the old gwbasic line numbers and code around.

Mazing game screen

Mazing game screen

Puzzle did spawn a somewhat more original game design in mazing. I took the basic tiles from puzzle and scattered them randomly around a play field, with the numbers of each tile weighted according to a difficulty level. The player had to navigate through the play field from the bottom to the top, activating some tiles as they go to help them reach the end. Some tiles blocked you from moving, some trapped you and others cleared portions of the field. You got points based on the tiles you triggered instead of a time frame reaching the exit. So when playing against another player you could lose in the sense that you didn’t make the exit, but win based on points. The code for this game was not really any better than puzzle, mostly because it was based of the puzzle code. But given that it was an experiment in game design it kinda worked alright as a game.

Bobs fury

Bobs Fury game screen

Bobs Fury game screen

One of my favourite genres of game is the platform game. Back in the day I used to play two games in particular a lot, both Xargon and Hocus Pocus. They inspired me to want to make a proper original platform game of my own. Working with my younger brother we created a simple platform game. I did the programming as my younger brother was a bit young to be able to do it, and my younger brother helped me with some of the graphics and level design. The game engine was a lot more limited than I really wanted to make when I first started, we were stuck with only two screens per level, and I couldn’t program scrolling at the time. A lot of features were cut out, I had wanted water levels like some of those that were in Xargon, as well as the normal ones within a castle or other area. But with my limited skills (and the limitations of Qbasic) we couldn’t add levels like that.  The code was a lot neater as this was one of the first programs that I wrote that used the qbasic function support. Using functions made the code a lot easier to read, but I still had a lot of bad coding habits from gwbasic, and from being self-taught. The game itself is playable but quite slow, although this could be because I’m testing it in dosbox, I believe some delay loops could be the issue. We made something like 40 or 50 different levels so there was plenty of content. I made a very basic music system for the pc speaker (via the play statement) that had a short bit of music looping that can get a bit annoying after a while. The collision detection wasn’t always the best either, mostly having issues with collisions with wall tiles rather than monsters.

Tomb game screen

Tomb game screen

I later used this engine to create another platform game called tomb, that was kinda based on an idea I saw in a magazine, a game called Pharaohs Tomb that I was not going to be able to get (but now have).  The game was different because you couldn’t kill the monsters and they couldn’t hurt you by shooting. You had to avoid the enemies whilst trying to collect the treasure. We created a different boss, either shown as a sphinx or mummy it walked back and forth across the level.

I’ve since made a Pascal port of Bobs Fury adding many features that I hadn’t even thought of back then, but remaining true enough to the old game to be able to play the old levels. I still continue to work on that version to this day, and probably have some more features to add!

Weird

Wierd game screen

Weird game screen

Yes one of my old qbasic games is named weird. This one is another attempted clone of Squarez, but one that worked out a whole lot better in game play. In order to score you have to put tiles togethor so that there are 3 or more surrounding the last tile you place. The tiles still come out individually, so it’s still not on par with squarez, but it’s quite playable and the graphics are weird to fit in with the name. Code wise it is a heap neater than it’s puzzle ancestor, but it is still all in one lump without functions. I’m not sure when in the time scale I wrote this one.

War

War game screen

War game screen

A game we played quite often was civilization, but one feature that was missing from the DOS version was some simple multiplayer support. Hot-seat play would have been fine by us as we only has the one machine! So I decided to create a simplified war game based on how you fight wars in civilization. War is played as a hot seat game, has some basic units you can build, a single screen map, and some simple to manage cities for each player. The goal being to destroy the enemies cities. I did make a basic AI, but it wasn’t very good. There are several versions of the game adapted to different scenarios and differing levels of advancement in the engine. This was one of the last games I wrote for Qbasic, and it pushes the limits in terms of complexity and sheer size in both code and memory usage. Fortunately it’s also one of the better designed games, mainly because it had to be. The user interface isn’t as well designed as I’d like, but I was running out of memory to add any thing extra. It plays quite well, and speed doesn’t seem to be an issue.

Conclusion

Qbasic Gorillas

Qbasic Gorillas

Qbasic is a powerful language for learning to program. The feature set is better than older versions of basic by a long way, encouraging programmers to make neater code, not by forcing you to, but by providing a better means of writing the same thing. I personally got a lot out of writing the projects that I did, not all my code was well written, in fact I think a lot of it wasn’t, but I learned a lot in the process. There are not many good languages good for learner programmers that also give you the power to create more complex applications. Qbasic fits the bill in many ways, but is difficult to get working on modern machines. So if you have an interest in programming I suggest you use QB64 which is basically a clone of Qbasic for modern systems with many added features, but compatibility with the old Qbasic. Microsoft also have made a nice starter language in small basic, but it is not compatible with Qbasic, which wont be a problem if you don’t require it.

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’

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