Using Azo Photoisomerization To Alter Semiconductor Film Properties

Generally semiconductor devices like transistors have fixed properties, but using an azobenzene (Azo) compound it’s possible to optically alter these properties by exposing them to UV light. This is demonstrated in a recent paper by [Jaehoon Ji] et al., as published in Science Advances, with accompanying coverage by Princeton University.

Building on previous research on e.g. flakes of MoS2 with photochromic Azo molecules, a functional semiconductor device was created. This uses a transition metal dichalcogenide (TMD) monolayer combined with the Azo compound, with the latter altering the electrical and optical properties of the structure.

In both n- and p-type FET semiconductors it was demonstrated using visible and UV light that this can alter the carrier densities in the material, effectively altering the FET’s behavior.

While this is of course just a proof of concept, it does show that by using (Azo) molecules that can respond to certain electromagnetic radiation frequencies, electric fields, temperature, etc. semiconductor devices can be created whose behavior dynamically changes with these factors. This could potentially provide new ways to make programmable circuits and sensors.

Emulating Memory Access: How Hard Can It Be?

There are so many things we approximate to make life simple. Wires, for example, have no resistance or other strange effects. Crystal oscillators output their exact frequency. But surely our model of how a computer stores and loads memory is accurate, right? You put data in a particular location and, later, you take it out. The [FEX-Emu] developers have a different perspective. Once you have caches and, perhaps, multiple CPUs, it isn’t that easy.

The basic problem is this: if one CPU (or, more accurately, bus master) writes to a location, will another CPU have access to the new value? X86’s Total Store Ordering model gives programmers strong guarantees about when loads and stores become visible, while ARM deliberately uses a weaker memory model that permits considerably more reordering for performance and efficiency.

An emulator can, in theory, compensate by translating ordinary x86 memory operations into ARM acquire/release operations, but doing that for nearly every memory reference can be expensive. Newer ARM extensions such as LRCPC help considerably, while Apple took a more direct approach by adding an x86-compatible TSO mode to Apple Silicon. That lets ordinary loads and stores behave the way translated x86 code expects with comparatively little overhead.

Continue reading “Emulating Memory Access: How Hard Can It Be?”

The Concertina Goes Electronic

The concertina is an instrument that features heavily in European folk music, of which there are a variety of types. [Xcott Craver] has built one, an anglo concertina of the type you may recognise accompanying sea shanties, but this is no ordinary squeezebox. Instead it’s an electronic concertina, and it’s a project with a significant attention to detail.

Perhaps the most obvious thing most of us know about a concertina is that it’s an instrument with two ends separated by a set of bellows, and manipulation of the bellows lends a lot to the music it produces. This instrument doesn’t have bellows, but its innovation is to simulate them through means of a load cell. The two sides of the wooden chassis are fixed, but the force exerted on them is measured.

The keys are Cherry MX switches with custom keycaps, mounted on a pair of PCBs. Driving the whole thing is a Teensy 4.0, and to avoid unfortunate accidents with ripped-out connectors there’s a USB extension lead as a bit of strain relief. You can hear the result in the video below.

This is like no other instrument we’ve seen here, though we’ve had a few electronically enhanced conventional concertinas and accordions. We like it for its interesting design.

Continue reading “The Concertina Goes Electronic”

On Chip Debug For (Some) MicroPython

If you’ve used MicroPython much, you know that debugging usually amounts to printing a few things out, trying your code out, and then repeating. But [ghi-electronics] wants you to have full on-chip source-code debugging in Visual Studio. You don’t need anything special to use it — just a supported MicroPython host and the same USB cable you program with now.

The downside is that you either have to build a custom MicroPython image and flash it or use one that they include. They support several Raspberry Pi Pico versions and ESP32 chips, as well. However, at least one “odd” Pico we had lying around wouldn’t take the firmware. A stock one did, and it worked as you would expect. A little more investigation showed the odd Pico (an RP2040 GEEK) probably did take the firmware; it just produced an error during setup. There is a known problem with Linux and the ESP32-S3 having similar behavior.

Continue reading “On Chip Debug For (Some) MicroPython”

Sony’s First Computer

In 1982, desktop computers were coming into their own, and no clear leaders had emerged. But everyone knew they wanted a piece of the action. This led to, among other things, Sony’s SMC-70, which, frankly, for 1982, was a good-looking, if not oddball, machine. [Tech Tangents] shows the machine off in a recent video.

From the front, the computer looks more-or-less like everything else. But as you move backward, you can see this computer wasn’t another typical entry into the market. One of the things that was the hallmark of successful business computers of the day was expandability. The earlier Altair had the later-titled S100 bus. The IBM PC had the ISA bus. But in both cases, you had to open the box to plug and unplug cards.

Continue reading “Sony’s First Computer”

Making A Digital Music Player For Cassette Decks

In the cross-over between the era of tapes into that of MP3s, you’d see quite a few of those special cassette tapes that were actually digital music players inside. Some simply provided a 3.5 mm input, while others were complete MP3 players or Bluetooth receivers that just happened to also output to the magnetic read head of a cassette player. Recently [Jonathan Rowny] decided to make his own version of the latter.

Although getting the actual audio signal into the read head is easy enough – requiring little more than its equivalent being used as a write head on the cassette side – actually interfacing with the player’s mechanisms like auto-stop, reverse and so on requires the use of some gearing that detect motion on what would be the tape spools, as well as transfer the motion from the take-up spool to the other spool so that features like the auto-stop mechanism don’t get triggered.

A lot of inspiration here can be found in e.g. the videos made by [Clint] of [Lazy Game Reviews] who looked at a number of examples – including their internals – over the years, with various levels of functionality. For this particular implementation an ESP32-S3 module is used for the brains, along with a microSD card reader for music and a PCM5102 I2S audio codec to create the analog audio signal.

The gears were printed using an SLA printer and seem to work all right. Unfortunately he didn’t realize the importance of the capstan as the mechanism that actually transports the tape, so its motion was not measured as is done in the better cassette adapters. This will likely be corrected in a future iteration, however.

Continue reading “Making A Digital Music Player For Cassette Decks”

Reconstructing A Pin On A Pin Grid Array Package

Before moving to land grid array (LGA) packaging whereby each pin on the substrate is just a copper pad, processors commonly used pin grid array (PGA) packaging, including the still highly relevant AMD AM4 socket. With PGA you get a pin soldered onto the copper pad which inserts into the ZIF socket, rather than a fragile pin on the mainboard side. Repairing a damaged PGA pin can be easy if just the pin broke off at the solder joint, or rough if the pad was destroyed, as in the case of this Pentium III CPU that [Bits und Bolts] recently tried to fix.

In the case of something like a ground pin or similarly unimportant pin you can ignore the damage, but in this case it concerned an important pin for this 1.2 GHz Tualatin PIII core, with the damage consisting of a well and truly destroyed pad. The first step to repair the damage is thus to try and rebuild the pad, which was done using solder mask and solder.

Although a PIII-era Celeron CPU is definitely not a high-value CPU, since they have so few and such large pins they do make for useful test subjects when it comes to PGA repair practicing. In this case the affected data pad and pin appears to have been repaired successfully, with it running overclocked to 1.6 GHz and crushing similarly or higher clocked Pentium 4 and AMD Athlon CPUs of the era.

Continue reading “Reconstructing A Pin On A Pin Grid Array Package”