Paolo Amoroso's Journal

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... Email | Reply @amoroso@oldbytes.space

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 Write.as, which drives home the superiority of Write.as as a frictionless blogging platform.

#blogging

Discuss... Email | Reply @amoroso@oldbytes.space

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... Email | Reply @amoroso@oldbytes.space

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.

#blogging

Discuss... Email | Reply @amoroso@oldbytes.space

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@oldbytes.space

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... Email | Reply @amoroso@oldbytes.space

Chromebooks are mainstream but many people don’t grok Chromeboxes.

Some wonder what’s the point of Chromeboxes and what to use them for, especially high-end units. People seem to assume Chromeboxes are good only as kiosks or for who knows what uncommon use-case.

This is the main unit of my ASUS Chromebox 3:

I chose a Chromebox because I nearly never need to move my primary desktop device. And I want the most high-end unit I can get my hands on to do the same stuff cheap Chromebooks can do, but faster.

Let me elaborate.

First off, in 2015 I switched to using exclusively chromeOS on the desktop and ditched traditional desktop operating systems such as Linux or Windows.

Therefore, for me the choice is among the form factors of chromeOS desktop devices: Chromebook (laptop), Chromebox (fixed desktop system), or Chromebase (think iMac for chromeOS).

I went with a Chromebox as my daily driver because I work with it at the same desk 99.999% of the time. Since I nearly never need to move the device, not even to a different room or chair, I want the best experience with a large monitor, a full-size keyboard, a mouse, and wired Ethernet. I could plug these peripherals into a Chromebook but it would introduce friction, take up additional desk space, and cost more.

Here's the workstation of my ASUS Chromebox 3.

I got the most high-end Chromebox available at the time I researched it, i.e. an Intel CORE i7 ASUS Chromebox 3 with 16 GB RAM and 256 GB storage. Why? To run exactly the same software that works on cheap Chromebooks, but with a snappier and more responsive experience. If you're old enough to remember MS-DOS, it’s the same reason people got 80386 PCs when the same software ran just fine on 8088 PCs.

Why not a Chromebase? Because I want to be able to upgrade different parts of the system separately, such as changing only the monitor.

As for software, I use mostly web apps and they work great on chromeOS as this is the use case the platform was designed for. Installing Android apps on the Chromebox fills a few gaps in my needs for which no web alternatives are available. Crostini Linux is invaluable in running specific and niche software.

I happen to have a Chromebook too, a Lenovo Yoga N26. I use it for experimenting with Chrome OS and on the — very rare — occasion I need the mobility of a laptop.

#chromeOS

Discuss... Email | Reply @amoroso@oldbytes.space

I've always worked in astronomy and space outreach and education. But one of my assignments led to an unusual experience in a completely different field, art.

In 2018 I was hired for an art project at Fondazione Prada, precisely because of my astronomy background.

Fondazione Prada (Prada foundation) is a contemporary art museum and cultural institution in Milan, Italy, where I live. It's a unique and intriguing place, especially for someone like me with no art background. What impressed me most were the architecture and the insightful conversations I had with staff members, such as the room guardians who are usually art or design students.

Between August, 11 and October, 22, 2018 Fondazione Prada run a temporary exhibition by Brazillian artist Laura Lima, Slight Agitation 4/4. It featured an impressive series of room-sized installations, including one named The Telescope. It was a giant scaffholding structure with a lecture space and an actual small telescope.

My job was to do daily performances inside the structure, i.e. ordinary astronomy lectures. Laura Lima advised me to focus and geek out on astronomy, not art.

I talked about the Moon, Mars and the planets, comets, space exploration, and more. This is the whiteboard I used, with my doodles after a lecture on comets and meteors.

It was a fun and unique experience the many visitors who attended the lectures seemed to appreciate. I didn't anticipate so much interest and questions in a context where people didn't expect to stumble upon science.

Prada Foundation published a video that shows Slight Agitation 4/4 and the structure where I performed. I'm the guy with sparse hair and glasses handling the telescope at 00:45 and 03:08, and lecturing at the whiteboard at 02:47.

#astronomy

Discuss... Email | Reply @amoroso@oldbytes.space

One of the Z80-MBC2 boot menu options, iLoad, allows uploading an executable program in Intel HEX format. This is cool because it enables running code on the bare metal with no operating system, such as a resident monitor or software that directly accesses the hardware.

To test iLoad I uploaded and run a demo to the Z80-MBC2, a Z80 Assembly program that prints a message to the console and blinks the board's User LED.

The source file, Blink demo Z80-MBC2.asm, is included in the sources of the Z80-MBC2 firmware in directory src. I assembled the program with the zasm Z80 assembler and converted it to HEX format with the bin2hex tool that comes with the z80pack Z80 emulator.

The screenshot shows the steps for uploading the demo to the Z80-MBC2 and running it. It's a Minicom session under Crostini Linux on my Chromebox.

First off, I brought up the Z80-MBC2 boot menu. After selecting the iLoad option, the Z80-MBC2 waited for the file transfer to start.

Next, in Minicom I executed the Paste file command (activated by the Ctrl+A Y keystroke), which reads an ASCII file and sends its contents as if it were typed in, and selected the program file blink.hex. A few seconds later the message Z80-MBC2 User led blink demo running... appeared on the console and the board's User led started blinking.

I completed the process successfully only after tweaking the transmission parameters.

The Z80-MBC2 developer notes the board's serial port can't handle high-speed data transfers, and advises to set a 50-90 ms newline transmission delay in the settings of the terminal emulator used for the transfer.

In Minicon I set the delay with the Newline Tx delay (Ctrl+A T D) option. But with my setup iLoad transfers abort even with delays up to 150 ms, causing the Z80-MBC2 to display a checksum error and halt.

To overcome the issue I set a character transmission delay of at least 5 ms with the Character Tx delay option (Ctrl+a T F).

#z80mbc2 #z80 #sbc

Discuss... Email | Reply @amoroso@oldbytes.space

Working on Suite8080 and using the Z80MBC2 encouraged me to learn Intel 8080 and Z80 Assembly.

Now I'm dipping my toes into x86 Assembly, which I've always been curious about and attracted by. An additional motivation is discovering MikeOS, a lovely real-mode operating system in x86 Assembly that's surprisingly easy to read and understand.

Therefore, I put together an environment to cross-develop and run x86 code.

Requirements

My desktop daily driver is an ASUS Chromebox 3, with the Crostini Linux container of chromeOS that lets me run most Linux software. Any emulation and development tools must therefore be available for Linux.

Intel x86 Assembly is close enough to 8080 Assembly that x86 code looks familiar. To leverage this similarity and avoid the complexity of x86 segmentation, for the time being I want to develop 16-bit real-mode programs that fit into the single segment of a .COM executable.

The obvious choice for an operating system to run these programs is MS-DOS. Why? Because its rich environment strikes the right balance between complexity and functionality.

So the emulator must run a full MS-DOS environment and boot from media images. Which enables coding for the bare metal, a PC with no operating system.

As for the Assembly tools, I prefer to cross-develop on Linux. Although I'm a retrocmputing enthusiast, for writing and building code I want the convenience of a modern system.

MS-DOS emulation

QEMU would have been my first choice for x86 emulation but has compatibility issues with Crostini, as virtualizing in a virtual environment is tricky.

A bit of research led me to DOSBox-X, which runs fine on Crostini as it emulates rather than virtualize. DOSBox-X is a fork of DOSBox with a more fleshed out MS-DOS environment. Plus it can boot from media images.

DOSBox-X running under chromeOS on my Chromebox looks like this:

Installing DOSBox-X on the Chromebox was straightforward. However, the Flatpak package carried almost a gigabyte worth of dependencies that nearly filled the Crostini file system. I had to resize the container from 7.5 to 10 GB to accommodate all the files and leave enough free space.

A feature I like is the emulator can mount a directory tree of the Linux file system as an MS-DOS disk. This is handy for quickly transferring cross-assembled binaries to MS-DOS.

DOSBox-X has rendering issues on chromOS, i.e. the menu bar and items flicker randomly. A workaround is to turn off the menu bar.

I tested DOSBox-X booting by checking out MikeOS, which runs well.

Assembly development

There's a vast assortment of x86 assemblers but I skipped the research by picking NASM for Linux.

I like this popular tool because it's rich of features and comes with extensive documentation. It also has a clean, non verbose syntax and can generate MS-DOS .COM programs.

To test the full cross-development and emulation toolchain I used NASM to assemble an x86 real-mode hello world demo, copied it to a directory DOSBox-X mounts as a disk, and ran it under MS-DOS. Success! A simple and low friction workflow.

#Assembly #MSDOS #chromeOS #retrocomputing #x86

Discuss... Email | Reply @amoroso@oldbytes.space