I was having some issues with my A1200 constantly crashing and resetting, and at the time I had been using an old, original white power supply box. A friend of mine had suggested that I get a new one, as the caps might be going bad in it. It would certainly explain the resets at random occasions and a few other things, so rather than buy a new one, I decided to convert an old ATX power supply I had laying around and make use of it.
As with all things power related, if you plan on trying to make one of these things at home, make sure it is unplugged and de-energized! I will not be held responsible for anyone electrocuting themselves!
So, what do we need to get going?
- An old ATX power supply, any size will do. I used an old 250watt supply.
- An old Amiga Power Supply or Power Connector
- On/Off switch. I was creative and re-used one (See Below)
- Crimp Tool/Insulation Tape
Step 1 – Prepare the Power Connector
Before we can start, we need to be able to connect the power to the Amiga. The best way to do this is to acquire one from an old Amiga supply. Most Amiga fans have several laying around, I used one from an old supply I had brought over from England years ago. It’s not much use to me here in the USA anyways 🙂
Open up the power supply, and cut out the wire at the base of the transformer. This will give you the maximum amount of length available on the new project. You can of course cut it down if you want a shorter one. My current desk doesn’t have a very good power layout, so having a 6 foot cord worked out quite well.
Step 2 – Acquire A Power Switch
Due to the ATX power supply needing a short to work, the best and easiest way to regulate this is to use a simple power switch. Being creative, I used the one that was already in my existing Amiga PSU and cut it out with a length of wire. It also helps to keep it a little more nostalgic!
Step 3 – Prepare the ATX Power Supply
The easiest way to make this work is to cut off one of the Molex connectors on the line that powers a HD. Most ATX supplies have some that are longer than the rest, just cut the plug off the end. You also need to cut the Blue line from the ATX Motherboard connector (-12V). Make sure to clean the other end up, so theres no exposed wiring hanging around. In the next step, there is a table showing the common colour codes for the Amiga wiring.
Step 4 – Assemble The Wires Together
Theres a number of different ways to connect the wiring, some people prefer to just twist wires together and tape them, but you can also use a crimping tool, or a terminal block. The good thing with terminal blocks during the testing phases is that you can swap the wires around if you do manage to get them mixed up. Below is a table showing the common wiring colours of the Amiga to ATX connections. Some Commodore wires may vary in colour, if this is the case, see below to determine how to make sure you have the right ones. It is crucial that it be correct before it is plugged into your Amiga. Don’t blow it up!
Assemble/Connect the wires as shown in the table. Make sure they are safe from coming into contact with each other.
|Amiga Wire Colour||ATX Wire Colour||Voltage/Supply|
Step 5 – Connect The Power Switch
Now we need to connect the power plug to the ATX supply. On a normal motherboard, this is done by shorting out 2 pins together. This is why using a switch makes the job perfect. The simple way to acheive this is to look at the blue wire we cut off the motherboard connector. The pins to short are directly next to it (See the picture above) in the form of the Green & Black wires.
Cut these wires and follow them up to the power supply, you can then attach the switch directly to these Green & Black wires and voila! You now have a working switch. When the switch is on, the power supply will work, and then flick the switch to turn it off again. Remember, not all ATX power supplies have a power switch in the back of them, so this is a perfect solution to the problem.
Step 6 – Test The Crap Out Of Your Wiring!
I can’t stress enough that you DO NOT plug this new power supply into your Amiga until you have FULLY tested that it’s wired up correctly. If even one wire is not correct, your Amiga would be toast. Take the time to test your work, before plugging it in! All you need is a simple multimeter to read the voltages.
I drew a quick diagram of how to read the values. When you are holding the ATX side of the power plug and looking directly at the pins, each one should measure exactly as they are pictured in the diagram. Place the Negative electrode on the outer shield of the connector, and touch the Positive electrode on each of the pins. You should get very close to the values shown. If a wire is in the wrong location, then you need to fix it and test it again. It’s extra-important to test this when your Amiga wires don’t match the colour table above.
Step 7 – Give it a whirl!
When you are confident your wiring is all good, you can give it a try in your Amiga! She should boot up just the same as before, so take note if any wierd behaviour occurs. In my case, my A1200 booted a lot quicker and almost all my crashes and random resets stopped happening. It wasn’t until I did this, I realized how bad my original power supply really was!
If you have any questions about this, feel free to ask them in the comments. I hope you find this useful!
As far as work goes, I have spent the last few months working with the Bosch Rexroth aluminium profiling system (or Aluminum as my american friends like to call it). For those who have never heard of it, it’s a system of metal profiles, or struts, that interconnect similar to Meccano/Erector Set and it is used to build structures, desks, and anything else you can think of. I really like the system, and maybe I will start blogging about some of the various things I have built if there’s interest. I currently use it to build workstations, tooling, and small cabinets to house various pieces of equipment.
I have done a bit of coding, I made a great start to my Mahjong game, and hope to finish it as soon as I get some available time!
My company has been lucky enough to purchase a brand new Schleuniger MegaStrip 9650 & PreFeeder machine. This beauty has the rotary incision box, and I have it set up and configured to work with Cayman software.
I was travelling to Europe last month as part of work, and was lucky enough to go to the Schleuniger facility in Thun, Switzerland for two days to do some testing on this machine before we purchased it. I toured the facility, met some of the engineers who designed and made their products, and learned a great deal. As always, Schleuniger were excellent hosts, thanks a lot guys 🙂
This machine will be used primarily to cut corrugated copper cables, about 16mm thick. The Cayman software will be configured with the various different connectors we use on our cables, then the lengths can be tweaked in later. It’s always nice to get a late christmas present, and i’m going to have a lot of fun working with this machine 🙂
In the next few weeks, this bad boy will be shipped off to the datacenter and installed in it’s rack, so the site can receive a much-needed upgrade.
If you want to check out CVGM and listen to some great oldskool computer game music, check out http://www.cvgm.net Thanks!
A few weeks ago, I took a bunch of my old computer systems (Atari’s, GameBoys and Sega Systems) to my kid’s school to show them off as part of his “History Of Video Games” project he had worked on. Several of the kids ask me, as a games programmer, how I make them, and even my own kids recently have started asking questions about how I make the small games that I do, so I thought I would write this up showing how I made my Reversi Magic game to hopefully educate them a little bit, and also anyone else who might be interested in learning the process.
Firstly, I should start by saying that the various methods used by different people tend to be very different; I take a more OldSkool approach to writing games than say, some of the modern game programmers. Also, being that I work mostly in my spare time, at home, at night, in-between a full time job & managing the kids, some things get done with more priority than others. Someone with more resources/time etc. can probbably get things done a lot quicker. That being said, i’m always open to feedback so feel free to comment on this if you have some 🙂 Don’t shoot me if I do something differently than everyone else 🙂
Coming Up With Ideas
Before I start laying in any amount of code, I usually try to come up with an idea of where I want the game to go. Depending on the game and whats going on, there might not even be an idea yet. Ideas tend to come from existing games, so you might have a couple of web games that seem good, but if one had this feature, or copied ideas from this, it might be even better. If I have a general idea of what I want to work on, i’ll take an empty project file of mine (which consists of the game basics such as the menu’s and basic graphics, enough to be able to press Play, and just start adding game code right away) and modify it to work with a very crude, but simple engine showing the gameplay for this idea. This will be tweaked until the game is able to do what I was thinking of, then its evaluated for how well it plays.
In this picture, this game (called Avalanche!) was put together in about 2 days altogether, to show off some ideas I had about a columns-based game, and matching snowflakes together to make some cool snowy explosions etc. In the end, I never released the game, but it was fun to work on the prototype.
In the past, I have prototyped as many as 30+ different game ideas, some better than others, until something comes up. Often, you’ll know when a good idea comes up as you’ll find yourself playing it for ages, while not getting bored of it. Also, your friends might like playing it too. They are also handy to come back on later as well, i’ve worked on some I haven’t touched in years, bringing some new changes and various elements to the table that turn it into a better game.
The Design Process
Once you have thought of a solid idea to work on, it’s often a good idea to do a brief design draft of where the game should be heading, so that you don’t fall off the wagon too easily. If you’re going a route that’s not recommended or you get stuck what to do next, you still have your plan to fall back on for guidance. Again, depending on the type of game you are writing, you can also define a list of specific behaviour rules here, that must be followed at all times. For example, if it’s a puzzle game, you would lay out the logic here exactly, so that you know exactly how it’s supposed to play. If its doing something its not supposed to, you can later analyze this logic to start tracking bugs. This is more important for larger games, or puzzle games that have a lot of different AI/Logic combinations.
Normally I do paper notes for almost all of my games, I still have notebooks with designs in them from my days of writing programs on the ZX spectrum games! One day, i’ll put all that stuff online, but it won’t be today hehe 🙂
Below is my notebook pages that I did for my Reversi Magic game, that’s currently available on Android, iOS and Kindle Fire. The notes were done a year or so ago. The idea was very simple, and I have always been interested in playing Reversi on the computer, with this game not being my 1st on the computer. The goal was to make a simple, easy to pick up game that anyone could familiarize themselves with, without having to learn any new rules or be bombarded with over-the-top graphics. Not all games require notes, but it doesn’t hurt to play with pen/paper every so often to make some design sketches. These 2 pages are the design spec that I originally set forward to complete:
The 1st page just covers some simple layout rules and goals that I would like to have the program meet, and the 2nd page shows some interface layouts for various orientations, and a few other design elements such as an idea I had for dynamic grid frames.
I spent a full month of non-stop coding of the AI engine for the game. The tough parts were testing it to make sure it plays 100% compliant moves, so in the end, there would be a long debug report of the game, how the computer did, as well as opportunities that it took/missed so I could review and tweak the AI later. The AI algorithm itself is based on a combination mix of NegaScout & Min/Max game theories. The Min/Max algo will evaluate scores recursively for the Best/Worst possible scoring points, and NegaScout does some pruning to several paths in that tree, to ensure the answer it comes out with can be found faster. Combine this with some traditional elements of gameplay, a method of looking at grid moves to determine how risky they are, and you have a very powerful AI routine. You can learn more about the Min/Max methods Here in this great tutorial (with samples and images).
The next hardest part of programming the AI was to teach the computer not to be too hard on beginner players. Its programatically easy to make the computer as hard as nails when it comes to playing the game, but how do you adjust those levels so that they are somewhat forgiving to a new player? Again, with a reverse NegaScout algo, and a few other traditional playing rules implemented, the computer will now assist the player to some extent when playing its moves, so as not to dominate. Of course, there are always some people who are just not very good at the game (or Reversi in general), and as I have seen on the feedback for my games, they think the game is the fault and tend to leave negative feedback because of that.
Your game should also show assists/help to your players, for when they get stuck and cannot decide where to play a move. They also may not realize they can play a move in certain areas. In Reversi Magic, I added options that show you where you can place a tile, they actually cycle in and out as small transparent disks of your colour. Tap the disk to place your move. There is also an option that shows you where the opponent last moved, so if you are not following the board too closely, you can still see where they last played and how it affects your strategy. Both of these assist options can be turned off in the game Options screen at any time, though they are enabled by default for first time users of the game. In my original design, I had wanted to show how many disks were going to be flipped for each move that was shown as available, but as experienced players will tell you, playing for the best possible score every time is not the best playing strategy at all, so I eventually removed it.
Cleaning Things Up
Now that the majority of your code is done, the last part of the process is to apply the spit & polish needed before you release it. For me, this is usually when I will finalize all of my graphics, and add all of the last bits of fine tuning to the game. Normally, i’ll sit in a room with my Nexus 7 and play the game, write down all the stuff that I see that is annoying, or needs fixed (out of place text, menus that move too slow, playing effects that should happen that don’t, ways to improve the ingame experience etc. etc.) and then after I have the list, i’ll set forth on making the changes. If you are not already doing so at this point, its often a good idea to send out your game to some private testers. Friends/family often make a good choice, but you want to pick some who are open to give you criticizing feedback (and some who will actually give feedback!) Listen to their complaints and what they think might make the experience better. You might not be able to implement it 100% exactly as everyone wants it, but you might be able to meet in the middle, especially if several testers are reporting on one specific area/feature of the game (which normally means you should focus some effort on it anyways).
From Prototype, To Finished Game
In the above pictures, I have used my game Twinz! as an example of what the game may look like in prototype, to the final product. The left screenshot is from the prototype game I did in about 2005 or so. It was just a handful of images, a simple shaded image for the door shutters, and a small logo. The image on the right is taken from an iPhone running the released version of the game. As you can see, the screen’s real-estate has been cleaned up to make the size of the tiles more optimal, and get rid of the unused areas. This game runs great on tablets, and features high resolution tiles.
After the launch, you can sit back and watch your total downloads go up for each market, and wait for your customer’s feedback. Most players are nice in that they will contact you directly about any bugs they might find, before they leave negative feedback, so if you do get not-so perfect app feedback, or bug reports, be sure to get right on top of them and prepare for an update in the future.
While I have yet to become mega rich or famous from one of my games, this is still a hobby that I love to do, and hope that one day at least one of my games will be successful enough that I can quit my job and focus on doing this full time 🙂
If you want to play any of the games mentioned above, or any other games of mine, please visit the app store for your preferred device and try them (there are free versions of all of my games): Amazon App Store (For All Kindle Fires), Apple App Store, Google Play
Should you find the info in this page useful for anything, show your support by buying a game! If you have questions, ask in the comments or send me a quick email. Thanks!
Today I released a new version of my popular Litecoin Miner Status program. The tool sits in the background of your computer and monitors various litecoin mining pools for your mining activity. The program does not do any mining of it’s own, it simply watches the pools that you mine at to provide you with statistics about how well your miners, and your profits are doing. You can go directly to the application page Here or by the Discography -> Litecoin Miner Status link at the top of this page.
Lots of changes & tweaks have gone into the new program, including the addition of new pools to monitor. If you mine LTC and wish to keep track of your mining rigs or your coins, give the program a try.
I have been spending a lot of time lately working on Reversi Magic, my Othello/Reversi game. Since the game was originally released last year, I have been spending time on optimizing the various parts of the game for AI, appearance, and also ensuring that it works on absolutely any device out there. The game has certainly come a long way since I originally started working on it!
The game’s AI functions make use of a NegaScout/PVS algorithm to determine the best possible moves based on a series of conditions, such as difficulty, board status and a few other things. The easy level is designed to be not too difficult, but good enough to keep you alert during play. As the levels get harder, the AI will step up it’s game and the Hard levels are quite tough to beat! I spent close to a full month working on AI code alone, and it was very educational for me. One day I should write up something on how the AI works, as someone else might find it useful in a different game.embedded by Embedded Video
Anyways, if you would like to give the Free version of the game a go, you can find it at your favourite App Store by clicking one of the links below:
Screenshot Gallery for Reversi Magic:
Recently I purchased a new Dedicated server box running Ubuntu 8.10 / DirectAdmin and needed to transfer a bunch of my stuff to it. One of the sites I needed to trandsfer was CVGM ( http://www.cvgm.net ) which is powered by Django / Python / Mod_WSGI. I couldn’t find many instructions on the net on how to complete the task easily, so after I figured out how to do it, I wanted to post my results here so that other people who need the same kind of help can find the post and maybe use it 🙂
The DirectAdmin default setup uses a customized version of Apache in order to work, and as a result, it’s not as simple to work with/customize as a regular install of apache. To give you an example, if you would apt-get a module (such as mod_wsgi) that relies on apache2 as a dependency, it thinks apache2 isn’t even installed, so be careful! The global config file for the DirectAdmin apache is /etc/httpd/conf/httpd.conf and I should point out that right now, you should not edit anything in this file whatsoever!!
First, we need to install the Apache module for Mod WSGI. I copied a version of the file from a copy of 8.10 Server I installed on a VM to make sure it matched the same system requirements (Python 2.5) however you can always build one, or obtain one from somewhere on the net. Once I built the file, I copied it to /usr/lib/apache/mod_wsgi.so on the dedicated box.
There are two ways that you can proceed to activate the module, and i’ll explain both ways. The 1st way is probbably more beneficial if you plan on running multiple WSGI applications, whereas the second is better if you just plan on running a single site and you don’t want to initialize it for every thread your apache creates.
Enabling As Global Module
This is the simplest method of enabling the module. Open the following file for editing:
There should already be a line in there for PHP, so we only need to add the following line underneath it:
LoadModule wsgi_module /usr/lib/apache/mod_wsgi.so
Save and Exit the file, if you restart the httpd instances within DirectAdmin, they will all have access to mod_wsgi features.
Setting up a VirtualHost to run a WSGI Application
I’d like to point out here that we are manually editing/changing the automated VirtualHost information generated from within DirectAdmin, so DirectAdmin might change it all back again if you go to edit anything through the admin panels. Remember, when it works, back it up in case that does happen!
The VirtualHost lists are defined in a user’s httpd.conf file, so to edit the list for your site, run the following command:
vim /usr/local/directadmin/data/users/[UserName]/httpd.conf (Replacing UserName with the user account name set up under your site)
Modify the top portion of your Vhost file to look like the following, with your own WSGI settings of course:
# Frontpage requires these parameters in every httpd.conf file or else # it won't work. ServerRoot /etc/httpd WSGIDaemonProcess ProcessName threads=25 WSGIProcessGroup ProcessName <VirtualHost *:80> ...
Inside the VirtualHost container, you will add your actual WSGI code as such:
# Load the WSGI adapter just for this VirtualHost, if you choose not to enable it # Globally. Do not add this line if you added the module globally!! LoadModule wsgi_module /usr/lib/apache/mod_wsgi.so # Set up Aliases to Django admin, and our own static files Alias /media/ /usr/share/python-support/python-django/django/contrib/admin/media/ (path might vary on your setup) Alias /static/ /path/to/static/ <Directory /usr/share/python-support/python-django/django/contrib/admin/media> (path might vary on your setup) Order deny,allow Allow from all </Directory> # Direct root to our WSGI script file WSGIScriptAlias / /path/to/file.wsgi <Directory /path/to> Order deny,allow Allow from all </Directory> <Directory /path/to/static> Order deny,allow Allow from all </Directory>
Save the changes to your VirtualHost. I would like to point out here, that for CVGM I chose to comment out completely the same VirtualHost entry for SSL (port 443). My site has no use for SSL, and duplicating this code in the 2nd VirtualHost (which is what would happen if edit the Custom HTTPD for this domain in DirectAdmin) will cause an error for already having being called once.
The WSGI file for your project is created in pretty much the standard way:
import os, sys sys.path.append('/path/to') sys.path.append('/path/to/ExtraPath') os.environ['DJANGO_SETTINGS_MODULE'] = 'ProcessName.settings' import django.core.handlers.wsgi application = django.core.handlers.wsgi.WSGIHandler()
Save it, double check the paths to the files and then restart httpd in DirectAdmin. If all goes well, the site should fire right up! If you start getting 503/500 errors, check the error.log file in the DirectAdmin viewer for a detailed description of what is happening. If there are no errors in the log, it’s not WSGI causing the problem, it’s something else in your code.
Common Error With Mod_WSGI and DirectAdmin
Depending on which version of DirectAdmin you are using, you may run into a massive slap-in-the-face 503 error regarding misconfiguration, and the error log will tell you something like: “No such file or directory: mod_wsgi (pid=7295): Unable to connect to WSGI daemon process”.
If you do run into this problem, you can try one of two things in the virtual host file. Here is a quote directly from Graham Dumpleton on the WSGI homepage explaining the problem and the solution ( http://code.google.com/p/modwsgi/wiki/ConfigurationIssues#Location_Of_UNIX_Sockets ) :
“To resolve the problem, the WSGISocketPrefix directive should be defined to point at an alternate location. The value may be a location relative to the Apache root directory, or an absolute path.
On systems which restrict access to the standard Apache runtime directory, they normally provide an alternate directory for placing sockets and lock files used by Apache modules. This directory is usually called ‘run’ and to make use of this directory the WSGISocketPrefix directive would be set as follows:
Although this may be present, do be aware that some Linux distributions, notably RedHat, also locks down the permissions of this directory as well so not readable to processes running as a non root user. In this situation you will be forced to use the operating system level ‘/var/run’ directory rather than the HTTP specific directory.
Note, do not put the sockets in the system temporary working directory. That is, do not go making the prefix ‘/tmp/wsgi’. The directory should be one that is only writable by ‘root’ user, or if not starting Apache as ‘root’, the user that Apache is started as. ”
So, you would change the top of the VirtualHost to read something along the lines of:
WSGISocketPrefix /var/run/wsgi WSGIDaemonProcess ProcessName threads=25 WSGIProcessGroup ProcessName
After restarting Httpd in DirectAdmin, it should clear up the problem!
This was a post I had originally made a long time ago (November 2009), so I have edited/replaced it here for completeness, as I get a lot email requests about it. I don’t use this setup any longer, and use a dedicated box for CVGM which solved a lot of other issues that I was having at the time, and of course the dedicated box is running a much newer Ubuntu distribution. Thanks!
It has been a long time since I last worked on one of my own game projects, so it is nice to be able to say that I have finally released a new game 🙂 The game is called Twinz! and is based on an game I wrote back on the Commodore Amiga back in 1996 (HOL Link). The original game it was based on was written by Theo Develegas on the ZX Spectrum (WOS LINK) back in 1991, it was a covertape game that I liked to play and back then, I wanted to have a go at doing one myself. If you asked people to load games from cassette tape nowadays, they would have a heart attack! hehe.
The objective of the game is very simple, you turn over 2 tiles at a time to see if the pictures behind them match. If they do, then they stay open and you keep going. If they don’t match, they turn back over. The logic to the game comes from remembering the images behind each tile, so when you find it somewhere else you can turn it over at the right place. Points are awarded for better playing tactics (tiles that are not checked underneath lots of times) and pairs that are found in sequence (one after the other). The game features 5 levels, three difficulties, and an online high score sharing system where you can post your best scores directly from within the game.
Twinz is compatible on any mobile or tablet device. Releases coming for Kindle fire soon, along with iPhone/iPad and other markets. Stay tuned!