wolfSSL on Amiga

As many of you are probably aware, I am one of the developers of wolfSSL. I specialise in porting to various platforms, everything from 16bit microcontrollers to big iron 64bit server processors. I decided to see if I could get wolfSSL running on a 30+ year old platform, specifically “Jops”, the Amiga 4000 I just finished restoring.

Porting

wolfSSL actually already has a 68000 based port, so some of the work is done for me. The most difficult part is generating entropy for the random number generator seeding. The typical ways of doing this are clocks (especially not synced to the CPU) and analogue ports.

At first, I wanted to try using the HSYNC counter as part of this, but unfortunately the Amiga Workbench scheduler syncs application time slices to this, so there is no real entropy here. Instead, I ended up using a combination of the ~7KHz E-clock counter, the counter for how many ticks the mouse has moved, and the analogue input on the joystick port. This is not perfect, but should be good enough for now.

For the developers out there, this is the core part of the code for this:

UBYTE amiga_rng(void)
{
    struct EClockVal clockval;
    UBYTE rng_out;
    UWORD old_pot = potgo;
    potgo = 0x0fff;
 do {
  ReadEClock(&clockval);
 } while (clockval.ev_lo == last_time);
 last_time = clockval.ev_lo;
    rng_out = pot1dat ^ joy0dat ^ clockval.ev_lo;
    potgo = old_pot;
    return rng_out;
}

The potgo register turns on/off parts of the analogue input for the joystick and mouse ports, joy0dat is the counter for the mouse movement.

After this, it was just a matter of creating user_settings.h from wolfSSL’s canned templates and a Makefile. I set the compile settings to a 68030, and it may require a 68881/68882 FPU to work, but these settings are easy to tweak.

When running on a real Amiga, the stack size for the executable needs increasing to at least 16KB. The wolfSSL benchmark compiles into a 400KB executable and will likely need 1MB RAM available to run.

The source code can be found here.

Testing

At first, I tested this in FS-UAE on my laptop, using a configuration very similar to my Amiga 4000. I won’t bore you with the test output passing, but here is the benchmark output.

It is not going to break any records, but I’m actually quite impressed so far, some of the embedded platforms I develop for cannot get these speeds. But, will this translate to real hardware?

Real Amiga

My Amiga 4000 has a 68060 CPU clocked at 50MHz and 388MB RAM. This specification would have been crazy expensive in the early 90s, when this machine was new. It wasn’t cheap to build it as it is today. It has also taken a lot of work to repair all the damage to the motherboard due to failing chips and battery leakage.

The machine was previously owned by Stoo Cambridge, the artist at Sensible Software behind games such as Cannon Fodder. It was used where he worked after Sensible.

Results

I copied the executables to the Amiga and ran the benchmark. This is the output (alongside WhichAmiga’s output).

In general, the performance is about on-par with the emulator to start with. The performance of RSA and ECC was not so great, but this is a 50MHz chip, so I shouldn’t be surprised. Given the 90s hardware constraints I’m very happy with the results.

Future

There are lots of options for the future with this. I may or may not work on them. These could be:

• Make a port of this to replace AmiSSL, it should be lighter-weight and faster. wolfSSL has an OpenSSL compatible API available, so I suspect this shouldn’t be too difficult.
• Try this out on my Amiga 1200 with a PiStorm32-Lite, this is basically like having a 2GHz 680×0 CPU
• The ZZ9000 graphics card has an ARM processor on it, one core is used by the video output, but there is a spare core. There is an API to upload code to it from the Amiga. I could offload wolfSSL onto that core
• Port other things in the wolfSSL suite of libraries and tools

In particular, I want to try to make a wolfSSH port. It will be interesting to see if SSH can be used to communicate with my laptop, and upload/download files. It definitely won’t be as fast as FTP, but it will be a fun project.