Does anybody actually use or need network support?

I'm currently working on the H616 port. The H616 is a wretched abomination that consists of more bugs than transistors. It requires tons of workarounds in Linux, all of which are either implemented in out-of-tree patches of abysmal quality, or not at all. Or they are implemented and don't work. Or they only work on some boards. Allegedly.

One of the things that don't work is Ethernet on the X96 Q LPDDR3 TV box, no matter how many questionable workarounds I try out. Given that networking is hardly a first-class feature of the BASIC Engine, I do not really want to invest any more time in getting it to work. OTOH, I don't want first and second-class platforms. So I'm thinking about removing network support altogether.

My (IMO) very good reasons for that are:

  • It doesn't work all that well anyway. Basically, you can do WGET. And that has only recently started to work on H3.
  • It's a metric shit-ton of work, even when using Linux as a crutch. This is especially true for WiFi, but as the H616 example shows, wired networking doesn't "just work" either.
  • Network access brings up the question of security. Right now I'm simply ignoring it, but if networking in EB were ever to be used on a significant scale, that would no longer be possible. Maintaining ports is hard enough without having to follow Linux (or lwip) security updates.

I am not necessarily thinking of disabling network on the Linux side, but of removing built-in support from Engine BASIC and answering any questions about networking with "not supported".

Would that inconvenience anybody?

    uli The H616 is a wretched abomination that consists of more bugs than transistors.

    🤣

    uli Would that inconvenience anybody?

    Not me! Get rid of it! 🪓
    What I would really love to have is an emulator, to develop and test programs on my Mac without much back and forth with the SD card. But I don't care for network support atm.

    • uli replied to this.

          Networking in BASIC isn’t something that I’d be planning to use.

          5 days later

          Dmian What I would really love to have is an emulator, to develop and test programs on my Mac without much back and forth with the SD card.

          Uhm, completely hypothetically speaking: What SDK version would one use in order to target the biggest Mac audience? (https://developer.apple.com/support/xcode/)

              uli The latest MacOS (14.4) is all that’s needed, actually. Mac users keep the system up to date, and Mac is the platform where most developers will develop on. Also, being a Unix system, a lot of Linux libraries are available (in my case, I use Homebrew as my package manager https://brew.sh/ )

              I really need to see how Commander X16 did their emulator. I have the feeling it can even be done without Mac specific tools (but will probably complain a lot about security issues). To avoid that, the app must be signed. But other than that, I think it should probably be very similar to developing for Linux, for something that is not using any Mac specific features.

              Hypothetically, of course 😁

                This is Commander X16 emulator: https://github.com/x16community/x16-emulator

                I was able to run it, and the only requirement was installing SDL2 using Homebrew.

                I have no idea if this is helpful or not, but I just wanted to show it as a reference. (But I hope it helps in some way)

                Edit: just checked, and to run the emulator I don't need to have SDL2 installed, that's to build the emulator, but I'm not building it, just running the binary. It does complain about the security of it, but that's easily avoidable.

                Edit 2: I just opened Xcode on my Mac, and the target OS is actually 14.2, but I guess an older version could be used without any problems.

                Try this. It's cross-compiled on Linux with osxcross and SDK 10.13 (I think) for AMD64 and tested on Big Sur running in QEMU (which is the third version of OSX that I tried to install and so far the only one that works). It's dynamically linked, but the zip file includes the SDL2 library.

                enginebasic-osx-prototype.zip
                1MB

                You may want to start it with -s 960x540 -r <absolute_path_to_your_engine_basic_root_directory>.

                For reference: I pushed the code to the osx branch in the basicengine-firmware repository. It compiles with CC=x86_64-apple-darwin23-clang CXX=x86_64-apple-darwin23-clang++ AR=x86_64-apple-darwin23-ar ./configure.sh && ninja -f build.ninja.sdl if you have libsdl2 installed with MACOSX_DEPLOYMENT_TARGET=10.13 osxcross-macports install libsdl2. Not sure how imporant the deployment target part is; I just went with the first thing that worked.

                I have used clang with Engine BASIC before for static code analysis, and did half a Windows port recently (doesn't work yet) that fixed a lot of Linuxisms, so this was surprisingly easy. The most difficult and time-consuming part was actually installing OSX in QEMU...

                One thing: This is not an emulator. It's simply Engine BASIC running on macOS. It works exactly as on the bare metal platforms (or it should, at least), albeit restricted by whatever limitations the underlying OS imposes. (IOW: Use POKE, and Engine BASIC will most likely crash.)

                There is no attempt to emulate an ARM CPU, or to reproduce the timing of any hardware platform. If you want to use modules, you have to compile them for whatever CPU architecture you're running on.

                I'll be on my way back to Europe in two days, so I probably won't be able to do anything about this if it doesn't work. If it does: Enjoy!

                Thanks a lot!
                I'll see if I can manage this (I'm pretty dumb regarding this kind of development). I understand that I first need to compile BE for MacOS X, and then run the dynamic library pointing to my BE build?

                So far I'm trying to compile it on MacOS. I cloned the osx branch on my Mac, and used Homebrew to install gcc, ninja, sdl2 and gettext (I even installed cmake, why not? hahaha).

                I modified the config file to use python3 instead of python, and used pip3 (yes, MacOS uses python3 and pip3 for some reason) to instal polib.

                So, right now, if I use the compiling line you provided I get two erros:

                [5/87] CC="x86_64-apple-darwin23-clang" CXX="x86...win23-clang++" make -C build_sdl/dyncall/dyncall
FAILED: build_sdl/dyncall/dyncall/libdyncall_s.a 
CC="x86_64-apple-darwin23-clang" CXX="x86_64-apple-darwin23-clang++" make -C build_sdl/dyncall/dyncall
x86_64-apple-darwin23-clang    -c -o dyncall_vector.o /Users/damian/GitHub/basicengine-firmware/libraries/dyncall/./dyncall/dyncall_vector.c
make: x86_64-apple-darwin23-clang: No such file or directory
make: *** [dyncall_vector.o] Error 1

                And also

                [6/87] xgettext -k_ -k__ --from-code utf-8 ttbas...ipts/msgs.py msgs_$i.h $i ; done ; rm tmpmsgs.po
xgettext: La opción '--sort-output' está obsoleta.

                (option '--sort-output' is obsolete)

                I'll keep trying to see what I can do. Don't worry much, you've done a lot so far (way more than I expected), and I really appreciate it. If I have further information, I'll let you know.

                Edit: a couple comments. My Mac is a ARM machine (M2 Pro). So, maybe that's why I'm getting the clang error?
                And also, when I remove the -s option form gettext, it still gives me an error:

                [6/87] xgettext -k_ -k__ --from-code utf-8 ttbas...ipts/msgs.py msgs_$i.h $i ; done ; rm tmpmsgs.po
ninja: build stopped: subcommand failed.
                • uli replied to this.

                  Dmian I first need to compile BE for MacOS X

                  Absolutely not. Just download the zip file, unpack it and run the binary inside (basic.sdl). That's it.
                  I just added the compile instructions for reference, in case I forget it.

                  Dmian My Mac is a ARM machine

                  From what I read ARM Macs can run AMD64 binaries using "Rosetta 2", which should be automatically installed if not already there when trying to run an AMD64 program.

                        uli Just download the zip file, unpack it and run the binary inside (basic.sdl). That's it.

                        OMG! 😍

                        Thank you! 🥰
                        I'll play with it, hehehe...

                        Edit: yes, it needs nothing to run (Rosetta is automatic), just open it with Terminal, and it runs... Wonderful!

                          This makes me really happy... 😁

                          • uli likes this.

                          I'm now looking to see if I can create a Mac Bundle with the sdl app. There are manual ways, and also utilities that help in the process: https://github.com/auriamg/macdylibbundler
                          My goal is to have something that you can double-click to easily open the app, so it's easier for other Mac users.
                          Ha ha ha, I'm really having fun with it. 😄

                          Soooo...
                          I followed this tutorial (https://tmewett.com/making-macos-bundle-info-plist/) and:

                          http://damianvila.com/basicengine/bundle.mp4

                          Probably the dumbest thing you've seen today. 🤣
                          Btw: it's not practical. It gets the root directory (not the directory where you'd like to open, not even the user directory), and opens in the default resolution (you can't pass parameters), but if someone who doesn't know how to open an app from terminal wants to try it, it may be useful.
                          I hope at least you were entertained by my shenanigans. 😄

                          In the end I used Mac’s Automator to create an “app” that launches the sdl via a bash script with parameters. I called it “EngineBASICLauncher”, and I can double-click on that to launch BASIC Engine. The funny thing is that, since I have the info.plist file in the same directory, the sdl behaves like a native app, with a menu and Quit option. 😁👍

                          18 days later

                          Fyi: there's a Swift SDL wrapper that can eventually be used if somebody wants to try that: https://github.com/KevinVitale/SwiftSDL
                          I'm not going to investigate that route, though, since the launcher works quite well. 😊

                          Powered by: FreeFlarum.
                          (remove this footer)