Paolo Amoroso's Journal

Tech projects, hobby programming, and geeky thoughts of Paolo Amoroso

Beagle Term is a terminal emulator Chrome packaged app for controlling serial USB devices.

I checked it out with the Z80-MBC2 and the V20-MBC homebrew computers on my Chromebox and the app works well, with good VT100 emulation. A major downside is it doesn't support XMODEM or other file transfer protocols. And Google deprecated Chrome apps, so this one will eventually be discontinued.

When plugging a serial device into a USB port, chromeOS prompts to connect to the device from the Crostini Linux or the Android container. But Beagle Term runs in Chrome, so the selection isn't necessary and the notification may be dismissed.

Launching the app opens a connection configuration dialog prefilled with the default communication parameters, which are fine for the homebrew computers.

As I said VT100 emulation is pretty good. For example, here is the CatChum Pacman clone running under CP/M Plus on the Z80-MBC2:

CatChum Pcaman clone under CP/M Plus on the Z80-MBC2 homebrew computer.

And this is what WordStar 4 looks like under CP/M-86 on the V20-MBC:

WordStar under CP/M-86 on the V20-MBC homebrew computer.

Good VT100 support shouldn't be taken for granted in terminal emulators as it may be missing or broken such as in CuteCom or Serial USB Terminal.

#z80mbc2 #v20mbc #chromeOS

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

I enrolled into Bring Back Blogging. It's a project to encourage and bring awareness to blogging by challenging bloggers to publish at least 3 posts in January of 2023, and enabling readers to discover content in the list of participating blogs that includes almost 140 so far. I blog regularly anyway, so it was a no brainer.

I shared Bring Back Blogging on Mastodon and my toot generated huge enthusiasm, with many saying they'll join.

#blogging

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

The iLoad feature of the Z80-MBC2 homebrew Z80 computer allows uploading binary code that runs on the bare metal.

I thought it would be fun to try iLoad with some Intel 8080 code generated by the asm80 assembler of Suite8080, the suite of 8080 Assembly cross-development tools I'm writing in Python. But the code crashed the Z80-MBC2, uncovering a major asm80 bug.

It all started when, to practice the toolchain and process, I started with a Z80 Assembly demo that comes with the Z80-MBC2, which prints a message to the console and blinks one of the devices's LEDs. I assembled the program with the zasm Z80 and 8080 assembler, uploaded it via iLoad, and successfully ran it.

Next, I ported the blinking LED demo from Z80 to 8080 code and assembled it with asm80. But when I ran the demo on the Z80-MBC2, it crashed the device.

The baffling crash left me stuck for threee months, as I had no tools for debugging on the bare metal and there were only a few vague clues.

I carefully studied the less than a hundred lines of code and they looked fine. To isolate the issue I cut the code in half, leaving the part that prints a message to the console, and transforming the blinking demo into this bare.asm hello world for the bare metal:

OPCODE_PORT     equ     01h
EXEC_WPORT      equ     00h
TX_OPCODE       equ     01h
EOS             equ     00h
CR              equ     0dh
LF              equ     0ah


                org     0h

                jmp     start

                ds      16
stack:


start:          lxi     sp, start
                lxi     h, message
                call    puts

                hlt


message:        db      CR, LF, 'Greetings from the bare metal', CR, LF, EOS


puts:           push    psw
                push    h
puts_loop:      mov     a, m
                cpi     EOS
                jz      puts_end
                call    putc
                inx     h
                jmp     puts_loop
puts_end:       pop     h
                pop     psw
                ret


putc:           push    psw
                mvi     a, TX_OPCODE
                out     OPCODE_PORT
                pop     psw
                out     EXEC_WPORT
                ret

                end

The constants at the beginning define the addresses of the output ports, the opcode for sending a character over the serial line, and a couple of control characters. Next, the program sets up the stack and iterates over the output string to print every character.

The simplified demo program still crashed the Z80-MBC2, forcing me back to the drawing board.

Then I had an epiphany. What if the binary code asm80 generates is different from zasm's?

I fired up the dis80 disassembler of Suite8080 and compared the output of the assemblers. Sure enough, the difference jumped at me: the destination addresses of all the branches after the label message are off by 5 bytes.

The instructions branch to addresses 5 bytes lower, so the call to puts executes random string data that chrashes the device. The last correct address asm80 outputs is that of the label message. The address of the next one, puts, is wrong and leads to the crash.

Indeed, the same demo code assembled with zasm ran fine on the Z80-MBC2 and printed the expected message. This confirmed my hunch.

What now?

The next step is to find the bug in the Python source of asm80, which I'm developing with Replit. Although Replit provides a debugger, I won't use it. The tool is not well documented and I'm not sure how it works. In addition the Replit debugger is best suited to code started from the run button. This is inconvenient for command line programs like the Python scripts of Suite8080.

Therefore, I'll take the opportunity to use Python's native debugger pdb, which I always wanted to try in a real project. I played with pdb a bit and it looks easy to use, with all the commands and options handy.

Let's see if pdb can help me pinpoint the bug in the Python code.

#Suite8080 #z80mbc2 #Assembly #Python

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

I'm reading the book Writing An Interpreter In Go by Thorsten Ball, which I got along with the sequel Writing A Compiler In Go.

I have always been fascinated by compilers and seeked good learning resources. These books bridge the gap between short tutorials that teach how to write an arithmetic expression parser, and 900 page compiler tomes packed with math.

I don't know Go, but Ball designed the books and sample code so that no knowledge of the language is required other than a general programming background. All I know about Go comes from reading the Wikipedia entry and a short reference. Yet the code of Writing An Interpreter In Go is easy to understand, reads as pseudocode, and is arranged in short blocks rarely spanning more than a page.

I really love Writing An Interpreter In Go.

The book presents the material in a smooth and clear progression and anticipates the questions the reader may have. For example, whenever I wonder why some code does or doesn't do something, the next paragraph acknowledges and addresses the hurdle.

I hope Ball's books will help me rewrite the assembler of my Suite8080 suite of Intel 8080 Assembly tools, finally replacing the ad hoc syntacting analysis mess with a true and extensible parser.

#development #books

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

You know what I envied of those influencers with millions of followers? The magic of tweeting a question and getting valuable answers and advice from knowledgeable people.

I'm no celebrity, but on Mastodon I'm getting the same experience with orders of magnitude fewer followers.

As a retrocomputing enthusiast, it's a lot of fun to explore and program my V20-MBC homebrew Nec V20 computer. But CP/M-86, one of the operating systems the V20-MBC runs, was eclipsed by MS-DOS back in the day, leaving little surviving documentation and literature. Especially about CP/M-86 development.

So the Open Library listing of the book CP/M-86 Assembly Language Programming by Jon Lindsay (Brady Communications Co., 1986) caught my attention. Sadly, the text isn't available. I decided to try to track down the book, starting by asking for help on comp.os.cpm.

Without expecting much, I also posted a toot to my Mastodon account in case anyone had useful clues on the book. What happened next blew my mind.

Within a day the post was boosted over a hundred times, got some fifty stars, and received dozens of valuable replies. The replies contributed promising leads, tagged others who might know something, suggested workarounds or other lines of inquiry, and started a few interesting side conversations. Everyone went out of their way to assist.

I was speechless, breathless. Literally. I didn't even know how to adequately thank the many who chimed in.

This isn't possible on Twitter, where the algorithms boost celebrities and influencers and bury everyone else.

You may think this overwhelming support has something to do with my 1.1K Mastodon followers. But I've been having a similar experience since joining Mastodon ten months ago. I'd say the critical mass is somewhere between a few dozen and a couple hundred followers.

I want to give back. I want to give others the opportunity of a similar positive experience, which is within reach of everyone in the Fediverse. Boosts proved crucial to amplify my quest for help, so I'm boosting more toots for a chance to reach someone who may be interested or willing to help.

People are the ultimate algorithm.

#fediverse #retrocomputing #books

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

This is the 200th post over 10 months of my blog hosted at Write.as. The milestone is even more significant considering I published 146 posts over 3 years to my previous blog hosted at the bloated, inflexible, and clunky old Blogger.

I credit the milestone in large part to Write.as, a lightweight blogging platform that nearly eliminates friction with its Markdown support and minimalist design.

Typing into the Write.as editing area is all it takes to insert, format, and present the content of a post. With Blogger, even basic text formatting requires laboriously moving and clicking the mouse to select text, click icons, pick menu items, and apply formatting. It all adds up to enough friction to dread the experience and be discouraged from posting.

I started this blog on February 28, 2022. I stumbled upon Write.as at the end of a long research process that led to the best platform for my technical writing needs.

#blogging

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

I'm always looking for terminal emulators and communication programs for controlling the Z80-MBC2 and V20-MBC, hoping they provide useful features Minicom misses.

That's why when stumbling upon CuteCom I eagerly checked it out. CuteCom is a graphical serial terminal program for Linux with a clean and simple user interface.

I tried it in Crostini Linux on my Chromebox connected to the Z80-MBC2 and the V20-MBC. The layout of CuteCom's window reminds me of the Serial USB Terminal app for Android which, unlike Minicom's single input and output area, has an input field separate from the output area.

The basic features of CuteCom are okay, but the program has major limitations when used with my homebrew computers. The main one is the program does no terminal emulation, doesn't support the escape codes for terminal control, and doesn't even properly align the output of a simple program like DIR. This screenshot of a V20-MBC CP/M-86 session shows the issue:

CuteCom terminal connected to a V20-MBC homebrew CP/M-86 computer.

I checked out CuteCom also with the Z80-MBC2 and tried to upload a file with XMODEM to a CP/M Plus session. However, an error informed CuteCom was unable to start the Linux program sz. There were no other clues and CuteCom has no documentation, so I have no idea what may be wrong. sz seems correctly set up under Crostini.

Given these issues, I can't unfortunately use CuteCom with the Z80-MBC2 and the V20-MBC.

The program is not a full terminal emulator to run programs that send terminal control codes to format the output. Instead, it's designed for the different use case of accessing electronic boards, embedded systems, and other devices via a serial connection, which typically produce line-oriented output.

#z80mbc2 #v20mbc

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

The great experience with Mastodon and the Fediverse made me curious about other decentralized and federated platforms.

As the next step, I decided to check out the Matrix messaging and communication network. Browsing the list of the main homeservers led me to join aria-net.org, the only one in Italy where I live.

As Matrix clients I use the Element web app on my Chromebox and the Element Android app on my Pixel 4 XL. Element has a clean, modern design the developers rightly describe as “glossy”. I also love the Markdown support, a key productivity feature. There are several features and settings I need to study in more detail, especially the message encryption options.

However, my experience with the Matrix infrastructure has been a bit bumpy so far as the homeserver has configuration, stability, and certificate issues.

When signing up, an error reported the handle of my account was already in use, but the server let me sign in with and use it anyway. As prompted, I tried to verify my phone numer but received another error. According to the server's help desk phone verification was disabled.

Sometimes the Element web app doesn't load or is slow. But an even more serious issue prevents me from using the web app. For the past severel days, visiting the website has been returning the error NET::ERR_CERT_COMMON_NAME_INVALID due to certificate issues.

If these issues persist, I will have to migrate to a more stable homeserver. It won't be a problem as only one of my contacts uses Matrix so far.

#misc

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

I'm collecting and reading more Pascal programming books than I ever did.

My Z80-MBC2 and V20-MBC come with Turbo Pascal for CP/M preinstalled. Using the environment is making me rediscover Turbo Pascal and realize it's great for creating small CP/M tools and programs.

To take advantage of Turbo Pascal I have been gathering old books and other Pascal learning resources that cover the CP/M version I use, selecting only the best and most interesting.

All of them are available online, for example at the Open Library or Bitsavers.org. But these works are too precious and may disappear, not to mention the high prices of rare retrocomputing books. I want backups, so I bought used copies of some of these. Here's what my Pascal programming retro bookshelf looks like:

Pascal programming books.

These are the Pascal books and resources I reference most often, along with notes on what they cover or why I like them:

#pascal #retrocomputing #books

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

I’m typing this with a keyboard that is cheap and looks cheap. And I’m loving it.

My appreciation for cheap keyboards began with my first Chromebook, an Acer C720 I got to learn and explore chromeOS. I loved the device so much I switched to using chromeOS as my only desktop operating system. Back then my daily driver was an i3 ASUS Chromebox 2 hooked to a Logitech K120 full travel keyboard from my last PC.

With the Chromebox as the main desktop machine, I put aside the Chromebook for a while. But something later motivated me to play more with the Chromebook: its keyboard.

The screen of the Acer C720 has notoriously poor viewing angles. But I realized I could improve legibility by setting the Chromebook on a slightly taller desk, which made the viewing angle optimal. This led me to use the device more and appreciate its chiclet keyboard with good feedback.

To have a similar experience on the ASUS Chromebox 2 I used at the time, I bought the only low profile chiclet unit I found that provided the extended Italian layout with accented letters I wanted, an Atlantis Chocolate 1300 wired keyboard. It was cheap and came from a little known manufacturer, but worked great. I began enjoying typing on the Chromebox more and more.

When I upgraded to my current i7 ASUS Chromebox 3, I plugged the Atlantis keyboard into it. However, its cable and that of the mouse contributed to the mess on my desk, so I replaced the input devices with wireless units. I bought a Logitech M220 mouse and, again, the only low profile chiclet keyboard with the required layout I found, this Nilox Kt40W:

Nilox Kt40W wireless chiclet keyboard.

The keyboard cost me all of €14.69. Besides being cheap and from an unknown brand, the plastic finish and feel make it also look cheap.

But I really enjoy using the Nilox keyboard.

Pressing the keys makes a clunky noise, a satisfying kind of clunky with a pleasant feedback. At first the pressure of the keys felt hard, slightly more than the Atlantis. But I eventually got used to the keyboard and came to love it.

#chromeOS

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

Enter your email to subscribe to updates.