You probably don’t spend a lot of time using the FAT32 file system anymore, since it’s thoroughly been superseded many times over. Even so, Microsoft has seen fit to deliver an upgrade for FAT32 for the latest Windows 11 Insider Preview build. Finally, the stock Windows tools will let you format a FAT32 drive up to 2 TB instead of locking you to a 32 GB maximum!
The size limit was never baked into the FAT32 spec itself. With a 32-bit field for counting sectors, the file system supports up to 2 TB volumes with 512-byte sectors. However, as explained by former Microsoft developer [Dave Plummer], it just so happened that the 32 GB limit came about because of a random decision made when slapping together the Format dialogue box over 30 years ago.
The pending change was first announced in 2024, affecting the command line format tool as well. It’s actually been possible to create larger FAT32 volumes for some time, you just couldn’t easily do it with Microsoft’s standard formatting tools.
FAT32 is still a terrible file system to use in 2026, mostly because it has a hard limit on file size that tops out at 4 GB. It’ll ruin your life if you’re shooting HD or 4K video. We often don’t spend a lot of time musing over file systems in detail, but they’re right at the heart of everything we do on our computers on a daily basis. Sometimes, it bears thinking about!
It seems like everybody takes their turn doing an ESP32-based weather display, and why not? They’re cheap, they’re easy, and you need to start somewhere. With the Cheap Yellow Display (CYD) and modules like it, you don’t even need to touch hardware! [likeablob] had the CYD, and he’s showing weather on it, but the Cydintosh is a full Macintosh Plus Emulator running on the ESP32.
Honey, I stretched the Macintosh!
The weather app is his own creation, written with the Retro68k cross-compiler, but it looks like something out of the 80s even if it’s getting its data over WiFi. The WiFi connection is, of course, thanks to the whole thing running on an ESP32-S3. Mac Plus emulation comes from [evansm7]’s Micro Mac emulator, the same one that lives inside the RP2040-based PicoMac that we covered some time ago. Obviously [likeablob] has added his own code to get the Macintosh emulator talking to the ESP32’s wireless hardware, with a native application to control the wifi connection in System 3.3. As far as the Macintosh is concerned, commands are passed to the ESP32 via memory address 0xF00000, and data can be read back from it as well. It’s a straightforward approach to allow intercommunication between the emulator and the real world.
The touchpad on the CYD serves as a mouse for the Macintosh, which might not be the most ergonomic given the Macintosh System interface was never meant for touchscreens, but evidently it’s good enough for [likeablob]. He’s built it into a lovely 3D printed case, whose STLs are available on the GitHub repository along with all the code, including the Home Assistant integration.
In a move that’s no doubt going to upset and confuse many, Espressif has released its newest microcontroller — the ESP32-S31. The confusing part here is that the ESP32-S series was always the one based on Tensilica Xtensa LX7 cores, while the ESP32-C series was the one using RISC-V cores.
That said, if one looks at it as a beefier -S3 MCU it does have some appealing upgrades. The most obvious improvements are with the use of WiFi 6, as well as Bluetooth Classic and LE 5.4, including LE Audio. There is also Thread and Zigbee support for those who are into such things.
The Ethernet MAC got a bump from the 100 Mbit RMII MAC in previous MCUs and is now gigabit-rated, while the number of GPIO is significantly higher at 60 instead of 45 on the -S3. On the RAM side, things are mostly the same, except for DDR PSRAM support, with octal SPI offering up to 250 MHz compared to 80 MHz on the -S3.
On the CPU side the up-to-320 MHz RISC-V cores are likely to be about as powerful as the 240 MHz LX7 cores in the -S3, based on the ESP32-C series performance in terms of IPC. Overall it does seem like a pretty nice MCU, it’s just confusing that it doesn’t use LX7 cores with the series it was put into. When this MCU will be available for sale doesn’t seem to be known yet, with only samples available to select customers.
We don’t usually speculate on the true identity of the hackers behind these projects, but when [TN666]’s accoustic drone-detector crossed our desk with the name “Batear”, we couldn’t help but wonder– is that you, Bruce? On the other hand, with a BOM consisting entirely of one ESP32-S3 and an ICS-43434 I2S microphone, this isn’t exactly going to require the Wayne fortune to pull off. Indeed, [TN666] estimates a project cost of only 15 USD, which really democratizes drone detection.
It’s not a tuba– Imperial Japanese aircraft detector being demonstrated in 1932. Image Public Domain via rarehistoricalphotos.com
The key is what you might call ‘retrovation’– innovation by looking backwards. Most drone detection schema are looking to the ways we search for larger aircraft, and use RADAR. Before RADAR there were acoustic detectors, like the famous Japanese “war tubas” that went viral many years ago. RADAR modules aren’t cheap, but MEMS microphones are– and drones, especially quad-copters, aren’t exactly quiet. [TN666] thus made the choice to use acoustic detection in order to democratize drone detection.
Of course that’s not much good if the ESP32 is phoning home to some Azure or AWS server to get the acoustic data processed by some giant machine learning model. That would be the easy thing to do with an ESP32, but if you’re under drone attack or surveillance it’s not likely you want to rely on the cloud. There are always privacy concerns with using other people’s hardware, too. [TN666] again reached backwards to a more traditional algorithmic approach– specifically Goertzel filters to detect the acoustic frequencies used by drones. For analyzing specific frequency buckets, the Goertzel algorithm is as light as they come– which means everything can run local on the ESP32. They call that “edge computing” these days, but we just call it common sense.
The downside is that, since we’re just listening at specific frequencies, environmental noise can be an issue. Calibration for a given environment is suggested, as is a foam sock on the microphone to avoid false positives due to wind noise. It occurs to us the sort physical amplifier used in those ‘war tubas’ would both shelter the microphone from wind, as well as increase range and directionality.
[TN] does intend to explore machine learning models for this hardware as well; he seems to think that an ESP32-NN or small TensorFlow Lite model might outdo the Goertzel algorithm. He might be onto something, but we’re cheering for Goertzel on that one, simply on the basis that it’s a more elegant solution, one we’ve dived into before. It even works on the ATtiny85, which isn’t something you can say about even the lightest TensorFlow model.
Thanks to [TN] for the tip. Playboy billionaire or not, you can send your projects into the tips line to see them some bat-time on this bat-channel.
We’re used to electronic parts of the same type staying predictably the same, sometimes over many years. An early Z80 from the mid 1970s can be exchanged with one from the end of production a few years ago, for example. This week, we’ve had DMs from several readers who’ve found that this is not always the case, and the culprit is surprising. Espressif has released a new revision of their P4 application processor, and though it’s ostensibly the same, there are a couple of changes that have been catching people out.
The changes lie in both hardware and software, in that there’s a pin that’s changed from NC to a power rail, a few extra passives are needed, and firmware must be compiled separately for either revision. The problem is that they are being sold as the same device and appear in some places under the same SKU! This is leading to uncertainty as to which P4 revision is in stock at wholesalers. We’ve been told about boards designed for the old revision being assembled with the new one, a situation difficult to rework your way out of. Designers are also left uncertain as to which firmware build is needed for boards assembled in remote factories.
The ESP32-P4 is an impressive part for its price, and we’re sure that we’ll be seeing plenty of projects using this new revision over the coming years. We’re surprised that it doesn’t have a different enough part number and that the wholesalers have seemingly been caught napping by the change. We’re told that some of the well-known Chinese assembly houses are now carrying the two chips as separate SKUs, but that’s scant consolation for a designer with a pile of boards carrying the wrong part. If you’re working with the P4, watch out, make sure your board is designed for the latest revision, and ask your supplier to check which chips you’ll get.
[Jakub] is a musician, and found himself in need of a simple way to trigger samples via MIDI when on stage. So many commercial solutions exist, but most were overkill for the job or too messy and complicated to justify their use in a live environment. Thus, [Jakub] worked up Samplotron to do exactly the job needed with a minimum of fuss.
The project is based around the ESP32. It’s effectively a lightweight hardware sampler that can trigger sounds on command via MIDI. Sample data is loaded from an SD card, which also stores the device configuration. The Samplotron plays back mono 16-bit WAV files at 44,100 Hz, delivering audio via an ES8388 audio codec module connected via I2S. Two encoders are used to control the device, with a menu system presented via an SSD1309 OLED screen. Samples can be loaded and managed via this interface, and it allows tweaks to be made to volume levels and one-shot/loop playback as needed. MIDI input to the device is simply handled via the onboard UART functionality of the ESP32 itself.
It’s a neat little bit of music hardware that does exactly what [Jakub] needs and nothing more. We’ve featured similar builds before, like this neat RP2040 soundboard. If you’re building rad custom hardware for your own musical adventures, we’d love to know all about it.
Most people love arcade games, but putting a full-sized arcade cabinet in the living room can lead to certain unpleasant complications. Ergo the market for fun-sized cabinets has exploded alongside the availability of cheap SBCs and MCUs that can run classical arcade titles. Microcontrollers like the ESP32 with its dual 240 MHz cores can run circles around the CPU grunt of 1980s arcade hardware. Cue [Till Harbaum]’s Galagino ESP32-based arcade emulator project, that recently saw some community versions and cabinet takes.
There was a port to the PlatformIO framework by [speckhoiler] which also added a few more arcade titles and repurposed the enclosure of an off-the-shelf ‘My Arcade’ by stuffing in an ESP32-based ‘Cheap Yellow Display‘ (CYD) board instead. These boards include the ESP32 module, a touch display, micro SD card slot, sound output, and more; making it an interesting all-in-one solution for this purpose.
Most recently [Davide Gatti] and friends ported the Galagino software to the Arduino platform and added a 3D printed enclosure, though you will still need to source a stack of parts which are listed in the bill of materials. What you do get is a top display that displays the current game title in addition to the display of the usual CYD core, along with an enclosure that can be printed both in single- or multi-color.
There’s also a build video that [Davide Gatti] made, but it’s only in Italian, so a bit of a crash course in this language may be required for some finer details.
The size limit was never baked into the FAT32 spec itself. With a 32-bit field for counting sectors, the file system supports up to 2 TB volumes with 512-byte sectors. However, as explained by former Microsoft developer [Dave Plummer], it just so happened that the 32 GB limit came about because of a random decision made when slapping together the Format dialogue box over 30 years ago.
