Using Smart Mobile Studio under Linux

Every now and then when I post something about Smart Mobile Studio, an individual or two wants to inform me how they cannot use Smart because it’s not available for Linux. While more rare, the same experience happens now and then with OS X.

The Smart desktop demo running in Firefox on Ubuntu, with Quake 3 at 60 fps

While the request for Linux or OS X support is both valid and understandable (and something we take seriously), more often than not these questions can be a pre-cursor to a larger picture; one that touches on open-source, pricing and personal philosophical points of view; often with remarks on pricing.

Truth be told, the price we ask for Smart Mobile Studio is close to symbolic. Especially if you take the time to look at the body of work Smart delivers. We are talking hundreds of hand written units with thousands of classes, each spesifically adapted for HTML5, Phonegap and Node.js. Not to mention ports of popular JavaScript frameworks.

If you compare this to native object pascal development tools with similar functionality, they can set you back thousands of dollars. Our asking price of $149 for the pro edition, $399 for the enterprise edition, and a symbolic $42 for the basic edition, that is an affordable solution. Also keep in mind that this gives you access to updates for a duration of 12 months. When was the last time you bought a full development suite that allows you to write mobile applications, platform independent servers, platform independent system services and HTML5 web applications for less that $400 ?

Our price model is more than reasonable considering what you get

With platform independent we mean that in the true sense of the word: once compiled, no changes are required. You can write a system service on Windows and it will run just fine under Linux or OS X. No re-compile needed. You can take a server and copy it to Amazon or Azure, run it in a cluster or scale it from a single instance to 100 instances without any change. That is unheard of for object pascal until now.

Smart Mobile Studio is the only object pascal development system that delivers a stand-alone IDE, stand-alone compiler, a wast object-oriented run-time library written from scratch to cover HTML5, Node.js and embedded systems that run JavaScript.

And yes, we know there are other systems in circulation, but none of them are even close to the functionality that we deliver. Functionality that has been polished for seven years now. And our RTL is growing every day to capture and expose more and more advanced functionality that you can use to enrich your products.

The RTL class browser shows the depth of our RTL

As of writing we have a team of six people working on Smart Mobile Studio. We have things in our labs that is going to change the way people build applications forever. We were the first to venture into this new landscape. There were nobody we could imitate, draw inspiration from or learn from. We had to literally make the path as we moved forward.

And our vision and goal remains the same today as it was seven years ago: to empower object pascal developers – and to secure their investment in the language and methodology that is object pascal.

Discipline and purpose

There is so much I would like to work on right now. Things I want to add to Smart Mobile Studio because I find them interesting, powerful and I know people are going to love them. But that style of development, the “Garage days” as people call it, is over. It does wonders in the beginning of a project maybe, but eventually you reach a stage where a formal timeline and business plan must be carved in stone.

And once defined, you have to stick to it. It would be an insult to our customers if we pivoted left and right on a whim. Like every company we have room for research, even a couple of skunkwork projects, but our primary focus is to make our foundation rock solid before further growth.

By tapping into established JavaScript frameworks you can cover more than 40+ embedded systems and micro-controllers. More and more hardware supports JS for automation

Our “garage days” ended around three years ago, and through hard work we defined our timeline, business model and investor program. In 2017 we secured enough capital to continue full-time development.

Our timeline has been published earlier, but we can re-visit some core points here:

The visual components that shipped with Smart Mobile Studio in the beginning, were meant more as examples than actual ready-to-use modules. This was common for other development platforms of the day, such as Xamarin’s C# / Mono toolchain, where you were expected to inherit from and implement aspects of a “partial class”. This is also why Smart Pascal has support for partial classes (neither Delphi or Freepascal supports this wonderful feature).

One of our skunkwork projects is a custom linux distro that runs your Smart applications directly in the Linux framebuffer. No X or desktop, just your code. Here running “the smart desktop” as the only visual front-end under x86 vmware

Since developers coming from Delphi had different expectations, there was only one thing to do. To completely re-write every single visual control (and add a few new controls) so that they matched our customers expectations. So the first stretch of our timeline has been 100% dedicated to the visual aspects of our RTL. While doing so we have made the RTL faster, more efficient, and added some powerful sub-systems:

• A dedicated theme engine
• Unified event delegation
• Storage device classes
• Focus and control tracking
• Support for relative position modes
• Support for all boxing models
• Inline linking ( {$R “file.js”} will now statically link an external library)
• And much, much more

So the past eight months has been all about visual components.

Theming is important

The second stretch, which we are in right now, is dedicated to the non-visual infrastructure. This means in particular Node.js but also touches on non-visual components, TAction support and things that will appear in updates this year.

Node.js is especially important since it allows you to write platform and chipset independent web servers, system services and command-line applications. This is pioneering work and we are the first to take this road. We have successfully tamed the alien landscape of JavaScript, both for client, mobile and server – and terraformed it into a familiar, safe and productive environment for object pascal developers.

I feel the results speak for themselves, and our next update brings Smart Mobile Studio to the next level: full stack cloud and web development. We now cover back-end, middle-ware and front-end technologies. And our RTL now stretches from micro-controllers to mobile application to clustered cloud services.

This is the same technology used by Netflix to process terabytes of data every second on a global scale. Which should tell you something about the potential involved.

Working on Linux

Since Smart Mobile Studio was designed to be a swiss army knife for Delphi and Lazarus developers, capable to reaching segments of the market where native code is unsuitable – our primary focus is Microsoft Windows. At least for now.

Delphi itself is a Windows-based development system, and even though it supports multiple targets, Windows is still the bread and butter of commercial software development.

Like I mentioned above, we have a timeline to follow, and until we have reached the end of that line, we are not prepared to refactor our IDE for Linux or OS X. This might change sooner than people think, but until our timeline for the RTL is concluded, we will not allocate time for making the IDE platform independent.

But, you can actually run Smart Mobile Studio on both Linux and OS X today.

Linux has a system called Wine. This is a system that implements the Windows API, but delegates all the calls to Linux. So when a Windows program calls a WinAPI through Wine, its delegated to Linux variation of the same call. This is a massive undertaking, but it has years of work behind it and functions extremely well.

So on linux you can install it by opening up a shell and typing:

sudo apt-get install wine

I take for granted here that your Linux flavour has aperture installed (I’m using Ubuntu since that is easy to work with), which is the package manager that gives you the “apt-get” command. If you have some other system then just google how to install a package.

With Wine and it’s dependencies installed, you can run the Smart Mobile Studio installer. Wine will create a virtual, sandboxed disk for you – so that all the files end up where they should. Once finished you punch in the license serial number as normal, and voila – you can now use Smart Mobile Studio on Linux.

Note: in some cases you have to right-click the SmartMS.exe and select “run with -> Wine”, but usually you can just double-click the exe file and it runs.

Smart Mobile Studio on OSX

Wine has been ported to OS X, but it’s more user friendly. You download a program called wine-bottler, which takes Smart and bundles it with wine + any dependencies it needs. You can then start Smart Mobile Studio like it was a normal OS X application.

Themes and look

The only problem with Wine is that it doesnt support Windows themes out of the box. It would be illegal for them to ship those files. But you can manually copy over the windows theme files and install them via the Wine config application. Once installed, Smart will look as it should.

By default the old Windows 95 look & feel is used by Wine. Personally I dont care too much about this, it’s being able to code, compile and run the applications that matters to me – but if you want a more modern look then just copy over the Windows theme files and you are all set.

 

 

Multiplication decomposer

Here is a fun little number decomposer I made a while back. As you might know, the ancient egyptians were no strangers to binary. They also didnt use multiplication tables like we do – but instead used a method called “double down”.

To demonstrate this technique I wrote a simple little program that takes a multiplication and then breaks it down to the numbers an egyptian would look-up in his table to find the right answere.

It’s actually pretty cool. They did not apply multiplication like we do at all, but adding

You will need to drop two textboxes, 3 labels, one button and a memo control on your form (see layout in picture).

 

unit Form1;

interface

uses
  System.Types,
  System.Types.Convert,
  System.Objects,
  System.Time,
  SmartCL.System,
  SmartCL.Time,
  SmartCL.Graphics,
  SmartCL.Components,
  SmartCL.FileUtils,
  SmartCL.Forms,
  SmartCL.Fonts,
  SmartCL.Theme,
  SmartCL.Borders,
  SmartCL.Application,
  SmartCL.Controls.Button,
  SmartCL.Controls.Label,
  SmartCL.Controls.EditBox,
  SmartCL.Controls.Memo;

type

  TDecomposer = Class(TObject)
  private
    FBitValues:   TIntArray;
    FLeftPillar:  TIntArray;
    FRightPillar: TIntArray;
    FSumPillar:   TIntArray;
  protected
    procedure BuildLeftPillar(Number:Integer);
    procedure BuildRightPillar(Multiplier:Integer);
  public
    Property  LeftPillar:TIntArray read FLeftPillar;
    Property  RightPillar:TIntArray read FRightPillar;
    Property  SumPillar:TIntArray read FSumPillar;

    function  DecomposeNumber(aNumber:Integer):String;
    function  DecomposeMultiplication(aNumber,aMultiplier:Integer):String;

    Constructor Create;Virtual;
  end;

  TForm1 = class(TW3Form)
    procedure W3Button1Click(Sender: TObject);
  private
    {$I 'Form1:intf'}
  protected
    procedure InitializeForm; override;
    procedure InitializeObject; override;
    procedure Resize; override;
  end;

implementation

{ TForm1 }

procedure TForm1.W3Button1Click(Sender: TObject);
begin
  var LObj := TDecomposer.Create;
  try
    var LText := LObj.DecomposeMultiplication(StrToInt(w3editbox1.Text),StrToInt(w3editbox2.text));
    w3memo1.text := LText;
    writeln(LText);
  finally
    LObj.free;
  end;
end;

procedure TForm1.InitializeForm;
begin
  inherited;
  // this is a good place to initialize components
end;

procedure TForm1.InitializeObject;
begin
  inherited;
  {$I 'Form1:impl'}
end;

procedure TForm1.Resize;
begin
  inherited;
end;

//#############################################################################
// TDecomposer
//#############################################################################

constructor TDecomposer.Create;
begin
  inherited Create;

  (* Build table of bitvalues *)

  var mValue := 1;
  for var x :=1 to 32 do
  begin
    FBitValues.add(mValue);
    mValue:=mValue * 2;
  end;
end;

procedure TDecomposer.BuildLeftPillar(Number:Integer);
begin
  FLeftPillar.clear;
  if FBitValues.length>0 then
  begin
    var mValue := 1;
    for var x := FBitValues.low to FBitValues.high do
    begin
      if FBitValues[x] <= Number then         FLeftPillar.add(FBitValues[x])       else         break;     end;   end; end; procedure TDecomposer.BuildRightPillar(Multiplier:Integer); begin   FRightPillar.clear;   if FLeftPillar.length>0 then
  begin
    for var x := FLeftPillar.low to FLeftPillar.high do
    begin
      FRightPillar.add(Multiplier);
      Multiplier:=Multiplier * 2;
    end;
  end;
end;

function TDecomposer.DecomposeMultiplication
         (aNumber,aMultiplier:Integer):String;
begin
  var mSum := aNumber * aMultiplier;
  BuildRightPillar(aMultiplier);

  result := aNumber.toString + ' x '
     + aMultiplier.toString
     + ' = '
     + DecomposeNumber(mSum);
end;

function TDecomposer.DecomposeNumber(aNumber:Integer):String;
begin
  FSumpillar.clear;
  FLeftPillar.clear;
  FRightPillar.clear;

  BuildLeftPillar(aNumber);

  for var x := FLeftPillar.low to FLeftPillar.High do
  begin
    if TInteger.getBit(x,aNumber) then
    FSumPillar.add(FBitValues[x]);
  end;

  if FSumPillar.length>0 then
  Begin
    result:=aNumber.ToString + ' = ';
    for var x:=FSumPillar.low to FSumpillar.high do
    begin
      if x=FSumPillar.low then
      result += FSumPillar[x].toString else
      result += ' + ' + FSumPillar[x].toString;
    end;
  end;
end;

function QTX_GetNumberProducer(aNumber:Integer):String;
const
  QTX_BITS:  Array[0..31] of Integer =
  ( 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048,
    4096, 8192, 16384, 32768, 65536, 131072, 262144, 524288,
    1048576, 2097152, 4194304, 8388608, 16777216, 33554432,
    67108864, 134217728, 268435456, 536870912, 1073741824,
    2147483648);
Begin
  var LStack: array of string;
  if aNumber > 0 then
  begin
    for var x := QTX_BITS.low to QTX_BITS.high do
    begin
      if TInteger.getBit(x,aNumber) then
        LStack.add(QTX_BITS[x].toString);
      if QTX_BITS[x] >= aNumber then
        break;
    end;

    if LStack.length>0 then
    begin
      result := aNumber.toString + ' = ';
      for var x := LStack.low to LStack.high do
      begin
        if x > LStack.low then
          result += ' + ' + LStack[x]
        else
          result += LStack[x];
      end;
    end;
  end else
    result := "0";
end;

function QTX_GetNumberMultiplier(aFirst,aSecond:Integer):String;
Begin
  var LSum := aFirst * aSecond;
  result := aFirst.ToString() + ' x ' + aSecond.ToString();
  result += ' = ';
  result += QTX_GetNumberProducer(LSum);
end;

initialization
  Forms.RegisterForm({$I %FILE%}, TForm1);
end.

Paypal, enough is enough

I used to love PayPal. Really, it was a brilliant solution to a global problem.
As a software developer living in Norway, where I spend most of my time with people who live and work in the United States, India or the Arab Emirates – commerce can sometimes be a challenge. It’s a strange situation to be in, where you have lunch with people thousands of miles away. You call up your friends in NYC after work just like you would a friend down the street; and in the weekend you share a cold beer over video chat, or team up on Playstation to enjoy a game together.

I have become, for all means and purposes, an american by proxy.

As a software developer part of what I do is to produce software components. These are intricate blocks of code that can be injected into programs, thus saving other developers the time it takes to implement the functionality from scratch. This is a fantastic thing because one person cannot possibly cope with “everything”. Buying components and libraries is a fundamental part of what a software manager does when prototyping a new product. It is a billion dollar industry and it’s not going away any time soon.

The reason is simple: if you hire someone to research, implement and test something you need in your product, the wages you pay will be 10-100 times higher than if you just buy a pre-fabricated module. I mean, allocating 2 developers to work full-time for a month to make a PDF rendering component (as an example of a complex component) will cost you two months salary. This also leaves you with the responsibility for bugs, updates – the whole nine yards.

“PayPal has a policy where it completely ignores the voice of merchants. They automatically side with the customer and will thus remove funds from your account as they please”

Lets say you have two junior developers making $6000 a month each, coupled with an estimate of 8 weeks to finish the functionality (which is always wrong, so add a couple of weeks for Q&A), that brings us to $12000 + $6000 = $18000. OR — you can just buy a ready to use component for $500 and have PDF support up and running in a day. This also delegates bug-fixing, documentation and updates onto the vendor.

When I wanted to set up shop, I figured that PayPal would be an excellent platform to use. I mean, it’s been around for so long that it’s become intrinsic to international, online economics. It’s available everywhere, and their percentage of sales is reasonable.

Well, that turned out to be a mistake. PayPal is not cool at all when you move from consumer to merchant. Which takes weeks by the way if you live outside the US. You have to send in photocopies of your passport, credit card receipts and social security information; which is illegal in Norway and a serious breach of privacy.

It’s only your money if we allow it

We live in a world where there are a lot of terrible people. People that sell broken goods, that lie, steal and is willing to do just about anything if it benefits them. Honesty is almost regarded as a burden in online business, which I detest and refuse to take part in.

“The second and third calls [to PayPal] resulted in 45 and 90 minutes of “please hold”. They literally exhausted their own merchant to make the case go away.”

UPS is on my door more than the average American household. This is the new reality.

Lord knows I have been victim to some extremely unjust sales representative in my time (havent we all). And the experience has often been that you are helpless once you have received a product. It doesn’t matter if the product you received was faulty, the wrong size – or even the wrong bloody product! As a consumer you often have to calculate how much it will cost you to fight back. And more often than not, fighting back costs more than just accepting that you have been ripped off. I mean, nobody is stupid enough to return the wrong goods to China (for example), because you will never hear from them again.

Well, once I switched from being just a consumer to selling goods and becoming a PayPal merchant – I was shocked to discover that it’s the same situation on the other side! But not from small, semi anonymous scam artists; no it turned out to be PayPal.

PayPal has a policy where it completely ignores the voice of merchants. They automatically side with the customer and will thus remove funds from your account as they please. This happens without a dialog with you as a merchant first. They just waltz in and help themselves to your funds. It’s like something out of a 12th century trial where you are guilty by default and thus there is no room for documentation or evidence to the contrary.

“PayPal didn’t even bother to contact me for verification or comments. They just helped themselves to my registered credit card – which in Norway would have landed them in jail for theft.”

In my case where I sell software components, which by nature is digital and delivered via e-mail, that leaves me as a vendor completely without a voice.

Just weeks ago I got a strange e-mail from a customer who claimed he had not received my software. I naturally took that very seriously so I checked, double checked and triple checked that the software had been sent. I also checked the log on my server to see if the download ticket had been activated (it is marked as active when a full download has been completed. It remains open for 12 months which is the duration of the license).

Well the ticket was active, so there was no doubt that the customer had indeed downloaded the product. And it was downloaded in full. The server picks up on partial downloads so it doesn’t activate should the customer have network problems.

But hey, accident can happen, maybe the customer managed to delete the file or his hard disk was damaged. I gave him the benefit of the doubt and informed him that the ticket has been activated, but he can download as many times as he wants for the duration of 12 months.

In return I got an email saying: “He he, its all good. Thx!“

Well, it sure was all good for him, but not for me. Not only had this man downloaded and made use of my product, he sent a false claim to PayPal stating that he never received the software. And since PayPal can’t deal with packages that are not shipped through their explicit channels (which is made for physical goods, not digital), that was that.

PayPal didn’t even bother to contact me for verification or comments. They just helped themselves to my registered credit card – which in Norway would have landed them in jail for theft.

“A parallel is of a man entering a store, buying an ice-cream, slowly removing the wrapping and starting to eat – while walking over to the store manager claiming, he never got an ice-cream to begin with.”

Had PayPal bothered to contact me, which both Norwegian and European law demands, I could easily document that the customer had indeed downloaded and activated the product. I have both the e-mails between the customer and myself, as well as the ticket logs from the hosting company I use.

There is no doubt that this ticket has been spent, only hours before this scam artist sent his false claim to PayPal.

International vs. national law

Norwegian law gives a merchant 3 chances to rectify a situation. This law applies where the customer has not received what they ordered, where they have received a broken item – or where there has been problems with delivery.

When you sell software however, there are two types with very different rules attached to them. The second method is rarely used outside the world of engineering:

• Compiled proprietary software, which doesn’t avail how the product is made and the customer does not have access to the source code.
• Source code for proprietary software, where the customer receives the actual source code for the product and are allowed to adapt the code. But there are strict rules for not sharing or re-selling this – since it’s very much intellectual property and once shared, cannot be un-shared.

The latter, source code packages (which is what my customer bought), also falls under “spoilables”, meaning that once the customer has received the package, they cannot return it. This applies to other goods too, such as underwear. Since the merchant cannot know if the product has been used (or copied in the case of source-code) – there is never any return policy on such goods once delivered. If the product has not been delivered however, normal return policies apply.

Since PayPal is an American company, I can understand there is some aversion for adapting their services to every known framework of law known to mankind. But I cannot imagine that American legislation on this topic can differ much from Norwegian law. Selling compiled code vs. source-code are two very different things. Comparable to frozen goods and fresh goods. You dont have a 3 week return policy on fruit for obvious reasons.

A parallel is of a man entering a store, buying an ice-cream, slowly removing the wrapping and starting to eat – while walking over to the store manager claiming, he never got an ice-cream to begin with.

There is no way in hell that this would fly with an american store manager. A friend of mine in San-Diego was so upset on my behalf that he called Paypal directly, but they refused to comment without written consent from me. Which I then sent, only to magically disappear.

The second and third calls resulted in 45 and 90 minutes of “please hold”. They literally exhausted their own merchant to make the case go away.

PayPal, trust is a two way street

This episode has shocked me. In fact it has forced me to close my PayPal merchant account permanently. And I will avoid using PayPal as much as possible until they can show normal, human decency for law-abiding citizen, regardless of what country they come from.

Would you run a business with a third-party that can just help themselves to your accounts? I can’t imagine anyone would.

I have no problem giving a customer his money back, provided the delivery ticket is un-spent. Had the customer been unable to download or somehow gain access to the product – then of course normal money back rules apply. I’m not out to cheat anyone, nor am I hard to talk with.

But when there is no dialog at all – and your “bank” ignores the fact that some people are willing to do anything to cheat his fellow-man, that’s when I pack up and leave.

The Amiga ARM project

This has been quite the turbulent week. Without getting into all the details, a post that I made with thoughts and ideas for an Amiga inspired OS for ARM escaped the safe confines of our group, Amiga Disrupt, and took on a life of its own.
This led to a few critical posts being issued publicly, which all boiled down to a misunderstanding. Thankfully this has been resolved and things are back to normal.

The question on everyone’s lips now seem to be: did Jon mean what he said or was it just venting frustration? I thought I made my points clear in my previous post, but sadly Commodore USA formulated a title open for interpretation (which is understandable considering the mayhem at the time). So let’s go thrugh the ropes and put this to rest.

Am I making an ARM based Amiga inspired OS?

Hopefully I don’t have to. My initial post, the one posted to the Amiga Disrupt comment section (and mistaken for a project release note), had a couple of very clear criteria attached:

If nothing has been done to improve the Amiga situation [with regards to ARM or x86] by the time I finish Amibian.js (*), I will take matters into my own hand and create my own alternative.

(*) As you probably know, Amibian.js is a cloud implementation of Amiga OS, designed to bring Amiga to the browser. It is powered by a node.js application server; a server that can be hosted either locally (on the same machine as the html5 client) or remotely. It runs fine on popular embedded devices such as Tinkerboard and ODroid, and when run in a full-screen browser with no X or Windows desktop behind it – it is practically indistinguishable from the real thing.

We have customers who use our prototype to deliver cloud based learning for educational institutions. Shipping ready to use hardware units with pre-baked Amibian.js installed is perfect for schools, libraries, museums, routers and various kiosk projects.

Amibian.js, here running Quake 3 at 60 fps in your browser

Note: This project started years before FriendOS, so we are not a clone of their work.

Obviously this is a large task for one person, but I have written the whole system in Smart Mobile Studio, which is a product our company started some 7 years ago, and that now has a team of six people behind it. In short it takes object pascal code such as Delphi and Freepascal, and compiles this to JavaScript. Suitable for both the browser and NodeJS. It gives you a full IDE with form designer, drag & drop visual components and a wast and rich RTL (run-time library) which naturally saves me a lot of time. So this gives me an edge over other companies working with similar technology. So while it’s a huge task, it’s leveraged considerably by the toolchain I made for it.

So am I making a native OS for ARM or x86? The short answer: I will if the situation havent dramatically improved by the time Amibian.js is finished.

Instead of wasting years trying to implement everything from scratch, Pascal Papara took the Linux kernel and ran with it. So Aeros boots by virtue of the Linux Kernel, but jumps straight into Aros once the drivers has loaded

If you are thinking “so what, who the hell do you think you are?” then perhaps you should take a closer look at my work and history.

I am an ex Quartex member, which was one of the most infamous hacking cartels in europe. I have 30 years of software development behind me, having worked as a professional developer since the age of 17. I have a history of taking on “impossible” projects and finding ways to deliver them. Smart Mobile Studio itself was deemed impossible by most Delphi developers; It was close to heresy, triggering an avalanche of criticism for even entertaining the idea that object pascal could be compiled to JavaScript. Let alone thrive on JSVM (JavaScript Virtual Machine).

Amibian.js runs javascript, but also bytecodes. Here showing the assembler prototype

You can imagine the uproar when our generated JavaScript code (compiled from object pascal) actually bested native code. I must admit we didn’t expect that at all, but it changed the way Delphi and object pascal developers looked at the world – for the better I might add.

What I am good at, is taking ordinary off the shelves parts and assembling them in new and exciting ways. Often ways the original authors never intended; in order to produce something unique. My faith is not in myself, but in the ability and innate capacity of human beings to find solutions. The biggest obstacle to progress is ultimately pride and fear of losing face. Something my Buddhist training beat our of me ages ago.

So this is not an ego trip, it’s simply a coder that is completely fed-up with the perpetual mismanagement that has held Amiga OS in captivity for two decades.

Amiga OS is a formula, and formulas are bulletproof

People love different aspects of the same thing – and the Amiga is no different. For some the Amiga is the games. Others love it for its excellent sound capabilities, while some love it for the ease of coding (the 68k is the most friendly cpu ever invented in my book). And perhaps all of us love the Amiga for the memories we have. A harmless yet valuable nostalgia of better times.

Amiga OS 3.1 pimped up, running on Amibian [native] Raspberry PI 3b

But for me the love was always the OS itself. The architecture of Amiga OS is so elegant and dare I say, pure, compared to other systems. And I’m comparing against both legacy and contemporary systems here. Microsoft Windows (WinAPI) comes close, but the sheer brilliance of Amiga OS is yet to be rivaled.

We are talking about a design that delivers a multimedia driven, window based desktop 10 years before the competition. A desktop that would thrive in as little as 512 kb of ram, with fast and reliable pre-emptive multitasking.

I don’t think people realize or understand the true value of Amiga OS. It’s not in the games (although games is definitively a huge part of the experience), the hardware or the programs. The reason people have been fighting bitterly over Amiga OS for a lifetime, is because the operating system architecture or “formula” is unmatched to this very day.

Can you imagine what a system that thrives under 512 KB would do to the desktop market? Or even better, what it could bring to the table for embedded and server technology?

And this is where my frustration soars up. Even though we have OS 4.1, we have been forced to idly stand by and watch, as mistake after mistake is being made. opportunities that are ripe for the taking (some of them literally placed on the doorstep of Hyperion), have been thrown by the wayside time and time again.

And they are not alone. Aros and Morphos has likewise missed a lot of opportunities. Both opportunities to generate income and secure development as well as embracing new technology. Although I must stress that I sympatize with Aros since they lack any official funding. Morphos is doing much better using a normal, commerical license.

Frustration, the mother of invention

When the Raspberry PI was first released I jumped of joy. Finally a SBC (single board computer) with enough power to run a light version of Amiga OS 4.1, with a price tag that everyone can live with. I rushed over to Hyperion to see if they had issued a statement about the PI, but nothing could be found. The AEON site was likewise empty.

The PI version 2 came and went, still no sign that Hyperion would capitalize on the situation. I expected them to issue a “Amiga OS 4.1 light” edition for ARM, which would put them on the map and help them establish a user base. Without a user base and fresh blood there is no chance in hell of selling next generation machines in large enough quantities to justify future development. But once again, opportunity after oppertunity came and went.

Sexy, fast and modern: Amiga OS 4.1 would do wonders on ARM

Faster and better suited SBC’s started to turn up in droves: The ODroid, Beaglebone black, The Tinkerboard, The Banana PI – and many, many others. When the SnapDragon IV CPU’s shipped on a $120 SBC, which is the same processor used by Samsung Galaxy 6S, I was sure Hyperion would wake up and bring Amiga OS to the masses. But not a word.

Instead we were told to wait for the Amiga x5000 which is based on PPC. I have no problem with PPC, it’s a great platform and packs a serious punch. But since PPC no longer sell to mainstream computer companies like it used to, the price penalty would be nothing short of astronomical. There is also the question of longevity and being able to maintain a PPC based system for the forseeable future. Where exactly is PPC in 15 years?

Note: One of the reasons PPC was selected has to do with coding infrastructure. PPC has an established standard, something ARM lacked at the time (this was first established for ARM in 2014). PPC also has an established set of development platforms that you can build on, with libraries and pre-fab modules (pre fabricated modules, think components that you can use to quickly build what you need) that have been polished for two decades now. A developer who knows PPC from the Amiga days will naturally feel more at home with PPC. But sadly PPC is the past and modern development takes place almost exclusively on ARM and x86. Even x86 is said to have an expiration date now.

The only group that genuinely tried to bring Amiga OS to ARM has been the Aros team. They got their system compiled, implemented some rudimentary drivers (information on this has been thin to say the least) and had it booting natively on the Raspberry PI 3b. Sadly they lacked a USB stack (remember I mentioned pre-fab modules above? Well, this is a typical example. PPC devtools ship with modules like this out of the box) so things like mouse, keyboard and external peripherals wouldn’t work.

Aeros, the fastest Amiga you will ever play with. Running on the Raspberry PI 3b

And like always, which is the curse of Amiga, “something came up”, and the whole Raspberry PI / ARM initiative was left for dead. The details around this is sketchy, but the lead developer had a personal issue that forced him to set a new direction in life. And for some reason the other Aros developers have just continued with x86, even though a polished ARM version could have made them some money, and helped finance future development. It’s the same story, again and again.

But then something amazing happened! Out of the blue came Pascal Papara with a new take on Aros, namely AEROS. This is a distro after my own heart. Instead of wasting years trying to implement everything from scratch, Pascal took the Linux kernel and ran with it. So Aeros boots by virtue of the Linux Kernel, but jumps straight into Aros once the drivers has loaded. And the result? It is the fastest desktop you will ever experience on ARM. Seriously, it runs so fast and smooth on the Raspberry PI that you could easily mistake it for a $450 Intel i3.

Sadly Pascal has been more or less alone about this development. And truth be told he has molded it to suit his own needs rather than the consumer. Since his work includes a game machine and some Linux services, the whole Linux system is exposed to the Aros desktop. This is a huge mistake.

Using the Linux kernel to capitalize on the thousands of man hours invested in that, not to mention the linux driver database which is massive, is a great idea. It’s also the first thing that came into my mind when contemplating the issue.

But when running Aros on top of this, the Linux aspect of the system should be abstracted away. Much like what Apple did with Unix. You should hardly notice that Linux is there unless you open a shell and start to investigate. The Amiga filesystem should be the only filesystem you see when accessing things from the desktop, and a nice preferences option for showing / hiding mounted Linux drives.

My plans for an ARM based Amiga inspired OS

Building an OS is not a task for the faint of heart. Yes there is a lot of embedded / pre-fab based systems to pick from out there, but you also have to be sensible. You are not going to code a better kernel than Linus Torvalds, so instead of wasting years trying to catch up with something you cannot possibly catch up with – just grab the kernel and make it work for us.

The Linux kernel solves things such as process contexts, “userland” vs “kernel space” (giving the kernel the power to kill a task and reclaim resources), multitasking / threading, thread priorities, critical sections, mutexes and global event objects; it gives us IPC (inter process communication), disk IO, established and rock solid sound and graphics frameworks; and last but perhaps most important: free access to the millions of drivers in the Linux repository.

Early Amibian.js login dialog

You would have to be certified insane to ignore the Linux Kernel, thinking you will somehow be the guy (or group) that can teach Linus Torvalds a lesson. This is a man who has been writing kernel’s for 20+ years, and he does nothing else. He is surrounded by a proverbial army of developers that code, test, refactor and strive to deliver optimal performance, safety and quality assurance. So sorry if I push your buttons here, but you would be a moron to take him on. Instead, absorb the kernel and gain access to the benefits it has given Linux (technically the kernel is “Linux”, the rest is GNU – but you get what I mean).

With the Linux kernel as a foundation, as much as 50% of the work involved in writing our OS is finished already. You don’t have to invent a driver API. You dont have to invent a new executable format (or write your own ELF parser if you stick with the Linux executable). You can use established compilers like GCC / Clang and Freepascal. And you can even cherry pick some low-level packages for your own native API (like SDL, OpenGL and things that would take years to finish).

But while we want to build our house on rock, we don’t want it to be yet another Linux distro. So with the kernel in place and a significant part of our work done for us, that is also where the similarities end.

The end product is Amiga OS, which means that we need compatibility with the original Amiga rom libraries (read: api). Had we started from scratch that would have been a tremendous effort, which is also why Aros is so important. Because Aros gives us a blueprint of how they have implemented these API’s.

But our main source of inspiration is not Aros, but Amithlon. What we want to do is naturally to pipe as much as we can from the Amiga API’s back to the Linux kernel. Things like device detection, memory allocation, file IO, pipes, networking — our library files will be more thin wrappers that expose Amiga compatible calls; methods that calls the Linux Kernel to do the job. So our Amiga library files will be proxy objects whenever possible.

Amithlon, decades ahead of it’s time

The hard work is when we get to the window manager, or Intuition. Here we can’t cheat by pushing things back to Linux. We don’t want to install X either (although we can render our system into the X framebuffer if we like), so we have to code a window manager. This is not as simple as it sounds, because our system must operate with multiple cores, be multi threaded by design and tap into the grand scheme of things. Things like messages (which is used by applications to respond to input) must be established, and all the event codes from the original Amiga OS must be replicated.

So this work wont be easy, but with the Linux kernel as a foundation – the hardest task of all is taken care of. The magic of a kernel is that of process management and task switching. This is about as hard-core as you can get. Without that you can almost forget the rest. But since we base our system on the Linux kernel, we can focus 100% on the real task – namely to deliver a modern Amiga experience, one that is platform independent (read: conforms to standard Linux and can thus be recompiled and run anywhere Linux can run), preserves as much of the initial formula as possible – and can be successfully maintained far into the future.

By pushing as much of our work as possible into user-space (the process space where ordinary programs run, the kernel runs outside this space and is thus unaffected when a program crashes) and adhering to the Linux kernel beneath the bonnet, we have created a system that can be re-compiled anywhere Linux is. And it can be done so without any change to our codebase. Linux takes care of things like drivers, OpenGL, Sound — and presents to us a clean API that is identical on every platform. It doesn’t matter if it’s ARM, PPC, 68k, x86 or MIPS. As long as we follow the standards we are home free.

Last words

I hope all of this clears up the confusion that has surrounded the subject this week. Again, the misunderstanding that led to some unfortunate posts has been resolved. So there is no negativity, no drama and we are all on the same page.

Early Amibian.js prototype, running 68k in the browser via uae.js optimized

Just remember that I have set some restrictions for my involvement here. I sincerely hope Hyperion and the Aros development group can focus on ARM, because the community needs this. While the Raspberry PI might seem too small a form-factor to run Aros, projects like Aeros have proven just how effective the Amiga formula is. I’m sure Hyperion could find a powerful ARM SOC in the price range of $120 and sell a complete package with profit for around $200.

What the Amiga community needs now, is not expensive hardware. The userbase has to be expanded horizontally across platforms. Amiga OS / Aros has much to offer the embedded market which today is dominated by overly complex Linux libraries. The Amiga can grow laterally as a more user-friendly alternative, much like Android did for the mobile market. Once the platform is growing and established – then custom hardware could be introduced. But right now that is not what we need.

I also hope that the Aros team drops whatever they are working on, fork Pascal Paparas codebase, and spend a few weeks polishing the system. Abstract away the Linux foundation like Apple have done, get those sexy 32 bit OS4 icons (Note: The icons used by Amiga OS 4 is available for free download from the designer’s website) and a nice theme that looks similar to OS 4 (but not too similar). Get Lazarus (the freepascal IDE) going and ship the system with a ready to use Pascal, C/C++ and Basic development environments. Bring back the fun in computing! The code is already there, use it!

Aeros interfaces directly with linux, I would propose a less direct approach

Just take something simple, like a compatible browser. It’s actually not that simple, both for reasons of complexity and how memory is handled by PPC. With a Linux foundation things like Chromium Embedded could be inked into the Amiga side of things and we would have a native, fast, established and up-to-date browser.

At the same time, since we have API level compatability, people can recompile their Aros and Morphos applications and they would run more or less unchanged.

I really hope that my little protest here, if nothing else, helps people realize that there are viable options readily at hand. Commodore is not coming back, and the only future this platform has – is the one we make. So people have to ask themselves how much they want a future.

If the OS gains momentum then there will be grounds for investors to look at custom hardware. They can then choose off the shelves parts that are inexpensive to cover the normal functionality you expect in a modern computer – which more resources can go into custom hardware that sets the system apart. But we cant start there. It has to be built up brick by brich, standing on the shoulders of giants.

OK, rant over 🙂