NetUSBee configuration for Atari ST

NetUSBee is a network card for 16-bit Atari computers, which is compatible with modern ethernet devices. To make it work under plain TOS you need Sting drivers; you can find those drivers, as well as the installation manual, here.
Unfortunately, the manual covers only peer to peer connection, and it's not enough when you want to connect your computer to the Internet. Two importand pieces missing are gateway and DNS configuration.

Gateway, as the name suggests, is a network device which passes traffic from your host to the Internet, and vice versa. If you configure an Atari and a PC as specified in the manual, the Atari will have an IP address 192.168.255.1, and the PC's IP address will be 192.168.255.2. If you enable Internet connection sharing in the PC, it will become a gateway for the Atari, and the Sting drivers must be properly configured for it.
To do this, run a text editor (I strongly recommend Everest for this purpose), open file C:\STING\ROUTE.TAB and scroll to the end. You will see the following lines:

192.168.255.2   255.255.255.0   EtherNet        192.168.255.1
0.0.0.0         0.0.0.0         Modem 1         0.0.0.0

This is so called routing table; it tells the host which gateway it should use when communicating with a specific network. Because the entries above make no sense for NetUSBee configuration described in the manual, you should remove them. Instead, replace them with the following entry:

0.0.0.0 0.0.0.0 EtherNet 192.168.255.2

This defines so called "default gateway". What it says is that for any IP address ("0.0.0.0" means "any") in any subnetwork (again: "0.0.0.0") the traffic should be passed through the computer connected to the ethernet interface, with IP address "192.168.255.2" (it's the PC's address).
Now very important note: you should use tabs to separate the column entries, so the line would be typed in like this:

0.0.0.0<TAB>0.0.0.0<TAB>EtherNet<TAB>192.168.255.2

If you use spaces, it will not work, and some editors silently replace tabs with spaces - this is why I recommend Everest (but QED will work as well).

Second thing you need to set up is a Domain Name Server configuration. DNS is a service used to translate human readable names into IP addresses - when you type in "blogspot.com" in your browser, it will contact a DNS server first, to ask what IP number hides behind it.
To configure DNS in Sting, open C:\STING\DEFAULT.CFG in text editor, find the line which says:

NAMESERVER  =

and enter your Internet provider's DNS addresses. If you don't know what they are, you can use Google's:

NAMESERVER  = 8.8.8.8, 8.8.4.4

Save modified DEFAULT.TAB and ROUTER.TAB files and restart the computer. If you configured Internet Connection Sharing properly in the PC, you will be able to use various Internet applications on your Atari.

Protecting privacy with personal VPN

There are more and more examples of privacy violation in the Internet. Even in supposedly democratic countries, the governments want to know what the citizens are up to, "just in case". For example, in my country the police have recently been given the power to eavesdrop phone calls and intercept any forms of electronic transmission, without prior permission from the court.

Thinking that you have nothing to worry about if you do nothing wrong is naive. Any information gathered about you can be sooner or later used against you. It can also leak, be stolen, or even sold by a corrupted police officer. Remember, that your home network consists of many devices, not only your personal computer (or computers). Your phones, tablets, TV boxes, and sometimes even your refrigerator as well as other home appliances, constantly transmit various data over the network. Many of them use RESTful APIs over unsecured HTTP channels, because it's simpler and helps keeping the costs low. But this is only part of the problem. Even if you make sure you use only encrypted HTTPS protocol, your software still needs to perform unencrypted DNS queries to translate domain names to IP addresses. This way anyone eavesdropping your network traffic can gather information about the sites you visted, how often and for how long. This so called "metadata" can reveal much more information about you than the actual content you view with your Internet browser. Metadata can tell a lot about your interests, habits, in which banks you keep your money (because you visit their sites often), what you buy and where you do your shopping, even where you plan to spend next weekend (because you just checked weather forecast for this place with your mobile phone). It can even be used to check if you are at home and whether it can be safely robbed. You can be profiled quickly and without much effort, just by intercepting transmission from you home router. Moreover, your traffic can be redirected (through DNS spoofing) to false web servers, to make you reveal some sensitive data, like logins and passwords. Also, your devices automatically synchronizing time over the Internet can be tricked into using a particular timestamp. The timestamp is a crucial element of digital cryptography: controlling the clock of your computer will make it generate predictable cryptographic keys, which then can be easily broken.

So, how can you protect yourself? My solution was to built a personal Virtual Private Network. I have a VPN server hosted in the cloud, and a home router configured as VPN client, passing all my Internet traffic through that server over an encrypted "tunnel". Of course it makes my Internet connection a little slower, because every data packet, including metadata queries (like DNS and NTP), must be encrypted and transferred to the cloud, where it "jumps out" and begins its regular way through the network, but this way my network traffic cannot be eavesdropped. The server is hosted in another country, so the government can no longer watch me "just in case", because they need a court permission to claim my data from a foreign cloud provider.

How is this better than TOR, or any other peer-to-peer network? - you may ask. With TOR, the idea is that your data travels around the world through other people's computers, but also other people's data travels through yours, and you have no control over it. Frankly speaking, I don't feel comfortable knowing that my computer can be indirectly used by criminal offenders for their illegal activities.

I used tinc to build the VPN. It's fairly easy to configure and available for many operating systems. I used Ubuntu for the server, and OpenWRT router for the client, but you can use a different configuration (for example an old PC with Linux as a router).

1. Server configuration.

First, you need to set up a server. Tinc has very minimal hardware requirements (a few megabytes of disk space and memory), and I use it successfully with Ubuntu 14.04 installed on a virtual server with 512MB RAM. First, you need to be root to perform all necessary tasks. Swith to user root with:

sudo bash

Then install the tinc package:

apt-get install tinc

Next, create a proper directory tree and configuration files using the following commands:

mkdir -p /etc/tinc/vpn/hosts
echo 'vpn' > /etc/tinc/nets.boot
echo 'ifconfig $INTERFACE 10.8.0.1 netmask 255.255.255.0' > /etc/tinc/vpn/tinc-up
chmod +x /etc/tinc/vpn/tinc-up
echo 'ifconfig $INTERFACE down' > /etc/tinc/vpn/tinc-down
chmod +x /etc/tinc/vpn/tinc-down
echo 'Name=server' > /etc/tinc/vpn/tinc.conf
echo -e 'Subnet=10.8.0.0/24\nMode=switch' > /etc/tinc/vpn/hosts/server

This makes the basic scaffolding of your VPN server configuration. Now you must add the server's public IP address to the /etc/tinc/vpn/hosts/server configuration file (replace "xxx.xxx.xxx.xxx" with the public IP address of the server):

echo 'Address=xxx.xxx.xxx.xxx' >> /etc/tinc/vpn/hosts/server

Notice ">>" instead of ">" when using this command!
The file /etc/tinc/vpn/hosts/server should now have the following content:

Subnet=10.8.0.0/24
Mode=switch
Address=xxx.xxx.xxx.xxx

Where, again, "Address=" field contains the public IP address of your server.
Now you need to generate an encryption key used to protected data transmission over the VPN tunnel:

tincd -n vpn -K

Confirm the defaults pressing Enter. After this operation you will see a new file /etc/tinc/vpn/rsa_key.priv containing the private key, and a new section in /etc/tinc/vpn/hosts/server file containing the public key. As their names state, the public key can be visible to anyone, and the private key must remain secret and cannot be revealed.

You can now start tinc server (as user root) with:

tinc -n vpn

Now you should be able to list the new network interface with:

ifconfig vpn

And it sould have a section saying "inet addr:10.8.0.1". You can turn it off for now with:

tincd -n vpn -k

Notice lower case "-k", not uppercase "-K", which was used to generate the key.

2. Client configuration.

Now for the router (client) configuration, you also need to install tinc package. With OpenWRT you can do it either through the web interface or via the command line with the following command:

opkg update && opkg install tinc

With Ubuntu as the client the procedure is the same as with the server:

sudo apt-get install tinc

Now you need to configure the client. On the router (or the computer acting as a router) switch to user root with:

sudo bash

Then run the following set of commands:

mkdir -p /etc/tinc/vpn/hosts
echo 'vpn' > /etc/tinc/nets.boot
echo 'ifconfig $INTERFACE 10.8.0.2 netmask 255.255.255.0' > /etc/tinc/vpn/tinc-up
chmod +x /etc/tinc/vpn/tinc-up
echo 'ifconfig $INTERFACE down' > /etc/tinc/vpn/tinc-down
chmod +x /etc/tinc/vpn/tinc-down
echo -e 'Name=client\nConnectTo=server' > /etc/tinc/vpn/tinc.conf
echo -e 'Subnet=10.8.0.0/24\nMode=switch' > /etc/tinc/vpn/hosts/client
tincd -n vpn -K

You are almost done. Your router is now the client of the VPN network, and you need to make sure that the server and the client know about each other, so they can communicate. To achieve this, you need to copy /etc/tinc/vpn/hosts/server file to the client, and /etc/tinc/vpn/hosts/client to the server, so that the contents of the /etc/tinc/vpn/hosts directory is the same on both hosts and contains both client and server files.
Now start tinc both on the client and the server (again, as user root) with:

tincd -n vpn

After a short while the connection should be established and you should be able to ping the server (10.8.0.1) from the client (10.8.0.2) and vice versa. If something goes wrong, you can start tinc with debugger to see what's going on:

tincd -n vpn -d -D

The messages are elaborate enough to allow you quickly locate the source of the problem.

3. Routing setup.

You are almost done here. The client and the server can see each other, but you want to pass all your traffic through this connection, right? So there are two more things to be done.

First, you need to configure the server to forward the traffic between the VPN and the outside world:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE

The above commands should be run every time you start the server, so you can add them to /etc.rc.local startup script (along with the command to start tinc).

Second, on the client side, you need to modify the routing table to make the VPN server a default gateway for all the internet traffic passing through the client (i.e. your router), except the VPN server itself. So, check the routing table on your VPN client with:

route -n

You should see something similar to this:

Destination  Gateway   Genmask       Flags Metric Iface
192.168.1.0  0.0.0.0   255.255.255.0 U     0      br-lan
5.10.64.0    0.0.0.0   255.255.192.0 U     0      eth0.1
0.0.0.0      5.10.64.1 0.0.0.0       UG    0      eth0.1

Look at the Gateway column in the line where the Destination says 0.0.0.0 (meaning: any address) - it's the default gateway. In this case it's 5.10.64.1 and it's the address of you nearest outside world neighbour, probably your Internet provider's modem or router. You need to make sure that you leave this route open for the connection between your client and your server to work.
Do the following magic commands (replacing 5.10.64.1 with your own default gateway, and xxx.xxx.xxx.xxx with the public IP of your VPN server):

route add xxx.xxx.xxx.xxx gw 5.10.64.1
route del default gw 5.10.64.1
route add default gw 10.8.0.1

What happens here is that you leave the traffic to your VPN server via the old route, and replace the gateway for all other traffic with the encrypted VPN. If you did it properly, you should now be able to ping any Internet address from your client. Also, the traceroute (or any other similar utility) should show your traffic going first through the tunnel:

root@OpenWrt:~# traceroute google.com
traceroute to google.com (173.194.204.113), 30 hops max, 38 byte packets
 1  10.8.0.1 (10.8.0.1)  107.456 ms  106.969 ms  114.178 ms
 2  ...

If you don't want to modify the routing table by hand every time you start the router, you can add the commands to /etc/tinc/vpn/tinc-up script. Don't add them to /etc/rc.local, because that script is executed early on startup, when 10.8.0.1 address may not yet be available, and the commands will fail.

Now the last step. You need to allow traffic between your local network and the VPN, similar to what you did on the server side. Assuming your router's (the VPN client's) LAN address is 192.168.1.1 (it's a common default for most routers), you need to run the following commands:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE

You can safely add them to /etc/rc.local startup sequence.

Now connect to your router and go to any address from https://www.google.pl/search?q=what+is+my+ip. You should see the public IP of your VPN server, not your home router. It indicates that all your Internet traffic now goes through the VPN.

And finally, one more thing. If you haven't done it yet, change the primary DNS server on your router to 8.8.8.8 and secondary to 8.8.4.4 (they are Google DNS servers). Otherwise all your DNS queries will go through the VPN server back to your Internet provider, and you don't want that to happen, do you?

Using Raspberry Pi with operating system installed on pendrive

You cannot boot current versions of Raspberry Pi from mediums other than an SD card, which means that for some space consuming operating systems, like Raspbian, you need at least a 4GB or 8GB card. But it doesn't mean that if you have a 1GB or 2GB SD you cannot use a larger system on Pi. You just need a memory stick with sufficiently high capacity.

The trick is simple. Write the operating system image on a pendrive instead of an SD card. Format the card just like you do for everyday use with a camera or smartphone, i.e. just create a single partition with regular FAT file system on it. Now mount the memory stick and you will notice that the first partition is also a FAT parition with a couple of different files - they are required to boot the operating system. Copy all files and folders from the stick to the card. Now edit cmdline.txt file located on the SD card (this is important, remove the pendrive before editing to make sure you modify the right file). The file contents will be similar to this:

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1
elevator=deadline root=/dev/mmcblk0p2 rootfstype=ext4 fsck.repair=yes rootwait

It's the arguments passed to the kernel on boot up. The root parameter tells the kernel where the main file system is located. Change it from root=/dev/mmcblk0p2 to root=/dev/sda2 and save the file on card. Connect the card and the pendrive to the Pi and turn on the power. It will load the kernel from the card, but will mount as root folder the second partition of the memory stick, containing the actual operating system (and recognized by Linux on boot up as /dev/sda2).

I used this trick to run Minibian, having a few memory sticks and just one small 128MB SD card at my disposal. If the Pi doesn't boot from /dev/sda2 make sure you don't have any other usb storages connected, otherwise try a different device instead of /dev/sda2, like /dev/sdb2, /dev/sdc2, etc.

Authenticating apps with Google using OAuth 2.0

OAuth 2.0 is an open standard protocol for authentication and authorization, which is used by Google to provide users and applications with access to its APIs. If you own a Google account you have probably noticed that you can grant and revoke access to your account for desktop and mobile applications. To grant access, you have to log in to your account from within the application and confirm that it can access some (or all) of your data. To revoke access, you can go to your account's settings, select "Connected apps and sites" and remove the application from the list.

But sometimes things become complicated. Calendar-Indicator is an application for Ubuntu written in Python, which integrates nicely with Unity and allows you to access Google calendar directly from your desktop. It also provides you with very nice OSD notifications, so you don't need any extra software (like Evolution or Thunderird) to remind you about incoming events. Unfortunately, being a fantastic application, it has some issues when it comes to authenticating with corporate Google accounts using additional authentication mechanisms, like Active Directory. It's because such mechanisms can use some extra redirections and pop-up windows, which are not handled well by the application's built-in HTML login widget.

To work around this problem, you can authenticate Calendar-Indicator using Google OAuth2 API directly. In order to do this, you need to know the Client Id and Client Secret, which can be considered as application's username and password. When you look into the source code you will find them in share/calendar-indicator/googlecalendarapi.py file:

CLIENT_ID='906536899599-93lne5t3cb0keptl8fh0o8ghpmt447ls.apps.googleusercontent.com'
CLIENT_SECRET='x_QgZkRfUJ_08lWvCw4EIK3U'

They are written in plain text, but it doesn't matter. OAuth protocol is designed in such a way, that learning application's credentials only cannot be used to compromise it.
Having obtained the credentials, you need to use them to ask Google for a permission to access your calendar. To do this, open a web browser and paste the following url into the address bar (the whole text below is one line):

https://accounts.google.com/o/oauth2/auth?response_type=code&access_type=offline
&client_id=906536899599-93lne5t3cb0keptl8fh0o8ghpmt447ls.apps.googleusercontent.com
&redirect_uri=urn:ietf:wg:oauth:2.0:oob&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar

You will be asked to log in to your account and then to grant permission to your calendar. When you agree, you will receive a one-time code, which you need to use to confirm that the application received the permission. The code is placed inside a small input field and is usually a little bit longer than it's size, so make sure you don't miss any characters when copying it into the clipboard.
Now open a terminal window and enter the following command, replacing the string CODE_RECEIVED_FROM_GOOGLE with the actual code (again, the whole text below is one line):

curl -X POST -d "code=CODE_RECEIVED_FROM_GOOGLE
&client_id=906536899599-93lne5t3cb0keptl8fh0o8ghpmt447ls.apps.googleusercontent.com
&client_secret=x_QgZkRfUJ_08lWvCw4EIK3U&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&grant_type=authorization_code" https://accounts.google.com/o/oauth2/token > ~/.config/calendar-indicator/token

When you open ~/.config/calendar-indicator/token file you will notice that it's a JSON object. There are two fields that are important from the application's point of view: access_token and refresh_token. The access_token, combined with Client Id and Client Secret, identifies the application and is valid only for one session only. The refresh_token, also combined with Client Id and Client Secret is used to receive new access_token every time application is run. This way, even when an attacker breaks current access_token, he or she will not be able to create a new application session and compromise the application as a whole.

As you can see, with just two simple steps your application is now securely authorized. When you revoke access to the application or delete the token configuration, you can use aforementioned procedure again to regain access to your calendar.

Modern micro with RISC OS Pico

RISC OS Pico is a stripped down distribution of RISC OS which turns Raspberry Pi into a modern micro computer. It was created by RISC OS Open Limited to celebrate 50 years of Basic programming language. Imagine a classic BBC Micro manufactured today: the same black and white text console, the same fun and easy to learn programming language, but much cheaper, with much faster CPU and more RAM, with super fast flash storage, capable to fit into your pocket. This is what Raspberry Pi with RISC OS Pico is.

Pico boots within a few seconds, straight into console Basic interpreter, just like all classic and modern micros. Yes, you heard it right. Micro computers didn't die with the demise of Atari XL/XE, BBC, C64 and Spectrum. There are many modern incarnations, like Micromite Companion, Fignition (using Forth instead of Basic, just like renowned Jupiter ACE), Grant Searle's Multicomp and other homebrew projects. RISC OS Pico has additional advantage, though. Because its shell is BBC Basic VI, it is natively capable of running programs written in BBC Basic. When I was a child I found it very exciting to type in a program printed in a computer magazine and watch it run. Now you can do the same with your kids to teach them programming. You can google around for some ready to use BBC Basic listings or check out the online book and create something yourself. Basic is very easy to learn and great for understanding how the computer works. It lacks many concepts found in other high level languages, like objects, interfaces, first class functions and other stuff, but they have been created for professional programmers, and they don't show you the way the computers really work. For the CPU any program is just a list of instructions (keywords in Basic) located at subsequent memory addresses (line numbers), and the program counter goes over that list one by one, changes the flow when a condition is met (IF...THEN...ENDIF), repeats some instructions in a loop (REPEAT, WHILE) jumps into a subroutine located at different address (GOSUB line-number), then returns from it (RETURN), or jumps to some other place in a program (GOTO line-number). Even threads, when run on a single CPU core, are executed sequentially, it's just very fast switching between them which creates an illusion of parallel processing. This is why people who can program in Basic are able to learn assembly language much quicker than those who come from other languages. Don't be afraid of Basic teaching you "bad habits". Languages are not good or bad, it's programmers that are.

To start using RISC OS Pico you need a distribution which is suitable for your version of Raspberry Pi. If you have model A or B you can use an official ROOL version, otherwise you should download an alternative version, which has been upgraded to work with Raspberry Pi B+ and Raspberry Pi 2. The file is just 4MB and the only thing you need to do is to unpack it to a blank, FAT formatted SD card. You can also buy a ready to use SD card.

When you put the RISC OS Pico on the card and turn the power on, you should see the following prompt on your screen:

RISC OS 192MB
ARM1176JZF-8 Processor
Piccolo Systems SDFS
ARM BBC BASIC VI (C) Acorn 1989
Starting with 97040636 bytes free
>_

The memory size and processor type can be different, depending on the Raspberry Pi model used with Pico. If you see nothing but a blank screen, add the following line to CONFIG.TXT:

hdmi_safe=1

It should solve the video output problem.

Your new BBC Micro is now ready to use, but if you don't have a UK keyboard, you may notice that some keys are mapped differently. To fix his just type in:

*keyboard usa

and press Enter. If you don't use a standard QWERTY layout, replace "usa" with proper country name ("france", "germany", etc). Notice that the aforementioned keyword starts with "*". It's so called "star command", and it's an operating system command called inside Basic - just like DOS command in Atari or Commodore Basics. There are more commands you can use, for example "*cat" lists the contents of a directory, and "*quit" quits from Basic (to go back just type in "basic" and press Enter). Star commands are written in lowercase, unlike Basic keywords, which must be uppercase. You can find star commands reference here.

To load a program from the SD card use the Basic keyword LOAD, for example to load SimonSays program located in Examples folder use the following:

LOAD "Examples.SimonSays"

To list a program use LIST. Press Scroll Lock key during listing to pause screen scrolling, or use "LIST 10,50" to show only lines from 10 to 50.

When you type your own program you can number the lines yourself or use AUTO keyword to let Basic do it for you. To turn off this feature just press Esc. It's a good practice to leave a bit of space between subsequent line numbers (use 10,20,30 instead of 1,2,3) in case you need to put some code between existing lines. But don't worry if you get lost in numbering - just use RENUMBER.

To replace a program line with new code just enter it using the same line number, and to delete it use only the number with no instructions to follow, for example to remove line 10:

10 PRINT "Hello"

type in:

10

and press Enter. Editing lines is also very easy. List the program, press up arrow and find the line you want to modify on the screen, than keep pressing End key. The contents of the line gets copied to the prompt, so you can edit it and then confirm changes with Enter.

When your program is ready you can SAVE it with:

SAVE "filename"

and then execute it with RUN. You can break it at any moment with Esc key. If by any chance the program stops responding, you can restart the Pico pressing CTRL and Break keys simultaneously.

Programs written in BBC Basic are very fast. Even when 8-bit computers dominated the world, BBC Basic was considered the fastest and most mature. I wondered if it's still true, so I created an implementation of the sieve of Eratosthenes in Basic (available here) and Python (available here) using exactly the same algorithm, and ran them both on my Raspberry Pi B+. The results are as follows:

Interpreter	Operating system	Execution time
BBC Basic VI	RISC OS Pico	7.84 seconds
BBC Basic VI	RISC OS 5.21	4.59 seconds
Python 2.7.2	RISC OS 5.21	25.68 seconds
Python 2.7.9	Raspbian Jessie	17 seconds

To try the BBC Basic version with RISC OS Pico, just put the file "sieve" in the root folder of the Pico SD card, fire up the Pi and do:

LOAD "sieve"
RUN

Playing classic games with !ADFFS

!ADFFS is a software written by Jonathan Abbott, which allows booting floppy disk images inside RISC OS desktop. Thanks to his fantastic work you can play many classic games released for Acorn Archimedes on modern RISC OS machines, including Raspberry Pi.

The latest version available for Raspberry Pi at the moment is 2.50 beta, which can be downloaded from The Archimedes Software Preservation Project forum. Open !NetSurf, go to http://forums.jaspp.org.uk:9000/forum/viewtopic.php?f=9&t=228 and click on the post attachment (adffs250b.zip). A popup window "NetSurf Download" with a progress bar will appear. When download finishes click on the file icon (green square labeled "Data") and drag it to the SD card icon located on the iconbar. Double click the SD card icon to open the root folder of the card. You should see a green icon labelled "file" - it's the file you just downloaded. It's a zip archive containing !ADFFS, but the system does not recognize it, yet. Click with the middle mouse button on the file and select "File->Set type". The default value is "Data", change it to "Zip" and press Enter. The icon should turn blue with a big letter "Z" on it, which means that RISC OS now properly recognizes the file as a zip archive. Double click on it with the left mouse button to open the archive contents. You should see an icon labeled !ADFFS. Drag it to the folder you want to have it - I keep it in "Utilities" - and the installation is complete!

Now you need some games to play. I will use one of my favourite ones, Gods, as an example. First, download the full game archive from http://forums.jaspp.org.uk:9000/forum/viewtopic.php?f=25&t=107 just as you downloaded !ADFFS. Open the archive, go into Discs folder and drag the disc image files to a separate folder ($.Apps.Games.Gods for example). Again, you have to make the files recognized by the operating system by setting appropriate file type. Click middle mouse button on each file, select "File->Set type" and change "Data" to "Floppy". Observe the icons, they should change to !ADFFS-like.
When a game consists of only one floppy image, you can finish here.

With multi-disc games, you also need to change the image file names. It's because !ADFFS emulates a single drive and if you want to swap floppies their order is recognized by the suffix of the file name, so "Gods 1" becomes floppy number one, "Gods 2" becomes floppy number two, etc. To change the image name to conform to !ADFFS requirements click on the file with the middle mouse button, select "File->Rename", enter new file name and press Enter.

Finally, you can play the game! First, open the SD card, enter Utilities and run !SparkFS (if you opened any zip archive before it should already be running in the iconbar). !SparkFS comes preinstalled with RISC OS on Raspberry Pi, but if for some reason you don't have it, you can download a free read-only version (it's enough for !ADFFS) from RISC OS Open website.
Now run !ADFFS itself - it's icon appears on the iconbar. Drag "Gods 1" onto ADFFS icon on the iconbar to put the floppy image into the virtual disk drive. Click with the middle mouse button on the ADFFS icon on the iconbar and choose "Boot floppy". When asked about "Boot floppy via a simulated Shift-Break?" answear "Yes", and voila - the game starts. After playing the intro you will be asked to insert disc 2, which you can do by pressing CTRL-SHIFT-F2 (disc one is CTRL-SHIFT-F1, disc three is CTRL-SHIFT-F3, etc). To quit the game press CTRL-SHIFT-F12.

Tip: Want to play once more? Just click on ADFFS, select "Boot floppy"... why the game won't start? Yes, you put disc 2 in the drive during the game! Drag "Gods 1" over ADFFS and try booting again. Enjoy!

Using Raspberry Pi with a VGA monitor

One of the most fantastic Raspberry Pi features is its ability to fit in a pocket. Whether you travel far away from home or just go for a short visit you can always have your whole workplace with you. You don't have to copy all the files to a pendrive and then look for a computer to work on, wondering if you bring back home a virus or find your secret files "backed up" on some peer-to-peer network. You don't have to carry a big case with heavy latop inside, either. All you need is to take your Pi out of your pocket and connect a mouse, a keyboard, and a TV.
But what if there is only one TV set, and suddenly everybody wants to watch TV or play the latest hit on a game console? Yes, you can use a good old (S)VGA monitor! It can be an interesting alternative to a big TV. A flat LCD monitor takes little space on desk and can be a useful way to recycle some old electronic stuff, instead of just throwing it away. You can make the world a better place by reusing an old monitor with Raspberry Pi!
I will show you how to connect Raspberry Pi running RISC OS to a regular computer monitor with VGA input, but most of the tips below should be useful for Linux users as well.

Although Raspberry Pi does not feature a VGA output, there are many adapters available, which can convert digital HDMI data stream into analogue signal required by a VGA monitor. However, you have to pay attention to two very important things.
First, it has to be an adapter with a special DAC (Digital to Analogue Converter) chip. Some adapters just pass the signal through, and they can only work with PCs or laptops which can transfer an analogue signal through HDMI port. Raspberry Pi is not designed to support such feature.
Second, search for an adapter with audio output (the most popular is mini-jack port). It's because the Pi settings required to make it work with a VGA display can make the built-in mini-jack audio output port inactive. It is possible to have video signal passed through the adapter, and sound through a built-in audio jack, but it can be very tricky and the settings described below don't work for everybody. Moreover, if an adapter has an analogue audio output, it indicates that it has some kind of a DAC chip onboard, and is not a simple pass-through.
Hint: adapters advertised to work with a smartphone (or tablet) in most cases also work with the Pi. Anyway, before you buy such adapter, read it's description carefully or, if in doubt, ask the seller whether it was tested with Raspberry Pi. If you are still unsure, you can buy PiView, which is guaranteed to work with all Raspberry Pi models, but it costs almost as much as the Pi itself. Personally, I use an adapter I bought quite cheap on eBay and it works very well.

Now for the software part. The Pi can now speak to the monitor through the adapter, but the monitor will not send back the information the Pi expects to receive, so we need add some information to the Pi's default GPU (Graphics Processing Unit) configuration. This configuration is stored on a boot partition of the RISC OS SD card in a file called CONFIG.TXT. To edit this file on a PC, simply put the card into a reader and after it mounts open CONFIG.TXT from the mounted partition in the editor of your choice. To edit it from RISC OS, open !StrongED, click on the SD card icon on the iconbar, then hold down Shift and double click on !Boot icon, then Loader and drag CONFIG/TXT to !StrongED icon on the iconbar. The reason I recommend !StrongED over !Edit is that the former one can handle PC end-of-line codes better (!Edit displays [0d] at the end of each line).
The contents of the config file for RISC OS should look more or less like this:

fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG

This is a basic configuration needed to boot RISC OS on Raspberry Pi. It will look a bit different for Raspbian and other Linux distributions, but it doesn't matter now. The parameters are written in "key=value" form, each in separate line. You can find a detailed description of the configuration parameters at Embedded Linux Wiki.
What you should do is to add the following lines to the configuration file. You can place them right after the last parameter, before the first one, or somewhere in the middle:

hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=17

Those lines require some explanation. The "hdmi_force_hotplug=1" tells the Pi to use to use HDMI output even if no connection with an HDMI with display was detected. As I mentioned before, a VGA monitor can't communicate with Raspberry Pi through HDMI, it can only display a picture received via the adapter. Next option "hdmi_group=2" selects DMT (Display Monitor Timig) output mode, which is a VESA (Video Electronics Standard Association) standard for VGA monitors, and "hdmi_mode=17" sets screen resolution to 1024x768 with 70Hz refresh rate. You should tweak that parameter depending on your monitor display capabilities, using information found at RPiconfig in DMT video modes table.

Now for the sound. If you have a VGA adapter with audio output and want to use it, you should add the following lines to your configuration:

hdmi_drive=2
hdmi_force_eid_audio=1

The "hdmi_drive=2" option selects HDMI mode with sound (value "1" means "no sound") and "hdmi_force_eid_audio" makes the Pi skip detection of the display's audio capabilities. Without this option you may get some strange sound problems, like no audio signal after first boot, suddenly reappearing after reboot.

If you want to use the Pi's built-in audio jack instead (you can't have both outputs active at the same time!), you should add these lines in place of the previous two:

hdmi_ignore_edid_audio=1
audio_pwm_mode=2

The first option tells the Pi that there is no digital audio device connected and forces it to use the analogue output, and "audio_pwm_mode=2" reduces some nasty hissing you can sometimes get (if you have very quiet sound output you may try try to remove this parameter from the config file).

And that's it, enjoy your new Raspberry Pi display!