PCLinuxOS Magazine

PCLinuxOS

Mind Your Step: Vintage Computing on PCLinuxOS

by phorneker

Over the past few months, cybersecurity has been THE hot topic of discussion in media outlets covering technology and digital lifestyles worldwide. Frankly, I would like nothing better than to go a whole week without having to worry about cybercriminals stealing personal information and money. I am sure you will agree with me on that.

This month, I want to do something different. At the end of the last issue, I did an update on the Seeburg 1000 articles published some time ago.

YouTube has evolved into a streaming service. But then, it has always been a streaming service depending on how you use it. For example, you could stream a series of videos by simply creating and playing a playlist.

I find YouTube to be a useful tool for learning things, from the Dutch language to vintage tech.

What do TechMoan, the 8-Bit Guy, VWestlife, and LGR have in common? These are people who present forms of vintage technology on their YouTube channels.

My series on the Seeburg 1000 is one example of vintage technology brought to PCLinuxOS, and that is what I intend to do this month.

The repository contains a number of emulators that can be installed to emulate various vintage computers. The dosbox and dosemu packages alone can run applications designed for the IBM-PC/XT/AT and compatibles, which covers a wide range of computers built in the 1980s through the early 2000s.

The linapple package emulates the Apple II+, IIe, and IIc machines.

The vice package emulates the Commodore PET, 64, VIC-20, 128, Plus-4, and CBM2 (the last one having been sold mainly in the EU).

The beebem emulates the BBC Micro Model B, Model B+ and Master 128 machines built by Acorn.

If you are not familiar with Acorn Computers, this company was given the contract by the BBC to produce the BBC Micro series. This same company later on produced a line of RISC-OS machines (with the operating system distributed on ROM chipsets) as well as the microprocessors that powered them. The company today still makes microprocessors...the ones that now power the Raspberry PI kits as well as some smartphones built in the 2000s and early 2010s.

The hatari package emulates all of Atari's 16/32-bit machines from the original ST to the Falcon.

The fbzx package emulates various Sinclair ZX models.

The ep128emu package emulates the German made Enterprise 64/128 computer as well as the Sinclair ZX Spectrum 48/128 and the Amstrad CPC 464 computers.

If you really want to emulate the Amstrad machines, use the javacpc package instead. The javacpc package emulates the entire line of Amstrad machines of the 1980s, including the 464, the 664 and the 6128..

Linguistic note: The ZX in the Sinclair ZX is pronounced as "zed-ex", and not the letters "ZX".

I have discussed some of these machines this past year. Since then, new emulators have been added, some were updated, and some emulators are now accessible online rather than having to download and install emulators.

Recently, the Internet Archive made a large library of MS-DOS games available for playing on their website. These, of course, use dosbox configured as a web service. There is already an online arcade available with a similar MAME implementation, and the games available play the same way they did when they were in the arcades back in the day.

These emulators can run without having to create ROM images from the physical machines. This is important for legal reasons. The ROMS for the Sinclair and Amstrad machines have been freely and legally available for years. The same is true for the original Atari 800.
(The linapple package was developed without replicating the system ROMs.)

Unfortunately, the same cannot be said for the gaming console emulators. The ROM images for these machines are copyrighted material and in the US, you can be sued for copyright infringement if you download the ROM files (even if you actually own the machine.)

For what we have in the repository, there are enough emulators to implement vintage technology on PCLinuxOS. In addition, we also have VirtualBox and VMWare available for virtualization of x86 machines. Add that to what is available on the Internet Archive, almost anything is possible.

To some extent, I have covered the Atari ST series as well as the Amstrad machines in previous articles.

I have always been a fan of Atari computers, not so much as gaming machines, but as graphics machines. Programming graphics displays on the Atari has always been a breeze when compared to other popular home computers at that time.

Note: I am not talking about the IBM Personal Computer here. While the IBM-PC, XT, and AT were available, they were not commonly found in stores of that day, but instead in shops that specialized in business computers such as those that ran CP/M or were authorized IBM resellers.

Atari BASIC contains a boatload of commands that take advantage of the graphics capabilities of their 8-bit line of computers (including the 1200XL). Contrast that with the BASIC interpreter that came with the ever popular Commodore 64.

That machine came with Version 2.0 of Commodore BASIC, and to program graphics on that machine, you either needed to print strings with the graphics characters embedded in the strings, or you needed to program in 6502 assembly language (which also required knowledge of the memory maps of the Commodore machines to take advantage of the graphics capabilities). PETSCII is the variant of the ASCII character set that was found on Commodore machines starting with the PET Model 2001.

This limitation was circumvented by third party cartridges that supplemented the Commodore BASIC with graphics and sound commands with the extensions implemented on the cartridges.

Another way to overcome that limitation was to acquire a Commodore 128, which contains Version 7.0 of Commodore BASIC, which did take advantage of not only graphics and sound, but also facilitated some of the disk storage functions that were available to Commodore machines of that time.

Atari's 8-bit machines also had their own ASCII variant called ATASCII, which had graphics characters, which were rarely used since the Atari BASIC already took advantage of the 8-bit machine's graphics and sound capabilities.

VICE: Commodore History

The success of Commodore Business Machines was mainly due to the business decisions made by Jack Tramiel (with his last name pronounced as "tramel"). While the Apple II series, the Atari 800, the BBC Micro and Commodore PET/VIC-20/64 used variants of the 6502 chip, it was Commodore that purchased the manufacturer of the 6502 chips, namely MOS.

The reason for the purchase goes back to the days when Commodore was manufacturing calculators.

Texas Instruments manufactured the chips that went into the Commodore calculators. Wanting in on the success of the calculator market, TI raised the price of the chips to the point that almost put Commodore Business Machines out of business. By purchasing MOS (and acquiring the KIM computer that MOS had developed in the process), Commodore assured that the price of the chips needed to build the machines was well controlled.

This move allowed Commodore to manufacture the PET series, and later facilitated the popularity of the Commodore 64 by controlling the costs of manufacture to the point where the machines can sell as low as they did.

I was not a fan of Commodore machines until I watched 8-Bit Guy's videos about Commodore's line of computers and the history behind them.

The PET series was called the CBM series in Europe to avoid trademark infringement with Koninklijke Philips N.V. (translated to English as Royal Philips), which had a trademark with the name "PET" as part of one of that company's trademarks.

The Model 2001 had this for a keyboard. This layout looks and feels like a calculator, and that is because it is a remnant of Commodore's days of manufacturing calculators. (Try to make sense out of this one.)

To the immediate left of this keyboard was a built-in cassette recorder. The Tandy/Radio Shack's TRS-80 line of computers, the Apple II and II+, Timex/Sinclair machines, many MSX standard machines, the Amstrad line of 8-bit computers, the BBC Micro series (including the Acorn Electron), and even the IBM Model 5150 (PC), 5160 (XT), and PCjr had cassette ports that recorded to cassettes with analog audio signals.

8-Bit Commodore and Atari machines, however, recorded digital signals to cassettes so programs and their data could be reliable as cassettes can (and often do) wear out over time. Hence, Commodore and Atari produced their own cassette decks for their 8-bit machines.

The disk drives from these companies were built to similar standards for reliability of programs and data. These devices contained their own 6502 microprocessors that are dedicated to control of the disk heads when reading or writing to diskettes.

The same could not be said for the other lines of 8-bit computers as their disk controllers are part of the main system board.

Today, there are drive replacements for the 8-bit line of machines. These drives used the same SD/MMC cards found in today's phones, cameras, music players, etc. In fact, the Atari Flashback 9 series of retro gaming machines uses an SD card for expansion of its built-in game library (presuming that these games were properly licensed to begin with).

Later versions of the PET series contained a full keyboard that looks and feels like a real keyboard commonly found on terminals connected to mainframes of the day.

This series of computers were targeted for small business and education markets, and did rather well until their own Commodore 64 came into the market.

By that time, the education market started adopting the Macintosh platform. In the mid 1980s, the Macintosh LC (for Lower Cost) had the option of an Apple IIe on an expansion card that installed into the LC, making this a suitable option for educators who adopted the Apple II series line with a library of Apple II software.

Meanwhile the VIC-20 was introduced as a home computing option for those who are used to using the PET series of machines. A 22 column display with 23 rows of text and 3583 bytes of memory for Commodore BASIC 2.0 (the same version used in the Commodore 64) do not exactly make it comparable to the PET series (which had a 40x24 display for text on most PET models. The CBM2 had a proper 80 x 24 text display). In fact, this would create numerous (and rather obvious) issues with compatibility with PET software.

Thankfully, the Commodore 64 would solve that issue, by providing a machine that takes much of the same software as the PET while using the same disk drives, cassette decks, joysticks and printers as the VIC-20.

So, what machines does VICE emulate?

The vice package in the repository contains the emulator, a disk image utility, and a SID file player. In chronological order of Commodore releases, vice emulates:

The original PET series of machines
The VIC-20 home computer
The CBM2 sequel to the PET series
The ever popular Commodore 64
C-Plus 4 line of home computers
The Commodore 128

The C-Plus 4 line of machines had limited functionality. Think of it as a cross between a Commodore 64 and a VIC-20 with the system software being Commodore BASIC, the operating system, a word processor, a spreadsheet and a database all residing in the system ROM chips.

Of these machines, the Commodore 128 provides the most functionality in the vice package as the Commodore 128 itself was really three machines in one, namely the Commodore 128 itself, a Commodore 64, and a typical CP/M machine that also happens to read CP/M disks from Osborne and Kaypro machines of the day (when used with the 1571 floppy drive).

Installing the vice package from Synaptic places entries for each of the Commodore machines being emulated. On a real Commodore 128, typing "go 64" on the command line literally transforms the Commodore 128 into a Commodore 64, i.e. the features that are exclusive to the Commodore 128 would not be accessible when running the Commodore 128 as a Commodore 64.

It really makes no sense to use "go 64" when running VICE as a Commodore 128, when we can run VICE as a Commodore 64.

A real Commodore 128 is capable of booting CP/M from a floppy as the 1571 drive has the capability to autoboot from diskette, not unlike the floppies used on Apple II series, the Atari 8-bit and ST series, the Commodore Amiga series, the Macintosh and the x86 machines of that day. (The same could be said for the Commodore 64 as well, but on a real Commodore 64, you would need to plug in a cartridge containing a Z80 microprocessor, whereas a real Commodore 128 has a Z80 processor built in to the motherboard coexisting with a variant of the 65C02.)

Information and CP/M disk images for use with vice are available at https://www.cpm8680.com/cpmc64/.

Vintage Computing is more than just games

Much of the content on YouTube covering vintage computers emphasizes primarily on the games available for the machines. Most of you have used these machines to play a game or two at one time or another.

As for me, my primary interest for vintage computing is not so much for the games, but for the programming languages available for software development.

(After all, the games would not have come into existence if it were not for programming languages.)

If you had a computer in your home in the late 1970s through the 1980s, chances are there was a BASIC interpreter embedded in the system ROM that launched on system startup if there was no game (or application) cartridge plugged in or a disk in the (optional at the time) disk drive(s).

BASIC interpreters that came with home computers in the day were licensed by Microsoft. Incidentally, this is one of the very few products that Microsoft got right from the start.

Most home computers of that day licensed the BASIC interpreter from Microsoft. One notable exceptions was Apple's Integer BASIC which was developed entirely by Steve Wozniak. Applesoft BASIC was a dialect of Microsoft BASIC was developed specifically for the Apple II series (including the Apple II compatible machines manufactured by Franklin). A Z80 version of Applesoft BASIC was ported to the Coleco Adam. While this version was indeed Applesoft BASIC, there were a few differences.

Applesoft BASIC programs written for the Apple II series would run on the Coleco Adam if and only if no CALL, PEEK or POKE statements were used, i.e. no assembly language code had to be implemented as the Coleco Adam sported the Z80 processor instead of a 6502.

When it comes to licensing of Microsoft BASIC, Jack Tramiel purchased a BASIC license once, then used that license for all machines approach to Commodore BASIC. Here is a case of two titans butting heads with each other, in this case Jack Tramiel vs Bill Gates. You could imagine what happened there.

(The Commodore machines were an exception here. The PET and CBM2 series always started with the BASIC interpreter launched from ROM. The VIC-20, C64, C-Plus 16, and C128 launched BASIC from ROM if there was no application or game cartridge plugged into the machine. Additionally for the Commodore 128, if a disk was inserted into a 1571 floppy drive at the time the Commodore 128 was powered on, the disk will automatically load whatever software was on that disk, which is usually the first program found on the disk. This allowed CP/M to boot from the disk on the Commodore 128.)

BASIC was also an integral part of MS-DOS and PC-DOS through until version 5.0. This was known as GW-BASIC.

Today, we have Bywater BASIC available in the repository.

The BBC Micro series from Acorn Computers came with BBC Basic, which is what launches when you first launch beebem after installing from Synaptic. You can get BBC Basic as a standalone compiler. The page dedicated to this dialect of BASIC can be found at:

http://www.bbcbasic.co.uk/bbcbasic.html

There is a 64-bit Linux version of the language, and I have yet to test this product to see if it will work with PCLinuxOS. (This version uses the SDL2 library.)

However, you can install the Windows version on wine, run the DOS version in DOSBOX or a FreeDOS machine installed on VirtualBox.

FreeDOS comes with Bywater BASIC and FreeBASIC on their installation media. In addition, the operating system also comes with FreePascal, FASM, NASM, and the DJGPP development system, so this is well worth installing inside VirtualBox.

In terms of time under development, FreeDOS has been under development since 1994, or 26 years and it is still under development! Contrast that to MS-DOS, which really dates back to 1977 with the purchase of Seattle Computer System's QDOS for the Gazelle, and it has been under development until the release of Windows ME (the year 2000), or 23 years! PC-DOS existed from 1981 to 2003 when the last patches of PC-DOS 7.1 (aka PC-DOS 2000) were released. This was 22 years of which the past 8 of those years of PC-DOS were developed by IBM itself. The same could be said for OS/2, which support ended by IBM in 2005.

(Fortunately for the latter, Arca Noae brought OS/2 back in 2016 in the form of ArcaOS 5.x. It still runs DOS and Windows 3.x applications the way they always did on OS/2.)

This means that DOS has been an open source product longer than it has been a commercial product. The bottom line: If you are going to run DOS inside PCLinuxOS, the best way to do it is to use FreeDOS on VirtualBox.

(The second best way is to install FreeDOS inside DOSBOX. But that is a topic for another issue.)

What is wrong with BASIC?

Before one could purchase off the shelf applications such as Lotus 1-2-3 and WordPerfect from retail stores, computer manufacturers made the assumption that people would write their own programs.

The BASIC interpreter was a perfect product for home computers (at that time) as it provided an easy way for people to get their machines to do what they want. Computer manuals, even for the Commodore 64, included a tutorial on the BASIC language.

Contrast that with the manuals you get on today's laptop and desktop machines.

From a personal perspective, I am used to having software development tools installed on my laptops and desktops over the years. This is one reason why I like working with Linux, and PCLinuxOS in particular.

With the emulators available in the repository, I get to see what it was like to program for machines such as Atari ST series, Amstrad CPC 464, or even a Timex Sinclair 1000 (none of which I ever had access to back in the day).

For instance, on my hatari installation, I have Turbo C, HiSoft PASCAL, LISP and Pure PASCAL for programming languages.

If BASIC was a perfect product for home computers, what was wrong with BASIC?

The answer lies in how BASIC programs were written.

First, BASIC stands for Beginners All purpose Symbolic Instruction Code.

BASIC was developed in 1964 at Dartmouth College by John G Kemeny and Thomas E Kurtz (both now retired) with the initial goal of making computers accessible to all students, not just students of mathematics and various sciences.

Let us take the classic hello world example. 10 REM HELLO WORLD
20 PRINT "HELLO WORLD!"
30 END

This example when executed will always display:

HELLO WORLD

regardless of what computer it was running on back in the day, as long as it has a BASIC interpreter.

In the days when the first versions of BASIC were being developed, memory was a precious resource and conserving memory was the main concern for programmers in those days.

To contrast today's computers with those of that day, my laptop has 1,048,576 times the memory of the average mainframe built in the late 1960s and the early 1970s.

As a result, each keyword in BASIC is assigned a single byte code, and that byte is what gets stored in memory, and eventually stored to tapes (both paper and magnetic, including audio cassettes) and disks (from those large noisy platters housed in cabinets the size of a refrigerator to floppy disks which were available in 5.25 inch and 8 inch.

How many of you remember the eight inch floppy? The last time I saw a floppy drive that took an eight inch disk was on a Tandy/Radio Shack TRS-80 Model II.

These were magnetic disks housed in eight inch (square) plastic sleeves, and were commonly used on minicomputers such as the Altair 8080, the early Digital PDP series, and the IBM DisplayWriter (a dedicated word processing machine that was actually a computer that ran CP/M and the UCSD PASCAL P-Code system).

The BASIC interpreter had its own program editor, namely the command line itself. To keep track of where the program starts and where it ends, as well as to simply keep track of the logic behind BASIC programs, line numbers were required.

With today's BASIC interpreters and compilers such as FreeBASIC and GAMBAS, line numbers are optional but can be included to maintain backwards compatibility with coding styles of programmers as well as BASIC programs themselves.

I like this feature as this forces BASIC programs to be structured rather than loosely coded to ensure quality control of the programs.

Let us look at the example again:

10 REM HELLO WORLD
20 PRINT "HELLO WORLD!"
30 END

If we were to insert a line of code inside the program, we would have to use a line number that has not already been used in the program. As BASIC was developed before the existence of full screen editors such as vi and emacs (the very first version of BASIC was developed in 1964, or four years before the first UNIX operating system was developed!), the BASIC interpreter relied on line numbers to determine where to place the BASIC line in the program.

Contrast that with today's BASIC compilers, which do not require line numbers as they compile BASIC code to native code for whatever processor we are developing the BASIC application for (in the case of PCLinuxOS, that would be 64-bit x86 machine code when using Gambas).

The real problem with BASIC is what happens when we design large projects, such as a word processor (I have done this on an Apple IIe in Applesoft BASIC), or a computer game.

The idea behind structured programming (I have discussed this in my Ruby Programming Language series) is to ensure that algorithms are properly designed, that is, each algorithm (be it a function or procedure) contains one entry point and one exit point for program flow, and that all parameters passed to and returned from the algorithm are accounted for.

The Pascal language was developed primarily for the teaching of good programming practices. Variables used in Pascal programs can be global, i.e. accessible to all procedures and functions within the entire program, or local, i.e. variables that are local to a single function or procedure.

In BASIC, all variables are global, and the data types are either numeric, or are character strings, the latter being suffixed with a "$" at the end of the variable. Unless you carefully document these variables, this can cause numerous problems when diagnosing problems with the BASIC program, such as what happens when you reuse the name of a variable.

Some dialects of BASIC restrict the number of characters a variable name can have, making programming more likely to be error prone.

The other problem with BASIC is also memory related. If you attempt to create a structured program in a BASIC on a machine with low available memory (such as a Commodore VIC-20, which has only 3583 bytes of available memory), you will find that you have to take very risky shortcuts in programming code in order to get the program to work on such machines.

As a result, programs must use the CHAIN or similar command to load parts of the program when needed, and reload the main program when that part of the program is finished, or (worse) use the infamous GOTO statement, which has been known to create a type of code called spaghetti code.

When you eat spaghetti for dinner, notice how the pasta is typically laid out. All strung out requiring the spinning of a fork to get the spaghetti into a form you can cleanly consume. Spaghetti code is what you get when you trace the flow of a program that contains numerous GOTO statements, resulting in a hard to debug program when errors creep up in the program's execution.

As a result, you end up spending more time diagnosing and debugging a program laden with GOTO statements. This is not very productive, and is usually a result of a poorly designed program.

Thankfully, BASIC has been deprecated in the late 1980s by the popularity of the C language.

IMO, the only acceptable use for the GOTO statement is in assembly language, where structured programming techniques are really not possible (or even appropriate) when working directly with a microprocessor.

BBC Basic takes programming one step further by embedding assembly language into sections of BASIC code. This only applies to the BBC Micro series of machines, and is not part of the stand alone compilers available for Linux, Windows and Mac OS-X (because there is no need to embed assembly code for modern computers).

Other Languages for Vintage Computing

Besides assembly language and BASIC, typical languages available for machines of that day are FORTRAN, Pascal, LISP and FORTH, the last one still in use for embedded systems programming (and is what the bootloader in FreeBSD was written in).

Other languages such as ALGOL, PL/I, JCL, JOSS and APL were specific to minicomputers and mainframes of that day.

Of interest is PL/I, which is slowly regaining popularity as a programming language for Internet applications because of its strong variable typing and the need for security in such applications.

There is a PL/I extension for the GNU Compiler Collection in the works, but its status is unknown at this time.

Why Vintage Computing on PCLinuxOS?

So, why emulate these machines on PCLinuxOS?

The answer lies in the following factors:

Availability of vintage machines
Availability of peripherals
Availability of cabling
Overall cost of operation of vintage equipment

In short, collecting and restoring vintage computers is for you only if you have the time, patience and enough money to acquire the necessary hardware and accessories to get these machines working...and that is if you can find the necessary hardware and accessories in the first place.

Even if it were possible, there would have to be a way to connect these machines to either the Internet, or your local PCLinuxOS machine.

In the case of the Atari ST series, simply connect an external floppy drive to your PCLinuxOS machine and copy disk images to a 720KB floppy as the Atari ST series will read and write to 720KB FAT diskettes. The same could be said for vintage x86 machines equipped with floppy drives.

The availability of emulators in the PCLinuxOS repository should be sufficient to allow us to see what it was like to program for and use vintage computers, or better yet, relive the memories of having used those vintage computers.

I have looked at prices of vintage computers on e-Bay. When you add up the cost of what is available to get these machines working, it is cheaper in the long run to install the equivalent emulators from Synaptic, and you will get the experience of using these vintage computers (as well as programming for these machines as well).

Vintage Printers for your PCLinuxOS machine

The experience of owning a vintage computer is one thing. Owning a vintage printer, however, is another.

Remember the days when you heard the noise of the dot-matrix printer, printing your text line by line. There is a reason why older printers do not appear for sale very often online. With vintage printers, while they are universally supported in one way or another by PCLinuxOS, what makes vintage printers a deal maker or a deal breaker is the availability of supplies for that printer.

For example, when was the last time you saw fanfold printer paper for sale? Today's printers print by the page rather than by the line, hence the need for fanfold paper is very much nonexistent, unless you can find a reliable source online.

Epson's ActionPrinter series were dot-matrix printers that happen to be page oriented as they were designed to be low cost alternatives to laser printers.

For many vintage printers, connecting these to your PCLinuxOS machine will involve the use of a USB to Parallel Port adapter, or a USB to Serial adapter depending on which ports the printer has, unless your machine has a parallel and/or serial port, either on the machine itself, or on a docking station.

In the case of my laptop, there is a docking station available that happens to have parallel and serial ports in addition to two USB 2.0 ports.

Alternatively, if that vintage printer connects to a network, it is possible to connect the printer to PCLinuxOS through a network connection at Port 9100 (the port used by HP's JetDirect print server).

Even if you do get that vintage printer connected and working, the next thing you need to worry about is getting a source for ribbon, ink or toner. It makes no sense to purchase a vintage printer if you cannot purchase supplies for that printer.

Then there is the issue of paper. Daisy wheel printers (remember those) were designed to take either fanfold paper or sheet paper. The issue here is that not all programs printing to these printers do not necessarily know whether you are using fanfold paper or sheet fed paper.

Even if you configure one of these printers under CUPS, fanfold paper is generally assumed to be loaded into such printers. Also, the USB to Parallel and USB to Serial adapters do not inform CUPS that the printer is out of paper, because vintage printers in general do not have the capability to inform the host machine of that status.

With many of today's low cost printers being able to work under PCLinuxOS, is there really any reason to use a vintage printer with PCLinuxOS?

Nostalgia, perhaps? But only if the cost is worth it!

Previous Page Top Next Page