Paolo Amoroso's Journal

retrocomputing

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

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:

DOSBox-X session under chromeOS on an ASUS Chromebox 3.

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

Exploring the Z80-MBC2 is a required learning step for the adventurous hobbyists and electronic enthusiasts who use this Z80 homebrew computer, to whom it's aimed.

The device comes only with schematics, source code, and a few brochures. However, despite the lack of an official manual, there is a lot of information on the Z80-MBC2 scattered across a number of websites. Put together, this content makes for a solid starting point for further exploration.

In my own journey I'm collecting these resources, which I share here in the hope they will help you get started. I'll update the post with more as I discover them.

Features and operation

The closest thing to a manual is the Z80-MBC2 guide by DarS007, a user who compiled an unofficual user guide. It consists of original notes and snippets from other sources organized into an architectural overview, software information, and tips.

The Z80-MBC2 developer Just4Fun published most of the available information on the project's Hackaday page. All its sections are well worth reading in full, particularly Details and Logs. Section Discussion contains Z80-MBC2 user posts with interesting links and tips.

I also recommend the project page of the Z80-MBC, the Z80-MBC2 predecessor with which it shares most hardware and software features. These pages provide complementary content, i.e. the Z80-MBC page has useful information missing from the Z80-MBC2 page.

Just4Fun published much of the same content on his personal website and has an Instructables guide.

The Z80-MBC2 user Coopzone posted some notes on managing virtual disks and files. Another user blogged his experience with assembling and using the Z80-MBC2.

Operating systems

The Z80-MBC2 can boot a number of operating systems such as CP/M 2.2 and 3.0, as well as UCSD p-System.

Nearly all the existing documentation on these historical systems applies to the versions that ship with the Z80-MBC2. The same goes with the application software for these operating systems that's preinstalled on the Z80-MBC2, for example WordStar and Turbo Pascal.

Some of these operating systems and programs are less known. Refer to the official QP/M and Collapse OS official websites for documentation on Q/PM 2.71 and Collapse OS, bootable from the Z80-MBC2.

As for lesser known application software, see the documentation of the VDE text editor on which the CP/M ZDE16 editor that comes with the Z80-MBC2 is based.

Programming languages

Along with the operating systems, the Z80-MBC2 firmware can boot a couple of programming language interpreters like the BASIC and Forth systems in the ROMs of typical 1980s microcomputers.

The Z80-MBC2 ships with a Nascom BASIC implementation modified by Grant Searles. See the Nascom BASIC documentation.

Development tools

In addition to using the supplied software, it's fun to program the Z80-MBC2 in C or Assembly. The project sites of the major compilers and development tools usable for the Z80-MBC2 usually provide documentation:

#z80mbc2 #sbc #retrocomputing

Discuss... | Reply by email...

I created a YouTube playlist about the Z80-MBC2 Z80 homebrew computer.

The videos visually decument my journey to using, learning, and programming the Z80-MBC2. They are screencasts demonstrating various features of the device and my projects, such as feature walkthroughs, running programs, coding sessions, and so on.

As I gain more experience with the Z80-MBC2, I'll publish more videos.

#z80mbc2 #sbc #retrocomputing

Discuss... | Reply by email...

I ported to CP/M Twirl, a twirling bar animation demo in Intel 8080 Assembly. I originally developed it for emuStudio, an emulator and development environment that recreates a number of classic computers and CPUs. The port runs on any CP/M system with an ANSI terminal or display.

This video shows Twirl running under CP/M 3.0 on the Z80-MBC2 computer, controlled from a Minicom terminal emulator session under Crostini Linux on my Chromebox.

How it works

The demo displays an ASCII animation of a bar twirling clockwise at the home position of the console, i.e. the top left corner. After clearing the screen, Twirl repeatedly moves the cursor to the console home, prints the current animation frame, and checks for key presses to decide whether to terminate.

Although visually simple, the program demonstrates some key Assembly programming techniques such as looping, calling BDOS functions, and doing output with ANSI escape codes.

Porting

The original Twirl runs on a virtual Altair 8800 computer with a Lear Siegler ADM-3A terminal emulated by emuStudio.

However, I designed the program intending to port it to CP/M. The necessary work consisted in replacing the Altair-specific I/O rutines with equivalent BDOS calls for printing a single character (function 02h) and a string (09h) of ANSI escape codes, and checking the console status for key presses (0bh).

The program logic works as is, but I had to modify the CP/M version for defining the appropriate constants and ANSI escape strings, as well as adapting to the execution environment of the operating system and returning control to it.

Building and running

For me, the whole point of writing programs like Twirl and getting Z80 hardware is to use Suite8080, the suite of Intel 8080 Assembly cross-development tools I'm writing in Python. The CP/M port is a new Suite8080 Assembly demo I built from source on Linux with asm80, the Suite8080 assembler:

$ asm80 twirl.asm

I tested the resulting 74 bytes twirl.com executable under CP/M 2.2 with the CP/M software emulators ANSI CP/M emulator and z80pack.

Running the demo at the CP/M prompt is straightoward:

B>twirl

Pressing any key quits Twirl and returns control to the operating system.

To exeute Twirl on actual hardware I converted twirl.com to Intel HEX format with z80pack's bin2hex tool, then transferred the twirl.hex file to the Z80-MBC2 under CP/M 3.0.

It was really rewarding to see Twirl come to life on a real Z80 computer and get a sense of its performance.

The code

Here is the full code of the CP/M port of Twirl:

; Twirling bar animation.
;
; Runs on CP/M with an ANSI terminal. Press any key to quit the program.


TPA        equ      100h
BDOS       equ      0005h
WRITESTR   equ      09h                ; Write string
WRITECHR   equ      02h                ; Write character
CONSTAT    equ      0bh                ; Console status

FRAMES     equ      8                  ; Number of animation frames


           org      TPA
            
           mvi      c, WRITESTR
           lxi      d, cls             ; Clear screen
           call     BDOS

loop:      lxi      h, anim            ; Initialize frame pointer...
           mvi      b, FRAMES          ; ...and count

loop1:     push     h
           push     b
           mvi      c, WRITESTR
           lxi      d, home            ; Go to screen home
           call     BDOS
           pop      b
           pop      h

           push     h
           push     b
           mvi      c, WRITECHR
           mov      e, m               ; Print current frame
           call     BDOS
           pop      b
           pop      h

           push     h
           push     b
           mvi      c, CONSTAT         ; Get console status
           call     BDOS
           pop      b
           pop      h
           ora      a                  ; Key pressed?
           jnz      exit               ; Yes

           inx      h                  ; Point to next frame
           dcr      b                  ; One fewer frame
           jnz      loop1

           jmp      loop

exit:      ret


cls:       db       1bh, '[2J$'        ; ANSI clear screen: ESC [ 2 J
home:      db       1bh, '[H$'         ; ANSI go to screen home: ESC [ H
anim:      db       '|/-\|/-\'         ; 8 frames

           end

The program represents the animation as the string |/-\|/-\, a sequence of ASCII characters that show the bar at various steps of the rotation.

After clearing the screen, Twirl begins the main loop loop: by initializing the frame pointer and count. An inner loop loop1: prints each animation frame, i.e. the characters of the animation sequence.

The inner loop moves the cursor to the home position and prints the current frame. Then it updates the frame pointer and count, and checks whether a key was pressed. In case of a key press the inner loop exits the program, otherwise it jumps back to the beginning of the main loop.

#Assembly #retrocomputing #Suite8080 #z80mbc2 #CPM

Discuss... | Reply by email...

Many thanks to Jan Rösner and Bastian Schade, the editors of 8bitnews, for featuring my Z80-MBC2 projects and adventures in issue #55. 8bitnews is my favorite retrocomputing newsletter, I don't miss a single issue and always read it cover to cover.

#z80mbc2 #sbc #retrocomputing

Discuss... | Reply by email...

Twelve years ago these days, in early July 2010, I put aside print books and began reading only ebooks. The transition to digital allowed me to read more, access books faster, and discover new content and authors.

My motivations for trying ebooks were my ageing eyesight, which was making reading printed material increasingly uncomfortable, and the curiosity for checking out a new gadget a friend had bought, an e-ink ebook reading device.

I soon replaced e-ink readers with ebook reading apps on my Android smartphones and tablets. They're equally effective and more practical, thus making dedicated devices unnecessary.

To round up my digital book experience, I also self-published two ebooks. They were mostly experiments for getting familiar with the digital writing, publishing, and promotion tooling and processes.

Over the years, I shared my digital reading experience and data on the ebooks I bought. Here are the latest entries:

I never looked back. Twelve years later, I'm super happy with digital reading and regularly buy or download tons of ebooks.

However, over the past year I resumed buying a handful of paper books.

Why? Because of my interest in retrocomputing.

Some old programming books about early systems and languages are difficult to find, even online. So, when I come across second-hand copies of valuable old technical books at reasonable prices, I buy them as backups, even if I continue reading and referencing their digital copies. I don't want these precious and rare works to disappear.

#ebooks #retrocomputing

Discuss... | Reply by email...