Running QB64 on a Raspberry PI (And known issues)
#1
To run QB64 on a Raspberry PI, you need to do a few things to QB64 in order to compile and run programs.

Also, right now, QB64 will only run on a 32-bit running on the RPI. I haven't yet gotten it to work on 64-bit OS's. I am still researching if this is possible. It just might be a PI ARM issue. I am experimenting with settings in the ARM chip itself and GCC/G++ compiler options from the ARM technical documents I've obtained from the IEEE. Very few in my local chapter have had experience in the ARM, and none with QB64.

However, there are a few issues that are part of the PI's ARM processor that cannot be easily fixed in QB64.

Most programs will compile and run fine. Others will get one or both of the following issues:

1) Racing Conditions (can appear as SIG BUS errors)
2) Misaligned Addresses, or misaligned word errors (appears as SIG BUS errors)

For the most part, identifying where the racing condition is occuring (you will need to do a gdb session to find out), a simple _DELAY .3 will fix it. Racing occurs when QB64 creates multiple threads, and since QB64 isn't really a multithreaded programming language (the backend C++ is), there can be issues.

There are two ways to fix the misaligned address/word issue. One way is to use the -fsanatize compiler option. However, the better fix for most of these issues has been added to the common.h file provided. The code that fixes this and other non-x86 issues is:

Code: (Select All)
//Setup for ARM Processor (Similar to -fsanitize=address GCC compiler flag)
#ifdef __arm__
    #define QB64_NOT_X86
#define POST_PACKED_STRUCTURE
#else
#define POST_PACKED_STRUCTURE __attribute__((__packed__))
#endif /* ARM */

I've included the #define for the non-ARM processors. It doesn't hurt, and on the slim occasion you run into this error, that code will fix it.

The misaligned address, or misaligned word error (SIG BUS), is a hardware issue in the ARM processor. The reason this does not occur on the x86_64 chips is the manufacturers of these chips fixed this issue within its circuitry. If you were to get this error on an x86, it will be a really really bad day for you.

Code, like the following used in the program supplied, is giving the PI ARM processor fits:

Code: (Select All)
TYPE tENTITY
    objectID AS LONG
    objectType AS LONG
    parameters AS tENTITYPARAMETERS
    pathString AS STRING * 1024 ' for A* Path 'U'-Up 'D'-Down 'L'-Left 'R'-Right
    fsmPrimary AS tFSM
    fsmSecondary AS tFSM
END TYPE


It just can't handle these.

One of the ways to fix this on the PI ARM is to rewrite the backend of QB64. This is not practical.

In the enclosed compressed file, I included an example of a program that has both conditions - racing and misaligned addresses.

One of the things I plan to do late summer is to get my hands on an Apple M1 ARM laptop, and test this out. This is important, as Apple plans to roll this out to their other products. Also, INTEL is close to finishing their ARM processor, and last October (2021), Microsoft and AMD announced a joint venture to develop their own ARM processor. God only knows what, if any, standards any of these chips will follow. The ability to run QB64 on these systems, although my sources say they are at least 5 years away, means we need to take a headstart in determining, if any, changes need to be made to QB64 itself.

I am hoping that it will be mostly parameters added to the GCC compiler, and that the chips will follow some of the X86 fixes.

To install QB64 on the PI:

1. Extract QB64 but do not run the install.
2. From the compressed file, copy/replace the common.h file in the /internal/c directory.
3. Replace the setup_lnx.sh script in the qb64 folder with the one from the compressed file.

Note: I have provided the makedat files, just to show you what changes were needed here. Without these changes, your binary executables will get ASAN errors, or malformed binary files. (This is the issue with running QB64 on the 64-bit OS. I have a question in to PI support, and am trying to find out from GNU if there are other things I need to do.

I have run 12 openGL programs with no issues. My EBACCalculator runs fine. I even ran my baseball/softball statistics system, that incorporates mySQL (on the PI they use mariaDB), Zenity, HTML/CSS, and multiple shell calls to programs and use of pipecom with memory allocations, call to C++ functions from header files, runs with no issues.

Right now, it mostly works. If you use UDT types, it may compile, but will not run.


Here are the files.



.zip   qb64RPI.zip (Size: 64.83 KB / Downloads: 82)

George
Reply
#2
Wow. Nice work.

My jaw dropped when I saw something that looked like my code. It was never intended to run on a Pi, and I see that it will not. I'm assuming you are just using it as a demonstration.

I have an updated version on my Github. I don't have my Pi here in Austin, but if you need alterations to the code or you have updates you want to push then let me know.
Reply
#3
(04-21-2022, 01:53 AM)justsomeguy Wrote: Wow. Nice work.

My jaw dropped when I saw something that looked like my code. It was never intended to run on a Pi, and I see that it will not. I'm assuming you are just using it as a demonstration.

I have an updated version on my Github. I don't have my Pi here in Austin, but if you need alterations to the code or you have updates you want to push then let me know.

Well, I have to walk into another chat room... OUCH! Hey, who left this jaw on the floor?!!!

Pete Big Grin
Reply
#4
(04-21-2022, 01:53 AM)justsomeguy Wrote: Wow. Nice work.

My jaw dropped when I saw something that looked like my code. It was never intended to run on a Pi, and I see that it will not. I'm assuming you are just using it as a demonstration.

I have an updated version on my Github. I don't have my Pi here in Austin, but if you need alterations to the code or you have updates you want to push then let me know.

Yes. Not only using it as a demonstration, maybe someone smarter than me can figure it out running your code.

Your program had both issues - racing and misalignment. I spent three whole days in gdb figuring that one out!
—————————————————————————————
George McGinn
Theoretical/Applied Computer Science Specialist
Member: IEEE, IEEE Computer Society
               Technical Council on Software Engineering       
               IEEE Standards Association
               Society of American Baseball Research
Reply
#5
Even with my machine I occasionally ran into race conditions at the very start of the program. I put a .5 second delay at the start of the "SUB initScreen (engine AS tENGINE, w AS LONG, h AS LONG, bbp AS LONG)" and that fixed or masked the issue.  I can see that you did that already.

The other delays I saw, in particular after "SUB vector2dSet (v AS tVECTOR2d, x AS _FLOAT, y AS _FLOAT)" might tank your FPS, if you manage to get it running.

I'm not sure if this would help, but you might change all of the _FLOAT to SINGLE and change the Hashes from _INTEGER64 to LONG that would put most everything into 32bits, which might help the alignment issue.

I realize you might be using my program as a torture test, so it may not be in your interest to repair the program, but look at the compiler instead.
Reply
#6
(04-21-2022, 12:28 PM)justsomeguy Wrote: Even with my machine I occasionally ran into race conditions at the very start of the program. I put a .5 second delay at the start of the "SUB initScreen (engine AS tENGINE, w AS LONG, h AS LONG, bbp AS LONG)" and that fixed or masked the issue.  I can see that you did that already.

The other delays I saw, in particular after "SUB vector2dSet (v AS tVECTOR2d, x AS _FLOAT, y AS _FLOAT)" might tank your FPS, if you manage to get it running.

I'm not sure if this would help, but you might change all of the _FLOAT to SINGLE and change the Hashes from _INTEGER64 to LONG that would put most everything into 32bits, which might help the alignment issue.

I realize you might be using my program as a torture test, so it may not be in your interest to repair the program, but look at the compiler instead.

I will give that a try. Right now I am testing a mySQL/mariaDB client connector I wrote in C to implement SQL into QB64, but sometime next week I'll give it a try. Thanks.
—————————————————————————————
George McGinn
Theoretical/Applied Computer Science Specialist
Member: IEEE, IEEE Computer Society
               Technical Council on Software Engineering       
               IEEE Standards Association
               Society of American Baseball Research
Reply
#7
While it's not QB64 are you aware of PicoMite: Running BASIC on a Raspberry Pi Pico? That's a YouTube video by ExplainingComputers. It's based on this website - BASIC Interpreter for the Raspberry Pi Pico. Thought there might be something there that might be useful for your project.

TR
Reply
#8
Hi George,
Did you have a chance to try QB64PE on a 64 bit release of the OS for the Raspbery Pi yet?
If yes, what's the result?
And what must be changed in the makefile to install and run QB64PE on let's say a Pi 400 or a Pi 4 model B?
Looking forward.
Cheers.
Fifi
Before to send the arrow of truth, dip the head in a honey pot (Cheyenne saying).
Don't tell my Mom I'm on iMac with macOS, she thinks I work on PC with Windows. Tongue
Reply
#9
Lightbulb 
George, are you making any progress on this? Because several people are interested in this project. Mostly lurkers, and there will be more asking if QB64(PE) would ever have ARM support. Not being very helpful making this comment and bumping a month-old thread but still...
Reply
#10
I'm sorry for posting again in a thread that might not have much relevance anymore, but there are a few people on the "other" forum interested in making QB64 work in another operating system. I saw George posting somewhere else the other day, just writing here as a last reminder.
Reply




Users browsing this thread: 2 Guest(s)