It’s presented in 16 millions colours and is written using Amcog’s very own AMCOG Development Kit – which is also available for purchase.
The game itself involves you, a Cyborg treasure hunter, attempting to penetrate Castle CyberDroid on your quest to thieve ancient treasures from under the noses of hordes of security robots that are teleported into nearby rooms with a view to spoiling your fun.
To make things worse, if you spend longer than 30 seconds in any given room then a holgrammatic energy field aptly named ‘Buzz’ will activate and give you a nasty shock.
The overall aim of the game is to collect all of the treasures on each level before heading to the teleport – and then presumably selling your ill-gotten gains on eBay.
Cyborg comes with 7 level maps consisting of 112 screens and 5 especially made music tracks to go with it. As with all of Amcog’s games, the game’s audio has received a lot work – all sound effects are provided by the RDSP virtual sound chip that generates synthesised sounds in real time.
Since it’s release, a free update has been issued to all Cyborg users with improved graphics and animation, as well as improvements to the sound effects and a few additional levels to play. For more details on what the v2.20 brings to the table, have a read of Amcog’s press release.
As you’d expect from a game influenced on the original Cybertron, the game has a definite retro feel to it – and the music definitely ties in with this. At times I found myself being reminded of a cross between the Botkiller series from Artex Software and Moonquake.
Cyborg incorporates multiple types of enemy robots that come along throughout the various levels to spoil your fun, there’s also several power ups that you stumble across from time to time, these include smart bombs, freeze, local transporters and bonus lives.
The game’s controlled through the standard WSAD keys on the keyboard for moving up, down, left, right etc. The arrow keys can also be used as well as an alternate configuration of z & x for left and right, with @ & ? for up and down. The game’s response to your keyboard input is sharp and responsive, which turns out is pretty key for a game of this nature considering that I spent a good chunk of time dancing out of the way of charging enemies and other nasties.
Playability-wise, the game’s levels are not particularly long in length, but the game’s difficulty definitely makes up for that. There’s a definitive learning curve to begin with, but once you’ve become used to the mechanics of the game and when to time your runs past enemies then the game begins to flow nicely.
The game is a digital purchase via the Pling Store. The process is quite easy, if you haven’t used the Pling Store before, you just need to download the application itself, unzip it and place it wherever you want on your computer. Once run, you’ll need to register or login to the Pling Store, the registration process took me a few minutes when I signed up a few months back and as far as I’m aware all information including card information is kept locally on your computer rather than in a data center somewhere.
The game should play fine on a vast majority of RISC OS machines, be it legacy 26-bit computers or 32-bit machines. It was designed for use on Raspberry Pi and similar modern machines but it should work fine with older systems.
Overall, Cyborg is a solid and well-authored game. It successfully delivers that retro platformer feel Anthony at Amcog has worked to achieve. If you’ve got a tenner ear-marked for procrastionation material then spending it on a copy of Cyborg isn’t a bad shout.
Released back in February 2016, the Raspberry Pi 3 marked the Pi’s fourth year in existence. The latest board from the Raspberry Pi foundation brings in a number of interesting features, including built-in wireless connectivity and a more powerful processor.
A while ago we took a hands-on look at the Raspberry Pi 2, the board’s hardware specs and the way it handles RISC OS. For the most part it passed the test with flying colours. Considering the amount of cash required to purchase it, you get an awful lot of bang for your buck – and it runs RISC OS 5 very well.
So it’s not a surprise that the Pi 3 follows the same path as its predecessor. Let’s take a look at the board, and what you can expect from it if you’re planning on running RISC OS on it.
The board itself
The Pi 3 has quite a powerful processor, powered by a BCM2837 SoC (System on a Chip) and featuring a 64-bit ARM Cortex A53 quad core processor running at 1.2GHz.
There’s no RAM upgrade when compared to the Pi 2, the board is loaded with 1GB of RAM, which is not horrific for most use cases using a Unix/Linux operating system and it’s certainly more than enough if it’s going to be predominantly a RISC OS machine.
An interesting upgrade with this board is the VideoCore IV which handles video and graphics now clocking in at 400MHz compared to earlier models at 250Mhz.
Physically the Raspberry Pi 3 looks very similar to the Pi 2; there’s a new Wi-fi and Bluetooth chip (BCM43438) on the underside of the board and the location of the status LEDs has changed slightly. What’s cool is the antenna used for wireless communications is located on the outer edge of the board, this is so add-on boards shouldn’t interfere with wireless connectivity.
- Architecture: ARMv8 Cortex-A53
- Processor: Broadcom BCM2837 1.2GHz
- RAM: 1GB
- SD Micro: SDUSB4
- Wireless: B/G/N, Bluetooth
Setting up RISC OS
Getting RISC OS 5 up and running on the Pi 3 is exactly the same as you’d do it on its predecessors. Just download RISC OS from ROOL’s website and stick it on an SD card with at least 2GB of space on it.
There’s a very useful guide available here that covers everything you need to do to get your Pi up and running with RISC OS as well as how to use the OS, where to get more software etc.
How it handles RISC OS
Generally, the Pi 3 handles RISC OS very well. The only down-sides I’ve come across are down to compatibility issues between RISC OS and the hardware, this doesn’t cause any huge problems but it just means you don’t get the most out of the board.
One of these issue is RISC OS does not support the Pi 3’s 4 cores, it can only utilise one. Also, there’s no wi-fi support built into RISC OS as it stands so networking has to be hard-wired.
Apart from that, it’ll run whatever 32-bit software you throw at it including 26-bit apps running under Aemulor.
Everything I’ve chucked at it has run flawlessly, I even went to the extent of spinning up a web server using WebJames and then hammering it from a few external computers – not a hitch.
The Raspberry Pi 3 is a great piece of kit, if you already know how RISC OS performs on the Pi 2 (Shameless plug: which you should do if you read this blog!) handled RISC OS then you wouldn’t be surprised to know that I’ve not come across any kind of bottle-neck with the Pi 3.
A question you might have is, is it worth opting for the Pi 3 compared to the Pi 2? If you’re only going to be running RISC OS on it then I’d argue no, I found the experience across both boards to be pretty much identical. If you’re going to be using the board for other operating systems then I’d definitely opt for the Pi 3 purely because of its extra compute capabilities and it’s built-in wi-fi support.
The Raspberry Pi 3 Model B is currently priced around the £32.50 mark depending where you look – Amazon has the best price from the searching I’ve done so far.
Online privacy and net-neutrality are terms that are being thrown about quite a lot nowadays. The security of systems on the Internet and especially the data on them as well as data passed to and from them has never been more important.
Malicious third parties including state sponsored hackers now have more knowledge and resources than ever, so it’s only natural that more and more people are taking steps to secure their online activity and protect their data. Encrypting your traffic and communications is a very good way of doing this, and Tor does this nicely.
What is Tor?
Tor is short for The Onion Router, it is an anonymity network initially developed by the U.S. Navy. It enables users to pass traffic across the internet anonymously. Now, it’s a non-profit organization whose main purpose is the research and development of online privacy tools.
The Tor network disguises your identity by moving your traffic across different Tor servers, and encrypting that traffic so it isn’t traced back to you. Anyone who tries would see traffic coming from random nodes on the Tor network, rather than your computer.
There are several layers that your traffic passes through before leaving the Tor network using an exit-node, the end destination that you route to, say for example your Webmail website, they will only be able to see that you have visited their site from the IP address used by that Tor exit-node, they can’t tell what servers you’ve routed through and they can’t tell where you’ve come from.
It is important to keep in mind that while your traffic is encrypted from your computer to the exit-node where your traffic leaves the Tor network, but your traffic is not encrypted between the exit node and the final destination. So to be doubly sure that your traffic not intercepted to the final destination, then using protocols that utilise encryption such as SSH or HTTPS will achieve this.
How is Tor accessed?
Tor can be accessed through two methods – the Tor browser or the Tor daemon.
The most popular is through the Tor browser, which is an open-source web browser based on Firefox that is pre-configured to route all web traffic through Tor – it also features add-ons such as NoScript that restricts websites from executing scripts unless you specifically allow it to.
There’s no port of the Tor browser available for RISC OS, but the second method of accessing the network is very much accessible as long as you have a second non-RISC OS machine that you can configure as a Tor proxy that your RISC OS machine can route through.
The second option is the Tor daemon, which runs as a background process and opens up a local SOCKS5 proxy that can be used to push traffic onto the Tor network.
Providing you don’t have a firewall specific to the computer running the daemon blocking traffic to systems on your Local Area Network (LAN), any computers on the same local network (i.e. your home network) will also be able to use the computer running the daemon as a SOCKS5 proxy. This normally involves configuring a web browser to use that machine as a proxy or by using a utility like Proxychains (no RISC OS port unfortunately) that allows you to force specific applications through the Tor proxy.
Setting up a Tor proxy
Note: All the Unix/Linux commands below require admin privileges to work. Running these commands as root will work, or if your system has sudo installed and configured then use the sudo command before every command so that your privileges are elevated for that command.
Before you can access the Tor network on RISC OS you’ll need to configure a second non-RISC OS machine as the Tor proxy that you can configure Netsurf to push its traffic through.
1 – Pick a system to setup as a Tor proxy
You can setup a Tor proxy on Windows computers but in most cases people use a Unix-based or Unix-like operating system, they’re ideal for running servers like this and are extremely stable even under high load. I installed my Tor proxy on a Raspberry Pi running FreeBSD but it’ll work just as well on Linux or another BSD variant, including MacOS.
2 – Prepare the target system
Before going anywhere, you must make sure that the system you’re going to configure as a Tor proxy has the correct date and time. If it doesn’t, then your Tor proxy will accept connections but it won’t route them anywhere. It’s also recommended you install NTP to keep the time correct automatically, otherwise it will go out of sync after a while. It’s worth keeping in mind too that if you’re installing NTP, the existing date and time of your machine pre-install must be within 30 minutes of UTC-time otherwise ntpd won’t start.
On FreeBSD I used the command ‘pkg install ntp’ to install NTP onto my system. On Debian/Ubuntu based Linux systems you can use the ‘apt-get install ntp’ command. In my case I then added the line ntpd_enable=”YES” to the /etc/rc.conf config file so that NTP runs on boot, some Unix/Linux systems will configure this automatically.
Finally before installing Tor, configure the system to act as a Gateway. This will allow your system to receive packets and route them on. On FreeBSD I configured this by adding gateway_enable=”YES” to the /etc/rc.conf file. Most Linux systems will allow you to do this by editing the /proc/sys/net/ipv4/ip_forward file to replace the default configuration of 0 (Gateway disabled) to 1 (Enabled).
3 – Install and configure Tor
Now that the system is setup to run as a Tor proxy, you can install the Tor application. On FreeBSD the ‘pkg install tor’ command will take care of this, Debian/Ubuntu based Linux systems should accept ‘apt-get install tor’ in most cases.
Using a text editor such as nano we’ll then configure Tor to act as a proxy. This can be done by editing the /usr/local/etc/tor/torrc file on FreeBSD, or for Linux systems /etc/tor/torrc.
To enable your Tor SOCKS5 proxy to run on the default port of 9050, remove the hashtags from the start of the below lines then save the text file, removing the hashtags will enable the code to run. Make sure to change the 184.108.40.206 IP address to your own local IP address (usually something like 192.168.0.x).
SOCKSPort 9050 # Default: Bind to localhost:9050 for local connections.
SOCKSPort 220.127.116.11:9050 # Bind to this address:port too.
Once you’ve done that you’ll need to configure your system to run Tor on boot. Most Linux systems will do this by default when you install Tor. On FreeBSD I just added tor_enable=”YES” to the /etc/rc.conf config file.
Now that’s done you can start the Tor service by using the service tor start command. You can check to see if your system is listening on the Tor proxy ports you’ve configured in torrc file by running the netstat -a | grep LISTEN command which would show output results like below to show that it’s actively listening for connections on that port.
tcp4 0 0 18.104.22.168.9050 *.* LISTEN
tcp4 0 0 127.0.0.1.9050 *.* LISTEN
The above outputs shows that the system is listening on 22.214.171.124:9050 – which is port 9050 on the local LAN IP for my system, this means it’s accessible by machines other than just itself. The 127.0.0.1:9050 means it’s also listening for port 9050 (Tor SOCKS5) connections on the device itself.
4 – Configure a HTTP proxy
By default, Tor sets itself up as a SOCKS5 proxy. Most non-RISC OS web browsers will allow you to route web traffic through a SOCKS5 proxy but with NetSurf we’ll need to configure our Tor proxy to also serve as a HTTP proxy as it only has a HTTP proxy option.
We can use a piece of web proxy software called Polipo to do this. To install it on most Linux systems, use the ‘apt-get install polipo’ command, or on FreeBSD – ‘pkg install polipo’.
Once that’s done, we then just need to configure it to chain to Tor’s SOCKS proxy, we can do this by modifying Polipo’s config file – FreeBSD: /usr/local/etc/polipo/config or Debian/Ubuntu Linux: /etc/polipo/config.
Amend it so that it shows the below configuration. This will allow your system to act as a Tor HTTP proxy over the default Polipo port 8123.
allowedClients = 127.0.0.1, 192.168.1.0/24
socksParentProxy = “localhost:9050”
socksProxyType = socks5
proxyAddress = “0.0.0.0”
Once done, save the file. We then need to configure the system to run Polipo on boot. Most Linux systems will do this by default when you install Polipo. On FreeBSD I just added polipo_enable=”YES” to the /etc/rc.conf config file. After that’s done, restart Polipo and Tor using the ‘service tor restart’ and ‘service polipo restart’ commands, or just reboot your machine.
Your system should now be accepting SOCKS5 connections over port 9050 & HTTP connections over port 8123.
The above configuration does NOT use any authentication, so do not expose port 9050 and 8123 to the Internet (i.e. past your firewall), this configuration is designed to be used on a local network only. It is possible to setup Tor to require authentication before the proxy can be used, this will need to be setup if you want to access this proxy from outside of your local network.
Configure NetSurf to use the HTTP proxy
Now that there’s a Tor proxy running on your local network, it’s now time to boot up Netsurf on your RISC OS machine and point it to pass its traffic through the proxy and in-turn, the Tor network.
So once NetSurf is running, middle-click on its iconbar icon then select Choices then Connection.
Set the Proxy type as Simple proxy, then stick in the local IP address of your Tor proxy system in the Host field, followed by the port number of your HTTP proxy in the field to its right.
If you’ve followed this guide to the letter then the HTTP proxy will be running on port 8123, it is possible to set the proxy to run on the same port as the SOCKS5 proxy (9050) like in the image on this article.
Have a play around!
That’s it, NetSurf is now configured to push its traffic through the Tor proxy. You can test this out by checking your IP address with a website such as DuckDuckGo or ping.eu. This will show the IP address that other systems and websites you interact with through your Tor proxy will see you as. If you attempt to visit the IP address that DuckDuckGo or Ping.eu has shown to be the IP you’ve visited from, it should show you a ‘This is a Tor Exit Router’ page.
All your NetSurf traffic will now be pushed through various Tor proxies and anonymised. You can also access dark web (.onion) sites now also.
For more information on Tor, have a read of the Tor project’s extensive Documentation section. If you’re really curious then take a look dark web websites, these are websites that are hosted within the Tor network and can only be routed to from within the Tor network. These sites usually have .onion domain names.
Be wary though, while there’s an awful lot of good stuff on Tor and the dark web, there’s also a lot of bad stuff – so exercise caution when taking a look around.