Lotus 123 For Linux Is Like A Digital Treasure Hunt

Ever hear of Lotus 123? It is an old spreadsheet program that dominated the early PC market, taking the crown from incumbent Visicalc. [Tavis Ormandy] has managed to get the old software running natively under Linux — quite a feat for software that is around 40 years old and was meant for a different operating system. You can see the results in glorious green text on a black screen in the video below.

If you are a recent convert to Linux, you might not remember what a pain it was “in the old days” to install software. But in this case, it is even worse since the software isn’t even for Linux. The whole adventure started with [Tavis] wanting to find the API kit used to add plugins to Lotus. In theory, you could use it to add modern features to the venerable spreadsheet program.

The $395 software development kit wasn’t very common and there was also a Unix version of Lotus 123, but no one seemed to have a copy of that. [Tavis] eventually found someone who ran a circa-1990 BBS and had the data on tape. Turned out there was a hot copy of the SDK that he was able to use. But he noticed something else in the BBS’s list of files: the long-lost Unix version of Lotus!

An investigation found the installer used TD0 files which took some research. Luckily, a utility exists that can convert these to raw disk images. Inside was a very large object file. Apparently, in the days without dynamic loading, that object would be linked with plug in modules to install them.

The object file had all of its debugging information intact which shed a lot of light on the program’s internal operations. The old executables used COFF format but it is possible to relink it to an ELF file. Of course, it isn’t just that easy. [Tavis] wrote a small program to remove the old-style Unix system calls so they could be rerouted to Linux system calls. Some calls just pass through, but others need some translation due to differences in things like structure layout, sizes, and alignment.

In the end, it all worked but didn’t have a valid license. However, [Tavis] felt like since he did have a license and the software is abandoned, he was within his rights to crack the license check.

We are well-known abusers of spreadsheets around here. Of course, we aren’t the only ones.

Continue reading Lotus 123 For Linux Is Like A Digital Treasure Hunt”

Hack Another ELF On The Stack

[dropbear] recently found herself in a pickle. Dumping some data out of an Android app at a specific point for reverse engineering purposes. While it worked great in the simulator, it was painfully slow on hardware via lldb. The solution was to write a patch and apply it to the ELF file.

Writing the AArch64 assembly to dump the buffer is relatively trivial, but adding it to the existing ELF and repackaging it into a new APK leads to strange errors. The relative offsets into .rodata are now all wrong. For those who don’t routinely interface with the format of ELF files, we have a fantastic resource to take you into the dark depths. But the quick summary version is that sections contain various resources, and you find parts of those resources by relative offsets. The program header describes what type of resources each section contains.

[dropbear] found a NOTE section that just contained some metadata. She created a new section at the end of the file for her custom assembly and modified the header to declare the NOTE section as a LOAD section that pointed at her new section, which would get mapped into memory. All that was left to do was tweak the assembly in the actual code to jump to her new code that dumps. The BSS section was extended by a few bytes so that her program could store its state there.

It’s an impressive technique, and her program for modifying the program header is on her website under a BSD-3 license.

One Coder Is Porting Portal To The Nintendo 64

When Portal came out in 2007, developers Valve chose not to release the groundbreaking title on an obsolete Nintendo console long out of production. Nobody cared at the time, of course, but [James Lambert] is here to right that wrong. Yes, he’s porting Portal to the N64.

The port, or “demake,” as [James] calls it, has been under construction for some time. The project has posed some challenges: Portal was developed for PCs that were vastly more powerful than the Nintendo 64 of 1996. Thus, initial concerns were that the console wouldn’t be able to handle the physics of the game or render the recursive portal graphics.

However, hard work has paid off. [James] has chipped away, bit by bit, making improvements to his engine all the while. The latest work has the portals rendering nicely, and the companion cube works just the way you’d expect. There’s also a visible portal gun, and the engine can even render 15 recursive layers when looking through mirrored portals. Sixteen was too much.

Of course, there’s still lots to do. There’s no player model yet, and basic animations and sound are lacking. However, the core concept is there, and watching [James] flit through the not-quite-round portals is an absolute delight. Even better, it runs smoothly even on original Nintendo hardware. It’s a feat worthy of commendation.

We had no idea what [James] had in store back when we featured his work creating real-time shadows on N64 hardware. Now we know! Video after the break.

Continue reading “One Coder Is Porting Portal To The Nintendo 64″

Things Are Getting Rusty In Kernel Land

There is gathering momentum around the idea of adding Rust to the Linux kernel. Why exactly is that a big deal, and what does this mean for the rest of us? The Linux kernel has been just C and assembly for its entire lifetime. A big project like the kernel has a great deal of shared tooling around making its languages work, so adding another one is quite an undertaking. There’s also the project culture developed around the language choice. So why exactly are the grey-beards of kernel development even entertaining the idea of adding Rust? To answer in a single line, it’s because C was designed in 1971, to run on the minicomputers at Bell Labs. If you want to shoot yourself in the foot, C will hand you the loaded firearm.

On the other hand, if you want to write a kernel, C is a great language for doing low-level coding. Direct memory access? Yep. Inline assembly? Sure. Runs directly on the metal, with no garbage collection or virtual machines in the way? Absolutely. But all the things that make C great for kernel programming also make C dangerous for kernel programming.

Now I hear your collective keyboards clacking in consternation: “It’s possible to write safe C code!” Yes, yes it is possible. It’s just very easy to mess up, and when you mess up in a kernel, you have security vulnerabilities. There’s also some things that are objectively terrible about C, like undefined behavior. C compilers do their best to do the right thing with cursed code like i++ + i++; or a[i] = i++;. But that’s almost certainly not going to do what you want it to, and even worse, it may sometimes do the right thing.

Rust seems to be gaining popularity. There are some ambitious projects out there, like rewriting coreutils in Rust. Many other standard applications are getting a Rust rewrite. It’s fairly inevitable that the collection of Rust developers started to ask, could we invade the kernel next? This was pitched for a Linux Plumbers Conference, and the mailing list response was cautiously optimistic. If Rust could be added without breaking things, and without losing the very things that makes Rust useful, then yes it would be interesting. Continue reading “Things Are Getting Rusty In Kernel Land”

An ATTiny board that one of the students developed for this project, etched on single-sided FR4.

Electronics And C++ Education With An ATTiny13

When [Adam, HA8KDA] is not busy with his PhD studies, he mentors a group of students interested in engineering. To teach them a wide range of topics, he set out to build a small and entertaining embedded project as they watch and participate along the way. With this LED-adorned ATTiny13A project, [Adam] demonstrated schematic and PCB design, then taught C++ basics and intricacies – especially when it comes to building low-footprint software – and tied it all together into a real-world device students could take home after the project. His course went way beyond the “Hello world”s we typically expect, and some of us can only wish for a university experience like this.

He shares the PCB files and software with us, but also talks about the C++20 framework he’s developed for this ATTiny. The ATTiny13A is very cheap, and also very limited – you get 1K of ROM and 64 bytes of RAM. This framework lets you make good use of it, providing the basics like GPIO wiggling, but also things like low-power operation hooks, soft PWM with optional multi-phase operation support and EEPROM access. Students could write their own animations for this device, and he includes them in the repo, too!

In educational projects, it pays to keep code direct and clean, cruft-less and accessible to students. These are the things you can only achieve when you truly understand the tools you’re working with, which is the perfect position for teaching about them! [Adam] intends to show that C++ is more than suitable for low-resource devices, and tells us about the EEPROM class code he wrote – compiling into the same amount of instructions as an Assembly implementation and consuming the same amount of RAM, while providing compile-time checks and fail-safe syntax.

We’ve talked about using C++ on microcontrollers before, getting extra compile-time features without overhead, and this project illustrates the concept well. [Adam] asks us all, and especially our fellow C++ wizards, for our opinions on the framework he designed. Could you achieve even more with this simple hardware – make the code more robust, clean, have it do more within the limited resources?

What could you build with an ATTiny13, especially with such a framework? A flashy hairclip wearable, perhaps, or a code-learning RF-remote-controlled outlet. We’ve also seen a tiny camera trigger for endurance races,, a handheld Flappy Bird-like console, and many more!

Modifying Old Fonts In The Name Of Baseball

Baseball is in full swing again, and having recently accepted a position with Major League Baseball, [Ty Porter] is warming up with a big contribution to the MLB LED Scoreboard project — modifying 20-some old fonts to support baseball’s ‘ꓘ’ character that indicates a special strikeout with a called third strike (meaning the batter didn’t take a swing).

The problem is that Major League Baseball-the-entity recently deprecated the original data source for the scoreboard project. This called for a huge refactor of the codebase, including previously-patched fonts which were now showing either the font’s default no-character character, or nothing at all.

Fortunately, BDF font files are fairly human-readable and make reference to bitmap, which is an actual bitmap in hex. [Ty] settled on Unicode A4D8 (ꓘ), a character from the Tibeto-Burman language Lisu that certainly looks good enough to this baseball fan. Then it became a matter of mirroring the bitmap for ‘K’. [Ty] tried a few things like reversing the nibbles and looking up each one in a table, but that also mirrors the padding, which is bad news.

Then he tried not reversing the nibbles and just looked them up in a table, but this approach dropped and added bits unintentionally. Finally, he tried reversing the order, looking up the reversed nibble, and shifting each byte until there was no padding. This worked for most of the 20 fonts [Ty] patched. The others fell in line with some manual work.

Not much of a baseball fan? You’re almost guaranteed to like this one, especially if you hate mayo.

A modern Tamagotchi PCB design and built-up prototype

Classic Tamagotchi Is Reincarnated In Modern Hardware

If you thought that Tamagotchis were a late ’90s fad that has faded from most people’s memory by now, you’d be wrong: the franchise is still alive and well today, with new models being released regularly. But even the original model from 1996, known as Tamagotchi P1, is being kept alive by a small group of enthusiasts. When ROM dumps of the original hardware began floating around the internet a couple of years ago, even those without the real thing could run these virtual pets in an emulator.

But the whole idea of the Tamagotchi hardware was that it was portable enough to carry around anywhere. If you’re among those who missed that part of the Tamagotchi experience, you’ll be pleased to know that [JC] designed OpenTama: a portable hardware platform that runs an emulated version of the original Tamagotchi P1 software. It’s about as close as it gets to those first-generation virtual pets, but with several additions that make your life easier.

The software platform is [JC]’s TamaLib which we featured last year; in effect it’s an open-source emulator that allows the Tamagotchi ROM to run on a variety of modern hardware platforms. It also contains several additional options like the ability to save and restore your progress or to select customized ROMs. The OpenTama hardware, meanwhile, is a proper 21st-century reimplementation of the original: a small, egg-sized PCB sporting an STM32 microcontroller driving an LCD or OLED display, powered by a 100 mAh battery that can be recharged through a USB-C port.

OpenTama is not limited to the TamaLib software, either: as an open-source general-purpose platform, it can also be used as a learning tool for embedded programming, so if you’ve always wanted to program your own virtual pet, or are simply looking to build a fancy egg timer, OpenTama’s GitHub page is the way to go. We’ve seen quite a few neat Tamagotchi-like projects recently: this 3D-printed one comes with a nice retro LCD screen, while this one’s giant size ensures you don’t forget to feed it.

Continue reading “Classic Tamagotchi Is Reincarnated In Modern Hardware”