A Tricky Commodore PET Repair And A Lesson About Assumptions

April 14, 2025 by Maya Posch 11 Comments

The PET opened, showing the motherboard. (Credit: Ken Shirriff)

An unavoidable part of old home computer systems and kin like the Commodore PET is that due to the age of their components they will develop issues that go far beyond what was covered in the official repair manual, not to mention require unconventional repairs. A case in point is the 2001 series Commodore PET that [Ken Shirriff] recently repaired.

The initial diagnosis was quite straightforward: it did turn on, but only displayed random symbols on the CRT, so obviously the ICs weren’t entirely happy, but at least the power supply and the basic display routines seemed to be more or less functional. Surely this meant that only a few bad ICs and maybe a few capacitors had to be replaced, and everything would be fully functional again.

Initially two bad MOS MPS6540 ROM chips had to be replaced with 2716 EPROMs using an adapter, but this did not fix the original symptom. After a logic analyzer session three bad RAM ICs were identified, which mostly fixed the display issue, aside from a quaint 2×2 checkerboard pattern and completely bizarre behavior upon running BASIC programs.

Using the logic analyzer capture the 6502 MPU was identified as writing to the wrong addresses. Ironically, this turned out to be due to a wrong byte in one of the replacement 2716 EPROMs as the used programmer wasn’t quite capable of hitting the right programming voltage. Using a better programmer fixed this, but on the next boot another RAM IC turned out to have failed, upping the total of failed silicon to four RAM & two ROM ICs, as pictured above, and teaching the important lesson to test replacement ROMs before you stick them into a system.

The ProStar: The Portable Gaming System And Laptop From 1995

April 13, 2025 by Maya Posch 5 Comments

Whilst recently perusing the fine wares for sale at the Vintage Computer Festival East, [Action Retro] ended up adopting a 1995 ProStar laptop. Unlike most laptops of the era, however, this one didn’t just have the typical trackpad and clicky mouse buttons, but also a D-pad and four suspiciously game controller looking buttons. This makes it rather like the 2002 Sony VAIO PCG-U subnotebook, or the 2018 GPD Win 2, except that inexplicably the manufacturer has opted to put these (serial-connected) game controls on the laptop’s palm rest.

Though branded ProStar, this laptop was manufactured by Clevo, who to this day produces generic laptops that are rebranded by everyone & their dog. This particular laptop is your typical (120 MHz) Pentium-based unit, with two additional PCBs for the D-pad and buttons wired into the mainboard.

Unlike the sleek and elegant VAIO PCG-U and successors, this Clevo laptop is a veritable brick, as was typical for the era, which makes the ergonomics of the game controls truly questionable. Although the controls totally work, as demonstrated in the video, you won’t be holding the laptop, meaning that using the D-pad with your thumb is basically impossible unless you perch the laptop on a stand.

We’re not sure what the Clevo designers were thinking when they dreamed up this beauty, but it definitely makes this laptop stand out from the crowd. As would you, if you were using this as a portable gaming system back in the late 90s.

Our own [Adam Fabio] was at VCF East this year as well, and was impressed by an expansive exhibit dedicated to Windows 95.

Continue reading “The ProStar: The Portable Gaming System And Laptop From 1995” →

Illustration of author surveying the fruits of his labor by Bomberanian

Learning Linux Kernel Modules Using COM Binary Support

April 13, 2025 by Maya Posch 17 Comments

Have you ever felt the urge to make your own private binary format for use in Linux? Perhaps you have looked at creating the smallest possible binary when compiling a project, and felt disgusted with how bloated the ELF format is? If you are like [Brian Raiter], then this has led you down many rabbit holes, with the conclusion being that flat binary formats are the way to go if you want sleek, streamlined binaries. These are formats like COM, which many know from MS-DOS, but which was already around in the CP/M days. Here ‘flat’ means that the entire binary is loaded into RAM without any fuss or foreplay.

Although Linux does not (yet) support this binary format, the good news is that you can learn how to write kernel modules by implementing COM support for the Linux kernel. In the article [Brian] takes us down this COM rabbit hole, which involves setting up a kernel module development environment and exploring how to implement a binary file format. This leads us past familiar paths for those who have looked at e.g. how the Linux kernel handles the shebang (#!) and ‘misc’ formats.

On Windows, the kernel identifies the COM file by its extension, after which it gives it 640 kB & an interrupt table to play with. The kernel module does pretty much the same, which still involves a lot of code.

Of course, this particular rabbit hole wasn’t deep enough yet, so the COM format was extended into the .♚ (Unicode U+265A) format, because this is 2025 and we have to use all those Unicode glyphs for something. This format extension allows for amazing things like automatically exiting after finishing execution (like crashing).

At the end of all these efforts we have not only learned how to write kernel modules and add new binary file formats to Linux, we have also learned to embrace the freedom of accepting the richness of the Unicode glyph space, rather than remain confined by ASCII. All of which is perfectly fine.

Top image: Illustration of [Brian Raiter] surveying the fruits of his labor by [Bomberanian]

Hacking A Cheap Rechargeable Lamp With Non-Standard USB-C Connector

April 12, 2025 by Maya Posch 40 Comments

Recently [Dillan Stock] bought a $17 ‘mushroom’ lamp from his local Kmart that listed ‘USB-C rechargeable’ as one of its features. Unfortunately while this is technically true, there’s a pretty major asterisk. This Inaya-branded lamp comes with a USB-C cable with a rather prominent label attached to it that tells you that this lamp requires that specific cable. After trying with a regular USB-C cable, [Dillan] indeed confirmed that the lamp does not charge from a standard USB-C cable. So he did what any reasonable person would do: he bought a second unit and set about to hacking it.

The "USB C" cable that comes with the Inaya Portable Rechargeable Lamp. (Credit: The Stock Pot, YouTube) — The “USB C” cable that comes with the Inaya Portable Rechargeable Lamp. (Credit: The Stock Pot, YouTube)

[Dillan] also dug more into what’s so unusual about this cable and the connector inside the lamp. As it turns out, while GND & VCC are connected as normal, the two data lines (D+, D-) are also connected to VCC. Presumably on the lamp side this is the expected configuration, while using a regular USB-C cable causes issues. Vice versa, this cable’s configuration may actually be harmful to compliant USB-C devices, though [Dillan] did not try this.

With the second unit in hand, he started hacking in earnest. The changes include a regular USB-C port for charging, an ESP32 board with integrated battery charger for the 18650 Li-ion cell of the lamp, and an N-channel MOSFET to switch the power to the lamp’s LED. He’s made the full plans and schematics available on his website.

With all of the raw power from the ESP32 available, the two lamps got integrated into the Home Assistant network which enables features such as turning the lamps on when the alarm goes off in the morning. All of this took about $7 in parts and a few hours of work.

Although we commend [Dillan] on hacking his device instead of just returning it to the store, it’s worrying that apparently there’s now a flood of ‘USB C-powered’ devices out there that come with non-compliant cables. It brings back fond memories of hunting down proprietary charging cables, which was the issue that USB power was supposed to fix.

Continue reading “Hacking A Cheap Rechargeable Lamp With Non-Standard USB-C Connector” →

Tracing The #!: How The Linux Kernel Handles The Shebang

April 11, 2025 by Maya Posch 9 Comments

One of the delights in Bash, zsh, or whichever shell tickles your fancy in your OSS distribution of choice, is the ease of which you can use scripts. These can be shell scripts, or use the Perl, Python or another interpreter, as defined by the shebang (#!) at the beginning of the script. This signature is followed by the path to the interpreter, which can be /bin/sh for maximum compatibility across OSes, but how does this actually work? As [Bruno Croci] found while digging into this question, it is not the shell that interprets the shebang, but the kernel.

It’s easy enough to find out the basic execution sequence using strace after you run an executable shell script with said shebang in place. The first point is in execve, a syscall that gets one straight into the Linux kernel (fs/exec.c). Here the ‘binary program’ is analyzed for its executable format, which for the shell script gets us to binfmt_script.c. Incidentally the binfmt_misc.c source file provides an interesting detour as it concerns magic byte sequences to do something similar as a shebang.

As a bonus [Bruno] also digs into the difference between executing a script with shebang or running it in a shell (e.g. sh script.sh), before wrapping up with a look at where the execute permission on a shebang-ed shell script is checked.

Creating A Somatosensory Pathway From Human Stem Cells

April 11, 2025 by Maya Posch No comments

Human biology is very much like that of other mammals, and yet so very different in areas where it matters. One of these being human neurology, with aspects like the human brain and the somatosensory pathways (i.e. touch etc.) being not only hard to study in non-human animal analogs, but also (genetically) different enough that a human test subject is required. Over the past years the use of human organoids have come into use, which are (parts of) organs grown from human pluripotent stem cells and thus allow for ethical human experimentation.

For studying aspects like the somatosensory pathways, multiple of such organoids must be combined, with recently [Ji-il Kim] et al. as published in Nature demonstrating the creation of a so-called assembloid. This four-part assembloid contains somatosensory, spinal, thalamic and cortical organoids, covering the entirety of such a pathway from e.g. one’s skin to the brain’s cortex where the sensory information is received.

Such assembloids are – much like organoids – extremely useful for not only studying biological and biochemical processes, but also to research diseases and disorders, including tactile deficits as previously studied in mouse models by e.g. [Lauren L. Orefice] et al. caused by certain genetic mutations in Mecp2 and other genes, as well as genes like SCN9A that can cause clinical absence of pain perception.

Using these assembloids the development of these pathways can be studied in great detail and therapies developed and tested.

Using Integer Addition To Approximate Float Multiplication

April 10, 2025 by Maya Posch 14 Comments

Once the domain of esoteric scientific and business computing, floating point calculations are now practically everywhere. From video games to large language models and kin, it would seem that a processor without floating point capabilities is pretty much a brick at this point. Yet the truth is that integer-based approximations can be good enough to hit the required accuracy. For example, approximating floating point multiplication with integer addition, as [Malte Skarupke] recently had a poke at based on an integer addition-only LLM approach suggested by [Hongyin Luo] and [Wei Sun].

As for the way this works, it does pretty much what it says on the tin: adding the two floating point inputs as integer values, followed by adjusting the exponent. This adjustment factor is what gets you close to the answer, but as the article and comments to it illustrate, there are plenty of issues and edge cases you have to concern yourself with. These include under- and overflow, but also specific floating point inputs.

Unlike in scientific calculations where even minor inaccuracies tend to propagate and cause much larger errors down the line, graphics and LLMs do not care that much about float point precision, so the ~7.5% accuracy of the integer approach is good enough. The question is whether it’s truly more efficient as the paper suggests, rather than a fallback as seen with e.g. integer-only audio decoders for platforms without an FPU.

Since one of the nice things about FP-focused vector processors like GPUs and derivatives (tensor, ‘neural’, etc.) is that they can churn through a lot of data quite efficiently, the benefits of shifting this to the ALU of a CPU and expecting (energy) improvements seem quite optimistic.