Reviving Interlisp With The Medley Interlisp Project

Within the Artificial Intelligence and natural language research communities, Lisp has played a major role since 1960. Over the years since its introduction, various development environments have been created that sought to make using Lisp as easy and powerful as possible. One of these environments is Interlisp, which saw its first release in 1968, and its last official release in 1992. That release was Medley 2.0, which targeted various UNIX machines, DOS 4.0, and the Xerox 1186. Courtesy of the Interlisp open source project (GitHub), Medley Interlisp is available for all to use, even on modern systems.

The documentation contains information on how to install Medley on Linux but also Mac and Windows (via WSL1 or WSL2). For those just curious to give things a swing, there’s also an online version you can log into remotely. What Medley Interlisp gets you is an (X-based) GUI environment in which you can program in Lisp, essentially an IDE with a debugger and the (in)famous auto-correction tool for simple errors such as typos, known as the DWIM (Do What I Mean), which much like the derived version in Emacs seeks to automatically fix simple issues like misspellings without forcing the developer to fix it and restart the compilation.

Thanks to [Pixel_Outlaw] for the tip and for also telling us about a project they wrote using Medley Interlisp for the Spring Lisp Game Jame 2023 titled Interlisp Fifteen Puzzle.

Miniware TS1C: A Cordless Soldering Iron With A Station

Most soldering irons in the market seem to fall into a few distinct categories. They either provide a full-blown station to which the soldering iron is wired, powered straight by mains, or an iron powered by DC power. The Miniware TS1C takes up an interesting position here in that it features both a station you put the iron into and adjust the temperature, as well as a fully cordless iron. Sounds too good to be true, perhaps, but a recent Tom’s Hardware review by [Les Pounder] seems to think it has real merit.

Behind the glossy exterior and marketing, we find a cordless soldering iron that uses a supercapacitor to power itself when it is not inserted into the station, with communication between the iron and station performed using Bluetooth. This way, you can keep an eye on both the tip temperature and the remaining charge left, which [Les] found to be sufficient for soldering about 80 smaller joints, with the marketing claiming it can solder 180 size 0805 SMD parts with one charge.

The advantage of having a station is that it is the part that is wired to a power bank or wall wart, with the temperature setting performed using a chunky dial. The station also provides a place for the iron in between soldering sessions, but in order to recharge the iron, the brass bands near the front have to be pushed into the holder for them to make contact. This also makes one-handed removal of the iron from the holder not as easy as you’d hope.

Continue reading “Miniware TS1C: A Cordless Soldering Iron With A Station”

Creating A Joule-Thomson Cryocooler And A Little Bit Of History At Home

The fun part about crycoolers is that there are so many different and exciting ways to make stuff cold, based on a wide variety of physics. This is why after first exploring the Stirling/GM cycle and vapor-compression to create a cryocooler that he could liquefy nitrogen with, [Hyperspace Pirate] is exploring a Joule-Thomson cooler, which is also misspelled as ‘Joule-Thompson’ by those who don’t mind take some liberties with history. Either way, the advantage of the adiabatic Joule-Thomson effect is that it is significantly simpler than the other methods — having been invented in the 19th century and used for the earliest forms of refrigeration.

This is what peak Joule-Thomson prototype cooler performance looks like.
This is what peak Joule-Thomson prototype cooler performance looks like.

The big difference between it and other technologies is that the effect is based on throttling the flow of a gas as it seeks to expand, within specific temperature and pressure ranges to ensure that the temperature change effect is positive (i.e. the temperature of the gas decreases). The net result is that of a cooling effect, which as demonstrated in the video can be used with successive stages involving different gases, or a gas mixture, to reach a low enough temperature at which nitrogen (contained in the same gas mixture) liquefies and can be collected.

Although not a very efficient process, if your local electricity costs allow it, running the compressor in a closed loop version isn’t that expensive and worth it for the science alone. Naturally, as with any experimental setup involving a range of gases, a compressor and other components, getting it to run perfectly on the first try is basically impossible, which is why this is so far Part 1 of another series on cryocoolers at home (or in the garage).

If you’re interested in the previous work [Hyperspace Pirate] has done with DIY cyrocoolers, take a look at our coverage from earlier this year.

Continue reading “Creating A Joule-Thomson Cryocooler And A Little Bit Of History At Home”

ITER Dreams And The Practical Reality Of Making Nuclear Fusion Work On Earth

Doing something for the first time is tough. Yet to replicate the nuclear fusion process that powers the very stars, and do it right here on Earth in a controlled and sustained fashion is decidedly at the top of the list of ‘tough’ first times. What further complicates matters is when in order to even get to this ‘first’ you also add in a massive, international construction project and a heaping of geopolitics, all of which is a far cry from past nuclear fusion experiments.

With the International Thermonuclear Experimental Reactor (ITER) as the most visible part of nuclear fusion research, it is perhaps little wonder that the recent string of delays and budget increases is leading some to proclaim doom and gloom over the entire sector. This ironically in contrast with the recent news from the US’s NIF and its laser-based inertial confinement fusion, which is both state-funded and will never produce commercial power.

In light of this, it feels pertinent to ask the question of whether ITER is the proverbial white elephant, or even the mausoleum of international science that a recent article in Scientific American makes it out to be. Is fusion research truly doomed to peter out amidst the seemingly never-ending work on ITER?

Continue reading “ITER Dreams And The Practical Reality Of Making Nuclear Fusion Work On Earth”

The I960: When Intel Almost Went RISC

The i960 KA/KB/MC/XA with the main functional blocks labeled. Click this image (or any other) for a larger version. Die image courtesy of Antoine Bercovici. Floorplan from The 80960 microprocessor architecture.
The i960 KA/KB/MC/XA with the main functional blocks labeled. Click this image (or any other) for a larger version. Die image courtesy of Antoine Bercovici. Floorplan from The 80960 microprocessor architecture.

From the consumer space it often would appear as if Intel’s CPU making history is pretty much a straight line from the 4004 to the 8080, 8088 and straight into the era of Pentiums and Cores. Yet this could not be further from the truth, with Intel having churned through many alternate architectures. One of the more successful of these was the Intel i960, which is also the topic of a recent article by [Ken Shirriff].

Remarkably, the i960 as a solid RISC (Reduced Instruction Set Computer) architecture has its roots in Intel’s ill-fated extreme CISC architecture, the iAPX 432. As [Ken] describes in his comparison between the i960 and 432, both architectures are remarkably similar in terms of their instruction set, essentially taking what it could from the 432 project and putting it into a RISC-y shape. This meant that although the i960 could be mistaken as yet another RISC CPU, as was common in the 1980s, but integrated higher-level features as well, such as additional memory protection and inter-process communication. Continue reading “The I960: When Intel Almost Went RISC”

Quantum Computing On A Commodore 64 In 200 Lines Of BASIC

The term ‘quantum computer’ gets usually tossed around in the context of hyper-advanced, state-of-the-art computing devices. But much as how a 19th century mechanical computer, a discrete computer created from individual transistors, and a human being are all computers, the important quantifier is how fast and accurate the system is at the task. This is demonstrated succinctly by [Davide ‘dakk’ Gessa] with 200 lines of BASIC code on a Commodore 64 (GitHub), implementing a range of quantum gates.

Much like a transistor in classical computing, the qubit forms the core of quantum computing, and we have known for a long time that a qubit can be simulated, even on something as mundane as an 8-bit MPU. Ergo [Davide]’s simulations of various quantum gates on a C64, ranging from Pauli-X, Pauli-Y, Pauli-Z, Hadamard, CNOT and SWAP, all using a two-qubit system running on a system that first saw the light of day in the early 1980s.

Naturally, the practical use of simulating a two-qubit system on a general-purpose MPU running at a blistering ~1 MHz is quite limited, but as a teaching tool it’s incredibly accessible and a fun way to introduce people to the world of quantum computing.

Four jumper wires with white heatshrink on them, labelled VCC, SCL, SDA and GND

Three Pitfalls In I2C Everyone Wishes Weren’t There

The best part of I2C is that it is a bus that is available just about anywhere, covering a vast ecosystem of devices that offer it as a hardware-defined interface, while being uncomplicated enough that it can also be implemented purely in software on plain GPIO pins. Despite this popularity, I2C is one of those famous informal standards that feature a couple of popular implementations, while leaving many of the details such as exact timing, bus capacitance and other tedious details to the poor sod doing the product development. Thus it is that we end up with articles such as a recent one on the tongue-twisting [pair of pared pears] blog, covering issues found while implementing an I2C slave.

As with any shared bus, whether multi-master or not, figuring out when the bus is clear is a fun topic, yet one which can cause endless headaches. One issue here comes from a feature that the SMBus version of I2C calls quick read/write. This allows for the rapid transfer of some data. Still, depending on the data returned by the slave, it may appear to the master that nothing is happening yet, since SDA is being held low by the slave until the stop condition, essentially locking the bus.

I2C hold times example.
I2C hold times example.

Where things get even more exciting comes generally in the form of what logic analyzers love to traumatically call a ‘spurious start/stop condition’. This refers to the behavior of SDA and SCL, with SDA going low before SCL indicating an error. This can occur due to a hold time that’s too low, causing other devices on the bus to miss the transition. Here SMBus defines a transition time of 300 ns, while I2C calls for 0 seconds, but it’s now suggested to delay calling a start/stop condition until a delay of 300 ns has passed. Essentially, it would seem that implementing a hold time is the way forward until evidence to the contrary appears.

The third pitfall pertains to the higher-speed modes of I2C, including Fast-Mode (FM) and Fast-Mode Plus (FM+). Backward compatibility with these higher speed versions is absent to spotty. Although FM+ (introduced by NXP in 2007) is supposed to be backward compatible with slower speeds, effectively the timing requirement differences between the FM+ and FM standards are too large to compensate for. At least in the current versions of the standards, but one of the joys of I2C is that there’s always another new set of revisions to look forward to.