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 64bit Vista driver (also works with Windows 7 64bit) for the MX716/7C can be downloaded here along with installation instructions

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 Windows7 64bit.

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

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 below are a few 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. Currently I’m using the demo of MusicReader, I’ve not yet decided whether to purchase it. I want to make sure there isn’t a better alternative. . I’ll be buying a copy this week

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

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 AVI

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: 30×120s Avg
• Date: 2009-03-05 03:06 UTC
• CCD: Starlight XPress MX716
• Scope: LX90 8″
• Dark Frames: 10×120s Avg
• Flat Frames: 10×0.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 2×0.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

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: 15×81s Avg
• Date: 2007-11-23 23:47:55 UTC
• CCD: Starlight XPress MX716
• Scope: LX90 8″
• Dark Frames: 15×15s Median
• Apparent Dimension: 85×60 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.

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: 6×60s Avg
• Date: 2007-09-08 02:44:37 UTC
• CCD: Starlight XPress MX716
• Scope: LX90 8″
• Dark Frames: 7×60s 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: 15×60s Avg
• Date: 2007-09-08 02:12:17 UTC
• CCD: Starlight XPress MX716
• Scope: LX90 8″
• Dark Frames: 7×60s Avg
• Apparent Dimension: 70×45 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: 15×60s Avg
• Date: 2007-09-10 23:48:16 UTC
• CCD: Starlight XPress MX716
• Scope: LX90 8″
• Dark Frames: 15×60s Avg
• Apparent Dimension: 18 arc min
• Visual Brightness: 6.2 mag

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

Brew Isles can be download via the GreatGamesExperiment.

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: 2×0.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: 1×5s

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.

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.

You may have noticed the books on the right hand side of this blog. I thought it was about time I started listing which books I’ve read, I’m reading or I’m planning to read. Hopefully I’ll give a short review of each once I’m done. For those in the UK I’ve added a link to the Amazon page for each book too, yes I’m after the affiliate commission but I’ll only recommend books I’ve read and found useful. Besides which, it would seem most people that read this blog are not UK based anyway.

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

PS: Guitar Hero ROCKS! Go buy it

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

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.

The Texture Generator Sample App is available for download and includes a few generators not shown in the screenshots. I think the best looking one is the Inverse Cellular

I’ll upload the final source code later on, too busy adding to it at the moment

EDIT:

Source code is now available for anyone that may be interested.

Forum Link updated, thanks Fabricator.