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!

Back to the Future with RISC OS

RISC OS is an operating system for ARM based computers, originally developed by Acorn for their Archimedes home computers. Acorn is one of the most well known British computer manufacturers of the 80s, and the famous opponent of Sinclair. The rivalry between the two companies and their leaders has become the main motive of a fascinating BBC drama "Micro Men". A few years after the movie plot takes place, Acorn developed a 32-bit RISC processor, which they called ARM (Acorn RISC Machine). That CPU is a grandfather of the chip we all now have in our mobile devices, like smartphones, smartwatches, and tablets. Acorn also built a series of home computers based on that CPU, called Archimedes. While at the same time popular Amiga 500 and Atari ST home computers, featuring a 16/32-bit mixed Motorola 68000 CPU, could barely exceed one million instructions per second, Acorn Archimedes easily reached 4.5 million, having the same 8MHz clock. Although it was called "the fastest micro in the world", Archimedes' price was several times higher than the price of other microcomputers, so it hasn't gained much popularity and was mainly present in British schools and companies only. Acorn also developed a graphical, multitasking operating system for their computers, which they called RISC OS. When the home computer market has become dominated by Intel based PCs and MACs, RISC OS could only be used by a handful of lucky owners of RISC PCs and Iyonix. Nowadays, thanks to Raspberry Pi, RISC OS is back in the game. RPi is an affordable ARM based computer, and it's hardware specification is more than enough for RISC OS. You can either buy it preinstalled on an SD card or download for free and install yourself.

Why should you know all this? It's because I have seen many people downloading RISC OS and expecting to get a better and faster version of Raspbian, and then becoming frustrated because they didn't even know how to use the system. Remember, RISC OS is older than Linux, it's even older than 16-bit Windows for Workgroups. Because of this, it's not only extremely fast and requires very few resources, but it also has it's own philosophy, which is different from what you may know from other operating systems. For example, applications start minimized on the icon bar (a RISC OS equivalent of taskbar or dock), you open the context menu with the middle mouse button, and save a file by dragging it's icon to the destination folder. The same applies to system commands, for example "dir" changes active directory ("cd" in Linux), and "cat" displays it's contents ("dir" in MS-DOS or "ls" in Linux, "cat" in Linux outputs a file). RISC OS uses "." as a path separator ("\" in Windows, "/" in Linux) and "/" to separate extension from the file name ("." in Windows and Linux). Once you understand that, and are ready to learn, you can start exploring RISC OS. There are some introductory materials about RISC OS you can find on Youtube and on RISC OS dedicated sites, there are also two magazines dedicated to RISC OS users: Archive Magazine (paper) and Drag 'N Drop (PDF).

I have been using RISC OS on Rapberry Pi B+ for a couple of months now and I simply love it.

On one hand, it has all the qualities of a good operating system: it uses very little resources (the OS itself occupies about 10MB RAM), leaving as much memory and CPU time as possible to the user (on the contrary to most modern operating systems, which do exactly the opposite). It also does not stand in your way telling you what you can or cannot do with your computer. If you wish, you can talk directly to hardware from the built-in programming environment, which also serves as a command line. What is it? Basic, of course! And it's one of its best dialects: BBC Basic V with built-in assembler, so you can even control the CPU registers directly from the command line. When I had a C64 I wanted to have a language that is as simple as Basic and as quick as machine code - with RISC OS I can now have both. Moreover, if you need a real-time hardware control, RISC OS will also not complain. Because it uses a cooperative multitasking model, your application can simply not return CPU control back to the OS, effectively changing your computer into a single tasking machine. Of course, this way you can shoot yourself in the foot, but if this is what you want, RISC OS allows you to do it.

On the other hand, RISC OS can be used to do many daily tasks, like programming, writing texts, sending and receiving email, listening to the music (including MP3s and online radio stations) and browsing web sites. Even though Netsurf, a built-in web browser, does not support latest HTML and CSS features and has only rudimentary JavaScript support, it is quite enough if you want to read most of the online articles and news. Even GMail (basic HTML version) is fully functional with Netsurf. There are also absolutely no problems with tasks like networking or reading and writing FAT32 external USB drives in RISC OS.

In the world dominated by bloated and restricting operating systems RISC OS is like a breath of fresh air. Working with it is for me equally pleasant to working with Amiga OS. Unfortunately, latest Amiga OS can only run on hardware which is (like Pegasos) no longer produced, or (like AmigaONE X1000) ridiculously expensive - which is a real shame, because it's a great operating system, with support to most of the classic Amiga software. Fortunately, RISC OS supports not only Raspberry Pi, but also other affordable devices like BeagleBoard or PandaBoard, which makes it a great choice for hobbyists and power users, who want a fast and user friendly system with low hardware requirements. There is also a lot of software written for older versions of RISC OS, which can be run with little or no effort on Raspberry Pi, there are emulators for MS-DOS, Atari and ZX Spectrum, some Linux tools like bash or gnu compiler collection have been ported as well. And if you need a program that cannot be found in online repositories, just hit F12 (type in "Basic" in console) and write it yourself! Learn! Experiment! Computing is all about it after all, isn't it?

Replacing floppy drive in Atari STF(M)

Retrocomputing is not an easy hobby, especially when it comes to fixing original hardware. Sometimes original spare parts are so hard to find that you need to look for replacements. Recently I was looking for a way to replace the internal floppy drive in my Atari 1040 STFM, and the only reasonable option I found was to use a PC drive. The good news is that PC floppy drives are very cheap and easy to find, and virtually all of them can be used, as long as they fit inside the original Atari case. The bad news is that there are a few quirks you need to handle before you make such drive work. Here are two important pieces of advice to help you deal with it without much stress.

First, floppy drives used in PC compatible computers work as logical unit 1, while Atari drives work as logical unit 0. Some older floppy drive models have jumpers that allow you to set logical unit number, but they are very rare and hard to find. However, on the hardware level, the difference between the two modes is the line number that is used to respond to drive select signal from the floppy controller: those lines are connected to pin 10 and 12 of the floppy drive. So to convert a floppy drive from unit 0 to unit 1 you would need to switch those lines either in the floppy drive cable or in the floppy drive itself - but it's a difficult operation if you don't have proper tools and at least some experience in soldering electronics. Fortunately, Atari internal floppy drive controller (as opposed to PC one) is not designed to work with two drives, and it ignores drive select signal. This means you can safely shortcut pins 10 and 12 in the floppy drive and it will not confuse Atari floppy controller at all.
It is easy to find a floopy drive with clearly visible pin connectors. I used Samsung's model SFD-321B, and soldered a small wire to the pins marked with red dots:

Second, Atari STF/STFM/STE can't handle high density (HD) 1.44 MB floppies. As long as you use single density (SD) 360 KB or double density (DD) 720 KB floppies you are fine, but if you put a HD floppy disk in the PC drive connected to Atari, it will start sending information to the floppy controller which Atari will not be able to understand. Again, there is a simple trick to work around this problem. HD floppies are recognized by the drive through an additional square hole in their casing. Because they can be safely formatted and used as DD disks, you can use a piece of black tape to seal this extra hole so that a photocell in the drive would not activate and a high density disk was treated as low density.

Benchmarking C compilers for Commodore Amiga

There are a lot of great programming tools for classic Amiga computers, some of them absolutely unique for this platform, like AMOS or Amiga E. AMOS is a very powerful Basic dialect with a wide set of graphics and sound commands that allow you to create entertainment software, especially games, in no time. Amiga E is an advanced, multi-paradigm programming language, featuring flexible types, powerful module system and very short compilation times.

There is also AREXX, which is Amiga port of REXX programming language popular on IBM mainframes. Every decent Amiga software offers so called "AREXX port", which is a set of commands that can be called from an AREXX script. This is a very powerful tool, which allows you to write a script that, for example, calls a graphics software to make thumbnails for a set of images, than an archiver to put them into a compressed file, and than another program to upload that file to an ftp server. Modern software very rarely allows you to control it with external scripts, and even if it does, you must use some clunky tools like AutoIt, which simulate keystrokes and mouse clicks. Sometimes a program can be called from command line, but than you must learn how to parse its output if you want to know more than just whether the operation failed or not. In AmigaOS, thanks to AREXX, automation is a heck of a lot easier, because there is a single communication standard with clearly defined interfaces for every software written for this platform.

Of course there are also traditional programming languages avaiable, like ubiquitous ANSI C. Doing some research on Amiga programming tools I managed to make a couple of them work. Three of them run natively on classic Amiga: Aztec C 5.0a, Dice C 3.16, and SAS C 6.58. Another two are cross compilers, which run under Linux on PC, but produce native Amiga executables: vbcc 0.9b and m68k-amigaos-gcc, which is a port of gcc 2.95 generating code for Motorola MC68xxx CPU family. There is also a vbcc build for Windows available on Github.
I decided to make a simple benchmark to compare the compilation times, executable sizes and their execution times. Of course you cannot make definite judgement just by one benchmark, but I needed at least a basic reference to start with. At one time a popular benchmark was a sieve of Eratosthenes, so I decided to implement one. I also used AmigaOS timer device to measure execution time of the generated executables. If you are interested in the source code you can get it from here.

Except from cross compiling, I made all tests on Amiga 600 with 2MB Chip RAM, 1MB FastRAM and Workbench 2.0. As a rule of thumb, you should always make tests on real hardware - emulators are not 100% cycle perfect, and they always run on top of a multitasking operating system, which introduces additional interference. I also ran each test 10 times, rejected the highest and the lowest result, and took an average from the remaining ones. I didn't measure compilation time for cross compilers, as they run on PC, and not on Amiga.
All in all, the results are as follows:

Compiler	Compilation time	Executable size	Execution time
Aztec C 5.0a	37 seconds	12032 bytes	3114 miliseconds
gcc 2.95	-	12072 bytes	809 miliseconds
Dice C 3.16	31 seconds	7092 bytes	1332 miliseconds
SAS C 6.58	55 seconds	14612 bytes	1597 miliseconds
vbcc 0.9b	-	12764 bytes	1306 miliseconds

As you can see, for this particular test, Dice C is a clear winner among the native compilers: not only was it the quickest, but also produced the smallest and the fastest executable code. Execution time of the code compiled by Dice C was almost on par with the code produced by vbcc, which ran on incomparably more powerful machine and could perform a lot more optimisations. Not surprisingly, the fastest executable was produced by gcc.

Don't throw your old computer away!

I have had quite a break in posting to my blog, mostly because I spent last year collecting and playing around with vintage computers. As a kid I only had C64 and Amiga 1200 before I got a PC, so I decided to make up for it and buy a couple of machines popular in my country those days. It turned out to be so much fun that I got completely lost in it. I was absolutley amazed how much retrocomputing is alive and how many people are actually actively involved in it.

Let's start with Atari. 8-bit Atari machines were one of the most powerful home computers of the late seventies and early eighties. They featured an incredibely powerful graphics chip, Antic, which allowed fully programmable graphics modes. You could even use more than one screen resolution at a time, a trick that was later only possible on Amiga thanks to the Copper chip. No wonder if you take into account that both Atari and Amiga graphics chipsets were designed by the same man, Jay Miner.
There is a lot of great software written for the 8-bit Atari computers, and new one is still being developed. My favourite game for 8-bit Atari is Yoomp!, created in 2007 by a demoscene group taQuart, and there are also many great tools, like SpartaDOS X, which gives you the power comparable to CP/M or MS-DOS. Once I put SpartaDOS X on a programmable cartridge I never looked back at any other Atari DOS again. SpartaDOS X also works great with new Atari storage devices, like SIO2SD or Side, which use modern flash memory and not only can seamlessly replace your regular Atari disk drive (Side can also work as a hard drive), but also allow you to exchange data with a regular PC easily. Speaking of hardware - today, apart from buying a flash based disk drive for your Atari, you can also upgrade memory (up to 1MB, bank switched), install a graphic card (VideoBoard XE) or even a CPU accelerator (based on 16-bit MOS 65c816, compatible with 8-bit MOS 6502 originally mounted in Atari 400/800/XL/XE).

16-bit Atari computers can also be upgraded. Two most popular upgrades are Satandisk and Ultrasatan, which are flash based hard drives compatible with Atari ST/STE and Falcon. You can also replace original disk drive with HxC and use floppy images saved on regular pendrive as floppy disks. This is a very comfortable solution, because quality floppies are becoming more and more difficult to buy (those produced today are much less reliable than original ones). If you have enough RAM in your Atari, you can even connect to the Internet thanks to NetUSBee device. Additional RAM is required not by the device itself, but by the software. I have Atari STFM with 4MB RAM and I can comfortably use some simple software for FTP or IRC, I even managed to open a few simple web pages with Crystal Web Browser. Unfortunately in most cases I ended up seeing garbage (I use freeware CAB v1.5, which comes form 1996 and does not support any modern web standard) or running out of memory. Still, connecting to the global network from a 16-bit computer, designed before the beginning of the Internet revolution, is an unforgettable experience.

Atari had many comptetiors at the time. One of them was Commodore, run by Jack Tramiel, who later left the company and bought Atari. Commodore machines were very famous in 1980s and 1990s due to two very popular lines of computers: VIC-20/C64 and Amiga. VIC-20 was the first home computer to sell one million units, and C64 is listed in the Guiness World Records as the best selling single computer model in history, with estimated number of around 12.5 million units sold. Unfortunately, I don't have any VIC-20 in my collection, but I have a C64 and I use two hardware extensions with it: Epyx Fastload Reloaded cartridge and SD2IEC flash based disk drive emulator. Epyx has built-in software to accelerate disk operations (up to five times), but if you don't want to buy a cartridge you can use SJLOAD, which is a software only fastloader. From my experience SJLOAD works as well as Epyx, but I just find the cartridge more comfortable to use (plus it has some additional software, like memory monitor, extended DOS commands, etc). As for SD2IEC - it's quite cheap and works with most software, but unfortunately cannot serve as a full replacement for the original disk drive. A real 1541 has it's own MOS 6502 CPU and RAM, which is extensivelly used by some utilities, like fastloaders, and although SD2IEC can emulate some of them, it does not contain a full MOS 6502 emulation and therefore some programs, like GEOS, will not work with SD2IEC. So if you are not tight on budget, I'd recommend buying a device like Ultimate or UK1541, both of which offer full 1541 hardware emulation.

If you are lucky Amiga owner, you can also enjoy a few interesting hardware extensions. You can replace your floppy disk with HxC, or Gotek, which is much cheaper option than HxC. I have Gotek drive emulator working in my Amiga 600 and so far experienced absolutely no problems with it, so in my opinion it's worth buying. If you have Amiga with IDE controller on board (like A600 or A1200), you can buy a very cheap CF to IDE adapter, which allows you to use Compact Flash cards as hard drives, because they have built-in controllers which work with IDE protocol. Amiga also features probably the most powerful (and most expensive) CPU accelerators in the market. Some of them, like FPGA based Vampire 600, can speed up your machine up to one hundred times! If you have Amiga 1200 you can extend it with PowerPC CPU card, 256 MB RAM, dedicated graphics card, install the latest version of Amiga OS (an operating system designed for Amiga computers, still actively developed) and work on it almost like on any other modern computer. It's because Amiga hardware architecture, combined with dedicated software, makes it much less resource hungry than an Intel based PC.

There is also one more computer brand that holds a special place in my heart: Sinclair. Sir Clive Sinclair is often compared to Steve Jobs, not only because of his temper, but also because he was one of the greatest visioners of his era. He was the first one to introduce pocket calculators in 1972 and pocket TV in 1978, he also introduced the first affordable (priced less than 100 GBP, a few times less than the competition) home computer to the British market: ZX80. It featured a 3.5MHz CPU, only 1kB RAM, no high resoultion graphics (only text mode), no sound chip and no disk drive - you could only use a tape recorder as a storage device. It was very little even those days, but ZX80 was extremely cheap and became a huge success. Sir Clive Sinclair supposedly said that at that price, everyone would want a computer, even if they had absolutely no idea what to do with it. Apart from that, Sinclair devices were always designed to look slick and elegant. Even today, white ZX80 looks beautiful, and so do all later black models. ZX80 featured a built-in Basic interpreter and, despite it's horrible keyboard, allowed users to write their own programs, and many future programmers began their careers from it.
ZX80's successor, ZX81, featured a black case and the same hardware capabilities, but due to more compact chip design it was even cheaper. It also fixed a lot of ZX80 problems (especially screen flickering) and became the first European computer to sell over one million units. ZX81 became successful in United States, where it was sold by Timex as TS1000. In fact, a company called Zebra Systems sells ZX81 kits until today. An essential hardware extension for every ZX81 is a memory pack, which adds more RAM to the system. It's true that 1kB may be enough even to play chess, but most software for "Zeddy" requires at least 16kB RAM. You can also use your PC as a tape recorder and make tapeutils load software into ZX81 - just remember to use mono audio lead (regular stereo leads will not work) and set the PC audio output volume to maximum (ZX81 requires a strong input signal). If it's not enough for you, there is a ZXpand interface, which adds 32kB RAM, allows instant software loading from a flash card, and features an AY sound interface.

But the most successful Sinclair computers were ZX Spectrum 48k and it's descendants. It was also the most often cloned computer, especially in communist countries, which were cut off from the world computer markets due to Cocom regulations. As a consequence, most of Sinclair fans beyond Britain are located in Eastern Europe. Russian ZX Spectrum scene is especially strong, and they even developed their own, extended models, most famous of them being Pentagon and Scorpion.
The most problematic hardware part of ZX Spectrum was its keyboard, but you can easily buy a new membrane and replace it yourself, following one of many online tutorials - it requires only a screwdriver, and a bit of patience.
If you have a fully functioning Spectrum you can, just as with ZX81, use a PC as a tape recorder. There are two programs that I would recommend using: OTLA and PlayTZX. The first one recognizes a lot of different tape formats (TAP, TZX) and can work in "turbo mode", which due to a smart audio signal modulation allows loading programs a few times faster. Unfotrunately, some games, especially copy protected, don't load with OTLA. In this case, you can try PlayTZX, or its Windows counterpart, winTZX. PlayTZX is a console only tool, which can work only with files encoded in TZX format (it's less popular format than TAP), while winTZX can work with both TAP and TZX files. On the other hand, TAP and TZX formats are very similar, and there are many tools to convert between those two formats to be found online. To avoid load errors remember to use a mono audio lead and very loud audio output (just as with ZX81). It is also important to use verified TAP and TZX files: I found that many of them available online are somehow broken, and although they work with emulators, they fail to load into real hardware. So far the most reliable source of Sinclair software I know is World Of Spectrum - I never found a single file which would refuse to load with a real computer.
And, of course, just as for all aforementioned computers, there is also a flash based storage device for ZX Spectrum: Divide. Just as ZXpand, it connects directly to the system bus through the expansion port, which allows you not only to use TAP and TZX files, but also emulator snapshots (SNA). It means that you can, for example, freeze a game state in a software Spectrum emulator on PC and load it directly into Speccy.

There are of course dozens of computers from the "good old times" that you can have fun with: Apple, Acorn, Amstrad, even an old PC. If you have such computer - don't throw it away! Instead, try to put a new life in it and give it to someone who can still find it enjoyable - like your kid or a geek friend. If not, just sell it online - there are many people out there who will be happy to have it.