In the world of children’s toys there are many offerings which are meant to look like devices used by older kids or even adults, with the Fisher Price Laugh & Learn Lil’ Gamer toy bearing quite the resemblance to Nintendo’s iconic Game Boy. Although this factoid could be filed away as amusing trivia before passing said toy to a child for its requisite physical abuse by said child, a purported adult can still have a lot of fun with this toy by modding it into a real Game Boy, as [KOUZEX] recently did.

Part of the challenge here is to not just treat it as an unconventional replacement shell for a genuine Game Boy, but to retain as much of the child toy’s look and feel as possible. This includes things like buttons and even the weird sliding blocks on the side.

For the functional components a Game Boy Color with a busted screen was chosen as a donor, with the GBC mainboard fitting almost perfectly inside its new shell. Wires were then soldered to bridge Nintendo’s PCB with the toy’s PCB to make the original buttons and speaker work. After blowing a fuse on the GBC mainboard due to likely some power back feeding, the toy’s PCB had its non-essential parts stripped, but fortunately without further damage to the grafted in electronics.

Most of this mod is quite straightforward, just with some creativity required to add a Select and Start button as these were notably absent from the original. The new, rather large replacement OLED screen is a nice upgrade too and actually fits pretty well with the chunky look of the child’s toy. Even as mostly a joke mod, it seems surprisingly functional.

I’ve had an idea rattling around to get more detail from coverage measurement. Can we measure the coverage in a function separately for each caller of the function?

Here’s why I want it: in Acidica, my toy BASIC interpreter, I had code to implement the built-in functions that looked something like this:

match func_name:



    case "LEN":

        if len(args) != 1:

            raise TypeError(f"Wrong arguments for LEN, got {len(args)}")

        return len(args[0])



    case "LEFT$":

        if len(args) != 2:

            raise TypeError(f"Wrong arguments for LEFT$, got {len(args)}")

        return args[0][:args[1]]



    # ... 19 other built-ins ...

I didn’t like the repeated code here: each different func_name has to check that it got its expected number of arguments and perhaps raise an error. So I refactored:

def expects(nargs: int, func_name: str, args: tuple) -> None:

    if len(args) != nargs:

        raise TypeError(f"Wrong arguments for {func_name}, got {len(args)}")



match func_name:

    case "LEN":

        expects(1, func_name, args)

        return len(args[0])



    case "LEFT$":

        expects(2, func_name, args)

        return args[0][:args[1]]

Nice. The code is tighter, easier to read, and common behavior is implemented in one place.

But the old code had an advantage: because each error condition had its own raise line, coverage measurement could tell me whether I had tested every func_name for the wrong number of arguments. With the error handling happening in a helper function, that information is lost. I’ll know that some func_name had a test for the wrong number of arguments, but not that all of them did.

Here’s where the new idea comes in. What if I could indicate that for the expects function, I want separate coverage data for each distinct calling site? Then I could see that every func_name had a test for both the wrong number of arguments and the right number of arguments. The simple branch inside expects would be measured separately for each caller.

I have a quick proof-of-concept. A decorator on expects does the work. Coverage.py already has dynamic contexts which are used for things like tracking which tests called which code. The decorator starts a new context named for the calling location, then restores the context when the function returns:

def coverage_per_caller(func):

    @functools.wraps(func)

    def _wrapper(*args, **kwargs):

        cov = coverage.Coverage.current()

        name = func.__name__

        caller = inspect.currentframe().f_back

        file = caller.f_code.co_filename

        lineno = caller.f_lineno

        prev_context = cov.switch_context(f"per_caller:{name}:{file}:{lineno}")

        try:

            ret = func(*args, **kwargs)

        finally:

            cov.switch_context(prev_context)

        return ret



    return _wrapper

I had to make one tiny (unreleased) change to coverage.py for this: switch_context used to return None, but now it returns the previous context so that we can nest them properly.

To my delight, this works! I can look at the HTML coverage report and see the caller contexts for the lines in expects. I can see that 20 callers ran the if line, but only 2 ran the raise, and the context names show the file and line number of the callers for each:

This isn’t the whole solution yet. Things to improve:

• I’d like to post-process these contexts to show which callers were missing lines inside expects. What I’m looking for is the same kind of “this line is missing” information that I got from the original inlined logic.
• These per-caller contexts overwrite the contexts we were already collecting (the test names). Ideally we’d have some kind of sub-context so that we could track both (or many) at once.
• It’s not great that I had to add a decorator to the source code. Driving this through the coverage configuration would keep these kinds of details out of the source.

But it’s a start, and gives me other ideas. I could use some aspect of the data passed into a function as the context name. In this example, we could have used func_name as the context instead of the caller’s location. Maybe you have ideas for other uses.

A whole bunch of emoji. What could they mean?

This particular post comes out of left field a bit. I was playing around with a web application I had made - an online disassembler for the x86 - when I noticed that emoji were being encoded into the url. 

I pasted a goat emoji, 🐐  and I noticed the encoding %F0%9F%90%90.

Now, if you're familiar with x86 assembly language at all, hexadecimal 90h is probably familiar to you. It's the opcode for a null operation or NOP.

I had a brief nerd chuckle over the thought that goats were the NOPs of emoji, but then I got curious. F0h on the 8088 is the LOCK prefix. This prefix is generally used to coordinate exclusive bus access with a coprocessor such as the 8087, but otherwise does nothing for most instructions on the 8088 and is ignored (this would change on later Intel CPUs). That leaves us with 9Fh. 

9Fh is LAHF. 

The entire goat emoji is valid 8088 machine code, a sequence that reads

lock lahf
nop
nop

As it turns out, the vast majority of emoji graphemes, as they are called, start with the sequence F09F. A dim little light bulb started to flicker above my head.  Could you actually write an 8088 program using nothing but displayable emoji?  

The idea is not without precedent. It has been well-established that executables can be generated with only printable ASCII characters - the most famous example probably being the EICAR test file, an ASCII string that is also a valid DOS executable that prints "EICAR-STANDARD-ANTIVIRUS-TEST-FILE!" and exits.

Other small ASCII programs were printed in magazines or distributed in other ways, such as the tiny terminal utility TCOM, the entire source of which is reproduced below:

XPHPD[0GG0G,0G51G31GB'(G+(G:u'0g?(G>(GE1G@arwIV_F*=US@>1|_,5wXNg-7muTu(4
1m0ss1k260s@3G1g360@3G0i7t2g3A1g350@3G2E1=0C1g350@3T2M0^\1g3>0@3T=1s2g0T
1g3;0@3ToN2g391g0t@3G0^F1k0s2?0@3T4

This is an interesting "emergency terminal" solution: if someone had no other means of loading an executable onto a computer system, it could simply be entered in via the keyboard. 

It surprises me that the idea of directly executing emoji has apparently never been explored.

Hello (World)!

Of course, the first thing to do is attempt Hello World! in emoji. For space reasons and partly due to the pain of doing any sort of arithmetic in emoji, we will only print the string HELLO.

Here is the full program:

🐸☺️🐰🐎♐🗃️🧯🧯🧯🐮💗🦮🪏♐🐰🐹🗃️🧯🧯🧯🧯💗🪗🧯😗🧮🫪😗🧮😗🐮😪😔⭐

Pasted into a text editor and saved as UTF-8, no BOM, with a .COM file extension, the result should be 141 bytes with an MD5 sum of 0a5c91475ca2de33e36aacc2f0b7b840.

The disassembly of the entire program can be viewed here.

Several emoji here may display as tofu, depending on your browser and what year you are reading this article.

🪏 is the shovel emoji, introduced in Unicode 16.0 in 2024.  These glyphs still take time to trickle down into font updates.

🪗 is the accordion emoji, added to Unicode 13.0 in 2020, but somehow still not visible in Chrome on Windows 10. Go figure.

🫪 is the "Distorted Face" emoji and is brand new in Unicode 17.0, approved in 2025. 

In theory, it should be possible to copy the relevant tofu character and preserve the representational bytes, but some operating systems and programs seem to struggle with the byte-preserving concept.

This program relies on a few undocumented 8088 aliases, and so requires a fairly accurate 8088 core to execute successfully. Let's see what it does in DOSBox-X with cpu cputype=8086:

The "Hello (World!)" program executing in DosBox-X

00000000  F0 9F     lahf
00000002  90        nop
00000003  B8 E2 98  mov ax,98E2h
00000006  BA EF B8  mov dx,B8EFh
00000009  8F        db 0x8F

0000012C  F0 9F  lahf
0000012E  92     xchg dx,ax
0000012F  97     xchg di,ax

00000146  83 EF B8  sub di,FFB8h

Emojissembly Reference

Standalone Emoji

Open-Tail Emoji

Useful Gadgets

These are complete, useful sequences of multiple emoji.

BunnySad: 🐰😔 - Stack repair

This eight-byte sequence deliberately replaces the current stack pointer with FFF0h:

0000: F0 9F    lahf
0002: 90       nop
0003: B0 F0    mov al,F0h
0005: 9F       lahf
0006: 98       cbw
0007: 94       xchg sp,ax

The rabbit's final B0h consumes the sad face's leading F0h, loading AL=F0h. The second LAHF is followed by CBW, which turns that into AX=FFF0h; XCHG then installs it as the stack pointer.

This is how to recover after intentional POPs and keep asynchronous interrupt pushes near the top of the segment. It discards the current stack, so it is safe only when no return address or saved value is live. The old SP is left in AX.

BunnySnowParty 🐰☃️🐰😔 - Safe addition: DI += 48h

This 18-byte sequence advances DI by 48h (72 decimal), absorbs the snowman's dangling POP, and repairs the stack:

0000: F0 9F       lahf
0002: 90          nop
0003: B0 E2       mov al,E2h
0005: 98          cbw
0006: 83 EF B8    sub di,FFB8h
0009: 8F F0       pop ax
000B: 9F          lahf
000C: 90          nop
000D: B0 F0       mov al,F0h
000F: 9F          lahf
0010: 98          cbw
0011: 94          xchg sp,ax

The first rabbit consumes the snowman's E2h; B8h is a signed -72 immediate, so SUB DI,-72 adds 72. The snowman's final 8Fh consumes the next rabbit's F0h as the undocumented POP AX encoding 8F F0. The final rabbit/sad-face pair restores SP=FFF0h.

This was one of the first gadgets found. The eye and plate gadgets are usually more efficient, but this one is included for completeness.

PlateGoat: 🍽️🐐 - Increment SP and advance DI

The plate needs a following byte to complete its final 8Fh. A padding goat is a convenient harmless tail.

0000: F0 9F          lahf
0002: 8D BD EF B8    lea di,[di-4711h]
0006: 8F F0          pop ax
0008: 9F             lahf
0009: 90             nop
000A: 90             nop

B8EFh is the 16-bit representation of -4711h, so the LEA performs DI += B8EFh. The plate's 8Fh consumes the goat's leading F0h as undocumented POP AX; the remaining 9F 90 90 is LAHF; NOP; NOP.

Plates advance SP by two as well as moving DI a significant distance. Plates are excellent for pointer arithmetic, but their stack effects must be accounted for.

CatGoat: 😿🐐 - Absolute DI reset

The crying cat opens MOV DI,imm16. A padding goat supplies the immediate.

0000: F0 9F       lahf
0002: 98          cbw
0003: BF F0 9F    mov di,9FF0h
0006: 90          nop
0007: 90          nop

This eight-byte gadget resets DI to 9FF0h without depending on its previous value. If another emoji replaces the goat, its leading F0 9F still becomes the immediate, but its remaining bytes execute as a tail and may further change DI.

CamelWrite: 🗓️ + arithmetic + 📗🐪 - Generate and write a byte

The generic form is 15 fixed bytes plus the chosen arithmetic sequence. Here is the simplest concrete example, 🗓️🐮📗🐪, using a cow to add one:

0000: F0 9F       lahf
0002: 97          xchg di,ax
0003: 93          xchg bx,ax
0004: EF          out dx,ax      ; spurious OUT to B8EFh
0005: B8 8F F0    mov ax,F08Fh
0008: 9F          lahf
0009: 90          nop
000A: AE          scasb
000B: F0 9F       lahf
000D: 93          xchg bx,ax
000E: 97          xchg di,ax
000F: F0 9F       lahf
0011: 90          nop
0012: AA          stosb

On entry, DI is the real output pointer and AX contains the arithmetic seed. 🗓️ moves the seed into DI and saves the output pointer in BX.

The middle emoji sequence performs arithmetic on this temporary DI; the cow above adds one.

📗 restores the output pointer and transfers the computed low byte into AL, and 🐪 writes it.

The calendar also performs OUT DX,AX. The common startup establishes DX=B8EFh, a generally unmapped port. Use with caution on real hardware!

FrogStrap: 🐸☺️😖🐰😗😯😯😯😯😯😯😯 - Common register bootstrap

This 50-byte sequence obtains a known zero from the normal COM entry stack and establishes a specific register state:

0000: F0 9F       lahf
0002: 90          nop
0003: B8 E2 98    mov ax,98E2h
0006: BA EF B8    mov dx,B8EFh
0009: 8F F0       pop ax
000B: 9F          lahf
000C: 98          cbw
000D: 96          xchg si,ax
000E: F0 9F       lahf
0010: 90          nop
0011: B0 F0       mov al,F0h
0013: 9F          lahf
0014: 98          cbw
0015: 97          xchg di,ax
0016: F0 9F       lahf
0018: 98          cbw
0019: AF          scasw
001A: F0 9F       lahf
001C: 98          cbw
001D: AF          scasw
001E: F0 9F       lahf
0020: 98          cbw
0021: AF          scasw
0022: F0 9F       lahf
0024: 98          cbw
0025: AF          scasw
0026: F0 9F       lahf
0028: 98          cbw
0029: AF          scasw
002A: F0 9F       lahf
002C: 98          cbw
002D: AF          scasw
002E: F0 9F       lahf
0030: 98          cbw
0031: AF          scasw

🐸☺️ loads DX=B8EFh and leaves a dangling 8Fh. The first byte of 😖 completes POP AX, obtaining the known zero at SS:FFFEh and wrapping SP to 0000h; the rest of 😖 moves that zero into SI.

🐰 consumes the leading F0h from 😗 to make AL=F0h, after which CBW; XCHG DI,AX establishes DI=FFF0h. Seven SCASWs advance it to FFFEh.

The final state is DX=B8EFh, SI=0000h, DI=FFFEh, and SP=0000h.

The value of B8EFh in DX is within the lower portion of CGA video memory if used as a segment.

An additional 😯 can roll DI over to 0000h. The value FFFEh left in DI has conceivable uses as a -2 constant.

🐸☺️🐰🐎♐ - Load the CGA segment

This 21-byte sequence exploits the original 8088's undocumented segment-register alias to establish ES=B8EFh:

0000: F0 9F       lahf
0002: 90          nop
0003: B8 E2 98    mov ax,98E2h
0006: BA EF B8    mov dx,B8EFh
0009: 8F F0       pop ax
000B: 9F          lahf
000C: 90          nop
000D: B0 F0       mov al,F0h
000F: 9F          lahf
0010: 90          nop
0011: 8E E2       mov es,dx
0013: 99          cwd
0014: 90          nop

A Basic Loader

bits 16
org 0

    push di
    pop  si                         ; SI = encoded emoji data
    mov  di,0100h
    push di                         ; RET target after reconstruction
    mov  cx,RAW_SIZE

.decode:
    lodsw                           ; discard the fixed F0 9F prefix
    lodsw                           ; AL=third UTF-8 byte, AH=fourth
    aad  8Fh                        ; AL=(AL + 8Fh*AH) & FFh; AH=0
    stosb
    loop .decode
    ret                             ; execute reconstructed COM at 0100h

A VGA Emoji Demo

Spoiler — click to reveal

1981 was a different time for computing. It was expensive (both hardware and software), and it was far from a given that machines from one vendor would be able to talk to those from another. In fact, Columbia University had just such a problem, so in 1981, Frank da Cruz and Bill Catchings designed a serial protocol they called Kermit. Because of the many quirks of the DEC-20 and IBM mainframes, the Kermit protocol was highly adaptable from the start: able to handle systems that had trouble processing more than 96 bytes of data at once, able to transfer 8-bit files over 7-bit links, able to translate between character sets (ASCII and EBCDIC then; now also various Unicodes), and of course, handling of error-prone serial links.

Kermit spread rapidly; by 1982, Kermit had been ported to MS-DOS and Unix. Eventually, C-Kermit (an implementation of Kermit in C) became the flagship Kermit. It gained TCP support, an interactive CLI, a powerful scripting language (with features from the shell, Lisp, and expect), and optimizations for today’s high-speed links, such as jumbo packets, sliding windows, and streaming modes. Along the way, Kermit flew on the International Space Station, ran data collection from sensors during hurricanes, and many other uses including postal systems, Boeing 787 manufacturing, and more.

Today, I use it as a powerful ssh wrapper (letting me easily transfer files through multiple nested ssh, sudo, su, etc. commands), a BBS client, to exchange data with me HP 48GX calculator, and so on. It’s also used today to transmit firmware updates to embedded devices. And, of course, anyone that works with vintage systems is likely to use Kermit at some point.

It wouldn’t be until the late 1990s that the TCP/IP stack was finally adopted by most OS vendors, establishing something of a common basis for communication. Of course, we assume this today. Though transferring large files between OSs (say, Linux, Windows, MacOS, Android, iPad, etc.) is still a challenge, even though they all speak TCP/IP! I find that the easiest way to get large files from two computers is to spin up Kermit (see ckwin for a Windows fork of C-Kermit) and just set up a TCP connection over the LAN. In fact, I added a new show interfaces command in C-Kermit 11, making it easy to see your system’s local IPs.

For most of its history, Columbia’s Kermit project was self-funded. Columbia charged for commercial use, which limited its inclusion in Linux distributions. In 2011, 30 years after its founding, Columbia canceled the Kermit Project and released C-Kermit as Open Source under a BSD license. Frank da Cruz, who had still been working with the Kermit project all those years, volunteered to continue maintaining Kermit outside Columbia, and continued development with alpha and beta releases through his retirement from the project in 2025.

I dive into this C codebase

As Debian maintainer of Kermit, I noticed some areas where it wasn’t matching modern expectations. One area was, not surprising for a project of its age, security. Another area was that its character set or line-ending conversions are usually not desired now; we are used to byte-identical binary transfers, and the defaults caused confusion and even some rare instances of data corruption. So I started making a few patches last year.

I’ve worked with old C codebases before, such as Varnish. I’ve generally hated it. You usually find a mix of bad and terrible practices, unclear memory management, and so forth.

But I’ve been living in the C-Kermit codebase for a few months now, and I enjoy it. Yes, this thing is still designed to build on VMS, OS/2, and with compilers that haven’t heard of ANSI — and those that require modern practices. (That em-dash was mine; I knew how to use them before LLMs existed and I’m not going to stop just because LLMs have copied people like me! No AI was used for this post.)

The there is an elegance in all of that. As I worked, I fixed a bunch more potential security issues, both with memory safety and with protecting against a malicious remote in roughly the same manner that some patches to scp did a few years back. I added IPv6 support, of course conditionally compiled because some systems C-Kermit builds on have never heard of IPv6 and never will. (And, of course, with fallback algorithms at runtime for systems that have IPv6 support but not IPv6 connectivity.)

I added unit tests and Python-based end-to-end tests, running nearly 2000 test cases in total. Along the way, I found and fixed a number of bugs going back decades. I learned about FIONREAD being broken on macOS, about NetBSD’s bugs in the pty driver, and fixed bugs in the Kermit protocol implementation itself. I added compatibility tests with the gkermit and ekermit (embedded) implementations, as well as the last full release, C-Kermit 9.0.302 from 2011 (which was difficult to get compiled on a modern system).

There is an extensive changelog describing all the improvements in C-Kermit 11.

C-Kermit development had never really used a VCS at any point, though Kermit veteran Jeffrey Altman imported historical releases into a Git repo, along with some patches that hadn’t made it into a release (which I also pulled in.) There was a lot of disabled code behind #ifdef COMMENT, along with commentary describing why it was no longer used. With Git, we would now generally just remove the old code and explain why in a commit message. I went through and did so with a lot of it, meaning that, at last check, C-Kermit actually has fewer lines of code now than it used to.

Towards a new release

It became apparent pretty quickly that I was making more changes than would make sense as a Debian patch series. Not only that, but they would be more widely applicable to more than just Debian and Ubuntu users. As Linux and BSD distributions were running everything from the last non-beta release (2011’s 9.0.302) to the last beta release (about 1.5 years ago), depending on their different policies about running betas, even sharing patches in a useful fashion was going to be quite difficult.

So, I spun up a project at Open Kermit to coordinate future development in the open and keep Kermit going.

With modern CI, I run that test suite on Linux (x86_64 and arm64), macOS, FreeBSD, NetBSD, and OpenBSD. It builds binary releases on all those platforms, plus a statically-linked Linux binary built with musl libc.

You can download the latest C-Kermit release, and of course contribute to C-Kermit and its website.

Dedication

Frank da Cruz was directly involved with Kermit for 44 years. I’m not aware of any other Open Source project founder being involved for so long. Richard Stallman started working on GNU Emacs in 1984, 3 years after Frank started working on Kermit, but Richard hasn’t been in that role since around 2008.

Accordingly, C-Kermit 11 bears this dedication:

I dedicate this release of C-Kermit to Frank da Cruz.

Frank was directly involved with Kermit for 44 years, from its initial design in 1981 all the way through 2025. He maintained Kermit as an Open Source project after Columbia University ended its sponsorship. I know of no other Open Source project where the founder remains so personally involved for so long.

When Kermit was begun, transfers between different hardware and operating systems were difficult or impossible. Frank helped build a bridge. Kermit glued systems together, from the International Space Station to pocket calculators, and set a new standard for interoperability. It continues to do so.

Kermit is still one of the quietly-working pillars of computing today, enabling everything from firmware upgrades to radios. And, yes, it still reliably transfers files over serial lines.

As we start to spend a lot of time in the Kermit codebase, we do so standing on the shoulders of a giant. Thanks, Frank, for your decades of work on Kermit.

John Goerzen, July 2026

The release of NetBSD 11.0, the 19th major version of the operating system, has been announced. There are many changes and enhancements since the 10.1 release, including a new port to RISC-V, better support for Linux system calls in compat_linux(), as well as improvements to the NPF firewall.

As you are probably aware, the number of security issues found or suspected everywhere has massively increased with the advent of AI tools. As a consequence, we can't publish a release without open issues. Instead of delaying the release further to fix them (new ones are being reported all the time), we've instead chosen to be transparent about this.

See the full release notes for links to the binary distributions and links to the full change logs.

Project LANA interim report on IUT theory, “As of July 2026, the LANA Project has not made a final judgment on the correctness or incorrectness of IUT theory. However, through the multiple bootcamps held since February 2025 and lively discussions during numerous online meetings, it has progressed to the point of transforming the core of the controversy, which for many years had been discussed in vague terms, into the form of diagrams, types, code, black boxes, and explicit questions”, and later: “we are reserving our final judgment on whether a proof exists for Corollary 3.12 in Mochizuki’s third paper on IUT theory.”

Silk, a cooperative fiber scheduler for Linux with per-CPU scheduler threads, io_uring integration, and topology-aware work-stealing. By ClickHouse.

The git history command deserves more attention, useful additions in Git 2.55.

Justif is a JavaScript library that applies TeX-style paragraph layout to existing HTML.

Fast Synthesis of Basic Oscillators, by Artemis Everfree.

E73, a rendering of the ECMA-42 standard bitmap printer font from 1973.

Why did early ASCII have ← and ↑ but not ↓ or →?

BSD Make extravaganza computes the Mandelbrot set in bmake.

Bad Apple, animated in the browser, without JS and CSS.

Frankfurt Schoodle, guess the author of a quote.