Here's a preview of the new Linux-based system, tentatively named "BASIC Engine LT". šŸ˜€

There are numerous new features, and also a few breakages. The most important feature, though, is portability. To demonstrate that, I have created builds for two new platforms, the Raspberry Pi 4 and the good old IBM PC, in its 64-bit incarnation. (That does not necessarily imply that RPi4 and PC will be first-class platforms from now on; they just happen to be what I had lying around here.)

Most testing has been done on the Orange Pi Lite and Orange Pi PC, with very limited testing done on a Raspberry Pi 400 and my x64 notebook (Asus F510U, with an Optimus NVIDIA/Intel graphics setup). YMMV considerably on other devices.

The H3 version comes up with a boot menu in which you have to choose the board you are using. I have included device trees for all H3 and H2+ boards that are supported, but only OPi Lite and OPi PC have been tested. (There are also device trees for A20-based Orange Pis in there; no idea if those do anything.)

On first boot, all versions create a BASIC partition on the SD card/USB stick, then reboot and install the Engine BASIC system files on that partition. Be VERY CAREFUL when using the PC version if you have any
valuable data on it! It may be wiped out if I got anything wrong with this procedure!

In case you are wondering why this new system is so big, the answer is hardware support. You can plug an infinite number of USB devices into all available platforms, and on the PC you can also plug in yet another infinite number of PCIe devices. Linux supports all of them. I thought long and hard about what to include or not, but ultimately there is a legitimate use case for virtually everything. Picking out the three devices that nobody is going to use is not going to help significantly with size, and it is all but guaranteed that someone will pop up who wants to use them immediately. You can therefore expect the size of the images to grow a little going forward as I re-enable the few things I have disabled.

The reason the PC port is x64 and not x86 is that I checked eBay Germany, and the very bottomest-of-the-barrel devices (both notebooks and PCs) are all 64-bit, so I felt there to be no advantage in supporting 32-bit devices.

If anybody is interested in porting this to another platform, the most important requirement is hardware-accelerated OpenGL ES support, which may be surprising, considering we are not doing any 3D stuff (yet). The reason is that the SDL2 kmsdrm driver uses GBM, and that only works reasonably well with hardware acceleration. It would be possible to implement graphics backends on the Engine BASIC side that lift that requirement, but those would probably be platform-specific, and that's not something I want to re-introduce.

Stuff that is new and improved:

  • SHELL command. Allows you to run all that Unix goodness.
  • Remote file system access; run SHELL "sshfs <user>@<host>:<path> <local path>" and you can access any file over the network.
  • Improved text mode performance (I think; mode 20 seems to be faster than before; I haven't done any measurements, though.)
  • Support for ANSI terminal commands integrated into the Engine BASIC text mode system for seamless integration of Unix stuff into your BASIC workflow. (Not 100% there yet, but works well enough for shell commands and the bundled text editors.)
  • Out-of-the-box support for virtually all USB game controllers, including XBox.
  • More editors. Enjoy nano, joe and everybody's favorite beginner editor, vi. (Atto is still there.)
  • Saving programs without line numbers (SAVE "foo.bas" LINE OFF). (Only possible with Linux, I swear!)
  • Automatically creates a BASIC partition on first boot that spans the entire SD card.

Stuff that is as good as it was on the bare-metal platform:

  • Impossible to break accidentally. The file system is read-only, so it even survives SHELL "rm -fr /". User files will be gone, of course, but the system will still be fine. Unlike the bare metal system, it will also restore BASIC system files if they have been deleted. (Only tested on OPi; do not try this on other platforms!)
  • Stutter-free video output at 60 fps.
  • CPUSPEED. It's still manually controlled, mostly because changing frequencies caused stuttering in the video output on H3.
  • separate graphics rendering thread (SDL1 version was single-threaded)
  • Most things, actually.

Stuff that technically works, but is not easy to use:

  • WiFi on the OPi Lite; the driver is there, and so is wpa_supplicant, so it's probably possible to bring it up somehow. (Same probably applies to PC and RPi4.)
  • wired network setup (run SHELL "udhcpc" for now)

Stuff that is expected to work, but is untested:

  • GPIOs
  • I2C, SPI. To use those devices, you have to use the DTBLOAD command on a device tree overlay (can be found in /boot/overlays) that enables the specific controller. Then use I2CBUS or SPIDEV to select a bus/device.
  • UARTs 1 to 3. Again, use DTBLOAD to enable. You can then use the standard file functions with "/dev/ttyS1" to "/dev/ttyS3" to access the serial ports.
  • analog audio (will only work without HDMI display, might have issues with audio levels)

Stuff that sort of works a bit:

  • TV output on OPi PC; the picture has the wrong aspect ratio; I don't have an actual TV at hand, so that might be an issue with my CVBS-to-VGA converter. Not enabled on any other board.

Stuff that doesn't work because it's not implemented yet:

  • BASIC network commands
  • direct hardware access; still not sure if there is a point to that or not
  • borders

Stuff that doesn't work even though it is implemented:

  • controller hotplugging (new controllers are not detected; make sure you boot with the controller(s) plugged in)
  • mounting files on the BASIC Engine from another host via sshfs (no idea what's wrong with that; sftp is there)

Other known issues:

  • Rebooting sometimes fails on the Orange Pi PC; not sure if that is a fault of my unit or a general problem.
  • Sound is muted on PC by default. Use SHELL "alsamixer", unmute the master channel (M key) and turn up the volume.
  • The terminal emulation is lacking many features.
  • BOOT command doesn't work, use SHELL "reboot" or SHELL "poweroff". (Or SYSTEM if you only want to restart Engine BASIC, not the whole system.)
  • NEON is disabled for the BG engine blending/scaling code, so there may be a performance hit on ARM devices.

Downloads:

Check https://github.com/uli/basicengine-buildroot/releases for SD/USB images.

Wow, you've been really busy @uli . I look forward to giving BASIC Engine LT a spin, although LT would suggest Light, and it certainly doesn't feel as light as it was. Maybe LX would be a better suffix to represent the Linux version.
Anyway, I have a few different platforms to test on (OPi PC, Pi400, various PC laptops - if I can get the laptop to boot from SD, Oh, I wonder if it would work on my ASUS Netbook...I think it's only 32bit.) so I look forward to getting some free time.
Would you like any bug reports raised as issues in GitHub?
Cheers,
Mike

  • uli replied to this.

    Hawk if I can get the laptop to boot from SD

    USB is probably easier. šŸ˜€

    Hawk Would you like any bug reports raised as issues in GitHub?

    Just give me your impression here. If there are things that require a more in-depth look, we can transfer it to Github. Thank you.

      WOW! This is amazing, Uli!
      Thanks a lot for all your work. I have a RPi 4 around I can try this on.
      Iā€™m a bit demotivated because the chip shortage is making most electronic projects difficult to carry on, but your effort with this new branch of code is invigorating.
      Cheers!

      Thank you, uli !! This will be the impetus for me to get a Pi4...or maybe Pi 400.

      I know it is very early, but if anyone is trying this out in a VM, I would love to hear how it goes!

      • uli replied to this.

        painintheworld I know it is very early, but if anyone is trying this out in a VM, I would love to hear how it goes!

        Huh, that never occurred to me. šŸ˜€

        QEMU is not going to work. Mesa's virgl driver is not enabled, and even when I enable it, it still doesn't work. I'm not sure what's going on, but I would not be surprised if it simply didn't support GLES.

        As for VMware, drivers are there, but I have so far not managed to get 3D working in VMware at all, and I use it for real-life applications, so I'm not inclined to tinker with it too much. And, again, I don't know if there is any GLES support.

        (Note that if you just want to run Engine BASIC on your (Linux) desktop PC, you can just do that without any virtual machines.)

          uli Thank you! I played around with it using Virtualbox, with Windows 10 as the host, without any success.

          a month later

          Ahoy all,
          I'll explore this option. I think I might give this a spin on my RPi400. I have many (I mean lotsa) computers I could try this on. But I have yet to use my RPi400 for much as my main system is a RPi4B 8G.

          Oh, I'm back and pretty healthy after good news on the big C šŸ˜„ I hope it holds up longer this time. I'm retired 100% now so so much time but not so much energy. Just glad to be on my way again.
          daveyb

          I hope your health improves each and every day, @MC10Guru, and that C is in your rearview mirror for the rest of your life. I am in a very similar position, though I'm a few years removed (8 years since any treatments of any sort) and finally feel pretty damned good šŸ™‚

          I've been wanting to get an 8GB version of the Pi4, but am not going to pay scalper prices. I have a Pi400 in my Amazon cart that I'm going to pull the trigger on one of these first days šŸ™‚

          a month later

          I hope it's not too much to ask, but... is it possible to add a Splash Screen (BASIC Engine logo) to the boot screen? (using psplash or something like it).

          It's only personal preference, I know, but I always like when you are presented a logo when the system is loading instead of a lot of text. At least to me, it seems friendlier.

            Dmian ATM, the different platforms behave differently:

            • Allwinner H3 has a framebuffer driver, but the console is on the serial port only. You therefore see a blinking cursor during bootup, but no messages.
            • RPi4 has a framebuffer driver as well, and that one is actually used as the console and therefore shows kernel messages.
            • PC has the console on VGA and, at some point, switches to a DRM-based framebuffer console (IIRC), which display the kernel messages.

            Silencing the messages is easy, and I'm going to do that as soon as I trust this stuff to work on most supported devices. (NB: For PC, that probably means never.)

            Showing a splash screen at the right time and for the right duration is considerably more difficult. On the SBCs, the control of the display is passed from the boot loader to the framebuffer console, and then to the DRM application (Engine BASIC). On the PC, it goes from the boot loader to the VGA console driver, to the framebuffer console and then to the DRM application. By the time anything can be displayed on the screen from Linux userspace that actually stays there and doesn't get wiped out immediately by the next stage, the boot process is basically done.

            The way to display something that stays there until the application (Engine BASIC) starts is to disable all the stuff that uses the display without being asked (VGA console, framebuffer console), and have the boot loader show a splash screen. I already don't like that simply because each of the three existing flavors has a different boot loader.

            Apart from that, I am not at all comfortable with the idea of disabling the standard console drivers. The framebuffer device might be required by legacy applications people might want to run on their BE systems, and not having an on-screen console means there is no way to interact with the system or even to indicate an error if something goes wrong on the OS level.

            To sum it up, showing a splash screen is something that needs to be done on a per-platform basis and it would either be imperfect (showing up only during some parts of the boot process) or require removal of functionality from the kernel. I don't like it.

              uli Oh, ok.

              I was just talking about the bootloader (the part form "Uboot..." to "Starting kernel...."), because after that, you see just a black screen.
              I just looked if it was possible to do that, and looked for splash screens for buildoot, and understood that using psplash it was just converting an image to a specific format and adding a few lines. But since I know nothing about it I may've had the wrong impression (I'm sorry).
              Of course, if it's something difficult or something that just complicates things, don't even think about it. As I said, it's just a matter of personal preference, and there's nothing wrong with how things are.
              Cheers!

                Dmian Dmian, if you happen to work this out, I will gladly throw in a few $/ā‚¬/Ā£ to help the cause.

                Powered by: FreeFlarum.
                (remove this footer)