Atomized

Bootstrapping Nonguix

2026-05-21

How to perform a fresh install of nonguix

Maybe Later

2024-11-24

Maybe Later

"Install update" Maybe later.

"Sign in to access this content" No.

"It’s better in the app!" Whose fault is that?

"We completely redesigned this thing you need to do your job for no good reason" Got it.

"Disable any adblocker." Absolutely not.

"This content is for subscribers only." Close tab.

"Accept cookies." No.

"Try the new experience!" Maybe later.

"Allow random website to send you notifications?" No.

"Rate this app." Zero stars.

"Allow GenericTodoListApp to access your location?" No.

"Subscribe to our newsletter!" No.

"Sign in with Google" No.

"Donate $2.17" NO!

Why do companies ship this garbage? Products that barely work at all, actively stop their users from using them, and deliver awful experiences their users hate. Maybe someone can point to a 2% increase on an internal dashboard, but who actually likes this? Do the people shipping this junk use their own products?

When will they start building good experiences that solve problems instead of create new ones?

Maybe later.

Atari Space Duel Self-Test ROM Signatures

2022-05-30

An explanation of how Space Duel determines if a ROM is good

Old McCarthy Had a Form

2021-12-04

Old McCarthy Had a Form

What is EIEIO?

EIEIO is an Emacs Lisp implementation of (most of) the Common Lisp Object System (CLOS), which is a library for writing object-oriented Lisp. Both CLOS and EIEIO are implemented as normal Lisp code, with no special support from the runtime.

Why OOP Lisp?

Different problems require different solutions, which is why the most successful programming languages are multi-paradigm. There’s no single approach that’s optimal for every program, so choosing the best fit for your problem yields better results than cramming everything into the same model. OOP’s strengths make it a good choice for many medium- to large-sized programs needing encapsulation, abstraction, and/or extensibility.

My goal with this is for Emacs Lisp programmers to recognize cases where EIEIO is a good fit, and think to themselves "aha! there’s a thing for that!", then get on with writing their program instead of creating tooling that reimplements part of what EIEIO already does.

The CLOS Model

If you’ve used OOP languages before, you may find the CLOS approach surprising. It’s object-oriented, but very different than popular OOP languages like Java, Python, Ruby, C++, etc.

Classes

Classes are similar to other OOP languages: they define how a structure encapsulates data. Unlike other languages, CLOS classes only have fields ("slots," in CLOS parlance) — no methods.

Here’s an example of a base class for an EMMS player. It only has one slot, a boolean to indicate if it’s playing or not.

(defclass form/emms-player ()             ; parent class/es
  ((playing :type boolean :initform nil)) ; slot (field) defintions
  :abstract t)                            ; EIEIO extension

The :abstract option is an EIEIO extension, but it’s a good one. Similar to Java, an abstract class may be extended, but cannot be instantiated by itself. They’re not always necessary, but in this case it represents a lower type bound.

Once the base class is defined, it can be extended. Here’s one which can hold an MPV implementation of the form/emms-player:

(defclass form/emms-player-mpv (form/emms-player) ; Child of form/emms-player
  ())                                             ; no additional slots

Instantiation

Defining the class also defines a constructor function with the same name, so getting an object is as simple as:

(form/emms-player-mpv)

#s(form/emms-player-mpv nil)

This is the normal way of creating objects, but if you’re doing more dynamic programming and need to instantiate different classes based on a symbol value, make-instance makes that easier:

(let ((class 'form/emms-player-mpv))
  (make-instance class))

#s(form/emms-player-mpv nil)

The #s reader macro will evaluate to an equivalent object, which means objects can be printed and read as normal:

(list #s(form/emms-player-mpv nil)
      (read "#s(form/emms-player-mpv nil)"))

(#s(form/emms-player-mpv nil)
   #s(form/emms-player-mpv nil))

Accessing Slots

Once you have a class instance, you can access the slots in three ways.

The simplest are the oref and oset macros. Since they’re terse and don’t evaluate the slot argument, they can be convenient in some cases.

(let ((p (form/emms-player-mpv)))
  (progn (oset p playing t)
         (oref p playing)))

The slightly more verbose slot-value function takes an evaluated slot name, making it a good choice if you need to store the slot symbol in a variable.

(let ((slot 'playing))
  (slot-value (form/emms-player-mpv) slot))

nil

Both styles are =setf=’able:

(let ((p (form/emms-player-mpv)))
  (list
   (progn (setf (slot-value p 'playing) t)
          (slot-value p 'playing))
   (progn (setf (oref p playing) nil)
          (oref p playing))))

(t nil)

But the nicest way is the with-slots macro, which is a bit like a destructuring let-bind. The first argument is a list of slot symbols, which behave like ordinary variables within the body of the macro. The bound symbols are also =setf=’able:

(with-slots (playing) (form/emms-player-mpv)
  (list playing (progn (setf playing t) playing)))

(nil t)

Slot Initialization

There are three ways to set the initial value of a slot.

The class’ :initform (if specified) is the default if no other value is provided. You’re not limited to constants or static defaults — the form is evaluated at object construction time. So you can do things like initialize a slot with the current time:

(defclass form/now ()
  ((time :initform (current-time-string))))

(list
 (oref (form/now) time)
 (progn (sleep-for 1)
        (oref (form/now) time)))

("Sat Dec  4 15:02:31 2021" "Sat Dec  4 15:02:32 2021")

If the class has an :initarg option set, it specifies the keyword used to initialize the slot when the object is created.

(defclass form/now ()
  ((time :initform (current-time-string)
         :initarg :time)))

(list (slot-value (form/now :time "about half past noon") 'time)
      (oref (make-instance 'form/now :time "a quarter till 1") time))

("about half past noon" "a quarter till 1")

The third way is to define an initialize-instance method, which is useful for cases where initialization depends on the value of multiple slots. But I haven’t covered generic functions and methods yet, so let’s do that now.

Generic Functions

CLOS implements dynamic dispatch from a generic function to a method. The generic function is like an interface: it only specifies the function name and argument list. CLOS doesn’t have explicit, named interfaces.

This example shows some generic functions that would work with an EMMS player object. EMMS doesn’t use CLOS, but these are the same functions it needs to define a player backend.

(cl-defgeneric form/emms-playablep (player track))
(cl-defgeneric form/emms-start     (player track))
(cl-defgeneric form/emms-stop      (player t))

Methods & Specialization

Methods are implementations of generic functions. In the same way that a Java interface can have many classes implementing it, a generic function may have many methods. Methods are never called directly; code calls the generic function (just like any other function), and EIEIO dynamically dispatches to an appropriate method. The method definitions include specializers which tell CLOS when to invoke them.

Defining a method will implicitly create the generic function, if it hasn’t already been defined.

Building on the EMMS example, here are some fake implementations of the EMMS player functions:

;; Method applies when PLAYER arg is an instance of form/emms-player-mpv (or a subclass)
(cl-defmethod form/emms-playablep ((player form/emms-player-mpv) track)
  (not (eql :unplayable track)))       ; MPV can play almost anything!

(cl-defmethod form/emms-start     ((player form/emms-player-mpv) track)
  "Started")

(cl-defmethod form/emms-stop      ((player form/emms-player-mpv))
  "Stopped")

In this example, the first argument contains the specializer, which says that the player argument must be an instance of form/emms-player-mpv (or an instance of a subclass of it).

Even though you can dispatch on subclass-of-type, you aren’t limited to it. You can:

Dispatch on primitive type: (x integer)
Dispatch on value: (x (eql 5))
Dispatch on properties of multiple arguments: ((x integer) (y float))
Fallback, default dispatch: (x t)
Define your own: see cl-generic-generalizers

Qualifiers

CLOS uses a qualifier to support four different kinds of methods. The examples so far have had empty qualifiers, which makes them the primary method; these are equivalent to methods or functions in other languages. In addition to those, CLOS has:

:before. Evaluated before the primary method(s).
:after. Evaluated after the primary method(s).
- Both before/after are for side effects only; their return values are discarded.
:around. Evaluated around the all other method types. Their return value is the return value of the function, and they may choose to return the primary method’s, or substitute it with their own.

Both the primary and around methods can choose to run the rest of the methods, by calling cl-call-next-method, or choose not to, returning their own value instead.

If you’ve done much Emacs Lisp programming, those last three type will be very familiar: they replicate Emacs’ built-in function advice. But, where advice runs globally on every function call, qualified methods may be composed into an EIEIO class hierarchy. This allows freely mixing in new behavior to existing code, without need for guards.

Multiple Inheritance

In addition to the single inheritance in the previous examples, EIEIO supports full multiple inheritance. This is a very powerful mechanism which allows deeper separation of concerns than most languages, where extremely generic code may be composed to get the precise behavior desired.

For example, here’s an implementation of a logging class. It’s completely separated from any other concerns: it only logs, and only knows about logging.

(defclass form/logger ()
  ((messages :initform nil)))

(cl-defmethod form/log ((logger form/logger) format-string &rest args)
  (with-slots (messages) logger
    (push (apply #'format format-string args) messages)))

(cl-defmethod form/logs ((logger form/logger))
  (with-slots (messages) logger messages))

(cl-defmethod form/latest-log ((logger form/logger))
  (car (form/logs logger)))

(let ((l (form/logger)))
  (form/log l "Hello, %s!" "world")
  (form/latest-log l))

"Hello, world!"

Building on that, a generic logging EMMS player class can be defined, which adapts the logger class to the EMMS player interface.

The methods use the three novel qualifiers: :before is used to emit a log prior to a player starting; :after is emits a lot after the player stops, and :around logs whether a track was playable.

(defclass form/emms-logging-player (form/logger)
  ())

(cl-defmethod form/emms-start :before ((player form/emms-logging-player) track)
  (form/log player "Playing track: `%s'" track))

(cl-defmethod form/emms-stop :after ((player form/emms-logging-player))
  (form/log player "Stopped"))

(cl-defmethod form/emms-playablep :around ((player form/emms-logging-player) track)
  (let ((playable (cl-call-next-method player track)))
    (prog1 playable
      (form/log player "Track `%s' is%s playable" track (if playable "" "n't")))))

With those two classes defined, they can be composed into a logging MPV player, by defining a new class which extends a concrete MPV player class and a logger.

(defclass form/emms-logging-player-mpv (form/emms-logging-player form/emms-player-mpv)
  ())

(let ((ml (form/emms-logging-player-mpv)))
  (list (list (form/emms-playablep ml :unplayable) (form/latest-log ml))
        (list (form/emms-playablep ml :foo) (form/latest-log ml))
        (list (form/emms-start ml :foo) (form/latest-log ml))
        (list (form/emms-stop ml) (form/latest-log ml))))

((nil "Track `:unplayable' isn't playable")
 (t "Track `:foo' is playable")
 ("Started" "Playing track: `:foo'")
 ("Stopped" "Stopped"))

Note how generic this code is:

form/logger only knows about logging: it doesn’t know that it’s logging EMMS actions.
form/emms-player-mpv only knows about playing, and doesn’t have any logging code at all.
form/emms-logging-player only cares about logging actions, and knows nothing about the specific player backend. It can be composed with any player backend to extend its functionality.
form/emms-logging-player-mpv only combines classes, it has no special knowledge of what they do.

The combination of multiple inheritance and before/after/around methods allows extremely rich & flexible functionality. Around methods mean you can add new functionality like memoization or performance profiling to existing code, without having to change it at all.

Structures

If you only need to encapsulate data, there’s also cl-defstruct. They don't support multiple inheritance, but perform better if you're just encapsulating data. Since generic functions can dispatch on any type, they can still participate in interface abstractions.

Nice Properties

There are a bunch of things I like about how this works.

It feels like normal Lisp. There’s limited new syntax, and you interact with the sytem by calling functions, as usual.

If you only need to encapsulate data, you can only use classes or structs. If you don't need a bunch of interface abstraction, you can pass objects to normal functions. If you only need interface abstraction, you can write generic functions without using classes or structs. This ala carte approach allows using only what tools are needed, instead of pulling in unnecessary baggage or boxing you into a particular model.

Multiple inheritance means you get type punning. An instance of form/emms-logging-player-mpv is both a logger and an EMMS player, and can be substituted for code which expects either.

An upshot of that is that third-party code can be adapted to any interface without needing to modify it. Whereas Java-type systems may require building an adapter class (which then isn't an instance of the wrapped type), CLOS doesn't have this problem.

Dynamic dispatch is fully controlled by the methods, rather than the generic functions. A programmer who creates an interface may not be able to forsee all the ways it needs to be used. Methods declaring their own dispatch conditions means that if you’re implementing an interface, you’re guaranteed to be able to express the dispatch conditions you need.

Because the calling convention is (function argA argB…), there’s no possibility for a null pointer exception, because there’s nothing to be null; the generic function always exists.

And because you can define a method specialized to a nil argument, you can have the same nil punning as in the rest of Lisp.

Practical Examples

Now that the model's laid out, how can it be put to use? I think EIEIO solves a lot of very practical problems.

Example: `transmission.el`

Here’s some abbreviated code from Emacs’ Transmission torrent client:

(defcustom transmission-host "localhost")
(defcustom transmission-service 9091)
(defcustom transmission-rpc-path "/transmission/rpc")
(defcustom transmission-rpc-auth '(:username "transmission"
                                             :password "trance mission"))

For this to work, all four variables have to be set, and set consistently. Annoyingly, the customization interface sorts them alphabetically, by variable name, instead of grouped logically, by function. So they end up strewn all over the buffer.

Instead, these could be expressed as an EIEIO class:

(defclass form/transmission-connection ()
  ((host :type string :initarg :host
         :initform "localhost"
         :custom string
         :documentation "Hostname or IP address to connect to.")
   (port :type integer :initarg :port :initform 9091
         :custom integer :label "Port"
         :documentation "TCP port on host to connect to.")
   (path :type string :initarg :path :initform "/transmission/rpc"
         :custom string
         :label "Path"
         :documentation "Path to Transmission RPC endpoint on HOST:PORT.")
   (username :type string :initarg :username :initform "transmission"
             :custom string :label "Username"
             :documentation "User to authenticate as")
   (password :initarg :password :initform nil
             :custom (choice
                      (const :tag "Fetch from auth-source" nil)
                      (string :tag "Password"))
             :label "Password"
             :documentation "Password for USERNAME"))

  :documentation "A class encapsulating a Transmission connection.")

This has two benefits. Firstly, Emacs’ global namespace is less polluted. With four variables, they all need the transimission- prefix, which is kludgey. Using a class allows for a single global variable, bound to an object, with the data neatly tucked into its slots.

Secondly, Emacs’ customization interface knows how to edit EIEIO objects. If you load eieio-custom, and specify the variable holding the object as type 'object, like this:

(require 'eieio-custom)

(defcustom form/transmission-conn (form/transmission-connection)
  "The Transmission connection."
  :type 'object
  :tag "Transmission connection")

Then the individual slots show up as separate (but grouped) customizable fields, making it very easy to edit, and also to express invariants about validity, making the configuration process much smoother.

Example: `sql.el`

Here’s the definition of the PostgreSQL backend for the built-in sql.el:

(postgres                               ; from sql-product-alist
 :name "Postgres"
 :font-lock sql-mode-postgres-font-lock-keywords
 :sqli-program sql-postgres-program
 :sqli-options sql-postgres-options
 :sqli-login sql-postgres-login-params
 :sqli-comint-func sql-comint-postgres
 :list-all ("\\d+" . "\\dS+")
 :list-table ("\\d+ %s" . "\\dS+ %s")
 :completion-object sql-postgres-completion-object
 :prompt-regexp "^[[:alnum:]_]*=[#>] "
 :prompt-length 5
 :prompt-cont-regexp "^[[:alnum:]_]*[-(][#>] "
 :statement sql-postgres-statement-starters
 :input-filter sql-remove-tabs-filter
 :terminator ("\\(^\\s-*\\\\g\\|;\\)" . "\\g"))

There’s a similar struct for every supported backend. The keywords on the left are common, shared among all backends, and the values on the right are the backend-specific implementations. Some are simple values, while others are functions.

This is a very clear example of an OOP interface abstraction. It’s already OOP, but it’s expressed with an ad-hoc system instead of a formal one.

Example: Modes

Emacs supports defining modes based on other modes’ behaviors:

(define-derived-mode shell-mode comint-mode "Shell" ...)
(define-derived-mode inferior-python-mode comint-mode "Inferior Python" ...)

What would it look like to have major modes implemented as EIEIO classes? Instead of the special-case define-derived-mode, new modes could extend others with the standard EIEIO mechanism.

Following this line of thought, what about minor modes? They’re very similar to mixins, adding new functionality to an existing mode. What if, instead of enabling minor modes with hooks, they were classes that got mixed in with major modes?

Conclusion

I think the CLOS/EIEIO model is extraordinarily powerful, much more so than other OOP languages I’ve worked with. It’s amazing that Emacs Lisp has this rich functionality out of the box, and it's a testament to Lisp's power that a whole new paradigm can be implemented without modifying the runtime.

This is an expanded version of my EmacsConf 2021 talk, Old McCarthy Had a Form.

Common Lisp in Practice

2020-07-06

Common Lisp in Practice

Introduction

One of the things which has kept Common Lisp out of my day-to-day toolbox is a lack of clear instructions how to get up and running with it — not in the REPL, but building small utility programs that can be called from the shell. I tend to reach for Python or Emacs Lisp, since I have a good grasp and they’re readily available, but I’ve always felt that Common Lisp could be a potent tool for these applications.

Building a project in Lisp can be confusing, because Lisp itself works so differently to other languages. While there are fundamental similarities to other AOT languages, the mechanisms are very different than most people are used to.

After reading my friend Steve’s Road to Common Lisp, I was inspired to figure this out. Many thanks to him for helping me with the proofreading and aiding my understanding where it lacked.

Goals

The overarching goal is to explain how to put together a Common Lisp Program, by walking through it step by step. The end result should be a functional, well-understood program.

It isn’t a tutorial on Lisp programming, because there are already great resources for that.

It doesn’t rathole on every possible approach you could possibly use, but treads and illuminates the beaten path. It explains the less obvious nuts-and-bolts of building Common Lisp programs by example: Where to put source code, how to make a binary, how to use libraries.

Running the Examples

If you’d like to run the example code, you’ll need to install Steel Bank Common Lisp (SBCL) (for all of them) and Quicklisp (for the last two). The Quicklisp installation is unusual if you’re coming from other languages, so it’s also fine to read along and see what things are like before investing in a Lisp environment.

This is written in a literate programming style using org-babel. All program output should be very, very close to what you’d see if you ran those programs. The original Org document and source code extracted from it are available in my GitHub repo.

Background

A typical compiler is a standalone executable which runs one OS process for each file, producing a binary artifact corresponding to its input; a linker executable combines those into the final binary. Some compilers output an intermediate representation (IR), such assembly language, then spawn a separate executable to assemble them.

Each executable represents a capability boundary. Their functionality is only usable in one way: by executing them with no context except what’s provided on their commandline.

For example, if you wanted the compiler to create the assembler listing in memory, then have the assembler work on that (skipping the whole compiler-output/assembler-input dance), you’re out of luck; it can’t be done. Or if you wanted to go one better and have the compiler create an in-memory AST the assembler can work on directly, this is also impossible.

Another way to think about this is that most languages have a close relationship between programs and binaries, and typically a single binary can run a single program. This wall precludes tight integration of multiple programs, because they can only communicate across the I/O constructs afforded to OS processes.

Common Lisp does not work this way. Much like interpreted languages, everything is loaded into one environment, and all functionality is accessible in the same way — by calling a function. However, Lisp goes much further than other languages.

For example, Python 3 ships with five executables:

dpkg -L python3-minimal | grep -c /bin/

This includes the interpreter, a byte-compiler, another program to remove the files the byte-compiler creates, etc.

OpenJDK has 8:

dpkg -L openjdk-11-jre-headless | grep -c /bin/

GCC has 16:

dpkg -L gcc | grep -c /bin/

And in order to actually use GCC, you also need binutils, which has many more:

dpkg -L binutils | grep -c /bin/

Can you guess how many Steel Bank Common Lisp (SBCL) has?

dpkg -L sbcl | grep -c /bin/

Just one, /usr/bin/sbcl. Everything that can be done with SBCL is done inside of the environment it provides.

The Environment; Images

When Common Lisp starts, it initializes a Lisp environment in the computer’s memory, then evaluates a toplevel function. The environment contains the Lisp language and tools; the standard toplevel is the REPL. When code is typed into the REPL, or loaded from a file, it’s added to the environment and can be used by other programs inside it.

The state of the environment can be saved to disk in a Lisp image¹, and restored by giving that image to sbcl(1), or executing the image directly from the shell. When the image is saved, a different toplevel function can be specified.

These are the building blocks for making executables. Code is loaded into the environment, then an image is created from that state, with the toplevel set to the desired entry point.

Version 1: Quick & Dirty

With all that out of the way, it’s time to make a traditional "Hello, World" program. This program will:

Run from a shell.
Use the first argument given to it as the name of the person or thing to greet.

Starting from the ground up, the function to create the greeting:

(defun greet (whom)
  "Create a greeting message for WHOM."
  (format nil "Hello, ~A." whom))

Trying this in the REPL shows that it works:

(greet "World")

The Toplevel Function

To satisfy the first requirement, a toplevel function is needed — this will be evaluated when the image is restored, handling the command-line arguments and printing the greeting.

I named the toplevel function MAIN, but it can be called anything. Any function which accepts zero arguments can be used as a toplevel.

(defun main ()
  "Greet someone, or something."
  (write-line (greet (first (uiop:command-line-arguments))))

  (uiop:quit))

There are two functions in here that may be new to you.

The command-line arguments given to an executable aren’t turned into arguments for the toplevel function, as with other languages; they’re returned from UIOP:COMMAND-LINE-ARGUMENTS.

As one might expect, UIOP:QUIT terminates the process.

Neither of these functions are part of the Common Lisp standard; both come from UIOP, which bridges some of the gaps in the spec, and between implementations.

Packages

The next thing to get a handle on is packages. This terminology is different than in other languages, which use it in the sense of "package manager," meaning a downloadable library and/or mechanism to install them.

In Common Lisp, a package is a namespace which contains symbols. The symbols can be defined in the package, like MAIN and GREET, or they can be symbols inherited from other packages, like DEFUN and FORMAT (which both come from the COMMON-LISP package²).

The Hello World example should define a package, called HELLO.

Packages must be explicitly defined before they can be used. Many languages treat a statement like:

package hello

As definition and use, i.e. everything declared in this file is implicitly put in the hello package.

The similar-looking Lisp analogue of this is IN-PACKAGE:

(in-package :hello)

While the code is similar, the semantics are different. This only sets the active package, it won’t create :hello³ if it doesn’t exist. Creating the package is an explicit step which must be done first.

The DEFPACKAGE macro creates a package. It takes a symbol naming it:

(defpackage :hello)

In Lisp, newly-created packages are completely empty, and don’t even include core language functionality like DEFUN. Those symbols can be used to by qualifying them with the package name, but in most cases, it’s desirable to use them directly. Adding a (:use …) form inside DEFPACKAGE will copy other packages’ exported symbols into the package being defined:

(defpackage :hello
  (:use :common-lisp))

If you hypothetically wanted to use to more packages, their symbols would need to be added after :common-lisp⁴. Note that this should be used with care, since updates to those packages could collide with the symbols in :hello.

In the same way that defining and using a package are separate, loading and using a package are also completely separate operations. While many languages have an import mechanism which both loads and uses, Lisp doesn’t work this way; :foo and :bar must have been loaded already.

Exports

The last package-related topic to cover is exported symbols. When a symbol is exported, it may be used by packages; the set of exported symbols comprises the public API of a package. Non-exported symbols should only be used within the same package.

Many languages specify visibility symbol-by-symbol, at the point of definition:

public int hashCode()

Lisp declares exported symbols when the package containing them is defined, using the (:export …) form:

(defpackage :hello
  (:use :common-lisp)
  (:export :greet :main))

Tying it All Together

The complete source for Hello World now looks like this:

(defpackage :hello
  (:use :common-lisp)
  (:export :greet :main))

(in-package :hello)

(defun greet (whom)
  "Create a greeting message for WHOM."
  (format nil "Hello, ~A." whom))

(defun main ()
  "Greet someone, or something."
  (write-line (greet (first (uiop:command-line-arguments))))

  (uiop:quit))

Building an Image

Because the Common Lisp toolchain exists inside the Lisp environment, build scripts for Common Lisp project are written in, you guessed it, Lisp.

The first thing the build script should do is load the source of the program, which I’ve placed in hello.lisp:

(load "hello.lisp")

Then, tell Lisp to dump the image into an executable, which will call MAIN when invoked:

(sb-ext:save-lisp-and-die "hello"
 :toplevel 'hello:main
 :executable t)

I’m using SBCL for these examples, and SB-EXT:SAVE-LISP-AND-DIE is the SBCL way of doing this. The precise incantation will vary based on Lisp implementation, because it’s not part of the Common Lisp standard.

The call to SAVE-LISP-AND-DIE could be put at the end of hello.lisp for this example, but it’s is a poor separation of concerns for anything more complex than one-off scripts. Its rightful place is build.lisp.

The complete build script goes into build.lisp and looks like:

(load "hello.lisp")

(sb-ext:save-lisp-and-die "hello"
 :toplevel 'hello:main
 :executable t)

Executing the build script with sbcl(1) will produce the binary:

sbcl --non-interactive --load build.lisp

Running it shows the message:

./hello World

Passing in the name of the current user also works:

./hello $(whoami)

Now that the program works, and you hopefully understand why and how, it’s time to tear it down and rebuild it a few times.

Version 2: Package Structure

Having all the code in one file is fine for a toy, but larger programs benefit from more organization. If the core functionality is split from the CLI, other projects (or other parts of the same project) can reuse the greeting function without the CLI code.

Also, Lisp packages can span files, so it’s not good practice to put the package definition in one of the N files that represent its contents.

What this should look like is:

build.lisp
packages.lisp
- src/
  - greet.lisp
  - main.lisp

The organization is different, but the contents of the files are almost exactly the same.

The package definition is identical to v1, but moved into packages.lisp:

(defpackage :hello
  (:use :common-lisp)
  (:export :greet :main))

The greeting code is moved to src/greet.lisp. It’s identical, except it has to declare the package it belongs to.

(in-package :hello)

;; Unchanged from v1
(defun greet (whom)
  "Create a greeting message for WHOM."
  (format nil "Hello, ~A." whom))

The CLI code moves to src/main.lisp, and also declares what package it’s in:

(in-package :hello)

;; Unchanged from v1
(defun main ()
  "Greet someone, or something."
  (write-line (greet (first (uiop:command-line-arguments))))

  (uiop:quit))

The build.lisp script needs to load the new pieces in the correct order. Since packages must be defined before they’re used, packages.lisp needs to be loaded before either of the files in src/; since MAIN calls GREET, the file containing GREET must be loaded before the one with MAIN:

(load "packages.lisp")                  ; Load package definition
(load "src/greet.lisp")                 ; Load the core
(load "src/main.lisp")                  ; Load the toplevel

;; Unchanged from v1
(sb-ext:save-lisp-and-die "hello"
 :toplevel 'hello:main
 :executable t)

Building and running works the same way:

sbcl --non-interactive --load build.lisp
./hello World

Version 3: Systems

The next yak in the recursive shave is systems. Packages are part of the Lisp language specification, but systems are not; they’re provided by a library. The dominant systems library at the time of writing is ASDF, which means "Another System Definition Facility." ASDF is a de facto standard, and comes bundled with both SBCL and Quicklisp.

Systems and packages are orthogonal, but since they both deal with some of the same parts of the project, and the names often overlap, it can get confusing.

A package is a way of organizing the symbols of a project inside the Lisp environment. Lisp doesn’t have a convention for determining what package things belong to based on the path or filename. One package can be split across multiple files, or one file can contain multiple packages.

A system is a description of how to load part of a project into the environment. A system can load multiple packages, or it can load a subset of one package. Systems encapsulate the list and order of files needed to produce a usable package.

Further complicating things, one project can have multiple systems. A system is a view into part of a project, and different code may need different pieces. For example, test code will need the test library loaded, or may need to set state before loading the code to be tested, or may need to change values inside the package containing it. Having a separate system for tests allows these different usecases to be supported gracefully.

Defining the System

Systems are defined in an .asd file, using the DEFSYSTEM form. To maintain good separation of concerns, the Hello World project needs two systems: one for the core, and one for the CLI. For these examples, I’ll be using the CLI system to demonstrate. If someone wanted to reuse the core GREET code in their own program⁵, they’d use that system.

(defsystem :hello)

There are multiple strategies for loading code, but the easiest is to load components in the order they appear in the system definition. This is indicated with :serial t:

(defsystem :hello
  :serial t)

Then, the components need to be specified. These are the files and directories the make up the system:

(defsystem :hello
  :components ((:file "packages")
               (:module "src"
                        :serial t
                        :components ((:file "greet")))))

Then a secondary system for the binary. The only new thing is :depends-on, which indicates that this system relies on the earlier one.

(defsystem :hello/bin
  :depends-on (:hello)      ; This system needs the core HELLO system…
  :components ((:module :src
                :components ((:file "main"))))) ; …and includes one
                                                ; additional file.

Putting the two declarations together into hello.asd results in:

(defsystem :hello
  :components ((:file "packages")
               (:module "src"
                        :serial t
                        :components ((:file "greet")))))


(defsystem :hello/bin
  :depends-on (:hello)      ; This system needs the core HELLO system…
  :components ((:module :src
                :components ((:file "main"))))) ; …and includes one
                                                ; additional file.

Since the system defines the files and load order, the build script doesn’t need to replicate that anymore; it can lean on Quicklisp and ASDF instead:

(ql:quickload :hello/bin)

(sb-ext:save-lisp-and-die "hello"
 :toplevel 'hello:main
 :executable t)

ASDF needs to be told where to find the system definition, and all others it should be able to load. This is a complex topic, but the simplest approach is:

Use Quicklisp.
Make a symlink from Quicklisp’s local-projects directory, named after the project, which points to the source tree.

This is easily the grossest thing about this entire setup.

rm ~/quicklisp/local-projects/{hello,system-index.txt}
ln -sf $PWD/v3 ~/quicklisp/local-projects/hello

The rest of the source is unchanged from v2.

Running works the same way:

sbcl --non-interactive --load build.lisp
./hello World

Version 4: Using Libraries

The final step is to replace UIOP’s basic program arguments with a more full-featured library, unix-opts.

Common Lisp libraries are installed via Quicklisp, and loaded with ASDF. As with other Common Lisp tasks, actually installing the library is done from the REPL.

Quicklisp

Quicklisp is not a package manager like other languages have. There’s no project-specific setup, like with virtualenv or rbenv. There’s no node_modules.

Quicklisp is more of a caching mechanism than a package manager. Similar to Maven’s ~/.m2, a single copy of the code is stored in ~/quicklisp/dist/quicklisp/installed. ASDF looks there when asked to load systems into a Lisp environment.

As with other tooling, the primary interface for Quicklisp is the Lisp environment.

Installing unix-opts

The Quicklisp documentation discusses this, but I’m going to cover the essentials.

Quicklisp has QL:SYSTEM-APROPOS, which searches available libraries:

(ql:system-apropos "unix")

Installing is done with QL:QUICKLOAD. This downloads the library (if necessary) and loads its system:

(ql:quickload "unix-opts")

Defining the Systems

The only change to the system definitions is adding :unix-opts to the :depends-on form. Note that this refers to the system, not the package. Systems provide packages, and depend on other systems. Because build.lisp uses QL:QUICKLOAD to load the system, it’ll notice if unix-opts (or any other system in :depends-on) hasn’t been installed, and do that automatically.

The New `MAIN`

With the :unix-opts system loaded, the :unix-opts package is available for MAIN to use:

(in-package :hello)

(unix-opts:define-opts
  (:name :help
   :description "Print this help text"
   :short #\h
   :long "help"))

(defun main ()
  "Greet someone, or something."
  (multiple-value-bind (options free-args)
      (unix-opts:get-opts)
    (if (or (getf options :help) (/= (length free-args) 1))
        (unix-opts:describe
         :prefix "A Hello World program."
         :args "WHOM")
        (write-line (greet (first free-args)))))

  (uiop:quit))

Nothing needs to change in any of the other source files.

Building

For this to work, the Quicklisp local-projects symlink created in v3 needs to be updated to point here instead:

rm ~/quicklisp/local-projects/{hello,system-index.txt}
ln -sf $PWD/v4 ~/quicklisp/local-projects/hello

…and the ASDF registry cleared:

(asdf:clear-source-registry)

After building (using the same commands as previously), the new options parser is working:

sbcl --non-interactive --load build.lisp

./hello

./hello $(whoami)

Conclusion

At over four thousand words, this piece has been a lot more than I set out to write. The process of learning, organizing, and refining my own understanding has been wonderful. I hope you’ve been able to take away some of that, and will go forth with useful new tools.

Footnotes:

SBCL refers to them as "cores."

:CL is an alias for the :COMMON-LISP package, so (:use :cl) is a common equivalent.

You may note that I’ve written the name of the package as HELLO (which it is), but it’s in the code as :hello. For a deeper explanation on why this is the case, I recommend the chapter on Packages and Symbols from Programming in the Large. In the mean time, you’ll just have to trust that it’s right and I know what I’m doing.

⁴

:cl is an alias for :common-lisp, so it’s common to see that in code in the wild.

⁵

For example, to have their program greet the user when it starts, or to create a massively multiplayer online Hello World (MMOHW).

Repairing Asteroids

2020-05-09

Repairing Asteroids

Repairing Asteroids ATTACH

Asteroids is one of my favorite games, and I’ve owned numerous cabinets over the years. If my memory serves, I’ve had three uprights and three cabarets. My current keeper cabinet is cabaret s/n 750, which I took to the Portland Retro Gaming Expo from [2019-10-18 Fri] through [2019-10-20 Sun]. Several former Atari employees were there, including Ed Logg (the programmer of the game) who was kind enough to autograph my game.

Figure 1: My Asteroids, autographed by Ed Logg.

The game made it through the show just fine, but when I put it back in its spot in my game room and turned it on, it was playing blind¹.

This is a newer acquisition, so I haven’t gone through it; some problems are to be expected.

I pulled the machine back out of the row to investigate. I found:

The neck of the monitor was glowing. With raster monitors, this is usually a very good sign, because the 6.3V for the tube filament (which is what’s glowing) comes off the flyback, which means that things are mostly working. But, on these B&W vectors, the power comes from a winding on the transformer in the bottom of the cabinet, so this doesn’t tell us anything about the state of the monitor.
The spotkiller LED was off. This lights up if the monitor has gone into shutdown because no video signal is present. When the LED is off and the monitor isn’t working, that points to an issue with its power supply.

So, I removed the monitor and started looking things over. Right away, I found that fuses F100 and F101 on the monitor’s deflection board appeared to be blown. I tested them anyway, by pulling one end out of the fuse holder and using a multimeter in continuity test mode. You always want to disconnect at least one end of the fuse from the circuit to test.

And they were, indeed, blown.

Figure 2: Blown fuses

These games came with either a Wells-Gardner 15V2000 or an Electrohome G05-805 15" B&W vector monitor. Atari made the design, then had Wells and Electrohome manufacture them, so they’re very similar, but not identical. This machine has a the Electrohome version.

Figure 3: Power supply schematic

Pulling up the schematic, you can see that this is a very simple unregulated AC-to-DC power supply, with a bridge rectifier, two filter caps, and two decoupling caps.

The fuses protect the AC side of the diode bridge, so it’s a fair bet that they blew because DB100 failed short and started drawing too much current. So, out that comes for testing.

As the schematic shows, DB100 is four diodes potted into a single component with four leads. It can be tested using the diode function of a multimeter, which I did, and found it shorted.

I didn’t have a new replacement handy, so I pulled one from a parts monitor and put it in. I also did a field modification; later revisions of these monitors deleted resistors R100/R101, because they weren’t necessary, but had a high failure rate. They can be bypassed by soldering 18ga wire across them, which is what I did.

Next, test. One thing I’ve learned from working on electronics of all kinds is: if you reassamble something before testing it, it definitely will not work.

I have an extension cable I made for this purpose, which lets me hook the monitor up to the game while it’s sitting outside the cabinet. So, I did this, flipped the power on, and... success!

Back into the cabinet it went. I also took a few minutes to vacuum out the inside of the cabinet, clean dust off the CRT face, etc.

Figure 4: The Asteroids multi-game bootup splash screen

Footnotes:

"Playing blind" means the game appears to be working, but isn’t displaying an image.

I like ThinkPads

2019-03-20

I like ThinkPads

When I switched back to Linux, I bought a Dell XPS 13. It’s a very slick little machine, but hasn’t held up quite as well as I’d hoped. This is partly my fault, because it’s taken a couple spills, but several issues are due to the design of the system. It runs hot, the fans are noisy, the rubber feet came unglued, and after two years the battery only holds 55% of a charge. It still works, but the issues add up -- I don’t think I’ll be getting another one.

ThinkPads are the other line of laptops that are known for running Linux well, so I figured I’d see what was available there. I ended up ordering an X1 Carbon (6th gen) while it was on sale at the end of the year, but found that it wasn’t to my liking. The size and build quality are terrific, but it had a some deal-breaker issues. The soft touch finish feels nice, but collects skin oil so easily that it looks grubby all the time. The memory card reader only accepts microSD cards, is hidden behind a panel, and you have to close the lid to access it. It’s pretty much unusable, and they really shouldn’t have even bothered including it. The high-DPI display is a weird resolution that’s much too small at 1x scaling and much too large at 2x; and scaling to 1.5x is a big hassle in Linux. The speakers are also were terrible. I just don’t think a laptop with a $2,000 list price should have these kinds of issues. I’ve never returned a laptop in my life, but I returned this one.

Lenovo gets some credit for the painless return process. I got 100% of my money back without having to speak to anyone.

The ThinkPad 25 was another model I’d considered, a modern laptop with the classic ThinkPad style "7-row" keyboard. I was interested when it was first announced, but never bought one. They’ve been discontinued, but I found one on eBay for a decent price. It’s very nice. It might be too nice, because I’m afraid I’ll wear it out or drop it... Then what? Being a limited edition, parts are hard to come by. That nice classic style keyboard, for example: replacements were $300... when they were available... which they aren’t anymore. So if that breaks, I’m out of luck. Or if the keys wear smooth and I want to make it look new again, I just can’t.

But it is very nice.

Having heard that older ThinkPads are inexpensive and still run great, I went looking for one and ended up with an X230 from a local seller for $180. It’s the highest spec Core i7-3520M CPU, with 8gb RAM and a SSD -- and a matte screen, which I’d nearly forgotten how much I missed. Even though it’s nearly six years old, it still works great and is plenty powerful.

Cosmetically, it was pretty beat up. Compared to the ThinkPad 25, it’s actually liberating. I don’t have to worry about putting the first scratch on it, since it’s already got several.

The X230 is a great laptop, and I really like this machine; I’ve been using it daily. It’s a sweet spot in the ThinkPad lineup, with classic style and good performance. The X230 runs faster and cooler than its predecessor, and adds USB 3.0. The x240 which replaced it is inferior in several ways: It uses slower Ultrabook CPUs and removes the physical buttons from the TrackPoint.

ThinkPads are amazingly repairable. The amount of documentation and support for ThinkPads is incredible. Every model has a detailed service manual that shows how to replace every major component. You can look up every part used in a particular model, or put in a specific laptop’s serial number to see exactly what was in it when built. Lenovo still sells parts for older laptops, and what it doesn’t stock is usually available from third parties. Most parts are extremely cheap, ranging around $10-$30. Most repair jobs only take a few minutes. I swapped up the LCD panel for a nice IPS one in less than five minutes. A replacement for the cracked LCD bezel cost $13 shipped to my door.

Because all that documentation is available, ThinkPads are extremely hackable notebooks. Many models can use the open-source coreboot firmware, which is a free software BIOS replacement. It lets you neuter the Intel Management Engine, removes hardware restrictions, and boots faster than the stock BIOS. With a hardware modification, you can replace the original LCD panel in an X220 or X230 with a 1080p one. You can even install a classic "7-row" keyboard on models after they switched to the Mac-style "island" keys.

All this is to say: I really like ThinkPads. They’re cheap, powerful, repairable, and hackable -- all things I really appreciate these days.

So Long, Apple

2019-03-20

So Long, Apple

A brief history of my last Apple product purchases.

13" MacBook Air

Bought brand new in 2011, maxed out. Somewhat underpowered, but fine for most things I did. Great design. A good computer I was happy with. After three or four years, I’m thinking of a newer one, but there have been zero compelling upgrades. A couple processor bumps, but they’re all the same Ultrabook CPUs with the same number of cores running at the same speeds. I replace the battery instead.

Then, one day, I try to wake it from sleep. Instead of resuming from suspend mode, it boots up like I’d reset it. I put my disk password in, it gives me half a progress bar for a few minutes, then resets. Try again, same story; the disk has failed at the block level and can’t be unlocked. I boot the recovery partition, but it can’t repair this failure. My only option is to reinstall.

That’s fine, since I have backups, but I’m never trusting the storage on this machine again. The storage is soldered to the motherboard and can’t be replaced. Whoops.

I consider buying a new MacBook, but see that my options are another Air without significant upgrades, a low-end MacBook Pro, or a mainline machine with the terrible keyboard with a row of keys replaced with a touchscreen.

I buy a Dell XPS 13 instead.

Prior to this, I owned numerous Macs: The very first first MacBook Pro, then a Core 2 Duo, and a 27" iMac -- not including several I had for work.

iPhone 6

Bought launch day. I soon discover that it’s too large to use comfortably. The metal case bends within two weeks and I get the whole phone replaced. It has that godawful camera bump. It’s the first iPhone that I disliked.

iPhone SE

The iPhone SE comes out, and I buy one as soon as I can. It’s the perfect form factor, has no camera bump, and it’s fairly inexpensive despite being a very good performer. I like it a lot and am very happy with it.

iOS 11 happens, and it’s terrible, easily the single worst iOS release ever. Performance takes a huge hit, battery life suffers significantly, and the number of obvious, embarrassing bugs is through the roof. Text overflows its containers, controls are obscured by other things so they can’t be used, Night Shift mode makes the whole device slow down, and it keeps popping up errors about the iTunes store when I’m not doing anything related to it. I loathe it.

The hardware sleep/wake button fails. The phone thinks it’s always being pressed, which makes it bring up the power-off screen constantly. I power it off. It turns back on because the button is pressed, but before it can finish booting, it turns off again because the button is stuck.

The phone’s 18 months old and I don’t want to spend $100 repairing it. I don’t want to buy a new one, because they’re 18 months out of date and barely run the current iOS. Every current iPhone is too large and still has that camera bump. I hold out for a bit, hoping they’ll refresh the SE, but it doesn’t happen.

I buy a Sony Xperia XZ1 Compact instead.

Prior to this, I’d owned at least every other iPhone generation back to the very first model, and have never owned an Android phone.

iPad Mini 4

Having owned the first two iPad models, I was very excited to own an iPad Mini. It’s the perfect size. I buy them for everyone in my family. My daughter breaks hers and I buy myself a nice Mini 4 and hand her down my Mini 3.

Years pass with no upgrades. I break the screen on mine, and again, can’t justify the repair cost, and there is no new model of the same size.

I buy nothing instead.

Prior to this, I owned the very first iPad, an iPad 2, and iPad Mini 1.

Bye

It took me a while to write this, and in the interim, there have been new iPad Mini and MacBook Air models released. I don’t think I’ll be buying them. If I buy now, it’s going to be another four years of neglecting the hardware, while the software makes it more and more frustrating to use.

I love vintage hardware, but it loses its charm when you can’t run the same vintage software -- and Apple makes it difficult or impossible to do so.

It’s very clear to me that Apple doesn’t care about the parts of their product lineup I did. It’s very frustrating to see the parade of new stuff I will never, ever buy (Apple Watch, HomePod, AirPods) while chomping at the bit for a refreshed iPhone SE.

Handling OS-9 RBF (Fluke 9100) floppies on Linux

2018-12-17

Handling OS-9 RBF (Fluke 9100) floppies on Linux

I recently had need to figure out how to read and write floppy disks for the Fluke 9100 on a Linux box. There are various other methods for accomplishing this, but I was specifically looking for something that would work without special hardware or booting a non-Linux operating system. Since programs like TeleDisk / ImageDisk / SAMdisk can read using the same hardware, this is purely a software issue.

You need a machine with a real floppy disk controller (FDC) -- USB floppy drives won’t work.

Background

Floppy controller hardware can’t autodetect disk formats, it needs to be told what the format is. When a disk is ejected/inserted, the parameters reset to the defaults. If the disk doesn’t match them, the controller needs to be told what its format is again.

Linux’s floppy subsytem has many knobs exposed via fdutils, but the documentation isn’t great, so this requires some sleuthing.

Disk Format

Knowing the disk format up-front helps a lot. The 9100A uses soft-sector, double-sided, double-density floppies.

Bytes per sector	256
Sectors per track	16
Tracks (cylinders)	80
Formatted capacity	655,360 bytes

Later machines upgraded to a high-density drive. All the parameters are the same, except the sectors per track were doubled to 32, resulting in 1,310,720 of raw storage.

Each sector on the disk has its number recorded along with the data. PC disk formats start numbering their sectors at 1, but OS-9 begins numbering them at 0. This is important.

Tuning

The approach is to put the 9100 disk in, configure the controller with setfdprm(8), then read the raw sectors with dd(1). The manpage for setfdprm(8) describes itself as "woefully inadequate," but a jaunt through the source code is enlightening, and provides us with the following parameters for a high-density disk:

sect=32 ssize=256 cyl=80 ds hd zerobased

... which matches up nicely with what we know about the disk format.

From here, it’s a simple matter to configure and image a disk:

setfdprm /dev/fd0 sect=32 ssize=256 cyl=80 ds hd zerobased
dd bs=256 if=/dev/fd0 of=disk.img

Handling a double-density disk requires a bit more tweaking, but the following is what’s required:

sect=16 ssize=256 cyl=80 ds dd zerobased

Formatting and Writing

Before writing the disk, it has to be low-level formatted using the correct parameters. The arguments we’ve already discussed are accepted by most everything in the fdutils arsenal, including superformat(8), so we can use that:

1: superformat /dev/fd0 sect=32 ssize=256 cyl=80 ds hd zerobased

Formatting will also set the parameters -- if you just formatted the disk, you can dd(1) the image onto it now. If the disk was already formatted, you can call setfdprm(8) after inserting it and just dd(1) the image.

This works for double-density media as well, however, the usual caveats about writing DD media in a HD drive apply. If it doesn’t work, format the disk on a true DD drive, or degauss the media entirely.

But why

Because even though the 9100 is awesome, its editing facilities leave a lot to be desired. There’s no concept of version control, and it’s relatively difficult to get debugged programs off it. Because of all that, I’ve been making an effort to move as much development as possible onto my regular workstation. I wrote an Emacs mode for the TL/1 programming language and have a Git repo with all my TL/1 code in it. I’ve created a build process which syntax checks everything (using Fluke’s MS-DOS TLC.EXE, inside a headless DOSBox), creates a userdisk structure, copies it into a disk image, and writes it to disk -- all with a single make(1) invocation.

Repairing a Sharp PC-1261 Pocket Computer

2018-12-02

Repairing a Sharp PC-1261 Pocket Computer

Background

I’ve been getting interested in vintage portable computers lately, and have bought a few to play with. The latest is a Sharp Pocket Computer PC-1261, which is a tiny calculator-sized machine from 1984. It has 10kb RAM, a two-line 24-character LCD display, a custom CPU that runs at 768khz, and you can program it in BASIC with the built-in QWERTY keypad. It runs for ever on two CR2032 button batteries.

While limited, it compares pretty favorably with other early-80s machines, and the portability you get for the compromise is pretty good.

Sharp made dozens of models and variants of pocket computers from the early 80s up until the late 1990s. They all blur the lines between computer and calculator, with the later models resembling graphing calculators, but also having an optional proprietary 2.5" external floppy disk drive.

The PC-1261 is one of the last/better models of the line which goes back to the PC-1211 from 1980. I got mine with a CE-125 microcasette/tape interface/thermal printer, which the PC-1261 slots right into, for programming on the go.

The Problem

When I got mine, the batteries were dead, but fortunately not leaking. I replaced them and it seemed to work, but would occasionally have some weird behavior when I was programming it. It worked perfectly in RUN mode (which is immediate, like a calculator), but didn’t work right in PRO (BASIC programming) mode. I also was seeing issues where the machine would seem to reset midway through entering a sequence, no matter what mode it was in.

This inconsistent, partly working behavior made me afraid it might be a fault on one of the parts on the PCB. Since they’re all custom QFP parts, this wasn’t something I would be able to repair, except by replacing the board with one from another machine. But, after messing with it a little more, I realized that it was a much simpler problem.

To change modes, you move a physical slide switch, and this switch wasn’t working reliably. When moved into PRO mode, the computer wouldn’t recognize it. Since you can’t enter BASIC programs in RUN mode, that explained the errors I was seeing. Also, when I’d stretch my hand to reach a key and the machine would seem to reset, that was the switch breaking contact and the machine losing power. This, then, is a problem I can fix.

Opening and Repairing the Computer

Figure 1: Back of the computer, showing a label with the former owner’s name

Two small Philips screws hold the metal back of the computer on, and removing them reveals this:

Figure 2: The inside back of the PC-1261

The metal cover on the left is where the batteries are. The PCB in the center holds the RAM. Top left is the display contrast pot. The right side has a cutout for the piezo speaker, as well as the expansion bus in the lower-right.

Figure 3: RAM module removed

Figure 4: RAM module

Next step is to remove the three screws securing the RAM module and remov it. There are two grounding springs and the actual connector is a rubberized conductive foam material.

The last screw secures the PCB and back plastic frame to the front of the machine. After the screw is removed, grab the bottom of the frame and PCB and lift it out. There are tabs which secure them under the top lip of the front of the case.

Be careful when removing these parts. The battery contacts in the plastic frame are soldered to the main PCB with thin wires. Also, this can happen:

Figure 5: Tiny plastic keys all over the place

They keys are tiny and will fly all over the place and get lost if you’re not careful.

Figure 6: Separated halves of the computer

Once the computer is open, you can see the key membrane. The mode switch and contacts are on the left. The switch has two metal contacts which touch pads on the PCB. The left side seems to be power to the computer, while the right controls the mode.

There was some visile crud on the PCB, which I cleaned the PCB with DeOxIt. I also used it on the switch contacts, then put everything back together. Unfortunately, it still didn’t work reliably.

Another trip inside the machine (along with messing up the keyboard again), I pulled the switch out completely, and bent the contacts down so they would make better contact with the PCB, and put it back together. Success! It worked perfectly. Except I put the A key back in sideways, and reversed the DEF and SHIFT keys. I opened it once again to correct these issues. The switch is working like it should now, and all the keys are where they should be.

Figure 7: The repaired computer, showing "HELLO, WORLD"

Atomized

Bootstrapping Nonguix

Maybe Later

Maybe Later

Atari Space Duel Self-Test ROM Signatures

Old McCarthy Had a Form

Old McCarthy Had a Form

What is EIEIO?

Why OOP Lisp?

The CLOS Model

Classes

Instantiation

Accessing Slots

Slot Initialization

Generic Functions

Methods & Specialization

Qualifiers

Multiple Inheritance

Structures

Nice Properties

Practical Examples

Example: transmission.el

Example: sql.el

Example: Modes

Conclusion

Common Lisp in Practice

Common Lisp in Practice

Introduction

Goals

Running the Examples

Background

The Environment; Images

Version 1: Quick & Dirty

The Toplevel Function

Packages

Exports

Tying it All Together

Building an Image

Version 2: Package Structure

Version 3: Systems

Defining the System

Version 4: Using Libraries

Quicklisp

Installing unix-opts

Defining the Systems

The New MAIN

Building

Conclusion

Further reading

Footnotes:

Repairing Asteroids

Repairing Asteroids

Repairing Asteroids ATTACH

Footnotes:

I like ThinkPads

I like ThinkPads

So Long, Apple

So Long, Apple

13" MacBook Air

iPhone 6

iPhone SE

iPad Mini 4

Bye

Handling OS-9 RBF (Fluke 9100) floppies on Linux

Handling OS-9 RBF (Fluke 9100) floppies on Linux

Background

Disk Format

Tuning

Formatting and Writing

But why

Repairing a Sharp PC-1261 Pocket Computer

Repairing a Sharp PC-1261 Pocket Computer

Background

The Problem

Opening and Repairing the Computer

Example: `transmission.el`

Example: `sql.el`

The New `MAIN`