Posts Tagged ‘gwbasic


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.


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.


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.


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!


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.


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.


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’


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.


retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way