Paolo Amoroso's Journal

Astronomy & space, Google, Python, retrocomputing, coding

I couldn't resist. I ordered an assembled V20-MBC 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... | Reply by email...

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 this video, which shows the output as well as the menus:

Here the Z80-MBC2 runs in a Minicom terminal emulator session under Crostini Linux on my Chromebox.

#z80mbc2 #retrocomputing #sbc

Discuss... | Reply by email...

I don’t like algorithms deciding what ends up in my reading feed. For my content consumption I want platforms that don't filter but deliver all the content from all the sources I want, and only those sources.

This is why my information hub is an RSS feed reader, Feedly. In addition, since running my own email newsletter for some time, I have been subscribing to a growing number of newsletters on a variety of topics. From technology and software development, to content creation and publishing.

Here are the newsletters I subscribe to. I prefer niche, obscure, or unique sources, so I hope this list will help you discover valuable content that’s not mainstream.

I'll keep the list up to date.


Discuss... | Reply by email...

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 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:


Again, 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... | Reply by email...

If you lived through the personal computer revolution of the 1980s, you may have read some books that got you hooked with programming. These works led the reader through the intellectual adventure of using computing to explore interesting problem domains.

Two recent Python books bring back this fascination and excitement with programming, Impractical Python Projects: Playful Programming Activities to Make You Smarter and the sequel Real-World Python: A Hacker's Guide to Solving Problems with Code, both by Lee Vaughan and published by No Starch Press.

They are not Python tutorials or guides. Instead, they present stimulating coding projects for non-programmers who want to use Python for doing experiments, test theories, or simulate natural phenomena. This includes professionals who are not software developers but use programming to solve problems in science and engineering. And, of course, hobbyists.

Exploring and understanding the problem domain is an integral part of the books' projects along with coding. This is unlike typical programming books where the examples are often trivial, have little or no domain depth, and are stripped of everything but the essentials.

The science and engineering Vaughan's books cover include some great projects that match my interest in astronomy and space. For example, Impractical Python Projects has chapters on estimating alien civilizations, simulating a volcano on Jupiter’s moon Io, simulating orbital maneuvers, and stacking planetary images. Real-World Python discusses re-discovering Pluto, plotting the Apollo 8 lunar trajectory, selecting martian landing sites, and detecting exoplanets.

The sample code is straightforward, clear, and hints at how much can be done with little code. Since the books are not language tutorials, they focus on prototyping and exploration rather than building large and maintainable systems.

#Python #books

Discuss... | Reply by email...

Over the three years I ran my discontinued Blogger blog I published 146 posts. In just seven months I published 151 posts on this new blog hosted at, which drives home the superiority of as a frictionless blogging platform.


Discuss... | Reply by email...

I ported to Intel 8080 Assembly the Z80-MBC2 Z80 code of the led blink demo, assembled it with the Suite8080 assembler, and uploaded the HEX binary to the Z80-MBC2. Instead of printing a message to the console and blinking the User led, the program made the led turn on and the board reset, booting up the default operating system.

I have no tools to debug software that runs on the bare metal. So the next step is to investigate these clues, starting from a comparison of the Z80 and 8080 sources.

#Assembly #z80mbc2 #Suite8080

Discuss... | Reply by email...

The conventional blogging wisdom is to address the readers as you and avoid writing in first person. This is supposedly friendlier and makes the readers feel at the center of attention.

I use you sparingly. For example, when I write how-to or instructional material, ask something, or try to persuade. Most of the times I write in first person. It's a natural way of sharing with fellow tech enthusiasts my direct experience and projects, the steps I take, the thought processes I go through, the setbacks.

There's another reason I rarely address readers as you.

You may come across as a marketing or SEO tool. The insincere intention of pleasing and luring readers to sell something — products, ads, attention — and monetize blogs.

My readers can cut through the BS and know when I feels right.


Discuss... | Reply by email...

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.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... | Reply by email...

My post on why I use a Chromebox was shared on Hacker News and got enough upvotes to receive more than 4,000 views over a day. The feedback in the comments made me realize I didn't explain why I use chromeOS instead of Linux, so here goes.

I did use various Linux distros from the mid 1990s until switching to chromeOS, but I got exasperated with maintenance.

Device driver support was suboptimal. System updates would often break something and throw me to the console, forcing to waste days to troubleshoot and fix whatever broke and restore X. These issues were so frequent I ended up deferring to apply system updates, trading features and fixes for stability.

I had enough with Linux maintenance, realized I was living in Chrome anyway, didn't mind Google, and gave chromeOS a try. Seven years and four chromeOS devices later, I never had a single system update issue. And maintenance simply disappeared.

For years I used also Windows and Mac OS X but I liked Linux — and later chromeOS — much more.

#chromeOS #Linux

Discuss... | Reply by email...

Enter your email to subscribe to updates.