Make Your Bookshelf Clickable

February 15, 2024 by Al Williams 21 Comments

We’ll confess that we have a fondness for real books and plenty of them. So does [James], and he decided he needed a way to take a picture of his bookshelves and make each book clickable to find more information. This is one of those things that sounds fairly simple until you decide to do it. You can try an example of the results and then go back and read about the journey it took to get there.

There are several subtasks involved. First, you want to identify each book’s envelope. It wouldn’t do to click on the Joy of Cooking and get information about Remembrance of Things Past.

The next challenge is reading the title of the book. This can be tricky. Fonts differ. The book could be upside down. Some titles go cross the spine, but most go vertically. The remainder of the task is fairly easy. If you know the region and the title, you can easily find a link (for Google Books, in this case) and build an SVG overlay that maps the areas for each book to the right link.

Continue reading “Make Your Bookshelf Clickable” →

Developing In Pascal On The Commodore 64 With Abacus Super Pascal 64

February 14, 2024 by Maya Posch 8 Comments

Abacus Super Pascal 64 for the Commodore 64.

Most people associate the Commodore 64 with Commodore BASIC and precompiled applications, but it also had a number of alternative development environments produced for it. One of these was Super Pascal 64 by Abacus. A solid introduction to this software package is provided in a video tutorial by [My Developer Thoughts] on YouTube. This uses the Abacus Super Pascal 64 software and manual from the [Lyon Labs] website, which incidentally has a lot more development environments and operating systems for the C64 listed for your perusal.

Abacus’ Super Pascal supports the official Pascal language, requiring nothing more than a Commodore 64 and two Commodore 1541 floppy disk drives to get started. One FDD is for the Super Pascal software, which boots into the development environment, the other FDD and the disks in it are the target for the current project’s source code and compiled binary. Although the lack of support for FDDs other than the 1541 is somewhat odd, this comes presumably from the operating system nature of the development environment and the 1541 being by far the most common FDD for the C64.

Continue reading “Developing In Pascal On The Commodore 64 With Abacus Super Pascal 64” →

How Many Time Zones Are There Anyway?

February 14, 2024 by Al Williams 34 Comments

Nowadays, it’s an even bet that your newest project somehow connects to the Internet and, thus, to the world. Even if it doesn’t, if you share your plans, someone might reproduce your creation in some far distant locale. If your design uses time, you might need to think about time zones. Easy, right? That’s what [Zain Rizvi] thought until he tried to deploy something that converted between timezones. You can learn from his misconceptions thanks to a detailed post he provides.

You might think, “What’s the big deal?” After all, there’s UTC, and then there are 12 time zones ahead of UTC and 12 time zones later. But that’s not even close to true.

As [Zain] found out, there are 27 hours in a full-day cycle if you count UTC as one hour. Why? Because some islands in the Pacific wanted to be on the wrong side of the International Date Line. So there are a few extra zones to accommodate them.

You can’t even count on time zones being offset by an hour from the previous zone. Several zones have a half-hour offset from UTC (for example, India’s standard time is 5.5 hours from UTC). But surely the offset is always either a whole number or a number where the fractional part is 0.5, right?

Um, no. Nepal wants the sun to be directly over the mountain at noon, so it offsets by 45 minutes! [Zain] wonders — as we do — what would happen if the mountain shifted over time? Until 1940, Amsterdam used a 20-minute offset. Some cities are split with one half in one time zone and another in the other.

Of course, there are the usual problems with multiple names for each zone, both because many countries want their own zone and because the exact same zone is different in different languages. Having your own zone is not just for vanity, though. Daylight savings time rules will vary by zone and even, in some cases, only in certain parts of a zone. For example, in the United States, Arizona doesn’t change to daylight savings time. Oh, except for the Navajo Nation in Arizona, which does! Some areas observe daylight savings time that starts and ends multiple times during the year. Even if you observe daylight savings time, there are cases where the time shift isn’t an entire hour.

Besides multiple names, common names for zones often overlap. For example, in the United States, the Eastern Standard Time zone differs from Australia’s. Confused? You should be.

Maybe we should have more respect for multiple time zone clock projects. We’ve noticed these problems before when we felt sorry for the people who maintain the official time zone database.

Benchmarking Latency Across Common Wireless Links For MCUs

February 11, 2024 by Maya Posch 13 Comments

Although factors like bandwidth, power usage, and the number of (kilo)meters reach are important considerations with wireless communication for microcontrollers, latency should be another important factor to pay attention to. This is especially true for projects like controllers where round-trip latency and instant response to an input are essential, but where do you find the latency number in datasheets? This is where [Michael Orenstein] and [Scott] over at Electric UI found a lack of data, especially when taking software stacks into account. In other words, it was time to do some serious benchmarking.

The question to be answered here was specifically how fast a one-way wireless user interaction can be across three levels of payload sizes (12, 128, and 1024 bytes). The effective latency is measured from when the input is provided on the transmitter, and the receiver has processed it and triggered the relevant output pin. The internal latency was also measured by having a range of framework implementations respond to an external interrupt and drive a GPIO pin high. Even this test on an STM32F429 MCU already showed that, for example, the STM32 low-level (LL) framework is much faster than the stm32duino one.

Continue reading “Benchmarking Latency Across Common Wireless Links For MCUs” →

The Usage Of Embedded Linux In Spacecraft

February 10, 2024 by Maya Posch 44 Comments

As the first part of a series, [George Emad] takes us through a few examples of the Linux operating system being used in spacecraft. These range from SpaceX’s Dragon capsule to everyone’s favorite Martian helicopter. An interesting aspect is that the freshest Linux kernel isn’t necessarily onboard, as stability is far more important than having the latest whizzbang features. This is why SpaceX uses Linux kernel 3.2 (with real-time patches) on the primary flight computers of both Dragon and its rockets (Falcon 9 and Starship).

SpaceX’s flight computers use the typical triple redundancy setup, with three independent dual-core processors running the exact same calculations and a different Linux instance on each of its cores, and the result being compared afterwards. If any result doesn’t match that of the others, it is dropped. This approach also allows SpaceX to use fairly off-the-shelf (OTS) x86 computing hardware, with the flight software written in C++.

NASA’s efforts are similar, with Ingenuity in particular heavily using OTS parts, along with NASA’s open source, C++-based F’ (F Prime) framework. The chopper also uses some version of the Linux kernel on a Snapdragon 801 SoC, which as we have seen over the past 72 flights works very well.

Which is not to say using Linux is a no-brainer when it comes to use in avionics and similar critical applications. There is a lot of code in the monolithic Linux kernel that requires you to customize it for a specific task, especially if it’s on a resource-constrained platform. Linux isn’t particularly good at hard real-time applications either, but using it does provide access to a wealth of software and documentation — something that needs to be weighed up against the project’s needs.

Breaking Through The 1 MB Barrier In DOS With Unreal Mode And More

February 9, 2024 by Maya Posch 17 Comments

The memory map of the original 8086 computer with its base and extended memory made the original PC rather straightforward, but also posed countless issues for DOS-based applications as they tried to make use of memory beyond the legacy 1 MB address space. The initial ways to deal with this like EMS, XMS and UMB were rather cumbersome and often impractical, but with the arrival of the 80286 and 80386 processors more options opened up, including protected mode. More interestingly, this led to unreal mode, DOS extenders and the somewhat more obscure LOADALL instruction, as covered by [Julio Merino] in a new article.

This article builds on the first one which covered the older methods and covered the basics of protected mode. Where protected mode is convenient compared to real mode is that with the former the memory accesses go via the MMU and thus allows for access to 16 MB on the 80286 and 4 GB on the 80386. The segment descriptors and resolving of these that make this possible can be (ab)used on the 80286 and up by realizing that these segment descriptors are also used in real mode. Unreal mode is thus about switching to protected mode, loading arbitrary segment descriptors and switching back to real mode. As this is outside the original processor spec, it is commonly called ‘unreal mode’.

Continue reading “Breaking Through The 1 MB Barrier In DOS With Unreal Mode And More” →

Ask Hackaday: What About Imperfect Features?

January 24, 2024 by Arya Voronova 24 Comments

Throughout the last few years’ time, I’ve been seeing sparks of an eternal discussion here and there. It’s a nuanced one, but if I could summarize, it’s about different feature development strategies we can follow to design things, especially if they’re aimed at a larger market. Specifically – when adding a feature, how complete and perfect should it be?

A while back, I read a Mastodon thread about VLC not implementing backwards per-frame skipping. At the surface level, it’s about an indignant user asking – what’s the deal with VLC not having a “go back a frame” button? A ton of video players have this feature implemented. There’s a forum thread linked, and, reading it could leave you with a good few conflicting emotions. Here’s a recap.

In what appears to be one of multiple threads asking about a ‘previous frame’ button in VLC, there’s an 82-post discussion involving multiple different VLC developers. The users’ argument is that it appears to be clearly technically possible to add a ‘previous frame’ button in practice, and the developers’ argument is that it’s technologically complex to implement in some cases – for certain formats, even impossible to implement! Let’s go into the developers’ stated reasoning in more details, then – here’s what you can find in the thread, to the best of my ability.

Continue reading “Ask Hackaday: What About Imperfect Features?” →