Figment Games

Page Turner Mk II

2011-02-22T13:00:00.010Z

Using an LCD monitor + computer for sheet music display along with the first version of Page Turner has turned out to be a much nicer experience than struggling to page turn manually. However, the iPad lacks a serial port yet it makes for a great portable sheet music display.

Enter Page Turner Mk II, a USB device that plugs into the iPad's camera connection kit and identifies itself as a USB keyboard device. It sends a page forward/backward keypress depending on which foot pedal is pressed.

The USB port shown in the photos is used to connect a standard USB cable to the iPad via the camera connection kit, as far as the iPad is concerned this is a normal USB keyboard. The two jack sockets on the opposite side of the box accept 3/4" foot pedal jacks to allowing both forward and reverse page turns.

Holding the "forward" pedal down and plugging the device into a a PC will cause the bootloader to enter flashing mode, allowing new firmware to be downloaded to the device.

Internally the device makes use of a PIC 18F4550 which includes a USB module and corresponding stack which avoids interfacing with a separate FTDI chip. A lower pin count PIC could have been used, but I had the 18F4550 spare at the time. Hardware wise, the device is pretty simple with just a few decoupling capacitors, a crystal to drive the PIC and interface connections for the two switches plus USB socket.

Since making this, the AirTurn bluetooth model is now on sale in the EU, I had planned to buy one when they became available, however I'm now tempted to make Page Turner Mk III with bluetooth instead :)

MX716/7C and SXV 64 Bit CCD Drivers

2010-01-14T18:58:00.005Z

Last year I switched over to a 64bit operating system and realised there were no 64bit drivers available for the MX716 CCD camera I use for astrophotography. Unable to pass up the opportunity to learn about windows driver programming I spent a bit of spare time creating two drivers for the camera (firmware loader and blockIO driver).

The Windows 7 64bit MX716/7C driver (v1.0.3.1) can be downloaded here, installation instructions are included.

The driver supports both the original StarlightXpress software, AstroArt and MaximDL. In addition, the MaximDL universal firmware may be used (see installation instructions for details).

I've also created 64bit drivers for the newer Lodestar guiding camera and SXV USB2 range of CCDs, these are now available for download direct from the Starlight Xpress site and are for Windows 7 64bit.

My thanks to Terry from StarlightXpress for his assistance and openness on the SX hardware.

Page Turner

2009-08-24T21:49:00.035+01:00

Its about a year and a half since I bought a Digital Piano and finally started practicing daily. In that time I've progressed quite well and the pieces I'm able to play (albeit still at the late-elementary / early intermediate level) are finally starting to increase in length to a few pages.

This has brought about a problem I'd not really considered up to this point that I'm sure plagues all pianists. How to turn the page without interrupting your playing. Given time I'm sure I could get used to reaching up and turning the page and make do with copying a few measures from the next page to get me to a suitable place to turn the page, but I'd rather not :)

A product called the AirTurn provides a solution to this problem. However, as a hardware hobbiest I decided to roll my own. Using a Laptop or LCD monitor to display the scores in either Adobe Reader or Music Reader and a serial connected foot pedal to fire off a PG Down event.

Above is a picture of the final device and a screen shots of the pedal turner .NET application which monitors the serial port and sends out PAGE DOWN keyboard events to the activate application whenever the pedal is pushed down.

The application and documentation, which also includes brief instructions on how to build your own serial connector (it's pretty simple!) can be downloaded here

As a side benefit to going digital, there's no more printing out digital music from the various on-line stores and no more hunting around for a specific score amongst the thousands of downloadable public domain scores.

With PDF Annotator or MusicReader, it's also possible to annotate the scores, adding fingering information and highlighting practice sections. Plus re-ordering pages so they're out of sequence is great for handling all those jumps back and forth in a piece. [Shortly after writing this blog I purchased MusicReader and have not regreted it.]

I've demo'd several other apps, but mostly they're related to music notation rather than playing from a score. Theres some pretty cool OCR software available for music that'll scan a score, convert it to various formats including MusicXML and allow you to play it back. Unfortunately, all the apps that include that kind of feature do not seem to offer any kind of library management nor are they as suited to playing from and annotating scores as MusicReader is.

From what little I've used of MusicReader so far, one feature I'd like to see added is a layer option. Having the ability to erase all annotations on a given layer whilst keeping marks made on other layers rather than having to be careful what you erase. Plus an option to toggle the visible layers.

I guess I can't discuss paperless playing without mentioning Hugh Sung, who's blog and youtube videos put me onto MusicReader and the pedal page turning idea in the first place. His company produce the AirTurn, which is a USB device that allows you to connect a set of pedals to your PC without wires. His site is also responsible for the expensive notion of buying a table PC that I now have stuck in my head, hopefully the idea will remain there and not make it to my credit card ;)

RA Clutch Slippage

2009-07-02T22:18:00.000+01:00

Back in 2002 when I purchased my first telescope, an 8" LX90, the first month or so of usage brought up a very frustrating problem. When slewing the scope to a new target it would suddenly stop mid-slew, yet the motors continued to whir. The cause, the RA clutch had loosened and was no longer engaged, gotos were now ruined and after tightening the RA knob to engage the clutch I had to start the alignment process over again. Very frustrating.

I solved the problem after receiving some useful suggestions from the LX90 yahoo group, not a single clutch slip in nearly 7 years usage :) Earlier today I received an email asking about how I fixed the issue so I thought I may as well type it up.

The cause of the clutch slippage is pretty simple, as is the fix. The knob that you tighten on the base of the LX90 to engage the clutch is pushing against not only the clutch but the top of the LX90 base too. As the scope slews, the friction between the base and knob is sufficient to slowly unscrew and disengage the clutch. So the fix is simply to raise the knob off of the base of the LX90.

To do so, use an Allen key to loosen the small screw on the side of the RA clutch knob. Then turn the knob anti-clockwise until it catches and starts to unscrew. It should eventually come fully off as the photo below shows.

Notice the circular scratch marks from the RA knob contacting the base.

Inserting a nylon or fibre washer (not metal) over the bolt that protrudes from the base, one that is small enough to fit inside the hole, will raise the RA knob just enough to prevent contact occuring with the telescope base when the clutch is engaged.

If you look at the base of the bolt, you should be able to make out the washer I've added. Here's a close up

Re-assembly is straight forward, just be sure the clutch is fully engaged before you tighten the tiny screw on the RA knob.

With this simple fix, you only need to apply a little pressure when tightening the RA knob and engaging the clutch. Also, no matter how much you slew the scope, the knob should no longer contact the base and cause the clutch to slip.

More recently, I've taken apart the DEC axis to fix a significant (when viewed through eyepiece) amount of slop of 5-10 degrees. When I get a spare moment, I'll upload photos of the disassembly. They show the amount of excess grease inside the dec axis and the cause of the slop, an over tightened screw on the worm gear!

CCD Image Processing

2009-03-07T01:57:00.040Z

Its been a while since I've made an astronomy post, not because I haven't had the scope out imaging, but because I haven't been all that happy with recent results. My images have been showing a nasty central brightening that prevents fainter details been brought out in post processing.

Why is this a problem? Take a look at the image below of M51. I've stretched the data a little to emphasise the brightening. The problem is that in order to bring out fainter details in the galaxy or the lower magnitude stars around the edges of the image, the data levels need adjusting. However, long before those stars are visible, the bright centre has spread across the entire image and ruined it.

Vignetting

After doing some research, it turns out this is known as vignetting and is a problem caused by the telescope optics. MAPUG-Astronomy describes this in great detail, but the important part is

The image is brightest on axis, at the center of the field of view, and dimmer off axis. This is a classical case of vignetting. Note that this is not a sharp cut off of the image, but a gradual dimming of it. Unfortunately, it is a feature of folded telescope optics which cannot be avoided.

Flat Frames

Although nothing can be done to prevent vignetting, it turns out there's a way to account for the dimming and in turn remove it from the images. Enter the Light Box. By taking a photo of an evenly lit area, the dimming of pixels from vignetting can be isolated and then in turn removed from the light frame.

I've built a light box using foamboard to construct the box and holders for the diffusers. Two sheets of opal perspex slot into the holders to diffuse the light (from four LEDs) and present a flatly lit front pane. The box is loosly based on the many designs posted throughout the net. It won't win any awards for construction, but it was cheap :) About £25 in materials which can likely be sourced for cheaper than that.

Here's an avi showing the light box image captured by the CCD in various rotated positions to ensure the field is evenly lit and that the dimming is due to vignetting and not shoddy light box construction ;)

Flat Field YouTube

Calibration

After calibrating the images with the flat field frames, here's the result.

The bright gradient has now been eliminated. All that remains is a bit of signal noise which can be handled by stacking multiple short exposures. Below is the first stacked and calibrated image. I'm still working on alternative ways to process the fits data to improve the image, but a quick processing shows promising results.

After a closer inspection of the combined frames, there is still a slight gradient from the bottom of the image moving upwards towards the centre. Whether this is due to the light box not providing a totally flat field frame or simply light pollution, I'm not yet certain.

A Trio of Galaxies

Exposure Time: 30x120s Avg
Date: 2009-03-05 03:06 UTC
CCD: Starlight XPress MX716
Scope: LX90 8"
Dark Frames: 10x120s Avg
Flat Frames: 10x0.8s Avg
Apparent Dimension: 11 x 7 arc min
Visual Brightness: 8.4 mag

The centre of the image shows two galaxies, the first and larger NGC 5194 and just above it NGC 5195. The two colliding galaxies are better known as M51 the Whirlpool Galaxy.

During processing I noticed a faint object in the lower right corner. According to the reference of bright galaxies, this is IC 4263, a magnitude 15 galaxy measuring only 2x0.4 arc minutes in size.

The image to the right has had a high pass filter applied as an attempt to sharpen the image a little. I'm still not sure which of the two I prefer most.

I've glossed over all the details of calibrating images, but if you're interested in knowing more there's a few sites with more detailed descriptions. Such as AAVSO

There's still a lot of room for improvement. Still, compared to my previous attempts at M51, I think the light box was worth every penny :)

Orion Nebula

2007-11-28T15:23:00.005Z

Winter is usually a great time for astronomy with longer nights and the sun setting at a reasonable hour, with the forecast for last Friday as clear until 12am I thought I'd put in a few more hours imaging. I hadn't realised it was a waxing gibbous moon until after I'd lugging all the gear outside and started setting up.

A nearly full moon, combined with a slightly hazy sky limited the choice of objects severely. The moon was out of the question, as I've yet to buy a moon filter, even on the lowest exposure setting of 0.001 seconds the ccd chip was becoming fully saturated. So I turned instead to the Orion Nebula, M42.

At magnitude 4.0 the nebula is visible as a fuzzy gray blob to the naked eye, just below the belt of Orion. I took a total of 90 exposures (81 usable) at 15 seconds each in an attempt to not burn out the central core on the 15 second exposures, whilst bringing out the fainter detail.

Exposure Time: 15x81s Avg
Date: 2007-11-23 23:47:55 UTC
CCD: Starlight XPress MX716
Scope: LX90 8"
Dark Frames: 15x15s Median
Apparent Dimension: 85x60 arc min
Visual Brightness: 4.0 mag

Since it looked neat, I've uploaded a pseudo colour version, this isn't in anyway the true colour of the Orion Nebula, I don't have any colour filters yet :)

I believe this is my best image to date. Although it's still not quite in focus, the exposure was perhaps too long resulting in a burnt out core. Not to mention the moon/haze made post processing a nightmare with a bright central light gradient to remove.

Collimation of the scope is still slightly out. I spent an hour before taking this image to improve it a little, but it's going to take stabler skies before I can collimate at a reasonable magnification. I think the sky stability and lack of good collimation is partly to blame for the difficulty in achieving a good focus.

I'm looking forward to re-imaging this object on a moonless night to see how big an improvement I can achieve.

"My God, it's full of stars!"

2007-09-12T13:27:00.002+01:00

The usual clouds that seem to be permanently situated above the UK parted for a few days, which finally coincided with a few evenings I had spare. The LX90 hasn't seen the night sky since way back in March, when I last had it pointing skyward for my first real attempts at collimation.

The seeing over the last few nights, has still been poor, with stars twinkling away making achieving critical focus very difficult. The collimation adjustments from March do seem to have improved things, although I still think finer adjustments will be needed on a night with better seeing.

On the first nights outing, Polar alignment was woeful and gotos were constantly 1/4 fov in the finder off. Still, I managed to image a few objects, the two most notable been a double star cluster in Persei and M33 a spiral Galaxy in Triangulum.

h Persei Open Cluster

Exposure Time: 6x60s Avg
Date: 2007-09-08 02:44:37 UTC
CCD: Starlight XPress MX716
Scope: LX90 8"
Dark Frames: 7x60s Avg
Apparent Dimension: 30 arc min
Visual Brightness: 4.3 mag

The image above is h Persei (NGC 869), which along with Chi Persei (NGC 884) forms a double cluster. The full double cluster was a little too large to fit into the tiny fov of my CCD camera, I've not calculated the exact fov yet, but it's somewhere around 30 to 60 arc minutes.

Open clusters are interesting objects as they contain hundreds, sometimes thousands of stars, all of which were born around the same time and are still gravitationally bound (however loosely) to each other. This is in contrast to Globular Clusters (such as M15 which I imaged on Monday and will upload later) which are strongly bound and often contain millions of stars in a tightly packed ball, making them stunning visual objects.

M33 Spiral Galaxy in Triangulm

Exposure Time: 15x60s Avg
Date: 2007-09-08 02:12:17 UTC
CCD: Starlight XPress MX716
Scope: LX90 8"
Dark Frames: 7x60s Avg
Apparent Dimension: 70x45 arc min
Visual Brightness: 5.7 mag

I'm quite pleased with the M33 image, the stars are reasonably well focused and the spiral arms are fairly visible. It's far from a perfect image, with a good proportion of the outer arms not visible, but considering the skies were a little hazy and how blurry my previous images have turned out, I think this is a huge improvement.

Also just about visible on the edges of M33 is NGC 604 a diffuse nebula.

I also imaged M31 the great Andromeda Galaxy, however after underestimating the sheer size of it, the image ended up containing only the bright core and a few dust lanes.

At the start of this week I also managed a third night imaging several objects, M15, M101, NGC7780, NGC 281 (Pacman Nebula ;) as well as a poor image of M42 taking during early dawn. I should have these processed and the best uploaded to this post later this week.

M15 Globular Cluster in Pegasus

Exposure Time: 15x60s Avg
Date: 2007-09-10 23:48:16 UTC
CCD: Starlight XPress MX716
Scope: LX90 8"
Dark Frames: 15x60s Avg
Apparent Dimension: 18 arc min
Visual Brightness: 6.2 mag

GID 23 - Brew Isles

2007-09-01T21:54:00.010+01:00

GID 23 took place a few weeks ago on the 11th/12th of August.

It all began at approximately 11:01.34pm Saturday night, with nearly half of GID#23 already gone and yet I still had no idea what to do. Tom suggested I team up with him to do something similar to the original Teaminator.

We had no idea what the game was going to be about only that it had to involve Tea. A large part of the core code was already in place from previous GID's Tom had done, which left us free to concentrate on more game specific issues.

The result by the end of Sunday was larger than expected and shows clear signs of the games and tv show we drew inspiration from; Monkey Island, Dizzy and Open All Hours.

I finally got around to playing Treasure Island Dizzy the other night, which I used to have for the C128 (or was it the Amiga, I forget which). It's strange going back and playing games which I played many years ago. Some games I remember as amazing, and yet on playing them again all the fond memories of how good the game was, which you've over the years raised onto a pedestal of "how games should be", comes crashing down as you suddenly realize you've built the game up to be more than it really was. Fortunately that isn't the case with Dizzy nor Monkey Island (which I'm also part way through replaying)

I had forgotten just how HARD older games really are. Most games these days you can pickup and play for some time before you die, try playing Dizzy for more than a minute without dieing several times!

The GID did highlight a few areas of the Engine which could do with improvements, which has resulted in a complete overhaul of the dialogue system to now use a node based tree structure. This enables dialogue to be constructed through a parent/child relationship of dialogue and dialogueItem nodes.

Special purpose nodes can also be inserted into the tree allowing actions to be performed on the display of specific dialogue or the selection of a dialogue option. New node types will be added in the future to support a variety of actions, for example, enabling a quest, playing an animation or transitioning the camera. A general purpose callback node functions as a stop gap until new node types are available.

The Quest system has also seen a significant improvement along with the addition of an NPC Editor

Download the Brew Isles prototype.

A few images

2007-03-29T23:59:00.003+01:00

For a change the skies were relatively clear on Monday night so I took the opportunity to take the scope out and take a few images. Unfortunately I made a few mistakes during setup that resulted in woeful polar alignment giving a 5 second max exposure time before star trailing became apparent, compared to the usual 5+ minutes I've acheived with previous drift aligning... With fog rolling in I had little time to correct it and instead made do.

Despite using the fastest exposure time my ccd camera was capable of 0.001s, the moon was still over exposed. Really a filter will be needed to reduce the light gathered by the scope for future attempts. Still with a bit of post processing I've managed to isolate the overexposure to a smaller area.

Exposure Time: 1 x 0.001s
Date: 2007-03-27 00:42:07 UTC
CCD: Starlight XPress MX716
Scope: LX90 8"
Dark Frames: 2x0.001s averaged

The second image was taken through the first wave of fog and suffered for it, especially with it been a 1/2 moon and limited to 5 second exposure times :( If I'd noticed the fog coming in, I'd have packed up before the corrector plate became saturated, the dew heater didn't stand a chance :(

Still, you can just about make out the spiral arms of M51 and the companion galaxy above as well as the effects of the moon and fog despite post processing attempts to clean it up ;) I plan to reimage this pair of galaxies on a fogless night with more suitable exposure times to really bring out the detail.

Exposure Time: 20 x 5s aligned and stacked
Date: 2007-03-27 01:26:36 UTC
CCD: Starlight XPress MX716
Scope: LX90 8"
Dark Frames: 1x5s

Tuesday was again a clear night, but yet again fog rolled in early. Knowing the nights imaging would be short, I decided against setting up for photography and instead spend the time collimating the scope to get the mirrors aligned correctly, which after allowing 90 minutes cooldown didn't leave all that long.

Seeing was only good enough to collimate with a 12mm eyepiece, still I felt it improved views of Saturn and the moon considerably unless it was a placebo effect, guess I'll find out next time I the ccd camera is setup. I'm sure given a night with better seeing allowing a 6mm eyepiece to be used, I could improve on the collimating further, which I'm hoping will improve the problems I've been having achieving a good focus whilst imaging.

Shelled Postmortem

2006-12-23T01:09:00.003Z

For anyone that hasn't already seen it, I've posted a Shelled! postmortem over on the GarageGames Site. You can also download the PDF version.

Hope you all have a Merry Christmas and a Happy New Year!

PS: Guitar Hero ROCKS! Go buy it :)

Shelled Released!

2006-11-17T00:46:00.000Z

Shelled! is finally out the door and it's FREE! For those that don't know what I'm talking about, head over to www.shelledgame.com to read about the game and download it.

I played for a few hours the other night, with 5 other people, great fun. Very easy for the odd grudge match to develop when you get shelled by another player ;) The poor AI always take a pounding in round 1 while everyone tries to stock up on cash for those nukes and high fives.

Out of all the shell types, there are only two I find I don't use at the moment. Every other shell has its uses depending upon the terrain. Slider shells are useful on very hilly terrain, high fives are great for a quick fly by shelling, the machine gun works great as a defensive shell when your jets have overheated and you have a tank inbound. The use for the leveler isn't obvious at first, but it can give a slight advantage on a few levels, I'll leave you to figure our which and how but a hint is the rocket comes into its own on the same level.

You could play Shelled! using nothing other than the default shell and do fairly well, but if you happen to play another human player that has discovered fly by high five shellings, you'll be in for a hard time making first place!

The game has a few nice tactics, which may at first not be apparent, after a while though I'm sure most people will work them out. Remember the machine gun is your friend, turtles with rocket jets are meant to fly and although the nuke is costly, nothing says good night better than a direct hit with one :D

I've had a great time developing Shelled! and wanted to say what a pleasure its been to work with Joshua, Andreas and everyone else on the Shelled team.

Happy Shelling

XGS-FrameBuffer

2006-07-28T19:35:00.017+01:00

I've been coding a basic line buffer renderer for the XGS, I say basic because firstly its black and white only (well black and a fixed colour) and secondly its still in need of a good optimisation.

The current code takes up just under one page (<512 words), however with a lot of spare cycles there's the oppertunity to reduce the code size whilst still meeting the tight timing criteria. The largest chunk of the 512 words is taken up by the numerous uses of the DELAY macro in generating the HSYNC delays, shifting this to a subrouting would make quite a difference.

The buffer itself handles 200 pixels with 4 pixel padding either side, giving a horizontal resolution of 200 active pixels and 8 overscan. Vertically it uses 208 active lines with 48/52 lines for top/bottom overscan and 4 vsync lines totalling 312 vertical lines. Although I'm considering reducing the overscan lines and increasing vsync to 10 lines to provide a greater number of spare cycles in one chunk for gameplay logic.

The line buffer uses 25 bytes of internal RAM (banks 1 & 2) for storage with each byte holding 8 pixels (thus the reason for single colour only support atm)

The line buffer is populated during each of the hsync periods utilising the spare cycles. During the active line period the code generates the required tv signal to output each pixel of the line buffer with only 20 cycles (250ns) per pixel available.

Currently the biggest question is whether 900 cycles will be enough time to generate 200 pixels worth of data and cache it to the line buffer banks. With a player sprite, enemy sprites and missiles in the mix the cycle count could be quite tight.

The main rendering loop still has quite a few cycles to spare, around 12 per pixel, however using these will mean tightly coupling the line buffer generation with the rendering, which is something I would like to avoid.

Although not in place yet, the plan is the for game logic to run during vsync, which assuming we use 10 lines would provide just over 50,000 cycles for game logic. A further 420k cycles are available during the overscan generation which means there's plenty of room for gameplay logic and music.

Part way through building the line buffer I attempted to generate a pal signal with the colour GREEN for an on pixel and BLACK for an off pixel. However, my TV would not recognise the signal as PAL with colour output when using the NTSC setting only.

As the following forum thread describes, PAL has a few extra requirements to NTSC.

1 - Colour burst on alternative lines must be phase shifted +- 45 degrees
2 - Each colour output must be phase shifted by 180 degrees on alternative lines

With James' help and a fair amount of time reading the PAL specs and XGS specs, the TV finally picked up on this been a PAL signal and displayed bars in all their colour :)

Next step will be finalising the hsync callback code to render a player sprite under joystick control.

At a later date I'll probably look into increasing the size of the line buffer to 100 bytes which would allow 200 pixels at a bit depth of 4. Then up'in the sprites from been an 8bit x 8bit block to support 4 bits of colour information per pixel. Using a palette this would allow for colours 16 colours.

A larger bit depth is plausible especially if its moved out to the external SRAM, however doing so may require some creative thinking in order to meet the timing requirements of 20 cycles per pixel.

Once the code is more functional and rendering a few sprites I'll get it uploaded, perhaps with a pdf explaining everything for any XGS owners that are interested :)

Procedural Texture Generation

2006-07-08T01:18:00.001+01:00

CGEmpire, a new forum I've been reading, posted a challenge to code a procedural texture generator. After seeing some of the examples in the challenge thread it looked interesting enough to have a go at.

I've created a DirectX app with a choice between three different texture generation methods. The first two are very simple, random and linear. Random selects a colour for each x,y pixel randomly and as you would expect is pretty much random noise. Linear draws 5 pixel wide alternating white/black bars, again nothing worth showing.

The third creates a cellular texture. This is my first attempt at generating a Cellular texture and aside from been extremely inefficient in the nearest coord calculation (brute force :( ) the results are quite pleasing.

I'm going to try a few variations on the default cellular algorithm and will post any that are worth seeing, I'll probably also add a few more texture generators based on other methods such as Perlin noise etc.

Anyhow, heres a screenshot of the first results.

Forum Link updated, thanks Fabricator.

Black and White

2006-05-25T17:05:00.005+01:00

No not the game Black and White (although it was a good game), I'm talking black and white TV, the next evolution of my console. I'd give it a name but it's currently too close (almost identical ;) ) to the Pico to warrant it. Besides, choosing a name can be a difficult business, I'll probably just not give it a seconds thought and pick anything, how about the "me", the "you", the "them", the "we"... Wii thats the ticket. Wait what do you mean its already taken? Yes I know the joke has passed, but I couldn't resist. Besides, I'm quite looking forward to it :)

I spent the better part of last weekend reading up on nodal analysis to be able to calculate the voltage at each junction of the R-2R ladder that I've added. The calculations themselves are simple, just an application of Ohms law. Simplifying the network however took most of the time, at least until the method finally clicked.

The Pico uses an R-2R ladder to convert the digital signal of the SX28 into an analogue signal ready for sending to a TV. Four pins on the SX28 allow 16 different voltages to be transmitted to the TV. The voltage levels are interpreted as intensity, however since the signal the TV uses 0.0v to sync on and 0.3v as black, that leaves around 10 voltage levels to play with.

Since the previous blog entry, I've reshuffled the layout with the power regulator on its own in the top left of the image. Partially cut off is the main power switch (currently taped down :P).

Looking at the main part of the image to the right of the SX28 you can see the R-2R resistor network used to convert the 4 bit digital signal into an analogue voltage which is adjusted to a 0-1.4v range via the bottom red potentiometer. Above the SX28 is the main external oscillator socket, the 80MHz oscillator is currently in the XGS. Just to the right of this, taped to the breadboard is a switch to select between the external oscillator and the 4 pin SX-Key header.

The hardware above is still almost identical to the Pico, however it won't remain like this for long. The first divergance is probably going to come with the addition of joystick hardware. The Pico only supports a single joystick which is connected directly to the SX28. I'd like to have two ports (pong is two player afterall :P) so will be adding a serial interface for the joysticks.

The second area is either going to be interfacing with an SRAM chip or adding extra graphics hardware to take some pressure off of the SX28. I'm not sure which way to go with that yet, nor how problematic the pin count may be

To test the new hardware I created a quick test program that outputs a white bar at the top and bottom of the screen. The code used for signal generation is the "GID j - pixel in a day" code with the colour burst generation stripped out. Nothing fancy, but at least it's working :)

Schwassmann-Wachmann 3

2006-05-11T22:11:00.002+01:00

Schwassmann-Wachmann 3 otherwise known as Comet 73P is on perhaps its final voyage around the sun. A recent hubble image shows the disitrigration quite clearly

With a good clear night on Monday, I took the opportunity to take a photograph of the comet. Yes I know, its not quite up to hubble standards ;)

Considering how little experience I have imaging, I'm quite happy with how this image turned out. I'm sure someone with more experience (read - any experience) at image reduction could improve on this.

In hindsight, I should have taken a lot more exposures for stacking and perhaps used a longer exposures time to help cut down on light pollution.

For anyone that cares, here are the image details:

Exposure Time: 5 x 1.0s stacked
Date: 2006-05-10 02:19:44 UTC
CCD: Starlight XPress MX716
Scope: LX90 8"
Dark Frames: 5 x 1s median combined

I also managed to get an image of M57. 10x10s exposures stacked with 4 median combined dark frames. Comparing the image to my star charts, I've accounted for most of the brighter and dimmer stars but there's one star that shows quite brightly that isn't listed on my star chart, if anyone knows what it is please let me know.

The biggest problem I'm currently facing is the lack of accurate focus. I'm probably going to invest in a zero image shift microfocuser to help improve on that. I also think my scopes collimation is off, something to double check next time I get a clear sky. Fingers crossed I don't spend all night on it only to make it worse :P

Hopefully with more practice I'll get a little closer to getting the most out of the scope. In the hands of an experienced user, the LX90 and MX716 are capable of much much better images.

We have a pulse

2006-04-29T21:49:00.005+01:00

Continuing my adventures with the XGS I decided to make use of the larger breadboard bought the other week from maplins (along with a nice pre cut set of jumper leads).

My long term plan is to build a simple games console capable of loading games from an external flash rom (possibly cartridge based on simply onboard via switching to access a handful of pre-loaded games). This is a lot more work than it sounds since the SX range of chips can only execute instructions from their internal rom, 2K on the SX28 and 4K on the SX52. There are ways around this which I'll cover at a later date.

There are a lot of hurdles between now and the simple console I'm picturing, so the first versions of the console will be limited to 2K of ROM and 144 bytes of RAM, basically the onboard rom/ram for the SX28. The SX28 (parallax micro-processor) is going to be the heart of my games console. The reason, because thats what the XGS used which means I have a boat load of reference docs, manuals and papers about it plus a local supplier and I'm already slightly familiar with SX assembly. Also, the SX28 is available in a DIL package which makes prototyping much simpler than the surface mount versions of the SX48 and SX52 (although I've a few of those ready for a future project :)

So the plan currently is to start very simple, and progressivly add more and more "features" to the console such as graphics/sounds/external flash rom & sram/joystick port etc If you've read the XGS ebook then you'll probably notice many similarities to the PICO and XGS which are been used as a base reference, however I plan to expand the feature set of the PICO much further. For example with the addition of graphics and sound hardware. How far this can be taken with just the SX28 and the limited output pins, I'm not sure. At the expensive of speed I can probably serialise a number of the systems although worst case scenario will be stepping the design up to use the SX48. Thats the rough plan anyway, I'm sure it will change as I learn more.

Step one was getting a power supply up and running, actually very easy to do, a 7805 regulator did all the hard work plus theres quite a good section on power supply regulation in the XGS ebook :) I'm still not 100% certain on how the capacitors reduce the ripple in the DC supply, well I understand the concept but don't quite understand the calculations enough to work out which frequencys are getting through and which are filtered. Something to work on in the future.

Anyhow, enough reading, heres a picture of a very basic SX28 project. In the top right of the picture can be seen the 7805 voltage regulator that takes a 9V DC supply and produces a 5V supply, along with the smoothing and noise filtering capacitors to clean up the 5V output.

Located at the top/middle of the image is the SX28, the heart of this project. Pin one is the top right pin with pin 28 been the bottom right pin. The connection is pretty simple, pins 2 and 4 provide +5V and GND along with decoupling capacitors. On the other side of the chip pins 26 and 27 carry the oscillator 1 and 2 lines which are connected to the pin header in the top left of the photo where the SX Key Programmer connects. Pin 28 is the /mclr line used to reset the processor by grounding (via the connected reset switch). Finally pin 18 (output port RC.0) is connected to an LED to be used in testing whether the circuit actually works.

Missing from the circuit is an external osciallator to provide an accurate clock to the SX28, I plan on ordering a selection of oscillators next week. In the mean time the SX28 has an internal oscillator that can provide frequencies in the range 31.25kHz to 4MHz, then there is also the SX Key which can generate a clock between 400kHz and 100Mhz more than enough for my purposes (although it can be less accurate than an external oscillator it will do for now).

Programming the SX28 with this setup is simple, connect the SX Key to the pin header, program the chip then remove the SX Key and we're done. That is assuming we're running the chip via its internal osciallator, otherwise the SX Key remains connected to provide a clock source. Heres the program I used to test the hardware:

; //////////////////////////////////////////////////////////////////////
    ; SX28 - V0.1 LED Blink
    ; (c) Gary Preston 29th April 2006
    ; gary@figmentgames.com
    ; //////////////////////////////////////////////////////////////////////
    include "Setup28.inc"
     
    ; ----------------------------------------------------------------------
    ; Global Data $08-$0F in all 8 banks on SX28
    org $08
    counter1  ds  1
    counter2  ds  2
    counter3  ds  3
    ; ----------------------------------------------------------------------
    ; Banked Data
     
    ; ----------------------------------------------------------------------
    ; Main entry
    ; ----------------------------------------------------------------------
    Main
      ; clear up mem avoiding 00-07 in each bank
      clr fsr
    :cleardata
      sb  fsr.4                 ; skip if accessing $10 - $1F, $30 - 3F...
      setb  fsr.3               ; offset by 8 bits to avoid first 8 mem locations
      clr ind
      ijnz fsr, :cleardata      ; keep looping until wrap around to $00
     
      mov W, #%11111110         ; RC.0 set to output
      mov !RC, W               
     
      setb  RC.0                ; default to on
     
    :blink
      mov W, /RC
      mov RC, W
      ; Running @ 1MHz one clock cycle = 1.0uS
      ; 1023 cycles per loop = 525833 cycles = ~0.53 seconds
     
      mov counter3, #2
    :loop
      decsz counter1            ; 1/3
        jmp :loop               ; 3
      decsz counter2            ; 1/3
        jmp :loop               ; 3
      decsz counter3            ; 1/3
        jmp :loop
      jmp :blink

The layout of the board leaves a bit to be desired, I'll probably shuffle things around a little for the next itteration. A few months ago I wouldn't have had a clue what any of the above did, but today it actually looks quite simple (aside from circuit analysis of the capacitor filter frequency, but I'm working on that :P)

The next task is to get graphics generation working and add an RCA output connected to the TV. How successful this will be using the SX Key as a clock source rather than a good osciallator remains to be seen.

GID j - Mission Accomplished

2006-04-10T00:17:00.009+01:00

Having only had a few hours Sunday night to work on the last part of the code I wasn't expecting to actually reach my goal of a pixel on the screen. In the end though, I managed to get a square block drawn in the center of the screen synced well enough to show flicker free on both my TV and Digital TV card in the PC.

The actual TV picture is a nice vibrant yellow, the screen capture doesn't do it justice looking a little washed out. Oh, that reminds me, the colour burst wasn't that hard afterall, just a case of making sure the colour is set in the upper 4 bits and the luma in the lower 4 :)

Adding in the VSync and overscan code wasn't that difficult, the hard part was counting all the clock cycles to make sure they met the timing requirements. In fact the most trouble was with the comparison loop where I check whether the scanline is within the block and needs to be drawn in colour. This results in 3 possible code paths all of which had to have exactly the same number of cycles before reaching the final DEALY(174-3) instruction. A little fudging goes a long way though :)

The theme for this GID was "Extreme Forces" well the forces exerted on my TV by all the badly formed signals I sent throughout Saturday were pretty extreme, does that count?

For those that care the source code is zipped up and available for download. Although it works fine on my TV that doesn't mean the code is correct so I'd love to hear back from any of the more experienced XGS users if you can see any obvious flaws. The final code weighed in at roughly 374 bytes (don't quote me on that ;) ) After looking at a few other peoples delay macros I can see a saving of several bytes there alone, so I'm sure this code can be optimised significantly, maybe another day :)

Code Dump: Be aware the formatting is a little messed up

; //////////////////////////////////////////////////////////////////////
    ; GID j - Pixel in a day entry
    ; Gary Preston 8th April 2006
    ; //////////////////////////////////////////////////////////////////////
    include "Setup52.inc"
    include "macros.inc"
     
    ; //////////////////////////////////////////////////////////////////////
    ; Consts
    ; //////////////////////////////////////////////////////////////////////
    ;
    BLACK_LEVEL EQU 6
    WHITE_LEVEL EQU 15
     
     
    ; Colors
    VID_SYNC      EQU %11110000             ; No color + 0v
    VID_BLACK   EQU (%11110000 + BLACK_LEVEL)     ; 0.25-0.3V
    VID_WHITE   EQU (%11110000 + WHITE_LEVEL)      ; 1.0V
    TEMP_COLOUR EQU 011111                                       ; yellow
     
    ; Color Burst signal
    VID_COLORBURST_OFF EQU (%11110000 + BLACK_LEVEL)
    VID_COLORBURST_ON EQU  (000000 + BLACK_LEVEL)
     
    ; //////////////////////////////////////////////////////////////////////
    ; Variables
    ; //////////////////////////////////////////////////////////////////////
     
    ;----------------------------------------------------------------------
    ; $00 - 09 - registers (05-09 = ports RA-RE)
    ; 0A - 0F - globals
    ; Banks (00-0F, 10-1F, 20-2F ... F0-FF) bank 0 via semi-direct only
     
    ;----------------------------------------------------------------------
    ; GLOBALS (Not available using semi-direct!)
    ORG $0A        ; skip past global registers and banks 1-F
    counter DS   1  ; counter required by delay macro
     
    ;----------------------------------------------------------------------
    ; defines for TV Signal generation using Bank 1
    ORG $10
    BANK_VIDEO EQU $
     
    pixels    DS 1
    scanline       DS 1
     
    ; //////////////////////////////////////////////////////////////////////
    ; Program start
    ; //////////////////////////////////////////////////////////////////////
    main
        ; Initialise ports for video (RE port tied to video hardware)
        mov RE, #000000      ; clear port
        mov !RE, #000000    ; set all pins to output
     
        ; --------------------------------------------------------------
        ; Video Kernel (Colour upper nibble, Luma lower nibble)
        ; VID_CSEL3 (b7) - VID_CSEL0 (b4)
        ; VID_ISEL3 (b3) - VID_ISEL0 (b0)
        ; Tied to port RE0-7
        ; PAL 5Mhz
        ;   312 scan lines
        ;   pixel every 181.81ns approx 292 pixels per line (53.1us / 181.81ns)
     
        ; set bank
        _bank   BANK_VIDEO
     
    vidloop  
     
        ; we have 312 lines potentially with pal but will use only 192 active
        mov scanline, #206          ; 2
    :scanline_loop
        ;--------------------------------------------------------------
        ; Horizontal signal component 274 active lines
        ; blanking voltage 0.3V for 1.5us (front porch)
        mov RE, #VID_BLACK                        ; 2
        DELAY( 120-2 )
     
        ; horizontal sync 0V delay 4.7us
        mov RE, #VID_SYNC                           ; 2
        DELAY( 376-2 )
     
        ; pre burst breezeway 0.6us voltage 0.3V
        mov RE, #VID_BLACK                  ; 2
        DELAY( 48-2 )
     
        ; color burst 9-10cycles 0.3V for 2.5us (skipping data just delay for now)
        mov RE, #VID_COLORBURST_ON            ; 2
        DELAY( 200-2 )                              ; 200-2
       
        ; post burst blanking 0.3V 1.6us
        mov RE, #VID_BLACK                ; 2
        mov pixels, #255                              ; 2   
        DELAY( 128-4 )
     
        ; All the 3 branches following MUST have the same execution time, thus
      ; the extra jumps that don't go anywhere
        ; black for 141 pixels (2037 cycles) and color for 12 (174 cycles)
        mov RE, #VID_BLACK                ; 2
     
        ; color for 12 pixels (174 cycles)   
        cjb scanline, #97, :skipcolor1        ; 4/6
        cja scanline, #109, :skipcolor2   ; 4/6
        DELAY(2037-10)
        mov RE, #TEMP_COLOUR                            ; 2 setup pixel colour 
        jmp :color                        ; 3
     
    :skipcolor2
        DELAY(2037-12)
        nop 
        nop
        jmp :color                        ; 3
    :skipcolor1
        DELAY(2037-6)
        nop 
        nop
        jmp :color                        ; 3
    :color
        DELAY( 174-5 )
     
        ; black for 141 pixels (2037 cycles)                           
        mov RE, #VID_BLACK                              ; 2 setup pixel colour 
        DELAY(2037-6)            ; inc following jump
     
        djnz scanline, :scanline_loop   ; 2/4 (extra 2 from 4 is unaccounted for!)
       
      ; END of Horizontal Component (total scanline = 64us)
      ; we're 2 clock cycles over!
     
    ; ---------------------------------------------------------------------------------------------
    ; OVERSCAN BOTTOM
    ; --------------------------------------------------------------------------------------------- 
        mov scanline, #50   ; 2
    :o verscan_bottom
        ;--------------------------------------------------------------
        ; Horizontal signal component 274 active lines
        ; blanking voltage 0.3V for 1.5us (front porch)
        mov RE, #VID_BLACK                        ; 2
        DELAY( 120-2 )
     
        ; horizontal sync 0V delay 4.7us
        mov RE, #VID_SYNC                           ; 2
        DELAY( 376-2 )
     
        ; pre burst breezeway 0.6us voltage 0.3V
        mov RE, #VID_BLACK                  ; 2
        DELAY( 48-2 )
     
        ; color burst 9-10cycles 0.3V for 2.5us (skipping data just delay for now)
        mov RE, #VID_COLORBURST_ON            ; 2
        DELAY( 200-2 )                              ; 200-2
       
        ; post burst blanking 0.3V 1.6us
        mov RE, #VID_BLACK                ; 2
        mov pixels, #255                              ; 2   
        DELAY( 128-4 )
     
        ; draw full scanline (53.1us = 4248 cycles)
        mov RE, #VID_BLACK    ; 2
        DELAY( 2124-2 )  ; 4248 is one full scanline, delay function would overflow with that amount
        DELAY( 2124-4 )  ; Really need to build a better delay function that supports longer delays
        djnz scanline, :o verscan_bottom ; 2/4
        ; full scanlein = 64us
     
    ; ---------------------------------------------------------------------------------------------
    ; VSYNC LINES
    ; ---------------------------------------------------------------------------------------------
        mov scanline, #5        ; 2
    :vsync
        ; 4 sync lines
        mov RE, #VID_SYNC      ; 2
        DELAY( 2560-2 )  ; 4248 is one full scanline, delay function would overflow with that amount
        DELAY( 2560-4 )  ; Really need to build a better delay function that supports longer delays
        djnz scanline, :vsync   ; 2/4
     
    ; ---------------------------------------------------------------------------------------------
    ; OVERSCAN TOP
    ; --------------------------------------------------------------------------------------------- 
        mov scanline, #50   ; 2
    :o verscan_top
        ;--------------------------------------------------------------
        ; Horizontal signal component 274 active lines
        ; blanking voltage 0.3V for 1.5us (front porch)
        mov RE, #VID_BLACK                        ; 2
        DELAY( 120-2 )
     
        ; horizontal sync 0V delay 4.7us
        mov RE, #VID_SYNC                           ; 2
        DELAY( 376-2 )
     
        ; pre burst breezeway 0.6us voltage 0.3V
        mov RE, #VID_BLACK                  ; 2
        DELAY( 48-2 )
     
        ; color burst 9-10cycles 0.3V for 2.5us (skipping data just delay for now)
        mov RE, #VID_COLORBURST_ON            ; 2
        DELAY( 200-2 )                              ; 200-2
       
        ; post burst blanking 0.3V 1.6us
        mov RE, #VID_BLACK                ; 2
        mov pixels, #255                              ; 2   
        DELAY( 128-4 )
     
        ; draw full scanline (53.1us = 4248 cycles)
        mov RE, #VID_BLACK    ; 2
        DELAY( 2124-2 )  ; 4248 is one full scanline, delay function would overflow with that amount
        DELAY( 2124-4 )  ; Really need to build a better delay function that supports longer delays
        djnz scanline, :o verscan_top    ; 2/4
     
        jmp     vidloop     ; 3

GID j - signal generation

2006-04-09T20:58:00.001+01:00

Having nailed the delay code I've spent most of the evening reading up on the SX52 memory architecture and the PAL timing signal. To start with I've created the signal needed for each scanline (see previous blog with timing diagram)

The first attempt didn't go too well

It was only a few minutes though before I realise my timing was out by a few clock cycles. The reason? Well in order to generate say the SYNC pulse 0.0V on RE port for 4.7µs we need to delay for 4.7µs*1000/12.5ns = 376 clock cycles, so I did the following

mov RE, VID_SYNC
DELAY(376)

The problem though is that really we've taken up 378 clock cycles and thus the code is executing for 25ns longer than we need it to. Couple this with all the other mov/delay statements for the other parts of the signal and we end up many cycles out of sync. The solution is simple, a mov takes 1 cycle or in the case of a compound mov (which this is) 2 cycles, so we just reduce the delay by 2 cycles to give

mov RE, VID_SYNC       ; 2
DELAY(376-2)              ; 376-2

The result is a lot more promising, using VID_WHITE (1.0v) for the output port RE gives us a nice white screen, however we're not finished yet, since there is no handling of the vertical sync yet.

So thats as far as I managed to get by the end of Saturday. I expected to have a good few hours sunday to work on getting the vsync sorted and plotting a specific pixel, but plans change. If I'm lucky I'll squeeze in a few more hours tonight and hopefully finish things off.

GID j - Delay Debugging

2006-04-08T19:16:00.001+01:00

As mentioned in the last blog entry, timing is cricical down to the cycle. In order to make sure all branches of code execute in the exact same amount of time I've created a delay macro. This isn't an optimal method, I'm sure there are ways to reduce the number of bytes this uses however it does the job.. at least it does after a little debugging.

After coding up the above I programmed it into the SX52 and put the SXkey into debug mode which allows you to single step the processor one instruction at a time and view the programs memory/registers and flags. Using various delays of 1, 7, 10, 14 etc I noticed the NOP repeat was only generating a single nop rather than the expected number, this turned out to be because missed the ending ENDR directive

;
    ; DELAY for a specified number of clock cycles
    ; EXPECTS:
    ;    "counter" 1 byte variable defined
    DELAY MACRO clocks
      ; eat up clock cycles 10 at a time
      IF ( (clocks / 10)> 0)
        mov counter, #(clocks / 10)         ; 2
    :loop
        jmp $ + 1                   ; 3 jmp to next instruction
        jmp $ + 1                   ; 3 jmp to next instruction
        djnz counter, :loop                ; 2/4  (4 if <> zero)
                                    ; 10 cycles per loop, 8 for last loop
      ENDIF
     
      ; handle remaining delay 1-9 using nops
      IF ( (clocks // 10)> 0)
        REPT (clocks // 10)
          NOP                   ; 1
        ENDR
      ENDIF
    ENDM

The following screenshot (click for a larger view) shows the debugger running the DELAY(14) code and circled in red the lone NOP instruction. A simple mistake putting an extra slash but one which would if not caught render the video output useless. Glad I caught it early, otherwise I might have wasted hours debugging my video code.

With the delay loop out of the way, its time to final make a start on generating accurate h/v signals. Hopefully by the end of tonight :)

GID j - Attempt 1 snow

2006-04-08T15:01:00.001+01:00

Satuday 2pm and I'm a little closer to understanding how to plot a pixel, although only a little. The first attempt to generate a video signal resulted in, well see for yourself, detune a tv channel and look at the white snow, thats pretty close to what I'm looking at right now :)

The reason been, I've not setup any kind of timing for generating the video signal yet but I know that at least I'm outputting to the correct port to generate "a" signal. After a little digging through the XGS docs I've got the information on the PAL signal specs, the main bits of interest are:

Front Porch 1.5µs
Active Video 53.1µs
Sync 0V
Black 0.3V
White 1.0V

Based on this we can calculate the number of pixels a PAL tv can cope with (@5.5Mhz), we can change the signal at a rate of 1/5.5Mhz = 182ns which gives us 53.1µs / 182ns = 292 pixels per scanline (best case; although I think my tv will do 720 due to extra bandwidth, but we'll go for a conservative value)

So in order to get a pixel (assuming no colour) on the screen I need to generate a video signal to display 312 scanlines each comprised of at most 292 pixels. Heres the full scanline signal needed for a PAL system. (I'm ignoring colour burst for now; image obtained from Haagans website)

Once the horizontal signal is up and running the vertical signal should be a snap, its nothing more than another timing signal, so we'll be sending a H Sync signal for each line followed by 4-10 lines of vsync. I'm keeping this simple and going for 274 lines at 50Hz (50 frames per second) with 16 blank lines top/bottom to account for tv variations and the 6 lines of vsync giving a total of 312 lines.

The key to this is the timing, with the SX52 processor that the XGS uses running at 80Mhz, 1 clock cycle = 12.5ns we need to ensure that the number of cycles used to generate the signal matches the above timing diagram.

There is a whole lot more to the signal generation than the overview above, if you're really interested in the details either get the XGS and read the book (which in addition covers designing and building the actual video hardware) or google it.

So the plan for the larger part of today is to get a suitable delay macro up and running and outputting the appropriate voltages to generate a stable H/V signal. Initially using a fixed value for each pixel (we'll get to plotting a single specific pixel later.. for now its a screen fill) Fingers crossed that is.

GID j - Black Pixels

2006-04-07T23:50:00.001+01:00

Its that time of the month again, we're now on GID j, for a change I thought I'd code something for the XGS. I sense this GID is going to be rather painful just setting things up ready for tomorrows start brought problems.

Lesson1: When routing the video/audio output through your digital tv card and you only get black and white check the Crystal. I'd forgot that the last time I used the XGS I'd hooked it up to my TV which supports PAL or NTSC and had been playing around with some of the NTSC only demos. I'd left the 3.57Mhz crystal in the XGS rather than the 4.43Mhz crystal needed for PAL output.

Lesson2: Prepare for things to only get worse from here on in. This little voice keeps telling me this is a bad idea. Trying to learn the details of programming a chip such as the SX52 and assosiated hardware is bad enough, but considering how rusty my asm skills are we're in for a bumpy ride.

The chances of a successful GID appear to be slim to say the least, so I'm lowering my expectation (and I mean reeeealy lowering) and instead doing a PID; pixel in a day (if you hadn't already guessed ). In other words, if I manage to get a pixel up on the screen within the time constraints of this GID I'll be happy, anything beyond that is a bonus. On a good note I've already written code to handle interfacing with the joystick port (see previous blog) so if we can get a pixel up, maybe we can get it moving, perhaps even a several pixels ;)

Hey with 4k of direct memory who knows we may even get as far as displaying a sprite, maybe two but lets not get too carried away.

Anyhow the XGS is rigged up with video/audio routed through my pc to make for easier screen grabs (erm that is assuming we get as far as displaying anything, otherwise you're in for some code dumps instead ;) ) so, for what remains of Friday night and a few hours of Saturday morning I'm going to hit the SX Programming manuals and read over the XGS hardware specs.

I think this first calls for a fresh cuppa.

Ready, Fire, Aim

2006-03-25T21:17:00.000Z

In a recent podcast Steve Pavlina talked about kick starting your business, with advice aimed at turning a profit as soon as possible. One comment in particular made me think. He mentioned how when he started speaking about personal development as a business he didn't bother making a fancy website, designing a business logo, nor making fancy flyers or business cards instead he concentrated on the things that would make him money as soon as possible, eg the website content needed to draw in visitors.

I have to wonder how many projects spent more time creating a flashy website than working on the game the site is promoting. In many cases the games never reached fruition making all the work on the website a waste.

How many people spent months designing their game only to realise its way too complicated when it came to implementation. Perhaps if they'd prototyped their ideas early and often they could have refined and expanded their original design over time rather than throwing it all out. As steve put it, "Ready, Fire, Aim" rather than "Ready, Aim, Aim, Aim, Aim...."

This kind of thinking applies to most things including coding. Ask yourself how many times have you become hung up on the best way to solve a problem, turning what could have been a few hours thought and implementation into a day or more of procrastination.

In some cases the extra up front thought is justified and can save you time in the long run, but in many cases I'd wager that after just a short amount of thought you'll have a solution worth implementing. It might not be optimal, but if it works and gets the job done you can always refine and improve later. The chances are you'll later find your solution was good enough after all and the time you've saved can be spent more on improving more critical areas.

Although his advice in this specific case wasn't anything new to me, he did put it in a much more general way than I've usually heard. A few times this week I caught myself about to embark on a new task, then thinking do I really need to do this now, will it really help me achieve my current goals. In most of those cases I decided it wouldn't and put the task to one side or in the case of coding solutions, I went with a working solution rather than spending time coming up with an elegant reusable solution when realistically I'll probably never reuse the code. Besides if I need to I can always refactor it later.

I guess I should take my own advice more often, having just spent a few hours "flashing" up my web blog. Oh well what would the world be like without hypocrisy.

The Muse

2005-12-15T21:20:00.000Z

The other day I subscribed to the "I should be writing" podcast and downloaded a few of the previous weeks casts to get more of a feel for what it was like.

One cast in particular struck a cord with me, Show #13, this show featured an interview with Scott Sigler, author of the first PodCast novel EarthCore which I mentioned in I think my second ever blog post. Scott is now embarking upon his second PodCasted novel Ancestor which I've just subscribed to and plan to catch up this weekend.

So anyway, enough of plugging Scotts podcasts (did I mention how good they are? You have subscribed havn't you?) how does this writing podcast possibly relate to gamedev?

Mur quotes a figure that 95% of Americans think they can write a novel yet only 3% of those ever finish one, let alone sell it. I'm not sure where the figures came from, however just straw polling family/friends will show it can't be that far off. Many people think they have what it takes to write a novel but in reality very few will ever finish a novel let alone sell it. Sound familiar? How many game players think they have the next best game idea, that they're going to develop the next hit RTS/FPS/MMORPG. Of those, how many actually manage to deliver? Very few! How many of those finished actually sell? Even fewer.

There are many reasons for why projects fail, however a key one is down to the expectations of the project team. I've lost count of the number of projects that have created web sites to tout their grand idea, seeing a flurry of activity in the early days as new design features are added, prototypes built, concept art and model screenshots uploaded, only to have the project grind to a halt and be abandoned. I have to admit, many of my hobby projects in the past have followed this exact trend.

What happened? It could be one of several problems, but in my experience one seems to be the cause more often than any other. To draw a parallel with writing, they lost "the muse". That creative inspiration that drives you to work. In the early days of the project everyone has it, everyone finds it easier to work on the project than not. Then the muse leaves and slowly work on the project grinds to a halt as you losing interest. Development becomes sporadic with occasional bouts of activity as and when the muse returns, but for all intents and purposes the project is dead.

So what separates that 3% from the 95%, those who finished their games from those who havn't. I think it all comes down to one factor. Self Discipline. Those who finish will most likely be the same people who day in day out work on their game, whether they're feeling the creative flow or not, some days work will fly by, on others its a real grind. Yet they keep at it. Those are the people who will succeed.

To quote directly from the show,

"I think too many people have the romantic view of writers and artists as just people who lay around and think great thoughts and wait for the muse to strike and when the muse strikes we create these wonderful works and when the muse doesn't strike, we go back to laying around."

It's only when you really try to develop a game that you realise just how hard it can be. Not from a technical point of view, that's easily overcome by a few days research and work, but more the difficulty of working through those days when you can think of a million other things to do instead. It all comes down to pushing yourself, having a strong self discipline to work regularly and finish the projects you start.

I made up my mind earlier in the year that game programming is what I want to do, even if it takes years of work before I've accumulated enough relevant experience to get a break. Who knows if game programming will be for me, you can't really tell until you've done it. What I do know is programming is incredibly enjoyable, even after 5 years full time developing information systems and countless hours spent on hobby projects. What I do know is that even the most tedious of game programming work I've done to date has still been more enjoyable than any IS programming I did in the years before. I think that may be due to games been a more challenging area of programming than standard information systems. Challenging work is always more enjoyable than easy work, at least in my opinion.

Either way, there is one problem I've encountered more than any other this year. Its just too tempting to check your email every two minutes, read through the development forums to find better ways to code something, or read up on new development techniques. On going research and keeping up with technology is certainly a valid part of development, but doing too much can do more harm than good, especially when it eats into the time you've set aside for programming. (see show #13).

I'm sure many people are struggling or have struggled with this problem, but with enough will power it is possible to force yourself through the days that feel like a grind. I find now that most days (excluding the first 10-20minutes work) I can easily slip into the coding mind set whilst managing to avoid over procrastinating, I'm more productive than I've ever been. I hadn't realised it at the time, but as Scott says in his interview, it's all a matter of scheduling. It may not be anything new, nor is it a silver bullet for success, but it does make a difference.

Listen to the interview and substitute writing for coding, novel for game and the parallels between novel writing and developing a game are striking.

Falcon 4

2005-10-02T23:09:00.004+01:00

Over the years I've played a lots and lots of flightsims, the first I remember playing in any depth was F-117 Stealth Fighter and Chuck Yeagers Advanced Flight Trainer back on the Amiga, not to mention F29 Retaliator. I remember repeated attempts at breaking the altitude and speed records in Chuck Yeagers, a great sim with great graphics, well for the time :P

I think the first flightsim I really played on the PC was called TFX, the graphics were a vast improvement over the Amiga, it wasn't until Janes F/A-18 and digital integrations F/A-18E SuperHornet that the Sim was really put into simulation. You could spend hours playing around with the flight model or sitting on the flight deck of an aircraft carrier watching the intricate takeoff and landing operations take place around you.

However, most will agree that despite its dated graphics and many bugs nothing pushed the envelope more than the 1998 release of Falcon 4.0. Imagine my suprise last night to notice a review of Falcon 4 Allied Force, how I managed to avoid reading anything about this game including that it was even been developed, until shortly after its release, I'll never know.

Although the graphics arn't bad, they're not really up to the same level of detail as Lock on modern air combat, but they're certainly good enough. Where Falcon 4.0 excelled was the realism of the simulation, and Allied Forces doesn't look like it will dissapoint.

I've only been playing it for a few hours doing little more than taxiing, take-offs and some basic flight maneuvers including stalls and recovery. I've yet to test out the difficulty level of the AI in dogfights and campaigns having yet to figure out how the radar works :P Fair enough you could use the "easy" flight model, and play it more like an arcade game than a sim but wheres the fun in that? Whats the point of having and reading that 700 page pdf manual if you're not going to learn to play the game on its most accurate realism level.

Theres a nice review of the game over on SimHQ a site that I've not been paying enough attention to over the past year or two, otherwise the development of a new Falcon 4 wouldn't have passed under my radar.

I'm sure the depth of this flight sim will provide many months if not years of gameplay, especially if it gains as good a community following as the original Falcon 4.0 did. Anyhow, I'm off to work my way through the whopping 700 page manual (I really wish there was an option to purchase a bound/printed version as you could with LO-Mac) , so I'll leave you with a few screenshots.

Oh, one last thing, having played battlefield 2 for just over a week now, I can honestly say it's great fun :) Hopefully the next patch will resolve a few of the more irratiting gameplay elements though, such as the constant respawn killing via air attacks on your one and only starting flag. If you havn't bought it yet, what are you waiting for, Quake4?? me too :P

Transistor Logic

2005-09-27T20:53:00.001+01:00

Another day, another circuit, this one is a little more complex than the LED/Resistor circuit I made the other week. Having read about transistors I decided to design and build a NAND gate. The final circuit is very similar to the one discussed in the XGS ebook (below is the original circuit schematic from the very same ebook - which I highly recommend; a print version will be out soon as well :) )

Aside from been a little blury the photo below shows my version of the NAND gate circuit built from two transistors, 3 resistors, two switches and an LED. The hardest part was finding a suitable 5V regulated power supply. I really need to buy a variable supply.

The far right of the image is where the +5V power is sourced, the far left is used as GND. The LED is connected to the +5V line via a resistor which results in the LED been lit by default. At the bottom right you should be able to make out the two switches, these connect the +5V supply to the base node of the two transistors (via one of the two 10Kohm resistors). Thus the switches control the input for the two transistors 1 or 0.

The collector of the first transistor is connected to the same resistor as the LED, with the emitter of this transistor feeding the collector of the second transistor. Finally the emitter of the second transistor is connected to GND.

The result of this is that when both switches are closed, the base of each transistor receives a sufficient voltage to start conducting from collector1 to emitter1 which feeds collector2 to emitter2 and finally running to GND. This gives us a working NAND gate. A 1 & 1 signal will result in a 0 i.e the LED will be off since both transistors are conducting to ground. Any other combination will result in a 1 as one (or both) transistor does not conduct, so we get a flow through the LED.

To most this probably isn't the slightest bit impressive, its hard to appreciate the amount of background knowledge needed in order to understand how and why even simple circuit works, as well as analyse it; until you have done it yourself. So although it isn't much to look at, I'm please with myself none the less :)

One lesson to take away from this is that it's only once you begin to understand the basics that you start to finally realise how much more there is yet to learn. BTW I managed to get the joystick position to control the state of the LED that I mentioned in my previous XGS blog entry.