Cocoacrumbs

Cocoacrumbs

All of the buildings, all of those cars
were once just a dream
in somebody's head
Mercy Street - Peter Gabriel

Cocoacrumbs

5 minutes read

Pic 1

Warning: Before you get to enthusiastic… There is no integration at all with the VDP. This is alpha code and for experimenting only!


Bernardo Kastrup very kindly provided me with a beta version of the AgonLight hardware. It seemed only logical to try out Nuttx on the AgonLight(2) as well. And this turned out to be surprisingly easy now that I got NuttX working on my Z20X computer.


Setup of the AgonLight(2)

The AgonLight(2) loaded with the current state of the NuttX code talks via UART1 at 57.600 bps 8N1 to the outside world. Not via UART0 which is connected to the VDP! UART1 is available on the GPIO connector with:

    3.3V = pin 1
    GND  = pin 2
    Rx   = pin 17
    Tx   = pin 18

Available configurations

So far, I implemented the following configurations for the AgonLight:

  • agonlight:hello
  • agonlight:nsh
  • agonlight:nsh_builtin_hello
  • agonlight:nsh_basic

agonlight:hello

This is one of the smallest NuttX configurations, ideal for finding out if it will compile and run on new hardware. It simply prints something to the terminal and then runs forever in the idle loop. I decided to make the output a bit more colourful though by using a few ANSI colour escape codes.

A fancy Hello from NuttX on the AgonLight.

Note: I’m using picocom as terminal emulator instead of minicom. I found that minicom didn’t interpret the ANSI colour codes like picocom does.

agonlight:nsh

Now that the hello configuration has proven that we can have a successful compile and run of NuttX on the AgonLight(2), it’s time for something more ambitious, the nsh shell:

NSH running on the AgonLight(2).

agonlight:nsh_builtin_hello

NuttX also offers the possibility to built in apps inside the nsh shell. Lets try to add the hello application to nsh:

NSH with the hello app built in.

agonlight:nsh_basic

The apps/interpreters directory contains the implementation of 2 basic interpreters.

  • bas which is fully fledged BASIC interpreter by Michael Haardt
  • mini basic by Malcolm McLean

Unfortunately, both of them showed the limitation of the Zilog ZDS II tools.

Compiling bas proved to be a real challenge for the ageing C compiler. After finding workarounds for e.g. missing wchar.h files, the C compiler finally gave up and suggested contacting Zilog for technical support …

Compiling mini basic was a lot easier but is a lot more restrictive in its use. E.g. you can’t enter some kind of an editor to write the code in and then just run it. You need to give mini basic a file at the command line which it then will read and execute. The build also offers the option to compile in a basic program to avoid having to specify a path to a file containing the basic code. That’s what I opted for.

The BASIC program can be entered in the script.c file and I simply wrote this code:

static FAR char *script =
  "10 REM Test Script\n"
  "20 REM Tests the Interpreter\n"
  "30 REM By Malcolm Mclean\n"
  "40 PRINT \"\"\n"
  "50 PRINT \"############################\"\n"
  "60 PRINT \"# NuttX rocks on the eZ80! #\"\n"
  "70 PRINT \"############################\"\n"
  "80 PRINT \"\"\n"
  "90 PRINT \"Press enter to return to the NSH shell.\"\n";

After compiling, this mini basic is now available as a built in application of nsh:

NSH with the minibasic app built in.

The obvious question now is of course if BBC Basic can be added. The only potential problem I can see so far is that the current BBC Basic for the Z80 is running in Z80 mode (16 bit), not eZ80 (24 bit) and I have no idea if NuttX is happy running processes for both Z80 and eZ80 modes at the same time. This might be solved soon however since a port of BBC Basic to the eZ80 mode is currently underway.

If mixing Z80/eZ80 modes is possible in NuttX then maybe CP/M could simply become a task under NuttX while the eZ80 is doing other things as well. Not bad for an 8 bit CPU with a 40 year heritage…

Closing thoughts

This was a journal of my journey in NuttX land of the past 5 weeks. A lot of long evenings of compiling, reconfiguring, applying small changes and compiling again, trying to understand what’s happening, how things are supposed to build and work together.

I’m happy I got this far since this opens a lot of new possibilities for the eZ80 simply because of the treasure trove of high quality code [that I don’t have to write anymore]. I’m taking a slight pause though to catch my breath, explore other things and think of what to do next with NuttX (AgonHeavy anyone?).

Something else to consider. This was a port of NuttX version 9.1.1. NuttX is currently at 12.x. Maybe I should do some exploring to see if newer versions have new options that are desirable and then attempt to update the build system for a newer version of NuttX as well.


The code

What I did was simply downloading the source code tarballs for both nuttx and apps of version 9.1.1.

After extracting both tarballs, I initialized a git repo of it. Then I created my own branch ccc_dev_branch and used this branch to check in all my small modifications that lead to a NuttX that can compile, and finally works on the eZ80, under wine on Linux using the official ZDS II tools from Zilog.

You can find the git repo here.

Disclaimer

Although I verified the build on 2 separate PC’s (but using the same Manjaro Linux Distro) I can’t guarantee it will work for everyone. I guess, the best I can say in such circumstances is: It works on my computer: ¯\\_(ツ)_/¯

Recent posts

See more

Categories

About

Cocoacrumbs