Paolo Amoroso's Journal

retrocomputing

I'm collecting and reading more Pascal programming books than I ever did.

My Z80-MBC2 and V20-MBC come with Turbo Pascal for CP/M preinstalled. Using the environment is making me rediscover Turbo Pascal and realize it's great for creating small CP/M tools and programs.

To take advantage of Turbo Pascal I have been gathering old books and other Pascal learning resources that cover the CP/M version I use, selecting only the best and most interesting.

All of them are available online, for example at the Open Library or Bitsavers.org. But these works are too precious and may disappear, not to mention the high prices of rare retrocomputing books. I want backups, so I bought used copies of some of these. Here's what my Pascal programming retro bookshelf looks like:

Pascal programming books.

These are the Pascal books and resources I reference most often, along with notes on what they cover or why I like them:

#pascal #retrocomputing #books

Discuss... Email | Reply @amoroso@fosstodon.org

I assumed in Turbo Pascal for CP/M, when printing to a terminal, writeln wraps lines longer than the screen width. A quick test under CP/M-86 on the V20-MBC proved such lines are truncated instead. In hindsight it makes sense, as there's limited output state on a terminal system with no frame buffer.

#v20mbc #retrocomputing #development

Discuss... Email | Reply @amoroso@fosstodon.org

To code on the Z80-MBC2 and V20-MBC homebrew computers I often transfer text files to and from their CP/M environments.

In one direction I send files from Crostini Linux by dumping them to CP/M, where PIP saves the text to CP/M files. In the opposite direction I run PIP on CP/M to print the files to the screen, where Minicom captures the text and saves it to files on Crostini.

CP/M and Unix have different line break and end of file encodings. In addition, the transfer process may introduce unwanted text. That's why the text files exchanged between the systems need some conversion, to automate which I wrote two short Bash scripts.

The first script, unix2cpm, converts line breaks and the end of file marker in the input to the CP/M encoding and prints the result to stdout. If the optional file name argument isn't supplied the script reads from stdin with a technique I researched. This is the script:

#!/usr/bin/env bash

# Convert line breaks and end of file from Unix to CP/M.
#
# Usage:
#
#   unix2cpm [filename]
#
# Reads from stdin if the optional argument is missing.

input_file="${1:-/dev/stdin}"

cat "$input_file" | unix2dos
echo -e -n '\x1a'

The script calls unix2dos distributed with the dos2unix / unix2dos tools. unix2dos converts line breaks from Unix to MS-DOS, which borrows the encoding from CP/M. unix2cpm needs only to append with echo the ^Z end of file control character.

Once converted, the file is ready to be dumped from Linux to CP/M.

I initiate file transfers in the oppostite direction by executing the Minicom command to capture the terminal output to a file, Ctrl-A L (Capture on/off). Then, at the CP/M prompt, I execute a command like this to print a file to the console:

A>a:pip con:=filename.txt

When printing ends and the A> prompt reappears, I turn off output capture in Minicom to close the capture file. The captured output contains the PIP command in the first line, then the text of the file, and finally the A> prompt in the last line.

To remove the unwanted first and last line I wrote the second script, skipfl (skip first and last). Again, the script reads from stdin if the optional file name isn't supplied and writes to stdout. The code is:

#!/usr/bin/env bash

# Skip the first and last file of the argument file
#
# Usage:
#
#   skipfl [filename]
#
# Reads from stdin if the optional argument is missing.

input_file="${1:-/dev/stdin}"

cat "$input_file" | sed '1d' | sed '$d'

The script calls sed to delete the first and last line with the d command.

No further processing of the captured CP/M output file is necessary as Minicom takes care of inserting the proper line break and end of file encodings.

#z80mbc2 #v20mbc #linux #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org

Turbo Pascal 3.0 for CP/M has a display issue I noticed on the Z80-MBC2 and V20-MBC homebrew computers. When using the development environment, text in the terminal remained stuck with boldface turned on.

It was enough to launch Turbo Pascal and execute any command (e.g. compiler Options), or exit Turbo Pascal, to turn on boldface and leave it stuck in the IDE, in CCP, and when running other programs. Everything went bold such as code in source files edited in Turbo Pascal, CCP command lines, and the output of transient programs.

The issue occurred under CP/M 3.0 on the Z80-MBC2 and CP/M-86 1.1 on the V20-MBC, both accessed from the Minicom terminal emulator under Crostini Linux on my Chromebox.

I tried ANSI and VT102 emulation in Minicom and run the Turbo Pascal configuration utility TINST to set the terminal to ANSI, but the issue persisted. The only workaround was to resize the terminal window, which reinitializes the display.

I posted to comp.os.cpm for help and learnt Borland left the terminal reset string blank in the ANSI entry, which thus doesn't reset text attributes.

The fix was simple. I run TINST, selected the ANSI terminal, and edited the definition to insert the following reset string via the option Send a reset string to the terminal (the corresponding escape code strings and descriptions are below the hex values):

$1b $63    $1b  $5b $32 $4a

ESC c      ESC  [   2   J
Reset      Clear screen

ESC c is not enough as it only resets the terminal but doesn't clear the screen. With the new string the text attributes are now properly handled and the terminal is no longer stuck in boldface after using Turbo Pascal.

#z80mbc2 #v20mbc #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org

The option 4: Autoboot-80 of the V20-MBC boot menu switches the Nec V20 to Intel 8080 mode and loads version 1.4 of the IMSAI 8K BASIC interpreter. In this session I typed in and run a short BASIC program to print the ASCII character set:

IMSAI BASIC on the V20-MBC homebrew computer.

The code is:

10 FOR I=32 TO 127
20 PRINT CHR$(I);
30 NEXT I

Despite the brevity, entering the code I bumped into some unexpected errors and behavior. It's been almost four decades since I used a resident BASIC on a microcomputer, and never with a terminal. No wonder interacting with IMSAI BASIC felt weird.

Reading the IMSAI BASIC manual and experimenting with the interpreter cleared the hurdles and let me make progress, though I'm not sure whether the issues may be related to the terminal settings. By the way, the commented Assembly source of the interpreter in the manual is an interesting reading.

Here are some notes on what I learned.

BASIC keywords, commands, and identifiers must be in all uppercase. Lowercase is supported only in strings assigned to variables, but printing string literals yelds uppercase text.

Pressing Backspace or Ctrl-H moves the cursor one character to the left and Del does nothing. The only ways of fixing typos or errors are deleting the whole line with Ctrl-U or entering it again.

When the environment gets messed up I execute the NEW command that clears the program and data, thus letting me start from scratch.

#v20mbc #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org

Turbo Pascal 3 for CP/M comes preinstalled with the Z80-MBC2 and V20-MBC homebrew computers. Checking out the development environment made me rediscover Turbo Pascal and realize its potential for programming these computers.

Although I owned Turbo Pascal for MS-DOS in the early 1990s, I didn't use it much. Between other languages later getting my attention and Borland losing its market leadership, I eventually forgot about Turbo Pascal. Now, with the development environment handy on the Z80-MBC2 and V20-MBC, I began checking out the Turbo Pascal CP/M version I had never played with.

Being familiar with the Turbo Pascal MS-DOS IDE, which features a nice text user interface with pull-down menus and dialogs, the CP/M version seemed spartan and primitive.

But I pressed ahead, tried the various commands, edited and compiled some code, and got familiar with the keystrokes and workflow. I soon felt at ease with Turbo Pascal for CP/M. The environment is still suprisingly usable and productive, allowing fast edit-compile-run cycles with short compilation times even on the 8-bit Z80-MBC2.

I now understand why Turbo Pascal made such a sensation at the time and revolutionized development tools.

To learn the Turbo Pascal environment and language I began reading the manual, as well as books about Turbo Pascal and Pascal. The more I used Turbo Pascal and read about it, the more I enjoyed it and wanted to learn and explore.

Next thing I knew, I was down a rabbit hole.

This experimentation and reading made me realize the potential of Turbo Pascal as an ideal tool for hobby projects with these homebrew computers.

Pascal is an easy to understand, readbale, and expressive language. Despite the age and design flaws, it allows to write fairly advanced code. Pascal makes practicality win over language purity.

Sitting at a sweet spot between ease of use, features, and power, Turbo Pascal is a perfect fit for CP/M as it consumes limited resources, generates moderatly small and fast executables, and can access all the features of the system. That's why it's a good environment for quickly developing small tools or programs for the Z80-MBC2 and V20-MBC.

#pascal #retrocomputing #z80mbc2 #v20mbc

Discuss... Email | Reply @amoroso@fosstodon.org

I was a heavy user of shareware software but my experience was like a story with missing clues and no ending. Reading Shareware Heroes: The renegades who redefined gaming at the dawn of the internet by Richard Moss filled the gaps, completed the story, and gave a sense of resolution.

Android tablet with the cover of the of the Shareware Heroes ebook open in a reading app.

I encountered shareware via the Amiga Fish disk collection, and later MS-DOS productivity software and utilities such as the PC-Write word processor and the CompuShow image viewer.

As an Italian student I loved the affordable programs and the wide selection of shareware, much wider than the fewer and expensive packages by traditional American software houses local retailers carried. I assumed everyone else loved shareware, so I always found puzzling this distribution model was little known even among computer geeks. Equally puzzling was why shareware seemed to have faded since the late 1990s.

Later I realized my narrow focus on productivity software and programming tools made me miss major events, hits, and market players of gaming shareware, which I never was into.

There were other things I didn't know or understand at the time, such as why some shareware never made it to Europe. And, not having owned a Mac until well into the Internet era, I wasn't aware of the role of Mac shareware. Finally, I always wondered about the business side of shareware.

Thanks to accurate and extensive research based on original sources and interviews, Shareware Heroes puts the pieces together and presents a complete, coherent history of shareware from the early days to the Internet era. It paints the big picture, discusses shareware in the context of the computer industry, traces the evolution of shareware business models, and ties the past with the present from early shareware titles to the contemporary indie scene.

Although I'm less focused on gaming, the book has a lot of material also on the application software and utilities at the roots of shareware. But I found the coverage of gaming equally interesting even if I'm a non gamer. For example, I realized the key role of Apogee and id in both the evolution of gaming and software business models.

Interestingly, Shareware Heroes indirectly provides some historical context on the dispute between Epic Games, Apple, and Google over app store fees. Founder Tim Sweeney has always been highly competitive since the early days of Epic Games, for example in his rivarly with Apogee and id.

Sweeney is a tough leader, Apple and Google should have seen it coming. Their executives may want to read Shareware Heroes.

#retrocomputing #books

Discuss... Email | Reply @amoroso@fosstodon.org

CP/M-86 is a footnote to the history of the personal computer, which is part of why it's interesting.

The downside is the limited popularity the operating system enjoyed makes it difficult to discover online resources, particularly software. I face this issue when looking for software and tools for my V20-MBC homebrew computer, which can run CP/M-86 with the Intel 8088 of its Nec V20.

Therefore, I'm keeping track of the programs and software collections I run across online.

I include a list here, which I'll revise and expand with more entries. On the V20-MBC I tested only a small fraction of this software, so some programs designed for vendor-specific CP/M-86 versions or machines may not run on the device.

Repositories and collections

Old BBS archives, repositories, personal websites, and CD-ROM collections are good starting points. CP/M-86 software in executable form is usually in a section under general CP/M resources.

I found these repositories and websites:

Programs and utilities

Some applications are provided for download from their own websites or distribution archives:

Source code

Some software that works on CP/M-86 is distributed in source form with no prepackaged binaries. It's usually available at general CP/M repositories, in sections specific to the programming language or environment it was developed with such as Turbo Pascal or BASIC. This code may need some tweaks to run on CP/M-86.

For example, the Walnut Creek CP/M CD-ROM has a Turbo Pascal section.

CP/M-86 Miscellaneous Ports is a collection of C and Unix tools ported to CP/M-86, such as yacc.

#v20mbc #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org

Delivering files to the Z80-MBC2 and V20-MBC homebrew computers is an essential capability for bringing new software and data to these CP/M devices.

In particular I need a file upload capability, a way of transferring text files from the host system to the remote CP/M devices. Why just text? Because a text stream is the lowest common denominator. The simplest, most ubiquitous, and versatile communication channel.

Encoding binary files as text, such as the Intel HEX format for executables or uuencoding, enables moving arbitrary files over text streams.

The problem

I want to transfer files in the most practical way, i.e. via the serial USB connection from the host system, my Chromebox (where the terminal emulator for controlling the devices runs under Crostini Linux), to the remote devices. I could copy the files to the microSD cards the homebrew computers use to simulate storage devices like hard disks, but this would require additional steps.

An obvious solution would be a file transfer protocol like the XMODEM utility that comes with the Z80-MBC2. But XMODEM file upload to the Z80-MBC2 has issues and the V20-MBC doesn't have XMODEM or other file transfer software preinstalled.

My initial workaround, dumping a text file from the terminal into a CP/M text editor, does the job but creates friction. I wanted a minimal upload channel with less friction, that relies only on native CP/M features, and can work also on the V20-MBC.

The solution: a minimal file transfer channel

I came up with a similar but more streamlined solution.

Like in the workaround, on Linux the process consists in dumping a text file from the terminal emulator.

But on CP/M, instead of running the ed editor to collect the file and manually save it, PIP automatically receives and saves the file. An additional advantage is PIP can handle arbitrarily long files whereas ed is limited to available memory.

There's a reason the CP/M system utility PIP is called Peripheral Interchange Program — emphasis mine. In addition to copying, renaming, and combining files, PIP can transfer data to and from the console and other peripherals. The new transfer channel relies on this feature by receiving the text coming from the console associated with the terminal emulator, and saving it to a file.

The process

How does transfers over this channel work? I initiate file uploads on Linux from the Minicom terminal emulator.

First, to introduce a character trasmission delay I change Minicom's settings with the Ctrl-A T F command, Terminal settings > Character tx delay (ms). A value of 1 ms works well on both the Z80-MBC2 and the V20-MBC.

Why a delay? Although the homebrew computers are connected via a 115200 bps serial link, these 8-bit and 16-bit systems can't keep up with the full speed with which the 64-bit Intel i7 Chrombox can pump data. Hence the need for a transmission delay.

Next, at the CP/M prompt I launch PIP:

G>pip filename.txt=con:

Since the destination of the data before the = symbol preceeds the source, the command instructs PIP save to FILENAME.TXT the data coming from the logical device con:, the source. By default CON: is associated with the console, i.e. Minicom on Linux.

The above command makes PIP receive the text stream Minicom sends over the serial line as if typed by the user at the keyboard. How can Minicom type text virtually? The program's Ctrl-A Y Paste file command allows to select and dump a Linux file, which is the last step of the transfer.

Then, on CP/M, the incoming text is saved to a file and rapidly printed on the screen line by line. The transfer may take up to a few minutes depending on the file size.

When PIP terminates, the new file is ready. A caveat is CP/M expects text files to be encoded with specific line break and end of file control characters, i.e. ^M^J and ^Z, not ^J and ^D like on Linux. If the end of file is missing, PIP pauses until the ^Z keystroke is entered manually.

The procedure works well on both the Z80-MBC2 and the V20-MBC.

Next steps

Dumping text files over a serial line is slow and more involved than dedicated file transfer protocols such as XMODEM, and works only one file at a time.

But text streams are universal, easy to use, and reliable. More importantly, these streams are the only way of uploading binary files encoded as text, such as executable programs not already stored on the remote device. For example, neither XMODEM nor other file transfer utilities are preinstalled under CP/M-86 on the V20-MBC.

I'll leverage this text channel to upload to the V20-MBC the Kermit communication program, which implements the transfer protocol by the same name. I'll see if Kermit can upload from Linux to the V20-MBC, and then the Z80-MBC2.

#z80mbc2 #v20mbc #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org

Getting errors for basic disk access functions was a reminder WordStar must be configured for the CP/M system it runs on. The garbled text WordStar 3.30 rendered on the terminal under CP/M-86 on the V20-MBC drove the point home. Setting the terminal type to ANSI with the configuration utility WINSTALL.CMD fixed the issue.

#v20mbc #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org