Author: thequietlearner

Max7219 7-segment module FlashForth code

thequietlearner1 Comment
Max7219-based LED module driven by FlashForth

I pulled this old 7-segment display out of storage so I could write a module to control it with FlashForth. Here is the repository URL:

https://codeberg.org/infrared/ff-max7219

Using the words in max7219defs.fs and max7219cmd.fs you can control the digits, using either BCD, or controlling the segments individually. Using BCD make your programming much simpler but only gives you four letters to work with (besides the number characters).

I used individual segment control to make this simple demo which lights up each segment in sequence. Here is a video — sorry for the fuzzy image:

A demo of individual segment control

Advertisement

Commodore 64 FORTH: durexforth

thequietlearnerLeave a comment
durexforth running on VICE Commodore 64 emulator

This will be a short post, since I’ve only been playing around with durexforth for a few minutes so far. But some things I already like about durexforth:

  • Is coded for the great retro Commodore 64 PC
  • Is licensed under a free software license (MIT License)
  • Was pretty easy to build: only dependencies are make, gcc, and the ACME compiler from sourceforge. I used gcc 10.3.0 and the latest ACME SVN checkout (r319) from https://sourceforge.net/p/acme-crossass/code-0/HEAD/tree/trunk/.
  • Implements the words for the 2012 FORTH standard.

As you see in the above screenshot, you can use the % prefix to designate binary input, which is great.

Screenshot from the durexforth tutorial video

Here are the word listings:

Word list page 1

Word list page 2

I’m in the process of installing the texlive Guix package so I can try to build he durexforth PDF documentation and learn more about this FORTH. Some additional gratuitous screenshots of me playing around in durexforth:

Guix Manifests: Package Outputs and Inferiors

thequietlearnerLeave a comment

Package Outputs in Manifests

This post assumes you are using Guix manifest files (a snazzy feature of Guix) and want to know how to specify a non-default package output. I could not find this documented in the current revision of the Guix info manual. You have to use the procedure specification->package+output. Here is an example which has only a few packages (for readability) but you can have as many packages listed as you want:

(packages->manifest
 (map (compose list specification->package+output)
      '("abbaye"
        "emacs"
        "transmission:gui"
        "youtube-dl")))

The use of specification->package+output allows the specification "transmission:gui" to work. It is necessary to use the compose and list procedures also in this manner, because specification->package+output is a procedure which returns multiple values. (See 6.11.7 Returning and Accepting Multiple Values in the Guile Reference info manual.)

Inferiors

Inferiors are another great feature of Guix, and our documented in the manual. Stated informally, inferiors allow you to list packages from any version of Guix (any commit, or you might say, any time in history) in your manifest file. I use inferiors to install an older version of the linphone software, since I was having some trouble with the latest version. Here is a modification of the above example:

(use-modules (guix inferior)
             (guix channels)
             (srfi srfi-1))

     (define channels
       (list (channel
              (name 'guix)
              (url "https://git.savannah.gnu.org/git/guix.git")
              (commit
               "3f1b2bd322b6cdba99a43d08e5e8464f7424cbc5"))))

     (define inferior
       (inferior-for-channels channels))

(packages->manifest
 (cons (first (lookup-inferior-packages inferior "linphoneqt"))
       (map (compose list specification->package+output)
            '("abbaye"
              "emacs"
              "transmission:gui"
              "youtube-dl"))))

Now, the linphoneqt package is installed as well from older guix commit 3f1b2bd322b6cdba99a43d08e5e8464f7424cbc5.

Inferiors highlight one of the really awesome aspects of Guix: because guix uses “functional package management”, you can have packages installed in your profile from different versions of Guix, without conflicts or breakages. This would be like if you had the ability in Debian to installation packages from Debian Jessie, Debian Stretch, Debian Buster, and Debian Bullseye without conflicts or breakages. This is not a problem in Guix.[1]

[1] You could conceivably have a run-time conflict, e.g., if the old package depended on a linux kernel feature not available from your running linux kernel. I’ve never run into this sort of problem in any of my use cases. In guix, you don’t have to worry about conflicting package dependencies (e.g., library versions) but of course on a running system there are some services that can only have one version running at a time, the obvious example being the linux kernel. Guix does allow you to have multiple system generations selectable from the bootloader, meaning that you could at least boot into different versions of the linux kernel as would be suitable for running different packages.