Posts Tagged ‘Raspberry PI’

RemObjects Elements + ODroid N2 = true

August 7, 2019 Leave a comment

Since the release of Raspberry PI back in 2012 the IOT and Embedded market has exploded. The price of the PI SBC (single board computer) enabled ordinary people without any engineering background to create their own software and hardware projects; and with that the IOT revolution was born.

Almost immediately after the PI became a success, other vendors wanted a piece of the pie (pun intended), and an avalanche of alternative mini computers started surfacing in vast quantities. Yet very few of these so-called “pi killers” actually stood a chance. The power of the Raspberry PI is not just price, it’s actually the ecosystem around the product. All those shops selling electronic parts that you can use in your IOT projects for example.


The ODroid N2, one of the fastest SBCs in it’s class

The ODroid family of single-board computers stands out as unique in this respect. Where other boards have come and gone, the ODroid family of boards have remained stable, popular and excellent alternatives to the Raspberry PI. Hardkernel, the maker of Odroid boards and its many peripherals, are not looking for a “quick buck” like others have. Instead they have slowly and steadily perfected their hardware,  software, and seeded a great community.

ODroid is very popular at RemObjects, and when we added 64-bit ARM Linux support a couple of weeks back, it was the ODroid N2 board we used for testing. It has been a smooth ride all the way.


As I am typing this, a collection of ODroid XU4s is humming away inside a small, desktop cluster I have built. This cluster is made up of 5 x ODroid XU4 boards, with an additional ODroid N2 acting as the head (the board that controls the rest via the network).


My ODroid Cluster in all its glory

Prior to picking ODroid for my own projects, I took the time to test the most popular boards on the market. I think I went through eight or ten models, but none of the other were even close to the quality of ODroid. It’s very easy to confuse aggressive marketing with quality. You can have the coolest hardware in the world, but if it lacks proper drivers and a solid Linux distribution, it’s for all means and purposes a waste of time.

Since IOT is something that i find exciting on a personal level, being able to target 64-bit ARM Linux has topped my wish-list for quite some time. So when our compiler wizard Carlo Kok wanted to implement support for 64-bit ARM-Linux, I was thrilled!

We used the ODroid N2 throughout the testing phase, and the whole process was very smooth. It took Carlo roughly 3 days to add support for 64-bit ARM Linux and it hit our main channel within a week.

I must stress that while ODroid N2 is one of our verified SBCs, the code is not explicitly about ODroid. You can target any 64-bit ARM SBC providing you use a Debian based Linux (Ubuntu, Mint etc). I tested the same code on the NanoPI board and it ran on the first try.

Why is this important?

The whole point of the Elements compiler toolchain, is not just to provide alternative compilers; it’s also to ensure that the languages we support become first class citizens, side by side with other archetypical languages. For example, if all you know is C# or Java, writing kernel drivers has been our of limits. If you are operating with traditional Java or .Net, you have to use a native bridge (like the service host under Windows). Your only other option was to code that particular piece in traditional C.


With Elements you can pick whatever language you know and target everything

With Elements that is no longer the case, because our compilers generates llvm optimized machine-code; code that in terms of speed, access and power stand side by side with C/C++. You can even import C/C++ header files and work directly with the existing infrastructure. There is no middleware, no service host, no bytecodes and no compromise.

Obviously you can compile to bytecodes too if you like (or WebAssembly), but there are caveats to watch out for when using bytecodes on SBCs. The garbage collector can make or break your product, because when it kicks in -it causes CPU spikes. This is where Elements step-up and delivers true native compilation. For all supported targets.

More boards to come

This is just my personal blog, so for the full overview of boards I am testing there will be a proper article on our official RemObjects blog-space. Naturally I can’t test every single board on the market, but I have around 10 different models which covers the common boards used by IOT and embedded projects.

But for now at least, you can check off the ODroid N2 (64-bit) and NanoPI-Fire 2 (32-bit)

PNG icons on Amiga OS 3.X

December 6, 2017 2 comments

A couple of days back I posted a couple of pictures of my Raspberry PI 3b based Amiga setup. This caused quite a stir on several groups and people were unsure what exactly I was posting. Is this Amiga OS 4? Is it Aros? Scalos? Or perhaps just a pimped up classic Amiga 3.x?


The more the questions arose the more I realized that a lot of people dont really know what the PI can do. I dont blame them, between work, kids and mending a broken back it probably took me a year before I even entertained the idea of setting up a proper UAE environment. And as luck would have it, two good friends of mine Gunnar kristjánsson and Thomas Navarro Garcia, had already done the worst part: namely to produce a Linux distro that auto-boots into Workbench (or technically, into a full screen UAE environment).

Taking advantage of speed

Purists might not be happy about it, but the PI delivers some serious processing power when it comes to Amiga emulation. The version of UAE Thomas and Gunnar opted for is UAE4Arm, which is a special version that contains a hand-optimized JIT engine. This takes 68k code and generates ARM machine code “on the fly” and is thus able to run Amiga software much faster than traditional UAE variations like fs-uae.

But what should we do with all that extra speed? I mean, there is a limited number of tasks that benefits from the extra processing power of the PI (or an acellerator for that matter). Well, being a programmer the process of compilation is one aspect I really love the extra grunt. When using modern compilers like freepascal 3.x on a classic 68k amiga, there is no denying we need all the cpu power we can get. So compiling on the PI is a great boost over ordinary, real Amiga machines.


Freepascal is great, although the old “turbo” ide is due for an overhaul

The second aspects is the infrastructure. And this is where we get to the pimping part. By default Workbench is optimized for low-color representation. Meaning that icons and backdrops will be 4-8 colors, fixed palette and fairly useless by modern standards. Since UAE4Arm has built in support for RTG (re-targetable graphics), which means 15, 16, 24 and 32 bit screen-modes (the same as any modern PC) then surely we can remedy the visuals right?

Well, I had a google around and found that there is an icon library that supports the latest png based icons. These are icons that contain 32bit graphics with support for alpha blending (transparency). This is the exact same icon system that is used in Amiga OS 4.

So what I did was download  the versionb 46.x icon library from Aminet. Since the PI emulates (in my config) a mc68040 cpu, i was able to use the 040 optimized binary. And in essence i just copied that into my “libs” folder (and removed the old one first just to be sure).

And voila, my Workbench was now able to show 32 bit png icons just like OS 4 is!

Getting some bling

With OS 4 style icons supported, where do I get some icons to play with? Well, again I went on Aminet and downloaded a ton of large icon packs. I also visited OS4Depot and downloaded some cool background pictures and even more icons.

Then it was the time consuming process or manually replacing the *.info files. All files that you can see via Workbench has an associated .info file with the same name. So if you have a program called “myprogram”, then the icon file will be “”.

And that’s basically it! I spent a saturday replacing icons and doing some mild tweaking in VisualPrefs (again on Aminet), and suddenly my old, grey workbench was alive with radient colors.


I love it! It might not be perfect but i have seen Linux distros that looks worse!

What I find amazing is that even after 30 years the old Amiga OS 3.x can still suprise us! If nothing else it’s a testament to the flexible architecture the guys at Commodore knocked out, an architecture that thrives in extremely low memory situations – yet delivers in spades if you give it more to work with.

Doing some modern chores

One of the first things I installed on my PI was a copy of freepascal. This has been updated to version 3.1, which is just one revision behind the compiler used on Windows and OSX. This is a bit too nifty for standard Amiga machines. You need at least an A1200 with 64 megabyte ram to work with it. Although the size of the binaries is reasonable small if you stay clear of the somewhat bloated LCL framework.

So I was able to use my object pascal skills to create a unzip/zip command-line program in 15 minutes. Doing this on my Amibian box felt great, and I really enjoy the fresh new look of Workbench. In a perfect work OS4 would be 68k and the CPU’s would all be fpga’s that ran close to Intel i7 speeds, but alas – a humble PI will have to do for now.


If you want to re-create my experiment then start by downloading Amibian. This is a clean Linux Distro and doesnt contain workbench. So after you have made an sd-card with Amibian you need to copy over workbench. I suggest you copy over the raw files and mount a linux folder as a drive. Using harddisk images is possible, but I dont trust them. And should an error occur you lose everything. So yeah, stick with folder-mounted drives if you want less frustration.

You can visit Amibian here:

Why buy a Vampire accelerator?

August 24, 2017 4 comments

With the Amiga about to re-enter the consumer market, a lot of us “old timers” are busy knocking dust of our old machines. And I love my old machines even though they are technically useless by modern standards. But these machines have a lot of inspiration in them, especially if you write code. And yes there is a fair bit of nostalgia involved in this, there is no point in lying about any of this.

I mean, your mobile phone is probably 100 times faster than a vintage Amiga. But like you will discover with the new machines that are about to hit the market, there is more to this computer than you think. But vintage Amiga? Sadly they lack the power to anything useful [in the “modern” sense].

Enter the vampire

The Vampire is a product that started shipping about a year ago. It’s a FPGA based accelerator, and it’s quite frankly turning the retro scene on its head! Technically it’s a board that you just latch onto the CPU socket of your classical Amiga; it then takes over the whole machine and replace the CPU and chipset with its versions of these. Versions that are naturally a hell of a lot faster!

vanpireThe result is that the good old Amiga is suddenly beefy enough to play Doom, Quake, MP3 files and MPG video (click here to read the datasheet). In short: this little board gives your old Amiga machine a jolt of new life.

Emulation vs. FPGA

Im not going to get into the argument about FPGA not being “real”, because that’s not what FPGA is about. Nor am I negative to classical hardware – because I own a ton of old Amiga gear myself. But I will get in your face when it comes to buying a Vampire.

Before we continue I just want to mention that there are two models of the vampire. There is the add-on board I have just mentioned which is again divided into different models for various Amiga versions (A600, A500 so far). The second model is a completely stand-alone vampire motherboard that wont even need a classic Amiga to work. It will be, for all means and purposes, a stand alone SBC (single board computer) that you just hook up power, video, storage and mouse – and off you go!

This latter version, the stand-alone, is a project I firmly believe in. The old boards have been out of production since 1993 and are getting harder to come by. And just like people they will eventually break down and stop working. There is also price to consider because getting your 20-year-old A500 fixed is not easy. First of all you need a specialist that knows how to fix these old things, and he will also need parts to work with. Since parts are no longer in production and homebrew can only go so far, well – a brand new motherboard that is compatible in every way sounds like a good idea.

There is also the fact that FPGA can reach absurd speeds. It has been mentioned that if the Vampire used a more expensive FPGA modules, 68k based Amiga’s could compete with modern processors (Source: Can you imagine a 68k Amiga running side by side with the latest Intel processors? Sounds like a lot of fun if you ask me !


Amiga 1000, in my view the best looking Amiga ever produced

But then there is emulation. Proper emulation, which for Amiga users can only mean one thing: UAE in all its magnificent diversity and incarnations.

Nothing beats firing up a real Amiga, but you know what? It has been greatly exaggerated. I recently bought a sexy A1000 which is the first model that was ever made. This is the original Amiga, made way back before Commodore started to mess around with it. It cost me a small fortune to get – but hey, it was my first ever Amiga so I wanted to own one again.

But does it feel better than my Raspberry PI 3b powered A500? Nope. In fact I have only fired up the A1000 twice since I bought it, because having to wait for disks to load is just tedious (not to mention that you can’t get new, working floppy disks anymore). Seriously. I Love the machine to bits but it’s just damn tedious to work on in 2017. It belongs to the 80s and no-one can ever take away its glory or it’s role in computer history. That achievement stands forever.

High Quality Emulation

If you have followed my blog and Amiga escapades, you know that my PI 3b based Amiga, overclocked to the hilt, yields roughly 3.2 times the speed of an Amiga 4000/040. This was at one point the flagship Commodore computer. The Amiga 4000’s were used in movie production, music production, 3d rendering and heavy-duty computing all over the world. And the 35€ Raspberry PI gives you 3.2 times the power via the UAE4Arm emulator. I don’t care what the vampire does, the PI will give it the beating of its life.

Compiling anything, even older stuff that is a joke by today standard, is painful on the Raspberry PI. Here showing my retro-fitted A500 PI with sexy led keyboard. It will soon get a makeover with an UP board :)

My retrofitted Raspberry PI 3b Amiga. Serious emulation at high speed allowing for software development and even the latest Freepascal 3.x compiler

Then suddenly, out of the blue, Asus comes along with the Tinkerboard. A board that I hated when it first came out (read part-1 here, part-2 here) due to its shabby drivers. The boards have been collecting dust on my office shelf for six months or so – and it was blind luck that i downloaded and tested a new disk image. If you missed that part you can read the full article here.

And I’m glad I did because man – the Tinkerboard makes the Raspberry PI 3b look like a toy! Asus has also adjusted the price lately. It was initially priced at 75€, but in Norway right now it retails for about 620 NKR – or 62€. So yes, it’s about twice the price of the PI – but it also gives you twice the memory, twice the graphics performance, twice the IO performance and a CPU that is a pleasure to work with.

The Raspberry PI 3b can’t be overclocked to the extent the model 1 and 2 could. You can over-volt it and tweak the GPU and memory and make it run faster. But people don’t call that “overclock” in the true sense of the word, because that means the CPU is set to run at speeds beyond the manufacturing specifications. So with the PI 3b there is relatively little you can do to make it run faster. You can speed it up a little bit, but that’s it. The Tinkerboard can be overclocked to the hilt.


The A1222 motherboard is just around the corner [conceptual art]

Out of the box it runs at 1.5 Ghz, but if you add a heatsink, fan (important) and a 3A PSU – you can overclock it to 2.6 Ghz. And like the PI you can also tweak memory and gpu. So the Tinkerboard will happily run 3 times faster than the PI. If you add a USB3 harddisk you will also beef up IO speeds by 100 megabyte a second – which makes a huge difference. Linux does memory paging and it slows down everything if you just use the SD card.

In short: if you fork out 70€ you get a SBC that runs rings around both the vampire and the Raspberry PI 3b. If we take height for some Linux services and drivers that have to run in the background, 3.2 x 3 = 9.6. Lets round that off to 9 since there will be performance hits by the background services. But still — 70€ for an Amiga that runs 9 times faster than A4000 @ MC68040 cpu ? That should blow your mind!

I’m sorry but there has to be something wrong with you if that doesn’t get your juices flowing. I rarely game on my classic Amiga setup. I’m a coder – but with this kind of firepower you can run some of the biggest and best Amiga titles ever made – and the Tinkerboard wont even break a sweat!

You can’t afford to be a fundamentalist

There are some real nutbags in the Amiga community. I think we all agree that having the real deal is a great experience, but the prices we see these days are borderline insane. I had to fork out around 500€  to get my A1000 shipped from Belgium to Norway. Had tax been added on the original price, I would have looked at something in the 700€ range. Still – 500€ for a 20-year-old computer that can hardly run Workbench 1.2? Unless you add the word “collector” here you are in fact barking mad!

If you are looking to get an Amiga for “old times sakes”, or perhaps you have an A500 and wonder if you should fork out for the Vampire? Will it be worth the 300€ pricetag? Unless you use your Amiga on a daily basis I can’t imagine what you need a vampire for. The stand-alone motherboard I can understand, that is a great idea – but the accelerator? 300€?

I mean you can pay 70€ and get the fastest Amiga that ever existed. Not a bit faster, not something on second place – no – THE FASTEST Amiga that has ever existed. If you think playing MP3 and MPG media files is cool with the vampire, then you are in for a treat here because the same software will work. You can safely download the latest patches and updates to various media players on the classic Amiga, and they will run just fine on UAE4Arm. But this time they will run a hell of a lot faster than the Vampire.


My old broken A500 turned into an ass-kicking, battle hardened ARM monster

You really can’t be a fundamentalist in 2017 when it comes to vintage computers. And why would you want to? With so much cool stuff happening in the scene, why would you want to limit your Amiga experience to a single model? Aros is doing awesome stuff these days, you have the x5000 out and the A1222 just around the corner. Morphos is stable and good on the G5 PPC — there has never been a time when there were so many options for Amiga enthusiasts! Not even during the golden days between 1989-1994 were there so many exciting developments.

I love the classic Amiga machines. I think the Vampire stand-alone model is fantastic and if they ramp up the fpga to a faster model, they have in fact re-created a viable computer platform. A 68080 fpga based CPU that can go head to head with x86? That is quite an achievement – and I support that whole heartedly.

But having to fork out this amount of cash just to enjoy a modern Amiga experience is a bit silly. You can actually right now go out and buy a $35 Raspberry PI and enjoy far better results than the Vampire is able to deliver. How that can be negative? I have no idea, nor will I ever understand that kind of thinking. How do any of these people expect the Amiga community to grow and get new, young members if the average price of a 20-year-old machine costs 500€? Which incidentally is 50€ more than a brand new A1222 PPC machine capable of running OS 4.

And with the Tinkerboard you can get 9 times the speed of an A4000? How can that not give you goosebumps!

People talk about Java and Virtual-Machines like its black magic. Well UAE gives you a virtual CPU and chipset that makes mince-meat of both Java and C#. It also comes with one of the largest software libraries in the world. I find it inconceivable that no-one sees the potential in that technology beyond game playing – but when you become violent or nasty over hardware, then I guess that explains quite a bit.

I say, use whatever you can to enjoy your Amiga. And if your perfect Amiga is a PI or a Tinkerboard (or ODroid) – who cares!

I for one will not put more money into legacy hardware. I’m happy that I have the A1000, but that’s where it stops for me. I am looking forward to the latest Amiga x5000 PPC and cant wait to get coding on that – but unless the Appollo crew upgrades to a faster FPGA I see little reason to buy anything. I would gladly pay 500 – 1000 € for something that can kick modern computers in the behind. And I imagine a lot of 68k users would be willing to do that as well. But right now PPC is a much better option since it gives you both 68k and the new OS 4 platform in one price. And for affordable Amiga computing, emulation is now of such quality that you wont really notice the difference.

And I love coding 68k assembler on my Amibian emulator setup. There is nothing quite like it 🙂

The Tinkerboard Strikes Back

August 20, 2017 1 comment

For those that follow my blog you probably remember the somewhat devastating rating I gave the Tinkerboard earlier this year (click here for part 1, and here for part 2). It was quite sad having to give such a poor rating to what is ultimately a fine piece of hardware. I had high hopes for it – in fact I bought two of the boards because I figured there was no way it could suck with that those specs. But suck it did and while the muscle was there, the drivers were in such a state that it never emerged for the user. It was released prematurely, and I think most people that bought it agrees on this.


The initial release was less than bad, it was horrible

Since my initial review those months ago good things have happened. Asus seem to have listened to the “poonami” of negative feedback and adapted their website accordingly. Unlike the first time I visited when you literally had to dig into recursive menus (which was less than intuitive in this case) just to download the software – the disk images are now available at the bottom of the product page. So thumbs up for that (!)

They have also made the GPIO programming API a lot easier to get; downloading it is reduced to a “one liner” for C developers, which is the way it should be. And they have likewise provided wrappers for other languages, like ever popular python and scratch.

I am a bit disappointed that they don’t provide freepascal units. A lot of developers use object pascal on these board after all, because Object Pascal gives you a better balance between productivity and depth. Pascal is easier to learn (it was designed for that after all) but avoids some of the pitfalls of C/C++ while retaining all the good things. Porting over C headers is fairly easy for a good pascal programmer – but it would be cool of Asus remember that there are more languages in the world than C and python.

All of this aside: the most important change of all is what Asus has done with the drivers! They have finally put together drivers that shows off the capabilities of the hardware and unleash the speed we all hoped for when the board was first announced. And man does it show! My previous experience with the Tinkerboard was horrible; it was the text-book example of a how not to release a product (the whole release has been odd; Asus is a huge, multi-national corporation. Yet their release had basement 3 man band written all over it).

So this is fantastic news! Finally the Tinkerboard delivers and can be used for real life projects!

Smart IOT

At The Smart Company we both create and use our core product, Smart Mobile Studio, to deliver third-party solutions. As the name implies Smart is a software development system initially made for mobile applications; but it quickly grew into a much larger toolchain and is exceptionally good for making embedded applications. With embedded applications I mean things that run on kiosk systems, cash machines and stuff like that; basically anything with a touch-screen that does something.


The Smart desktop gives you a good starting point for embedded work

One of the examples that ship with Smart Pascal is a fully working desktop embedded environment. Smart compiles for both ordinary browsers (JavaScript environments with a traditional HTML5 display) but also for node.js, which is JavaScript unbound by the strict rules of a browser. Developers typically use node.js to write highly scalable server software, but you are naturally not limited to that. Netflix is written 100% in Node.js, so we are talking serious firepower here.

Our embedded environment is called The Smart Desktop (also known as Amibian.js) and gives you a ready-made node.js back-end that couples with a HTML5 front-end. This is a ready to use environment that you can deploy your own applications through. Things like storage, a nice looking UI, user logon and credentials and much, much more is all implemented for you. You don’t have to use it of course, you can write your own system from scratch if you like. We created “Amibian” to demonstrate just how powerful Smart Pascal can be in the right hands.

With this in mind – my main concern when testing SBC’s (single board computers) is obviously web performance. By default JavaScript is a single core event-driven runtime system; you can spawn threads of course but its done somewhat different from how you would work in Delphi or C++.  JavaScript is designed to be system friendly and a gentle giant if you like, which has turned out to be a good thing – because the way JS schedules execution makes it ideal for clustering!

Most people find it hard to believe that JavaScript can outperform native code, but the JavaScript runtimes of today is almost a whole eco system in themselves. With JIT compilers and LLVM optimization — it’s a whole new ballgame.

Making a scale

To give you a better context to see where the Tinkerboard is on a scale, I decided to set up a couple of simple tests. Nothing fancy, just running the same web applications and see how each of them perform on different boards. So I used the same 3 candidates as before, namely the Raspberry PI 3b, the Hardkernel ODroid XU4 and last but not least: the Asus Tinkerboard.

I setup the following applications to compile with the desktop system, meaning that they were compiled with the Smart project. We got plenty of web applications but for this I wanted to pack the most demanding apps in our library:

  • Skid-Row intro remake using the CODEF library
  • Quake 3 asm.js build
  • Plex

OK let’s go through them and see where the chips land!

The Raspberry PI 3b


Bassoon ran well, its not that demanding

The Raspberry PI was aweful (click here for a video). There is no doubt that native applications like UAE4Arm runs extremely well on the PI (which contains hand optimized assembler, not exactly a fair fight)- but when it comes to modern HTML5 the PI doesn’t stand a chance. You could perhaps use a Raspberry PI 3b for simple applications which are not graphic and cpu intensive, but you can forget about anything remotely taxing.

It ran Bassoon reasonably fast, but all in all you really don’t want a raspberry when doing high quality IOT, unless its headless code and node.js perhaps. Frameworks like Johnny #5 gives you a ton of GPIO features out of the box – in fact you can target 40 embedded systems without any change to your code. But for large, high quality web front-ends, the PI just wont cut it.

  • Skid-Row: 1 frame per second or less
  • Quake: Can’t even start, just forget it
  • Plex: Starts but it lags so much you can’t watch anything

But hey, I never expected $35 to give me a kick ass ARM experience anyways. There are 1000 things the PI does very well, but HTML is not one of them.

ODroid XU4


The ODroid packs a lot of power!

The ODroid being faster than the Raspberry PI is nothing new, but I was surprised at how much power this board delivers. I never expected it to give me a Linux experience close to that of a x86 PC; I mean we are talking about a 45€ SBC here. And it’s only 10€ more than the Raspberry PI, which is a toy at best. But the ODroid XU4 delivers a good Linux desktop; And it’s well worth the extra 10€ when compared to the PI.

Personally I don’t understand why people keep buying PI’s when there is so much better options on the market now. At least not if web technology is involved. A small server or emulator sure, but not HTML5 and browsers. The PI just cant handle it.

  • Skid-Row: 4-5 frames per second
  • Quake: Runs at very enjoyable speed (!)
  • Plex: Runs well but you may want to pick SD or 720p to avoid lags

What really shocked me was that ODroid XU4 can run Quake.js! The PI can’t even start that because it’s so demanding. It is one of the largest and most resource hungry asm.js projects out there – but ODroid XU4 did a fantastic job.

Now it’s not a silky smooth experience, I would guess something along the lines of 17-20 fps. But you know what? Thats pretty good for a $45 board.

I have owned far worse x86 PC’s in my day.

The Tinkerboard

Before i powered up the board I was reluctant to push it too far, because I thought it would fail me once again. I did hope that something had been done by Asus to rectify the situation though, because Asus really should have done a better job before releasing it. It’s now been roughly 6 months since I bought it, and roughly 8 months since it was released here in Europe. It would have been better for them to have waited with the release. I was not alone about butchering the whole board, its been a source of frustration for those that bought it. 75€ is not much, but no-one likes to throw money out the window like that.

Long story short: I downloaded the latest Ubuntu image and burned that to an SD card (I actually first downloaded the Debian Jessie image they have, but sadly you have to do a bit of work to turn that into a desktop system – so I decided to go for Ubuntu instead). If the drivers are in order I have a feeling the Jessie image will be even faster – Ubuntu has always been a high-quality distribution, but it’s also one of the most demanding. One might even say it’s become bloated. But it does deliver a near Microsoft Windows like experience which has served the Linux community well.

But the Tinkerboard really delivers! (click here for the video) Asus have cleaned up their act and implemented the drivers properly, and you can feel that the moment the desktop comes into view. With the PI you are always fighting with lagging performance. When you start a program the whole system freezes for a while, when you quit a program the system freezes – hell when you move the mouse around the system bloody freezes! Well that is not the case with the Tinkerboard that’s for sure. The tinkerboard feels more like running vanilla Ubuntu on a normal x86 PC to be honest.

  • Skid-Row: 10-15 frames per second
  • Quake: Full screen 32bit graphics, runs like hell
  • Plex: Plays back fullscreen HD, just awesome!

All I can say is this: if you are going to do any bit of embedded coding, regardless if you are using Smart Mobile Studio or some other devkit — this is the board to get (!)

Like already mentioned it does cost almost twice as much as the PI, but that extra 30€ buys you loads of extra power. It opens up so many avenues of code and you can explore software far more complex than both the PI and ODroid combined. With the tinkerboard you can finally deliver a state of the art product built with off the shelves web components. It’s in a league of its own.

The ‘tinker’ rocks at last

When I first bought the tinker i felt cheated. It was so frustrating because the specs were so good and the terrible performance just came down to sloppy work and Asus releasing it prematurely for cash (lets face it, they tapped into the lucrative market established by the PI foundation). By looking at the specs you knew it had the firepower to deliver so much, but it was held back by ridicules drivers.

There is still a lot that can be done to make the Tinkerboard run even faster. Like I mentioned Ubuntu is not the racecar of distributions out there. Ubuntu is fat, there is no other way of saying it. So if someone took the time to create a minimalistic Jessie image, recompile every piece with maximum llvm optimization and as few running services as possible — the tinkerboard would positively fly!

So do I recommend it? I am thrilled to say that yes, I can finally recommend the tinkerboard! It is by far the coolest board in my collection now. In fact it’s so good that I’m donating one to my daughter. She is presently using an iMac which is overkill for her needs at age 10. Now I can make a super simple menu with Netflix and Youtube, buy a nice touch-screen display and wall mount it in her room.

Well done Asus!

A day with the Tinkerboard, part 2

June 10, 2017 1 comment

Please read the first article here before you continue.

Having gone through a wealth of alternative boards, alternative to the Raspberry PI 3b that is; I have to admit that I am really, really disappointed by the results. Not just with the Tinkerboard but also boards like the ODroid XU4 and the whole fruit-basket of banana, orange and pineapple PI clones.


What a waste

And please keep in mind that I have not been out to discredit anyone. I have been genuinely interested in these alternatives for many reasons, not just emulation or multimedia. I have no problem paying that extra 15£ for a system that delivers twice the power of the PI, in fact I even paid close to 150£ for the UP board. Which is also the only board that so far has delivered on its promise. Microsoft Windows and the horrors of eMMC storage considered.

Part of what I work with these days include node.js and full screen browser views, often touch enabled for POS (point of sale) type machines. This is an exciting field because for the first time in history we can now create rich, responsive and rock solid solutions using off the shelves web technology.

So while emulation of older systems is interesting for hobby purposes, the performance of vital technologies like the browser – and consequently the performance of JavaScript and the underlying JIT compilation, is naturally paramount for what I do.

So I was really looking forward to the extra power these boards advertize. Both CPU, number of cores, extra memory and last but not least – the benefits of a fast GPU. The latter directly impacts the effects we can use in our user-interface. And while effects may seem superficial, its important for touch feedback and the customers experience.


We have all come across touch devices that give little or no visual feedback. We all know what its like when you type something and the UI just hangs while talking with a server. This is why web tech is so important today. In many ways Html5 and websocket is re-defining what we think of as software.

So while I bring little pie-charts and numbers to the table, I do bring honesty and perspective. It’s not all fun and games.

Was it really fair?

It has been voiced by a couple that perhaps my way of testing things is unfair. Like I mentioned in my previous article the PI has a healthy head-start and a rich community that not only consumes and demands, but also contributes substantially to the value of the product. A well established community around a product is worth its weight in gold. The alternative boards have yet to establish that and when it comes to the Tinkerboard, it’s pretty much just getting started.

Secondly, as far as emulation goes, we have to remember that those who make these products rarely have emulation in mind (and probably not Amiga which by any standard is esoteric compared to Nintendo and Sega consoles). If we look at what people use gadgets like the Raspberry PI for, I think products like Kodi, Apache and various DIY programming experiments out-rank all the retro systems combined. And it’s clear that the people behind Tinkerboard is more media oriented than anything else; it ships with hardware support for 4k video playback after all.

Having said that, I do feel I gave both the ODroid and Tinkerboard a fair trial. I did not approach these boards as a developer, but rather as a consumer. I have focused on the experience of familiar things – like using a browser and how well JavaScript runs, does the UI lag under stress; things that any customer will face after purchase.


As far as UAE (Unix Amiga Emulator) there is one thing that might be unfair. Amibian is based around something called UAE4Arm which is a highly optimized version of the Amiga emulator. I would even go so far as to say its THE most optimized UAE version on any platform – Windows and OSX included.

The Amiga was a lot more than just a games machine, it was way ahead of both Windows and OS X for a decade

The Amiga was a lot more than just a games machine, it was way ahead of both Windows and OS X for a decade

Comparing that with FS-UAE is perhaps unfair. FS-UAE is based on the older, non optimized codebase. It’s known for stable emulation and good JIT performance. Sadly the JIT engine only works on x86 and is thus disabled on ARM systems. So to be honest it can’t hold a candle against UAE4Arm. The latter uses lookup tables for everything, fast switch cases instead of long sequences of “if then else” code (easier for the compiler to optimize), and it benefits from hardcore llvm level 3 optimization. So I agree, comparing FS to UAE4Arm is like comparing a tiger with a kitten. It’s not even in the same ballpark.

Optimization on this level is almost a lost art these days. People are used to languages like C# and Java – which are hopelessly bloated (for those that have seen what raw assembler and hand optimized pascal can deliver). On the Amiga we learned how to shave off a clock-cycle here and there – and the end result really made a huge difference.

The same type of low-level, every cycle counts, type optimization is used throughout UAE4Arm. FS-Uae is safe, slow and can hardly deliver A500 speed on a Raspberry PI. Yet UAE4Arm spits out 3.2 times the power of an Amiga 4000 with a 68040 cpu. That was the flagship power machine back in the day, and this little $40 card delivers 3 times the power under emulation.

Its like comparing a muffled 1978 Lada with a pissed off 2017 Lamborghini.

Fair is fair

Having tested just about every distro I could find for the Tinker, even back-tracking to older releases in hope that the drivers there would be better suited for the board (perhaps the new drivers were released in a hurry, or a mistake was made) the last straw really was Android. My hope was that Android could have better drivers since it sees a lot of development. It has giants like Google and Samsung behind it – so the last glimmer of light was that Asus had focused on Android rather than Linux.


Will Android save the say and give the Tinker it’s due credit?

I downloaded the latest image, burnt it and booted – thinking that this should finally put things right. Well it didn’t. Quite the opposite.

The first boot took almost an hour. Yes, an hour. I suspect this is because it did a network restore – downloading packages and requirements from the Internet. But that is still no excuse. I have tried Android on the PI it and it was up and running in less than 10 minutes; and that includes having to set some initial user information.

When the Android desktop finally came into view, it was stripped down with no repository package manager. In other words you would have to manually install packages. But that would have been OK had it not been for the utterly sluggish performance.

Android on the PI is no race-car, but at least it doesn’t freeze and lock-up every five second. Clicking on a link in the browser froze the whole system, and you were asked if you wanted to terminate the process again and again while Android figured out the meaning of life or whatever. Every single time.

I’m sorry but this is the worst experience I have ever had with a board. The ODroid XU4 at least tries to deliver a good experience. I had no problems finding Linux editions that ran well (especially gaming systems, Kodi and some homebrew distros) – and the chrome build for the ODroid gave far better results than both the PI and Tinkerboard. It was not the power-house it had been hyped up to be, but at least it delivered a normal desktop experience (even the PI locks up when facing demanding tasks, but the Tinker has an 8 core cpu, twice the ram and a supposedly superior GPU. With the capacity of running 8 threads and doing task scheduling in batches of 8 – the Tinkerboard should remain both stable and interactive under pressure).

I am sorry but I cannot recommend the Tinkerboard at all. The ODroid gives you a slight edge over the PI and if someone baked a more optimized Linux distro for it (it ships with a variant of Ubuntu) then ODroid XU4  would kick serious ass. But the Tinkerboard is a complete disaster.

Do not waste your money on the Tinkerboard. It may have the hardware but the software to utilize and express that power is simply not there! It has been the most pointless purchase I have done this year.

A common waste

The common denominator between these alternatives is the notion that more power equals more stuff. Which ultimately results in biting over more than they can chew. A distro like Pixel is lightweight, optimized and the PI foundation has spent a considerable amount of time making sure the drivers run as fast as possible.

Weird Science, a fun but completely fictional movie from 1985. I just posted this to liven up an otherwise boring trip down memory lane

Saying it doesnt make it so, except in Weird Science

What these alternative hardware suppliers don’t seem to get is that – what is the point of having a cpu that is twice as fast as the PI, when you waste it on a more demanding version of Linux? Both the ODroid and Tinkerboard ship with Ubuntu clones. And while Ubuntu is wonderful to work with on a high-end x86 machine, 32 gigabytes of ram and a i7 CPU growling away under your desk, it is without a doubt the worst possible OS you could pick for a tiny ARM board.

To put things into perspective: The Tinkerboard has the “theoretical” cpu power of a Samsung Galaxy S4 mobile phone (2012). Yet in their infinite wisdom they decided Ubuntu is what is really going to show off this fart of a device.

It makes absolutely no sense from a consumer’s perspective. As a user you want that extra power for running programs. You want to use the extra power on your stuff. Yet these guys seem to think that wasting all the extra power on infrastructure is going to score points.

So if anyone from the Tinkerboard or ODroid camp reads this, please remember the old saying “If you cannot innovate, emulate”. Make a fast, stable and small Jesse distro like Pixel. Focus on optimization. Compile whatever you can with maximum optimization. Shave off every clock cycle you can. Hand carve the drivers in assembler if that’s what it takes.

Because the sad result is, that right now the Raspberry PI is outperforming you with lesser hardware. There is no point in buying a Tinkerboard because it actually delivers a worse experience. It has bitten off more than it can chew and it’s trying to be something it’s not.

A day with the Tinkerboard, part 1

June 7, 2017 1 comment

Anyone into IOT mini computers, be it as a hobby or professionally – have no doubt heard about the Tinkerboard. The Tinkerboard is an alternative to the Raspberry PI (aren’t they all) produced by hardware giant Asus. Everything from its form-factor (size) to its color coordinated GPIO pins is more or less the same as the PI. What separates the two is that the Tinker gives you double the CPU power, double the ram and pretty much double of everything. If we compare it with the Raspberry PI 3b that is.

But you don’t get double for free. The Tinkerboard retails on Amazon for USD 60 which means something in the ballpark of 55£ for those that live in the UK. For the rest of us that live in far-away places like Norway, prices and taxes may vary.


Before I continue I want to write a few words about pricing. The word “expensive” is one I keep hearing when it comes to the Tinkerboard, but that is extremely unfair considering what you get for your money.

The Raspberry PI 3b is an awesome product and packs a lot of goodies into a credit-card size computer. The same is true for the Tinkerboard, but they have packed even more stuff into the same space! The difference in price is just 15£ – but those 15£ gives you the power to emulate demanding platforms like Nintendo Wii, Sega Dreamcast and Playstation (if you are into retro gaming). Platforms the Raspberry PI 3b dont stand a chance emulating (at least not smoothly).

For serious applications all that extra cpu power can be the difference between success and failure. In many ways the Tinker feels a bit like working on a low-end laptop. If you are building a movie server for your living-room the Tinkerboard will ble able to convert and stream movies much smoother and better than the PI. And if you are looking for a device to power your next kiosk system or POS device, again the extra memory and cpu power is going to make all the difference. And with just 15£ between the two models, I cannot imagine why anyone would pick the PI if gaming or movie streaming is on the menu.

Oh and it has built-in wi-fi and bluetooth support! Here are the specs as listed on Amazon:

  • High performance Quad Core ARM SOC 1.8GHz with 2GB of RAM -The Tinker board features the Rock chip RK3288 Soc with Mali – T764 GPU and 2GB of Dual Channel DDR3 memory
  • Non shared GBit LAN, Shielded Wi-Fi with upgradable antenna support
  • Highly compatible PCB & Topology, Tinker board offer extensive compatibility with SBC accessories & chassis
  • HD Audio & HD & UHD Video Support – Tinker board supports HD audio 192/24bit audio along with accelerated HD & UHD ( 4K ) video playback support* requires use of Rock chip video player in TinkerOS
  • DIY Friendly Design – Tinker board features multiple DIY friendly use features including a color coded GPIO header, silkscreen PCB and color coded pull tabs

That sounds pretty nice doesnt it 🙂

One does not simply take on the mighty PI

Being an alternative to the Raspberry PI is not as easy as it sounds. You would imagine that it all boils down to the specs right? So if you beef up the cpu, ram and gpu everyone will throw away their PI’s and buy your stuff? If only that was true. In which case the Tinkerboard would be awesome since it outperforms the PI on every level.

But it’s not that simple. There is more to a product than just raw power.

One of the cool things about the Raspberry PI is the community. The knowledge base of the product if you like. In order to build a community and be a success, everything has to click. I mean just look at the third-party eco-system that exists around the PI; all those companies selling add-ons and widgets, sensors and remote controls. The PI itself is quite dull. It’s all that extra stuff that makes it so fun to play with. And then you have things like excellent customer service, a forum where people help each other out, well written documentation — the value of the product suddenly exceeds whatever you paid for it to begin with.

And the Tinkerboard is not alone in trying to get a piece of the action. It competes with boards like the ODroid XU4, the x86 based UP boards, Latte Panda, The Pine boards and a whole fruit-basket of banana, orange and whatever PI clones. All of them trying to get a bite of the phenomenon that is the Raspberry PI.

So Asus got their work cut out for them.

First impressions

Having unpacked the board and plugged in all the cables (which is exactly as dull as it sounds) the first thing you do is look for software. Which naturally should be a one-click operation on their website.

Well, the first thing that annoyed me was exactly that: the Asus website. The Tinkerboard is not something that belongs on a sterile, streamlined corporate site. It belongs on website that should be easy to navigate, with plenty of information that hobbyists and “tinkers” need to get started. The Asus website simply lacks the warmth and friendliness of the PI foundation website. I even had to google around a couple of times just to find the disk images. These should be readily available on the site, on the first page even – to make sure customers can get up and running quickly.


It’s a little bit clangy and a little bit jammy

The presentation of the board was ok, but you really shouldnt have to use an external search engine to locate essential data for something you just bought. Unlike the PI foundation, Asus seem to have put little effort into what customers get once they have bought the board. As for community I dont even know if there is one.

When you finally manage to find the bloody download page, these are your options (there are 17 downloads in total, counting older OS images, config files and schematics):

  • TinkerOS 1.8
  • TinkerOS 1.6 Beta (my initial download)
  • Android, also beta

And don’t expect a polished Linux distro like Pixel either. You get a clean distro with some typical stuff pre-loaded (python, perl for some reason, and various tidbits) but nothing close to the quality of Pixel.

Note: Why they would list older beta releases in their downloads is beyond me. It only adds to the confusion of a sterile list of items. And customers who just got their boards will be eager to try it out and hence make a mistake like I did. Beta and unstable releases should be in a separate category, while the stable and up-to-date images are listed first.

The second thing that really irritated me was something as simple as adjusting the keyboard layout and setting the locale. These are simply not present in preferences at all. Once again you have to google around until you find the terminal commands to manually set these things, which utterly defeats booting into a desktop environment to begin with. This might seem trivial for someone who knows Linux well, but to a novice it can take hours. Things this fundamental should be available in preferences or at the very least as a script. Like raspi-config on the PI.

But OK. If we look away from these superficial things and focus on the actual board, things are not half bad.

It’s the insides that counts

The first thing you are going to notice is how much faster the system is compared to the PI. When you start an application on the PI that is demanding, like libre-office or Lazarus, the whole system can freeze-up for a few seconds while the CPU go through the roof. I was pleased to find that this is not the case here (at least not as disruptive). You can start a program and the system continues to be responsive while things load.

What made me furious though was the quality of the graphics drivers. Performance wise the Tinkerboard is twice (actually a bit more) as fast as the PI on all fronts – and the GPU is supposed to deliver a vastly superior graphics experience. Yet when I ran Amibian.js (the Smart Pascal JavaScript desktop system) in Chrome – the CSS hardware effects were painfully slow. I even questioned if GPU was used at all (Note: which I later confirmed was the case, so much for downloading a beta image by mistake). I was amazed at the cpu power of the Tinkerboard because despite having to do everything purely with the CPU (moving pixels in memory, allocating device independent bitmaps, rasterizing layers and complex compositions in X) and it was more than usable.

But it sure as hell was not the superior graphics experience I was hoping for.

I also noticed that when moving a normal desktop window (X window that is) rapidly around the screen, it would lag behind and re-trace your steps until it caught up with the mouse pointer. This was very odd since most composition engines would have eliminated these movements as much as possible – and the GPU would do all the work. Again, I blame the drivers and pondered what could possibly make a GPU perform so badly.


Im supriced it booted at all, nothing is working

So while the system is notably faster than the PI, I get the sense that the drivers and tooling is not really polished. The hardware no doubt got juice but without drivers being carefully written for the board – most of the extra juice you pay for is wasted.

In the end I opened up chrome and typed “chrome://gpu” to see what was going on. And not surprisingly I was correct. It wasnt using the GPU at all and I had wasted hours on something that should have been clearly marked “Lacks hardware acceleration” in bold, italic, underlined big red letters. Like the PI foundation did when they shipped Raspberry PI 2 without GPU drivers. But they promptly delivered and it was ok, because you were informed up front.


Back to scratch

After a trip back to google I downloaded the right (or at least working) image, namely the TinkerOS 1.8 stable. It booted up, resized the partition to fill the whole SD card automatically (and other boring bits).

The first thing I did was start chrome and use the “chrome://gpu” to get some statistics. And thankfully most of the items were now working and active.


Thats better, although i ponder why GPU DIB’s are not active

Emulation, the name of the game

While I have serious tests to perform there is no doubt that what I was most eager to play with was UAE (the Unix Amiga Emulator). Like most retro-heads I have a ton of Raspberry PI’s and ODroid’s around the house with the sole purpose of emulating older game or computer systems. And I think everyone knows that my favorite computer in the whole wide world is the Commodore Amiga.

On the PI, Gunnar’s native Amibian distro gives you awesome performance. If you overclock the ram, gpu and cpu using safe numbers – the PI 3b spits out roughly 3.2 times the power of a Mc68040 based Amiga 4000. In other words 3 times the power of a high-end Amiga from the early 90s. That is quite an achievement for a $40 board. You can only imagine my expectations for a board running more than twice as fast as the PI does (and costing that 15£ more).


Boots fine but you can forget about using it. The PI is 100 times faster than this

One snag though was that UAE4Arm which is the highly optimized version of the Amiga Emulator doesnt exist for the Tinkerboard. In theory it should compile without problems since the latest version uses SDL exclusively. So there is no odd, deprecated UI toolkit like the old UAE4Arm used.

The only thing available was fs-uae. And while that is a very popular emulator on Windows and Mac, it’s sadly not optimized as much as UAE4Arm is. The latter uses lookup tables to the extreme, all if, then, else statements have been replaced by fast switches — and it’s just optimized beyond anything else running on ARM.

The result on the PI in phenomenal, but sadly fs-uae was all I could play with. I will try to compile UAE4Arm on the Tinkerboard later though. But right now im to busy.

Not optimized at all

It is hard to pinpoint exactly where the problem is, but I suspect the older codebase of fs-uae combined with poorly written drivers is what resulted in the absolutely sluggish behavor.

Dont get me wrong, if all you want to do is play some A500 or A1200 games the Tinker is more than capable. But if you want to run the same high-performance desktop as Amibian gives you on the PI – you can pretty much forget it.

I set the system to emulate an A4000, activated the JIT engine and set my desktop to match the display of the desktop. This should run like hell — yet it was slow as a snail. You could literally see the mouse-pointer slowly trying to keep up as I moved it across the desktop.

One interesting thing though. When I ran fs-uae on the first image, the beta image where everything was crap, it actually ran exceptionally well. But here on the so-called stable and “up to date” version, it was useless for anything but clean floppy gaming.

There are many factors involved in this. The drivers sits at the bottom just above the kernel and exposes the hardware so it can be used through a common API. On top of this you have stuff like OpenGL and on top of that again you have SDL which simplifies typical gaming or graphics tasks. This may sound like a long road for code to travel, but it’s actually very fast. If the drivers expose the power of the GPU that is.

I can only conclude at this point that the Tinkerboard has the firepower, I have seen the result of tests performed by others (and tested a retrogaming image) – and you feel the difference almost immediately when you boot the device. But the graphics drivers seems.. crippled somehow. It’s easy to point the finger at Asus and say they have done a terrible job at writing drivers here, but it can also be a bottleneck elsewhere in the system.

This is something Raspberry PI has got so right. Every part of the system has been optimized for the hardware, which makes the PI feel smooth even under a lot of stress. It delegates all the hard graphical stuff to the GPU – and the GPU just deals with it.

Sadly this is not the case with the Tinkerboard so far. And it really is such a shame because the specs speak for themselves.


Next time: We will be giving Android a test and hopefully that will have drivers that are more up to date than whatever we have seen so far..

FMX4Linux is coming, and we cant wait!

May 3, 2017 1 comment

When Embarcadero announced Linux support for their Tokyo release of Delphi, my soul literally left my body for a moment. Could it really be true? After all these years have Embarcadero done what many said would be impossible?

I must admit that people saying something is impossible has lost its sting for me. Over the past 3 years I have one of these impossible things on a weekly basis, yet people are just as shocked every single time. But this time – I was the one in a state of excitement.

As an outspoken (an understatement perhaps) active blogger, my skin has grown thick over the years. I also get to see a lot of cool tech long before it’s commercially available and mainstream – so it takes more for me to be swayed and dazzled. And you grow a healthy instinct for separating bullshit from true technical achievements too.


Delphi Tokyo is probably one of the finest Delphi editions to date

But yes, I admit it – this time Embarcadero surprised me in every positive way imaginable. If you follow my blog you know that I call it as I see it and hold little back. But this was a purely positive experience.

No I know what you are going to say; everyone knew about this right? Yeah me too. But my mind has been elsewhere lately with work and projects, so I didn’t catch the release buzz from the closed forums (well, “closed” is a matter of perspective, I have friends from Russia to the United States, and from china to the Sudan) and for the first time since the Borland days – Embarcadero got the drop on me.

I’m the kind of guy that runs on passion. Delphi, Smart Pascal and even object pascal as a general language is not just work for me – its something I love to use. I relax and enjoy myself when coding. So you can imagine my reaction when my boss sent me a message with “Download Tokyo and give me a report”. It was close to midnight but I was out of that bed faster than bacon on toast, ran into my home office wearing nothing but boxers and a Commodore t-shirt – and threw myself into Embarcadero Developer Network’s download section.

From hero to zero in 2 seconds

I think it was around 07:00 the next morning, one hour before I was due for work that the magic phrase “command line and system services [daemons] only” hit home. And yes I “kinda” knew that before – but maybe, just maybe Embarcadero had thrown in visual applications in the 11th hour. I even had a friendly bet with Jim McKeeth that a FMX UI solution would appear less than 24 hours after release (more about that later).


Now that is a beautiful thing

Either way, it was quite the anti-climax after all that work in VMWare installing Delphi from scratch, waiting, hoping and praying. First of all because I remember watching an in-depth technical review about Firemonkey by David Intersimone a few years back; the one where he describes the Firemonkey architecture in detail. Especially how the abstraction layer between the visual control framework and the actual os made it possible for FMX to quickly adapt to new environments. Firemonkey is a complex and highly adaptable framework, but its biggest strength is paradoxically enough its simplicity. A simplicity achieved through abstracting the UI from the rendering functionality. At least as much as possible, you still have to deal with OS level windowing, security and all of that – so it’s no walk in the park either.

In the presentation (sadly I don’t have a link to this one) David went to great lengths to explain that regardless of operating system, as long as someone implemented a driver class that exposed the set of features FMX needs – Firemonkey would run as long as the compiler supported the instruction set. Visual engines could be DirectX, OpenGL, Cairo or whatever makes sense on that particular platform. As long as the “bridge class” talking with the operating system is there – Firemonkey can run on a toaster if so be.

So Firemonkey has the same abstraction concept that we use in the VJL (Visual JavaScript Component Library) for Smart Pascal (differences not withstanding). If it’s Windows you are running on, DirectX is used; If it’s OS X then Apple’s implementation of OpenGL runs the show – and if you are on Linux you can pick between OpenGL and Cairo. I must admit I havent looked too closely at Cairo, but I know it was designed to make advanced composition and UI rendering more efficient.

Why it Tokyo didn’t ship with visual application support is beyond me, but considering the timing of what happened next, I have made my own conclusions. It doesnt really matter to be honest – the point is we got it and it rocks!

FMX4Linux to the rescue!

Remember the wager I mentioned with Jim McKeeth? It wasnt a serious wager, I just commented and said “a Linux FMX solution will appear within 24hrs, you can bet on it” and added a smiley. I had no idea who or how, I just knew it’s going to turn up.

Because one thing that is a sure bet – it’s that the Delphi community is a group made up of highly resourceful, inventive and clever people. And I was pretty sure that it wouldn’t take many hours before someone came up with a patch or framework to fill the void. And right I was. Less than 24 hours later and it was fact rather than conjecture.


This is just a must have. There is no debate.

So less than 24 hours after Delphi Tokyo hit the shelves. Eugene Kryukov and Alexey Sharagin presented “FMX for Linux”. Giving you both the missing rendering back-end that talks to the system – and some kind of “widget mapping” (as far as I can understand, I wont pretend to know how they did it) that renders your UI according to GTK. So it’s not just a simple “patch”, theme or class that calls a handful of external routines; it’s a full visual implementation of FMX for Linux. Impressive? Oh yeah, and then some!

Let us explore!

Over the next few days I will be giving you an in-depth look at how this system works. I’m also going to test drive Html Components and see if we can get that running under Linux as well. Since FMX for Linux is still in development we have to take height for that – but being able to target Ubuntu is pretty cool! And Remobjects, glorious Remobjects SDK, if that works out of the box I will dance the jig and upload it to YouTube, I swear to cow!


Linux is about to feel the full onslaught of object pascal

There is little doubt what the next Smart Pascal IDE will be based on, and when you combine FMX for Linux, HTML components, Remobjects SDK and TMS into one – you got serious firepower to play with that will give even the most hardened C/C++ QT developer reason to be scared. And that is before the onslaught of Data Abstract and Remobjects C# native compiler.

Oh man next weekend is going to be the best ever!

Let’s not forget ARM targets


The “PI killer” has arrived!

On a second note we will also be looking at the my latest embedded toys – namely the Asus Tinkerboard. I just got two of them in the mail today. Its going to be exciting to see how it fares against the Raspberry PI, ODroid XU4 and the Intel Atom based UP board.

We will also be testing how these two cards can be clustered together using node.js to work as one – and see how that impacts performance for our node.js based Smart Desktop project. These are exciting times indeed!

To make things even more interesting I will be pitching the Tinkerboard against the ODroid XU4 (original version, not the pussy passive save the environment unicorn they push now) against both the x86 UP v1 and Raspberry 3b. Although I think the Raspberry PI is in for the beating of its life when the ODroid and Tinker is overclocked to blood lust mode!


The Smart desktop has a powerful node.js back-end that packs a punch

So, when LLVM optimized JavaScript runs Mc68040 machine-code at 4 times the speed of a high-end Amiga 4000, I will be content.

So let’s do another “that’s impossible” shall we 🙂

Smart Pascal: Arduino and 39 other boards

January 17, 2017 Leave a comment

Did you know that you can use Smart Mobile Studio to write your Arduino controller code? People think they need to dive into C, native Delphi or (shrug) Java to work with controller boards or embedded SoC’s, but fact is – Smart Pascal is easier to set up, cheaper and a hell of lot more productive than C.

Arduino getting you down? Why bother, whip out Smart Pascal and do some mild wrapping and kill 40 birds with one stone

Arduino getting you down? Why bother, whip out Smart Pascal and do some mild wrapping and kill 40 birds with one stone

What may come as a surprice to you though is that Smart allows you to write code for no less than 40 micro-controllers and embedded devices! Yes you read right, 40 different boards from the same codebase.

Johnny number five

jfiveNode.js is the new favorite automation platform in the world of hardware, and board’s both large and small either support JavaScript directly, or at the very least try to be JS friendly. And since Smart Mobile Studio support Node.js very well (and it’s about to get even better support), that should give you some ideas about the advantages here.

The magic library is called Johnny number five (JN5) and it gives you a more or less unified API for working with GPIO and a ton of sensors. And it’s completely free!

As of writing I havent gotten around to writing the wrapper code for JN5, but the library is so clean and well-defined that it’s something that should not take more than a day to port over. You can also take a shortcut via our Typescript importer and use our import tool.

Check out the API here:

Here is a list of the sensors JN5 supports:

  • Altimeter
  • Animation
  • Barometer
  • Button
  • Compass
  • ESC
  • ESCs
  • Expander
  • Fn
  • GPS
  • Gyro
  • Hygrometer
  • IMU
  • IR.Reflect.Array
  • Joystick
  • Keypad
  • LCD
  • Led
  • Led.Digits
  • Led.Matrix
  • Led.RGB
  • Leds
  • Light
  • Motion
  • Motor
  • Motors
  • Multi
  • Piezo
  • Pin
  • Proximity
  • Relay
  • Relays
  • Sensor
  • Servo
  • Servos
  • ShiftRegister
  • Stepper
  • Switch
  • Thermometer

And enjoy one of the many tutorials here:

Smart Pascal, supported server types

December 2, 2016 1 comment

Use node.js to fill your xmas with fun!

Node.js is probably one of the coolest pieces of software I have had the pleasure to work with for years. It’s platform independent and available for just about every operative system you can imagine. I would even go so far as to say it has become universal.

NodeJS allows you not only to write server-side JavaScript, but also your own system level services. This is especially easy on Linux where the philosophy regarding a service is somewhat different from Microsoft Windows. On Linux, a simple bash script can be installed as a service. You can write services in python, perl or whatever tickles your fancy.

Our latest addition: UDP

Today I had a few minutes to test the UDP implementation I finished last week, and I was for some odd reason expecting an exception or “something” to come up. You know.. when something is that easy to write, there’s typically is a catch right? Or maybe im just and old, cynical Delphi developer. Either way, it worked on the first try!

So easy, so powerful and you can deploy it anywhere. An embedded system, a dedicated server - or do a push to your Amazon / Azure cloud stack. Node.js is so powerful once you understand how to use it.

Compiled SMS (node.js) talking with a Delphi application

Now I realize that UDP is not what you use for high-end, reliable communication. But that is beside the point. I want the code you get access to in our next update to be polished, easy to use and something you can rely on. And the keyword here is “co-operation”. My personal service stack that I host in my own home is written in 4 different languages. You have Delphi and C# services running under Windows, you have Lazarus daemons on my Linux box (a full PC) and last but not least — you have Smart Pascal servers running on embedded hardware.

Our list of server types now include:

  • HTTP
  • TCP
  • WebSocket
  • UDP

I use UDP more or less as a signal trigger between processes to handle wait, ready, update and even restart. So by broadcasting a single “shutdown” signal, all my machines will gracefully stop and then power down.

So, how does an UDP server look like? It borders on ridicules how little effort it takes:

procedure TNodeService1.SetupUDPServer;
  Server: TNJUDPServer;

Server := TNJUDPServer.Create;
Server.Port := 1881;
Server.Address := '';
Server.MulticastLoopback := true;
Server.Broadcast := true;
Server.Exclusive:= false;

Server.OnMessage := procedure (Sender: TObject; Data: variant;
          RequestInfo: TNJUDPRequestInfo)
  writeln("Message recieved!");

Server.OnError := procedure (Sender: TObject; ErrorObj: TJsErrorObject)
  writeln("Error:" + ErrorObj.message);

Server.OnClose := procedure (Sender: TObject; ErrorObj: TJsErrorObject)
  writeln("Server closed");

Server.OnAfterServerStarted := procedure (sender: TObject)
  writelnF("Server started, listening on post %d @ %s",
  [Server.port, Server.Address]);

Server.Active := true;

That’s pretty much it. Naturally you have to fill in the blanks, but the above code is all you have to write to create a UDP server. The cool part is that all server classes inherit from a common ancestor, so once you know how to code one – you have a leg up on using the rest of them.

Running the server as a Linux Daemon

Like all languages, node.js has a few tools that are considered standard. It’s like we Delphi developers take component’s and libraries like GR32 and SynEdit for granted. These packages have become so standard that we forget how hard it can be for beginners to get an overview of what’s available.

Turns our node.js is no different, and the tool everyone is using to run their node.js code as a dedicated background service (meaning that it will start during the boot sequence) is called PM2 or node.js process manager v2.

Running your Smart Pascal server as a system-level daemon is very easy once you know what to look for :)

Running your Smart Pascal server as a system-level daemon is very easy once you know what to look for 🙂

In short, PM2 is like a watch-dog that keeps an eye on your service. If it crashed PM2 will re-started it (unless you tell it otherwise), it also does extensive logging for you – and it will even generate a startup script that you can add to the Linux (or windows) startup sequence.

But the most important aspect of PM2 is that you can easily get some “live” info on your services, like how much memory they consume, the CPU consumption and everything else. It’s also PM2 that makes it a snap to run your node.js servers in cluster mode, meaning that you can spread the workload over multiple machines and cores for better performance.

Getting PM2 up and running is easy enough. Just make sure you have installed NPM first, which is the “node package manager” front-end. To install NPM you just write:

sudo apt-get install npm -y

And with NPM available on your system, you install PM2 through NPM (PM2 is ofcourse written in node.js itself):

npm install pm2 -g

Next, having compiled our Smart Pascal project, we copy the file over to a shared folder on our raspberry PI (I installed Samba to make this easier), cd into the folder and type:

pm2 start backend/backend.js --name backend

Notice the “–name backend” part? PM2 allows you to assign names to your code. This makes it easier to manage them (not having to type the full path every single time).

To check if our service is now installed, type:

pm2 show backend

And voila! We have a live Smart Mobile Studio server running on a Raspberry PI 3! Now whip out Delphi and recycle those legacy services!

Build NodeJS from Source

November 17, 2016 Leave a comment
nodeJS rocks!

nodeJS rocks!

Since your Smart Mobile Studio programs can run from Linux under Raspberry PI, I figured I could write a few words about building from C/C++ source. Normally you don’t need to do this, but in case the process-manager (which makes sure your Smart NodeJS servers can be clustered and essentially controlled as services) can be picky about the version – you may suddenly find yourself needing the cutting edge.

Open up a command-line prompt and CD (change dir) to the location you want to keep node. Since this is so essential to my system I keep it at root (/), but you may want to stuff it in your home folder.

Either way, cd to the location then do:

sudo apt-get install build-essential
sudo apt-get install curl openssl libssl-dev

Odds are this is up to date (it was on my fresh Raspbian image). If not, let it finish (you may need to press “y” at some point) and let it work itself out.

You also need to install git (may also already be there):

sudo apt-get install git

With those in place, let’s do a clone of the node.js repository:

git clone

When its finished you should have a “nodejs” folder available. So we cd into that and do a configure:

cd node
sudo make install

Now building anything on the Raspberry PI is slow. So the “make” call will probably take 1.5 hours depending on your PI. If its overclocked you will probably get away with 45 minutes, but a bog standard Raspberry PI 3 is much slower.

When it’s all done, test it with

node --version

As of writing that prints out “8.0.0-pre” since im using the cutting edge pre-release version right now.

Now you can install npm (node package manager) and them pm2 and enjoy the show 🙂

Overclocking the Raspberry PI 3

November 17, 2016 2 comments

On the menu for today was a meeting with my partner in crime, Glenn, who is working hard on the Raspberry PI Linux distro for Smart Mobile Studio – and then do some Linux stuff. For the Smart Pascal headers to actually fit the latest stuff I needed (doh) the latest version of Node to test on. Which has to be built from C/C++ source code on the Arm device.

Building purely from C/C++ source on a PI is .. probably the worst thing I did all day. Cross-compile from your PC instead

Building purely from C/C++ source on a PI is .. probably the worst thing I did all day. Cross-compile from your PC instead

So I baked a fresh copy of Raspbian with the sexy new Pixel UI, updated packages and so on. I set the CPU in performance mode (yes the CPU has different modes) before doing a compile — installed git, cloned out the latest nodejs repository and hit configure + make.

Well, its been 60+ minutes since the bloody build started so I thought, hey why not overclock the sucker and at least shave some off the waiting. But sadly overclocking is not supported by the official Raspbian system settings.

After a bit of google time I found a guy that had gone through the ropes and settled on a sexy 1400 frequency overclock with an over-voltage at around 6. This is stable and the core temp when spawning 4 intense 100% threads (one for each core) is around 58-60 degrees. In other words, well within the specifications (the cpu blows at around 80 degrees and will also kick the bucket at -40).


The dark side of the force is a pathway to many abilities, some considered unnatural

So — you do this at your own risk. Do not attempt this unless you understand the risk. By overclocking you can kiss the warranty good-bye, and I take NO RESPONSEBILITY for whatever damage or loss this could cause. You are on your own when you overclock anything, be it your dishwasher, PC or Raspberry PI embedded boards.

Having said that, the worst that can happen is that you kill your PI. Not exactly a heart breaking loss since they retail at around $35. In most cases when a CPU gets to warm it just shuts down or programs crash. So should that happen let it cool, then use a normal image and leave overclocking alone.

Heat sinks

Yes it may look silly, but if you overclock anything you need to delegate the extra heat somewhere. You can get a heat-sink set for around $1-$3 depending on the vendor. I ordered a couple of sets from Asia at around $2. You get the same kit at RC components for roughly the same price.

Tiny little things with double-sided sticky tape. Works like a charm.

Tiny little things with double-sided sticky tape. Works like a charm.

Ironically it’s not just the CPU that overheat, but also the USB controller and WIFI chip. Thats why a trim-set typically ships with 3 mini heat sinks.

Let there be light!

Boot your PI with a normal raspberry image (and take a backup in case of karma). When you get to the desktop, open a command-prompt and cd all the way back to root (/). Then cd into the boot folder. Inside the boot folder you will find a file called “config.txt”. You need to edit this file with admin rights:

sudo nano config.txt

This opens up nano, a dos like text editor. Just scroll down until you find:

#uncomment to overclock the arm. 700 MHz is the default.

Change that to the following:

#uncomment to overclock the arm. 700 MHz is the default.

hit CTRL+x, when asked if you want to save – hit “y”. The file is now saved and the next time you boot – it should run at 1.45 GHz. Which is quite nice

To reboot, just type


This is the setting that works best for me:

#uncomment to overclock the arm. 700 MHz is the default.

The sdram overclocking might not work at all (did for me though), and some PI’s actually wont run any faster above arm_freq=1300, but mine works fine with the above settings.

From 3 FPS to 7 FPS! We are talking millions of pixels per frame, and going from 3 to 7 FPS is quite a boost!

Click for video!!! From 3 FPS to 7 FPS! We are talking millions of pixels per frame, and going from 3 to 7 FPS is quite a boost!

Also note that if it wont boot, just plug the sd-card into your PC and edit the config.txt there in notepad (the boot folder on the pi is actually a mapping to the windows fat32 partition).

Remember to fit the heat-sinks BEFORE you boot (!)


Since some guy has posted “you dont understand the raspberry PI” in the comment section I just want to respond to that briefly.

Yes, you are partly right, there are aspects of the PI I dont have a clue about. Nor do I pretend to be guru about every piece of tech i come into contact with (that would be a very booring life IMHO). In fact, what I think is exciting about that little machine is that you can tinker and learn as you go – and that even mid-level users like myself can get results.

The JavaScript demo I used to test the clocking is actually a reasonable starting point. At first it was running at roughly 1 fps (due to poor coding, I used timers rather than RequestAnimationFrame to synchronize redraw). By just changing the arm_freq to 1350 this doubled, to a whopping 2 fps.

After i tweaked the memory clock-speed and gpu and set some overvoltage, that in turn went up to a stable 7 fps.

Since this is a per-pixel demo, meaning that it uses the canvas to draw stuff, with a secondary callback cycle applying an alpha clear to give the impression of fading pixels out ( fillrect(0,0,width,height, rgba(0,0,0,0.3)) ) running out of sync — the demo is actually processing millions of bytes per frame.

Just for sake of argument, lets say the chrome window is “1024 x 1024” in 32 bit mode (which is probably a bit small, but lets go with that). We then get:

  • 1024 * 4 (four bytes per 32 bit pixel) = 4096 bytes per scanline
  • 4096 * 1024 = 4,194304 million bytes per frame

There is also a stride offset, but I will ignore that since it probably amounts to about 1kb or less. Right, since we are now drawing 7 frames instead of 3, this gives us:

4 * 4194304 = 16,777216 – a boost of 16.7 million bytes per second


I may not be a Raspberry PI guru, nor would I pretend to be one, but boosting the javascript virtual machine by that magnitude is pretty good. And remember: JavaScript is single threaded. I have yet to see what happens when we use all the cores here.

But I am open for information and would love to hear your take on this. Im sure we can dig down and find out exactly which of my settings had the most impact.

Either way: overclocking and tuning the Raspberry PI 3 for better performance is possible. And that was the only thing on the table here.

Raspberry PI fun

November 1, 2016 2 comments

Just got this box in the mail, now just waiting for a my new touch-screens. Looks like I got the weekend covered.


There was a small LCD screen that came with the kit. I will be putting that in my Amiga 500 retro-mod. Will try to wire it up so that every time i start a game or program – the title of the executable will scroll over the display.

This will involve a fpc compiled signal bridge, but I may be able to do the whole thing in node.js. On the Amiga side of things a task dump running on interrupt should be enough to catch the filename, then broadcast it via UDP on localhost. That way the Linux side of things can pick up the data -and push the text to the display.


Building a kiosk system with Smart Mobile Studio and ARM SoC

October 29, 2016 2 comments
Kiosk systems comes in all shapes and sizes

Kiosk systems comes in all shapes and sizes

Not sure how to define a kiosk system, but it would perhaps be something like “a multimedia driven information booth with user interaction allowed”? Most kiosk systems run your application in full-screen, have a touch capable display(some also have keypad or a full keyboard). Occationally you spot some mouse devices, but that is typically “homebrew”. We can do better.

You really want as little exposed hardware as possible. A mouse just screams “please cut me, cut me now!” to any teenager within miles, and it wouldn’t last an hour at a public library or museum. So touch screens – preferably with a secondary protective layer (an extra plate of thin plastic to protect the screen) is the way to go for public service machines.

Ok, lets look at the demographic for potential customers. This is something you should always do before starting a new (commercial) project. You should also check out the competition and find and angle where you have the advantage, where you can compete. It can sometimes be as simple as good service, better docs or a more friendly user interface. There are a ton of really bad software out there that survives and sells just because their service department does an outstanding job. So don’t limit your thinking to purely technical excellence (like we programmers typically do). Look at it from all angles. Under-do the competition is a catch phrase coined by 37signals in their book Rework (a great book by the way); it simply means: make sure the basic functionality is extremely well made and solid. Focus on the basic functionality rather than playing catch-up with every new “thing” on the market.

Ok, here are some examples of where you would offer your services and sell your kiosk systems:

  • Ticket booths for public offices
  • Ticket booths for pharmacies
  • Information booths for physicians and hospitals
  • City bicycle rental
  • Airport information stalls
  • Museum info booth
  • Library inventory booth
  • Paint color-mixers for hardware stores

I could go on forever, there are thousands of potential customers.


The hardware I am using is the Raspberry PI 3 model b. This is probably one of the most affordable embedded platforms you can buy. And model 3 packs quite a punch to be honest. You could buy one of the clones like the Banana PI (there is also an orange pi or whatever it’s called) and save a buck or two – but seriously: at $35 a pop for the original I would honestly not bother risking it. There are subtle incompatibilities between the clones and the real deal – so you could end up “saving the pennies while wasting the bills” as they say. The way to save money on hardware is to buy in bulk. End of story.

The fantastic Raspberry PI 3

The fantastic Raspberry PI 3

Next, you need a touch screen. The size is naturally only limited by the size of the booth and your budget. For this article series I will be using a small 10″ form-factor. I can recommend a visit to, never had any problems ordering from them. But stay away from Wish and Geek – these websites will lie, steal and sell their own grandmother just to make a buck. I have nothing but bad experienced with them (like never getting what you ordered). So stick with AliExpress or even better RS components.


Touch screens have become ridicules cheap lately

If you have $5 to spare, please buy a remote control. Being able to stop, restart or display an “admin panel” purely by clicking a button on a remote (that only you or your client have access to) will save you so much razzle. You don’t want to mess about with

Besides. Once you know how to code your own set-top-box like I’m showing you now, why not go all out and create your own movie player? Chrome can play pretty much everything out there – and you can get plugins for VLC. Plex eay your heart out!

I have actually had my own NAS running for quite some time now, coded completely in Smart Pascal. And believe you me, its much better than many of the commercial products I see out there. If you are interested in contracting me for projects, contact Quartex Components.

Anyways, what you can do with a remote control is only limited by your imagination. But above all it just looks cool. In fact, buy it because it looks cool and always have sunglasses on when you click the admin button.

This set me back a whopping $4 from!

This set me back a whopping $4 from!

Linux for HTML5?

fullpageosBut now you are thinking: Smart compiles for JavaScript, how the hell are we going to display that full-screen? Do we have to first load the Linux desktop and then manually start a browser?

The answere is: nope!

Our operative system will be a modified version of Debian, one especially tailored for full-screen, HTML5 kiosk displays. And it so happens that there are quite a few such distributions on the market. Most of them completely free as well. JavaScript is after all the leading programming language of our time. As much as 50% of all software being written on this planet right now, is written in JavaScript. We didn’t set out to create Smart Mobile Studio just for the hell of it, but rather because we knew this was going to happen all the way back in 2010. It was inevitable and the factors in the market (and socially) all pointed to the same.

For our Smart Pascal kiosk system we will be using FullPageOS which basically skips the whole desktop thingy and boots directly into Chrome in full-screen. No desktop, no “oh damn the user just minimized the browser window“, just chromium rendering our awesome code directly to the frame-buffer. But you still have Linux ticking away beneath the hood with all the perks and power that represents.

So jump over to Github and download the latest binaries here: FullPageOS. I have also setup a mirror over at Quartex Components. So should for some reason github spontaneously burst into flames, I got you covered!

Next, we will be modifying the distribution slightly. We want to start node.js as a service when the device starts. The easiest way of doing that is to install something called PM2, which also gives you clustering capabilities and drill-down analysis at the same time.

PM2 is node.js equivalent to Microsoft windows service console. It gives you the ability to define if a node.js program should run as a service, if it should be re-started on a crash, logging, distribution – and much more.

We will just be using the automatic restart feature in this tutorial, but I have to tell you, PM2 is a powerful piece of engineering capable of a lot more than that. The most important being that it adds clustering capabilities to your node.js programs if you need it.

If you tell PM2 to run your Smart Pascal server in cluster mode, it will utilize all the cores your CPU has to offer. This is imperative since the JavaScript virtual machine is single threaded, event driven and async by nature.

You can also setup a traditional network cluster, with X number of physical devices dealing with your payload, while a central server act as a dispatcher delegating tasks in good old round-robin style. And the best part? You don’t even have to change a single line of your code to use this. PM2 takes care of everything for you, clustering mode is just a command-line switch. Now that is awesome if you ask me.

PM2 makes clustering and process monitoring a snap. You can even check out the state of your back-end node processes remotely

PM2 makes clustering and process monitoring a snap. You can even check out the state of your back-end node processes remotely via a secondary fancy HTML5 dashboard

You can check out PM2 here: We will be installing that after we have prototyped our server -because during development you want errors to surface so they can be fixed.

Smart Mobile Studio

photoNeedless to say you are not in Kansas any more and Delphi is not really suited for this line of work. Object Pascal and C++ is great for a lot of things, from desktop applications to large-scale eco-systems. But for IOT the full might of Delphi or C++ builder is quite frankly overkill. In this part of the IT forest, python, node.js and bash rule supreme.

So whip out your trusty copy of Smart Mobile Studio and get ready to make those ARM cpu cores purr like a kitten!

The code thing

Since I work on the Smart Pascal RTL, we often have this problem where I blog about or demonstrate code that is not yet publicly available. The reason I blog about new features is naturally to show people what is going on, what they can expect from the next update and so forth.

For this project I will try to avoid non-released features as much as possible so everyone can execute and work with the code. But I will also include code from the new RTL whenever there are no options.

Just keep in mind that any RTL code is copyright. You are not allowed to use it without owning a proper license.

When this tutorial is done you will have a working kiosk system. What media or features you want to deliver is up to you, I’m just here to get you going 🙂

The architecture

Right! With the Linux distribution, node.js and PM2 taken care of, let’s look at the software architecture. What we are going to do is to divide our kiosk system into two parts. Two applications.

  1. A node.js server
    • database access
    • image and media serving
    • filesystem access
  2. A visual smart mobile user interface
    • Menu system
    • User interaction
    • Displaying information
    • Fancy CSS3 effects

Node.js is very different from the browser JSVM. First of all it executes with the same level of access to the filesystem, network, pipes, threading etc. as a normal executable. It basically gives you the same features Freepascal or Delphi would give you. Node.js is not sandboxed like the browser’s JSVM is. There are no restriction on database size, file size or anything like that.

This means that by dividing our application architecture into two parts, we get to enjoy the best of both worlds. We will isolate any low-level stuff in our node.js server (and more importantly: access to the content our booth is going to display). So our visual application needs only care about presenting information and keeping a dialog going with the node.js backend.

By using Chromium as our browser we ensure that the rendering process makes use of the GPU, which is quite important for embedded devices. HTML5 is demanding and rendering it all via the CPU alone would, well, suck.

But our simple architecture allows us to put our application logic in the front-end, and then reduce our node.js backend to a simple command server, almost like a DLL or library. But with perks. Loads of perks.

This model also helps us to abstract the display from changes or updates to the back-end server. The display interface could not care less if you are using sqlite as your database or a $200.000 a month Oracle monster. It doesn’t need to know where the server obtains images, music or files. All it needs to know is the commands and response codes.

It also means we can fragment and do clustering. If you have, say, between 50-100 booths operating on the same network, we could in fact push the node.js server to a dedicated server machine. The clients running on the Raspberry PI wont know the difference. Nor would they care as long as they can connect and get the response they need.


Developing on Windows

Before we start assembling the parts and jousting with Linux, I want to teach you a little trick. When people get a Raspberry PI they tend to do changes to their in the worst possible way: Namely to either use a second USB stick to move files between their PC and the RPI, or (better) install samba so they can copy files over the network.

QEmu makes it a bit easier developing for the PI

QEmu makes it a bit easier developing for the PI

Both solutions are “ok”, but they are time-consuming. And after having copied your Smart Mobile Studio compiled code over for the 78’th time, odds are your frustration level will be through the roof (yes we have all made this mistake at some point).

The trick is to run Raspbian on Windows through qemu. Just like you would run Windows or Linux through VMWare or similar products, you can actually do the same with Raspberry PI (although only model 2b is supported to my knowledge).

You can download the whole system image from Sourceforge here:

Alternatively, I did a mirror of the distribution and you can download that from Quartex Components, right here (but please use Sourceforge first, this link is only for emergencies like if the owner is kidnapped by aliens or moves to Tibet where he intends to live as a goat or something): QuartexHub-Public

Once downloaded, just unzip to whatever location you like.


Just click the "run.bat" file and Raspberry PI will run on your desktop

Could not be simpler to use

Notice the run.bat file? This simply starts qemu for ARM and loads the operative system disk image. The disk image is stored inside the qemu folder, cleverly disguised as:


Here is the full file-list inside the folder. You don’t have to understand or know what this is to use it. Once inside Raspbian you can install Samba (google it, its out of scope for this article to explain) so you can share files between your Windows host and the QEMU Linux installation.

QEmu is not the fastest horse in the stable so to speak, but it's highly flexible and free. So.. La-di-da

QEmu is not the fastest horse in the stable, but it’s super flexible and free!


No I didnt see you playing with your sockets SIR!

No I didnt see you playing with your websockets again SIR!

In the next installment of this article series we will create a websocket server for nodejs and a then use the websocket client in the VJL (the Smart Pascal run-time library) to communicate with it.

We will be sending whole objects over the wire, which sounds very complex and hard, but it’s almost a one-liner under Smart. All JavaScript objects can be serialized to JSON and un-serialized back to an instance on the other side, so this is a piece of cake.

The main job will be to establish a simple, fast, lightweight ASYNC protocol that ensures a snappy and responsive user-interface.

We will also dig into TFileStream which is exclusive for node.js and last but not least, use SQLite for our database needs (Raspberry PI is an embedded system after all, so resources are sparse).

When the coding is done we will perform the required changes to the Linux distribution, hook up the hardware and feel the thrill of having constructed our very own remote-controlled kiosk system!

Your homework assignment is to install node.js on your Windows PC, create a new node.js project in Smart Mobile Studio and look at the API units. You will find the node.js API units under $RTL\NodeJS\ (check links created by our installer in the start-menu program group).

In the next update of Smart Mobile Studio you will have plenty of high-level classes dealing with all that low-level stuff. But getting to know the classes and datastructures node.js expose beneath it all is very useful. It will help you build better node.js servers later on.

Have a good weekend!

The case for Raspberry PI, FPGA and AmigaOS 4.1

September 10, 2016 3 comments

First, thanks for so many good comments on the whole Amiga retro-emulation concepts. I think there is a sort of resurgence today of the whole retro gear thing. On Facebook the Amiga forums and groups are growing, and there is really a sense of community there. Something I havent experienced with the Amiga for well over a decade (or was it two?).

To those that grew up without an Amiga we “old timers” must seem nuts. But that is to be expected by generations growing up with 24/7 internet connections. I’m not dizzing young programmers in any way, absolutely not; but I will make a case that you are missing out on something very valuable in terms of learning and evolving your skill.

“It’s just that it’s based on pre-existing hardware, not an imaginary instruction-set that
assaults the stack while raping the instruction cache”

The term “personal computer” (PC) doesnt really have any meaning today. I see that with my son as well. He has no personal relationship with his computer at all. The computer is a means to an end for him and his friends – a portal if you like, to the reality on the internet. Be it steam, Photoshop express, chatting or whatever. Young coders sort of have a split reality, where their friends online that they have never meet plays a bigger role in their lives than, well, their best friend across the street.

Classic Amiga Workbench

Classic Amiga Workbench running under Amibian

People who grew up without the internet had only their computer to deal with. It was the center of music, demos, games and creativity. Be it coding, graphics, sound or whatever was the interest. The result was naturally that you created bonds to that computer that, to other people, could seem odd or silly. But the phrase “personal computer” is not just a throwback to the time when you no longer needed a campus mainframe or terminal. It also hints to a more personal approach to technology. Which is easy to forget in an age where you switch mobile phones once a year, and the average phone has more computing power than was on the planet in the 1970’s.

Amiga emulation; why it’s a good thing

If we forget the visual aspects of the grey “classical” Amiga OS for a moment and put the looks on the backburner — why on earth should a modern programmer or computing enthusiast even consider Amiga OS? What could a 30-year-old tech bring to a modern world of high-powered CPU and GPU driven monsters?

In a word: efficiency.

AmigaOS thrives with just one megabyte of memory. Stop and think about that for a moment. The core operating system itself resides in a 512kb (half a megabyte) ROM – and the rest fits nicely on a couple of 720kb disks. So if we say that a full desktop experience can fit in 4-5 megabytes (if we include the programs, accessories and extras), what does that tell you?

It should tell you something about how the code is written. But secondly it should tell you about how we write code today (!)

“You think Linux is a fast and efficient operating system? You don’t have a clue”

An average Microsoft Windows installation is what? 16 gigabytes? You can probably trim it down to 8 gigabytes by removing services, graphics and drivers you don’t use. There is also a huge difference in the size of executables and the amount of information stored in the binaries — but ultimately it comes down to a shift in mindset that occurred back in the late 90’s: rather than forcing coders to write efficient programs, the emphasis was placed on the hardware to deliver enough power to run crap and bloated code.

Now being a programmer myself I have no illusions that if AmigaOS, this time the modern and latest 4.x version, was ever re-compiled for x86 it would naturally result in bigger binaries. Depending on the amount of drivers, you would probably end up with at least 512 megabytes to 1 gigabyte of software. Add presentation and media to that and we are quickly breaching the 1.5 to 2 gigabyte boundary. But that in itself would be revolutionary compared to the size of Ubuntu or Windows. Yet the core of the operating system is so small that many young developers find it hard to believe.

And yes I know the Linux kernel and base packages can be squeezed down. But in all honesty, Amiga has much more interesting system. Some of the stuff you can do with shell scripting and Arexx on the Amiga, the lack of cryptic complexity, the ease of use and control you as an end-user had; im sorry but Linux is anything but user-friendly.

Why Raspberry PI

By any modern measure, the Raspberry PI is an embedded board at best, and a toy at worst. It exists there between the cusps of single-function boards and a modern computer. But is it really that bad? Actually, its bloody smashing. It’s just that people havent really been able to run anything written specifically for it yet.

Amibian, a debian based distro that boots straight into UAE (Unix Amiga emulator) and runs classical 16/32 bit Amiga OS, presently performs at 3.2 times the speed if an Amiga 4000\o60. So for $35 you will own the most powerful Amiga ever devised. If you take it one step further and overclock the PI (and add a heat-sink so you don’t burn out the SoC) it emulates the Amiga operating system roughly 4 times the speed of the flagship high-end Amiga of the late 90’s and early 2k’s. You also get 32bit graphics, HDMI output, USB device access through the Linux sub-layer, built-in tcp/ip (and WiFi built-in on the model 3b). And naturally: a hell of a lot more ram than the Amiga even needs (!)

Not exactly technologically impaired

AmigaOS 4, not exactly technologically impaired

Now remember, this is emulated on 68k instruction level (!) It is practically the same as running Java or CLR bytecodes (!) Which is a good parallell. People ask me why i bother with 68k; My reply is: why the hell do you bother with Java bytecodes if you don’t have a clue what a virtual machine is! An emulator is a virtual machine in the true sense of the phrase. It’s just that it’s based on pre-existing hardware, not an imaginary instruction-set that assaults the stack while raping the instruction cache (yeah I’m looking at you Java!).

Imagine then for a second what the situation would be if Amiga OS was compiled for Arm, running natively on the Raspberry PI with direct access to everything. You think Linux is a fast and efficient operating system? You don’t have a clue.

I mean, the PI was initially created to deliver cheap computing power to schools and educational centers, not to mention third-world countries. It made big waves as it blew the ridicules “$100 one PC per child” campagne out of the water (which was more an insult to the poor living in Africa than anything resembling help). Yet at the end of the day – what do these third world countries have to work with? Raspbian and Ubuntu are usable, but only superficially.

Try compiling something on the PI with a modern compiler. What would take less than a second to compile under Amiga OS can take up to 45 minutes to build under Linux on that SoC. If a kid in Africa starts learning C++ with Linux on a PI, he will be 59 years old before he can even apply for a job.

AmigaOS 4 is a sexy desktop

AmigaOS 4 is a sexy desktop

If AmigaOS 4 was ever compiled and setup to match the SoC firmware (which is also a benefit about the PI, the hardware is fixed and very few drivers would have to be made), it would revolutionize computing from the ground up. And I think people would be amazed at just how fast programs can be,when written to be efficient – rather than the onslaught of bloat coming out of Redmond (not to mention Ubuntu which is becoming more and more useless).

The benefit for Hyperion Entertainment, which has done a phenomenal job in upgrading AmigaOS to the modern age, are many:

  • Increased sales of the operating system
  • Sale of merchandize surrounding the AmigaOS brand
  • Sale of SDK and associated development tools
  • The establishment of a codebase for OS 4 that is modern

If we take it one step further and look at what would be the next natural step:

  • Team up with case producers to deliver a more “normal size” case for the PI with keyboard
  • Team up with Cloanto to ship the old ROM files for the built-in 68k emulation layer

The point of all this? To build up money. Enough money for Amiga Inc, Commodore or Hyperion to buy time. Time enough for the codebase to grow and become relevant in the marketplace. Once established, to further sale of a dedicated Amiga HW platform (preferably ARM or X86) and secure the investment the owners have made over the years.

FPGA, the beast of xmas future

FPGA (field programmable gate array) is the future. I don’t care how proud you are of your Intel i7 processor (I have a couple of those myself). Mark my words: 20 years from now you will be blazing behind your FPGA based computer. And I have no doubt that games and applications will adapt the hardware to their needs – with possibilities we can’t even dream about today; let alone define.


Mist. A low-cost FPGA computer capable of becoming an Amiga (and about 10 other platforms). The closest thing to new Amiga hardware to be created in 20 years.

Todays processors are fixed. They have a fixed architecture that is written silicon and copper. Once cooked they cannot be altered in any way. Nanotubes is just about to drop, but again the nature of fixed systems – is that they cannot be altered once cooked.

FPGA however is based on gate logic. Which means (simply put) that the relations that make up the internal architecture is fluid, like a million doors that can be opened or closed to create all manner of living space. In many ways its like a virus, capable of absorbing existing blueprints and becoming “that blueprint”. If we dip into sci-fi for a moment this is the computer variation of a xenomorph, a shape shifter. A creature that can adapt and alter itself to become any other thing.

As of writing this tech is in its infancy. It’s just getting out there and the prices and speed of these spectacular devices bears witness to its age and cost of production. If you want a FPGA with some kick in it, you better be prepared to take out a second mortgage your house.


The Vampire 2 accelerator for Amiga 600. This takes over and gives the Amiga so much power that it can play movies, modern music and 3d games faster than ever imagined. At the same time! In fact, I bought an A600 just to get this!

One of the cool things about this hardware is how it’s being used today. One of the first hardware platforms to be devised for FPGA was (drumroll) the Amiga. And you have to understand that we are not talking just the 68k cpu here – but the whole bloody thing: paula, agnus, deniese, fat agnus and the whole crew of chips that made the Amiga so popular in the first place. All of it coded in gate-logic and uploaded to a cpu that with a flick of a switch can turn right around and become an x86 pc, a PPC Mac, a Commodore 64, a Nintendo 64 or whatever tickles your fancy.

Lets stop and think about this.

Today we use virtual machines to mimic or translate bytecode (or pre-existing cpu instructions). We call these solutions by many names: virtual machine, emulator, runtime – but its all the same really. Even if you slap a JIT (just in time compilation) into the mix, which is the case of both emulators, Java and .NET compilers — it still boils down to running an imaginary (or pre-defined) platform under the umbrella of a fixed piece of kit.

Now what do you think would be the next logical step in that evolution?

The answer is naturally being able to sculpt virtual machines in hardware (read: fixed hardware that gives you a non-fixed field). Fixed processors is a costly process. Yet primitive when we really look at it. We may have shrunk the brilliance of the 1800’s and early 1900’s and made all the great inventions of the past fit on the head of a pin — but its all based on the same stuff: physical implementation. Someone has to sit there with a microscope and hammer the damn circuits out (although “hammer” is maybe the wrong word on particle level).

This is also the problem with western culture: the use and throw away mentality that creates mountains of technological garbage – and powers child labour and sickness beyond belief in poor parts of the world. You have six years old kids that work with melting out copper and quicksilver. A waste of life, tech and nature. So yeah, a bit of morality in this as well.

FPGA represents, really, the first actual breakthrough and paradigm shift since the invention of the first electric circuit. For the first time in history a medium has been created that is not fixed. It has to be created of course, and it’s not like its wet-wire technology or anything — but for the first time anyone with the skill to code the gates, can shape and adapt the hardware without the need to cook the chips first.

And they can be infinitely re-used, which is good for both people and nature.

Think about it.. then go “holy cow”.

And that my friend – is the thought of the day!


Smart Pascal, Pastafari PI, Amiga and all

September 9, 2016 Leave a comment

Hectic days so I dont have as much time to blog as I used to. Also found a new interest in electronics (total newbie, but i love it) so I jump from one thing to the next.

NodeJS, assembly and virtual machine

Whenever I have time I try to work as much on Smart Mobile Studio as I can. I keep working at a steady pace on the RTL.

At the same time I am also making headway on the assembler written in Smart Pascal. It is quite important for some of the future plans, and to be perfectly honest – it’s pretty cool! Basically I have mixed classic Acorn, MC68030 and x86 assembly language, adapted it to JavaScript (so no pointers, only references and offsets). The instruction set is fairly standard:

Unlike Java or CLR, this one is register oriented. One of the major weaknesses of Java is how it pushes everything on the stack, making calls slower than it has to be.

  • 32 data agnostic cpu registers
  • stack and frame
  • Program counter (PC)
  • Variable management
  • Inline constants
  • Asm compiles to codesegment assembly format
    • Support for const resource chunk
    • Instance frame oriented

The instruction set thus far is very fundamental. It contains instructions you will find on any processor (more or less).


Parameters always start with the destination (destination, source). Most instructions support all 3 modus operandi (register, constant or resource identifier and inline data).

Inline data instructs the cpu to read a data segment directly following the instruction. For example, this is a perfectly valid assembly snippet:

  LDD R0, "This is a string "
  MOV R1, R0
  ADD R0, R1
  ; r0 now contains "This is a string This is a string"

You can however put that string (which is a constant) into the resource chunk of the bytecode format. Then you can reference it by id:

  ; here presuming the string has the id $200
  LDC R0, C[$200]
  MOV R1, R0
  ADD R0, R1
  ; Same result as above
  • Alloc [identifier]
  • Free [identifier]
  • LD.C [register], [resource id]
  • LD.V [register], [variable id]
  • LD.D [register], [inline data]
  • PSH.C [resource id]
  • PSH.R [register]
  • PSH.D [inline data]
  • POP.R [register]
  • POP.V [variable id]
  • MOV.R [register], [register]
  • MOV.V [variable id], [register]
  • MOV.D [variable id], [inline data]
  • ADD.C [register], [resource id]
  • ADD.V [register], [variable id]
  • ADD.D [register], [inline data]
  • SUB.C [register], [resource id]
  • SUB.V [register], [variable id]
  • SUB.D [register], [inline data]
  • JSL [offset]
  • JSE [register], [offset]
  • BNE [offset]
  • BEQ [offset]
  • RTS
  • NOOP
  • CMP.C [register], [resource id]
  • CMP.V [register], [variable id]
  • CMP.D [register], [inline data]
  • MUL.R [register], [register]
  • MUL.C [register], [resource id]
  • MUL.D [register], [inline data]
  • DIV.R [register], [register]
  • DIV.C [register], [resource id]
  • DIV.D [register], [inline data]
  • AND.R [register], [register]
  • AND.C [register], [resource id]
  • AND.D [register], [inline data]
  • OR.R [register], [register]
  • OR.C [register], [resource id]
  • OR.D [register], [inline data]
  • NOT.R [register], [register]
  • NOT.C [register], [resource id]
  • NOT.D [register], [inline data]
  • MULDIV.R [register], [register]
  • MULDIV.C [register], [resource id]
  • MULDIV.D [register], [inline data]
  • XOR.R [register], [register]
  • XOR.C [register], [resource id]
  • XOR.D [register], [inline data]
  • LSR.R [register], [register]
  • LSR.C [register], [resource id]
  • LSR.D [register], [inline data]
  • LSL.R [register], [register]
  • LSL.C [register], [resource id]
  • LSL.D [register], [inline data]
  • MOD.R [register], [register]
  • MOD.C [register], [resource id]
  • MOD.D [register], [inline data]
  • SYSCALL [method id]

The second half is the disassembler – and naturally the most important: namely the CPU or virtual machine. Like the disassembler this decodes the instruction bits and executes each instruction accordingly. At high speeds i might add.

So, what on earth is that good for you ask? Well, I have written it in a way that makes it easy to port it to Delphi and Freepascal. So if you are into creating programming languages, game engines, portable services, emulators or whatnot — then this is a very handy piece of tech.

Once you have a working virtual-machine, you can build the high-level language on top of that. And the fact that its portable and you can execute the code inside your Smart Mobile Studio applications, your NodeJS services — or Windows, Linux and OS X (as long as freepascal is there, you are good), that opens up for some interesting ideas.

Pastafari PI

Those that read my blog know that I absolutely love retro machines. Atari, Commodore 64, Amiga, Acorn — I love them all. I grew up with Zx81, Speccy, C64 and Amiga – so naturally I have so many fun memories with these systems that it’s bound to influence me as an adult.

Now I had a broken Amiga 500 in the basement, and I figured — why fork out $200+ for a PITop or some other solution when I can actually do a retro-mod myself.

After all, distros like Amibian (debian based linux) boot straight into the emulated Amiga environment. And the speed is phenomenal! The PI 3 emulates the Amiga 3.2 times faster than the most high-end Amiga ever created. With overclocking we are looking at speeds up to 4 times faster than a juiced up Amiga 4000\ 060 (!)


Well, it’s not finished yet, but I have basically cut the case and made room for a fancy ADX gaming keyboard with sexy led lighting. I had to solder the keyboard controller to make it fit onto the Amiga keyboard back-plate – and also cut the keyboard quite heavily.


The idea is that when I have all the internals working – i will do a lot of epoxy and plastic work to make it look more authentic. Right now it looks very rough and rugged, but it runs like a dream!

I also bought a cheap 2.5″ multi sd-card reader. That came with an internal USB motherboard socket sadly — so I had to cut and do some soldering to make it into a normal external USB connector. And now it just plugs into the PI.


I also adapted the floppy-drive input on the side of the Amiga, so the SD-card reader now sits in place where the original 2.5″ floppydrive once lived.

I’m just waiting for the sd-card extender circuit so i can adapt the front of the Amiga and have the SD-card slot for the PI there. This will make it a snap to change sd-card whenever I want to use another operating system. Im also soldering up a reset and shutdown switch that will also be on the front (that thin region just above the keyboard).


To experienced technicians this no doubt look like a complete mess – but this is my first ever electronic “hands-on” project. I havent touched a soldering pen since highschool, so it was nerve-wreaking digging into the keyboard controller.


Enjoying some Pastafari PI computing – tremble before his noodly appendages!

The final step is naturally to do some plastic work. I bought a good dose of epoxy for this. Once that is done I have to sand everything down and make the cuts straight and better looking.

And then finally I can give it two coats of black spray paint, and that final coat of transparent paint for hardening. And voila — I’ll have a pretty cool rig to test and work with my Raspberry PI 3!

Smart Raspberry PI project

October 31, 2015 7 comments

Raspberry PI is a great little $35 mini computer the size of a credit card. The latest version (2.0) comes with 1 gigabyte of ram and a mid-range powerful ARM processor. Raspberry PI is used by hobbyists, schools and IOT companies to create clever consumer gadgets. The sky is the limit and what you can do with your PI is defined by imagination only (and I admit, some knowledge of Linux).

What our custom Linux distro brings, is a ready-to-use kiosk system

Smart Mobile Studio full control Raspberry PI

My good friend Glenn, a citizen of Denmark, loves all things Linux – so when I asked him if we could hijack the boot sequence, drop the desktop and boot straight into full-screen Chrome instead.. well, it didn’t take long for him to figure out a way to do that. I have to little experience with the mysteries of Linux to make that happen (it would take weeks of fiddling), so it’s good to have friends who know’s what they are doing.

A fully working desktop environment

A fully working desktop environment, took Glenn and myself 15 minutes to make

In essence we are creating a custom Linux distro which is designed to run your Smart Mobile Studio projects exclusively. This means:

  • full access to the filesystem
  • no content domain restrictions (CORS)
  • no blocking-operation restraints
  • No restriction on database or storage sizes
  • Your Smart program completely runs the show

As a gateway to the operative system and interesting functionality, I have gone for a nodeJS server running in the background (booted before the browser display) which means the desktop (or your project) can use RPC calls for advanced functions.

This is pretty cool because it means that the UI will be completely abstracted from the service functionality. The service can be local and run on the same installation – or it can run on Azure or Amazon cloud servers on the other side of the world.

Think of it this way: You dont have to run it on the same device. You can upload your desktop (or kiosk) to a normal web-host, disable CORS on the host, and then use websockets and connect to the NodeJS layer; which can be hosted on another computer or domain.

But all of that is already possible today. This is one of the simplest things to make with Smart Mobile Studio actually. A much cooler project is what we are doing now with the Raspberry PI — giving your creations the ability to live on and control a full Linux system.

So what are you guys up to?

The first project is a NetFlix like media system (or a XBMC clone) with full support for USB wireless remote controls. To make it short: a $35 home theatre that plugs into your television, which will scan your movies folder (or external drive) and present your movies like NetFlix does it. It will download info from and other media services for identification. It sounds complicated but it’s actually very straight forward. One of the simplest solutions I’ve done with Smart Mobile Studio to be honest.

Using a standard USB remote control is excellent because it registers as a touch-device. So the buttons you press registers as touch-events in a predictable order (read: it works on all controls of this type).

What our custom Linux distro brings, is a ready-to-use kiosk system. You can use it to display advertizing in a shop window if you like, or add a touch screen and build your own ticket ordering station. Again, it’s only limited by your own imagination.

A JavaScript cloud desktop

Depending on the success of the project we may go full-out and create the world’s first JavaScript desktop. It is essentially Debian + Chrome + Smart Mobile Studio. This would require a bit more NodeJS magic, where each exposed node service (RPC) represents a distinct part of the “operative system”. A virtual operative system running on top of a Linux stub. Pretty darn cool if you ask me. Who knows, maybe we can define POSIX for the cloud?

A fun hobby to say the least 🙂

Smart Mobile ‘retrogaming’ cloud services

April 19, 2015 1 comment

Im getting older. It’s with shock I have reached the age of 41 (!) In my sons eyes I am already the proverbial dinosaur. But in my own mind it was only yesterday I ran around with my friends, Amiga in nap-sack, on the way to some copy-party or gathering of Amiga enthusiasts, coders and gamers.

Sexy, compact and extremely fast! Amiga OS

Sexy, compact and extremely fast! Amiga

You may be wondering what all of this has to do with Smart Mobile Studio, cloud computing and object pascal. The answer is: everything. Because the Amiga computer was the machine which started all of this. In fact every project I have loved working on my entire life began on the Amiga. The reason I now live as a programmer is because of the Amiga. The reason I became who I am and live where I live, is because of the Amiga. And the reason I work where I do, and know what I know – is yet again because of the Amiga.

Trying to emphasis the impact the Amiga has had on hundreds of thousands of kids during the 80’s and 90’s is almost impossible. It’s like trying to explain the impact the moon landing had, or the cold war (we share a border with Russia, so that was fun). To be blunt: The Amiga has shaped my life more than any other person, education or “thing”.

The IOT phenomenon is about to emerge, so if you wanted a wink that a revolution is about to happen — this is it. Your chance to capitalize and make money is NOW.

Sadly I was to young to realize any of my ideas back then, and the hardware was not even close to deliver them. This is why the death of Amiga was so heartbreaking to a whole generation. Because the Amiga was the platform that gave us everything, yet it was cut down in it’s prime due to sloppy, greedy and outright insane management decisions. The entire IT market and reality of computing for the entire world would have looked very different had the Amiga realized it’s potential. Windows and OS X has only recently managed to catch up with the Amiga operative system. And we are talking about a machine which went out of production 20 years ago (!). It was way beyond anything Microsoft or Apple cooked up in their labs. We enjoyed a responsive and fast multitasking desktop, high-speed games and graphics and fantastic soundtracks – 15 years before the PC (fifteen years! That’s a whole “growing up” phase).

The amiga also had VR equipment more than 18 years ago. So yeah, it was a personal disaster for a whole generation when Commodore went bankrupt. It pushed computing back to the stone age. Could you imagine having to throw away your modern computer and be forced to buy a 15 year old piece of shit instead? Being told by people who know jack shit about the mac or pc you own today, that their old shabby system is better — when you in fact have tried future technology and used it for years, knowing full well that what they say is not true? Well, that was our experience. Having to pay money to get a 486 after having lived with an Amiga 1200/68040 CPU for years was just insane. It was like trading in your iPhone for a 1996 Nokia, or your Tessla car for a 1980 Fiat.

So indeed; we had so much more than kids today have. The experience of connecting your modem up to your dad’s phone, connecting to a BBS on the other side of the world, logging in and talking to people, swapping games, documents and whatnot — take a close look at the underlying technology there and what you see is the seed of cloud-computing.

A BBS functioned as a file-sharing service. So when you connected to the BBS, the files, games etc. you placed in the public folder was immediately shared with the others. And they all went through the server first, which typically picked up whole files first.

The Amiga was a lot more than just a games machine, it was way  ahead of both Windows and OS X for a decade

The Amiga was a lot more than just a games machine, it was way ahead of both Windows and OS X for roughly 15 years. So for 15 years we had a full multitasking desktop.

Now, going from that – to a reality of mainframes, thin clients, abstracted filesystems and remote data storage (or even better: dispersed data storage, where chunks of data can be stored anywhere on the planet and re-assembed when you need it) — all of this saw the light of day on the Amiga. In fact the second webbrowser ever written (the first was naturally on a unix machine) was written on the Amiga.

A fully working US produced Amiga 500, re-built and fixed by me this weekend. It took 2 days to get it working, but it's worth it!

A fully working US produced Amiga 500, re-built and fixed by me this weekend. It took 2 days to get it working, but it’s worth it!

But for me personally: did you know that the first programming language I wrote was called “concept basic”? It was written in assembler and blitzbasic on the Amiga. So the idea of programming languages, delivering a fun system that people love — it comes directly from my Amiga days. I would never have created Smart Mobile Studio or connected with the other people of the team had I never owned an Amiga.

Blitzbasic and Amos

Have you ever thought about the people who inspired your childhood? Not your mother and father, but all those people who – behind the scenes, did something which had a huge impact on your life? I have thought about that many times. And I believe hundreds and thousands of teenagers back then was touched by two titles especially, written by two near iconic Amiga personalities.

The first is Marc Sibly who gave us BlitzBasic, which was on the Amiga the closest thing to Turbo Pascal or low-level Delphi as you could get. You could write assembler side-by-side with fast basic, and the compiler gave you a single executable which ran at extreme speeds. Even die-hard assembler coders took their hat of to Marc for his invention.

Games like Worms and Lemmings were coded in BlitzBasic  2

Games like Worms and Lemmings were coded in BlitzBasic 2

The other title which enabled a world of children to learn programming and be creative, is Francois Lionet. I have been fortunate enough to talk with him online, where I also expressed my gratitude for Amos Basic. It’s really sad that so few Amiga users have done this, because both Francois and Marc deserves to be recognized.

Amos basic was the multimedia basic par excellence

Amos basic was the multimedia basic par excellence

Thanks to these two people and programming tools – hundreds of thousands of kids became professional programmers.

I cannot express enough just how fun it was to grow up with BlitzBasic and Amos basic. Every day before I went to school I would spend an hour coding. Slowly learning trick by trick. Without the inspiration of these two IDE and compilers, I have no idea what I would be working as right now. But I doubt I would be as happy as I am, or have such a rich intellectual life as I enjoy.

Smart Mobile Studio

What I really want is to re-create that feeling for others. I want people to start Smart Mobile Studio and feel that they can make anything. Be it games, mobile applications or cloud services. I realize of-course that the majority of people using Smart are grown men, but with the student program and a few plans we have — odds are we will be able to reach teenagers who want to master programming. Just like Marc and Francois did for us.

Early variation of Smart Mobile Studio

Early variation of Smart Mobile Studio

So that is a huge driving force in what I do and my work in programming language research

Raspberry PI

What is a cloud? Well it’s not just storage. Even though that is the first service people think about. So dropbox is not really a cloud service just because it allows seamless backup and re-distribution of data. But it is indeed one of the services cloud delivers.

No, what cloud is – is a very, very old idea. The idea that you log into a huge system, allocate computer time (just like on star-trek) and then work on your task is ancient. It goes back even before the Amiga to the huge IBM mainframes of the fifties, sixties and seventies.

The commodore mainframe, an ancient idea

The commodore mainframe, an ancient idea

The fun part is that a single $35 Raspberry PI 2 contains more computing power than the entire US government combined in the nineteen sixties. Just think about that for a moment.

But it should also mean that we have something to learn here, or an opportunity to explore and do things our parents never even dreamed about.

And this is where the Raspberry PI cloud system comes in. I have been coding this for a while now, and it still requires work, but when it’s done – you will be able to run your very own cloud using a single or multiple Raspberry PI’s. An the pricetag? For a measily $140 you can now own a 16 core cloud setup. Perfect for writing cloud software, which (let’s face it) the world is heading.

Smart Cloud

Cloud storage, coming to a smart RTL near you in the future

Cloud storage, coming to a smart RTL near you in the future

So what exactly is this cloud thing? Well, in short it allows you to install cloud resident applications. Meaning applications which live in the cloud, store data in the cloud, and which conforms to the laws of the cloud reality.

This means that you will be able to develop, test, maintain and deploy your own cloud solutions directly on your own mini-cluster at home. When your service is complete, tested and validated — you simply upload the whole system (a zip file) to Amazon or Azure. Now your system is “live” and can be reached by millions of potential customers though mobile phones, pads, smart-tv’s, tabs and computers of any size and form.

The IOT phenomenon is about to emerge, so if you wanted a wink that a revolution is about to happen — this is it. Your chance to capitalize and make money is NOW. If you wait a year, the window will be lost and you will have to wait for the “next big thing”.

Retro computing taken to the extreme

The first service I am going to make, besides the professional tools you need to write kick-ass cloud software, is the ultimate retro gaming platform in the universe. You may have heard of RetroPI, WinUAE and all those emulators which plays Nintendo, Amiga, Playstation and Mame games (NEO GEO) ? Imagine running all of these on a cluster.

Thousands of classical titles at your fingertips

Thousands of classical titles at your fingertips

Imagine being able to easily upload and download games via our Smart Mobile Studio nodeJS services (which you will get when you buy it, to run in your own home). And imagine (drumroll) being able to start and play those games from anywhere in the world. All you need is a browser, and the emulated screen will be transported to the browser in real-time.

With your cluster running at home, you can be in any hotel in the world and access thousands of games, movies and music. And the good part? It’s all written in Smart Mobile Studio, using the SmartSDI daemon interface (daemon is the same as service on linux).

Look out! 1990 is about to hit your system, like a ton of PI's

Look out! 1990 is about to hit your system, like a ton of PI’s

Sounds hard? Well not really. The cool thing about X, the windowing manager on Linux, is the idea of remote desktop session. So connecting and getting the desktop pixels is there from scratch. The rest is pure RPC service architecture, a handfull of scripts – and cluster software, allowing you to make use of all 16 ARM cores for tasks.

Well, stay tuned!

Smart Mobile Studio nodejs hardware platform

April 18, 2015 Leave a comment

I am proud to announce that my research into nodeJS and inexpensive hardware has resulted in the Smart Mobile Studio server platform, which is an inexpensive but highly usable linux setup designed to run on the Raspberry PI model B.

When the system is ready you will be able to download a Linux disk-image from for use with your own Raspberry PI 2. I am also talking to a Norwegian supplier about selling ready-to-use Raspberry PI 2’s with SmartSDI (Smart Software Distribution interface).

Working with SmartSDI

SmartSDI is a Linux executable written in FreePascal which simplifies moving files between the Raspberry PI and your Windows machine. The system can interface with Smart Mobile Studio directly, meaning that when the IDE obtains support for SmartSDI, it can automatically transport the compiled files to the Raspberry PI, install it into the nodeJS service stack — and you can test the application directly: either through your browser, your mobile phone or iPad/tablet.

It also makes it a snap to write your client applications, because once the server has been installed though SmartSDI, the client can connect and talk to it using the same interfaces as Amazon and Azure cloud services.

SmartSDI is also a lot more. It allows you to write, test and work closely with your Smart nodeJS services. Doing this on a dedicated “mini-computer” before you deploy to the cloud can mean the difference between success and failure.

The Raspberry PI2 image comes complete with nodeJS, mySQL and a host of typical nodeJS libraries and extensions. The goal is to provide you with an inexpensive, fully functional and convenient run-time environment for your cloud software.

The hardware runs on 5v only, which makes it suitable for 24/7 operation. It’s extremely cost effective at $35. Making Smart Mobile Studio the least expensive development platform for it’s gentre in the world. Embarcadero is 100 times more expensive for mobile and cloud work, and you get nothing we dont deliver. Even if you bought a 10 piece nodeJS cluster you would still have $2000 to spare.

The question should be — is Delphi 100 times better at modern mobile development?

From idea to production

With this platform, Smart Mobile Studio delivers a complete development path – from your idea to the finished product. The cloud based mobile application model can seem alien to many Delphi programmers, but it’s actually involves less work and more fun than native programming.

The cloud platform is likewise inexpensive, easy to use and easy to deploy to once understand it.

But stress testing your services, throwing deliberate exceptions and problems — which is the only way to be sure your program can deal with real-life problems, is expensive and time-consuming if done straight on the cloud node or your local PC.

This is where SmartSDI comes in. It comes with everything ready and working. Want to use mySQL in your cloud solution? Just use a mySQL editor and connect to the Raspberry PI to create your database. Now go back into Smart Mobile Studio and start using the mySQL drivers to talk with it.

When it all works as expected, your cloud solution is ready for deployment! A wizard will help you through the steps of uploading your cloud solution to your service provider (Amazon, Azure) and it’s up and running in minutes (!)

With the server in place, you package your client application with phonegap, and voila — you are ready for the marketplace! With Android, iOS, Blackberry and Microsoft mobile support ready to rock!

Node-Sega, this is cool!

April 14, 2015 Leave a comment

It was in the year of our lord 2015, when a norwegian brilliant scientist, dirsturbingly norwegian, but brilliant non the less – came to create the most awesome nodeJS server the world had ever seen.

And he putteth not one, ney, nor two, ney, nor three, ney — but four Raspberry PIes which he ordereth from the gloomy land called brittania through fed-ex, or fed-up or whatever the lord callest them sad men in browish cars delvering goods.


What do you get when you marry Raspberry PI (four of them), a Sega MegaDrive II, nodeJS and a whole afternoon of free time? Well if you are around me you will get the all singing, all spanking – Node-Sega MegaJS (ta-da!).

Ok serious: I ordered a Sega MegaDrive II from AliExpress, which ships good from China. I didnt expect much from this product because, let’s face it – they do sell a lot of rubbish on that website; but since the verison II of the megadrive never came out up here in Norway — what did I have to loose? It cost something like $30 or so – with shipping (!)

Daddy's new toy -- it goes with the 16 other collectables I own

Daddy’s new toy — it goes with the 16 other collectables I own

Well, I get the sucker delivered and the first thing I find is a maelformed power socket. And to make it even more interesting its a 9 volt adapter. Not 6, not 8 or 12 – something normal that you may have around the house. Nope, a nine volt adapter.

I open the damn thing up and check, and the motherboard actually runs on 5 — which I just happen to have a ton of. So a quick modding and it’ working. Sort of. For 3 seconds until it goes up in smoke. They really dont make’em like they used to! I remember my US produced Amiga computer. I spilled coke over it, fall off a motorbike with it in my backpack, i even jumped into a pool once with my Amiga in the napsack — it didnt even glitch. You could set the bloody thing on fire and it would still boot up.

Wow, they really polled out all the stops for this one. $0.30 in parts?

Wow, they really polled out all the stops for this one. $0.30 in parts?

Old box, new tricks

So with a freshly “burnt out” Sega Megadrive at my disposal, what should a man do? But build a Raspberry PI cluster containing: Mame arcade game emulator, NodeJS web server interface for uploading and downloading MAME Roms. A dedicated PI for database work and a fallback server so nodeJS can spawn threads on a secondary machine.

So my trusty old, very new Sega megadrive will not end it’s days on the skip having come here all the way from china — instead it is being transformed into a supe sega! When sega machines talk about heroes they will whisper the name of the super-sega who went to Norway to become a most powerful sega in the universe. Mohahahaha…

Alas, this GPU is no more of use.. oh the horror

Alas, this GPU is no more of use.. oh the horror

Now to squeeze in 4 of these babies!

Now to squeeze in 4 of these babies!

I guess I dont need to tell you where this is heading right? I must admit it’s going to be so fun to do this mod. I can just imagine the face of my boss when he asks me to bring my nodeJS monster to work. And I bring a Sega megadrive, hook it into the network and watch everything light up 🙂

Still, it does need some work. There is a height difference I need to fix, also need two types of switches (reset and movable), a HDMI extender (short) a power-led extender and splitter. A USB splitter (it will have 16 USB ports!).

Now that’s a megadrive!

And what should we call this freepascal and Smart Mobile Studio powered cluster? Why Sonic ofcourse!

Sonic clustering

Sonic clustering

Why is the seganodeJS megadrive so sexy?

The megadrive chassis is just the perfect size to do a avant-garde mod using Raspberry PI. First of all because it has plenty of room, but also because of height and the position of power-in and video/sound-out match our goals — well, perfectly!

It turns out the HDMI-out and power-in socket on the RPI fits neatly. This means that you will have power-in and HDMI out exactly where similar sockets used to be. This is a fingertip-rule when doing mod’s. Always, always try to retro-fit new sockets and parts where the older versions were. It will save you so much time and headache later.

To demonstrate just how much space the Sega chassis gives us, consider this fab setup I have in mind:

4. diasy-chained Raspberry PI 2B
2. Re-chargable power banks
1. Terrabyte slim 2.5″ USB 3.0 storage
1. USB splitter (1 to 6) which will be exposed in the cartridge bay-door
1. Fully working reset button, safe shutdown due to power-banks
1. Fullt working shutdown (hard) button
1. 5v internal fan
4. mico-heat sinks to keep the CPU’s fresh
Assorted cables

You would never, ever get anything like this into a PSX1 or psx2. You would have to gut open your XBox 360 or something, because the PSX is utterly dominated by the CD-ROM and blueray “brick” inside.

Another thing: If you decide to place the first PI right at the back and re-cycle the old power-input holes, you are lining yourself up for a neat gadget, because: one of the cooler things about the RPI is that it’s perfectly happy getting it’s power from a USB connection. And since the RPI comes with 4 USB ports, thats 3 ports to power the other RPI’s with one spare port.

And you use that spare port with a USB splitter which gives you six USB 2.0 ports in return.
This gives you 6 + 9 = 16 fully functional USB ports available to your cluster (!)

Software setup

Since the RPI has become so famous around the world, plenty of software can be downloaded for it. This includes cluster software, home-cloud solutions and whatever you can imagine. But for my solution you dont really need that much.

The vanilla Noobs setup with Raspdebian is more than ok. Because the only thing you are going to do is to pick one of them to be head-honcho. And this linux box PI should provide the following:

  • DNS service
  • Firewall service
  • Internet provider for the other machine
  • Shared HW resources (e.g “printer”, “keyboard” etc)
  • 6 extended USB ports are shared out from this unit
  • Desktop service
  • Freepascal
  • NodeJS
  • Mame
  • Remote desktop access

What you want to do here is to first setup the linux system so that it works, then and only then do you install MAME with a boot menu — that way when you fire it up the system will boot into a menu of games, and you can use your joystick ($10 gamepad, sega lookalike on amazon) to scroll around and pick a game.

But, you also want to be able to access linux. So pressing ESC on a BT device or physically connected keyboard should break you out of the MAME cycle and boot X as normal.

The second machine

The second machine is the actual nodeJS server where you will be running most of your programs. A linux system can have a maximum of 1024 sockets in read/write mode at any given point (but thousands of allocated sockets waiting) so you want to dedicate a full RPI for this task.

  • Standard Raspbean install
  • Remote desktop access
  • NodeJS
  • network name “http”

The third machine is the boring RPI, namely the database. The setup is pretty much the same as the server, except this one should have mySQL running.

  • Standard Raspbean install
  • Remote desktop access
  • MySQL
  • network name “DATA”

The last and final machine is more popular, it’s the storage manager for the entire system. This machine will have all it’s USB ports used and connected to storage, which it shares openly with it’s own network. Since the network doesnt extent beyond the DNS and firewall, it’s all good for our little cluster.

You can also install samba and use it as a backup target for time-machine if you own a mac, or a backup target if you work exclusively with windows. So your Sega Raspberry nodeJS drive can become your most priced possession 🙂

Well — thats it for me today! I have a SEGA to assemble 🙂

Get Smart Mobile Studio for 1 year

April 11, 2015 2 comments
Know Delphi or FPC? Then sign up now!

Know Delphi or FPC? Then sign up now!

The Smart Competition has been extended by 1 month, which means that you have ample time to join and code some interesting stuff with Smart Mobile Studio.

But ! I have decided to make the prices more interesting by adding a full 1 year subscription to Smart Mobile Studio pro (!) as the first price, and the Raspberry PI 2B as the second price and a Raspberry PI model 1 (the original RPI) as our third place price.

So we now have 3 prices which are as follows:

  1. Smart Mobile Studio Pro (1 yr subsc.)
  2. Raspberry PI model 2 B (Windows 10)
  3. Raspberry PI model 1 A (Linux only)

Wow! what is this competition about?

Simple. The winners will be picked from the entries and the 3 best components or packages will receive the prices.

Note: Please ship the components as a smart mobile studio package. Creating a SMS package is very easy, see the packages menu. This is not a must, but by far the easiest way for us to test the components and see them in action (demo program + package = good experience).

Writing slick HTML5 components is easy, fun and rewarding!

Smart needs stuff like this – are you up for the challenge?

What should I write components with?

Simply go to and download the trial. Remember to request a trial key (!) before you begin or you wont get access to the IDE.

With SMS installed, play around with it and get to know how it works. Especially SmartCL.Components is of interest for this competition – and then code a kick ass component or package which is noteworthy, unique and helpful.

Keep in mind that Smart Mobile Studio has few components, so controls which are old classics for Lazarus and Delphi – are completely new and valid here!

You can read the original competition post here!