iljitsch.com - retro

Vandaag is Teletext 45 jaar oud!

Tue, 01 Apr 2025 18:35:24 GMT

Op 1 april 1980 werd in Nederland Teletekst gelanceerd. Zelf maakte ik hier in 1983 kennis mee, en dit was voor het eerst dat ik digitale informatie waar ik zelf (in enige mate) keuze in had op mijn scherm zag verschijnen.

Bijna een halve eeuw later bestaat Teletext nog steeds in Nederland, waar de 101 toch het hoogste is wat je kan bereiken qua actueel nieuws.

Ik open de app meerdere keren per dag op mijn iPhone of iPad, en met enige regelmaat ook op mijn LG TV.

Soms moeten we toch stellen "less is more", waarbij de beperkingen uit de jaren '80 Teletext beter maken dan het wilde westen van het web.

More on optical disc longevity

Thu, 09 May 2024 13:23:07 GMT

Two years ago, I wrote a blog post on the longevity of optical media. Today, I found out that the Canadian government also has an interest in this topic and produced the following article: Longevity of Recordable CDs, DVDs and Blu-rays.

Much recommended if you're interested in the topic. However...

Although I'm sure their findings that a gold reflective layer is much, much better than silver / silver alloy / aluminium, I find their conclusions for "regular" CD-Rs, CD-RWs, DVD-RWs and DVD+RWs, based on accelerated aging tests, clash with my own experiences.

CD-RWs are rated for 20 to 50 years, but in my experience, those are not reliable at all, with most of them failing in well under 20 years. Rewritable DVDs are even worse, regularly failing immediately.

Mass manufactured read-only DVDs and BRs are listed as 10 - 20 years. I can't think of any of the about 200 that I have that fall in that age range failing to play because the disc was unreadable.

BD-REs (rewritable blu-ray discs) are listed as 10 - 20 years, which is not too bad, but BD-Rs only 5 - 10 years. I'm glad to report that my oldest ones, both two years old, still read without trouble, but this seems a very low number... especially for HTL discs that don't use organic dyes. Can it be right?

Also see this on M-DISC longevity.

→ The beauty of finished software

Wed, 01 Nov 2023 17:01:30 GMT

Finished software is software that’s not expected to change, and that’s a feature! You can rely on it to do some real work.

We need more of this.

But: how do you write software that will keep working for decades to come? Certainly don't look at Apple for this, they keep changing their CPU architectures every decade or so and after a transition period, the old stuff is dead.

Could WebAssembly be the solution? This is a pretty fast binary format that almost any programming language can be compiled to.

SQLite: add a powerful database engine to any app

Mon, 04 Sep 2023 14:51:39 GMT

When I was 24, I decided to give up my job and go to college and study computer science. If I'd have known how many database classes that involved, maybe I would have reconsidered.

Back then, we had a big server that ran a RDBMS (relational database management system) that hundreds of students all used together. These systems were big, complex and expensive. (Oracle made its fortune selling RDBMSes.) MySQL and PostgresQL are somewhat more streamlined free and open source RDBMSes. Much better, but firewalling, user authentication and backups are still somewhat of a headache. But hey, if you need a database, you need a database.

Enter SQLite.

Traditional RDBMSes are a service that you connect to over the network—even if the RDBMS runs on the local machine. SQLite, on the other hand, is just a (pretty small) library that you link to in your software, and all the database contents go into a single file stored on the local file system. But you still get a very complete implementation of SQL, the "structured query language" that is used to interact with most databases.

I find myself dealing with CSV files and the like pretty regularly. For just getting data in and out of applications, this is usually fine. But doing anything useful with CSV data in your own scripts or applications is a chore. With SQL, on the other hand, you can easily analyse and transform data, often with pretty simple SQL queries.

Compared to MySQL

In the past, I've installed MySQL on my laptop to some data analysis. Having to install a big piece of software and configuring a user account and permissions is less than ideal. With SQLite you just point to a local file and you're in business. If you know what you're doing, SQLite can also be a lot faster than many other database engines such as MySQL. (Although without grouping large numbers of insert statements into larger transactions SQLite will be slow.)

Se the page Appropriate Uses For SQLite on the SQLite website to learn when SQLite is a good fit and when it isn't. The main thing is that SQLite is not a good fit when the application needs to access the database over a network.

Using SQLite with PHP

Initially, it seemed that moving from MySQL to SQLite in PHP would be tricky. However, the basics are no issue at all. This is the simple way to use MySQL in PHP:

$db = mysqli_connect("localhost", "db_user", "secretpw", "db_name");
$result = $db->query("select * from pages where pagenum = $n");
while ($row = $result->fetch_assoc())
  echo json_encode($row);
$db->close();

That translates relatively neatly into SQLite:

$db = new SQLite3("content.db");
$result = $db->query("select * from pages where pagenum = $n");
if ($row = $result->fetchArray())
  echo json_encode($row);
$db->close();

The C API requires a few more steps to get things done, but doesn't look excessively complicated. However, MySQL and SQLite use different SQL dialects. So far, my main issue has been the missing left() and right() functions and the handling of dates/times. Especially adjusting a given date is done in rather different ways.

SQLite from the command line

You can directly interact with SQLite databases through the sqlite3 program that is installed by default on a good number of operating systems. You can download the Windows version from the sqlite.org version. And there's even an Amiga port. Sweet. Just type "sqlite3" followed by the filename of a database file and you're in business. SQLite 3 is open source, and interestingly, has no license: it's entirely in the public domain.

A features in SQLite that I really like is that you can read blobs from the file system in order to store them in a database table, and then later write those back to the file system:

insert into blobstore (id, data) values (1, readfile('Makefile')); select writefile('blob.bin', data) from blobstore where id = 1;

And another great feature of the command line sqlite3 program is that you can just call an editor to edit the contents of a field. This is especially useful if you store larger texts in a database. It works like this:

% sqlite3 test.db
SQLite version 3.28.0 2019-04-15 14:49:49
Enter ".help" for usage hints.
sqlite> update blobstore set data = edit(data, 'vi') where id = 1;

(Of course in general you'd probably edit text columns, not blob columns.)

Portability and easy backups

As mentioned before, SQLite stores an entire database, holding one or more tables and all the associated housekeeping, in a single file. So you can just copy that file to another computer, email it to someone, or use standard backup mechanisms to back it up. (Ok, it seems that backing up the database file while changes are being made is not 100% bullet proof, but it's close.)

The SQLite3 file format has been backward compatible since 2004, and it's 32/64-bit and big-endian/little-endian agnostic. This means you can just email a copy of a SQLite database to someone else, and they will be able to use it without trouble. And you can be fairly confident that several decades from now, it's still possible to retrieve data from an SQLite file.

SQLite has some interesting Unicode caveats, but I'll save those for a later post.

SDBox: a cheap SD card adapter for your Amiga

Mon, 21 Aug 2023 14:14:16 GMT

I was watching the videos on the BBC Master computer on the Adrian's Digital Basement Youtube channel. Adrian has cleaned up this old Acorn BBC Master, restored the keyboard to full functionality and then started to "Americanize" it by changing the power supply to use 120 V, and making the composite video NTSC rather PAL.

But what really peaked my interest is that he made a tiny little interface to hook up SD cards to the Master's user port. I think it only uses four wires. There's a very small circuit board, but that only has some resistors to adapt the user port's 5 V to the 3.3 V used by SD cards. Apparently, that's all the hardware you need for reading (and writing?) SD cards. Wow.

Digging a bit deeper, it looks like SD cards use the super simple Serial Peripheral Interface (SPI) interface/protocol as a lowest common denominator. And that is a protocol that you can bit bang with a few general purpose IO lines without trouble. That's going to be slow, but it'll still work.

So...

Could this also work on an Amiga?

One of the issues with Amigas is that none of their I/O options are in general use today. Getting data on and off your Amiga can be a challenge, especially for A500s without any additional hardware. So a simple way to read and perhaps write SD cards would be very welcome. Turns out, there are indeed cheap/easy solutions to use SPI in general or use SD cards with through the printer port on all Amigas (except for the A1000).

If you are inclined to build your own hardware, have a look at the SDBox-v2 github repository. You can also buy one premade for about 50 euros. And read this review to learn how well it works.

It does use an Arduino to translate the parallel I/O from the Amiga's printer port to SPI on the SD card side, though, no bit banging.

I'd say that with an A600 or A1200 you're better off with CF cards in the PCMCIA slot for about the same price, or perhaps a PCMCIA card network card with a driver off of Aminet.

I'd say that for an A500 or an A2000 without a harddrive, a Gotek floppy emulator is probably a better option. But for any non-A600/A1200 without a harddrive, the SDBox is a great solution because it lets you files that are larger than what fits on one floppy on your computer.