Writing in XGS Basic is a task, but the results, when run on the XGS, can be satisfying. However, the process is a bit cumbersome and the language is incomplete and the documentation was never finished. However, the source code is freely available, so there is a way to fix some of the issues. I am not, however, ready to tackle that just yet.
No, instead, I thought I would share my process for writing and then executing code from XGS Basic on the XGS.
First, you’ll need a good programmer’s editor and one that, preferably, understands BASIC. I am using Notepad ++.
You will also need a micro SD card, which came with your board OR you can use the Serial port on your computer and the appropriate cable plugged into the board. I do not have a physical Serial port on my desktop, so I have a USB to Serial cable. However, Windows 8 does not support the cable. I have to use the SD card method.
Next, you’ll need the XGS Basic package. You can download from the XGamestation web site, but it is on the DVD you got with your board. Unzip the 1_5 version to a location on your computer and fire up that editor.
Compiling your code and running it:
Open up a CMD window, you will need this when you compile.
Write your source in your favorite editor and save it to the XGS Basic directory where you unzipped the package.
Switch to the CMD window and type: basicVM <name of the source.BAS> and then hit ENTER. (Where <name of the source.BAS> is your program file.)
Your source will compile, provided you have no errors. If there is an error, you will be told what and where it is. Fix it and compile again.
A successful compile will result in a .bai file being created (And, if you use serial, the .bai file is downloaded and executed on the board.)
If you use the SD card method, copy the .bai file to the SD card and name it AUTORUN.BAI. Plug the card into the board and turn it on. Your code should execute automatically.
Notepad ++ will allow you to automate the compile part, but I like doing things the hard way. I remember the steps this way.
Getting to know the hardware:
I am, by no means, an expert on this board. I am somewhat new to this board, but have a basic understanding (the manual for the board is superb) of the device and how to use it. XGS Basic has a few rudimentary functions and statements that talk to the hardware. The most useful, for games, will be the graphics, of course, and the gamepad. The gamepad uses an Atari 2600 like connector, but is internally compatible with the NES style gamepads. They are small, but comfortable and somewhat cheap feeling. Sound is also possible, but I’ll save that for another day.
My introductory exercise was just to interact with the gamepad and draw something on screen, kind of like a rudimentary Etch a Sketch. Now, before I go on, I have to say that my code is crap. It is but an example of talking to the hardware and not some fine piece of art. That said, take a look at the code below:
// Set the target as bitmap (not tile) option target = "bitmap" // ------------------------------------------------------ def paddle_speed = 1 // Gamepad direction defines def gp_right = 0x01 def gp_left = 0x02 def gp_down = 0x04 def gp_up = 0x08 def gp_start = 0x10 def gp_select = 0x20 def gp_red = 0x40 def gp_yellow = 0x80 // colors def RED = 5 def BLACK = 0 // ------------------------------------------------------ // // ------------------------------------------------------ call clear(0) call text(10, 5, "Draw!") Start: // Check for player input buttons = gamepad(0) // if RED button pressed, clear the screen if (buttons & gp_red) then call clear(BLACK) // go up or down, depending on the button press if(buttons & gp_up) then player1_paddleX = player1_paddleX - paddle_speed else if(buttons & gp_down) then player1_paddleX = player1_paddleX + paddle_speed end if // go left or right, depending on the button press if(buttons & gp_left) then player1_paddleY = player1_paddleY - paddle_speed else if(buttons & gp_right) then player1_paddleY = player1_paddleY + paddle_speed end if // quit if Select is pressed if (buttons & gp_select) then goto NoMore // if Start is pressed, alternate the color if (buttons & gp_start) and pdColor = RED then pdColor = BLACK else pdColor = RED end if // if yellow button pressed, cycle the color if (buttons & gp_yellow) then pdColor = pdColor +1 if pdColor > 16 then pdColor = 0 end if end if // let the system catch up before updating the screen waitforvsync // draw our dot plot (player1_paddleY, player1_paddleX, pdColor) // go back for more goto Start NoMore: // end
The things to note are:
gamepad( 0 )
call clear( 0 )
call text( x, y, text)
Call CLEAR( 0 ) clears the screen to black and Call TEXT(x,y,text) will display a string at the x,y coordinates on the screen. Simple enough. Now, for the fun stuff.
gamepad( 0 ) refers to the ‘player one’ controller while gamepad( 1 ) refers to the ‘player 2’ controller. For our purposes today, we only have a player one controller.
PLOT (x, y, color) puts a pixel of color at the x,y coordinates.
WaitForVSync halts execution until after vertical blanking occurs. This should be done before drawing to the screen.
Most of my demo code is made up of interpreting the gamepad, so lets talk about that.
In order to interpret which button the user has pressed, we must ‘AND’ the button press with the value of the button we want to check for, so…here’s the values we need:
// Gamepad direction defines
def gp_right = 0x01
def gp_left = 0x02
def gp_down = 0x04
def gp_up = 0x08
def gp_start = 0x10
def gp_select = 0x20
def gp_red = 0x40
def gp_yellow = 0x80
You can copy that table into your code, near the beginning and before you check the gamepad. The ‘def’ simply tells BASIC that you are DEFining some constant values. Now, remember, you have to ‘AND’ the gamepad return value with the button value, such as:
// Check for player input
buttons = gamepad(0)
// quit if Select is pressed
if (buttons & gp_select) then goto NoMore
Notice, we get the current state of the gamepad using the ‘gamepad( 0 )’ function. It’s value goes into the variable ‘buttons’. Next, we check to see if the user has pressed the SELECT button and, if so, we goto the label ‘NoMore’ and continue execution from there. Go back and look at the demo code above. Go on, I’ll wait.
Oh, back so soon? Ok. Now, if you notice, we check for the directions (up, down, left, right) and the select, start, red and yellow buttons. Each one has a purpose: the directionals, of course, will change the direction we draw, start will alternate the color, select will end the demo, red will clear the screen to black and yellow will cycle the color (which, does not currently work because of the start button functionality. I’ll fix that in another post.)
See how easy it is to interpret the gamepad? Next time, we will take a look at some of the graphics stuff and discuss the two modes available (bitmap and tile) in XGS Basic.