Using digital techniques has caused a resurgence of interest in VLF — very low frequency — radio. Thanks to software-defined radio, you no longer need huge coils. However, you still need a suitable antenna. [Electronics Unmessed] has been experimenting and asks the question: What really matters when it comes to VLF loops? The answer he found is in the video below.

This isn’t the first video about the topic he’s made, but it covers new ground about what changes make the most impact on received signals. You can see via graphs how everything changes performance. There are several parameters varied, including different types of ferrite, various numbers of loops in the antenna, and wire diameter. Don’t miss the comment section, either, where some viewers have suggested other parameters that might warrant experimentation.

Don’t miss the 9-foot square antenna loop in the video. We’d like to see it suspended in the air. Probably not a good way to ingratiate yourself with your neighbors, though.

Between software-defined radio and robust computer simulation, there’s never been a better time to experiment with antennas and radios. We first saw these antennas in an earlier post. VLF sure is easier than it used to be.

youtube.com/embed/S7nQ2fnaA3Y?…

hackaday.com/2025/09/04/optimi…

Developing Android applications seems like it should be fairly straightforward if you believe the glossy marketing by Google and others. It’s certainly possible to just follow the well-trodden path, use existing templates and example code – or even use one of those WYSIWYG app generators – to create something passable that should work okay for a range of common applications. That’s a far cry from learning general Android development, of course.

The process has changed somewhat over the years, especially with the big move from the Eclipse-based IDE with the Android Development Tools (ADT) plugin, to today’s Jetbrains IntelliJ IDEA-based Android Studio. It’s fortunately still possible to download just the command-line tools to obtain the SDK components without needing the Google-blessed IDE. Using the CLI tools it’s not only possible to use your preferred code editor, but also integrate with IDEs that provide an alternate Android development path, such as Qt with its Qt Creator IDE.

Picking Poison

Both Qt Creator and ADT/Android Studio offer a WYSIWYG experience for GUI design, though the former’s design tools are incomparably better. Much of this appears to be due to how Qt Creator’s GUI design tools follow the standard desktop GUI paradigms, with standard elements and constraint patterns. After over a decade of having wrangled the – also XML-based – UI files and WYSIWYG design tools in ADT/Android Studio, it never ceases to amaze how simple things like placing UI elements and adding constraints love to explode on you.

The intuitive Android Studio WYSIWYG experience.

Somewhat recently the original Android API layouts also got ditched in favor of the ‘refactored’ AndroidX API layouts, with apparently now this Jetpack Compose being the (high-level) way to use. Over the years of me having developed for Android, many APIs and tools have been introduced, deprecated and removed at an increasingly rapid pace, to the point where having Android Studio or the CLI tools not freak out when confronted with a one year old project is a pleasant surprise.

Designing GUIs in Qt Creator’s Designer mode.

Although Qt isn’t the only alternative to the Android Studio experience, it serves to highlight the major differences encountered when approaching Android development. In fact, Qt for Android offers a few options, including building a desktop Qt application for Android, which can also use the Qt Quick elements, or including Qt Quick within your existing Android application. For Qt Quick you want to either create the UIs by hand, or using Qt Quick Designer, though I have so far mostly just stuck to using Qt Creator and liberally applied stylesheets to make the UI fit the target Android UI.

Whichever way you choose, it’s important to know your requirements and take some time to work through a few test projects before investing a lot of time in a single approach.

The Build System

No matter what approach you choose, the build system for Android is based on what is objectively one of the worst build automation tools conceivable, in the form of Gradle. Not only does it take ages to even start doing anything, it’s also agonizingly slow, insists on repeating tasks that should already have been completed previously, provides few ways to interact or get more information without getting absolutely swamped in useless verbosity, and loves to fail silently if you get just the wrong Gradle version installed in your Android project.

Did I mention yet that the entire Gradle tool is a permanent fixture of your Android project? Android Studio will want to upgrade it almost every time you open the project, and if you don’t use an IDE like it which automates Gradle upgrades, you better learn how to do it manually. Don’t forget to install the right Java Development Kit (JDK) either, or Android Studio, Gradle or both will get very upset.

If your IDE doesn’t pave over many of these inane issues, then getting familiar with the Gradle wrapper CLI commands is right on the top of your list, as you will need them. Fortunately sticking to an IDE here tends to avoid the biggest pitfalls, except for having enough time with each build session to fetch a coffee and go on a brisk walk before returning to address the next build failure.

There are no real solutions here, just a call for perseverance and documenting solutions that worked previously, because you will always encounter the same errors again some day.

Test, Debug And Deploy

Creating a new virtual Android device.

Even if you have built that shiny APK or app bundle, there’s a very high likelihood that there will be issues while running it. Fortunately the one advantage of JVM-based environments is that you get blasted with details when something violently explodes. Of course, that is unless someone screwed up exception handling in the code and your backtrace explodes somewhere in thin air instead. For the same reason using a debugger is pretty easy too, especially if you are using an IDE like Android Studio or Qt Creator that provides easy debugger access.

Logging in Android tends to be rather verbose, with the LogCat functionality providing you with a veritable flood of logging messages, most of which you want to filter out. Using the filter function of your IDE of choice is basically essential here. Usually when I do Android application debugging, I am either already running Qt Creator where I can start up a debug session, or I can fire up Android Studio and do the same here as at its core it’s the same Gradle-based project.

The NymphCast Player Android build, with default skin.

Of course, in order to have something catch on fire you first need to run the application, which is where you get two options: run on real hardware or use an emulator. Real hardware is easier in some ways, as unlike an emulated Android Virtual Device (AVD) your application can directly access the network and internet, whereas an AVD instance requires you to wrangle with network redirects each session.

On the other hand, using an AVD can be handy as it allows you to create devices with a wide range of screen resolutions, so it can be quite nifty to test applications that do not require you to connect to externally via the network. If you want to know for example how well your UI scales across screen sizes, and how it looks on something like a tablet, then using an AVD is a pretty good option.

Some hardware devices are also quite annoyingly locked-down, such as Xiaomi phones that at least for a while have refused to allow you to toggle on remote debugging via USB unless you install a SIM card. Fortunately this could be circumvented by clicking through an alternate path that the Xiaomi developers had not locked down, but these are just some of the obnoxious hurdles that you may encounter with real hardware.

With that out of the way, deploying to an AVD or real device is basically the same, either by using the ‘Start’ or similar function in your IDE of choice with the target device selected, or by doing so via the command-line, either with ADB, or via the Gradle wrapper with ./gradlew InstallDebug or equivalent.

This will of course be a debug build, with creating a release build also being an option, but this will not be signed by default. Signing an APK requires a whole other procedure, and is honestly something that’s best done via the friendly-ish dialogs in an IDE, rather than by burning a lot of time and sanity on the command-line. Whether you want to sign the APK or app bundle depends mostly on your needs/wants and what a potential app store demands.

Ever since Google began to demand that all developers – including Open Source hobbyists – send in a scan of their government ID and full address, I have resorted to just distributing the Android builds of my NymphCast player and server via GitHub, from where they can be sideloaded.

This NymphCast server is incidentally the topic of the next installment in this mini-series, in which we will be doing a deep dive into native Android development using the NDK.

hackaday.com/2025/09/04/bootst…

Microsoft ha ufficialmente reso pubblico il codice sorgente della sua prima versione di BASIC per il processore MOS 6502, che per decenni è esistito solo sotto forma di fughe di notizie, copie da museo e build non ufficiali. Ora, per la prima volta, è pubblicato con licenza libera e disponibile per studio e modifica.

La prima versione del BASIC di Microsoft apparve nel 1975 per il microcomputer Altair 8800 basato sul processore Intel 8080. Fu scritta dai fondatori dell’azienda, Bill Gates e Paul Allen. Un anno dopo, Gates, insieme al secondo dipendente Microsoft, Rick Weiland, portò il BASIC sul processore MOS 6502. Nel 1977, Commodore acquistò la licenza per 25.000 dollari e la integrò nei suoi sistemi PET, VIC-20 e Commodore 64.

Gli ultimi due computer vendettero milioni di copie e divennero uno dei fattori determinanti nella diffusione di massa della tecnologia informatica.

La versione 1.1 è stata resa pubblica, tenendo conto dei miglioramenti al garbage collector proposti dall’ingegnere Commodore John Feagans e dallo stesso Gates nel 1978. Nei dispositivi PET, questa versione era nota come BASIC V2. Il codice contiene 6.955 righe di assembler è pubblicato su GitHub con licenza MIT, che ne consente l’uso e la rivendita senza restrizioni.

Microsoft ha fornito al repository note storiche e commit eseguiti con timestamp di “48 anni fa”. Il codice sorgente implementa la compilazione condizionale per diverse piattaforme dell’epoca: Apple II, Commodore PET, Ohio Scientific e KIM-1.

Le funzionalità includono un set completo di operatori BASIC, supporto per array, gestione delle stringhe, aritmetica in virgola mobile, I/O, garbage collection delle stringhe e archiviazione dinamica delle variabili.

Particolare enfasi è posta sull’uso efficiente della memoria, fondamentale per i sistemi a 8 bit. Il codice contiene anche gli Easter egg di Bill Gates, nascosti nelle etichette STORDO e STORD0, confermati dallo stesso Gates nel 2010.

Il MOS 6502, per il quale fu creato l’interprete, divenne una leggenda del settore.

Fu la base dell’Apple II, delle console di gioco Atari 2600 e NES e di un’intera linea di home computer Commodore. La semplicità e l’efficienza dell’architettura lo resero popolare tra i produttori e influenzarono la formazione del mercato dei personal computer. Oggi, l’interesse per il 6502 non accenna a diminuire: gli appassionati creano repliche FPGA, sviluppano emulatori e persino preparano una nuova riedizione “ufficiale” del Commodore 64 basata su logica programmabile.

Microsoft sottolinea che è stato il BASIC a rendere l’azienda un attore significativo sul mercato, molto prima della comparsa di MS-DOS e Windows. La concessione in licenza di massa di questo interprete da parte di vari produttori è diventata il fondamento del modello di business di Microsoft nei suoi primi anni.

Dal 1977 a oggi, il BASIC continua a vivere: dal cursore lampeggiante sullo schermo del Commodore alle versioni FPGA del 2025. Oggi, il codice storico non solo viene preservato, ma anche trasferito nelle mani della comunità, per studio, adattamento e nuovi esperimenti gratuiti.

L'articolo Dal Commodore 64 a GitHub! Il BASIC di Gates e Allen diventa open source dopo 48 anni proviene da il blog della sicurezza informatica.