Paolo Amoroso's Journal

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

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@fosstodon.org

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@fosstodon.org

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@fosstodon.org

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@fosstodon.org

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@fosstodon.org

First reading about Flet made me jump over my chair as it's what I was long looking for, a solution to my web and Android development needs. Flet is an opinionated, Flutter-based GUI framework for creating multi-user web, desktop, and mobile applications.

What I was looking for is an easy way of creating simple web and Android apps in Python. Web frameworks such as Django are overkill and too low level for me, and in most cases require JavaScript or other non-Python frontend code.

As for mobile, although there are Python frameworks for Android development like Kiwi and BeeWare, they come with the ballast of a heavy Java and Android SDK toolchain.

Flet overcomes these issues. It enables creating web apps that hide a web framework under the hood. And, without touching Java, Flet can make also PWAs that run on Android and other mobile platforms. All from the same fully Python code base. Plus, deploying Flet web apps to my favorite Python environment, Replit, is well supported and straightforward.

I'm closely following the development of Flet and will experiment with the framework.

#Android #Python

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

I develop programs for the Z80-MBC2 in Intel 8080 Assembly with the Suite8080 8080 assembler. Aside from the binary compatibility, the Z80-MBC2 is a Z80 system, so I wondered what Assembly mnemonics and register set the CP/M development tools work with.

It turns out my favorite CP/M debugger, the SID symbolic debugger, comes in two versions specialized on the CPU, SID and ZSID.

SID accepts as input and outputs 8080 mnemonics and registers, ZSID Z80 mnemonics and registers. For example, in this CP/M 3.0 SID session on the Z80-MBC2 I loaded my Twirl 8080 program and disassembled it with SID's l (list) command:

A>sid f:twirl.com
CP/M 3 SID - Version 3.0
NEXT MSZE  PC  END
0180 0180 0100 D4FF
#l
  0100  MVI  C,09
  0102  LXI  D,0139
  0105  CALL 0005
  0108  LXI  H,0142
  010B  MVI  B,08
  010D  PUSH H
  010E  PUSH B
  010F  MVI  C,09
  0111  LXI  D,013E
  0114  CALL 0005
  0117  POP  B7

The output contains 8080 mnemonics. An analogous ZSID session running the same disassembly command outputs Z80 mnemonics:

A>zsid f:twirl.com
SID VERS 1.4
NEXT  PC  END
0180 0100 CDFF
#l
  0100  LD   C,09
  0102  LD   DE,0139
  0105  CALL 0005
  0108  LD   HL,0142
  010B  LD   B,08
  010D  PUSH HL
  010E  PUSH BC
  010F  LD   C,09
  0111  LD   DE,013E
  0114  CALL 0005
  0117  POP  BC

SID thus lets me work in a 8080 environment on a Z80 system.

#z80mbc2 #Suite8080 #CPM #Assembly

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

I've started writing a new Suite8080 demo in Intel 8080 Assembly, a CP/M program to move an ASCII character across the screen with vi's cursor keys h, j, k, and l. It's my first interactive CP/M program and does raw non-blocking I/O to read key presses.

#Assembly #Suite8080

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

Back in the early days of blogging, the tech press bashed RSS out of existence as it was supposedly too complex for ordinary users. To the point new bloggers don't even know what RSS is, some recent blogging platforms don't support RSS, and new personal and corporate blogs sometimes don't provide RSS feeds.

But if your blog doesn't have RSS or Atom, you shoot yourself in the foot.

You completely give up control of your traffic to search engines and social platforms. Along with email newsletters, RSS is among the few options remaining to bloggers for establishing a direct communication channel and relationship with readers. With no gatekeepers.

The readers who subscribe to your RSS feed always see all of your posts. No matter what Google, Facebook, or Twitter decide.

What if only a minority of readers subscribe to your RSS feed? Is it still worth it?

They are the readers you want. The superfans who share your work. They may be bloggers themselves and link to your posts from theirs, or enable other opportunities such as guest blogging or podcast interviews.

Those few RSS subscribers are much more engaged and valuable than the many social media users who don't read or click links.

I've seen two primary objections to RSS feeds.

The first is, if readers get the content in a feed without visiting the website, blogs can’t be monetized with ads. Aside from the growing use of ad blockers, bloggers can provide partial RSS feeds that contain only snippets of the posts. This way the readers have to visit the blogs to access the full text.

Another objection is RSS feeds make web scraping and content stealing easier. This is a legitimate concern. But, if a blog is valuable enough, the lack of an RSS feed is only a minor inconvenience for determined scrapers.

#blogging

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