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.

First off, since I’ve not blogged for a while about anything Game Dev related, I thought I’d mention why.

Myself and Tom Bampton have been working on a fun side project since late last year which we’re wanting to keep under wraps a little longer, however, there’s a ton of material to blog about once we’re far enough along to make it worth discussing. Also I’ve been working on Shelled 2 which I can’t really say anything about other than it’s coming along very nicely

GP2X Competitor

Anyhow, a few things have recently caught my eye that I felt were blog worthy. The first is a semi rumor, possibly vaporwear but interesting enough to hope it isn’t. There’s a pretty lengthy thread going on over at the GP32x.com forums regarding a new handheld device under development. The reason I’m saying this might be vaporwear is it’s not clear WHO that company is, only that several prominent gp2x community members who were very active in the development of software for and/or the distribution of the actual gp2x hardware, appear to have a reasonable amount of input into the new device.

I’ve not really talked about the GP2X much since buying one way back, but it’s a great little device and quite fun to program, well worth the price compared to any other handheld currently on the market.

That’s not to say it’s perfect. It’s not. For example the joystick is a little awkward to use and the lack of d-pad support makes some games awkward to play. The volume control is software based and inconsistent, even on the lowest setting it’s way too loud for my tastes when using headphones, the setting one step lower is mute.

Still, when you consider this device is first and foremost a media player, which it does very well I might add, it’s not a bad piece of hardware and the community has worked wonders turning it into a reasonable gaming handheld.

It would however, have been nice to have better hardware support aimed at gaming and this is where the new device sounds to be a step up, with 3d acceleration, higher res screen, touch screen, more memory and wifi. All of which will increase the possible capabilities well beyond that of the GP2X which already has great emulator support and homebrew capabilities.

That said, I already have a GP2X that I’m more than happy with, the new device could just be a joke (or never make it into production) and there’s another gadget that has caught my attention more that the possible GP2X successor has.

OpenMoko

I’m not really into mobile phones, the last phone I bought was a nokia 3210 although I’ve since upgraded via a hand-me-down from my brother to a newer nokia. Even so, I very rarely use it. That may be set to change with the pending release of the Phase 2 device from the OpenMoko project.

Currently you can buy the Neo1973 (GTA01 rev.) phone which has been designed specifically for the OpenMoko project. Now the idea of fully Open Source mobile phone is very very interesting, however it’s the phase 2 hardware (GTA02 rev.) that interests me even more.

Adds to the Phase 1 phone:
* 2D/3D-Graphics-Accelerator
* 2 Accelerometers (model and number is uncertain)
* Faster CPU - S3C2442/400
* WiFi: Atheros AR6K (see also [4])

The possibilities for development on this from low level hardware hacking and coding through to end applications and games is mouth watering, at least for a programming/hardware geek

The fact that the current version on sale has the disclaimer:

What you CAN NOT expect yet
* reliable means of making phone calls, esp. not from the UI
* reliable means of sending/receiving SMS, esp. not from the UI

and the list goes on… would make most people think twice about buying a “phone” that can’t really be used to make calls yet. But I’m sure any geeks reading this will find that only adds to the attraction.

The Phase2 hardware with it’s higher res screen would make a great replacement for my current phone and Palm Tungsten C, which I use for reading ebooks and appointments. Given that it’s totally open source you can bet someone will develop most of the common apps and any that are missing will make for a good project to work on. Roll on October….

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

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

I guess the title of this post gives the game away, I’ve bought a GP2X For those who want the short review it’s amazing…

Before we get to the long drawn out first impressions, I wanted to mention that a community game contest has just begun, starting August 1st with the entry deadline 11th December, head over to www.psymastr.com/gp2x/ for more information.

It’s certainly nice to see a community contest with reasonable rules, unlike the official GPH contest where the idea behind the contest may be genuine but the way it comes across leaves much to be desired. There are too many grey areas in the rules such as whether a losing entry that GPH do not wish to go commercial with can still be self published. I imagine this is totally down to the translation rather than ulterior motives since GPH are a korean company, however the grey areas are enough to put many off entering the official contest. Instead, we’ve got a community contest to enter

Anyhow, onto the review.

Games

Aside from emulators a number of homebrew games are available including ports of Doom and Quake. But, for me, the killer app is a port of Scummvm which allows you to run all those classic point and click adventure games. With beneath a steel sky, flight of the amazon queen and lure of the temptress all freely available from the original developers theres not excuse to not give them a go

There’s also a port of Spout, a simple yet strangly addictive game. You control a little ship in a similar way to asteroids with left/right rotation and thrust only. The aim is to progress as high up the screen as you can without colliding with any terrain, with the twist that your jet spout can be used to destroy terrain and provide a clear path. Very addictive. Grab the GP2X version from the gp2x archive there’s also a windows version on although I’ve not tried it.

Flashing

My GP2X came with the latest 2.0 firmware preflashed, but I like to know the details. From what I’ve seen/read so far, the GP2X has a boot loader known as “UBoot” which loads the kernel image. Stored in NAND memory is the 32meg linux filesystem as well as a 32meg “yaffs” filesystem. Since this is an open source handheld, the source for these can be obtained from the GamePark Holdings svn server.

I’ve also downloaded the latest pre built 2.0 firmware, this will come in handy when my experimentation goes awry and it stops booting The firmware zip contains a uboot image as well as kernel, filesystem and other images.

Flashing the UBoot is a little dodgy, since a bad flash will render the GP2X unbootable and un-recoverable outside of interfacing via JTag (which I don’t have). However, if the gp2xboot.img (UBoot) is not present on the SD card, the GP2X will not try to flash the UBoot continuing on to flash the rest of the files, so regardless of whether the rest of the flash succeeds or not (or if you mess up the filesystem by other means), the gp2x will still boot far enough to attempt another flash. In short, avoid messing with the UBoot part of NAND memory and things will be fine.

Boot Sound Mod

I know this isn’t anything new, it’s also a very simple mod but since the firmware zip contained a wav file which is the boot up sound, it seemed to be a logical first customisation. Besides, it’s a good test to demonstrate that my SD card is compatible with the firmware update process.

Loading the file into Audacity shows it to be a ~2.7 seconds long, stereo file. I’ve mixed the standard sound with a Buffy the vampire slayer “Grrrr Arrrrg” end credits Mutant Enemy sound. Exported as a 16bit pcm file the size should be 233bytes exactly the same as the original gp2xsound.wav (any different and the firmware update won’t pickup the file)

Flashing, is simple, place the gp2xsound.wav in the root of the SD card and boot the GP2X with select/start held down. For the record, I used a Fat32 formatted, 1GB SandDisk SD card which despite wiki information to the contary worked fine for firmware updating and general usage.

Development

I can’t have any kind of computer device without trying to dev on it and the GP2X is no exception. What’s great about this however is how easy it is to get up and running.

Enabling USB networking and samba server on the GP2X allows access to the root filesystem. There’s a samba client app available on the gp2x archive site, which allows the GP2X to mount an external samba share, such as the gp2x folder on my development machine.

Development can be done on my PC with the resulting cross compiled gpe file accessable on the gp2x thanks to the mounted samba share. Thus testing the newly built app is as simple as connecting via telnet, killing the existing gp2x menu and running the app. This avoids having to transfer any files onto the SD card during development.

[code]
killall gp2xmenu
cd /mnt/devshare/
./testapp.gpe
[/code]

The result been testapp running on the GP2X with any debug output displayed in the telnet window You can even remote control the running app via the telnet window using keys such as U,J,K,I for up/down/left/right.

The full process is documented in much more detail on the GP2X wiki

Currently I’ve got VS2005 setup with two separate projects in a single solution, the first been a standard windows project setup to link in SDL. The second project uses the custom build rules feature to build using the arm-linux-gcc toolchain to cross compile for the Arm architecture used by the GP2X. (available as a part of devkitpro).

The Future

One thing I’m looking forward to getting my hands on is the retail version of the breakout box which exposes amongst other goodies the host mode USB port. Been able to plug an external powered USB hdd into this would be great for streaming films/music especially on holiday ( 40gig iRiver anyone? )

Plus having JTag access would remove the fear of playing with the UBoot, not that I’ve any reason to.

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

Having done a little more reading on the GP2X (GamePark Holdings) I thought I’d check out how the XGP (GamePark) was coming along and came across three videos of the prototype in action on youtube.

From what I’ve been hearing the XGP may still under go further changes before shipping, which with an estimated release date of November makes me wonder if we’ll see further delays. I’d be interested in hearing what the changes are though and how they affect the specs.

I’m in two minds whether to plump for a GP2X which is available now, has a solid community behind it as well as a good set of emulators and homebrew games available. Or, hold out in the hopes the XGP does ship on time (assuming it ships at all) and lives up to its promise. From the brief amount of reading I’ve done, here’s my current pro/con list (of course my pro/cons may differ from yours based on what you want out of the system).

The GP2X VS the XGP

XGP Pros:

• 3d hardware - Aside from anything, it’ll be interesting for homebrew development
  
• Wifi
  
• 16:9 resolution, wide-screen movies
  

XGP Cons:

• More expensive than the GP2X.
  
• 16:9 Resolution of 480×272, not really suited 10+ year old games with mainly 4:3 aspect
  
• Single processor ARM920T, GP2X has an ARM920T and ARM940T
  
• Not truly open, although an SDK will be available, GP2X appears to be more open overall.
  
• Not available yet. November estimate.
  

Both a pro and a con is the addition of an analogue stick on the XGP. Whilst useful for new commercial games and homebrew games a digital stick imho would be preferable for emulators.

Several people think of the XGP as the successor to the GP2X (albeit made by different companies) newer and better in all regards, however, from my pov both devices have their own strengths and weaknesses, so the choice is not a simple one.

On the one hand the GP2X makes for a good emulator platform, on the other hand the XGP has 3d support which would be nice to have available for homebrew on a hand-held and may help improve psx/snes emulators but then the res/joystick isn’t as suitable and I’m still questioning how open the XGP will be aside from allowing homebrew via an SDK.

I imagine the decision will be a whole lot simpler once the XGP finally ships and we get our hands on concrete information/specs. The question is will I still be on the look out for a hand-held by then or will I be busy playing/developing for the GP2X

If you’re interested in emulators check out pdroms.de for a number of public domain roms

I’ve been reading up on the GP2X a very interesting console from a homebrew point of view, why? Here’s a quote

It’s open. You want to develop your own games for the GP2X? Go right ahead. The SDK is included with the system free. Not since the days of the Amiga has a system been so easy to develop for, commercially and for fun

Not many consoles/handhelds that can claim that. The specs ain’t half bad either

Yes that’s right, this hand-held can connect to the TV, console style. Watch your DivX movies on the TV. Play emulated classics on the TV. Try big screen Quake. Or just play them all on the GP2X’s large 320*240 backlit screen. You get the best of both worlds.

It runs the free Linux operating system. This means a whole world of Games, Utilities and Emulators are at your disposal. Quake, Doom, SNES, Megadrive, MAME, Media players and Applications to name just a few.

It’s powerful - Two 200mhz CPU’s with 64meg of RAM, custom graphics hardware and decoding chips. Takes SD cards and has 64M of NAND memory. Plenty to play with.

For £125 the price isn’t that steep either. So far I’ve only read about two commercial games been available, but then most people will probably be buying this for movies, homebrew and emulator use. Still it’s encouraging to see commercial games, hopefully they’ll be a success and bring in more developers.

Been able to transfer movies over without having to re-encode for a specific format is certainly a big boost compared to the PSP. The only things it’s lacking in is 3d hardware support. The XGP (made by the GP2X’s rival company gamepark, or is it gamepark holdings?) is rumoured to have 3d hardware support included, however its not shipping till the back end of the year and I’ve yet to see any full specs to compare against the GP2X in terms of raw power and openness.

Having read that the GP2X’s developers split from gamepark (holdings?) the makers of the GP32 over concerns of openness makes me wonder whether it will be or not. I can’t see it having as much of an impact as the GP2X if it isn’t open, which would then place it in direct competition with the Nintendo DS and PSP.

Craig over at gp2x.co.uk has recently posted a new review of the GP2X and I have to admit it really sounds like a fun hand-held (although I love retro games so it isn’t hard to sell me on the idea).

On a separate note, for all the ball dropping Sony has done recently, at least they’ve made WPA available in newer firmware. Nintendo however appear to be a little more stubborn, that is if the word of a moderator on the Nintendo forums can be taken at face value

We have no plans for WPA at this time.

If your concerned about WEP, turn your computers are OFF after you’ve switch to WEP for the DS. I don’t care if The Lone Gunmen are parked outside your door with a van full of equipment trying to bust in your computer files, they can’t do it if your computers are off. And, yes, your wireless router will still work if your computer is off. Um, unless it’s plugged into the same power strip and you power the whole strip off.

If that’s not an option for you, you may want to get the Nintendo USB WiFi Connector, as it works ONLY with the Nintendo DS, and you can leave your other WiFi router with WPA.

NOTE: The reason the Nintendo DS is compatible with WEP, and not WPA, is that we found WEP to be the most prevalent standard for securing wi-fi connections.

WEP is obviously going to be more prevalent, it has been around for longer, but that doesn’t change the fact that it is also extremely flawed. I’ve not used WEP on my wireless network for some time now, in fact the only reason I delayed switching to WPA for so long was due to waiting on US Robotics to release a firmware upgrade for their wireless gaming adapter that my XBox runs off.

I’m not saying WPA is foolproof either, but at least it does offer a reasonable amount of protection. Hopefully Nintendo will change their minds on this and release a firmware upgrade (assuming the hardware is capable of coping with WPA?), either way I hope the new Nintendo console supports WPA.

As far as I’m concerned,the DS may as well not have wireless support if it remains as WEP only, there is no way I’m allowing WEP access to my network (although it’s a mute point anyway since I’ll probably get a GP2X eventually rather than a DS Hey I like old games and homebrew and favour openness over proprietary systems any day.

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.

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

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.

For a breakdown of the circuit as well as the source code Read the rest of this entry »