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.

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:

• CP/M-86 Software Repository: utilities, editors, games, programming languages and tools, and more. Some programs run only on the iBM PC or IBM's version of CP/M-86.
• Walnut Creek CP/M CD-ROM: the collection has a CP/M-86 section featuring mostly tools and communication programs.
• Digital Research Binary Files: programming languages, development tools, and various versions of CP/M-86.
• oldcomputers-ddns.org: development tools, utilities, application programs.
• Gaby's Homepage for CP/M and Computer History: utilities.
• Commercial CP/M Software: programming languages and tools, application and business software grouped by category. The packages that run on CP/M-86 are noted in the descriptions and are available under several categories.

Programs and utilities

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

• Pirx Commander: a two pane file browser similar to Norton Commander. The official annoucement provides some more details.
• CP/M Kermit: CP/M-86 port of the Kermit communication program.
• CP/M-86 Hacking: tools and utilities, most of which run on the V20-MBC. Sources and binaries are available.

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

My memories of WordStar are fuzzy as I haven't been using it since the late 1980s and, even then, only on MS-DOS and not set up by me. So the errors for basic disk drive access functions I got from WordStar on CP/M surprised me.

My Z80-MBC2 and V20-MBC computers come with the word processor preinstalled, which runs under CP/M-80 on the former and CP/M-86 on the latter.

The e: drive holds the WordStar Release 4 files on the Z80-MBC2 with CP/M 3.0. I got an error about the program not finding its overlay files when starting it from a different drive, e.g. executing e:ws from F:. And the program's L command to change the logged drive to one other than A: or B: issued a file not found error.

Reading the manual clarified that, on CP/M-80, WordStar recognizes only A: and B: by default, but other drives can be accessed by installing the program with the INSTALL.COM utility or configuring it with WSCHANGE.COM.

The INSTALL.COM executable that ships with the Z80-MBC2 is designed for a version of WordStar different from the release 4 actually on the microcomputer. Therefore, I had to run WSCHANGE to change the settings with the option C (Computer: Disk Drives, WordStar Files > A (Disk Drives, Valid disk drives) > A (Valid disk drives).

The resulting configuration screen listed the valid disk drives, i.e. the floppy drives A: and B:, with the default where WordStar looks for the overlay files marked with an asterisk:

The screen also allowed to add the letters of valid drives one by one, with the first set as the default drive. I typed E as that's where WordStar's files are on the Z80-MBC2 under CP/M 3.0. Then I added more drive letters as the mciroSD storage of the device emulates the hard disks from A: to P:. For each drive I answered no to the question on whether it's a floppy:

Finally, the configuration program listed the new valid drives, i.e. A: through P: with E: coming first to indicate the default drive:

On the V20-MBC under CP/M-86, WordStar release 3.30 detects all the drives A: to P: out of the box, but the default drive where the program looks for its files still needed to be configured. No WSCHANGE utility comes with the word processor on my device, so I used the installation program WINSTALL.CMD to set C: as the default. C is where WordStar's files are stored on the V20-MBC.

#z80mbc2 #v20mbc #retrocomputing

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

The V20-MBC homebrew computer I ordered finally arrived and I started checking it out.

The V20-MBC is a single-board computer by the same maker of the Z80-MBC2. Most of the design is common to both. However, unlike the Z80-MBC2, instead of a Z80 the V20-MBC has a Nec V20 chip that implements the instruction sets of the Intel 8080, which runs CP/M-80 2.2 on the V20-MBC, and the Intel 8088 with CP/M-86 1.1.

I got a V20-MBC Black Edition. It's a version of the V20-MBC with higher quality parts and a black PCB that, along with most of the other components also black, makes for a slick look:

I already love the device. These notes are my early impressions, but I'll continue sharing my experience with the V20-MBC.

Hardware

Both homebrew computers have similar size and layout and are accessed the same way, i.e. with a terminal emulator running on a desktop computer, a Chromebox in my case, connected via a USB serial line. Here is the setup, with the Chromebox at the top:

The performance of the 8088 of the Nec V20 under CP/M-86 is noticeably better than the Z80-based Z80-MBC2. I estimate CP/M-86 software on the V20-MBC is 2-3X as fast as CP/M-80 programs on the Z80-MBC2.

Software

The V20-MBC is operated the same way as the Z80-MBC2, except for a couple of differences.

To account for the two CPUs, the boot and configuration menu duplicates the entries that load executable code. This is the menu in a Minicom terminal emulator session under Crostini Linux on the Chromebox:

There are two options for uploading an executable in Intel HEX format to run on the bare hardware with no operating system, iLoad for 8086 code and iLoad-80 for Intel 8080 code. Similarly, Autoboot automatically boots a designated 8086 binary, Autoboot-80 an 8080 one.

Although I never used CP/M-86 before, thanks to my prior experience with CP/M-80 the 16-bit operating system looks familiar and I already feel productive. Aside from the additional transient commands of CP/M-86, the only major difference is executable program files have the .CMD extension instead of .COM as on CP/M-80. This screenshot of the A: drive directory shows the extensions:

Issues

A quick check reveals some CP/M-86 files are missing, such as the TOD.CMD and ASSIGN.CMD transient commands. This is not unexpected as the Z80-MBC2 is also missing some files, e.g. STAT.COM and the Turbo Pascal sample .PAS sources. No big deal, it's easy to find and download suitable replacements.

#v20mbc #sbc #retrocomputing

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

I couldn't resist. I ordered an assembled V20-MBC Black Edition kit with 1 MB RAM, a homebrew computer by the same prolific maker of the Z80-MBC2. The devices share the same design, except instead of a Z80 like the Z80-MBC2 the V20-MBC features a Nec V20 bundling the 8088 and 8080 CPUs.

It's exactly what I needed, the perfect match for running my Assembly code on actual hardware and a complement to the Z80-MBC2.

Suite8080, my suite of Intel 8080 Assembly cross-development tools, includes the assembler I use for my 8080 programs executed on the Z80-MBC2 under CP/M-80, and now also on the V20-MBC as native 8080 code. I also set up an x86 Assembly cross-development environment to create 8086 code that will run on the V20-MBC under CP/M-86. And, of course, the Z80-MBC2 lets me run Z80-specific projects.

The shipping is on its way to me, I'll share my experience with the V20-MBC.

#v20mbc #retrocomputing #sbc #x86

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

The Z80-MBC2 homebrew Z80 computer is a living retrocomputing museum that runs early microcomputer operating systems such as CP/M, QP/M, and UCSD p-System. Since the latter is the one I know least, I explore it with the Z80-MBC2.

On UCSD p-System the user runs programs and manages the system through a series of hierarchical menus, unlike the command interpreters of other operating systems. Navigating the menus down the hierarchy is easy, but sometimes I'm not sure how to get up one level. Pressing the Q key works most of the times, but occasionally nothing happens and I get stuck.

Running UCSD p-System gives a sense of how slow the output is on serial terminals. For example, a demo program to plot an ASCII sine wave takes almost 20 seconds over a 115200 bps serial line to the 8 MHz Z80-MBC2.

It's best demonstrated by a screencast I recorded, which shows the output as well as the menus. In the video the Z80-MBC2 runs in a Minicom terminal emulator session under Crostini Linux on my Chromebox.

#z80mbc2 #retrocomputing #sbc

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

I cross-develop CP/M programs on Linux with the Suite8080 assembler and run them on a number of platforms, from software emulators to the Z80-MBC2 computer. But to test the code I use an emulator for Linux called ANSI CP/M Emulator and disk image tool, or just CPM.

CPM is unique in that it reduces development and testing friction. The emulator can execute CP/M programs stored on the Linux file system by passing CP/M executable files as arguments, such as:

$ cpm cpmprog

where cpm is the emulator and cpmprog.com is a .COM file on Linux. In addition, the current Linux directory appears as the A: drive from CP/M, so any .COM files there on Linux can be executed from CP/M like this:

A>cpmprog

Again, cpmprog.com is a .COM file on Linux.

This feature shortens the development cycle, as the emulator can access program files cross-assembled on the same file system it runs on.

Other emulators require copying files to disk images and mounting the images from the emulated environment. And before they can be run on the Z80-MBC2 or other hardware, CP/M programs need to be transferred via XMODEM or other means.

Once a .COM program is tested and debugged, I run it on richer CP/M environments like the z80pack emulator or the Z80-MBC2.

#retrocomputing #cpm

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

I'm looking for source code of MS-DOS .COM programs in real-mode 8086 Assembly written in NASM syntax.

Why such weird requirements? I'm learning Assembly programming under MS-DOS and MikeOS, and cross-developing on Linux with NASM. To avoid the complexity of x86 segmentation, I prefer to focus on single-segment programs as I plan to write small applications anyway. So I'd like to study examples of how these programs organize and reference data and code.

Despite the long history and influence of MS-DOS, finding .COM code is proving unexpectedly hard.

Googling doesn't turn up much. I solicited recommendations on comp.os.ms.dos.programmer, comp.lang.asm.x86, the NASM forum, and Mastodon but, aside from a lot of engagement and interest (and the occasional suggestion I change my mind and target Windows), I got few resources.

#Assembly #MSDOS #retrocomputing #x86

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