Project Dependencies

This document lists the software you might need to run the software produced by Cat's Eye Technologies. This includes interpreters and compilers for the programming languages our projects are written in, the platforms or operating systems that they run on, and libraries and tools they might require when run.

Some of these dependencies might be technologies which are, nowadays, considered historical. Legacy. Retro. Vintage. Old. These dependencies are listed at the bottom of this article, under Retro Dependencies and Retro Languages. For more information about Retrocomputing at Cat's Eye Technologies, see the Retrocomputing article.

Languages

ANSI C

Many of our C programs are written in C89, also colloquially known as "ANSI C". This is supported by many C compilers. Indeed, many C compilers understand an -ansi flag, as well as a -pedantic flag which makes them stick more closely to the letter of the ANSI C spec.

Some of our projects can be compiled as either ANSI C or C99. Often, ANSI C is selectable by setting the environment variable ANSI to YES while running the build command (which is often make.)

An older but still interesting link: C89 at clc-wiki.

C99

The disadvantage of ANSI C is that it defines only a very crude model of the world surrounding the program, and how the program can interact with it. For example, a program can sleep(), but with coarse granularity; it cannot sleep for less than 1 second. Interfaces and extensions that were added to various vendors' C language since ANSI C were collected into a new standard called C99, which improved on this.

Telling a C compiler that it should treat its input files as C99 is often done with a flag such as -std=c99.

Some of our projects can be compiled as either C99 or ANSI C. Often, C99 is the default, and ANSI C, if desired, must be selected explicitly when building.

Perl

Our Perl projects are written in Perl 5. For more precise version numbers they have been tested on, see The Cat's Eye Technologies Platform.

Python

Our Python projects are written in Python 3.x. Some of them (especially tools) are written so that they run under both Python 2.7 and Python 3.x. The ".x" in "3.x" is intentionally left ambiguous here; at the time of writing I typically use anything from Python 3.8 to Python 3.11 to run these things. For more precise information about version numbers they have been tested on, see The Cat's Eye Technologies Platform.

For links to additional Python resources, see the Python topic in The Glosscubator.

Lua

Lua is a lightweight scripting language.

Our Lua projects (barring any that may be in archived projects) are written in Lua 5.1 and tested with Lua 5.1.4.

Note that the 5.1.x series of Lua is not generally compatible with the 5.0.x series. (On the other hand, our 5.1 code appears compatible with 5.2 and 5.3, but we have not audited it.)

For running Lua programs on a web page, we use Fengari, a Lua VM written in JavaScript.

For links to additional Lua resources, see the Lua topic in The Glosscubator.

Scheme

Our Scheme projects are generally written in vanilla R5RS Scheme. Sometimes even R4RS Scheme. (And it should be noted that this is like saying "ATM Machine". But the alternatives all sound worse.) For more precise version numbers they have been tested on, see The Cat's Eye Technologies Platform.

For links to additional Scheme resources, see the Scheme topic in The Glosscubator.

Haskell

Haskell is a lazy functional language. Our Haskell projects try to come as close to Haskell 98 as humanly practicable, and use as few extensions as possible. (It's not humanly practicable to do without modules, so that is one area where we do feel we must go beyond Haskell 98.)

Most of our Haskell projects can run under Hugs, as well as under ghc 7.10 (see below for the reasons).

Implementation: ghc

The Glasgow Haskell Compiler is dangerously close to being "the" implementation of Haskell.

It also has an interpreter, ghci.

Implementation: hugs

hugs is a Haskell interpreter. It's used in The Cat's Eye Technologies Platform because, being written in C, it builds on NetBSD. (Boostrapping ghci there would, I imagine, be quite cumbersome.)

For running Haskell programs on a web page, we use the Haste compiler, a compiler that allows ghc to compile Haskell programs to JavaScript. Unfortunately it does not support any ghc after version 7, therefore we use a Docker image based on rwstauner/haste-compiler.

For links to additional Haskell resources, see the Haskell topic in The Glosscubator.

Erlang

Our Erlang projects are written in Erlang R16 and tested with Erlang/OTP R16B03-1.

Note that this is a pretty old version of Erlang at this point.

Note that the following paragraphs are sorely out of date.

Note that compiled Erlang modules are .beam files in the ebin directory. The source code lives in the src directory, and an Erlang compiler (such as the one which ships with Erlang/OTP) is required to build the modules.

Also note that the .beam files will have to be recompiled in order to run under recent versions (e.g. R13B) of Erlang/OTP, as the binary format has changed.

Also note there is a good chance that the sources will compile and run on an older version (say, R9C) of Erlang/OTP, but you may need to make some manual changes and system setup.

Bourne shell

We try to write our Bourne shell scripts to run on plain Bourne shell — nothing bash-specific. We try to test them on NetBSD for this purpose. As such, they run on the version of sh that ships with NetBSD 6 (which might be ash.) For more precise version numbers they have been tested on, see The Cat's Eye Technologies Platform.

For links to additional Shell Scripting resources, see the Shell Scripting topic in The Glosscubator.

NASM

In our projects, many of these NASM files were converted from older assembly-language sources written in the syntax of Turbo Assembler 3.1 (an old-school x86 assembler for MS-DOS, written by Borland.) In some cases the Turbo Assembler sources are still included in the project for historical interest, but the newer NASM sources are what the binaries should be built from.

JavaScript

There is no implementation of JavaScript bundled with The Cat's Eye Technologies Platform. Some of our JavaScript scripts are "universal" and will run under nodejs, but we don't have a versioning plan for those yet. Most of our JavaScript is intended to run in the browser and is simply kept reasonably up-to-date with current browsers. (At any given time, your mileage may of course vary.)

For links to additional JavaScript resources, see the JavaScript topic in The Glosscubator.

Java

Our Java projects are, as far as I can recall, written in Java 1.6. They have not been tested recently, but when they were, it might have been under the Java SE 6 JDK 1.6.0.

An implementation of Java is not included with The Cat's Eye Technologies Platform.

Generally, we're trying to migrate away from it. Etcha was originally written in Java, but it now has a second implementation in JavaScript. yoob is written in Java, and our implementation of several esolangs is only in yoob; but none of Cat's Eye Technologies' languages is implemented solely in yoob anymore.

Our few installations that are Java Applets have been converted into Java Web Start applications, since Java Applets are on the obsolescence track.

If you want to try installing a Java Runtime, you can apparently download a Java Runtime, after you have agreed to the "Oracle Binary Code License Agreement for Java SE".

Ruby

Some of our projects have some stuff written in Ruby — we implemented Thue in Ruby, and Castile can output Ruby — but nothing we've written relies on Ruby. (The original version of Velo was written in Ruby, but it was re-implemented in Lua.)

Therefore an implementation of Ruby is not included with The Cat's Eye Technologies Platform.

But the Ruby things should run in Ruby 1.8 or 1.9 or thereabouts, which you could once have downloaded here if you agreed to this BSD-compatible license but apparently 1.9 is just too old and not maintained anymore.

Anyway, here is a fairly good Ruby tutorial.

Ophis Assembler

Ophis is an assembler (and its concomitant assembly language) for the 6502 and related processors, which some of our 6502 code is written in.

Tools and Libraries

make

make is a tool for orchestrating builds.

Parsec

Parsec is a parser combinator library for Haskell.

realpath

realpath is a tool that reports the real, symbolic-link-free path for a filepath which may contain symbolic links.

I'm not sure if it's part of any standard, but it really should be, because it's very useful in scripts. It does come bundled with many Linux distributions, but not with NetBSD, so for The Cat's Eye Technologies Platform, we wrote our own implementation in Python.

Interfaces

ANSI Terminal

When a project claims it needs this to run, it needs to run in a terminal which understand the ANSI terminal control codes (more formally known as "ECMA-48") in order for their output to be intelligible. Almost all modern consoles and terminal emulators understand these codes, sometimes under the guise of a particular terminal standard which includes them, such as vt100 or vt220. For older MS-DOS systems, a driver such as ANSI.SYS may need to be loaded.

Music Formats

Here are various formats in which the Musical Compositions have been recorded, and/or software that plays and/or edits music in these formats. Indeed, sometimes the format is named after the software.

Sidplayer

This was a popular-ish music format for the Commodore 64. The names of these music files, by convention, ended in .MUS. There was a player for this format called SidPic, which could also play "sing-along" lyrics files, and display pictures; as of this writing, several versions of this player are available from the Commodore Software website, for example see the entry for SidPic v3.4. There was also an editor for this this format called Sidplayer Editor -- probably an early version of Enhanced Sidplayer Editor -- which was a huge program which was written largely in Commodore BASIC 2.0 with a few machine-language subroutines.

MIDI

This one's pretty well standardized, I think.

I did a lot of MIDI sequencing with a Roland JV-30 and Cakewalk, back in the Windows 95 era.

MIDI files can be rendered to digital audio using a "soundfont" such as "freepats" and a renderer like TiMidity++.

DMCS

By Electronic Arts. For the Amiga and the Apple Macintosh.

It could export to MIDI.

Noisetracker MOD

This is what we talk about when we talk about MOD files, I think.

There's an open-source audio player called xmp that can play MED, Noisetracker MOD, and many other formats.

MED

Amiga. The editor is called MED. There was a MED Player.

MED has a "transpose" command, but not all players honour it, and when they don't, well, one of the voices is in the wrong key.

There's an open-source audio player called xmp that can play MED, Noisetracker MOD, and many other formats.

Sonant Tracker Format

Sonant Live runs in a browser (JavaScript and HTML5) and synthesizes its voices. There is also a Sonant Tracker which uses the same format and runs on Windows.

Retro Dependencies

Apple II

Rundown: The Apple II series of microcomputers included the Apple ][+ and Apple //e. The CPU was a 6502. Applesoft BASIC was often in the ROM, but it could have been loaded from tape or disk.

Emulators: AppleWin is an emulator for the Apple II, built for Windows, written in C++ and distributed under the GPL. linapple is a port of AppleWin to Linux. zophar.net has a list of other emulators. For the more casual observer, our Apple II artefacts are all archived on the Internet Archive, and can be experienced online in your web browser using the emulation facilities provided there.

For links to additional Apple II resources, see the Apple II topic in The Glosscubator.

Commodore VIC-20

Rundown: The CPU was a 6502. Commodore BASIC 2.0 was in the ROM; this is the same BASIC that was in the Commodore 64.

Emulators: The xvic executable from VICE, written in C99 and distributed under the GPL, is a generally recommended emulator for the VIC-20, should you wish to run these artefacts locally. For the more casual observer, our VIC-20 artefacts are all archived on the Internet Archive, and can be experienced online in your web browser using the emulation facilities provided there.

For links to additional VIC-20 resources, see the VIC-20 topic in The Glosscubator.

Commodore 64

Rundown: The CPU was a 6510, which was a slightly modified 6502. Commodore BASIC 2.0 was in the ROM; this is the same BASIC that was in the VIC-20.

The Commodore 64 Programmer's Reference Guide is an invaluable reference (or is it merely a guide?). There was also a User's Guide. Lots of C64 stuff can also be found at zimmers.net.

Emulators: The x64 executable from VICE, written in C99 and distributed under the GPL, is a generally recommended emulator for the Commodore 64.

Previously, Cat's Eye Technologies was using its own fork of JaC64, a GPL'ed Java application which emulates a Commodore 64, to showcase our Commodore 64 artefacts as online installations. But then, as time passed, Java Applets died off, and though Java Web Start was a possible substitute, it was an obnoxious one. So today, our Commodore 64 artefacts are all archived on the Internet Archive, and can be experienced online in your web browser using the emulation facilities provided there.

For links to additional Commodore 64 resources, see the Commodore 64 topic in The Glosscubator.

6502

The common thread of the above 3 architectures is that they all have a 6502 processor.

Some things Cat's Eye Technologies has done (namely SixtyPical and SITU-SOL) have been 6502-specific, but not specific to any one computer architecture.

There are also a couple of C compilers that target 6502, famously cc65, but also scc6502, a Small-C for 6502 and LUnix.

For links to additional 6502 resources, see the 6502 topic in The Glosscubator.

Amiga 500

Rundown: The CPU was a Motorola 68000, but this could be upgraded to a 68020, etc (and needed to be if you wanted memory protection). It had many custom chips with colourful names such as "Angus" and "Paula".

AmigaDOS 1.3 (with a manual online here) was the version of Amiga's operating system which was current when the Amiga 500 was a really popular home computer — mostly for video games, but also for graphics and video processing, such as ray-tracing and animation.

AmigaBasic was the name of the "advanced" variant of BASIC that shipped with AmigaDOS. It was developed by Microsoft.

Emulators: There's an emulator for the Amiga 500 architecture (and several other models such as the Amiga 2000) called UAE. It's written in C++ and available under the GPL, and while the build of it for windows, WinUAE, seems basically stable, every decade or so the Unix version gets forked into a new incarnation. A few years ago, E-UAE was the thing to use, but now it's apparently FS-UAE. Last I tried it, E-UAE still worked for me, but I have had mixed experiences trying to build it over the years.

IBM PC compatible

Rundown: The CPU was a 8086, or 80286, 80386, 80486... or just "X86". Or "IA-32". Until you get to the 64-bit architectures — but that's not retrocomputing anymore. (yet.)

For any Cat's Eye Technologies project that claims to run on an "IBM PC compatible," probably a 486 with a BIOS, keyboard, and basic VGA is the minimum to make it worthwhile.

Some modern PC's can handle running that sort of legacy setup, but most don't. Or at least, I wouldn't risk it anymore. Better to run it under an emulator.

Two good emulators are:

For more in-depth information on this wonderful architecture, see Blurry Memories of DOS Programming.

MS-DOS

Rundown: By Microsoft. Can run .BAT files. And x86 machine code .COM files.

DJGPP is a port of GCC to MS-DOS. Here is a random MS-DOS game programming link.

I wouldn't assume any modern Windows installation can handle running MS-DOS programs directly anymore. Better to run it under an emulator.

Emulators: there are a few recommended choices here:

For more in-depth information on programming for this wonderful operating system, see Blurry Memories of DOS Programming.

Any Cat's Eye Technologies project which claims to need MS-DOS only needs something which emulates MS-DOS sufficiently well. This includes both the standard DOS INT 21h handler, and the standard DOS utilies like, for example, TYPE and DEBUG.COM.

(There are only two projects of Cat's Eye Technologies' that require MS-DOS (or a compatible operating system) anymore, and these dependencies are only partial.)

For links to additional DOS resources, see the DOS topic in The Glosscubator.

Z80

The Z80 is another 8-bit CPU that was popular.

Here are some links:

Z-Machine

It's actually a virtual machine designed by Infocom so they could port their interactive fiction onto a multitude of home computers.

Here are its specifications documents.

Emulators: ZPlet is a Java application which emulates a Z-Machine. There are other, much better emulators, such as Frotz.

Retro Languages

BASIC

There are lots and lots and lots of variants of BASIC. Some of our projects are written in Commodore BASIC 2.0. Others are written in Applesoft BASIC.

For links to additional BASIC resources, see the BASIC topic in The Glosscubator.

Commodore BASIC 2.0

The dialect of BASIC that shipped with the Commodore 64 and Commodore VIC-20.

Applesoft BASIC

This was a dialect of BASIC that was available for (in fact, generally shipped with) the Apple II. There is a manual online here. There was also an "Integer Basic".