A few years ago, I bought an 8 mm home movie camera in a second hand store. I did a teardown on it here and pulled out for your pleasure those parts of it which I considered interesting. My vague plan was to put a Raspberry Pi in it, but instead it provided a gateway into the world of 8mm film technology. Since then I’ve recreated its Single 8 cartridge as a 3D printable model, produced a digital Super 8 cartridge, and had a movie camera with me at summer hacker camps.

When I tore down that Single 8 camera though, I don’t feel I did the subject justice. I concentrated on the lens, light metering, and viewfinder parts of the system, and didn’t bring you the shutter and film advance mechanism. That camera also lacked a couple of common 8 mm camera features; its light metering wasn’t through the lens, and its zoom lens was entirely manual. It’s time to dig out another 8 mm camera for a further teardown.

A Different Camera To Tear Down

The camera with a Super 8 cartridge inserted.

My test camera is a battered and scuffed Minolta XL-250 that I found in a second hand store for not a lot. It takes Super 8 cartridges, of which I have an expired Kodachrome example for the pictures, and it has the advantage of an extremely well-thought-out design that makes dismantling it very easy. So out it comes to be laid bare for Hackaday.

Once the sides have come off the camera, immediately you can see a set of very early-70s-analogue PCBs containing the light metering circuitry. Typically this would involve a CdS cell and a simple transistor circuit, and the aperture is controlled via a moving coil meter mechanism. This camera also has a large mostly-unpopulated PCB, giving a clue to some of the higher-end features found on its more expensive sibling.

Turning our attention inside the camera to the film gate, we can see the casting the film cartridge engages with, and the frame opening for the shutter To the left of that opening is a metal claw that engages with the sprocket holes in the film, thus providing the primary film advancement. The metal claw is attached to a slider on the back of the film gate, which in turn is operated by the rotation of the shutter, which is the next object of our attention.

The shutter is a disc that spins at the frame rate, in this case 18 frames per second. It sits in the light path between the back of the lens system and the film gate. It has a segment cut out of the disc to let light through for part of the rotation, this is how it operates as a shutter. On its reverse is the cam which operates the slider for the film advancement claw, while its front is mirrored. This forms part of the through-the-lens light metering system which we’ll come to next.

The mirror on the front of the shutter is angled, which means that when the shutter is closed, the light is instead reflected upwards at right angles into a prism, which in turn directs the light to the light meter cell. The PCB on the other side must have a charge pump which takes this 18 Hz interrupted analogue signal and turns it into a DC to drive the moving coil mechanism. There’s a 10 uF capacitor which may be part of this circuit.

Finally, we come to the powered zoom feature that was missing from the previous camera. On the top of the camera is a W/T rocker, for Wide/Telephoto. that operates the zoom. It is connected to a set of levers inside the case, which emerge as a pin at the front of the camera below the lens. This engages with a small gearbox that drives a knurled ring on the lens body, and selects forward and reverse to turn the ring. It’s driven by the same motor as the shutter, so it only works when the camera is operating.

I hope this look at my Minolta has filled in some of the gaps left by the previous article, and maybe revealed that there’s more than meets the eye when it comes to 8 mm movies. Careful though. If you dip a toe into this particular puddle it may suck you in head first!

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.