Porting COBOL Code And The Trouble With Ditching Domain Specific Languages

April 16, 2025 by Maya Posch 80 Comments

Whenever the topic is raised in popular media about porting a codebase written in an ‘antiquated’ programming language like Fortran or COBOL, very few people tend to object to this notion. After all, what could be better than ditching decades of crusty old code in a language that only your grandparents can remember as being relevant? Surely a clean and fresh rewrite in a modern language like Java, Rust, Python, Zig, or NodeJS will fix all ailments and make future maintenance a snap?

For anyone who has ever had to actually port large codebases or dealt with ‘legacy’ systems, their reflexive response to such announcements most likely ranges from a shaking of one’s head to mad cackling as traumatic memories come flooding back. The old idiom of “if it ain’t broke, don’t fix it”, purportedly coined in 1977 by Bert Lance, is a feeling that has been shared by countless individuals over millennia. Even worse, how can you ‘fix’ something if you do not even fully understand the problem?

In the case of languages like COBOL this is doubly true, as it is a domain specific language (DSL). This is a very different category from general purpose system programming languages like the aforementioned ‘replacements’. The suggestion of porting the DSL codebase is thus to effectively reimplement all of COBOL’s functionality, which should seem like a very poorly thought out idea to any rational mind.

Continue reading “Porting COBOL Code And The Trouble With Ditching Domain Specific Languages” →

Revision D PCB of Mockingboard with GI AY-3-8913 PSGs.

Something Is Very Wrong With The AY-3-8913 Sound Generator

April 15, 2025 by Maya Posch 14 Comments

The General Instruments AY-3-8910 was a quite popular Programmable Sound Generator (PSG) that saw itself used in a wide variety of systems, including Apple II soundcards such as the Mockingboard and various arcade systems. In addition to the Yamaha variants (e.g. YM2149), two cut-down were created by GI: these being the AY-3-8912 and the AY-3-8913, which should have been differentiated only by the number of GPIO banks broken out in the IC package (one or zero, respectively). However, research by [fenarinarsa] and others have shown that the AY-3-8913 variant has some actual hardware issues as a PSG.

With only 24 pins, the AY-3-8913 is significantly easier to integrate than the 40-pin AY-3-8910, at the cost of the (rarely used) GPIO functionality, but as it turns out with a few gotchas in terms of timing and register access. Although the Mockingboard originally used the AY-3-8910, latter revisions would use two AY-3-8913 instead, including the MS revision that was the Mac version of the Mindscape Music Board for IBM PCs.

The first hint that something was off with the AY-3-8913 came when [fenarinarsa] was experimenting with effect composition on an Apple II and noticed very poor sound quality, as demonstrated in an example comparison video (also embedded below). The issue was very pronounced in bass envelopes, with an oscilloscope capture showing a very distorted output compared to a YM2149. As for why this was not noticed decades ago can likely be explained by that the current chiptune scene is pushing the hardware in very different ways than back then.

As for potential solutions, the [French Touch] project has created an adapter to allow an AY-3-8910 (or YM2149) to be used in place of an AY-3-8913.

Top image: Revision D PCB of Mockingboard with GI AY-3-8913 PSGs.

Continue reading “Something Is Very Wrong With The AY-3-8913 Sound Generator” →

Plasmonic Modulators Directly Convert Terahertz Waves To Optical Signals

April 14, 2025 by Maya Posch 5 Comments

A major bottleneck with high-frequency wireless communications is the conversion from radio frequencies to optical signals and vice versa. This is performed by an electro-optic modulator (EOM), which generally are limited to GHz-level signals. To reach THz speeds, a new approach was needed, which researchers at ETH Zurich in Switzerland claim to have found in the form of a plasmonic phase modulator.

Although sounding like something from a Star Trek episode, plasmonics is a very real field, which involves the interaction between optical frequencies along metal-dielectric interfaces. The original 2015 paper by [Yannick Salamin] et al. as published in Nano Letters provides the foundations of the achievement, with the recent paper in Optica by [Yannik Horst] et al. covering the THz plasmonic EOM demonstration.

The demonstrated prototype can achieve 1.14 THz, though signal degradation begins to occur around 1 THz. This is achieved by using plasmons (quanta of electron oscillators) generated on the gold surface, who affect the optical beam as it passes small slots in the gold surface that contain a nonlinear organic electro optic material that ‘writes’ the original wireless signal onto the optical beam.

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” →