One of my favourite of the clones, mainly becuase it comes with all drivers and fully working pretty much out of the box, it does not take a lot to get this very cheap quad core up and running.

Of course being cheap it does not have much in the way of performance, its ancient Mali400MP2 mean it has much less power than the Raspberry, and it only has an H3 running at 1.2ghz  its also a little prone to overheating but not too much.

Its a game little beast, comes with Debian and Ubuntu, I tend to use Debian, and GLMark2-es reports a modest speed of 72, so it is accelerated, its just not fast.

Setting up is pretty much the standard case of installing all the additional libs, locating where the standard libs are, they are not the same as Raspberry, check the generic build demo to see what it does.

And then simply compile and run as usual, it runs about 80% the speed of a Raspberry which is a good excuse to practice some GPU optimization concepts we never covered in the book.

Sadly FriendlyArm seem to have discontinued this very cheap fun board and replaced it with a more expensive M1Plus version with more RAM, eMMC store, Wifi and BT, but at 3 times the price....not sure I can justify the extra cost for the same cpu and gpu.

Not sure actually if I bought the basic or the pro, its reporting 2G of RAM for a basic, but has 32GB eMMC ram for a Pro, on board...
hmmm either way, here's a small report on using it. This is reposted from my Tiny Monsters that play games blog


This is an odd beast for sure, I had trouble with it simply because it uses a USB C cable for power, and even though it came with one my usb output from the monitor never seemed to give enough power and it would frequently die at the end of a boot.
Well finally I got a converter for micro to USB C, and also managed to finally work out how to update the on board memory to have a linux (ubuntu) system instead of the default, but actually rather nice Android

This is an 8 core beast (big/small) which should put it on a par with the mighty Odroid XU4, it even has a better GPU, a Mali T820, but only MP3 , not quite up to the XU4's MP6 but even so its a next gen chip so it might manage it. It's an ES3.2 chip, which even if it can't quite provide the parallel grunt sending ES2.0 shaders to work, its ES3.2 shaders should make them cry.
After a bit of head scratching which turned out to be nothing more than very bad documents that didn't immediately make sense I was able to get it to reflash, and then update.

Time for the graphics fun to begin but of course there's no drivers on board...oh well...

Installed GLMark2-ES2 ok, after I'd allowed the onboard installer to do an update and reset. It does not identify the MaliT820 though so its basically emulating and slowly as you might expect, frame rates so far are nothing to write home about and of course it errors a lot at the death, eventually exiting with no score.

I'll see if I can get the usual mesa libs on board and try to get a test build sorted...should only take an hour

And bugger me, that was actually quite easy, once I'd set up the standard libs etc, and also installed and activated SSH server with

sudo apt-get install openssh-server
sudo service ssh start

So that Visual GDB could make the connections, I had no problems getting the generic multi config Mazehunt to build at run at all aside, from the known keyboard problems, the chmod fix however got me control and off it went.

Its running very slow of course due to lack of hardware access to the GPU but its performing as well as any of the other units without graphics. So I'm genuinely impressed. That was the easiest I've had so far, and the 1st time I've been able to do a -j8 options without the target dying. Most impressive. It does get bloody hot though, and the fact its already encased in a perspex case means I can't add a heat sink or fan to it..but it does not seem to be too worried and is running all 8 cores at a nice old rate.

Will it ever get GPU access? I dunno...we'll see. Apparently Android has drivers, so maybe I'll use this as the Android port example.

Its a fast beast too, sysbench has it doing 10000 primes in 1.6212s, thats lighting fast..Odroid XU4 takes over 16 seconds thats a factor of 10 times and yet the Odroid is clocked a little higher.
If the GPU driver is ever released this will be a serious beast to use for dev...and OpenGLES3.2 on board will make it unstoppable...for now though its just a very fast CPU system.

The Raspberry is my favorite goto system for developing a project, its not the fastest, it does not have the best GPU but it is basically totally solid and totally reliable and of course the Raspberrypi.org forums are full of useful and helpful advice that pretty much solves all problems

In game programming terms the only issue I have with it is the keyboard system and the relative lack of GPU power.

Keyboards, I am still working on, usually they are ok, but recent updates mean that my wifi keyboard/mousepad combo isn't being registered as a keyboard any more but if I register it as a mouse it does work??

That's not ideal though I want to be able to have anyone run the games I make so need something more reliable, this is ongoing.

GPU power is the other thing and that is actually great fun to play with because it all boils down to how well you optimize your rendering systems, that creates lots of chances to play and experiment.  I did some work on optimizing in the book, but decided to take it out of the final draft as it was increasing the difficulty curve quite a bit, also its best demonstrated with video and more advanced/complex models and environment than I had available in the book.
So I will discuss optimizing in the main site in the coming months when I add some online tutorials, it will be applicable to most SBC's but for sure the current demo's can all be made quite considerably more efficient.



I can't see there will be a lot of specific questions here that are not covered in the RaspberryPi.org forums but feel free to ask, and I'm sure there will be someone who can answer.

VisualGDB is for me the best option for coding on SBC targets. But it does come at a cost and not everyone can afford it.

The next best option is to use Visual Studio's cross platform development options for Linux.

This provides almost all the functionality that VisualGDB does, Edit and debug on the PC, console screen display, but only build on target so it can be a slow build.
It can be a bit clunky to set up, but there is a default raspberry project that can be used to get started, and most default linux projects will work on other machines. Do not use the Raspberry config, if you are not using a raspberry, not all ARM systems are the same, it don't work like that

It needs a tiny bit more understanding of the build process to get set up, so its best to use the 30days free VisualGDB trial to get familiar with what is happening during a build process, and this will be more understandable.

Its also a bit of nightmare if you have more than one device listed for it, but assuming most people are normal and not like me with 20 different system to target, if you have 1 system its ok, it just makes you jump through strange hoops to add others.

A few of the book and Magpi projects will be converted to this system to demonstrate how to get going.

In the simplest terms VisualGDB is a magical system that saves weeks of work, litres of sweat and probably several pints of blood loss from bleeding knuckles bashing on keyboards.

Available here https://visualgdb.com/

VisualGDB is a plug in for your PC based Visual Studio IDE. It handles all the connections to your target system SBC, It lets you build your code on the target (reliable but slow) or on the PC, (basically just as reliable, but 100 times faster). It keeps track of all the libraries and assets you need and makes adding new things just as easy, allows you to debug on the PC while the SBC is running its code and is just generally amazing and useful.

Its not free though, but it is pretty cheap, especially if you plan to do a lot of coding, and  indeed value those litres of sweat and weeks of work which can now be productive rather than having lots of head scratching panicked wtf moments.

Of course its also not perfect, it does have a few quirks, it can be complex if you try to use the advanced features, and it does update every year or so requiring a bit more of a relearn and a decision to buy or not buy the new version.

But if you are in any way serious about working in a professional manner and producing high quality work, this is the package you need to have.

Try it out for 30 days free (if you are using the Fundamentals book, don't start the trial till it tells you)  and see for yourself just how much time and effort it will save you.

This one is a bit of a step up, putting graphics system in place, but even so we're only half way there. The nature of a 4 page article makes it very hard to keep the content relevant and interesting. But stick with it, we'll expand on it more each week and soon have a bunch of recognizable game characters chasing you around.

The Raspberry is a good little unit, and one of the tasks it does for you automatically now is to resize the root partition so that you get the full size of your SD card. Sadly most other SBC's don't, and expect you to know how to do that.. But its actually not that obvious, especially if like me you are not a regular linix user.
When you create a new image on your SD it does not start off with all the SD memory free, so you have to resize, if you find your SBC is resizing (a few do) then you won't need this, but I never could get a simple answer to the issue!


Lucky I stumbled onto this blog post that helps to explain it all, you have to do this the 1st time you boot up a new SD image, if you write anything before you do that you will lose data.
Here's the original post
http://gleenders.blogspot.nl/2014/08/ban...-root.html 

As its quite old, and the blogger does not seem to post any more, it might vanish so here is the bones of it again

sudo fdisk /dev/mmcblk0
In fdisk:

Press ‘p’ to print the partition table:

Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes
4 heads, 16 sectors/track, 486192 cylinders, total 31116288 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00084078

   Device Boot           Start         End      Blocks   Id  System
/dev/mmcblk0p1            2048      124927       61440   83  Linux
/dev/mmcblk0p2          124928    31116287    15495680   83  Linux 

the 124928 number may well be quite different on your SD, but take note of it, its this number that matters as its the start of the partition
Press 'd' to delete a partition:
Enter '2' to choose the second partition.
Press 'n' to create a new partition:
Enter 'p' to select primary as partition type.
Partition number: enter to accept 2 as default partition number.
First sector: enter to accept default.
This should be that 124928 number of the number you took not of as the start
Last sector: enter to accept default.
Press 'w' to write the new partition table.
Reboot to force the kernel to recognise the new partition table.

sudo reboot
After the system has come back up you still have to resize the partition.

sudo resize2fs /dev/mmcblk0p2


when done you will now have the full size of your drive available to you to store data

If you don't have access to a PC to use as a dev system, its still perfectly possible to work directly on your Raspberry/SBC using Code::Blocks which is an IDE designed to run on your target. 

It does mean that you don't always have access to your debugger (in a full screen game) and the build and run time is much slower than a PC build, but it is of course cheap and easy to do.

There are MANY other IDE's available for free on SBC's though, you can even just use a text editor if you want but its hard work and I don't like hard work, so I will only comment on Code::Blocks, until I find a better one

Be aware though that working on your target as your editor, risks the loss of your source files, not a common thing, but certainly something to be aware of, so make sure you keep backups (ideally on line) and use as big media store as you can manage, as your assets and files will fill up a small SD quite quickly.

As with the VisualStudo 2017 Linux builds, I will convert a few projects to run on Code::Blocks so you can get them to work and experiment yourself.

There's a couple of typo's in the 1st lesson, sorry

to install code::blocks use 

sudo apt-get install codeblocks not as listed sudo apt-get codeblocks


on the paragraph headed Starting with C++, the file you need to create (the last reference is Game.h) should actually be SimpleObj.h

I've noted in my book, that when building on target builds, you may find that your VGDB expects a later version of  GDB to be on the target. Earlier versions can cause annoying random hangs when debugging.

The reasons for this are pretty simple, if you are using VGDB in its default ARM mode, its going to assume the latest version of GDB on the target. But Raspbian is usually slower to update than most Debian builds, so it tends to lag behind.


Recent versions of Raspbian have updated to the required versions, but its possible VGDB will update as well and the problem returns.

You can replace the version on your targets Raspbian with a more uptodate version, but the easiest thing is to do builds on the PC using the Raspbian toolchain, which will use whatever is the latest Raspbian version of GDB (its also a much faster compile/build/run cycle)